當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

eBay | 实践Hadoop任务的性能翻倍之路

發(fā)布時間：2024/2/28 编程问答 25 豆豆

生活随笔收集整理的這篇文章主要介紹了 eBay | 实践Hadoop任务的性能翻倍之路小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

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

API調用響應時間的百分位值
服務調用關系
數(shù)據(jù)庫操作

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

?為什么要優(yōu)化??

CAL報告的Hadoop job現(xiàn)狀如下：

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

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

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

?eBay團隊如何優(yōu)化?

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

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

我們的優(yōu)化工作主要從執(zhí)行時間和資源使用兩方面考慮。

1）執(zhí)行時間

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

假設：

：Map任務執(zhí)行時間
?：Map任務個數(shù)
：Reduce任務執(zhí)行時間
?: Map任務個數(shù)

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

Map任務的執(zhí)行時間與Map任務的輸入記錄個數(shù)、輸出記錄個數(shù)成正比。

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

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

?GC時間?
?盡量避免Mapper和Reducer的數(shù)據(jù)傾斜
?優(yōu)化算法

2）資源使用

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

?:?MR job中的Mapper容器內存大小
:?Reducer容器內存大小
：MR job中的應用程序管理器容器內存大小
?: MR job中，Mapper任務個數(shù)
：Reducer任務的個數(shù)

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

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

減少Map或Reduce任務個數(shù)
減少Map或Reduce任務容器大小
優(yōu)化job的執(zhí)行時間

解決方案

? 1.?GC

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

1)? Mapper中的GC

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

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

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

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

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

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

CAL日志與指標

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

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

2)? Reducer中的GC

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

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

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

Reducer 收到的數(shù)據(jù)

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

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

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

?2. 數(shù)據(jù)傾斜

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

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

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

Partition能夠處理Reducer中的數(shù)據(jù)傾斜問題。在CAL報告中存在著兩個概念，一是報告名稱，二為指標名稱。對于每種報告，都有多個指標。優(yōu)化前，分區(qū)策略是使用報告名稱的哈希值。現(xiàn)在，使用報告名稱和指標名稱的哈希值作為分區(qū)策略，極大的改善了數(shù)據(jù)傾斜的狀況。

?3. 優(yōu)化算法

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

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

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

優(yōu)化結果

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

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

Hadoop Eagle中的資源使用情況

Hadoop Eagle中的計算資源使用率

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

CAL報告MR job執(zhí)行時間趨勢

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

總? ?結

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

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

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

總結

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

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