格式深度解析：從TextFile到ORC/Parquet的性能調(diào)優(yōu)實(shí)戰(zhàn))
1. 項(xiàng)目概述為什么Hive存儲(chǔ)格式是數(shù)據(jù)工程師的必修課剛接觸Hive的時(shí)候很多人覺得建個(gè)表、寫個(gè)SQL把數(shù)據(jù)導(dǎo)進(jìn)去就完事了至于數(shù)據(jù)在底層是怎么存的似乎沒那么重要。直到某天你發(fā)現(xiàn)一個(gè)看似簡單的查詢跑了半個(gè)小時(shí)或者一個(gè)只有幾列的表卻占用了驚人的存儲(chǔ)空間你才會(huì)意識(shí)到數(shù)據(jù)存儲(chǔ)格式的選擇遠(yuǎn)不止是“存進(jìn)去”那么簡單它直接決定了查詢性能、存儲(chǔ)成本和運(yùn)維復(fù)雜度。今天我們就來徹底拆解Hive中那些核心的數(shù)據(jù)存儲(chǔ)格式從最基礎(chǔ)的TextFile到復(fù)雜的ORC、Parquet我會(huì)結(jié)合自己踩過的坑和調(diào)優(yōu)經(jīng)驗(yàn)把它們的原理、選型場景和實(shí)操細(xì)節(jié)講透。無論你是正在搭建數(shù)倉還是優(yōu)化現(xiàn)有作業(yè)理解這些格式都能讓你在數(shù)據(jù)處理的路上少走很多彎路。2. Hive存儲(chǔ)格式核心原理與設(shè)計(jì)思路拆解2.1 存儲(chǔ)格式的本質(zhì)在性能與通用性之間做權(quán)衡Hive本身并不直接存儲(chǔ)數(shù)據(jù)它只是一個(gè)在Hadoop生態(tài)之上的數(shù)據(jù)倉庫工具其數(shù)據(jù)實(shí)際存儲(chǔ)在HDFS這樣的分布式文件系統(tǒng)中。因此Hive的存儲(chǔ)格式本質(zhì)上就是HDFS上文件的組織方式。這個(gè)組織方式的核心矛盾始終圍繞著“寫”和“讀”的效率以及“空間”和“時(shí)間”的交換。寫優(yōu)化 vs. 讀優(yōu)化像TextFile、SequenceFile這類格式寫入時(shí)非常簡單直接幾乎不需要額外的計(jì)算開銷屬于“寫友好”型。但讀取時(shí)尤其是需要過濾某些列或行時(shí)它們往往需要掃描大量無關(guān)數(shù)據(jù)效率低下。而像ORC、Parquet這類列式存儲(chǔ)格式寫入時(shí)需要將行數(shù)據(jù)打散、按列重組、壓縮過程復(fù)雜寫不友好但讀取時(shí)尤其是分析型查詢只涉及少數(shù)幾列時(shí)可以極大地減少I/O屬于“讀友好”型。大數(shù)據(jù)場景下數(shù)據(jù)通常是一次寫入、多次查詢所以犧牲寫入性能換取極致的讀取性能是列式存儲(chǔ)大行其道的根本原因。空間 vs. 時(shí)間壓縮是節(jié)省存儲(chǔ)空間的利器。但壓縮和解壓需要消耗CPU時(shí)間。不同的存儲(chǔ)格式對(duì)壓縮的支持程度不同。TextFile雖然可以壓縮但壓縮后的文件不可分割可能破壞MapReduce的并行度。而ORC、Parquet這類格式其文件內(nèi)部有精密的組織結(jié)構(gòu)如Stripe、Row Group支持在文件內(nèi)部塊級(jí)別進(jìn)行壓縮同時(shí)保持塊的可分割性從而在節(jié)省空間的同時(shí)不損失并行處理能力。序列化與反序列化這是影響CPU開銷的關(guān)鍵。TextFile的每一行文本在計(jì)算時(shí)都需要被解析成對(duì)應(yīng)的數(shù)據(jù)類型如將字符串“123”解析成整數(shù)123這個(gè)解析反序列化開銷巨大。而二進(jìn)制格式如SequenceFile、ORC數(shù)據(jù)以緊湊的二進(jìn)制形式存儲(chǔ)反序列化效率極高。Hive在計(jì)算時(shí)從磁盤讀到內(nèi)存的原始數(shù)據(jù)需要被轉(zhuǎn)換成Java對(duì)象高效的二進(jìn)制序列化框架能大幅降低這個(gè)過程的開銷。2.2 主流格式演進(jìn)脈絡(luò)從“能用”到“高效”理解格式的演進(jìn)能幫你更好地把握其設(shè)計(jì)初衷。早期Hadoop生態(tài)中TextFile是事實(shí)上的標(biāo)準(zhǔn)因?yàn)樗祟惪勺x、通用性強(qiáng)任何文本工具都能處理。但隨著數(shù)據(jù)量激增其性能瓶頸凸顯。SequenceFile作為Hadoop原生的二進(jìn)制格式出現(xiàn)解決了小文件問題和序列化效率但依然是行式存儲(chǔ)對(duì)于分析查詢優(yōu)化有限。真正的轉(zhuǎn)折點(diǎn)來自于對(duì)數(shù)據(jù)分析模式的深刻洞察。傳統(tǒng)的行式存儲(chǔ)適合事務(wù)處理OLTP比如需要獲取某個(gè)用戶的所有信息。而數(shù)據(jù)倉庫的分析查詢OLAP通常是“掃描全表但只關(guān)心少數(shù)幾列”例如“計(jì)算所有用戶的平均年齡”。基于此列式存儲(chǔ)理念被引入RCFileRecord Columnar File是Hive社區(qū)早期的列式存儲(chǔ)嘗試。它將數(shù)據(jù)先按行組Row Group分割在行組內(nèi)再按列存儲(chǔ)并引入了輕量級(jí)索引。RCFile證明了列式存儲(chǔ)在Hive中的巨大潛力但其索引能力較弱壓縮和編碼算法也比較基礎(chǔ)。ORCOptimized Row Columnar和Parquet可以看作是RCFile的“完全體”升級(jí)。它們?cè)赗CFile行組的概念上設(shè)計(jì)了更精細(xì)的數(shù)據(jù)結(jié)構(gòu)ORC的StripeParquet的Row Group內(nèi)置了更強(qiáng)大的索引如布隆過濾器、最小值/最大值索引支持更高效的壓縮編碼如字典編碼、游程編碼并且提供了ACID事務(wù)等高級(jí)特性。可以說ORC和Parquet是為現(xiàn)代大數(shù)據(jù)分析場景量身定制的存儲(chǔ)格式。注意不要孤立地看待某種格式。選擇哪種格式必須緊密結(jié)合你的數(shù)據(jù)特征寬表還是窄表字段類型、訪問模式點(diǎn)查還是全表掃描經(jīng)常過濾哪些字段和計(jì)算引擎Hive MRTezSparkPresto來綜合決策。3. 五大核心存儲(chǔ)格式深度解析與實(shí)操要點(diǎn)3.1 TextFile最原始的雙刃劍TextFile是Hive默認(rèn)的存儲(chǔ)格式。數(shù)據(jù)以純文本形式存儲(chǔ)每行一條記錄字段間通常用特定分隔符如\001、逗號(hào)、制表符分隔。創(chuàng)建表示例CREATE TABLE user_behavior_text ( user_id BIGINT, item_id BIGINT, category_id INT, behavior_type STRING, timestamp BIGINT ) ROW FORMAT DELIMITED FIELDS TERMINATED BY ‘,‘ -- 指定逗號(hào)為字段分隔符 STORED AS TEXTFILE;核心特點(diǎn)與適用場景優(yōu)點(diǎn)人類可讀直接用cat、head命令或文本編輯器查看調(diào)試數(shù)據(jù)極其方便。通用性強(qiáng)任何能處理文本的工具如Shell腳本、Python、Java都可以直接讀寫生態(tài)兼容性最好。寫入簡單數(shù)據(jù)無需復(fù)雜編碼直接寫入適合作為數(shù)據(jù)接入層的原始格式。缺點(diǎn)存儲(chǔ)空間大無任何壓縮數(shù)值、日期等類型也用字符串存儲(chǔ)空間利用率極低。解析開銷大查詢時(shí)需將文本行解析成各個(gè)字段并做類型轉(zhuǎn)換CPU消耗嚴(yán)重。不支持塊壓縮雖然可以對(duì)整個(gè)文件用Gzip、Bzip2壓縮但壓縮后的文件不可分割會(huì)變成單個(gè)Map任務(wù)處理嚴(yán)重拖慢作業(yè)。實(shí)操心得僅用于數(shù)據(jù)接入和交換適合存放從業(yè)務(wù)系統(tǒng)同步過來的最原始日志、CSV文件作為ODS層操作數(shù)據(jù)層的臨時(shí)存儲(chǔ)。避免用于生產(chǎn)分析絕對(duì)不要將TextFile作為數(shù)倉DWD/DWS層的存儲(chǔ)格式性能會(huì)成為災(zāi)難。分隔符選擇優(yōu)先使用不可見字符如\001Ctrl-A、\002Ctrl-B等因?yàn)樗鼈儙缀醪粫?huì)出現(xiàn)在業(yè)務(wù)數(shù)據(jù)中比逗號(hào)、制表符更安全。3.2 SequenceFileHadoop原生的二進(jìn)制容器SequenceFile是Hadoop設(shè)計(jì)的一種用于存儲(chǔ)二進(jìn)制鍵值對(duì)的扁平文件格式。在Hive中通常將整個(gè)行作為值Value而鍵Key可以忽略或存儲(chǔ)行號(hào)。創(chuàng)建表示例CREATE TABLE user_behavior_seq ( user_id BIGINT, item_id BIGINT, category_id INT, behavior_type STRING, timestamp BIGINT ) STORED AS SEQUENCEFILE;核心特點(diǎn)與適用場景優(yōu)點(diǎn)可分割支持塊壓縮Block Compression壓縮后的文件依然可以被多個(gè)Map任務(wù)并行處理。序列化高效以二進(jìn)制存儲(chǔ)省去了TextFile的文本解析開銷。適合小文件可以將大量小文件合并成少量SequenceFile解決HDFS小文件元數(shù)據(jù)壓力過大的問題。缺點(diǎn)非人類可讀二進(jìn)制格式無法直接查看內(nèi)容。依然是行式存儲(chǔ)查詢時(shí)仍需讀取整行數(shù)據(jù)對(duì)于分析型查詢優(yōu)化有限。Hive生態(tài)外支持弱相比TextFile其他非Hadoop生態(tài)工具處理起來較麻煩。實(shí)操心得小文件合并利器在數(shù)據(jù)采集階段如Flume可以配置Sink將數(shù)據(jù)寫入SequenceFile避免產(chǎn)生海量小TextFile。中間格式過渡在某些ETL流水線中可以作為中間步驟的存儲(chǔ)格式比TextFile高效又比ORC/Parquet寫入快。壓縮配置建表時(shí)可以指定壓縮算法如SET hive.exec.compress.outputtrue; SET mapred.output.compression.codecorg.apache.hadoop.io.compress.SnappyCodec;推薦使用Snappy在壓縮比和速度間取得平衡。3.3 RCFile列式存儲(chǔ)的先行者RCFile的設(shè)計(jì)理念是“先按行組分再按列存”。它先將數(shù)據(jù)劃分成多個(gè)行組Row Group在每個(gè)行組內(nèi)數(shù)據(jù)按列存儲(chǔ)在一起并對(duì)每列進(jìn)行壓縮。核心特點(diǎn)與適用場景優(yōu)點(diǎn)列式存儲(chǔ)優(yōu)勢(shì)在只查詢少數(shù)列時(shí)可以跳過其他列的數(shù)據(jù)減少I/O。可分割行組是數(shù)據(jù)分割和并行處理的基本單位。輕量級(jí)索引行組頭部存儲(chǔ)了每列的行數(shù)、壓縮大小等信息并提供每列在行組內(nèi)的偏移量便于快速定位。缺點(diǎn)索引能力弱只有基本的行組級(jí)統(tǒng)計(jì)信息沒有列級(jí)的細(xì)粒度索引如最小值/最大值。寫入性能差需要緩存整個(gè)行組的數(shù)據(jù)才能按列壓縮寫入內(nèi)存消耗較大。已逐漸被淘汰ORC在各方面都優(yōu)于RCFile目前新項(xiàng)目已很少使用RCFile。實(shí)操要點(diǎn)歷史遺產(chǎn)如果你維護(hù)的老系統(tǒng)還在用RCFile了解其原理有助于遷移或優(yōu)化。但在新項(xiàng)目中應(yīng)直接選擇ORC或Parquet。理解行組大小通過參數(shù)hive.io.rcfile.record.buffer.size可以設(shè)置行組緩沖區(qū)大小影響寫入性能和查詢時(shí)的I/O粒度。3.4 ORCHive親生的高性能列式格式ORC是Hive社區(qū)專為Hive設(shè)計(jì)的高性能列式存儲(chǔ)格式可以理解為RCFile的全面優(yōu)化版。它的文件結(jié)構(gòu)非常精巧。一個(gè)ORC文件由以下幾部分組成文件腳注Footer包含文件的元數(shù)據(jù)如模式Schema、行數(shù)、每個(gè)Strip的信息。條帶StripeORC文件的水平分割單元相當(dāng)于RCFile的行組升級(jí)版。通常大小建議為256MB。索引數(shù)據(jù)Index Data存儲(chǔ)Stripe內(nèi)每列的最小值、最大值、行索引以及布隆過濾器可選。這是ORC查詢快的核心使得查詢引擎可以快速跳過不滿足條件的整個(gè)Stripe。行數(shù)據(jù)Row Data按列存儲(chǔ)的實(shí)際數(shù)據(jù)每列獨(dú)立壓縮編碼。條帶腳注Stripe Footer存儲(chǔ)Stripe內(nèi)數(shù)據(jù)流的目錄信息。Postscript文件末尾記錄文件壓縮參數(shù)、版本等信息。創(chuàng)建表與高級(jí)參數(shù)示例CREATE TABLE user_behavior_orc ( user_id BIGINT, item_id BIGINT, category_id INT, behavior_type STRING, timestamp BIGINT ) STORED AS ORC TBLPROPERTIES ( ‘orc.compress‘‘SNAPPY‘, -- 壓縮算法可選NONE, ZLIB, SNAPPY ‘orc.stripe.size‘‘268435456‘, -- Stripe大小256MB ‘orc.row.index.stride‘‘10000‘, -- 索引粒度每10000行建一個(gè)索引項(xiàng) ‘orc.create.index‘‘true‘, -- 創(chuàng)建行索引 ‘orc.bloom.filter.columns‘‘user_id,behavior_type‘ -- 為指定列創(chuàng)建布隆過濾器 );核心優(yōu)勢(shì)與實(shí)操心得索引能力超強(qiáng)基于最小值/最大值索引的謂詞下推是ORC的王牌功能。例如查詢WHERE user_id 100000Hive可以直接根據(jù)每個(gè)Stripe的user_id列索引跳過所有max(user_id) 100000的Stripe極大減少數(shù)據(jù)掃描量。布隆過濾器對(duì)等值查詢?nèi)鏦HERE behavior_type‘buy‘過濾效果極佳。壓縮編碼高效針對(duì)不同數(shù)據(jù)類型采用特定編碼。整數(shù)類型采用行程長度編碼Run-Length Encoding, RLE和差值編碼Delta Encoding對(duì)于連續(xù)重復(fù)或遞增的值壓縮比驚人。字符串類型采用字典編碼Dictionary Encoding將重復(fù)的字符串值用數(shù)字ID代替對(duì)于低基數(shù)列如gender,city效果顯著。ACID事務(wù)支持從Hive 0.14開始ORC格式的表支持完整的ACID事務(wù)允許INSERT、UPDATE、DELETE這對(duì)于需要數(shù)據(jù)更新的場景至關(guān)重要。向量化查詢ORC格式完美支持Hive的向量化查詢引擎hive.vectorized.execution.enabledtrue。該引擎一次處理一批數(shù)據(jù)一個(gè)向量而不是一行充分利用現(xiàn)代CPU的SIMD指令將性能提升數(shù)倍甚至數(shù)十倍。重要提示要發(fā)揮ORC索引的優(yōu)勢(shì)必須對(duì)常作為查詢條件的列進(jìn)行排序。例如如果查詢總是按dt日期分區(qū)并按user_id過濾那么在插入數(shù)據(jù)時(shí)應(yīng)確保數(shù)據(jù)在每個(gè)分區(qū)內(nèi)按user_id有序。無序的數(shù)據(jù)會(huì)使索引的最小值/最大值范圍變得很寬失去過濾意義。可以通過INSERT ... SELECT ... ORDER BY或在計(jì)算引擎如Spark中寫入前重分區(qū)排序來實(shí)現(xiàn)。3.5 Parquet跨平臺(tái)的標(biāo)準(zhǔn)列式格式Parquet的設(shè)計(jì)理念與ORC類似但它的目標(biāo)是成為Hadoop生態(tài)系統(tǒng)中通用的列式存儲(chǔ)格式由Apache頂級(jí)項(xiàng)目支持不與任何計(jì)算引擎綁定。Parquet文件核心結(jié)構(gòu)行組Row Group邏輯上的水平分割包含一批行類似ORC的Stripe。列塊Column Chunk行組中每一列的數(shù)據(jù)。一個(gè)行組中有多少個(gè)列就有多少個(gè)列塊。頁P(yáng)age列塊被進(jìn)一步劃分為頁頁是壓縮、編碼和讀寫的最小單元。包含數(shù)據(jù)頁和字典頁等。頁頭存儲(chǔ)頁的元數(shù)據(jù)如編碼、壓縮后大小、未壓縮大小等。創(chuàng)建表示例CREATE TABLE user_behavior_parquet ( user_id BIGINT, item_id BIGINT, category_id INT, behavior_type STRING, timestamp BIGINT ) STORED AS PARQUET TBLPROPERTIES ( ‘parquet.compression‘‘SNAPPY‘, ‘parquet.block.size‘‘268435456‘ -- 行組大小256MB );核心優(yōu)勢(shì)與選型考量跨平臺(tái)原生支持這是Parquet最大的優(yōu)勢(shì)。Spark、Flink、Presto、Impala等主流計(jì)算引擎都對(duì)Parquet提供了原生Native支持讀寫性能最優(yōu)。而它們對(duì)ORC的支持可能通過Hive兼容層實(shí)現(xiàn)性能有時(shí)不如Parquet。嵌套數(shù)據(jù)模型支持出色Parquet原生支持復(fù)雜的嵌套數(shù)據(jù)結(jié)構(gòu)如struct,array,map其schema定義采用Dremel論文中的重復(fù)與定義級(jí)別非常高效。如果你的數(shù)據(jù)是半結(jié)構(gòu)化的JSON或Avro格式轉(zhuǎn)換為Parquet后能獲得很好的查詢性能和壓縮比。廣泛的生態(tài)工具大量數(shù)據(jù)工具如AWS Athena、Google BigQuery、Pandas都能直接讀取Parquet文件。ORC vs. Parquet 如何選擇這是一個(gè)常見問題。我的經(jīng)驗(yàn)是如果你的技術(shù)棧以Hive為核心且需要用到Hive特有的高級(jí)功能如ACID事務(wù)、復(fù)雜的物化視圖或者你的查詢模式能很好地利用排序索引ORC是更優(yōu)選擇。如果你的技術(shù)棧是混合的例如同時(shí)使用Hive、Spark、Presto或者未來有遷移到其他引擎的可能Parquet是更安全、更通用的選擇。如果你的數(shù)據(jù)是高度嵌套的如事件日志、JSON文檔Parquet對(duì)嵌套結(jié)構(gòu)的支持更成熟。從純性能角度看兩者在多數(shù)場景下相差無幾。ORC在Hive上的謂詞下推可能略強(qiáng)Parquet在Spark上的掃描性能可能略優(yōu)。真正的性能差異往往來自于數(shù)據(jù)布局如分區(qū)、排序和查詢寫法而非格式本身。4. 存儲(chǔ)格式實(shí)戰(zhàn)從選型到調(diào)優(yōu)全流程4.1 新項(xiàng)目存儲(chǔ)格式選型決策流程面對(duì)一個(gè)新項(xiàng)目我通常會(huì)遵循以下流程來選擇存儲(chǔ)格式分析數(shù)據(jù)特征與訪問模式數(shù)據(jù)量級(jí)TB級(jí)以下格式選擇影響不大PB級(jí)必須使用列式存儲(chǔ)。表寬度字段數(shù)超過30個(gè)的寬表列式存儲(chǔ)的I/O優(yōu)勢(shì)極其明顯。查詢模式列出高頻查詢語句。是否總是SELECT少數(shù)幾列WHERE條件是否集中在某幾列是否有ORDER BY或GROUP BY數(shù)據(jù)更新需求是否需要UPDATE/DELETE如果需要ORC開啟ACID或Hudi/Delta Lake基于Parquet/ORC是候選。評(píng)估技術(shù)棧與團(tuán)隊(duì)技能團(tuán)隊(duì)主要使用Hive還是Spark未來技術(shù)路線圖如何團(tuán)隊(duì)成員對(duì)哪種格式更熟悉運(yùn)維工具鏈?zhǔn)欠裰С謭?zhí)行概念驗(yàn)證抽取一份樣本數(shù)據(jù)如最近一周分別用ORC和Parquet格式建表。運(yùn)行典型的高頻查詢對(duì)比執(zhí)行時(shí)間和資源消耗。檢查文件大小對(duì)比壓縮比。制定規(guī)范并落地將選型結(jié)果寫入團(tuán)隊(duì)的數(shù)據(jù)開發(fā)規(guī)范。在數(shù)倉各層明確格式要求例如ODS層可用TextFile/SequenceFileDWD/DWS層統(tǒng)一使用Parquet。4.2 建表與數(shù)據(jù)寫入最佳實(shí)踐選好格式后建表和寫入數(shù)據(jù)是下一個(gè)關(guān)鍵步驟。分區(qū)與分桶 存儲(chǔ)格式解決的是文件內(nèi)部的效率問題而分區(qū)和分桶解決的是文件組織的問題兩者結(jié)合才能發(fā)揮最大效力。-- 分區(qū)表示例按日期分區(qū)是標(biāo)配 CREATE TABLE dwd_user_behavior_parquet ( user_id BIGINT, item_id BIGINT, category_id INT, behavior_type STRING ) PARTITIONED BY (dt STRING) -- 按天分區(qū) STORED AS PARQUET TBLPROPERTIES (‘parquet.compression‘‘SNAPPY‘); -- 分桶表示例對(duì)常做JOIN鍵或GROUP BY鍵的列分桶 CREATE TABLE dws_user_behavior_bucketed ( user_id BIGINT, buy_count INT, ... ) CLUSTERED BY (user_id) INTO 32 BUCKETS -- 按user_id哈希分桶 STORED AS ORC;分區(qū)將數(shù)據(jù)按某個(gè)字段通常是日期分布到不同目錄。查詢時(shí)通過WHERE dt‘2023-10-01‘可以分區(qū)裁剪直接跳過無關(guān)分區(qū)目錄。分桶將數(shù)據(jù)按某個(gè)字段的哈希值分散到固定數(shù)量的文件中。對(duì)于大表JOIN或大表GROUP BY能轉(zhuǎn)化為桶對(duì)桶的高效操作避免Shuffle。數(shù)據(jù)有序?qū)懭?如前所述對(duì)于ORC/Parquet有序的數(shù)據(jù)能極大提升索引效率。在Spark中寫入時(shí)可以這樣做df.repartition(1).sortWithinPartitions(“user_id”) // 先合并成一個(gè)分區(qū)再排序適用于小文件合并場景 .write.mode(“append”) .partitionBy(“dt”) .format(“parquet”) .saveAsTable(“dwd_table”)或者使用Hive的DISTRIBUTE BY和SORT BYINSERT OVERWRITE TABLE dwd_table PARTITION (dt) SELECT * FROM source_table DISTRIBUTE BY dt, FLOOR(user_id / 10000) -- 保證相同范圍的數(shù)據(jù)進(jìn)入同一個(gè)Reducer SORT BY dt, user_id; -- 在Reducer內(nèi)排序4.3 性能調(diào)優(yōu)關(guān)鍵參數(shù)實(shí)戰(zhàn)不同的格式有其關(guān)鍵的調(diào)優(yōu)旋鈕這里列舉一些最實(shí)用的ORC調(diào)優(yōu)參數(shù)orc.stripe.size默認(rèn)256MB。增大此值如512MB可以提高壓縮比和順序I/O效率但會(huì)消耗更多內(nèi)存。對(duì)于超大規(guī)模表可以適當(dāng)調(diào)大。orc.row.index.stride默認(rèn)10000行。索引條目間隔。減小此值會(huì)創(chuàng)建更密集的索引加快點(diǎn)查但增加存儲(chǔ)開銷。對(duì)于經(jīng)常按主鍵查詢的表可以設(shè)為5000。orc.bloom.filter.columns和orc.bloom.filter.fpp為高基數(shù)的等值過濾列如user_id創(chuàng)建布隆過濾器并設(shè)置誤報(bào)率默認(rèn)0.05。能高效過濾掉不滿足條件的Stripe。hive.vectorized.execution.enabledtrue務(wù)必開啟向量化查詢。對(duì)于ORC格式還需要設(shè)置hive.vectorized.execution.enabledtrue。Parquet調(diào)優(yōu)參數(shù)parquet.block.size默認(rèn)128MB。相當(dāng)于行組大小。建議設(shè)置為256MB或512MB與HDFS塊大小對(duì)齊如128MB的倍數(shù)以獲得更好的并行度。parquet.page.size默認(rèn)1MB。頁是編碼和壓縮的最小單元。對(duì)于有很多小字段的表可以適當(dāng)減小頁大小以提高隨機(jī)訪問性能對(duì)于大字段如長文本可以增大頁大小。parquet.dictionary.page.size默認(rèn)1MB。字典頁大小。對(duì)于低基數(shù)列確保字典頁足夠容納所有唯一值否則會(huì)退回到明文編碼。通用壓縮算法選擇Snappy默認(rèn)推薦。壓縮和解壓速度極快壓縮比中等。追求查詢性能時(shí)的首選。Zlib/Gzip壓縮比高但壓縮和解壓速度慢。適合對(duì)存儲(chǔ)成本極其敏感、且數(shù)據(jù)冷熱分明冷數(shù)據(jù)很少被查詢的場景。LZO需要單獨(dú)安裝編解碼器。速度與Snappy相當(dāng)壓縮比略好但生態(tài)支持不如Snappy廣泛。5. 常見問題排查與實(shí)戰(zhàn)技巧實(shí)錄5.1 查詢性能不及預(yù)期先檢查這些點(diǎn)即使使用了ORC/Parquet查詢也可能很慢。別急著怪格式按以下順序排查是否觸發(fā)了分區(qū)裁剪檢查執(zhí)行計(jì)劃EXPLAIN命令確認(rèn)你的WHERE條件中的分區(qū)字段是常量而不是函數(shù)計(jì)算如WHERE dt ‘20231001‘有效WHERE substr(dt,1,6)‘202310‘可能無效。謂詞下推是否生效對(duì)于ORC/Parquet在WHERE中對(duì)有索引的列進(jìn)行過濾應(yīng)該能在執(zhí)行計(jì)劃的TableScan階段就看到過濾條件。如果沒有檢查數(shù)據(jù)類型是否一致避免隱式轉(zhuǎn)換或者嘗試使用CAST函數(shù)。數(shù)據(jù)是否有序檢查用于過濾的列如user_id在文件內(nèi)是否大致有序。可以抽樣查看文件頭部的統(tǒng)計(jì)信息Hive命令hive --orcfiledump /path/to/file.orc如果某個(gè)列的min和max值相差巨大且覆蓋了整個(gè)范圍說明數(shù)據(jù)無序索引失效。小文件問題如果表目錄下有成千上萬個(gè)小文件比如每個(gè)只有幾MB那么啟動(dòng)Map任務(wù)的開銷將遠(yuǎn)超實(shí)際計(jì)算開銷。解決方案使用INSERT OVERWRITE語句重寫表或者使用計(jì)算引擎如Spark的coalesce或repartition功能合并小文件后再寫入。壓縮算法是否合適如果查詢CPU瓶頸明顯而I/O不是問題可以嘗試將壓縮算法從Zlib切換到Snappy甚至不壓縮NONE用空間換時(shí)間。5.2 從TextFile遷移到列式存儲(chǔ)的平滑方案遷移歷史數(shù)據(jù)是個(gè)大工程切忌一次性全量重寫。我的建議是采用雙軌并行、逐步切換的策略創(chuàng)建新表使用目標(biāo)格式如Parquet創(chuàng)建一張與原表結(jié)構(gòu)相同的新表table_new。增量遷移修改每日的ETL作業(yè)讓新數(shù)據(jù)同時(shí)寫入舊表TextFile和新表Parquet。可以寫一份數(shù)據(jù)然后通過INSERT ... SELECT復(fù)制到另一張表。歷史數(shù)據(jù)回填編寫一個(gè)后臺(tái)任務(wù)按時(shí)間分區(qū)如按月逐步將舊表的歷史數(shù)據(jù)轉(zhuǎn)換格式后導(dǎo)入新表。使用INSERT OVERWRITE table_new PARTITION (dt) SELECT ... FROM table_old WHERE dt‘...‘。查詢切換在新表數(shù)據(jù)完整且驗(yàn)證無誤后逐步將下游的查詢?nèi)蝿?wù)指向新表。可以先讓一些不重要的報(bào)表或臨時(shí)查詢用新表核心任務(wù)繼續(xù)用舊表。最終切換與清理所有下游任務(wù)切換完畢并穩(wěn)定運(yùn)行一段時(shí)間后可以歸檔或刪除舊表數(shù)據(jù)。5.3 格式相關(guān)報(bào)錯(cuò)與解決思路問題查詢ORC表時(shí)報(bào)錯(cuò)Malformed ORC file或Cannot read due to schema evolution。排查ORC文件可能損壞或者表的Schema定義與文件實(shí)際Schema不兼容比如增加了字段但未使用CASCADE選項(xiàng)。使用hive --orcfiledump檢查文件元數(shù)據(jù)。確保寫入和讀取的Hive版本兼容。問題Spark讀取Hive的ORC表時(shí)某些字段為null。排查檢查Hive和Spark的版本。不同版本間對(duì)ORC復(fù)雜類型如decimal精度、timestamp時(shí)區(qū)的處理可能有細(xì)微差異。盡量保持計(jì)算引擎與Hive Metastore和文件格式版本的匹配。問題向Parquet表插入數(shù)據(jù)時(shí)報(bào)錯(cuò)Unsupported type: VARCHAR(255)。排查Hive中的VARCHAR類型與Parquet的映射可能有問題。在數(shù)倉層除非有明確限制否則建議使用STRING類型兼容性最好。或者在Spark中明確定義Schema時(shí)使用StringType。5.4 一個(gè)真實(shí)的調(diào)優(yōu)案例慢查詢優(yōu)化曾經(jīng)遇到一個(gè)場景一張用戶行為寬表200字段存儲(chǔ)為TextFile一個(gè)簡單的SELECT user_id, COUNT(*) FROM tbl WHERE dt‘xxx‘ AND page_id‘home‘ GROUP BY user_id查詢需要20分鐘。優(yōu)化步驟格式轉(zhuǎn)換將表轉(zhuǎn)換為Parquet格式Snappy壓縮存儲(chǔ)空間從1.2TB下降到180GB。分區(qū)裁剪查詢已包含dt分區(qū)條件這一步已優(yōu)化。謂詞下推page_id列基數(shù)較低在Parquet中有很好的過濾效果。但檢查發(fā)現(xiàn)page_id在文件中無序?qū)е滦薪M級(jí)過濾效果一般。數(shù)據(jù)重組織我們修改了ETL任務(wù)在寫入前按dt, page_id對(duì)數(shù)據(jù)進(jìn)行排序。雖然ETL任務(wù)時(shí)間增加了15%但使得相同page_id的數(shù)據(jù)聚集在更少的行組中。最終效果同樣的查詢時(shí)間從20分鐘下降到45秒。其中格式轉(zhuǎn)換貢獻(xiàn)了主要性能提升減少I/O數(shù)據(jù)排序進(jìn)一步放大了列式存儲(chǔ)索引的優(yōu)勢(shì)。存儲(chǔ)格式的選擇和優(yōu)化是一個(gè)從宏觀架構(gòu)到微觀參數(shù)的系統(tǒng)工程。它沒有銀彈最好的格式就是最適合你當(dāng)前數(shù)據(jù)狀態(tài)和業(yè)務(wù)場景的那一個(gè)。理解其背后的原理掌握關(guān)鍵的調(diào)優(yōu)手段才能讓數(shù)據(jù)真正“存”得高效“取”得飛快。 Hive存儲(chǔ)格式深度解析：從TextFile到ORC/Parquet的性能調(diào)優(yōu)實(shí)戰(zhàn)
1. 項(xiàng)目概述為什么Hive存儲(chǔ)格式是數(shù)據(jù)工程師的必修課剛接觸Hive的時(shí)候很多人覺得建個(gè)表、寫個(gè)SQL把數(shù)據(jù)導(dǎo)進(jìn)去就完事了至于數(shù)據(jù)在底層是怎么存的似乎沒那么重要。直到某天你發(fā)現(xiàn)一個(gè)看似簡單的查詢跑了半個(gè)小時(shí)或者一個(gè)只有幾列的表卻占用了驚人的存儲(chǔ)空間你才會(huì)意識(shí)到數(shù)據(jù)存儲(chǔ)格式的選擇遠(yuǎn)不止是“存進(jìn)去”那么簡單它直接決定了查詢性能、存儲(chǔ)成本和運(yùn)維復(fù)雜度。今天我們就來徹底拆解Hive中那些核心的數(shù)據(jù)存儲(chǔ)格式從最基礎(chǔ)的TextFile到復(fù)雜的ORC、Parquet我會(huì)結(jié)合自己踩過的坑和調(diào)優(yōu)經(jīng)驗(yàn)把它們的原理、選型場景和實(shí)操細(xì)節(jié)講透。無論你是正在搭建數(shù)倉還是優(yōu)化現(xiàn)有作業(yè)理解這些格式都能讓你在數(shù)據(jù)處理的路上少走很多彎路。2. Hive存儲(chǔ)格式核心原理與設(shè)計(jì)思路拆解2.1 存儲(chǔ)格式的本質(zhì)在性能與通用性之間做權(quán)衡Hive本身并不直接存儲(chǔ)數(shù)據(jù)它只是一個(gè)在Hadoop生態(tài)之上的數(shù)據(jù)倉庫工具其數(shù)據(jù)實(shí)際存儲(chǔ)在HDFS這樣的分布式文件系統(tǒng)中。因此Hive的存儲(chǔ)格式本質(zhì)上就是HDFS上文件的組織方式。這個(gè)組織方式的核心矛盾始終圍繞著“寫”和“讀”的效率以及“空間”和“時(shí)間”的交換。寫優(yōu)化 vs. 讀優(yōu)化像TextFile、SequenceFile這類格式寫入時(shí)非常簡單直接幾乎不需要額外的計(jì)算開銷屬于“寫友好”型。但讀取時(shí)尤其是需要過濾某些列或行時(shí)它們往往需要掃描大量無關(guān)數(shù)據(jù)效率低下。而像ORC、Parquet這類列式存儲(chǔ)格式寫入時(shí)需要將行數(shù)據(jù)打散、按列重組、壓縮過程復(fù)雜寫不友好但讀取時(shí)尤其是分析型查詢只涉及少數(shù)幾列時(shí)可以極大地減少I/O屬于“讀友好”型。大數(shù)據(jù)場景下數(shù)據(jù)通常是一次寫入、多次查詢所以犧牲寫入性能換取極致的讀取性能是列式存儲(chǔ)大行其道的根本原因。空間 vs. 時(shí)間壓縮是節(jié)省存儲(chǔ)空間的利器。但壓縮和解壓需要消耗CPU時(shí)間。不同的存儲(chǔ)格式對(duì)壓縮的支持程度不同。TextFile雖然可以壓縮但壓縮后的文件不可分割可能破壞MapReduce的并行度。而ORC、Parquet這類格式其文件內(nèi)部有精密的組織結(jié)構(gòu)如Stripe、Row Group支持在文件內(nèi)部塊級(jí)別進(jìn)行壓縮同時(shí)保持塊的可分割性從而在節(jié)省空間的同時(shí)不損失并行處理能力。序列化與反序列化這是影響CPU開銷的關(guān)鍵。TextFile的每一行文本在計(jì)算時(shí)都需要被解析成對(duì)應(yīng)的數(shù)據(jù)類型如將字符串“123”解析成整數(shù)123這個(gè)解析反序列化開銷巨大。而二進(jìn)制格式如SequenceFile、ORC數(shù)據(jù)以緊湊的二進(jìn)制形式存儲(chǔ)反序列化效率極高。Hive在計(jì)算時(shí)從磁盤讀到內(nèi)存的原始數(shù)據(jù)需要被轉(zhuǎn)換成Java對(duì)象高效的二進(jìn)制序列化框架能大幅降低這個(gè)過程的開銷。2.2 主流格式演進(jìn)脈絡(luò)從“能用”到“高效”理解格式的演進(jìn)能幫你更好地把握其設(shè)計(jì)初衷。早期Hadoop生態(tài)中TextFile是事實(shí)上的標(biāo)準(zhǔn)因?yàn)樗祟惪勺x、通用性強(qiáng)任何文本工具都能處理。但隨著數(shù)據(jù)量激增其性能瓶頸凸顯。SequenceFile作為Hadoop原生的二進(jìn)制格式出現(xiàn)解決了小文件問題和序列化效率但依然是行式存儲(chǔ)對(duì)于分析查詢優(yōu)化有限。真正的轉(zhuǎn)折點(diǎn)來自于對(duì)數(shù)據(jù)分析模式的深刻洞察。傳統(tǒng)的行式存儲(chǔ)適合事務(wù)處理OLTP比如需要獲取某個(gè)用戶的所有信息。而數(shù)據(jù)倉庫的分析查詢OLAP通常是“掃描全表但只關(guān)心少數(shù)幾列”例如“計(jì)算所有用戶的平均年齡”。基于此列式存儲(chǔ)理念被引入RCFileRecord Columnar File是Hive社區(qū)早期的列式存儲(chǔ)嘗試。它將數(shù)據(jù)先按行組Row Group分割在行組內(nèi)再按列存儲(chǔ)并引入了輕量級(jí)索引。RCFile證明了列式存儲(chǔ)在Hive中的巨大潛力但其索引能力較弱壓縮和編碼算法也比較基礎(chǔ)。ORCOptimized Row Columnar和Parquet可以看作是RCFile的“完全體”升級(jí)。它們?cè)赗CFile行組的概念上設(shè)計(jì)了更精細(xì)的數(shù)據(jù)結(jié)構(gòu)ORC的StripeParquet的Row Group內(nèi)置了更強(qiáng)大的索引如布隆過濾器、最小值/最大值索引支持更高效的壓縮編碼如字典編碼、游程編碼并且提供了ACID事務(wù)等高級(jí)特性。可以說ORC和Parquet是為現(xiàn)代大數(shù)據(jù)分析場景量身定制的存儲(chǔ)格式。注意不要孤立地看待某種格式。選擇哪種格式必須緊密結(jié)合你的數(shù)據(jù)特征寬表還是窄表字段類型、訪問模式點(diǎn)查還是全表掃描經(jīng)常過濾哪些字段和計(jì)算引擎Hive MRTezSparkPresto來綜合決策。3. 五大核心存儲(chǔ)格式深度解析與實(shí)操要點(diǎn)3.1 TextFile最原始的雙刃劍TextFile是Hive默認(rèn)的存儲(chǔ)格式。數(shù)據(jù)以純文本形式存儲(chǔ)每行一條記錄字段間通常用特定分隔符如\001、逗號(hào)、制表符分隔。創(chuàng)建表示例CREATE TABLE user_behavior_text ( user_id BIGINT, item_id BIGINT, category_id INT, behavior_type STRING, timestamp BIGINT ) ROW FORMAT DELIMITED FIELDS TERMINATED BY ‘,‘ -- 指定逗號(hào)為字段分隔符 STORED AS TEXTFILE;核心特點(diǎn)與適用場景優(yōu)點(diǎn)人類可讀直接用cat、head命令或文本編輯器查看調(diào)試數(shù)據(jù)極其方便。通用性強(qiáng)任何能處理文本的工具如Shell腳本、Python、Java都可以直接讀寫生態(tài)兼容性最好。寫入簡單數(shù)據(jù)無需復(fù)雜編碼直接寫入適合作為數(shù)據(jù)接入層的原始格式。缺點(diǎn)存儲(chǔ)空間大無任何壓縮數(shù)值、日期等類型也用字符串存儲(chǔ)空間利用率極低。解析開銷大查詢時(shí)需將文本行解析成各個(gè)字段并做類型轉(zhuǎn)換CPU消耗嚴(yán)重。不支持塊壓縮雖然可以對(duì)整個(gè)文件用Gzip、Bzip2壓縮但壓縮后的文件不可分割會(huì)變成單個(gè)Map任務(wù)處理嚴(yán)重拖慢作業(yè)。實(shí)操心得僅用于數(shù)據(jù)接入和交換適合存放從業(yè)務(wù)系統(tǒng)同步過來的最原始日志、CSV文件作為ODS層操作數(shù)據(jù)層的臨時(shí)存儲(chǔ)。避免用于生產(chǎn)分析絕對(duì)不要將TextFile作為數(shù)倉DWD/DWS層的存儲(chǔ)格式性能會(huì)成為災(zāi)難。分隔符選擇優(yōu)先使用不可見字符如\001Ctrl-A、\002Ctrl-B等因?yàn)樗鼈儙缀醪粫?huì)出現(xiàn)在業(yè)務(wù)數(shù)據(jù)中比逗號(hào)、制表符更安全。3.2 SequenceFileHadoop原生的二進(jìn)制容器SequenceFile是Hadoop設(shè)計(jì)的一種用于存儲(chǔ)二進(jìn)制鍵值對(duì)的扁平文件格式。在Hive中通常將整個(gè)行作為值Value而鍵Key可以忽略或存儲(chǔ)行號(hào)。創(chuàng)建表示例CREATE TABLE user_behavior_seq ( user_id BIGINT, item_id BIGINT, category_id INT, behavior_type STRING, timestamp BIGINT ) STORED AS SEQUENCEFILE;核心特點(diǎn)與適用場景優(yōu)點(diǎn)可分割支持塊壓縮Block Compression壓縮后的文件依然可以被多個(gè)Map任務(wù)并行處理。序列化高效以二進(jìn)制存儲(chǔ)省去了TextFile的文本解析開銷。適合小文件可以將大量小文件合并成少量SequenceFile解決HDFS小文件元數(shù)據(jù)壓力過大的問題。缺點(diǎn)非人類可讀二進(jìn)制格式無法直接查看內(nèi)容。依然是行式存儲(chǔ)查詢時(shí)仍需讀取整行數(shù)據(jù)對(duì)于分析型查詢優(yōu)化有限。Hive生態(tài)外支持弱相比TextFile其他非Hadoop生態(tài)工具處理起來較麻煩。實(shí)操心得小文件合并利器在數(shù)據(jù)采集階段如Flume可以配置Sink將數(shù)據(jù)寫入SequenceFile避免產(chǎn)生海量小TextFile。中間格式過渡在某些ETL流水線中可以作為中間步驟的存儲(chǔ)格式比TextFile高效又比ORC/Parquet寫入快。壓縮配置建表時(shí)可以指定壓縮算法如SET hive.exec.compress.outputtrue; SET mapred.output.compression.codecorg.apache.hadoop.io.compress.SnappyCodec;推薦使用Snappy在壓縮比和速度間取得平衡。3.3 RCFile列式存儲(chǔ)的先行者RCFile的設(shè)計(jì)理念是“先按行組分再按列存”。它先將數(shù)據(jù)劃分成多個(gè)行組Row Group在每個(gè)行組內(nèi)數(shù)據(jù)按列存儲(chǔ)在一起并對(duì)每列進(jìn)行壓縮。核心特點(diǎn)與適用場景優(yōu)點(diǎn)列式存儲(chǔ)優(yōu)勢(shì)在只查詢少數(shù)列時(shí)可以跳過其他列的數(shù)據(jù)減少I/O。可分割行組是數(shù)據(jù)分割和并行處理的基本單位。輕量級(jí)索引行組頭部存儲(chǔ)了每列的行數(shù)、壓縮大小等信息并提供每列在行組內(nèi)的偏移量便于快速定位。缺點(diǎn)索引能力弱只有基本的行組級(jí)統(tǒng)計(jì)信息沒有列級(jí)的細(xì)粒度索引如最小值/最大值。寫入性能差需要緩存整個(gè)行組的數(shù)據(jù)才能按列壓縮寫入內(nèi)存消耗較大。已逐漸被淘汰ORC在各方面都優(yōu)于RCFile目前新項(xiàng)目已很少使用RCFile。實(shí)操要點(diǎn)歷史遺產(chǎn)如果你維護(hù)的老系統(tǒng)還在用RCFile了解其原理有助于遷移或優(yōu)化。但在新項(xiàng)目中應(yīng)直接選擇ORC或Parquet。理解行組大小通過參數(shù)hive.io.rcfile.record.buffer.size可以設(shè)置行組緩沖區(qū)大小影響寫入性能和查詢時(shí)的I/O粒度。3.4 ORCHive親生的高性能列式格式ORC是Hive社區(qū)專為Hive設(shè)計(jì)的高性能列式存儲(chǔ)格式可以理解為RCFile的全面優(yōu)化版。它的文件結(jié)構(gòu)非常精巧。一個(gè)ORC文件由以下幾部分組成文件腳注Footer包含文件的元數(shù)據(jù)如模式Schema、行數(shù)、每個(gè)Strip的信息。條帶StripeORC文件的水平分割單元相當(dāng)于RCFile的行組升級(jí)版。通常大小建議為256MB。索引數(shù)據(jù)Index Data存儲(chǔ)Stripe內(nèi)每列的最小值、最大值、行索引以及布隆過濾器可選。這是ORC查詢快的核心使得查詢引擎可以快速跳過不滿足條件的整個(gè)Stripe。行數(shù)據(jù)Row Data按列存儲(chǔ)的實(shí)際數(shù)據(jù)每列獨(dú)立壓縮編碼。條帶腳注Stripe Footer存儲(chǔ)Stripe內(nèi)數(shù)據(jù)流的目錄信息。Postscript文件末尾記錄文件壓縮參數(shù)、版本等信息。創(chuàng)建表與高級(jí)參數(shù)示例CREATE TABLE user_behavior_orc ( user_id BIGINT, item_id BIGINT, category_id INT, behavior_type STRING, timestamp BIGINT ) STORED AS ORC TBLPROPERTIES ( ‘orc.compress‘‘SNAPPY‘, -- 壓縮算法可選NONE, ZLIB, SNAPPY ‘orc.stripe.size‘‘268435456‘, -- Stripe大小256MB ‘orc.row.index.stride‘‘10000‘, -- 索引粒度每10000行建一個(gè)索引項(xiàng) ‘orc.create.index‘‘true‘, -- 創(chuàng)建行索引 ‘orc.bloom.filter.columns‘‘user_id,behavior_type‘ -- 為指定列創(chuàng)建布隆過濾器 );核心優(yōu)勢(shì)與實(shí)操心得索引能力超強(qiáng)基于最小值/最大值索引的謂詞下推是ORC的王牌功能。例如查詢WHERE user_id 100000Hive可以直接根據(jù)每個(gè)Stripe的user_id列索引跳過所有max(user_id) 100000的Stripe極大減少數(shù)據(jù)掃描量。布隆過濾器對(duì)等值查詢?nèi)鏦HERE behavior_type‘buy‘過濾效果極佳。壓縮編碼高效針對(duì)不同數(shù)據(jù)類型采用特定編碼。整數(shù)類型采用行程長度編碼Run-Length Encoding, RLE和差值編碼Delta Encoding對(duì)于連續(xù)重復(fù)或遞增的值壓縮比驚人。字符串類型采用字典編碼Dictionary Encoding將重復(fù)的字符串值用數(shù)字ID代替對(duì)于低基數(shù)列如gender,city效果顯著。ACID事務(wù)支持從Hive 0.14開始ORC格式的表支持完整的ACID事務(wù)允許INSERT、UPDATE、DELETE這對(duì)于需要數(shù)據(jù)更新的場景至關(guān)重要。向量化查詢ORC格式完美支持Hive的向量化查詢引擎hive.vectorized.execution.enabledtrue。該引擎一次處理一批數(shù)據(jù)一個(gè)向量而不是一行充分利用現(xiàn)代CPU的SIMD指令將性能提升數(shù)倍甚至數(shù)十倍。重要提示要發(fā)揮ORC索引的優(yōu)勢(shì)必須對(duì)常作為查詢條件的列進(jìn)行排序。例如如果查詢總是按dt日期分區(qū)并按user_id過濾那么在插入數(shù)據(jù)時(shí)應(yīng)確保數(shù)據(jù)在每個(gè)分區(qū)內(nèi)按user_id有序。無序的數(shù)據(jù)會(huì)使索引的最小值/最大值范圍變得很寬失去過濾意義。可以通過INSERT ... SELECT ... ORDER BY或在計(jì)算引擎如Spark中寫入前重分區(qū)排序來實(shí)現(xiàn)。3.5 Parquet跨平臺(tái)的標(biāo)準(zhǔn)列式格式Parquet的設(shè)計(jì)理念與ORC類似但它的目標(biāo)是成為Hadoop生態(tài)系統(tǒng)中通用的列式存儲(chǔ)格式由Apache頂級(jí)項(xiàng)目支持不與任何計(jì)算引擎綁定。Parquet文件核心結(jié)構(gòu)行組Row Group邏輯上的水平分割包含一批行類似ORC的Stripe。列塊Column Chunk行組中每一列的數(shù)據(jù)。一個(gè)行組中有多少個(gè)列就有多少個(gè)列塊。頁P(yáng)age列塊被進(jìn)一步劃分為頁頁是壓縮、編碼和讀寫的最小單元。包含數(shù)據(jù)頁和字典頁等。頁頭存儲(chǔ)頁的元數(shù)據(jù)如編碼、壓縮后大小、未壓縮大小等。創(chuàng)建表示例CREATE TABLE user_behavior_parquet ( user_id BIGINT, item_id BIGINT, category_id INT, behavior_type STRING, timestamp BIGINT ) STORED AS PARQUET TBLPROPERTIES ( ‘parquet.compression‘‘SNAPPY‘, ‘parquet.block.size‘‘268435456‘ -- 行組大小256MB );核心優(yōu)勢(shì)與選型考量跨平臺(tái)原生支持這是Parquet最大的優(yōu)勢(shì)。Spark、Flink、Presto、Impala等主流計(jì)算引擎都對(duì)Parquet提供了原生Native支持讀寫性能最優(yōu)。而它們對(duì)ORC的支持可能通過Hive兼容層實(shí)現(xiàn)性能有時(shí)不如Parquet。嵌套數(shù)據(jù)模型支持出色Parquet原生支持復(fù)雜的嵌套數(shù)據(jù)結(jié)構(gòu)如struct,array,map其schema定義采用Dremel論文中的重復(fù)與定義級(jí)別非常高效。如果你的數(shù)據(jù)是半結(jié)構(gòu)化的JSON或Avro格式轉(zhuǎn)換為Parquet后能獲得很好的查詢性能和壓縮比。廣泛的生態(tài)工具大量數(shù)據(jù)工具如AWS Athena、Google BigQuery、Pandas都能直接讀取Parquet文件。ORC vs. Parquet 如何選擇這是一個(gè)常見問題。我的經(jīng)驗(yàn)是如果你的技術(shù)棧以Hive為核心且需要用到Hive特有的高級(jí)功能如ACID事務(wù)、復(fù)雜的物化視圖或者你的查詢模式能很好地利用排序索引ORC是更優(yōu)選擇。如果你的技術(shù)棧是混合的例如同時(shí)使用Hive、Spark、Presto或者未來有遷移到其他引擎的可能Parquet是更安全、更通用的選擇。如果你的數(shù)據(jù)是高度嵌套的如事件日志、JSON文檔Parquet對(duì)嵌套結(jié)構(gòu)的支持更成熟。從純性能角度看兩者在多數(shù)場景下相差無幾。ORC在Hive上的謂詞下推可能略強(qiáng)Parquet在Spark上的掃描性能可能略優(yōu)。真正的性能差異往往來自于數(shù)據(jù)布局如分區(qū)、排序和查詢寫法而非格式本身。4. 存儲(chǔ)格式實(shí)戰(zhàn)從選型到調(diào)優(yōu)全流程4.1 新項(xiàng)目存儲(chǔ)格式選型決策流程面對(duì)一個(gè)新項(xiàng)目我通常會(huì)遵循以下流程來選擇存儲(chǔ)格式分析數(shù)據(jù)特征與訪問模式數(shù)據(jù)量級(jí)TB級(jí)以下格式選擇影響不大PB級(jí)必須使用列式存儲(chǔ)。表寬度字段數(shù)超過30個(gè)的寬表列式存儲(chǔ)的I/O優(yōu)勢(shì)極其明顯。查詢模式列出高頻查詢語句。是否總是SELECT少數(shù)幾列WHERE條件是否集中在某幾列是否有ORDER BY或GROUP BY數(shù)據(jù)更新需求是否需要UPDATE/DELETE如果需要ORC開啟ACID或Hudi/Delta Lake基于Parquet/ORC是候選。評(píng)估技術(shù)棧與團(tuán)隊(duì)技能團(tuán)隊(duì)主要使用Hive還是Spark未來技術(shù)路線圖如何團(tuán)隊(duì)成員對(duì)哪種格式更熟悉運(yùn)維工具鏈?zhǔn)欠裰С謭?zhí)行概念驗(yàn)證抽取一份樣本數(shù)據(jù)如最近一周分別用ORC和Parquet格式建表。運(yùn)行典型的高頻查詢對(duì)比執(zhí)行時(shí)間和資源消耗。檢查文件大小對(duì)比壓縮比。制定規(guī)范并落地將選型結(jié)果寫入團(tuán)隊(duì)的數(shù)據(jù)開發(fā)規(guī)范。在數(shù)倉各層明確格式要求例如ODS層可用TextFile/SequenceFileDWD/DWS層統(tǒng)一使用Parquet。4.2 建表與數(shù)據(jù)寫入最佳實(shí)踐選好格式后建表和寫入數(shù)據(jù)是下一個(gè)關(guān)鍵步驟。分區(qū)與分桶 存儲(chǔ)格式解決的是文件內(nèi)部的效率問題而分區(qū)和分桶解決的是文件組織的問題兩者結(jié)合才能發(fā)揮最大效力。-- 分區(qū)表示例按日期分區(qū)是標(biāo)配 CREATE TABLE dwd_user_behavior_parquet ( user_id BIGINT, item_id BIGINT, category_id INT, behavior_type STRING ) PARTITIONED BY (dt STRING) -- 按天分區(qū) STORED AS PARQUET TBLPROPERTIES (‘parquet.compression‘‘SNAPPY‘); -- 分桶表示例對(duì)常做JOIN鍵或GROUP BY鍵的列分桶 CREATE TABLE dws_user_behavior_bucketed ( user_id BIGINT, buy_count INT, ... ) CLUSTERED BY (user_id) INTO 32 BUCKETS -- 按user_id哈希分桶 STORED AS ORC;分區(qū)將數(shù)據(jù)按某個(gè)字段通常是日期分布到不同目錄。查詢時(shí)通過WHERE dt‘2023-10-01‘可以分區(qū)裁剪直接跳過無關(guān)分區(qū)目錄。分桶將數(shù)據(jù)按某個(gè)字段的哈希值分散到固定數(shù)量的文件中。對(duì)于大表JOIN或大表GROUP BY能轉(zhuǎn)化為桶對(duì)桶的高效操作避免Shuffle。數(shù)據(jù)有序?qū)懭?如前所述對(duì)于ORC/Parquet有序的數(shù)據(jù)能極大提升索引效率。在Spark中寫入時(shí)可以這樣做df.repartition(1).sortWithinPartitions(“user_id”) // 先合并成一個(gè)分區(qū)再排序適用于小文件合并場景 .write.mode(“append”) .partitionBy(“dt”) .format(“parquet”) .saveAsTable(“dwd_table”)或者使用Hive的DISTRIBUTE BY和SORT BYINSERT OVERWRITE TABLE dwd_table PARTITION (dt) SELECT * FROM source_table DISTRIBUTE BY dt, FLOOR(user_id / 10000) -- 保證相同范圍的數(shù)據(jù)進(jìn)入同一個(gè)Reducer SORT BY dt, user_id; -- 在Reducer內(nèi)排序4.3 性能調(diào)優(yōu)關(guān)鍵參數(shù)實(shí)戰(zhàn)不同的格式有其關(guān)鍵的調(diào)優(yōu)旋鈕這里列舉一些最實(shí)用的ORC調(diào)優(yōu)參數(shù)orc.stripe.size默認(rèn)256MB。增大此值如512MB可以提高壓縮比和順序I/O效率但會(huì)消耗更多內(nèi)存。對(duì)于超大規(guī)模表可以適當(dāng)調(diào)大。orc.row.index.stride默認(rèn)10000行。索引條目間隔。減小此值會(huì)創(chuàng)建更密集的索引加快點(diǎn)查但增加存儲(chǔ)開銷。對(duì)于經(jīng)常按主鍵查詢的表可以設(shè)為5000。orc.bloom.filter.columns和orc.bloom.filter.fpp為高基數(shù)的等值過濾列如user_id創(chuàng)建布隆過濾器并設(shè)置誤報(bào)率默認(rèn)0.05。能高效過濾掉不滿足條件的Stripe。hive.vectorized.execution.enabledtrue務(wù)必開啟向量化查詢。對(duì)于ORC格式還需要設(shè)置hive.vectorized.execution.enabledtrue。Parquet調(diào)優(yōu)參數(shù)parquet.block.size默認(rèn)128MB。相當(dāng)于行組大小。建議設(shè)置為256MB或512MB與HDFS塊大小對(duì)齊如128MB的倍數(shù)以獲得更好的并行度。parquet.page.size默認(rèn)1MB。頁是編碼和壓縮的最小單元。對(duì)于有很多小字段的表可以適當(dāng)減小頁大小以提高隨機(jī)訪問性能對(duì)于大字段如長文本可以增大頁大小。parquet.dictionary.page.size默認(rèn)1MB。字典頁大小。對(duì)于低基數(shù)列確保字典頁足夠容納所有唯一值否則會(huì)退回到明文編碼。通用壓縮算法選擇Snappy默認(rèn)推薦。壓縮和解壓速度極快壓縮比中等。追求查詢性能時(shí)的首選。Zlib/Gzip壓縮比高但壓縮和解壓速度慢。適合對(duì)存儲(chǔ)成本極其敏感、且數(shù)據(jù)冷熱分明冷數(shù)據(jù)很少被查詢的場景。LZO需要單獨(dú)安裝編解碼器。速度與Snappy相當(dāng)壓縮比略好但生態(tài)支持不如Snappy廣泛。5. 常見問題排查與實(shí)戰(zhàn)技巧實(shí)錄5.1 查詢性能不及預(yù)期先檢查這些點(diǎn)即使使用了ORC/Parquet查詢也可能很慢。別急著怪格式按以下順序排查是否觸發(fā)了分區(qū)裁剪檢查執(zhí)行計(jì)劃EXPLAIN命令確認(rèn)你的WHERE條件中的分區(qū)字段是常量而不是函數(shù)計(jì)算如WHERE dt ‘20231001‘有效WHERE substr(dt,1,6)‘202310‘可能無效。謂詞下推是否生效對(duì)于ORC/Parquet在WHERE中對(duì)有索引的列進(jìn)行過濾應(yīng)該能在執(zhí)行計(jì)劃的TableScan階段就看到過濾條件。如果沒有檢查數(shù)據(jù)類型是否一致避免隱式轉(zhuǎn)換或者嘗試使用CAST函數(shù)。數(shù)據(jù)是否有序檢查用于過濾的列如user_id在文件內(nèi)是否大致有序。可以抽樣查看文件頭部的統(tǒng)計(jì)信息Hive命令hive --orcfiledump /path/to/file.orc如果某個(gè)列的min和max值相差巨大且覆蓋了整個(gè)范圍說明數(shù)據(jù)無序索引失效。小文件問題如果表目錄下有成千上萬個(gè)小文件比如每個(gè)只有幾MB那么啟動(dòng)Map任務(wù)的開銷將遠(yuǎn)超實(shí)際計(jì)算開銷。解決方案使用INSERT OVERWRITE語句重寫表或者使用計(jì)算引擎如Spark的coalesce或repartition功能合并小文件后再寫入。壓縮算法是否合適如果查詢CPU瓶頸明顯而I/O不是問題可以嘗試將壓縮算法從Zlib切換到Snappy甚至不壓縮NONE用空間換時(shí)間。5.2 從TextFile遷移到列式存儲(chǔ)的平滑方案遷移歷史數(shù)據(jù)是個(gè)大工程切忌一次性全量重寫。我的建議是采用雙軌并行、逐步切換的策略創(chuàng)建新表使用目標(biāo)格式如Parquet創(chuàng)建一張與原表結(jié)構(gòu)相同的新表table_new。增量遷移修改每日的ETL作業(yè)讓新數(shù)據(jù)同時(shí)寫入舊表TextFile和新表Parquet。可以寫一份數(shù)據(jù)然后通過INSERT ... SELECT復(fù)制到另一張表。歷史數(shù)據(jù)回填編寫一個(gè)后臺(tái)任務(wù)按時(shí)間分區(qū)如按月逐步將舊表的歷史數(shù)據(jù)轉(zhuǎn)換格式后導(dǎo)入新表。使用INSERT OVERWRITE table_new PARTITION (dt) SELECT ... FROM table_old WHERE dt‘...‘。查詢切換在新表數(shù)據(jù)完整且驗(yàn)證無誤后逐步將下游的查詢?nèi)蝿?wù)指向新表。可以先讓一些不重要的報(bào)表或臨時(shí)查詢用新表核心任務(wù)繼續(xù)用舊表。最終切換與清理所有下游任務(wù)切換完畢并穩(wěn)定運(yùn)行一段時(shí)間后可以歸檔或刪除舊表數(shù)據(jù)。5.3 格式相關(guān)報(bào)錯(cuò)與解決思路問題查詢ORC表時(shí)報(bào)錯(cuò)Malformed ORC file或Cannot read due to schema evolution。排查ORC文件可能損壞或者表的Schema定義與文件實(shí)際Schema不兼容比如增加了字段但未使用CASCADE選項(xiàng)。使用hive --orcfiledump檢查文件元數(shù)據(jù)。確保寫入和讀取的Hive版本兼容。問題Spark讀取Hive的ORC表時(shí)某些字段為null。排查檢查Hive和Spark的版本。不同版本間對(duì)ORC復(fù)雜類型如decimal精度、timestamp時(shí)區(qū)的處理可能有細(xì)微差異。盡量保持計(jì)算引擎與Hive Metastore和文件格式版本的匹配。問題向Parquet表插入數(shù)據(jù)時(shí)報(bào)錯(cuò)Unsupported type: VARCHAR(255)。排查Hive中的VARCHAR類型與Parquet的映射可能有問題。在數(shù)倉層除非有明確限制否則建議使用STRING類型兼容性最好。或者在Spark中明確定義Schema時(shí)使用StringType。5.4 一個(gè)真實(shí)的調(diào)優(yōu)案例慢查詢優(yōu)化曾經(jīng)遇到一個(gè)場景一張用戶行為寬表200字段存儲(chǔ)為TextFile一個(gè)簡單的SELECT user_id, COUNT(*) FROM tbl WHERE dt‘xxx‘ AND page_id‘home‘ GROUP BY user_id查詢需要20分鐘。優(yōu)化步驟格式轉(zhuǎn)換將表轉(zhuǎn)換為Parquet格式Snappy壓縮存儲(chǔ)空間從1.2TB下降到180GB。分區(qū)裁剪查詢已包含dt分區(qū)條件這一步已優(yōu)化。謂詞下推page_id列基數(shù)較低在Parquet中有很好的過濾效果。但檢查發(fā)現(xiàn)page_id在文件中無序?qū)е滦薪M級(jí)過濾效果一般。數(shù)據(jù)重組織我們修改了ETL任務(wù)在寫入前按dt, page_id對(duì)數(shù)據(jù)進(jìn)行排序。雖然ETL任務(wù)時(shí)間增加了15%但使得相同page_id的數(shù)據(jù)聚集在更少的行組中。最終效果同樣的查詢時(shí)間從20分鐘下降到45秒。其中格式轉(zhuǎn)換貢獻(xiàn)了主要性能提升減少I/O數(shù)據(jù)排序進(jìn)一步放大了列式存儲(chǔ)索引的優(yōu)勢(shì)。存儲(chǔ)格式的選擇和優(yōu)化是一個(gè)從宏觀架構(gòu)到微觀參數(shù)的系統(tǒng)工程。它沒有銀彈最好的格式就是最適合你當(dāng)前數(shù)據(jù)狀態(tài)和業(yè)務(wù)場景的那一個(gè)。理解其背后的原理掌握關(guān)鍵的調(diào)優(yōu)手段才能讓數(shù)據(jù)真正“存”得高效“取”得飛快。