提高資源利用率的MapReduce框架

Hadoop系統提供了MapReduce計算框架的開源實現，像Yahoo!、Facebook、淘寶、中移動、百度、騰訊等公司都在藉助 Hadoop進行海量數據處理。Hadoop系統性能不只取決於任務調度器的分配策略，還受到分配後實際任務執行效率的影響，任務執行經常涉及讀取、排序、歸併、壓縮、寫入等具體階段。

HCE計算框架是一個開源項目，旨在經過優化任務執行的各個階段，提高整個Hadoop系統的效率。與Hadoop Java框架相比，基於HCE框架的MapReduce任務最高能夠節省超過30%的CPU資源使用。

圖1 Hadoop生態系統中的HCE計算框架

 

圖1給出了HCE框架在Hadoop生態系統中所處的位置。對於OLTP系統來講，用戶經過Web前端生成相應請求，請求通過中間件處理，做爲數據進入數據庫或者K-V存儲系統中，同時會產生日誌。OLTP系統產生的數據和日誌都會做爲分析系統的輸入，對於搜索引擎和廣告系統來講，天天的日誌會輕鬆超過TB。日誌和業務數據通常會存放到海量存儲系統HDFS文件系統或者K-V存儲系統中，分佈式計算框架MapReduce通常會基於存儲系統之上。天天會執行成千上萬的MapReduce做業進行海量數據處理，產生的結果會有三個去處：存放於海量存儲系統以備後續使用；導入用於產生報表或分析的數據庫；做爲OLTP系統的輸入，導入線上存儲中。MapReduce做業通常由內部用戶經過Hadoop原生客戶端、Pig/DISQL語言客戶端或者 Hive數據倉庫三種方式進行提交，做業執行結果能夠經過SQL客戶端查詢。

問題

愈來愈多的公司開始使用Hadoop及其周邊系統進行海量數據分析，Yahoo!和Facebook的Hadoop集羣節點數已通過萬，而且節點增加的趨勢不減，國內公司如騰訊和百度等也面臨着一樣的問題。不斷增加的業務需求和業務數據致使的集羣資源緊缺是集羣不斷擴容的主要緣由，CPU資源（注：存儲資源緊缺的解決方案之一是開啓重量級的壓縮（如Facebook），這涉及CPU資源的使用）又是其中最爲緊缺的。爲了控制成本，優化集羣資源利用率勢在必行。

對於分佈式計算層面，資源優化有兩個途徑：一是經過精細化的資源調度來保證全局資源的最大化利用，這一般涉及合理的資源調度算法和輕量級的資源隔離；二是經過優化計算任務和用戶程序來提高原有計算做業的資源使用率。HCE計算框架主要關注後者。

跨平臺、高擴展、通用接口的計算框架也帶來了額外開銷

分析Hadoop MapReduce計算框架，已有實現能夠再作權衡。

MapReduce框架經過Java語言高效實現，保證了其跨平臺的兼容性；不過國內互聯網公司通常都使用Intel x86平臺，兼容性的優點很可貴以體現，所以能夠選擇優於Java性能但不支持跨平臺的語言來實現MapReduce框架。

爲了最大化可擴展性（Extensibility），Hadoop實現了多層級的數據處理流封裝，這使得Java框架在大數據處理時存在一些性能損耗，實際上能夠實現更加直接的數據處理路徑來提高處理效率。

國內互聯網公司的工程師們大多使用C++進行功能開發或腳本語言來處理文本，Java接口對於他們而言是比較麻煩的事情。Hadoop提供了 Streaming編程接口，容許用戶程序能夠經過媒介——標準輸入輸出來和計算框架交互數據，也即繞開了語言的限制，所以不少用戶任務是經過 Streaming接口啓動的。Streaming接口的優點在於支持多語言開發，而增長通用性帶來的是性能的損耗，即數據拷貝管道和Key切分開銷（大約2%～5%），而且不如原生態的語言接口更加適宜編程。

用戶程序在計算框架控制以外

圖2 MapReduce任務執行框架示意圖

 

除了框架的開銷，計算任務的資源佔用還包括用戶程序。如圖2所示，Hadoop Streaming和Pipes框架支持C++用戶開發MapReduce 應用程序，框架啓動用戶可執行程序，框架和用戶程序分別處於兩個進程，分別佔用資源。簡單的分析程序不會佔用太多的CPU資源，即用戶程序在整個計算任務執行時間中所佔比例不大，此時，優化計算框架會帶來比較可觀的收益；不過，對於複雜的分析程序而言，用戶程序所佔時間遠遠超過計算框架，此時，優化計算框架帶來的收益可能微乎其微。所以，節省集羣CPU資源離不開優化用戶程序。

優化用戶做業能夠分爲兩個層面，一是經過較高層次的統一入口讓用戶提交做業，例如使用數據倉庫Hive的用戶不會操做 Hadoop MapReduce的API，在Hive內部統一作優化，包括一些靜態或者動態方法，調整用戶做業參數，使任務利用最少資源高效執行；二是優化直接操做MapReduce API的用戶做業，固然Hive也屬於這個範疇。設想用戶做業或者數據倉庫是經過C++語言實現的，編譯由用戶實施，平臺僅僅經過接口調用用戶的可執行程序，那麼此時想要優化用戶程序會比較困難。有動態和靜態兩種優化方式：動態優化方式（注：詳情參見 Starfish: A Selftuning System for Big Data Analytics (CIDR’11)）是在 MapReduce上新增一層，經過profiler和sampler等技術動態調整做業參數；靜態優化方式是讓用戶用編譯時依賴框架提供的頭文件和庫文件，經過編譯優化技術提高用戶程序性能。

