[[194070]]

主題

這篇文章提出了在Apache Hadoop 生態(tài)系統(tǒng)中對比一些當前流行的數(shù)據(jù)格式和可用的存儲引擎的性能：Apache Avro, Apache Parquet, Apache HBase 和 Apache Kudu 空間效率， 提取性能， 分析掃描以及隨機數(shù)據(jù)查找等領域。這有助于理解它們中的每一個如何(何時)改善你的大數(shù)據(jù)工作負載的處理能力。

引言

最初把hadoop文件格式和存儲引擎做比較的想法是在初始系統(tǒng)修訂版之一的驅動下完成的 –這個系統(tǒng)是在CERN中大規(guī)模調節(jié)Hadoop—ATLAS EventIndex.

項目啟動始于2012年。那時候用MapReduce處理CSV是最常見的處理大數(shù)據(jù)的方式。同期平臺， 像Apache Spark, Apache Impala (孵化), 或者文件格式像Avro 和Parquet 還沒有成熟，也不像現(xiàn)在這么流行， 甚至還沒有出現(xiàn)。然而在現(xiàn)在看來選擇基于HDFS MapFiles的設計概念就是陳舊和過時。

我們采用ATLAS EventIndex數(shù)據(jù)測試的最終目標是為了了解哪種存儲數(shù)據(jù)方法是最佳應用方法以及這種應用在系統(tǒng)的主要使用案例方面預期的效益是什么。我們要比較的主要方面是數(shù)據(jù)的容量和性能。

• 數(shù)據(jù)提取。
• 少量數(shù)據(jù)查詢。
• 全部數(shù)據(jù)掃描。

關于EVENTINDEX數(shù)據(jù)

ATLAS是CERN中的粒子加速器，是構建Large Hadron Collider探測實驗的七個粒子之一。

ATLAS EventIndex是所有碰撞(稱作事件)中的一個元數(shù)據(jù)目錄，在 ATLAS 實驗中發(fā)現(xiàn)，后來被永久存儲在CERN基礎架構中(通常每秒鐘會發(fā)生數(shù)以百計的事件)物理學家通過共同點和檢查生產(chǎn)周期的一致性用這個系統(tǒng)區(qū)分和定位有用的事件和人口群組事件。

每個索引碰撞都是獨立記錄存儲在ATLAS EventIndex ，這種獨立記錄平均1.5KB長具有56種屬性，其中有6個較為獨特的標記為一個碰撞，大多數(shù)記錄屬性是文本類型，只有少部分是數(shù)字。在給定時刻，HDFS可以存儲6e10條記錄占用上萬兆兆字節(jié)內存(不包含復制數(shù)據(jù))。

Hadoop的存儲測試方法

將相同的數(shù)據(jù)集使用不同的存儲技術和壓縮算法存儲在相同的Hadoop集群里(Snappy, GZip or BZip2)：

• Apache Avro是序列化數(shù)據(jù)，是小型的二進制格式的標準，廣泛用于在HDFS中存儲長久數(shù)據(jù)以及通訊協(xié)議。使用Avro特點之一是重量輕以及快速將數(shù)據(jù)序列化和反序列化，這樣提取性能就會非常好。此外， 即使它沒有任何內部索引(例如在MapFiles情況下)當需要訪問隨機數(shù)據(jù)時，HDFS目錄式分區(qū)技術可用于快速導航找到利益集合。

在測試中，把主鍵的前三列元組用作一個分區(qū)鍵。這就使得分區(qū)的數(shù)目(幾千)和分區(qū)的平均大小(成百上千兆)保持了良好的平衡。

• Apache Parquet是列導向序列化數(shù)據(jù)，是有效的數(shù)據(jù)分析的標準。其他優(yōu)化包括編碼 (RLE, Dictionary, 一些安裝) 和壓縮應用在同列的同系列值就能得到一個非常高的壓縮比率。當在HDFS上用 Parquet 格式存儲數(shù)據(jù)時，可使用類似Avro 案例中同樣的分區(qū)策略。
• Apache HBase為了存儲關鍵值對在HDFS上可擴展的分布NoSQL數(shù)據(jù)庫，關鍵值作索引通常能非?？焖俚脑L問到記錄。

當存儲ATLAS EventIndex數(shù)據(jù)到HBase時每個事件的屬性都存儲在獨立的單元格中并且行鍵值被組成串聯(lián)事件標記為列屬性。此外，不同的行鍵值 (FAST_DIFF)編碼可以減少HBase塊的大小(如果沒有這一步每行有8KB長度)

• Apache Kudu是新開發(fā)可伸縮，分布式，基于表的存儲方式。Kudu提供的索引和列式數(shù)據(jù)結構調和了提取速度和分析性能。像HBase案例中， Kudu APIs支持修改已經(jīng)存儲在系統(tǒng)中的數(shù)據(jù)。

