摘要：eBay的CAL（Central Application Logging）系統負責收集eBay各種應用程序的日志數據，并且通過Hadoop MapReduce job生成日志報告，應用程序開發人員與運維人員通過報告可獲得以下內容：

• API調用響應時間的百分位值

• 服務調用關系

• 數據庫操作

eBay每天產生PB量級的CAL日志，其數據量每天都在增加。對于日益增長的數據量，Hadoop MapReduce job的優化將會大大節省計算資源。本文將分享eBay團隊如何對這些Hadoop job進行優化，希望為開發者帶來啟發，解決Hadoop MapReduce（MR）job實踐中存在的問題。

?為什么要優化??

CAL報告的Hadoop job現狀如下：

?

• 數據集：CAL每天的日志量為PB量級，并以每年70%的速度增加，CAL收集的日志來自不同的應用程序，其日志的內容也有所不同。有些屬于數據庫操作密集型，有些則包含著復雜的嵌套事務，且每個應用程序日志的數據量差異大。

  ?

• 計算資源：CAL使用的是共享Hadoop集群。優化前，CAL Hadoop job需要使用約50％整個集群的資源才能完成。CAL報告Hadoop job在一天中，其中有9個小時只能使用19%的集群計算資源，不能在這段時間獲得資源執行的job將會等待在隊列中，直到這9小時結束，它才能有80%的集群計算資源可以使用。

  ?

• 成功率：CAL MapReduce job的成功率僅92.5％。

?

?eBay團隊如何優化?

在分享我們的經驗之前，我們先簡單介紹Hadoop MapReduce的流程。

?

Hadoop MR job一般分為五個階段，即CombineFileInputFormat, Mapper, Combiner, Partitioner, 以及Reducer。

我們的優化工作主要從執行時間和資源使用兩方面考慮。

?

1） 執行時間

?

Hadoop job的執行時間取決于最慢的Mapper任務和最慢的reducer任務的時長。?

假設：

• ：Map任務執行時間

• ?：Map任務個數

• ：Reduce任務執行時間

• ?: Map任務個數

?

那么，MR job執行時間 T則可表示為：

Map任務的執行時間與Map任務的輸入記錄個數、輸出記錄個數成正比。

?

此外，Hadoop job的計算復雜度也會影響Hadoop job的執行時間。同時對于某些極端的job，我們應關注job的GC時間。

?

綜上所述，我們從以下三個方面來減少Hadoop的執行時間：

• ?GC時間?

• ?盡量避免Mapper和Reducer的數據傾斜

• ?優化算法

2）資源使用

?

考慮到內存的資源使用，假設：

• ?:?MR job中的Mapper容器內存大小

• :?Reducer容器內存大小

• ：MR job中的應用程序管理器容器內存大小

• ?: MR job中，Mapper任務個數

• ：Reducer任務的個數

?

那么, Hadoop job的內存資源使用量R與Mapper/Reducer任務的執行時間成正比，可表示為：?

因此，為了降低資源使用，我們可以從以下幾個方面下功夫：

• 減少Map或Reduce任務個數

• 減少Map或Reduce任務容器大小

• 優化job的執行時間

?

解決方案

?

? 1.?GC

GC是我們遇到的很明顯的問題。job失敗的原因通常是“GC overhead”或“Out of Memory”。即便job成功了，通過Hadoop job計數器,可以看到其GC時間也很長，同時GC也會消耗大量的CPU資源。

?

1)? Mapper中的GC

?

所有發到CAL的日志，都會使用CALrecord的數據結構。CAL事務是由多個CALrecord組成的邏輯概念。

?

CAL事務一般可以對應到用戶的請求上。當應用程序對用戶的請求作出響應時，應用程序都會記錄CAL事務到CAL服務，而為了完成用戶請求，這個CAL 事務往往會調用多個子CAL事務協同完成。也就是說，CAL 事務是一個樹狀結構，每個CAL事務都是這個樹狀結構的一個節點，而報告中需要的指標（Metrics）需要讓每個節點知道其根節點信息，而在構建這個樹狀結構的過程中，節點是無序的。因此，需要保留所有節點信息以便幫助后來節點追溯其根節點。

?

例如，下圖展示了典型的樹狀事務層次結構。CAL事務 F是根。它會調用B和G來處理用戶請求。如果我們已經有了F、 B、 C，C要等到D節點出現，才能找到根 F。同時，這棵樹上的所有節點都需要保存在內存中，否則其子節點將不能找到其根。

?

顯然，這種情況沒有清理機制，會導致OOM。為了解決這個問題，從日志的業務邏輯上，CAL事務應該具有時間窗屬性，涉及同一個用戶請求的所有CAL事務都應該發生在一個時間窗內。如果時間窗為t，并且CAL 事務的開始時間戳為ts，則所有子CAL事務應在ts + t之前發生。

?

在我們的實驗中，我們假設時間窗為5分鐘。我們對12個日志量最大的應用程序的日志數據來驗證此假設。即，若現在正在處理數據時間戳為ts的CAL事務，則時間戳在ts-5分鐘之前的 CAL事務都將從內存中移除。12個應用程序日志中，有10個可以保證幾乎100％的準確性。同時，其他2個應用程序，此功能將會影響其正確性，我們對其設置了白名單，暫時不對其做處理。

?

時間窗口的設置有效地減少了Hadoop job執行時間，并將其成功率從93％提高到97％。

?

CAL日志與指標

?

優化之前，Mapper在處理一個CAL事務的時候，將組成該事務的CAL record完全讀取到內存中，然后提取出CAL事務有關的所有指標，如上圖左側所示。而CAL事務的原始信息并不完全需要保存在內存中，我們只需要保存必要的指標即可，如上圖右側所示。