解決

HCE計算框架經過靜態優化計算框架和用戶程序來提高計算任務的CPU使用率。如圖2所示，將框架和用戶程序整合到一個進程，能夠經過同一套編譯機制同時優化框架和用戶程序，Key-Values處理也處於同一個進程空間，不用藉助媒介（管道或套接字）來傳遞。HCE和Hadoop提供的用戶編程接口如表1所示。

表1 MapReduce框架各用戶接口對比

 

計算框架高效C++實現

HCE框架經過C++語言實現了MapReduce的數據處理邏輯，依託比Java性能更優的C++語言，能夠在數據處理操做上得到更佳的CPU利用率，同時也能夠更加直接地調用Native Lib而非經過JNI（注：壓縮庫是Native實現，Hadoop經過JNI來調用壓縮方法，HCE壓縮在一個進程空間執行）；此外，經過高效的編譯優化方法，例如ICC編譯器等，能夠進一步挖掘框架的性能優點。

HCE框架經過精簡的方式實現了MapReduce的數據處理流程，比較多層次的Java流式封裝，HCE的處理流程更加高效。

HCE框架提供了多種語言接口C++、Python等，方便了用戶編程，也節省了Streaming接口的額外開銷；同時HCE也提供徹底兼容原有Java Streaming的接口，即原有做業能夠無縫遷移到HCE框架。

用戶程序靜態編譯優化

HCE框架採用的是靜態優化用戶程序的方式，動態優化交給上層的數據倉庫去作。對於那些CPU負載較重的用戶程序，HCE提供C++編程接口給用戶，用戶編譯本地程序須要依賴框架的頭文件和庫文件，頭文件中內置瞭如SSE等優化代碼，可使得用戶程序在編譯時被優化。這種簡單的方式可以使得用戶程序的執行效率大幅提高。

框架

HCE框架實現了Hadoop支持的功能組件，例如在C++空間中支持Text或者SequenceFile格式的RecordReader和 RecordWriter，也支持Gzip、Lzo、QuickLz、Lzma等4種壓縮格式。因爲輸入文件切分是在Hadoop Client實施的，因此Split方法仍是在Java空間執行的；固然，用戶定義的Mapper和Reducer必須在C++空間實現，例如Hive想要基於HCE框架執行，那麼就必須實現C++版本的Mapper、Reducer等功能組件。

圖3 HCE框架數據處理流程圖

 

圖3展現了HCE框架的數據處理流程，能夠看出HCE框架在C++空間高效實現了多個可擴展的功能模塊，如RecordReader、 OutputCollector、Shuffle、ReduceInputReader、RecordWriter、Committer、 Partitioner、Mapper、Reducer、Combiner等，處理邏輯比Hadoop MapReduce更加緊湊高效。處於 Hadoop Java空間的MapRunner和ReduceRunner只是起到收集狀態信息的做用。

HCE框架的性能提高主要集中在Map階段，大約超過40%。對於通常的MapReduce程序，相比Shuffle和Reduce階段，Map階段也是其資源佔用最多的階段，由於最終做業的輸出通常僅僅是輸入的10%，大量的數據處理是在Map階段完成的。

拓展

僅有基本的HCE框架是不夠的，由於大量已有做業是經過Streaming接口執行的，並且除C++開發接口以外，腳本開發者也想使用對應語言的開發接口。幸運的是，全部腳本語言都基於C開發，所以能夠實現簡單的解釋器，將腳本語言翻譯成C語言，最終執行的還是HCE框架，而這個解釋開銷很小。固然，Streaming做業的額外開銷是不可避免了，不過基於HCE框架的Streaming做業能夠利用框架的性能優點得到CPU利用率的提高，這對於輕量級做業收益仍然可觀。

圖4展現了Java Streaming、HCE、Streaming Over HCE和Python Over HCE四個框架的數據處理途徑。Java Streaming框架的數據處理仍然是在Java空間完成的，而HCE、Streaming Over HCE、 Python Over HCE框架的數據處理都在C++空間完成，Child JVM僅從HCE進程收集任務狀態信息。

圖4 Streaming Over HCE和Python Over HCE框架示意圖

將來

MapReduce計算框架並不只僅依賴於HDFS存儲系統，也能夠基於其餘存儲系統，例如Hypertable或者是其餘的K-V系統。目前不少塊存儲系統或K-V系統都是C++語言實現的，想要在其上使用原生態的Hadoop MapReduce，就必須經過存儲系統的語言轉換接口（例如 Hypertable的Thrift）或者計算系統的轉換接口（例如Hadoop的AvroRPC等），問題是數據的序列化和反序列化不免帶來額外開銷。所以，基於HCE框架、非Java語言實現的存儲系統能夠更加高效地支持Hadoop MapReduce計算，固然它們須要實現對應的Split、 RecordReader、RecordWriter和Committer等組件。

小結

HCE框架是Hadoop MapReduce框架的一個衍生品。依託HCE框架的高效本地處理機制，Hadoop做業能夠最多節省30%的CPU 資源使用。此外，HCE提供了C++、Python等多種編程接口，而且保證了已有接口的向前兼容；多種編譯優化技術也能夠方便地應用到 MapReduce框架；最後，HCE經過編譯優化和內置解釋器等方式優化了用戶程序的執行。