干貨|不同文件格式和存儲引擎在Apache Hadoop生態系統中的性能比較

翻譯|大數據新聞|編輯：蔣永|2019-03-19 10:17:37.000|閱讀 275 次

概述：本篇博文對Apache Hadoop生態系統中可用的幾種流行數據格式和存儲引擎進行了性能比較。這些內容將有助于用戶理解如何（以及何時）可以改善大數據工作負載的處理。

相關鏈接：

主題

本篇博文對Apache Hadoop生態系統中可用的幾種流行數據格式和存儲引擎（包括Apache Avro、Apache Parquet、Apache HBase和Apache Kudu）進行了性能比較，涉及空間效率、數據擷取性能、分析掃描和隨機數據查詢等。這些內容將有助于用戶理解如何（以及何時）可以改善大數據工作負載的處理。

Apache Hadoop生態

關于作者

本文作者ZBigniew Baranowski是一位數據庫系統專家，并且是提供和支持中央數據庫和基于Hadoop服務的CERN（歐洲核子研究組織）的成員。

簡介

比較Hadoop文件格式和存儲引擎的最初想法是受第一個在CERN（ATNAS EventIndex）上大規模采用Hadoop系統版本啟發的。

該項目于2012年開始啟動，當時利用MapReduce處理CSV是處理大數據的常見方式。同時，Apache Spark、Apache Impala（正在孵化中）之類的平臺或Avro、Parquet等文件格式不像現在這么成熟和流行，甚至都尚未啟動。因此回顧過去，基于使用HDFS MapFiles選擇的設計是一種“過時的”且較不受歡迎的概念。

使用ATLAS EventIndex數據進行測試的最終目標是了解可以最優的使用哪種存儲數據方法；以及相對于系統的主要用例，此類應用程序的預期收益是什么。我們想要進行比較的主要方面是數據量和以下性能。

數據擷取；
隨機數據查詢；
全數據掃描。

EVENTINDEX數據概述

ATLAS是針對大型強子對撞機（CERN的粒子加速器）建造的七大粒子檢測器實驗之一。

ATLAS EventIndex是所有碰撞（稱為“事件”）的元數據目錄，這些碰撞在ATLAS實驗中發生，后被永久存儲在CERN存儲基礎設施中（通常每秒有幾百個事件）。物理學家使用該系統來識別和定位感興趣的事件，通過共性把事件群體進行分組，以及檢查產生周期的一致性。

每個編入索引的碰撞均作為單獨的記錄存儲在ATLAS EventIndex中，其平均長度為1.5KB，具有56個屬性，其中6個屬性唯一地標識了一個碰撞。大多數屬性是文本類型，只有少數屬性是數字類型。在某一給定時刻，包含占用幾十T字節（不包括數據復制）的6e10個記錄存儲在HDFS中。

HADOOP上已經過檢驗的存儲方法

已使用不同的存儲技術和壓縮算法（包括Snappy、GZip或BZip2）將相同的數據集存儲在同一Hadoop集群中：

Apache Avro是一種用于壓縮二進制格式的數據序列化標準，其廣泛應用于存儲HDFS上的持久性數據以及通信協議。Avro的優點之一是輕量級及快速數據序列化和反序列化，這可以提供非常優異的數據擷取性能。此外，當需要實現快速隨機數據訪問時，即使沒有任何內部索引（如在MapFiles的情況下），也可以應用HDFS基于目錄的分區技術快速導航到感興趣的集合。

在測試中，主鍵前3列的元組被用作分區鍵，允許在分區數（幾千個）和平均分區大小（數百兆字節）之間獲得良好的平衡

Apache Parquet是一種用于高效數據分析的面向列數據的序列化標準。其優化包括應用于來自相同列的一系列值的編碼（包括RLE、字典、位封包）和提供非常好的壓縮率。以Parquet格式在HDFS上存儲數據時，使用與Avro相同的分區策略。
Apache HBase - HDFS上用于存儲鍵值對的可擴展和分布式的NoSQL數據庫。對鍵進行索引，通常可以提供對記錄的快速訪問。

當將ATLAS EventIndex數據存儲到HBase中時，每個事件屬性存儲在單獨的單元格中，并且行鍵由事件標識屬性列的級聯組成。另外，為減小HBase塊的大小（否則每行長度會有8KB）啟用了行鍵（DATA_BLOCK_ENCODING）的差分（FAST_DIFF）編碼。

Apache Kudu是一種基于表的可擴展和分布式的新存儲方式。Kudu提供了索引和列數據組織，在獲取速度和分析性能之間實現了良好的折衷。與HBase的情況一樣，Kudu API允許修改已經存儲在系統中的數據。

在評估中，所有文字類型都以字典編碼存儲，數字類型則以位隨機編碼存儲。此外，通過使用主鍵的第一列（由與HBase案例中相同的列組成）作為分區鍵，引入了范圍和散列分區的組合。

