也是知識(shí)崎脉，要了解

URL：
https://zhuanlan.zhihu.com/p/459444652

為什么我們需要不同的文件格式伯顶？

對(duì)于 MapReduce 和 Spark 等支持 HDFS 的應(yīng)用程序來(lái)說(shuō)呛踊，一個(gè)巨大的瓶頸是在特定位置查找相關(guān)數(shù)據(jù)所需的時(shí)間以及將數(shù)據(jù)寫回另一個(gè)位置所需的時(shí)間啦撮。這些問(wèn)題隨著管理大型數(shù)據(jù)集的困難而變得復(fù)雜，例如不斷發(fā)展的模式或存儲(chǔ)限制愉择。

在處理大數(shù)據(jù)時(shí)锥涕，存儲(chǔ)此類數(shù)據(jù)所需的成本更高（Hadoop 冗余存儲(chǔ)數(shù)據(jù)以實(shí)現(xiàn)容錯(cuò)）狭吼。除了存儲(chǔ)成本之外，處理數(shù)據(jù)還伴隨著 CPU刁笙、網(wǎng)絡(luò)破花、IO 成本等疲吸。隨著數(shù)據(jù)的增加，處理和存儲(chǔ)的成本也隨之增加摘悴。

各種 Hadoop 文件格式在 數(shù)據(jù)工程解決方案中得到了發(fā)展峭梳，以緩解許多用例中的這些問(wèn)題蹂喻。

選擇合適的文件格式可以帶來(lái)一些顯著的好處：

1. 更快的讀取時(shí)間
2. 更快的寫入時(shí)間
3. 可拆分文件
4. 模式演變支持
5. 高級(jí)壓縮支持

一些文件格式是為一般用途而設(shè)計(jì)的葱椭，另一些是為更具體的用例而設(shè)計(jì)的，還有一些是為特定數(shù)據(jù)特征而設(shè)計(jì)的口四。所以有相當(dāng)多的選擇孵运。

Avro 文件格式

[圖片上傳失敗...(image-1ec66-1649317507854)]

Avro 格式是 Hadoop 的一種基于行的存儲(chǔ)格式窃祝，被廣泛用作序列化平臺(tái)粪小。

Avro 格式以 JSON 格式存儲(chǔ)模式探膊，使其易于被任何程序讀取和解釋逞壁。

數(shù)據(jù)本身以二進(jìn)制格式存儲(chǔ)，使其在 Avro 文件中緊湊且高效。

vro格式是語(yǔ)言中立的數(shù)據(jù)序列化系統(tǒng)姿骏。它可以被多種語(yǔ)言處理（目前是 C糖声、C++、C#分瘦、Java蘸泻、Python 和 Ruby）。

Avro 格式的一個(gè)關(guān)鍵特性 是對(duì)隨時(shí)間變化的數(shù)據(jù)模式的強(qiáng)大支持嘲玫，即模式演變悦施。Avro 處理模式更改，例如缺少字段去团、添加的字段和更改的字段抡诞。

Avro 格式提供了豐富的數(shù)據(jù)結(jié)構(gòu)。例如土陪，您可以創(chuàng)建包含數(shù)組沐绒、枚舉類型和子記錄的記錄。

[圖片上傳失敗...(image-aa93b7-1649317507854)]

Avro 格式是在數(shù)據(jù)湖登陸區(qū)存儲(chǔ)數(shù)據(jù)的理想選擇旺坠，因?yàn)椋?/p>

1.落地區(qū)的數(shù)據(jù)通常被整體讀取乔遮，以供下游系統(tǒng)進(jìn)一步處理（這種情況下基于行的格式效率更高）。

2. 下游系統(tǒng)可以輕松地從 Avro 文件中檢索表模式（無(wú)需將模式單獨(dú)存儲(chǔ)在外部元存儲(chǔ)中）取刃。

3. 任何源模式更改都很容易處理（模式演變）蹋肮。

列式存儲(chǔ)格式

為了更好地理解 Hadoop 中的 Parquet 和ORC 文件格式，首先我們來(lái)看看什么是列式存儲(chǔ)格式璧疗。在面向列的格式中坯辩，記錄中相同類型的每一列的值存儲(chǔ)在一起。

例如 崩侠，如果有一條記錄包含 ID漆魔、員工姓名和部門，則 ID 列的所有值將存儲(chǔ)在一起却音，Name 列的值將存儲(chǔ)在一起改抡，等等。如果我們采用與上述相同的記錄模式系瓢，具有三個(gè)字段 ID (int)阿纤、NAME (varchar) 和 Department (varchar)，則該表將如下所示：

