大資料檔案格式

什麼是檔案格式？ 常見的Hadoop檔案格式功能是什麼？ 您應該使用哪種格式？

在此部落格中，我將討論實際的檔案格式，介紹一些常見的Hadoop檔案格式功能，並就應該使用哪種格式提供一些建議。 您還可以在此處閱讀其他一些有趣的案例研究，以瞭解如何使用Hadoop託管服務處理不同的大資料檔案格式。

為什麼我們需要不同的檔案格式？

對於支援HDFS的應用程式（如MapReduce和Spark）而言，一個巨大的瓶頸是在特定位置查詢相關資料所花費的時間以及將資料寫回到另一個位置所花費的時間。 這些問題因管理大型資料集（例如，不斷髮展的模式或儲存約束）的困難而變得複雜。

當我們處理大資料時，儲存此類資料所需的成本更高（Hadoop冗餘儲存資料以實現容錯能力）。 除儲存成本外，處理資料還包括CPU，網路，IO成本等。隨著資料的增加，處理和儲存的成本也隨之增加。

各種Hadoop檔案格式已得到發展，可以緩解許多用例中的這些問題。

選擇適當的檔案格式可能會帶來一些明顯的好處：

· 讀取時間更快

· 更快的寫入時間

· 可拆分檔案

· 模式演進支援

· 先進的壓縮支援

一些檔案格式是為一般使用而設計的，其他檔案格式是為更具體的用例設計的，而某些檔案格式則考慮了特定的資料特徵。 因此，確實有很多選擇。

AVRO檔案格式

Avro是Hadoop的基於行的儲存格式，已廣泛用作序列化平臺。

Avro將模式儲存為JSON格式，使任何程式均可輕鬆讀取和解釋。

資料本身以二進位制格式儲存，從而使其緊湊高效。

Avro是與語言無關的資料序列化系統。 它可以由多種語言（當前為C，C ++，C＃，Java，Python和Ruby）處理。

Avro的一項關鍵功能是對資料架構的強大支援，該架構會隨時間變化，即架構演變。 Avro處理架構更改，例如缺少欄位，新增的欄位和更改的欄位。

Avro提供了豐富的資料結構。 例如，您可以建立一個包含陣列，列舉型別和子記錄的記錄。

這種格式是在資料湖著陸區中儲存資料的理想選擇，因為：1。 通常將從登陸區讀取的資料整體讀取，以供下游系統進行進一步處理（在這種情況下，基於行的格式更有效）2。 下游系統可以輕鬆地從檔案中檢索表模式（無需將模式分別儲存在外部元儲存中）3。 任何源模式更改都易於處理（模式演變）。

PARQUET檔案格式

Parquet是Hadoop的一種開原始檔格式，以平面列格式儲存巢狀的資料結構。

與以行方式儲存資料的傳統方法相比，實木複合地板在儲存和效能方面更為有效。

這對於從“寬”（具有很多列）表中讀取特定列的查詢特別有用，因為它僅讀取需要的列並且將IO最小化。

列式儲存格式是什麼？

為了更好地瞭解Hadoop中的Parquet檔案格式，首先，讓我們看看什麼是列格式。 以面向列的格式，記錄中相同型別的每個列的值都儲存在一起。

例如，如果存在包含ID，emp名稱和Department的記錄，則ID列的所有值都將儲存在一起，Name列的值將一起儲存，依此類推。 如果我們採用與上述相同的記錄模式，並且具有三個欄位ID（int），NAME（varchar）和Department（varchar），則表將如下所示：

對於此表，將按行儲存格式儲存資料，如下所示：

而面向列儲存格式的相同資料將如下所示：

當您需要從表中查詢幾列時，列儲存格式更有效。 由於它們相鄰，因此它將僅讀取所需的列，從而最大程度地減少了IO。

例如，假設您只想要NAME列。 以行儲存格式，必須載入資料集中的每個記錄，將其解析為欄位，然後提取Name的資料。 使用面向列的格式，因為該列的所有值都儲存在一起，所以可以直接轉到“名稱”列。 不需要遍歷整個記錄。