得出的結果

數據訪問和擷取測試在由14臺實體機器組成的集群上進行，每臺機器配備有：

2 塊8核@ 2.60GHz；
64GB內存；
2塊24 SAS驅動器。

從Cloudera Data Hub（CDH）發行版本5.7.0安裝的Hadoop集群包括以下幾個方面：

Hadoop內核2.6.0；
Impala 2.5.0；
Hive 1.1.0；
HBase 1.2.0（為區域服務器配置的JVM堆大小= 30GB）；
（不是來自CDH）Kudu 1.0（配置內存限制 = 30GB）。

在本報告后面提到的所有測試中，使用Apache Impala（正在孵化中）作為數據擷取和數據訪問框架。

重要提示：盡管本次測試為獲得盡可能精確的結果付出了一些努力，但這不應被視為測試技術的通用和基本基準。因為存在太多可能影響測試的變量，所以具體情況應該具體分析，例如：

選擇的測試用例；
使用的數據模型；
硬件規格和配置；
用于數據處理及其配置/調優的軟件堆棧。

每種格式的空間利用

圖表翻譯：

ROW LENGTH INBYTES 行長度字節

No compression 無壓縮

Snappy

GZip/BZip2

The figure reports on the average row length in bytes for each tested format and compression type

該圖顯示了各種測試格式和壓縮類型的平均行長度（以字節為單位）

測試描述：在使用不同技術和壓縮方法存儲相同的數據集（百萬條記錄）后，測量記錄的平均大小。

注釋：

根據測量結果，利用Kudu和Parquet編碼的數據提供了最佳的壓縮率。與使用MapFiles的原始數據集編碼相比，使用類似Snappy或GZip之類的壓縮算法可以進一步顯著減少數據量達10倍。
由于HBase存儲數據的方式是一個空間效率較低的解決方案，雖然HBase塊的壓縮給出相當好的比率，但是與Kudu和Parquet相比差距仍然較大。
就像其他HDFS行存儲方式（例如MapFiles）一樣，Apache Avro在空間占用方面提供了類似的效果。

各種格式的擷取速度

圖表翻譯：

AVERGE INSERTION RATE(KHZ) 平均插入速率（KHZ）

Figure reports on the average ingestion speed (103 record/s) per data partition for each tested format and compression type

該圖顯示了各種測試格式和壓縮類型的每個數據分區的平均擷取速度（103個記錄/秒）

測試描述：測量單個數據分區中的記錄擷取速度。

注釋：

由于Apache Impala執行數據重構以串行寫入單個HDFS目錄（Hive分區），因此對于HDFS格式和HBase或Kudu的格式，可以直接比較單個數據分區擷取效率。使用Avro或Parquet編碼寫入的HDFS文件比存儲引擎（如HBase和Kudu）提供了更好的結果（至少5倍）。
使用Avro或Parquet編碼寫入的HDFS文件比存儲引擎（例如HBase和Kudu）提供了更好的結果（至少5倍）。由于Avro具有最輕量的編碼器，因此其實現了最好的擷取性能。
另一方面，在這個測試中HBase非常慢（性能比Kudu差）。這很可能是由于行鍵的長度（6個并置列）引起的，其平均約為60個字節。HBase必須為一行中的每一列分別編碼一個鍵，這對于長記錄（包含許多列）可能不是最佳的方法。

各種格式的隨機數據查找延遲

圖表翻譯：

AVERGE RANDOM LOOKUP LATENCY[S] 平均隨機查找延遲 [單位：S]

Figure reports on the average random record lookup latency [in seconds] for each tested format and compression type

該圖顯示了每種測試格式和壓縮類型的平均隨機記錄查找延遲 [以秒為單位]

測試描述：通過提供記錄標識符（復合鍵）從記錄中檢索非鍵屬性。

注釋：

當通過記錄鍵訪問數據時，因為使用了內置索引，Kudu和HBase的訪問速度是最快的。圖上的值都是基于冷緩存（cold cache）進行測量。
使用Apache Impala進行隨機查找測試對于Kudu和HBase來說是次優選擇，因為在真正執行查詢（計劃、代碼生成等）之前耗費了大量的時間 - 通常大約是200ms。因此，對于低延遲數據訪問，建議跳過Impala并使用專用API（我們也嘗試過這種方法，Kudu和HBase的結果類似 - 冷緩存 < 200ms，預熱緩存 < 80ms）。
與Kudu和HBase相反，檢索以Avro格式存儲的單個記錄中的數據只能在對整個數據分區的強力掃描中完成（需要注意的是 - 數據由記錄鍵的一部分進行分區，因此針對這種情況應用分區修剪技術）。平均分區的大小為GB級，因此獲取所需的記錄需要耗費幾秒鐘的時間（取決于IO吞吐量），并使用大量的集群資源。這最終減少了必須在集群上全速執行的并發查詢的數量。
同樣的問題也適用于Parquet，然而，Parquet格式的柱狀特性允許相對快速地執行分區掃描。由于列投影和列謂詞的下推，掃描輸入集的大小最終從數GB減少到只有幾MB（非常高效，56列經過掃描后只剩下3列）。

