【Uber大數據供應端省錢術】落實機器記帳是設備省錢第一步，更要善用大容量硬碟和負載機制

儲存和運算設備的成本是Uber大數據平臺最大的成本來源，在Uber大數據省錢術中，如何提高用來執行大數據工作負載的硬體成本效益，就是第一步，也就是先從大數據平臺供應端著手。

Uber手上的大數據資料量高達數百PB之多，所部署的Hadoop叢集、Hive叢集、Spark叢集、Kafka叢集、Presto叢集到Flink叢集的規模，都是全球最大規模的叢集。要降低硬體資源的成本，Uber第一步想到的作法就是採用容量更大也更便宜的傳統硬碟。

因為大數據運算大多是循序讀取，而非隨機存取，傳統硬碟仍然是高容量和IOPS高比值的好選擇，但唯一的問題是，超大容量硬碟會削弱了每TB可用的IOPS，可能進一步對應用程式效能帶來不利的影響。

Uber的HDFS叢集用了數千臺儲存主機，每一臺主機上都有數十顆傳統硬碟（簡稱HDD），這些機器混用了2TB、4TB、8TB和16TB容量的傳統硬碟，平均容量是4TB。Uber透過使用數據發現，只要善用負載平衡，就可以舒緩儲存主機滿載或IOPS滿載時對應用程式效能的影響。

Uber改善負載有幾項秘訣，一是主動預測HDFS區塊的資料熱度（存取頻繁度）。分析HDFS區塊建立時間，建立位置，HDFS資料結構和歷史存取模式，來找出區塊未來的資料熱度，提前先將熱區塊的資料，改放到IOPS利用率較低的主機上，來避免IOPS塞車。其次是，進行「讀取時間的負載平衡」作法，因為Uber的HDFS檔案都會儲存3份，傳統做法上，Namenode會選擇任一個Datanode作為讀取來源。一般以為透過叢集負載平衡機制，每一個硬碟的工作負載應該一樣，其實不然，根據Uber實測，要在很短時間讀取大量資料時，將3份資料分散到1,000個節點上的1,000顆硬碟時，Uber發現，37%硬碟竟然沒有任何負載，而忙碌的硬碟卻會有5倍或更多請求，Uber修正做法，先紀錄每一個Datanode的存取次數，當要讀取資料時，就避開儲存在忙碌硬碟上的那一份，改從其他兩份資料讀取。這個簡單的修正，可以明顯減少出現少量熱機的情況。同樣的做法也可以套用在「寫入時間負載平衡」，來避開寫入頻寬的區塊，改寫入如其他閒置硬碟上的區塊。
透過這些負載平衡的調整，Uber就可以在HDFS叢集上大量運用16TB容量超大硬碟，不只減少了每TB的成本，更重要的也降低了叢集所需主機設備的數量，也等於可以減少每TB所耗的電力。另外，就算搭配Hadoop 3.0的糾刪碼演算法，將3份資料量，減少到1.5倍，上述做法也同樣有效果。

原本在本地端準備三份備份的HDFS叢集，建置成本向來比雲端物件儲存貴上許多，但改將2TB,4TB,8TB硬碟都換成 16TB之後，Uber大幅縮短兩者之間的成本差距。

兩大專案善用閒置運算資源

除了改用便宜超大硬碟，Uber還發起了兩大善用閒置硬體資源的專案，來提高供應端的成本效益，一個是專案是善用HDFS節點上的閒置CPU和記憶體。因為有充沛網路頻寬，可以把HDFS儲存和資源管理的YARN放在不同的機櫃，讓儲存和運算各自獨立擴充，來因應不同的需求，但這個架構需要在HDFS節點上準備大量備用的CPU和記憶體，遠超過了Datanode的需求。因此，Uber將部分YARN的Nodemanager放到這些運算力充裕的儲存節點上，來減少對運算用節點的需求。

另一個專案則是善用線上服務主機上的閒置資源。Uber將線上服務中的閒置主機（用量低的主機），挪出一部分來支援大數據平臺的備援支用，在那些線上服務中安插一部分的大數據平臺的備援服務，只要掌握了線上服務用量的周期性，就能善用離峰時的運算資源來支援大數據運算。

除此之外，Uber後來發現，光是做好機器記帳（Machine Accounting），清楚計算每一臺機器的分配和回收，就可以提高不少效益。因為過去幾年快速發展，Uber累積了大量獨立系統，有開發環境，測試環境，POC叢集等各式各樣的環境，甚至有些環境過度分配資源，或者用完沒有回收。「不只Uber，很多快速成長的企業，都會遇到這類的問題。」Uber大數據平臺資深主任工程師Zheng Shao強調。

Uber後來設計了集中式儀表板，可以從不同維度來看我們龐大硬體設備的利用情況透過這一組儀表板，半年內，就從好幾個團隊中，釋出了上千臺他們不用的機器。

 Uber大數據供應端省錢術 

1. 全面改用便宜的超大容量硬碟

2. 主動預測HDFS區塊的資料熱度

3 讀取時間和寫入時間的負載平衡

4. 善用HDFS節點上的閒置CPU和記憶體

5. 善用線上服務主機上的閒置資源

資料來源：Uber，iThome整理，2022年2月

 相關報導