?

Combiner可以減少Mapper和Reducer任務之間的數據傳輸。在實際應用中，由于Mapper的輸出數據量很大，Hadoop對Mapper的輸出數據做排序時，將帶來較長的GC。我們的解決方案是在Mapper端使用Combiner做預處理，減少Mapper與Reducer間的傳輸數據量，有效降低執行時間。?

?

2)? Reducer中的GC

?

Reducer與Mapper具有類似的GC問題。

?

用于生成CAL報告的Hadoop job輸出兩種類型的數據——15分鐘粒度的指標數據和用1小時粒度的指標數據。其中Mapper負責將日志映射為對應的指標，指標格式為三元組<時間戳，指標名稱，指標的值>，其中時間戳粒度為15分鐘，當Mapper將這些信息發送給reducer時候<時間戳，指標名稱>將作為鍵值，<指標的值>作為值，在reducer中，將不同Mapper任務輸出的指標聚合（如計數，求和等），聚合的結果包括15分鐘和1小時兩種粒度。

?

在MR中，Reducer收到的數據，Hadoop將根據其鍵值排好順序。優化前，Mapper發送給Reducer的數據以“時間戳+指標名稱”作為鍵值，Reducer收到的數據格式和順序如下圖左側部分：

?

Reducer 收到的數據

?

當計算指標Metrics1一小時粒度的值時，需要得到當前小時最后15分鐘（Timestamp4）的數據，并保存Metrics1的其他時間的數據。即為了計算N個指標的一小時粒度的值，需要保存3N條數據在內存中。當N很大時，內存溢出在所難免。

?

為了解決這個問題，我們將鍵值從“時間戳+指標名稱”調整為“指標名稱+時間戳”。為了計算指標Metrics1的一小時粒度的值，我們僅需保存3條數據在內存中，解決了Reducer中內存過量使用導致的問題。

?

該方法解決了Reducer中的問題，并增強了Reducer的可擴展性。

?

?2. 數據傾斜

?

在檢查Hadoop job里map任務和reduce任務時，我們發現一個Job中的多個map任務的執行時間從3秒到超過1小時不等。Reducer任務也有類似的問題。

?

由之前章節中的公式，我們將輸入記錄平均分配給Mapper或Reducer，以最小化和?。

?

CombineFileInputFormat可以幫助解決Mapper中的數據傾斜問題。之前，CAL MR job沒有使用CombineFileInputFormat，使用CombineFileInputFormat后，其將多個小文件合并成一個分片，分片大小設置為256MB，每個Mapper處理一個分片，這使Mapper任務數量減少到之前的一半。

?

Partition能夠處理Reducer中的數據傾斜問題。在CAL報告中存在著兩個概念，一是報告名稱，二為指標名稱。對于每種報告，都有多個指標。優化前，分區策略是使用報告名稱的哈希值?，F在，使用報告名稱和指標名稱的哈希值作為分區策略，極大的改善了數據傾斜的狀況。

?3. 優化算法

?

在Hadoop job執行時間的公式中，job執行時間與輸入記錄個數成正比。實驗中，有兩個數據集。數據集A為20MB，數據集B為100MB。數據集A的MR job需要90分鐘才能完成。以B作為輸入的job僅需8分鐘就能完成。

?

分析CAL日志內容，有兩種類型的日志：SQL日志和事件日志。SQL日志即數據庫操作有關的日志。事件日志可能會引用SQL日志，而解析SQL日志則更為耗時。

?

因此，我們計算了A和B中的SQL日志數目，結果顯示它們的數目接近。而在A中，引用了SQL的事件日志數目更多。顯然，對處理引用了SQL的日志上，出現了一些重復的計算——每次引用都會重新解析被引用的SQL日志。為了解決這個問題，我們緩存了SQL的解析結果，在引用時直接使用緩存結果。優化之后，A的job可以在4分鐘內完成。

?

優化結果

?

通過以上三個方面的優化，除了執行時間，任務的資源使用情況也得到了優化。

?

在優化之前，CAL報告job需要Hadoop集群中50％的資源才能執行完成。優化后，只需19%的資源就能執行完成。下圖顯示了Hadoop Cluster上的內存資源使用情況。左側是優化前的情況，右側是當前的情況。

?

Hadoop Eagle中的資源使用情況

?

Hadoop Eagle中的計算資源使用率

?

Job的成功率從92.5％增加到約99.9％。從 Hadoop平臺服務質量考慮，Hadoop 將會終止執行時間超過1小時的job，而部分應用程序的數據需要更復雜的計算，所以很難在1小時內完成。優化后95分位的Hadoop job執行時間約為40分鐘，遠低于優化前的90分鐘。

?

CAL報告MR job執行時間趨勢

?

本次優化后，我們節省了超過60％的相對計算資源，相當于Hadoop集群中大約200個Hadoop節點，并且Job的成功率增加到99.9％。

?

總? ?結

?

當對線上項目做優化工作時，應始終關注數據質量。因此，在優化之前，應最先制定驗證方案，使用具有冪等屬性的數據來驗證數據質量。

?

同時監控也是優化工作的重點——我們把所關心的KPI，如成功率、資源使用情況和job執行時間收集起來，有助于優化過程中觀察優化效果。

?

最后，非常感謝eBay Hadoop team提供的支持與幫助，其中Hadoop技術專家金瀾濤與徐冰泉深入分析用戶場景，提出了很多非常有價值的建議和解決方案，使優化工作順利進行，而Job優化不但可以讓CAL提供更好的報告服務，也對Hadoop平臺的穩定性與資源使用帶來好處，是團隊合作很好的實踐。

總結

以上是生活随笔為你收集整理的eBay | 实践Hadoop任务的性能翻倍之路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。