在評估中， 所有文本類型是字典編碼式存儲， 數(shù)字類型是隨機編碼存儲。 此外， 通過使用主鍵首列引入范圍組合和hash分區(qū)(組成像HBase案例中組合同樣的列) 作為分區(qū)鍵。

結果分析

數(shù)據(jù)訪問和提取測試都是在由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 堆 ，區(qū)域服務器大小 = 30GB)

(不是 CDH) Kudu 1.0 (配置存儲限制 = 30GB)

Apache Impala (孵化) 在所有測試中作為數(shù)據(jù)提取和數(shù)據(jù)訪問框架最后呈現(xiàn)在這份報告中。

重點：盡管所有的努力是為了得到盡可能精確的測試結果，但是也不要把他們當做是普遍和基本的測試技術基準。有太多的影響測試的變量，所以要視情況而定。例如：

• 選擇測試案例
• 使用數(shù)據(jù)模型
• 硬件規(guī)格和配置
• 用于數(shù)據(jù)處理和配置/調整的軟件棧

空間利用率格式

圖表顯示是測試格式和壓縮類型字節(jié)行的平均長度

測試描述： 在使用不同的技術和壓縮辦法存儲同樣的數(shù)據(jù)集(數(shù)百萬的記錄)之后測量平均記錄大小

評價：

• 根據(jù)測量結果，用 Kudu和Parquet 編碼數(shù)據(jù)得到最高的壓縮比率。用像Snappy 或者GZip 等壓縮算法可以進一步顯著的減少容量—通過factor10 比較用MapFiles編碼的原始數(shù)據(jù)集
• 因為HBase的儲存數(shù)據(jù)方法是一種空間用量更少高效的解決方案。盡管HBase塊壓縮得到非常不錯的比率， 然而， 還是遠遠不如Kudu 和 Parquet。
• Apache Avro得到的空間占用方面的結果類似HDFS的行存儲—MapFiles

測試描述：記錄測量單個數(shù)據(jù)分區(qū)的提取速度

評價：

• 為了寫入一系列的單個HDFS目錄 (Hive 分區(qū))Apache Impala執(zhí)行了數(shù)據(jù)重組，得到的結果是HDFS 格式、 HBase 、Kudu可以直接對比單個數(shù)據(jù)分區(qū)的提取效率。用Avro或者Parquet格式寫HDFS文件編碼 比用HBase 和 Kudu存儲引擎得到的結果更好(至少是5倍)。
• 用Avro或者Parquet編碼寫HDFS文件比用HBase 和 Kudu存儲引擎得到的結果更好(至少是5倍)因為Avro用的是重量最輕的編碼器，達到了最佳提取性能。
• 在光譜的另一端，HBase在這個測試中很慢(比Kudu更慢)。導致這種情況最大的可能是行鍵值的長度(6個連接的列)，平均約為60字節(jié)。HBase不得不在單獨的行中為每個列編碼一個鍵，(有很多列)這對于長期記錄并不是最好的選擇。

每種格式查詢隨機數(shù)據(jù)的延遲：

表格顯示每種測試格式和壓縮類型平均的隨機查詢延遲記錄【以秒計算】

測試描述： 通過提供的一個記錄標識符號從記錄中檢索一個非鍵屬性(一個混合的鍵)

評價：

• 當通過記錄鍵訪問數(shù)據(jù)時， Kudu 和 HBase是最快的， 因為他們使用的是內置索引。布局上的值是用冷緩存測量的。
• Apache Impala的隨機查詢結果僅次于Kudu和 HBase ，一個顯著原因是在真正執(zhí)行查詢之前，設置查詢(計劃，代碼生成等)用了大量的時間——通常約為200Ms。因此對于低延遲數(shù)據(jù)訪問建議跳過Impala使用專用的APIs(我們曾嘗試將這種方法用于Kudu 和 HBase ，結果差不多——用冷緩存小于200ms,用熱緩存小于80ms)。
• 和Kudu HBase相反，從單獨的記錄中檢索數(shù)據(jù)存儲為Avro格式只能在整個數(shù)據(jù)分區(qū)暴力的掃描才能完成 (提示數(shù)據(jù)是由記錄鍵的一部分分區(qū)的，因此精簡分區(qū)僅用于這種情況下)通常分區(qū)的大小為GB，因此要獲取想要的記錄需要花幾秒鐘(取決于 IO 吞吐量)使用了大量重要的集群資源。而且必須在集群上全速執(zhí)行最終才能降低并行查詢的數(shù)量，。
• 同樣的問題用于Parquet，然而，列式格式的本來的屬性就允許執(zhí)行分區(qū)掃描相對較快。 由于投影列和列斷言下推，一組掃描輸入最終從GBs減少到少量MBs(實際上只有3列掃描56)。

每種格式的數(shù)據(jù)掃描率：

圖表顯示了每種測試格式和壓縮類型在每個核中同樣的斷言的平均掃描速度

測試描述：在整個記錄集合中計算在非鍵值列之一中的固定子字符串的記錄數(shù)目。

