怎么在HDFS中進(jìn)行數據壓縮

這篇文章主要講解了“怎么在HDFS中進(jìn)行數據壓縮”，文中的講解內容簡(jiǎn)單清晰，易于學(xué)習與理解，下面請大家跟著(zhù)小編的思路慢慢深入，一起來(lái)研究和學(xué)習“怎么在HDFS中進(jìn)行數據壓縮”吧！

通過(guò)數據壓縮實(shí)現高效存儲

數據壓縮是文件處理的重要方面，在處理Hadoop支持的數據大小時(shí)，這一點(diǎn)變得更加重要。大部分企業(yè)在使用Hadoop時(shí)，目標都是盡可能高效得進(jìn)行數據處理，選擇合適的壓縮編解碼器將使作業(yè)運行更快，并允許在集群中存儲更多數據。

為數據選擇正確的壓縮編解碼器

在HDFS上使用壓縮并不像在ZFS等文件系統上那樣透明，特別是在處理可拆分的壓縮文件時(shí)(本章稍后將詳細介紹)。使用Avro和SequenceFile等文件格式的優(yōu)點(diǎn)是內置壓縮支持，使壓縮幾乎對用戶(hù)完全透明。但是在使用文本等格式時(shí)，就會(huì )失去這種支持。

問(wèn)題

評估并確定用于數據壓縮的最佳編解碼器。

解決方案

谷歌的壓縮編解碼器Snappy提供壓縮大小和讀/寫(xiě)執行時(shí)間的最佳組合。但是，當使用必須支持可拆分性的大型壓縮文件時(shí)，LZOP是最好的編解碼器。

討論

首先，快速瀏覽可用于Hadoop的壓縮編解碼器，如表4.1所示。

表4.1壓縮編解碼器

要正確評估編解碼器，首先需要確定評估標準，該標準應基于功能和性能特征。對于壓縮，你的標準可能包括以下內容：

• 空間/時(shí)間權衡——通常，計算成本越高的壓縮編解碼器可以產(chǎn)生更好的壓縮比，從而產(chǎn)生更小的壓縮輸出。

• 可拆分性——可以拆分壓縮文件以供多個(gè)mapper使用。如果無(wú)法拆分壓縮文件，則只能使用一個(gè)mapper。如果該文件跨越多個(gè)塊，則會(huì )丟失數據局部性，因為map可能必須從遠程DataNode讀取塊，從而導致網(wǎng)絡(luò )I/O開(kāi)銷(xiāo)。

• 本機壓縮支持——是否存在執行壓縮和解壓縮的本地庫?這通常勝過(guò)用Java編寫(xiě)的壓縮編解碼器，沒(méi)有底層的本機庫支持。

表4.2 壓縮編解碼器比較

Native vs Java bzip2

Hadoop添加了對bzip2的原生支持(從版本2.0和1.1.0開(kāi)始)。本機bzip2支持是默認的，但不支持可拆分性。如果需要可拆分性，就需要啟用Java bzip2，可以通過(guò)將io.compression .codec.bzip2.library設置為java-builtin來(lái)指定。

