主題
這篇文章提出了在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顯然是一個不錯的選擇。
快速随機通路(線上交易的優勢)
本文作者：佚名
來源：51cto