評價：

• 由于采用投影列減少輸入集， 在此次測試中Parquet落在 Avro后面。它不僅是單核處理率方面最有效率而且最快結束處理。
• 平均掃描速度(KHZ)
• 在Parquet 和 Avro是HDFS文件塊的情況下數(shù)據(jù)單元可以并行化訪問，由于所有的可用資源在一個Hadoop集群上所以要均勻分布處理非常簡單。
• 得益于列投影，在掃描效率方面Kudu (具有Snappy壓縮) 和Parquet差不多。
• 用Kudu和 HBase存儲掃描數(shù)據(jù)可能會平衡因為并行單元在兩種情況下都是分區(qū)表。因此參與掃描的資源量取決于給定分區(qū)表的數(shù)量，以及對其在集群中的分布。
• 在這個測試案例中， 使用Kudu本地斷言下推功能是不可能的， 因為Kudu不支持使用斷言。在其他測試中證實當Kudu支持使用斷言時它的掃描速度就比 Parquet更快。
• 在用HBase執(zhí)行測試之前掃描列被分離在一個專門的HBase列家族中—通過factor5提高了掃描效率。但是還是遠遠不如Parquet或者Kudu。

從測試中習得的經(jīng)驗：

在這段我們想分享關于使用的數(shù)據(jù)格式其他的想法，優(yōu)缺點，脫離測試和我們的工作負載參考：

• 存儲效率 — 對比未壓縮的簡單的序列化格式 用Parquet 或者 Kudu 和Snappy壓縮可以通過factor10減少全部的數(shù)據(jù)容量
• 數(shù)據(jù)提取速度 — 基于解決方案的所有的測試文件提供的提取率(在2倍和10倍之間)比專門存儲在引擎或者 MapFiles(按順序存儲) 中快。
• 隨機訪問數(shù)據(jù)時間 — 使用HBase或者Kudu，一般隨機查詢數(shù)據(jù)的速度低于500ms。使用智能HDFS命名Parquet分區(qū)空間可以提供一個第二水平的隨機查詢但是會消耗更多的資源。
• 數(shù)據(jù)分析 — 使用Parquet 或者Kudu 可以執(zhí)行快速、可擴展的(一般每個CPU核心每秒超過300k以上記錄)的數(shù)據(jù)聚合、過濾和報告。
• 支持數(shù)據(jù)原地突變 — HBase和Kudu可以原地修改記錄，如果將數(shù)據(jù)直接存儲在HDFS文件中是不可能修改的。

值得注意的是，壓縮算法扮演了一個非常重要的角色不僅是減少了數(shù)據(jù)容量還提高了數(shù)據(jù)提取和數(shù)據(jù)訪問的性能。比起未壓縮的普通編碼，編碼解碼器在所有的領域為所有的測試技術提供了最好的研究結果(除了 Avro 案例).

總結：

在Hadoop生態(tài)系統(tǒng)中流行的存儲技術，從很多方面證明了他們中每一個的優(yōu)點和缺點，像減少整體數(shù)據(jù)容量，簡化了數(shù)據(jù)提取，提高了數(shù)據(jù)訪問的性能等。

Apache Avro已被證明是結構化數(shù)據(jù)快速通用的編碼器。由于非常有效的序列化和反序列化，此格式可以確保良好的性能，同時支持隨時訪問記錄的所有屬性、數(shù)據(jù)傳輸、分級區(qū)等。

另一方面， Apache HBase提供了良好的隨機的數(shù)據(jù)訪問性能以及最大的靈活性在呈現(xiàn)數(shù)據(jù)存儲時(無模式表)HBase數(shù)據(jù)的批量處理的性能很大程度上取決于數(shù)據(jù)模型的選擇，并且其他測試技術無法在這一領域競爭。因此用Hbase的數(shù)據(jù)能執(zhí)行任何分析技術都很罕見。

根據(jù)測試中的列式存儲像Apache Parquet 和Apache Kudu在快速提取數(shù)據(jù)，快速隨機查詢數(shù)據(jù)，可擴展的數(shù)據(jù)分析，同時確保系統(tǒng)的簡化—僅用一種數(shù)據(jù)存儲技術，表現(xiàn)了非常好的靈活性。

Kudu擅長快速隨機查詢而Parquet擅長快速掃描及提取數(shù)據(jù)。

不同于單一存儲技術的實施，混合系統(tǒng)被認為是由批量處理的原始存儲技術以及隨機訪問的索引層技術組成的。這完全得益于特定訪問路徑提供的最佳性能對技術專業(yè)化/優(yōu)化。值得注意的是， 這種方法是以數(shù)據(jù)重復，整體系統(tǒng)的復雜性和更貴的維護成本為代價。因此如果簡化的系統(tǒng)是非常重要的因素那么Apache Kudu顯然是一個不錯的選擇。

快速隨機訪問(在線交易的優(yōu)勢)