接下來(lái)，我們來(lái)了解編解碼器在空間和時(shí)間上是如何平衡的。此處使用100 MB(10 ^ 8)的XML文件(來(lái)自http://mattmahoney.net/dc/textdata.html的enwik8.zip)來(lái)比較編解碼器運行時(shí)間及其壓縮大小，具體測試結果見(jiàn)表4.3。

表4.3 100 MB文本文件上壓縮編解碼器的性能比較

運行測試

當進(jìn)行評估時(shí)，我建議使用自己的數據進(jìn)行測試，最好是在類(lèi)似于生產(chǎn)節點(diǎn)的主機上執行測試，這樣就可以很好地理解編解碼器的預期壓縮和運行時(shí)間。

要確保集群已啟用本機編解碼器，你可以通過(guò)運行以下命令來(lái)檢查：

$ hadoop checknative -a

空間和時(shí)間的結果說(shuō)明了什么?如果將盡可能多的數據壓入集群是首要任務(wù)，并且允許較長(cháng)的壓縮時(shí)間，那么bzip2可能是適合的編解碼器。如果要壓縮數據但要求在讀取和寫(xiě)入壓縮文件時(shí)引入最少的CPU開(kāi)銷(xiāo)，則應該考慮LZ4。任何尋求壓縮和執行時(shí)間之間平衡的企業(yè)都不會(huì )考慮bzip2的Java版本。

拆分壓縮文件很重要，但必須在bzip2和LZOP之間進(jìn)行選擇。原生bzip2編解碼器不支持拆分，Java bzip2 time可能會(huì )讓大多數人放棄。bzip2優(yōu)于LZOP的唯一優(yōu)勢是其Hadoop集成比LZOP更容易使用。

圖4.4 單個(gè)100 MB文本文件的壓縮大小(較小的值更好)

圖4.5單個(gè)100 MB文本文件的壓縮和解壓縮時(shí)間(較小的值更好)

雖然LZOP似乎看起來(lái)是最優(yōu)的選擇，但還是需要做一些改進(jìn)，正如下文所述。

總結

最適合的編解碼器取決于你的需求和標準。如果不關(guān)心拆分文件，LZ4是最有前途的編解碼器，如果想要拆分文件，LZOP就是最應該關(guān)注的。

此外，我們還需要考慮數據是否需要長(cháng)期存儲。如果長(cháng)時(shí)間保存數據，你可能希望最大限度地壓縮文件，我建議使用基于zlib的編解碼器(例如gzip)。但是，由于gzip不可拆分，因此將它與基于塊的文件格式(如Avro或Parquet)結合使用是明智的，這樣數據仍然可以拆分，或者調整輸出大小使其在HDFS中占用一個(gè)塊，這樣就不需要考慮是否可拆分。

請記住，壓縮大小將根據文件是文本還是二進(jìn)制而有所不同，具體取決于其內容。要獲得準確的數字，需要針對自己的數據運行類(lèi)似的測試。

對HDFS中的數據進(jìn)行壓縮有許多好處，包括減小文件大小和更快的MapReduce作業(yè)運行時(shí)。許多壓縮編解碼器可用于Hadoop，我根據功能和性能對它們進(jìn)行了評估。接下來(lái)，讓我們看看如何壓縮文件并通過(guò)MapReduce，Pig和Hive等工具使用它們。

使用HDFS，MapReduce，Pig和Hive進(jìn)行壓縮

由于HDFS不提供內置的壓縮支持，因此在Hadoop中使用壓縮可能是一項挑戰。此外，可拆分壓縮不適合技術(shù)水平不高的初學(xué)者，因為它并不是Hadoop開(kāi)箱即用的功能。如果正在處理壓縮到接近HDFS塊大小的中型文件，以下方法將是在Hadoop中壓縮優(yōu)勢最明顯和最簡(jiǎn)單的方法。

問(wèn)題

希望在HDFS中讀取和寫(xiě)入壓縮文件，并將其與MapReduce，Pig和Hive一起使用。

解決方案

在MapReduce中使用壓縮文件涉及更新MapReduce配置文件mapred-site.xml并注冊正在使用的壓縮編解碼器。執行此操作后，在MapReduce中使用壓縮輸入文件不需要額外的步驟，并且生成壓縮的MapReduce輸出是設置mapred.output.compress和mapred.output.compression.codec MapReduce屬性的問(wèn)題。

討論

第一步是弄清楚如何使用本章前面評估的編解碼器來(lái)讀取和寫(xiě)入文件。本章詳細介紹的所有編解碼器都與Hadoop捆綁在一起，但LZO / LZOP和Snappy除外，如果想使用這三種編解碼器，需要自己下載并構建。

要使用壓縮編解碼器，首先需要知道它們的類(lèi)名，如表4.4所示。

表4.4 編解碼器類(lèi)

在HDFS中使用壓縮

如何使用上表中提到的任何一種編解碼器壓縮HDFS中的現有文件?以下代碼支持這樣做：

編解碼器緩存使用壓縮編解碼器的一個(gè)開(kāi)銷(xiāo)是創(chuàng )建成本很高。當使用Hadoop ReflectionUtils類(lèi)時(shí)，與創(chuàng )建實(shí)例相關(guān)的一些開(kāi)銷(xiāo)將緩存在ReflectionUtils中，這將加速后續創(chuàng )建編解碼器。更好的選擇是使用CompressionCodecFactory，它本身提供編解碼器緩存。

讀取此壓縮文件就像編寫(xiě)一樣簡(jiǎn)單：

超級簡(jiǎn)單。既然可以創(chuàng )建壓縮文件，那么讓我們看看如何在MapReduce中使用。

在MapReduce中使用壓縮

要在MapReduce中使用壓縮文件，需要為作業(yè)設置一些配置選項。為簡(jiǎn)潔起見(jiàn)，我們假設在此示例中使用了identity mapper和reducer：

使用未壓縮I/O與壓縮I/O的MapReduce作業(yè)之間的唯一區別是前面示例中的三個(gè)帶注釋的行。

不僅可以壓縮作業(yè)的輸入和輸出，而且中間map輸出也可以壓縮，因為它首先輸出到磁盤(pán)，最終通過(guò)網(wǎng)絡(luò )輸出到reducer。map輸出的壓縮有效性最終取決于發(fā)出的數據類(lèi)型，但一般情況下，我們可以通過(guò)進(jìn)行此更改來(lái)加速某些作業(yè)進(jìn)程。

為什么不必在前面的代碼中為輸入文件指定壓縮編解碼器?默認情況下，FileInputFormat類(lèi)使用CompressionCodecFactory來(lái)確定輸入文件擴展名是否與已注冊的編解碼器匹配。如果找到與該文件擴展名相關(guān)聯(lián)的編解碼器，會(huì )自動(dòng)使用該編解碼器解壓縮輸入文件。

MapReduce如何知道要使用哪些編解碼器?需要在mapred-site.xml中指定編解碼器。 以下代碼顯示了如何注冊上述提到的所有編解碼器。請記住，除了gzip，Deflate和bzip2之外，所有壓縮編解碼器都需要構建并在集群上可用，然后才能注冊：

現在，你已經(jīng)使用MapReduce掌握了壓縮，是時(shí)候了解Hadoop堆棧信息了。因為壓縮也可以與Pig和Hive一起使用，讓我們看看如何使用Pig和Hive鏡像完成MapReduce壓縮。

在Pig中使用壓縮

如果你正在使用Pig，那么使用壓縮輸入文件不需要額外的工作，需要做的就是確保文件擴展名map到相應的壓縮編解碼器(參見(jiàn)表4.4)。以下示例是gzips本地加密文件加載到Pig，并轉儲用戶(hù)名的過(guò)程：

寫(xiě)gzip壓縮文件是一樣的，都要確保指定壓縮編解碼器的擴展名。以下示例將Pig關(guān)系B的結果存儲在HDFS文件中，然后將它們復制到本地文件系統以檢查內容：

在Hive中使用壓縮

與Pig一樣，我們需要做的就是在定義文件名時(shí)指定編解碼器擴展：

前面的示例將一個(gè)gzip壓縮文件加載到Hive中。在這種情況下，Hive將正在加載的文件移動(dòng)到數據倉庫目錄，并繼續使用原始文件作為表的存儲。

如果要創(chuàng )建另一個(gè)表并指定需要被壓縮該怎么辦?下面的示例通過(guò)一些Hive配置來(lái)啟用MapReduce壓縮實(shí)現這一點(diǎn)(因為將執行MapReduce作業(yè)以在最后一個(gè)語(yǔ)句中加載新表)：

我們可以通過(guò)在HDFS中查看來(lái)驗證Hive是否確實(shí)壓縮了新apachelog_backup表的存儲：

應該注意的是，Hive建議使用SequenceFile作為表的輸出格式，因為SequenceFile塊可以單獨壓縮。

總結

此技術(shù)提供了一種在Hadoop中運行壓縮的快速簡(jiǎn)便方法，這適用于不太大的文件，因為它提供了一種相對透明的壓縮方式。如果壓縮文件遠大于HDFS塊大小，請考慮以下方法。

可拆分LZOP，帶有MapReduce，Hive和Pig

如果你正在使用大型文本文件，即使在壓縮時(shí)，這也會(huì )比HDFS塊大小大很多倍。為避免讓一個(gè)map任務(wù)處理整個(gè)大型壓縮文件，你需要選擇一個(gè)可支持拆分該文件的壓縮編解碼器。

LZOP符合要求，但使用它比上文示例更復雜，因為L(cháng)ZOP本身不可拆分。因為L(cháng)ZOP是基于塊的，不可能隨機搜索LZOP文件并確定下一個(gè)塊的起點(diǎn)，這是該方法面臨的挑戰。

問(wèn)題

希望使用壓縮編解碼器，以允許MapReduce在單個(gè)壓縮文件上并行工作。

解決方案

在MapReduce中，拆分大型LZOP壓縮輸入文件需要使用LZOP特定的輸入格式類(lèi)，例如LzoInputFormat。在Pig和Hive中使用LZOP壓縮的輸入文件時(shí)，同樣的原則也適用。

討論

LZOP壓縮編解碼器是僅有的允許拆分壓縮文件的兩個(gè)編解碼器之一，因此多個(gè)Reducer可并行處理。另一個(gè)編解碼器bzip2受到壓縮時(shí)間的影響導致運行很慢，可能會(huì )導致編解碼器無(wú)法使用，LZOP提供了壓縮和速度之間的良好權衡。

LZO和LZOP有什么區別?LZO和LZOP編解碼器都可用于Hadoop。LZO是一個(gè)基于流的壓縮存儲，沒(méi)有塊或頭的概念。LZOP具有塊(已校驗和)的概念，因此是要使用的編解碼器，尤其是在希望壓縮輸出可拆分的情況下。令人困惑的是，Hadoop編解碼器默認情況下將以.lzo擴展名結尾的文件處理為L(cháng)ZOP編碼，以.lzo_deflate擴展名結尾的文件處理為L(cháng)ZO編碼。此外，許多文檔似乎可以互換使用LZO和LZOP。

不幸的是，由于許可原因，Hadoop并未不捆綁LZOP。在集群上編譯和安裝LZOP非常費力，要編譯本文代碼，還請先行安裝配置LZOP。

在HDFS中讀寫(xiě)LZOP文件

如果要使用LZOP讀寫(xiě)壓縮文件，我們需要在代碼中指定LZOP編解碼器：

代碼4.3在HDFS中讀寫(xiě)LZOP文件的方法

讓我們編寫(xiě)并讀取LZOP文件，確保LZOP實(shí)用程序可以使用生成的文件(將$ HADOOP_CONF_HOME替換為Hadoop配置目錄的位置)：

以上代碼將在HDFS中生成core-site.xml.lzo文件。

現在確?？梢詫⒋薒ZOP文件與lzop二進(jìn)制文件一起使用。在主機上安裝lzop二進(jìn)制文件將LZOP文件從HDFS復制到本地磁盤(pán)，使用本機lzop二進(jìn)制文件解壓縮，并將其與原始文件進(jìn)行比較：

diff驗證了使用LZOP編解碼器壓縮的文件可以使用lzop二進(jìn)制文件解壓縮。

既然已經(jīng)擁有了LZOP文件，我們需要對其進(jìn)行索引以便可以拆分。

為L(cháng)ZOP文件創(chuàng )建索引

LZOP文件本身不可拆分，雖然其具有塊的概念，但缺少塊分隔同步標記意味著(zhù)無(wú)法隨機搜索LZOP文件并開(kāi)始讀取。但是因為在內部確實(shí)使用了塊，所以只需要做一些預處理即可，它可以生成一個(gè)包含塊偏移的索引文件。

完整讀取LZOP文件，并在讀取發(fā)生時(shí)將塊偏移寫(xiě)入索引文件。索引文件格式(如圖4.6所示)是一個(gè)二進(jìn)制文件，包含一系列連續的64-bit數字，表示LZOP文件中每個(gè)塊的字節偏移量。

你可以使用以下兩種方式創(chuàng )建索引文件，如果要為單個(gè)LZOP文件創(chuàng )建索引文件，只需要進(jìn)行一個(gè)簡(jiǎn)單的庫調用即可，如下：

shell$ hadoop com.hadoop.compression.lzo.LzoIndexer core-site.xml.lzo

如果有大量LZOP文件并且需要更有效的方法來(lái)生成索引文件，索引器運行MapReduce作業(yè)以創(chuàng )建索引文件，支持文件和目錄(以遞歸方式掃描LZOP文件)：

圖4.6中描述的兩種方法都將在與LZOP文件相同的目錄中生成索引文件。索引文件名是以.index為后綴的原始LZOP文件名。運行以前的命令將生成文件名core-site.xml.lzo.index。

接下來(lái)，我們來(lái)看看如何在Java代碼中使用LzoIndexer。以下代碼(來(lái)自L(fǎng)zoIndexer的主方法)將導致同步創(chuàng )建索引文件：

使用DistributedLzoIndexer，MapReduce作業(yè)將啟動(dòng)并運行N個(gè)mapper，每個(gè).lzo文件一個(gè)。沒(méi)有運行reducer，因此(identity)mapper通過(guò)自定義LzoSplitInputFormat和LzoIndexOutputFormat直接寫(xiě)入索引文件。

如果要從自己的Java代碼運行MapReduce作業(yè)，可以使用DistributedLzoIndexer代碼。

需要LZOP索引文件，以便可以在MapReduce，Pig和Hive作業(yè)中拆分LZOP文件。既然已經(jīng)擁有了上述LZOP索引文件，讓我們看一下如何將它們與MapReduce一起使用。

MapReduce和LZOP

在為L(cháng)ZOP文件創(chuàng )建索引文件之后，就可以開(kāi)始將LZOP文件與MapReduce一起使用了。不幸的是，這給我們帶來(lái)了下一個(gè)挑戰：現有的基于Hadoop文件的內置輸入格式都不適用于可拆分LZOP，因為它們需要專(zhuān)門(mén)的邏輯來(lái)處理使用LZOP索引文件的輸入拆分。我們需要特定的輸入格式類(lèi)才能使用可拆分LZOP。

LZOP庫為面向行的LZOP壓縮文本文件提供了LzoTextInputFormat實(shí)現，并附帶索引文件。

以下代碼顯示了配置MapReduce作業(yè)以使用LZOP所需的步驟。 我們將對具有文本LZOP輸入和輸出的MapReduce作業(yè)執行以下步驟：

壓縮中間map輸出還將減少MapReduce作業(yè)的總體執行時(shí)間：

可以通過(guò)編輯hdfs-site.xml輕松配置集群以始終壓縮map輸出：

每個(gè)LZOP文件的拆分數量是文件占用的LZOP塊數量的函數，而不是文件占用的HDFS塊數量函數。

Pig和Hive

Elephant Bird，一個(gè)包含與LZOP一起工作的實(shí)用程序的Twitter項目，提供了許多有用的MapReduce和Pig類(lèi)。Elephant Bird有一個(gè)LzoPigStorage類(lèi)，可以在Pig中使用基于文本的LZOP壓縮數據。

通過(guò)使用LZO庫中的com.hadoop.mapred .DeprecatedLzoTextInputFormat輸入格式類(lèi)，Hive可以使用LZOP壓縮的文本文件。