比較Apache Hadoop 生態系統中不同的文件格式和存儲引擎的性能
主題
這篇文章提出了在Apache Hadoop 生態系統中對比一些當前流行的數據格式和可用的存儲引擎的性能：Apache Avro, Apache Parquet, Apache HBase 和 Apache Kudu 空間效率， 提取性能， 分析掃描以及隨機數據查找等領域。這有助于理解它們中的每一個如何(何時)改善你的大數據工作負載的處理能力。
引言
最初把hadoop文件格式和存儲引擎做比較的想法是在初始系統修訂版之一的驅動下完成的 –這個系統是在CERN中大規模調節Hadoop—ATLAS EventIndex.
項目啟動始于2012年。那時候用MapReduce處理CSV是最常見的處理大數據的方式。同期平臺， 像Apache Spark, Apache Impala (孵化), 或者文件格式像Avro 和Parquet 還沒有成熟，也不像現在這么流行， 甚至還沒有出現。然而在現在看來選擇基于HDFS MapFiles的設計概念就是陳舊和過時。
我們采用ATLAS EventIndex數據測試的最終目標是為了了解哪種存儲數據方法是最佳應用方法以及這種應用在系統的主要使用案例方面預期的效益是什么。我們要比較的主要方面是數據的容量和性能。
- 數據提取。
- 少量數據查詢。
- 全部數據掃描。
關于EVENTINDEX數據
ATLAS是CERN中的粒子加速器，是構建Large Hadron Collider探測實驗的七個粒子之一。
ATLAS EventIndex是所有碰撞(稱作事件)中的一個元數據目錄，在 ATLAS 實驗中發現，后來被永久存儲在CERN基礎架構中(通常每秒鐘會發生數以百計的事件)物理學家通過共同點和檢查生產周期的一致性用這個系統區分和定位有用的事件和人口群組事件。
每個索引碰撞都是獨立記錄存儲在ATLAS EventIndex ，這種獨立記錄平均1.5KB長具有56種屬性，其中有6個較為獨特的標記為一個碰撞，大多數記錄屬性是文本類型，只有少部分是數字。在給定時刻，HDFS可以存儲6e10條記錄占用上萬兆兆字節內存(不包含復制數據)。
Hadoop的存儲測試方法
將相同的數據集使用不同的存儲技術和壓縮算法存儲在相同的Hadoop集群里(Snappy, GZip or BZip2)：
- Apache Avro是序列化數據，是小型的二進制格式的標準，廣泛用于在HDFS中存儲長久數據以及通訊協議。使用Avro特點之一是重量輕以及快速將數據序列化和反序列化，這樣提取性能就會非常好。此外， 即使它沒有任何內部索引(例如在MapFiles情況下)當需要訪問隨機數據時，HDFS目錄式分區技術可用于快速導航找到利益集合。
在測試中，把主鍵的前三列元組用作一個分區鍵。這就使得分區的數目(幾千)和分區的平均大小(成百上千兆)保持了良好的平衡。
- Apache Parquet是列導向序列化數據，是有效的數據分析的標準。其他優化包括編碼 (RLE, Dictionary, 一些安裝) 和壓縮應用在同列的同系列值就能得到一個非常高的壓縮比率。當在HDFS上用 Parquet 格式存儲數據時，可使用類似Avro 案例中同樣的分區策略。
- Apache HBase為了存儲關鍵值對在HDFS上可擴展的分布NoSQL數據庫，關鍵值作索引通常能非常快速的訪問到記錄。
當存儲ATLAS EventIndex數據到HBase時每個事件的屬性都存儲在獨立的單元格中并且行鍵值被組成串聯事件標記為列屬性。此外，不同的行鍵值 (FAST_DIFF)編碼可以減少HBase塊的大小(如果沒有這一步每行有8KB長度)
- Apache Kudu是新開發可伸縮，分布式，基于表的存儲方式。Kudu提供的索引和列式數據結構調和了提取速度和分析性能。像HBase案例中， Kudu APIs支持修改已經存儲在系統中的數據。
在評估中， 所有文本類型是字典編碼式存儲， 數字類型是隨機編碼存儲。 此外， 通過使用主鍵首列引入范圍組合和hash分區(組成像HBase案例中組合同樣的列) 作為分區鍵。
結果分析
數據訪問和提取測試都是在由14個物理機器組成的集群上完成， 每個物理機器配備：
- 2 x 8 cores @2.60GHz
- 64GB of RAM
- 2 x 24 SAS drives
Hadoop集群安裝的是Cloudera Data Hub(CDH) 分布版本 5.7.0，包括：
- Hadoop core 2.6.0
- Impala 2.5.0
- Hive 1.1.0
- HBase 1.2.0 (配置 JVM 堆 ，區域服務器大小 = 30GB)
(不是 CDH) Kudu 1.0 (配置存儲限制 = 30GB)
Apache Impala (孵化) 在所有測試中作為數據提取和數據訪問框架最后呈現在這份報告中。
重點：盡管所有的努力是為了得到盡可能精確的測試結果，但是也不要把他們當做是普遍和基本的測試技術基準。有太多的影響測試的變量，所以要視情況而定。例如：
- 選擇測試案例
- 使用數據模型
- 硬件規格和配置
- 用于數據處理和配置/調整的軟件棧
空間利用率格式
圖表顯示是測試格式和壓縮類型字節行的平均長度
測試描述： 在使用不同的技術和壓縮辦法存儲同樣的數據集(數百萬的記錄)之后測量平均記錄大小
評價：
- 根據測量結果，用 Kudu和Parquet 編碼數據得到最高的壓縮比率。用像Snappy 或者GZip 等壓縮算法可以進一步顯著的減少容量—通過factor10 比較用MapFiles編碼的原始數據集
- 因為HBase的儲存數據方法是一種空間用量更少高效的解決方案。盡管HBase塊壓縮得到非常不錯的比率， 然而， 還是遠遠不如Kudu 和 Parquet。
- Apache Avro得到的空間占用方面的結果類似HDFS的行存儲—MapFiles
測試描述：記錄測量單個數據分區的提取速度
評價：
- 為了寫入一系列的單個HDFS目錄 (Hive 分區)Apache Impala執行了數據重組，得到的結果是HDFS 格式、 HBase 、Kudu可以直接對比單個數據分區的提取效率。用Avro或者Parquet格式寫HDFS文件編碼 比用HBase 和 Kudu存儲引擎得到的結果更好(至少是5倍)。
- 用Avro或者Parquet編碼寫HDFS文件比用HBase 和 Kudu存儲引擎得到的結果更好(至少是5倍)因為Avro用的是重量最輕的編碼器，達到了最佳提取性能。
- 在光譜的另一端，HBase在這個測試中很慢(比Kudu更慢)。導致這種情況最大的可能是行鍵值的長度(6個連接的列)，平均約為60字節。HBase不得不在單獨的行中為每個列編碼一個鍵，(有很多列)這對于長期記錄并不是最好的選擇。
每種格式查詢隨機數據的延遲：
表格顯示每種測試格式和壓縮類型平均的隨機查詢延遲記錄【以秒計算】
測試描述： 通過提供的一個記錄標識符號從記錄中檢索一個非鍵屬性(一個混合的鍵)
評價：
- 當通過記錄鍵訪問數據時， Kudu 和 HBase是最快的， 因為他們使用的是內置索引。布局上的值是用冷緩存測量的。
- Apache Impala的隨機查詢結果僅次于Kudu和 HBase ，一個顯著原因是在真正執行查詢之前，設置查詢(計劃，代碼生成等)用了大量的時間——通常約為200Ms。因此對于低延遲數據訪問建議跳過Impala使用專用的APIs(我們曾嘗試將這種方法用于Kudu 和 HBase ，結果差不多——用冷緩存小于200ms,用熱緩存小于80ms)。
- 和Kudu HBase相反，從單獨的記錄中檢索數據存儲為Avro格式只能在整個數據分區暴力的掃描才能完成 (提示數據是由記錄鍵的一部分分區的，因此精簡分區僅用于這種情況下)通常分區的大小為GB，因此要獲取想要的記錄需要花幾秒鐘(取決于 IO 吞吐量)使用了大量重要的集群資源。而且必須在集群上全速執行最終才能降低并行查詢的數量，。
- 同樣的問題用于Parquet，然而，列式格式的本來的屬性就允許執行分區掃描相對較快。 由于投影列和列斷言下推，一組掃描輸入最終從GBs減少到少量MBs(實際上只有3列掃描56)。
每種格式的數據掃描率：
圖表顯示了每種測試格式和壓縮類型在每個核中同樣的斷言的平均掃描速度
測試描述：在整個記錄集合中計算在非鍵值列之一中的固定子字符串的記錄數目。
評價：
- 由于采用投影列減少輸入集， 在此次測試中Parquet落在 Avro后面。它不僅是單核處理率方面最有效率而且最快結束處理。
- 平均掃描速度(KHZ)
- 在Parquet 和 Avro是HDFS文件塊的情況下數據單元可以并行化訪問，由于所有的可用資源在一個Hadoop集群上所以要均勻分布處理非常簡單。
- 得益于列投影，在掃描效率方面Kudu (具有Snappy壓縮) 和Parquet差不多。
- 用Kudu和 HBase存儲掃描數據可能會平衡因為并行單元在兩種情況下都是分區表。因此參與掃描的資源量取決于給定分區表的數量，以及對其在集群中的分布。
- 在這個測試案例中， 使用Kudu本地斷言下推功能是不可能的， 因為Kudu不支持使用斷言。在其他測試中證實當Kudu支持使用斷言時它的掃描速度就比 Parquet更快。
- 在用HBase執行測試之前掃描列被分離在一個專門的HBase列家族中—通過factor5提高了掃描效率。但是還是遠遠不如Parquet或者Kudu。
從測試中習得的經驗：
在這段我們想分享關于使用的數據格式其他的想法，優缺點，脫離測試和我們的工作負載參考：
- 存儲效率 — 對比未壓縮的簡單的序列化格式 用Parquet 或者 Kudu 和Snappy壓縮可以通過factor10減少全部的數據容量
- 數據提取速度 — 基于解決方案的所有的測試文件提供的提取率(在2倍和10倍之間)比專門存儲在引擎或者 MapFiles(按順序存儲) 中快。
- 隨機訪問數據時間 — 使用HBase或者Kudu，一般隨機查詢數據的速度低于500ms。使用智能HDFS命名Parquet分區空間可以提供一個第二水平的隨機查詢但是會消耗更多的資源。
- 數據分析 — 使用Parquet 或者Kudu 可以執行快速、可擴展的(一般每個CPU核心每秒超過300k以上記錄)的數據聚合、過濾和報告。
- 支持數據原地突變 — HBase和Kudu可以原地修改記錄，如果將數據直接存儲在HDFS文件中是不可能修改的。
值得注意的是，壓縮算法扮演了一個非常重要的角色不僅是減少了數據容量還提高了數據提取和數據訪問的性能。比起未壓縮的普通編碼，編碼解碼器在所有的領域為所有的測試技術提供了最好的研究結果(除了 Avro 案例).
總結：
在Hadoop生態系統中流行的存儲技術，從很多方面證明了他們中每一個的優點和缺點，像減少整體數據容量，簡化了數據提取，提高了數據訪問的性能等。
Apache Avro已被證明是結構化數據快速通用的編碼器。由于非常有效的序列化和反序列化，此格式可以確保良好的性能，同時支持隨時訪問記錄的所有屬性、數據傳輸、分級區等。
另一方面， Apache HBase提供了良好的隨機的數據訪問性能以及最大的靈活性在呈現數據存儲時(無模式表)HBase數據的批量處理的性能很大程度上取決于數據模型的選擇，并且其他測試技術無法在這一領域競爭。因此用Hbase的數據能執行任何分析技術都很罕見。
根據測試中的列式存儲像Apache Parquet 和Apache Kudu在快速提取數據，快速隨機查詢數據，可擴展的數據分析，同時確保系統的簡化—僅用一種數據存儲技術，表現了非常好的靈活性。
Kudu擅長快速隨機查詢而Parquet擅長快速掃描及提取數據。
不同于單一存儲技術的實施，混合系統被認為是由批量處理的原始存儲技術以及隨機訪問的索引層技術組成的。這完全得益于特定訪問路徑提供的最佳性能對技術專業化/優化。值得注意的是， 這種方法是以數據重復，整體系統的復雜性和更貴的維護成本為代價。因此如果簡化的系統是非常重要的因素那么Apache Kudu顯然是一個不錯的選擇。
快速隨機訪問(在線交易的優勢)
