Hadoop小文件解決方案-基於文件整合的解決方案

經過研究一些不太經常使用的替代方案來解決MapReduce性能問題以及選擇解決方案時要考慮的因素。

解決MapReduce性能問題

---

如下解決方案來緩解MapReduce性能問題：

• 更改攝取過程/間隔
• 批處理文件合併
• 序列文件
• HBase
• S3DistCp（若是使用Amazon EMR）
• 使用CombineFileInputFormat
• Hive配置
• 使用Hadoop的附加功能

已經討論過更改攝取過程，批處理文件合併和序列文件。

Hbase

---

若是要生成大量小文件，將數據做爲文件存儲在HDFS中可能不是最佳解決方案。相反，您能夠考慮使用HBase列存儲。使用HBase能夠將攝取過程從生成許多小型HDFS文件更改成將單個記錄寫入HBase表。若是您的數據訪問模式基於明肯定義的隨機訪問查找，則HBase多是您的最佳選擇。它在架構上針對高速數據記錄插入，大容量，單個記錄查找和基於流的分析進行了調整。可是，若是您的數據訪問模式傾向於完整文件/表掃描，那麼HBase可能不是最佳的。

能夠建立映射到HBase數據的Hive表; 可是，此設計中的查詢性能會有所不一樣。當選擇單行或一系列行時，HBase上的Hive會閃爍，但若是您的查詢傾向於全表掃描，則HBase的效率很是低。大多數分析查詢，尤爲是那些使用group by的查詢，都須要進行全表掃描。

HBase提供了將數據流式傳輸到Hadoop並使其可實時處理的最佳能力。可是，平衡HBase與其餘集羣進程的需求可能具備挑戰性，而且須要高級系統管理。此外，HBase性能在很大程度上取決於數據訪問模式，在選擇HBase解決小文件問題以前，應仔細考慮這些模式。

S3DistCp

---

此解決方案僅適用於Amazon EMR的用戶。Amazon EMR集羣的生命週期很短，將數據保存在Amazon S3中。即便使用Amazon S3，處理大量小文件仍然會致使啓動沒必要要的map任務，從而下降性能。

S3DistCp是亞馬遜提供的一種實用程序，用於將數據從S3分發複製到臨時HDFS甚至其餘S3存儲桶。該實用程序提供了經過使用groupBy和targetSize選項將文件鏈接在一塊兒的功能。當您在S3中存儲了數千個要使用Amazon EMR處理的小文件時，這很是有用。S3DistCp經過鏈接許多小文件並使它們出如今更快，短暫的HDFS存儲中，一箭雙鵰。據報道，使用這種機制能夠提升15倍的性能。

出於全部實際目的，S3DistCp執行與提到的批處理文件合併方法相同的任務。若是使用Amazon EMR，請注意您有一個預先構建的工具來完成此任務。

使用CombineFileInputFormat

---

CombineFileInputFormat是Hadoop提供的抽象類，它在MapReduce讀取時合併小文件。合併的文件不會持久保存到磁盤。相反，該過程讀取多個文件並「動態」合併它們以供單個map任務使用。您能夠得到不爲每一個文件啓動一個map任務的好處，而且不須要將多個文件合併到一個持久文件中做爲準備步驟的一部分。這解決了MapReduce做業啓動太多map任務的問題; 可是，因爲做業仍在讀取多個小文件，所以隨機磁盤IO仍然存在問題。此外，CombineFileInputFormat的大多數實現都不考慮數據局部性，而且一般會經過網絡從各類數據節點提取數據。

爲了實現這一點，必須在Java中爲不一樣的文件類型擴展CombineFileInputFormat。這須要大量的開發專業知識來開發您的自定義輸入格式類。可是，一旦編寫，您能夠配置最大分割大小，它將合併文件，直到知足此大小。

請注意，因爲合併數據不會在HDFS中保留，所以CombineFileInputFormat不會緩解NameNode內存問題。

Hive配置

---

若是您注意到Hive經過「create table as」或「insert overwrite」語句在Hadoop集羣中建立小文件，則能夠調整一些Hive特定配置設置以進行緩解。使用時，這些設置會告訴Hive將建立的任何小文件合併到較大的文件中。可是，有一個懲罰。Hive將啓動一個額外的MapReduce做業後查詢，以執行合併。此外，在Hive向用戶指示查詢已完成處理而不是異步發生以前完成合並。

應該注意，這些設置僅適用於由Hive建立的文件。例如，若是使用其餘工具（如Sqoop）在Hive外部建立文件，則使用hdfs fs -mv命令將其複製到Hive表中，Hive將不會合並文件。所以，當攝入Hadoop的文件很小時，此解決方案不起做用。此解決方案僅建議在以Hive爲中心的體系結構中，其中insert overwrite和create table as語句中的小性能損失是可接受的。

要使用的設置是：

使用Hadoop的附加功能

---

附加多是可用的，但Hadoop生態系統中的主要工具都不支持它：Flume，Sqoop，Pig，Hive，Spark和Java MapReduce。MapReduce強制執行一條規則，即MapReduce做業的輸出位置在執行以前不得存在。因爲這個規則，MapReduce顯然不可能經過其輸出附加到預先存在的文件。因爲Sqoop，Pig和Hive都使用了MapReduce，所以這些工具也不可能支持追加。Flume不支持追加很大程度上是由於它假設通過一段時間（不管是秒，字節，事件數或不活動秒），Flume將關閉文件而再也不打開它。Flume社區認爲這足夠，而不是要求追加支持。

若是你真的必須在Hadoop中使用appends，你必須編寫本身的系統來執行攝取並附加到現有文件。此外，若是您的任何羣集內處理須要附加到現有文件，您將沒法使用Spark或MapReduce。所以，使用HDFS附加功能很是複雜，只能由技術最精湛的組織使用。若是沒有重要的工程團隊和支持承諾，則不建議使用此選項。

選擇解決方案

---

選擇使用小文件的最佳解決方案取決於各類問題。可能有必要根據訪問模式和數據要求使用這些解決方案的組合。應該考慮的問題包括：

• 數據流中的哪一點是生成的小文件？是在攝取時仍是經過羣集內處理建立小文件？
• 生成小文件的工具是什麼？更改工具配置能夠減小小文件的數量嗎？
• 您的組織有多少技術技能？您是否有能力維護輸入格式或編寫本身的攝取引擎？
• 生成小文件的頻率是多少？爲了建立大文件，能夠多久合併一次小文件？
• 這些小文件須要哪一種數據訪問？這些文件是否須要經過Hive訪問？
• 能夠在集羣內部運行流程以減輕小文件的管理週期類型？
• MapReduce流程可接受的延遲級別是多少？