[圖片上傳失敗...(image-c1bf62-1649317507854)]

<figcaption style="margin-top: calc(0.666667em); padding: 0px 1em; font-size: 0.9em; line-height: 1.5; text-align: center; color: rgb(153, 153, 153);">添加圖片注釋夷陋，不超過(guò) 140 字（可選）</figcaption>

對(duì)于此表欠拾，按行存儲(chǔ)格式的數(shù)據(jù)將按如下方式存儲(chǔ)：

[圖片上傳失敗...(image-b537ba-1649317507854)]

<figcaption style="margin-top: calc(0.666667em); padding: 0px 1em; font-size: 0.9em; line-height: 1.5; text-align: center; color: rgb(153, 153, 153);">添加圖片注釋胰锌，不超過(guò) 140 字（可選）</figcaption>

然而，面向列的存儲(chǔ)格式中的相同數(shù)據(jù)將如下所示：

[圖片上傳失敗...(image-7a4f5d-1649317507854)]

<figcaption style="margin-top: calc(0.666667em); padding: 0px 1em; font-size: 0.9em; line-height: 1.5; text-align: center; color: rgb(153, 153, 153);">添加圖片注釋藐窄，不超過(guò) 140 字（可選）</figcaption>

當(dāng)您需要從表中查詢幾列時(shí)资昧，列式存儲(chǔ)格式更有效。它將只讀取所需的列荆忍，因?yàn)樗鼈兪窍噜彽拈簧Γ瑥亩钚』?IO。

例如东揣，假設(shè)您只需要 NAME列践惑。 在行存儲(chǔ)格式中，必須加載數(shù)據(jù)集中的每條記錄嘶卧，將其解析為字段尔觉，并提取名稱的數(shù)據(jù)。面向列的格式可以直接轉(zhuǎn)到 Name 列芥吟，因?yàn)樵摿械乃兄刀即鎯?chǔ)在一起侦铜。它不需要遍歷整個(gè)記錄。

因此钟鸵，面向列的格式提高了查詢性能钉稍，因?yàn)檗D(zhuǎn)到所需列所需的查找時(shí)間更少，并且由于只需要讀取需要數(shù)據(jù)的列棺耍，因此需要更少的 IO贡未。

Parquet文件格式

[圖片上傳失敗...(image-a510fc-1649317507854)]

Parquet 是 Hadoop 的一種開(kāi)源文件格式，以扁平列格式存儲(chǔ)嵌套數(shù)據(jù)結(jié)構(gòu)蒙袍。

Parquet文件格式優(yōu)點(diǎn)

• 與以行方式存儲(chǔ)數(shù)據(jù)的傳統(tǒng)方法相比俊卤，Parquet文件格式在存儲(chǔ)和性能方面更高效。
• 這對(duì)于從“寬”（具有許多列）表中讀取特定列的查詢特別有用害幅，因?yàn)橹蛔x取需要的列消恍，并且最小化 IO。
• Parquet的獨(dú)特功能之一是它也可以以柱狀方式存儲(chǔ)具有嵌套結(jié)構(gòu)的數(shù)據(jù)以现。這意味著在 Parquet 文件格式中狠怨，即使是嵌套字段也可以單獨(dú)讀取，而無(wú)需讀取嵌套結(jié)構(gòu)中的所有字段邑遏。Parquet 格式使用記錄分解和組裝算法以柱狀方式存儲(chǔ)嵌套結(jié)構(gòu)佣赖。

[圖片上傳失敗...(image-c3759b-1649317507853)]

Parquet 文件格式結(jié)構(gòu)組成

[圖片上傳失敗...(image-41c9ac-1649317507854)]

• Header： 包含一個(gè)幻數(shù)“PAR1”（4 字節(jié)），用于將文件標(biāo)識(shí)為 Parquet 格式文件无宿。

• Row group（行組）：將數(shù)據(jù)邏輯水平劃分為行茵汰。行組由數(shù)據(jù)集中每一列的列塊組成枢里。

• Column chunk（列塊）：特定列的數(shù)據(jù)塊孽鸡。這些列塊存在于特定的行組中蹂午，并保證在文件中是連續(xù)的。

• Page（頁(yè)面）：列塊被分成背靠背寫的頁(yè)面彬碱。這些頁(yè)面共享一個(gè)標(biāo)準(zhǔn)標(biāo)題豆胸，讀者可以跳過(guò)他們不感興趣的頁(yè)面。

