干貨|不同文件格式和存儲(chǔ)引擎在Apache Hadoop生態(tài)系統(tǒng)中的性能比較

---

主題

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

關(guān)于作者

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

簡(jiǎn)介

 比較Hadoop文件格式和存儲(chǔ)引擎的最初想法是受第一個(gè)在CERN（ATNAS EventIndex）上大規(guī)模采用Hadoop系統(tǒng)版本啟發(fā)的。

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

 使用ATLAS EventIndex數(shù)據(jù)進(jìn)行測(cè)試的最終目標(biāo)是了解可以最優(yōu)的使用哪種存儲(chǔ)數(shù)據(jù)方法；以及相對(duì)于系統(tǒng)的主要用例，此類應(yīng)用程序的預(yù)期收益是什么。我們想要進(jìn)行比較的主要方面是數(shù)據(jù)量和以下性能。

• 數(shù)據(jù)擷取；
• 隨機(jī)數(shù)據(jù)查詢；
• 全數(shù)據(jù)掃描。

EVENTINDEX數(shù)據(jù)概述

ATLAS是針對(duì)大型強(qiáng)子對(duì)撞機(jī)（CERN的粒子加速器）建造的七大粒子檢測(cè)器實(shí)驗(yàn)之一。

 ATLAS EventIndex是所有碰撞（稱為“事件”）的元數(shù)據(jù)目錄，這些碰撞在ATLAS實(shí)驗(yàn)中發(fā)生，后被永久存儲(chǔ)在CERN存儲(chǔ)基礎(chǔ)設(shè)施中（通常每秒有幾百個(gè)事件）。物理學(xué)家使用該系統(tǒng)來識(shí)別和定位感興趣的事件，通過共性把事件群體進(jìn)行分組，以及檢查產(chǎn)生周期的一致性。

 每個(gè)編入索引的碰撞均作為單獨(dú)的記錄存儲(chǔ)在ATLAS EventIndex中，其平均長(zhǎng)度為1.5KB，具有56個(gè)屬性，其中6個(gè)屬性唯一地標(biāo)識(shí)了一個(gè)碰撞。大多數(shù)屬性是文本類型，只有少數(shù)屬性是數(shù)字類型。在某一給定時(shí)刻，包含占用幾十T字節(jié)（不包括數(shù)據(jù)復(fù)制）的6e10個(gè)記錄存儲(chǔ)在HDFS中。

HADOOP上已經(jīng)過檢驗(yàn)的存儲(chǔ)方法

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

• Apache Avro是一種用于壓縮二進(jìn)制格式的數(shù)據(jù)序列化標(biāo)準(zhǔn)，其廣泛應(yīng)用于存儲(chǔ)HDFS上的持久性數(shù)據(jù)以及通信協(xié)議。Avro的優(yōu)點(diǎn)之一是輕量級(jí)及快速數(shù)據(jù)序列化和反序列化，這可以提供非常優(yōu)異的數(shù)據(jù)擷取性能。此外，當(dāng)需要實(shí)現(xiàn)快速隨機(jī)數(shù)據(jù)訪問時(shí)，即使沒有任何內(nèi)部索引（如在MapFiles的情況下），也可以應(yīng)用HDFS基于目錄的分區(qū)技術(shù)快速導(dǎo)航到感興趣的集合。

 在測(cè)試中，主鍵前3列的元組被用作分區(qū)鍵，允許在分區(qū)數(shù)（幾千個(gè)）和平均分區(qū)大小（數(shù)百兆字節(jié)）之間獲得良好的平衡

• Apache Parquet是一種用于高效數(shù)據(jù)分析的面向列數(shù)據(jù)的序列化標(biāo)準(zhǔn)。其優(yōu)化包括應(yīng)用于來自相同列的一系列值的編碼（包括RLE、字典、位封包）和提供非常好的壓縮率。以Parquet格式在HDFS上存儲(chǔ)數(shù)據(jù)時(shí)，使用與Avro相同的分區(qū)策略。
• Apache HBase - HDFS上用于存儲(chǔ)鍵值對(duì)的可擴(kuò)展和分布式的NoSQL數(shù)據(jù)庫。對(duì)鍵進(jìn)行索引，通常可以提供對(duì)記錄的快速訪問。

 當(dāng)將ATLAS EventIndex數(shù)據(jù)存儲(chǔ)到HBase中時(shí)，每個(gè)事件屬性存儲(chǔ)在單獨(dú)的單元格中，并且行鍵由事件標(biāo)識(shí)屬性列的級(jí)聯(lián)組成。另外，為減小HBase塊的大小（否則每行長(zhǎng)度會(huì)有8KB）啟用了行鍵（DATA_BLOCK_ENCODING）的差分（FAST_DIFF）編碼。

• Apache Kudu是一種基于表的可擴(kuò)展和分布式的新存儲(chǔ)方式。Kudu提供了索引和列數(shù)據(jù)組織，在獲取速度和分析性能之間實(shí)現(xiàn)了良好的折衷。與HBase的情況一樣，Kudu API允許修改已經(jīng)存儲(chǔ)在系統(tǒng)中的數(shù)據(jù)。

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

得出的結(jié)果

數(shù)據(jù)訪問和擷取測(cè)試在由14臺(tái)實(shí)體機(jī)器組成的集群上進(jìn)行，每臺(tái)機(jī)器配備有：

• 2 塊8核@ 2.60GHz；
• 64GB內(nèi)存；
• 2塊24 SAS驅(qū)動(dòng)器。

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

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

 在本報(bào)告后面提到的所有測(cè)試中，使用Apache Impala（正在孵化中）作為數(shù)據(jù)擷取和數(shù)據(jù)訪問框架。