各種格式的數據掃描速率

圖表翻譯：

AVERGE SCAN RATE(KHZ) 平均掃描速率（KHZ）

Figure reports on the average scans speed with the same predicate per core [in k records/s] for each tested format and compression type

該圖顯示了各種測試格式和壓縮類型對每個核心具有相同的謂詞[單位：k 條記錄/秒]的平均掃描速度

測試描述：計算在整個記錄集合中的非鍵列之一中具有某個子串的記錄數。

注釋：

由于通過應用列投影輸入集數量減少，Parquet在此測試中勝過了Avro。Parquet不僅在每內核處理速率方面保持了最高效率，同時也在完成處理方面保持最快速度。
平均掃描速度（KHZ）。
在Parquet和Avro的情況下，數據訪問并行化的單位是HDFS文件塊 - 其很容易在Hadoop集群上的所有可用資源上均勻分布處理。
在掃描效率方面，Kudu（采用Snappy壓縮）與Parquet相差不大。因為列投影，其受益匪淺。
由于數據訪問并行化的單位是表分區，掃描存儲在Kudu和HBase中的數據可能不平衡。因此，掃描中涉及的資源量取決于給定表分區的數量及其在集群中的分布。
在這個測試案例中，因為Kudu不支持使用的謂詞，所以不可能使用Kudu的本地謂詞下推功能。附加測試結果證明，當使用支持的謂詞時，Kudu掃描速度比Parquet更快。
在使用HBase進行測試之前，掃描的列在專用HBase列族中被分離 - 這就提高了5倍的掃描效率。但仍然與Parquet或Kudu存在較大差距。

測試經驗教訓

在本節中，我們想分享關于數據格式使用的其它注意事項及其優點和缺點，因為這些是從我們的參考工作負載測試中得出的：

存儲效率 – 采用Parquet或Kudu和Snappy壓縮，與未壓縮的簡單序列化格式相比，總的數據量可以減少10倍。
數據擷取速度 - 所有基于文件的解決方案提供了比專用存儲引擎或MapFiles（排序后的序列）更快的數據擷取速度（在2倍-10倍之間）。
隨機數據訪問時間 - 使用HBase或Kudu，典型的隨機數據查找速度低于500ms。使用智能HDFS名字空間分區Parquet可以提供一秒級的隨機查詢速度，但是會消耗更多的資源。
數據分析 – 利用Parquet或Kudu可以執行快速和可擴展（通常每個CPU內核每秒超過300k條記錄）的數據聚合、過濾和報告。
支持就地數據突變 - HBase和Kudu可以就地修改記錄（模式和值）；與之對比，不可能就地修改直接存儲在HDFS文件中的數據。

值得注意的是，壓縮算法不僅在減少數據量方面發揮了重要作用，在增強數據擷取和數據訪問的性能方面也扮演著重要角色。在所有這些領域中，Snappy編解碼器為所有測試技術提供了最佳的結果，比沒有壓縮的純編碼（Avro除外）更好。

結論

對Hadoop生態系統上流行存儲技術的評估已經在許多方面展示了每種技術的利弊，這些方面例如減少總體數據量、簡化數據擷取及提高數據訪問的性能。

Apache Avro已被證明是一種用于結構化數據的快速通用編碼器。由于具備非常高效的序列化和反序列化性能，當需要同時訪問記錄的所有屬性時，此格式可以保證非常好的性能 - 數據傳輸、分段區域等。

另一方面，Apache HBase提供了非常優異的隨機數據訪問性能，以及如何存儲數據（無模式表）的最大靈活性。HBase數據的批處理性能在很大程度上取決于所選擇的數據模型，并且通常不能在該領域與其他測試技術競爭。因此，任何使用HBase數據的分析都應該很少執行。

同時列存儲方式，例如Apache Parquet和Apache Kudu，在快速數據采集、快速隨機數據查找和可擴展數據分析之間提供了非常好的靈活性，同時確保了系統簡單性 - 只需要利用一種存儲數據的技術。

Parquet在更快的數據掃描和擷取方面具有優勢，而Kudu擅長于更快的隨機查找。

替代單一存儲技術實現可以考慮由用于批處理（如Parquet）的原始存儲和用于隨機存取的索引層（例如HBase）組成的混合系統。這允許在某些訪問路徑上充分利用技術專業化/優化，并提供最佳性能。值得注意的是，這種方法存在數據重復和系統架構總體復雜性的問題，并且需要以更高的維護成本為代價。因此，如果系統的簡單性是重要因素之一，Apache Kudu似乎是一個很好的折衷方式。