• Footer（頁(yè)腳）：

• 文件元數(shù)據(jù)- 文件元數(shù)據(jù)包含所有列元數(shù)據(jù)起始位置的位置巷疼。它還包括格式版本晚胡、架構(gòu)和任何額外的鍵值對(duì)。讀者應(yīng)該首先讀取文件元數(shù)據(jù)以找到他們感興趣的所有列塊嚼沿。然后應(yīng)該順序讀取列塊估盘。

• 文件元數(shù)據(jù)的長(zhǎng)度（4 字節(jié)）

• 幻數(shù)“PAR1”（4 字節(jié)）

ORC 文件格式

[圖片上傳失敗...(image-f37441-1649317507854)]

優(yōu)化行列式 ( ORC ) 文件格式提供了一種高效的數(shù)據(jù)存儲(chǔ)方式。 它旨在克服其他文件格式的限制骡尽。ORC 文件格式理想地存儲(chǔ)緊湊的數(shù)據(jù)遣妥，并允許跳過(guò)不相關(guān)的部分，而無(wú)需大型攀细、復(fù)雜或手動(dòng)維護(hù)的索引箫踩。ORC 文件格式解決了所有這些問(wèn)題。

ORC 文件格式優(yōu)點(diǎn)

• 單個(gè)文件作為每個(gè)任務(wù)的輸出谭贪，減少 NameNode 的負(fù)載
• Hive 類型支持境钟，包括 DateTime、decimal 和復(fù)雜類型（結(jié)構(gòu)俭识、列表慨削、映射和聯(lián)合）
• 使用單獨(dú)的 RecordReader 并發(fā)讀取同一文件
• ORC 文件格式能夠在不掃描標(biāo)記的情況下拆分文件
• 根據(jù)文件頁(yè)腳中的信息估計(jì) Reader/Writer 的堆內(nèi)存分配上限
• 使用協(xié)議緩沖區(qū)存儲(chǔ)的元數(shù)據(jù)，允許添加和刪除字段

[圖片上傳失敗...(image-a34fff-1649317507854)]

ORC 文件格式將行集合存儲(chǔ)在一個(gè)文件中套媚，并且在集合中理盆，行數(shù)據(jù)以列格式存儲(chǔ)。

ORC 文件包含稱為stripe的行數(shù)據(jù)組和File footer（文件頁(yè)腳）中的輔助信息 凑阶。默認(rèn)stripe大小為 250 MB猿规。大stripe大小支持從 HDFS 進(jìn)行大量、高效的讀取宙橱。

ORC 文件格式結(jié)構(gòu)組成

• **Index data（索引數(shù)據(jù)）： **包括每列的最小值和最大值以及行在每列中的位置姨俩。ORC 索引僅用于stripe和行組的選擇，而不用于回答查詢师郑。

• Row data（行數(shù)據(jù)）：用于表掃描环葵。

• stripe footer（頁(yè)腳）：包含流位置的目錄。它還包含列級(jí)聚合計(jì)數(shù)宝冕、最小值张遭、最大值和總和。

• File footer（文件頁(yè)腳）：

• 文件中的stripe列表地梨。

• 每個(gè)stripe的行數(shù)菊卷。

• 每列的數(shù)據(jù)類型缔恳。

• Postscript：附有壓縮參數(shù)和壓縮頁(yè)腳的大小，在文件的末尾洁闰。

不同文件格式之間的比較

Avro 與 Parquet

1. Avro是一種基于行的存儲(chǔ)格式歉甚，而 Parquet是一種基于列的存儲(chǔ)格式。
2. Parquet 對(duì)于分析查詢要好得多扑眉，即讀取和查詢比寫入效率高得多纸泄。
3. Avro中的編寫操作比Parquet 中的要好。
4. 在模式演變方面腰素，Avro比 PARQUET 成熟得多聘裁。Parquet 僅支持模式追加，而 Avro支持功能強(qiáng)大的模式演變弓千，即添加或修改列咧虎。
5. PARQUET 非常適合查詢多列表中的列子集。Avro是 ETL 操作的理想選擇计呈，我們需要查詢所有列砰诵。

ORC 與 Parquet

1. Parquet更能存儲(chǔ)嵌套數(shù)據(jù)。
2. ORC 更有能力進(jìn)行謂詞下推捌显。
3. ORC 支持 ACID 屬性茁彭。
4. ORC 的壓縮效率更高。