重要提示：盡管本次測(cè)試為獲得盡可能精確的結(jié)果付出了一些努力，但這不應(yīng)被視為測(cè)試技術(shù)的通用和基本基準(zhǔn)。因?yàn)榇嬖谔嗫赡苡绊憸y(cè)試的變量，所以具體情況應(yīng)該具體分析，例如：

• 選擇的測(cè)試用例；
• 使用的數(shù)據(jù)模型；
• 硬件規(guī)格和配置；
• 用于數(shù)據(jù)處理及其配置/調(diào)優(yōu)的軟件堆棧。

每種格式的空間利用

圖表翻譯：

ROW LENGTH INBYTES 行長(zhǎng)度字節(jié)

No compression 無壓縮

Snappy

GZip/BZip2

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

該圖顯示了各種測(cè)試格式和壓縮類型的平均行長(zhǎng)度（以字節(jié)為單位）

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

注釋：

• 根據(jù)測(cè)量結(jié)果，利用Kudu和Parquet編碼的數(shù)據(jù)提供了最佳的壓縮率。與使用MapFiles的原始數(shù)據(jù)集編碼相比，使用類似Snappy或GZip之類的壓縮算法可以進(jìn)一步顯著減少數(shù)據(jù)量達(dá)10倍。
• 由于HBase存儲(chǔ)數(shù)據(jù)的方式是一個(gè)空間效率較低的解決方案，雖然HBase塊的壓縮給出相當(dāng)好的比率，但是與Kudu和Parquet相比差距仍然較大。
• 就像其他HDFS行存儲(chǔ)方式（例如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

該圖顯示了各種測(cè)試格式和壓縮類型的每個(gè)數(shù)據(jù)分區(qū)的平均擷取速度（103個(gè)記錄/秒）

測(cè)試描述：測(cè)量單個(gè)數(shù)據(jù)分區(qū)中的記錄擷取速度。

注釋：

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

各種格式的隨機(jī)數(shù)據(jù)查找延遲

圖表翻譯：

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

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

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

測(cè)試描述：通過提供記錄標(biāo)識(shí)符（復(fù)合鍵）從記錄中檢索非鍵屬性。

注釋：

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

各種格式的數(shù)據(jù)掃描速率

圖表翻譯：

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

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

測(cè)試描述：計(jì)算在整個(gè)記錄集合中的非鍵列之一中具有某個(gè)子串的記錄數(shù)。

注釋：

• 由于通過應(yīng)用列投影輸入集數(shù)量減少，Parquet在此測(cè)試中勝過了Avro。Parquet不僅在每?jī)?nèi)核處理速率方面保持了最高效率，同時(shí)也在完成處理方面保持最快速度。
• 平均掃描速度（KHZ）。
• 在Parquet和Avro的情況下，數(shù)據(jù)訪問并行化的單位是HDFS文件塊 - 其很容易在Hadoop集群上的所有可用資源上均勻分布處理。
• 在掃描效率方面，Kudu（采用Snappy壓縮）與Parquet相差不大。因?yàn)榱型队埃涫芤娣藴\。
• 由于數(shù)據(jù)訪問并行化的單位是表分區(qū)，掃描存儲(chǔ)在Kudu和HBase中的數(shù)據(jù)可能不平衡。因此，掃描中涉及的資源量取決于給定表分區(qū)的數(shù)量及其在集群中的分布。
• 在這個(gè)測(cè)試案例中，因?yàn)镵udu不支持使用的謂詞，所以不可能使用Kudu的本地謂詞下推功能。附加測(cè)試結(jié)果證明，當(dāng)使用支持的謂詞時(shí)，Kudu掃描速度比Parquet更快。
• 在使用HBase進(jìn)行測(cè)試之前，掃描的列在專用HBase列族中被分離 - 這就提高了5倍的掃描效率。但仍然與Parquet或Kudu存在較大差距。

測(cè)試經(jīng)驗(yàn)教訓(xùn)

 在本節(jié)中，我們想分享關(guān)于數(shù)據(jù)格式使用的其它注意事項(xiàng)及其優(yōu)點(diǎn)和缺點(diǎn)，因?yàn)檫@些是從我們的參考工作負(fù)載測(cè)試中得出的：

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

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

結(jié)論

 對(duì)Hadoop生態(tài)系統(tǒng)上流行存儲(chǔ)技術(shù)的評(píng)估已經(jīng)在許多方面展示了每種技術(shù)的利弊，這些方面例如減少總體數(shù)據(jù)量、簡(jiǎn)化數(shù)據(jù)擷取及提高數(shù)據(jù)訪問的性能。

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

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

 同時(shí)列存儲(chǔ)方式，例如Apache Parquet和Apache Kudu，在快速數(shù)據(jù)采集、快速隨機(jī)數(shù)據(jù)查找和可擴(kuò)展數(shù)據(jù)分析之間提供了非常好的靈活性，同時(shí)確保了系統(tǒng)簡(jiǎn)單性 - 只需要利用一種存儲(chǔ)數(shù)據(jù)的技術(shù)。

Parquet在更快的數(shù)據(jù)掃描和擷取方面具有優(yōu)勢(shì)，而Kudu擅長(zhǎng)于更快的隨機(jī)查找。

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

圖表翻譯：

Throughput for Analytics 分析吞吐量

Map Files地圖文件

 Fast random access (goodness for online transactions) 快速隨機(jī)訪問（在線交易的優(yōu)點(diǎn)）

 歡迎撥打慧都熱線023-68661681或咨詢，我們將幫您轉(zhuǎn)接大數(shù)據(jù)專業(yè)團(tuán)隊(duì)，并發(fā)送相關(guān)資料給您！