因此，面向列的格式提高了查詢效能，因為去所需的列所需的查詢時間更少，而所需的IO則更少，因為它只需要讀取需要資料的列。

Parquet的獨特功能之一是它也可以以列形式儲存具有巢狀結構的資料。 這意味著在Parquet檔案格式中，即使巢狀欄位也可以單獨讀取，而無需讀取巢狀結構中的所有欄位。 實木複合地板格式使用記錄粉碎和組裝演算法以列形式儲存巢狀結構。

要了解Hadoop中的Parquet檔案格式，您應該注意以下術語：

· 行組：將資料邏輯地水平劃分為行。 行組由資料集中每個列的列塊組成。

· 列塊：特定列的資料塊。 這些列塊位於特定的行組中，並保證在檔案中是連續的。

· 頁面：列塊分為重新寫回的頁面。 這些頁面共享一個公共標題，讀者可以跳過他們不感興趣的頁面。

在此，標題僅包含一個魔術數字“ PAR1”（4位元組），該數字將檔案標識為Parquet格式檔案。

頁尾包含以下內容-

· 檔案元資料-檔案元資料包含所有列元資料起始位置的位置。 希望讀者首先讀取檔案元資料以找到他們感興趣的所有列塊。然後應順序讀取列塊。 它還包括格式版本，架構和所有其他鍵值對。

· 檔案元資料的長度（4位元組）

· 幻數“ PAR1”（4位元組）

ORC檔案格式

最佳化行列（ORC）檔案格式提供了一種高效的資料儲存方式。 它旨在克服其他檔案格式的限制。 它理想地儲存緊湊的資料，並且無需大型，複雜或手動維護的索引就可以跳過不相關的部分。 ORC檔案格式解決了所有這些問題。

ORC檔案格式具有許多優點，例如：

· 一個檔案作為每個任務的輸出，從而減輕了NameNode的負擔

· 支援Hive型別，包括DateTime，十進位制和複雜型別（結構，列表，對映和聯合）

· 使用單獨的RecordReader併發讀取同一檔案

· 無需掃描標記即可分割檔案的能力

· 根據檔案頁尾中的資訊，估計讀取器/寫入器在堆記憶體分配上的上限。

· 使用協議緩衝區儲存的元資料，允許新增和刪除欄位

ORC將行集合儲存在一個檔案中，並且在該集合中，行資料以列格式儲存。

ORC檔案包含稱為條紋的行資料組，以及檔案頁尾中的輔助資訊。 在檔案的末尾，附言包含壓縮引數和壓縮後的頁尾大小。

預設條帶大小為250 MB。 大條帶大小可實現從HDFS進行大而有效的讀取。

檔案頁尾包含檔案中的條紋列表，每個條紋的行數以及每一列的資料型別。 它還包含列級聚合計數，最小，最大和總和。

條紋頁尾包含流位置的目錄。

行資料用於表掃描。

索引資料包括每一列的最小值和最大值以及每一列中行的位置。 ORC索引僅用於選擇條紋和行組，而不用於回答查詢。

不同檔案格式之間的比較

AVRO vs PARQUET

· AVRO是基於行的儲存格式，而PARQUET是基於列的儲存格式。

· PARQUET對於分析查詢要好得多，即讀取和查詢比編寫要有效得多。

· AVRO中的寫操作比PARQUET中的寫操作更好。

· 在模式演化方面，AVRO比PARQUET成熟得多。 PARQUET僅支援架構追加，而AVRO支援功能廣泛的架構演變，即新增或修改列。

· PARQUET是查詢多列表中的列子集的理想選擇。 對於需要查詢所有列的ETL操作，AVRO是理想的選擇。

ORC與PARQUET

· PARQUET更能夠儲存巢狀資料。

· ORC更有能力進行謂詞下推。

· ORC支援ACID屬性。

· ORC壓縮效率更高。

（本文翻譯自Rahul Bhatia的文章《Big Data File Formats》，參考：https：//blog。clairvoyantsoft。com/big-data-file-formats-3fb659903271）