基于Hadoop的58同城離線計算平臺設(shè)計與實踐

作者：余意，來自：DataFun

本文主要內(nèi)容包括：

• 58在集群快速增長的過程中遇到的問題以及解決之道；

• 58大數(shù)據(jù)集群跨機房遷移的相關(guān)工作，如何在5個月時間快速完成3000臺集群服務(wù)的遷移工作。

▌數(shù)據(jù)平臺部簡介

數(shù)據(jù)平臺部是負責(zé)58統(tǒng)一大數(shù)據(jù)基礎(chǔ)平臺能力建設(shè)。平臺負責(zé)的工作主要包括以下幾部分：

• 數(shù)據(jù)接入：文本的收集，我們采用 flume 接入，然后用 kafka 做消息緩沖，我們基于 kafka client 打造了一個實時分發(fā)平臺，可以很方便的把 kafka 的中間數(shù)據(jù)打到后端的各種存儲系統(tǒng)上。

• 離線計算：我們主要基于 Hadoop 生態(tài)的框架做了二次定制開發(fā)。包括 HDFS、YARN、MR、SPARK。

• 實時計算：目前主要是基于 Flink 打造了一個一棧式的流式計算開發(fā)平臺 Wstream。

• 多維分析：我們主要提供兩組多維分析的解決方案。離線的使用 Kylin，實時的使用 Druid。

• 數(shù)據(jù)庫：在數(shù)據(jù)庫的這個場景，我們主要還是基于 HBase 的這個技術(shù)體系來打造了出來，除了 HBase 提供海量的 K-V 存儲意外，我們也基于 HBase 之上提供 OpenTSDB 的時序存儲、JanusGraph 圖存儲。

我們綜合以上技術(shù)框架支撐了公司上層的業(yè)務(wù)：如商業(yè)、房產(chǎn)、招聘等核心業(yè)務(wù)。 此外，整個數(shù)據(jù)平臺部打造了統(tǒng)一的運營管理平臺，各個用戶在整個數(shù)據(jù)平臺上 ( 包括離線平臺、實時平臺等 ) 使用的是同一套主賬號在管理平臺上做數(shù)據(jù)方面的管理，包括：元數(shù)據(jù)管理、成本預(yù)算、數(shù)據(jù)自助治理、以及運營監(jiān)控的一些細節(jié)。

Flume 每天的日志采集量 240T，Haddop 單集群服務(wù)器臺數(shù)4000+，F(xiàn)link 每天進行超過6000億次的計算，Druid 已經(jīng)構(gòu)建超過 600 億條實時數(shù)據(jù)索引。

▌Hadoop 平臺建設(shè)優(yōu)化

我們的 Hadoop 集群從17年的1600臺->18年的2800臺->19年的4000臺。可以看到集群的增長速度還是非常迅速的。在整個集群中：HDFS 存儲數(shù)據(jù)150P+，YARN 每天調(diào)度超過8000萬的 Container， MR/Spark 每日計算任務(wù)總數(shù)40萬+、中間處理數(shù)據(jù)量超過 14P。在此基礎(chǔ)上集群規(guī)模也在不斷增長，集群穩(wěn)定性能和效率對我們來說是一個比較大的挑戰(zhàn)。下面我將給大家介紹在上述背景下，我們關(guān)于 Hadoop 平臺建設(shè)以及優(yōu)化的具體實踐。

我們將從以下幾個方面來做介紹：

1. 規(guī)模擴展

首先，對于大規(guī)模 HDFS 集群可擴展性這一塊，我們采用的解決方案是 HDFS Fedoration。HDFS 最大的痛點的話是 NameNode 單點瓶頸的問題，這其中包括內(nèi)存的問題以及小文件的問題。通過 Fedoration 使用多個 NN 來緩解元數(shù)據(jù)內(nèi)存的壓力以及均衡元數(shù)據(jù)訪問的 RPC。

其次，通過 ViewFileSystem 對業(yè)務(wù)做統(tǒng)一。ViewFileSystem 有一個好處是它在客戶端實現(xiàn)，這樣它的穩(wěn)定性和性能就有保證。當然，社區(qū)原生版本有一些缺點，就是不支持跨 mount 點 mv，這一點我們對它做了修復(fù)。另外，它的維護成本比較高，在58我們是通過控制用戶規(guī)模來保證低維護的成本，具體如下：通過58數(shù)據(jù)平臺運營管理一套主賬號體系，我們給每個業(yè)務(wù)一個大的根目錄，在第一層子目錄下只分配四個目錄，通過這種方式來管控目錄的數(shù)量來保證低成本維護，同時這樣做在發(fā)生業(yè)務(wù)變更時影響也非常小。

2. 穩(wěn)定性殺手

雖然有 Fedoration 機制來均衡各個 NN 的壓力，但是對于單個 NN 壓力仍然非常大，各種問題時刻在挑戰(zhàn) HDFS 穩(wěn)定性，比如：NN RPC 爆炸，我們線上最大的 NS 有15億的 RPC 調(diào)用，4000+ 并發(fā)連接請求，如此高的連接請求對業(yè)務(wù)穩(wěn)定影響很大。針對這個問題，我們使用"拆解+優(yōu)化"的兩種手段相結(jié)合的方式來改進。拆解就是說我們把一些大的訪問，能不能拆解到不同的集群上，或者我們能不能做些控制，具體案例如下：

• Hive Scratch：我們經(jīng)過分析 Hive Scratch 的臨時目錄在 RPC 調(diào)用占比中達到 20%，對于 Hive Scratch 實際上每個業(yè)務(wù)不需要集中到一個 NS 上，我們把它均衡到多個 NS 上。

• Yarn 日志聚合：Yarn 的日志聚合主要是給業(yè)務(wù)查看一些日志，實際上他沒有必要那個聚合到 HDFS 上，只需要訪問本地就可以了。

• ResourceLocalize：同樣把它均衡到各個 NS 上。

經(jīng)過這種拆解就可以降低單個 NS 的壓力。

對于 RPC 的性能瓶頸還有很多，本文主要介紹以下幾種典型案例：

• DN BlockReport：即 DataNode 全量塊匯報，目前 DN 都是大存儲的機器，存在單機 60T 數(shù)據(jù)、100w+ Block，這種情況下單機做一次 BlockReport 對性能的影響非常大。針對這種情況，我們的改進措施是降低匯報頻率，從1小時/次 降低到 10小時/次 ；

• DN IBR ( Incremental Block Report )：即 DN 的增量塊匯報。在集群比較繁忙的時候，增量塊匯報的規(guī)模也是比較龐大的，在這塊的優(yōu)化中參考社區(qū)新版本的 issue，就是我們使用批量塊匯報的方式來降低增量塊匯報的頻率；

• DN Liveless：即 DN 假死。有時候 NN 或者 DN 比較繁忙的時候會出現(xiàn)心跳超時的情況，這樣會導(dǎo)致 NN 會對心跳超時的情況做冗余操作，單個 NN 的塊數(shù)量非常大，做冗余的話對 RPC 的性能壓力也是很大的。這里的做法是使用獨立心跳，避免"假死"導(dǎo)致百萬 block 冗余。

核心鏈路優(yōu)化：我們對線上出現(xiàn)的一些問題對核心鏈路做的優(yōu)化，主要思想是提高并行度，比如：

• PermissionCheck ---減少持鎖時間

• QuotaManager ---避免遞歸，提高效率

• ReplicationMonitor ---增加吞吐

• choseTarget ---提高匹配效率

3. NS 間負載均衡

對于 NS 間負載均衡，提供了 FastCopy 工具來做數(shù)據(jù)的拷貝，因為 Fedoration 已經(jīng)做到了很好的數(shù)據(jù)本地化，沒有必要去做跨集群拷貝，通過 FastCopy HardLink 的機制可以直接將 block 指向到目標 block。當然這種方案在做 NS 之間元數(shù)據(jù)拷貝的時候，還是有一些遷移的成本，這時候就需要業(yè)務(wù)來做一些配合。

4. GC 調(diào)優(yōu)

在 GC 這塊，NN 線上最大堆內(nèi)存達到了 230G，GC 調(diào)優(yōu)我們使用的 CMS GC，這是一個比較成熟的調(diào)優(yōu)方式。主要通過下述手段：

• 降低 Young GC 的頻率和時間：通過一些參數(shù)來減少它的頻率和參數(shù)

• CMS GC initialmark & Remark

• 避免 Concurrent mode failure 和 Promotion failure ，避免它做 Full GC

5. 慢節(jié)點問題

慢節(jié)點問題是我們遇到典型問題之一，主要有三個場景：

慢節(jié)點問題一：DN IO Util 100%

我們線上集群在業(yè)務(wù)快速擴增的過程中，曾經(jīng)出現(xiàn)過大量 DN IO Util 100%的現(xiàn)象，而且 DN IO Util 100%的持續(xù)時間很有可能會超過二十分鐘甚至半個小時，這會導(dǎo)致業(yè)務(wù)讀取數(shù)據(jù)非常緩慢，甚至超時、失敗。對我們核心業(yè)務(wù)的影響是非常大的，比如對于某個有很多業(yè)務(wù)依賴的上游業(yè)務(wù)，如果這個上游業(yè)務(wù)的延時比較長，那么所有的下游業(yè)務(wù)的延時將會不可控。針對這個問題，我們分析主要是由以下三個操作會導(dǎo)致這個問題的出現(xiàn)并做了改進，改進整體效果良好，改進后計算任務(wù)的執(zhí)行時間提速了 25%。

• 第一：10min 間隔 CheckDir 的操作，改進措施：不檢查所有，只檢查父目錄，這樣會做到基本無 IO 消耗。

• 第二：10min間隔 du 操作，改進措施：改成 df 實現(xiàn)，改進后基本無 IO 消耗。由于 du 會掃描磁盤上的所有的塊，是非常重的一個操作，事實上在這里我們不需要那么精確，使用 df 是完全可行的。

• 第三：6h 間隔 directoryScan 操作，改進措施：掃描限速 & 低峰執(zhí)行，改進后 IO 控制在30%。做限速避免持續(xù)占用帶寬，避免高峰期執(zhí)行操作，58 的高峰基本在凌晨至早晨時間 0：00 -9：00，我們在這個時間段不做這個操作，放在空閑時間。

慢節(jié)點問題二：讀數(shù)據(jù)

• 預(yù)讀支持：對于大數(shù)據(jù)量下客戶端讀 DN 的比較慢的情況，hadoop 本身提供的預(yù)讀方案是在隨機訪問情況下的優(yōu)化，但是對于離線計算基本是順序讀的場景不能使用，我們對此做了擴展，對順序讀提供了預(yù)讀支持。

• 千兆機器持續(xù)負載優(yōu)化：在58異構(gòu)情況非常嚴重，之前1000多臺千兆機器，千兆機器會持續(xù)打滿負載。針對這種情況我們使用社區(qū)關(guān)于 DataNode 快速重啟的方案 ( HDFS-7928 )，基本可以在30S時間內(nèi)重啟 DN，這樣我們通過快速重啟 DN 的方式把客戶端的請求分配到其他的節(jié)點上再還給他。

慢節(jié)點問題三：寫 pipeline 無限重試

客戶端寫一個塊的操作會在三個節(jié)點上都一個塊，我們線上遇到的一個比較嚴重的問題：在寫的過程中如果一個節(jié)點出現(xiàn)故障，會去不斷的重試將集群中所有的幾點重試一遍然后失敗，這種情況社區(qū)也有對應(yīng) issue ( HDFS-9178 )，原因是在做 DN 的 pipeline 恢復(fù)的時候把異常的節(jié)點當成了正常的節(jié)點來做 pipeline 恢復(fù)的對象。

6. YARN 建設(shè)優(yōu)化

Yarn 調(diào)度的優(yōu)化主要是兩個方面：一個是穩(wěn)定性，另一個效率方面。

穩(wěn)定性：

① 服務(wù)穩(wěn)定性：

服務(wù)穩(wěn)定性主要針對于系統(tǒng)的核心模塊，下面介紹下線上易出現(xiàn)的核心問題：

• YARN-4741：升級過程中大規(guī)模的 NM 重啟的時候容易出現(xiàn)千萬級的冗余事件，這樣會造成 NM OOM 從而集群會掛掉，因此需要對冗余事件過濾。

• 異常 APP 過濾：在做 RM 切換的時候遇到的 App 異常狀態(tài)，導(dǎo)致 RM 直接掛掉

• DNS：DNS 服務(wù)掛掉導(dǎo)致集群宕機，主要是通過 cache 機制來解決，包括在集群層面、硬件層面做 cache。

② 計算穩(wěn)定性：

• 業(yè)務(wù)方面：提供標簽調(diào)度隔離，把業(yè)務(wù)做物理隔離保證重點業(yè)務(wù)的執(zhí)行

• Quene & APP 方面：提供優(yōu)先級的支持，保證高優(yōu)先級的任務(wù)先拿到資源

• 節(jié)點層面：container 做 Cgroup 的隔離，保證 container 的穩(wěn)定性

③ 過載保護：

• 在集群層面有過載保護措施，比如：最大用戶數(shù)，最大 APP 數(shù)，最大 container 數(shù)等。

YARN 調(diào)度吞吐保證：

• 減少調(diào)度規(guī)模怕從而減輕壓力：Hivesql 切換 sparkThriftServer，因為 sparkThriftServer 是一個常駐的服務(wù)，在初始化時申請下資源后基本不會再去向 YARN 申請資源，切換后可以減少吞吐。

• 錯峰：核心任務(wù)優(yōu)先保證，在空閑階段再跑一些非核心業(yè)務(wù)。

• 調(diào)度優(yōu)化：YARN 調(diào)度主要有三個線程，三個線程共享一把鎖來做各自的鎖邏輯，所以一個優(yōu)化思路就是解決這個鎖競爭的問題，另一個思路是對核心的調(diào)度邏輯做優(yōu)化。

持鎖時間優(yōu)化：

通過 Profiling 發(fā)現(xiàn)調(diào)度進程在排序操作的過程種需要消耗90%的 CPU 時間，而且在做排序的時候基本上只是讀的操作，沒有必要去拿鎖。另外調(diào)度的三個線程沒有必要都用排他鎖，我們可以做一個鎖降解，對于更新線程 updateThread 用讀鎖就可以了，另外我們需要做一個加鎖順序的保證來避免死鎖的情況。

核心計算邏輯 Profiling：

核心邏輯 Profiling 的幾種思路：

• 一是降低時間復(fù)雜度，社區(qū)使用的歸并排序的思想，復(fù)雜度為 O(N * logN)，實際上調(diào)度的時候我們只需要找到一個適配的節(jié)點，通過優(yōu)化可以將復(fù)雜度降為 O(n + k * logN)；

• 二是通過空間換時間的思想，比如通過預(yù)計算、預(yù)取數(shù)來減少計算次數(shù)；

• 三是在做排序的時候?qū)τ谝恍┮呀?jīng)不需要排序的，不需要資源的地方做優(yōu)化。

整體優(yōu)化完成以后調(diào)度系統(tǒng)提高到 3000 container/s，基本上滿足了我們的需求。

7. 計算引擎優(yōu)化

接下來，我們來介紹下關(guān)于計算引擎方面的優(yōu)化，主要是下面幾個方面：

云窗 Hive –> SparkSql：

云窗是 58 使用非常廣泛的 Sql 查詢平臺，主要用在即席查詢場景。之前一直存在一個痛點問題：查詢引擎只有 Hive，因此查詢效率很受局限。17年底的時候我們開始將查詢引擎由 Hive 轉(zhuǎn)向 SparkSql，在做即席查詢引擎轉(zhuǎn)換升級的時候我們做了一些調(diào)研，對比了 Impala，Presto 等等，結(jié)合 58 現(xiàn)狀我們最終使用 SparkSql 來替換了 Hive。當時 Spark 最新版本為 Spark 2.2，基于穩(wěn)定性考慮沒有激進的選擇使用最新的版本而是選擇了比較穩(wěn)定的版本 Spark 2.1.2。另外支持 SparkSql 引擎，也對 SparkThriftServer、Zeppelin 等解決方案做了調(diào)研，綜合以下幾個方面我們選擇了 SparkThriftServer：

一是由于云窗 Hive 主要是和前端 JDBC 的使用方式，這時候用 SparkThriftServer 改造起來就非常簡單；

二是需要在應(yīng)用性上做些保證，比如業(yè)務(wù)可以實時查詢執(zhí)行進度，可以組取消等相關(guān)操作；

三是云窗 Hive 是提供給多個用戶使用需要，所以需要支持多租戶。

SparkThriftServer 多租戶：

多租戶的問題主要在權(quán)限這一塊，需要把各個業(yè)務(wù)的權(quán)限打通，這樣各個業(yè)務(wù)在做查詢的時候做到安全隔離；此外在計算方面，由于 SparkThriftServer 業(yè)務(wù)使用公共資源，也需要把重點業(yè)務(wù)的資源做隔離。

SparkSql 兼容 Hive 的實現(xiàn)：

我們需要保證云窗 Hive 用戶的查詢和 SparkSql 的查詢做到一致性。主要用到下面四個問題：UDF 支持問題，語法兼容性問題，數(shù)據(jù)質(zhì)量問題，參數(shù)兼容問題。這塊的解決方案比較簡單，當時是把云窗 Hive 的所有語句遷移到 SparkSql 來做測試，根據(jù)測試的結(jié)果來修復(fù)相關(guān)的問題，最后修復(fù)了50+個 issue 把成功率提高到95%以上。

SparkThriftServer 平臺穩(wěn)定性建設(shè)：

SparkThriftServer 平臺穩(wěn)定性建設(shè)也做了比較多的工作，重點說以下幾點：

• Spark 自身穩(wěn)定性問題種 Spark Driver 內(nèi)存管理的問題

• 保障服務(wù)的穩(wěn)定性方面，通過 HA 機制提供多臺 SparkThriftServer 支持，另外在云窗上層提供重試策略，這樣在下游出現(xiàn)問題但不影響上游情況下通過上游重試來提高運行成功率

• 通過一些任務(wù)管控做集群的過載保護

• 降低集群壓力：Spark 對集群的壓力還是非常大的，特別是在不正確使用的情況下，我們需要對它對 HDFS 的壓力做一些管控，比如輸入輸出這一塊

SparkSql 上線運行后發(fā)現(xiàn)的一些問題：

比如在云窗上 Hive 和 Spark 默認情況下使用了同樣的配置，在云窗上用戶不會關(guān)心使用的是 Hive 還是 SparkSql，這樣存在一個問題就是很難對業(yè)務(wù)做一個針對性的調(diào)優(yōu)，這里我們做了一些優(yōu)化，優(yōu)化過程中主要參考了 Intel SparkAE 的一些特性。

• 最優(yōu) Shuffle Partition：Partition 數(shù)量的指定在各個階段都是一樣的，事實上很難達到一個最優(yōu)的效果；

• Join 的策略：原生的 join 策略是根據(jù)初始數(shù)據(jù)來做 join 策略，我們可以通過一些中間結(jié)果來做一些策略的改變；

• 數(shù)據(jù)傾斜：在做 Sql 查詢中我們遇到的比較多的情況就是數(shù)據(jù)傾斜，我們也是做了自動的數(shù)據(jù)傾斜的優(yōu)化。做完這些優(yōu)化后，線上的任務(wù)基本上都有2-3倍的提升，效果還是非常明顯的。

8. WSSM 平臺建設(shè)

對于大規(guī)模的集群，運營能力還是很重要的，否則集群開發(fā)人員會花費大量時間來做運維。運營主要在存儲和計算。

海量存儲一站式運營管理：

存儲運營有很多要做，比如目錄配額管控，權(quán)限控制，告警機制，成本的優(yōu)化等。我們主要是通過 FSImage + EditLog 的方式拿到需要分析的數(shù)據(jù)存儲信息，集群運營者分析獲取到的信息然后做相應(yīng)的存儲優(yōu)化策略。使用 FSImage + EditLog 一個好處就是對 NN 無影響。我們集群運營每天可以對4000萬+目錄做冷熱、增長等方面的分析；運營用戶可以根據(jù)數(shù)據(jù)目錄的冷熱情況自定義生命周期等策略來管理數(shù)據(jù)目錄，通過目錄增長信息用戶可以知道數(shù)據(jù)的增長情況是否正常。我們也提供了自動化目錄壓縮的接入，業(yè)務(wù)想做數(shù)據(jù)治理的化可以一鍵接入；自動化壓縮有以下幾個特點：冷數(shù)據(jù)使用 GZIP 壓縮，熱數(shù)據(jù)使用 LZO 壓縮；提供數(shù)據(jù)完整性校驗機制。數(shù)據(jù)壓縮帶來效果還是比較明顯的，以19年實踐為例：通過壓縮數(shù)據(jù)累計節(jié)省了 100P+ 空間，相當于千臺服務(wù)器的節(jié)省。

海量計算自主運營分析：

海量計算自助運營分析平臺可以避免很多重復(fù)工作，減少資源的浪費，提高業(yè)務(wù)開發(fā)以及集群運維開發(fā)的工作效率。

我們是基于 LinkedIn 開源的大象醫(yī)生 Dr-elephant 做的擴展改進，在改進過程中主要解決幾個問題：

• Dr-elephant 的擴展性問題，我們通過 AppList 派發(fā)到多臺 Dr-elephant 來支持擴展性問題。

• 對 spark 的各個版本做了兼容性的實現(xiàn)，比如：Spark2.1，Spark2.3

• Dr-elephant 原生啟發(fā)式算法改進。改進后支持分析：MR 是否分配在慢節(jié)點上，container 的資源是否合理等。

▌跨機房遷移

下面，給大家介紹下數(shù)據(jù)平臺部在19年下半年做的跨機房遷移這方面的事情。

遷移背景：

• 全量遷移：3000臺機器，130P數(shù)據(jù)，40萬計算任務(wù)

• 老機房資源緊張，無法擴容，業(yè)務(wù)持續(xù)增長

• 低成本遷移，控制時耗，Hadoop 機位半年內(nèi)騰空

• 其它：跨機房帶寬比較充裕 ( 2Tb )，延遲 2ms 左右 ( 機房內(nèi) 0.1ms )；離線 Hbase 集群混部，80臺 RS，100+表

方案預(yù)研以及選型結(jié)果：

常用方案——多集群多機房

• 新機房搭建同套環(huán)境，穩(wěn)定性好，改造少 ( 新版本特性可以直接使用 )

• 業(yè)務(wù)配合 ( 數(shù)據(jù)一致性驗證等 )，影響大，時間不可控

• 機器成本高

58方案——HDFS 單集群多機房

• 業(yè)務(wù)透明 -> 影響小

• 老機房下線機器，擴容新機房 -> 成本低

• 先遷移數(shù)據(jù)節(jié)點，后遷移主節(jié)點

跨機房網(wǎng)絡(luò)

• 壓測跨機房性能影響15% 以內(nèi)，網(wǎng)絡(luò)延時較好，可控
• 老機房峰值網(wǎng)絡(luò)吞吐 1.3T，帶寬充足

下面介紹遷移具體方案和實踐：

1. 單集群跨機房 HDFS 數(shù)據(jù)遷移

數(shù)據(jù)從老機房遷移到新機房主要用到了 HDFS 的 Decommision 特性。這里我們針對 decommision 存在的一些問題做了一些改進，改進后性能提升超過6倍，具體問題與方案如下：

不可指定機房：decommision 的數(shù)據(jù)目標節(jié)點是不確定的，如果直接使用 decommision 會產(chǎn)生較多的數(shù)據(jù)冗余，所以我們在數(shù)據(jù)路由上做了改進，讓 decommision 可以支持指定機房，這樣下線的時候就可以將數(shù)據(jù)直接 decommision 到新機房。

性能：decommision 本身性能較差吞吐量小且對 NameNode 的壓力較大，在這里做了如下的改進：

• dfs.namenode.replication.max-streams

• 降低 NN RPC 負載，充分利用 DN 機器帶寬 ( HDFS-7411，HDFS-14854 )

穩(wěn)定性：decommision 存在一些穩(wěn)定性問題，比如：不能正常結(jié)束，這里我們參考社區(qū) issue(HDFS-11847)，做了 decommision 的監(jiān)控工具，分析 decommision 不能結(jié)束的具體原因然后做針對性的處理。另外在 decommision 的執(zhí)行過程中可能會出現(xiàn)塊丟失問題，線上曾經(jīng)出現(xiàn)丟失幾百萬個塊，還好后來數(shù)據(jù)做了及時修復(fù)，此處參考 HDFS-11609。

此外，我們是在低峰期執(zhí)行 decommision 以降低影響。為保證服務(wù)穩(wěn)定下線速率保持在每天下線50臺，基本在5個月的時間內(nèi)完成集群遷移。

2. 網(wǎng)絡(luò)

在實踐過程中，我們發(fā)現(xiàn)網(wǎng)絡(luò)急劇增長，最大到 1.8T 接近上限，非常危險了，針對這個問題我們做了如下分析。

• 第一，因為集群是異構(gòu)的，集群中有大量千兆機器，在遷移過程中千兆機器在持續(xù)的下線，這樣很多計算落在了萬兆機器，從而增長了帶寬；

• 第二，在遷移完成后，我們會千兆機器的網(wǎng)卡升級到萬兆，因為網(wǎng)絡(luò)的性能提升，把帶寬提升上去了。

在網(wǎng)絡(luò)降低帶寬方面的優(yōu)化策略：

• 跨機房讀寫策略，整體策略完成后跨機房帶寬降低50%，具體如下：首先需要支持機房網(wǎng)絡(luò)拓撲結(jié)構(gòu)，支持本機房寫。另外考慮到老機房很少有存儲的情況，這里做動態(tài)配置策略：默認是本機房寫，通過修改配置可以隨機寫或者指定機房寫。在讀方面優(yōu)先級順序由高到低為: 同節(jié)點 -> 同機架 -> 同機房 –> 跨機房

• 控制大業(yè)務(wù)帶寬，主要是以下兩點：一是 Flume sink HDFS 實現(xiàn)壓縮機制，峰值帶寬 200Gb 降低到 40Gb 左右；二是分析計算依賴，對計算遷移控制跨機房計算的規(guī)模。

• 其他管控：比如硬件層面保證控制流優(yōu)先，這樣即使帶寬打滿也不會發(fā)生心跳信息無法傳遞導(dǎo)致集群崩潰

3. 新機房磁盤傾斜

在遷移過程中，遇到第二個比較大問題：新機房磁盤傾斜比較嚴重，大量機器存儲超過了95%，此時節(jié)點出現(xiàn) unhealthy 情況。由于機器在計算方面做了標簽隔離，如果存儲占滿對重要業(yè)務(wù)運行穩(wěn)定性影響非常大，需要有一個快速均衡方案來均衡高負載節(jié)點。這里我們使用 HDFS Balance 作為一個解決方案，同時優(yōu)化了 HDFS Balance 的幾個痛點問題：

• 支持可指定源節(jié)點，目的節(jié)點

• 直接從 DN 獲取 Blocks 信息，減輕 NN 壓力同時提高并發(fā)

• 源節(jié)點避免寫，控制讀

• 支持限速，水位可控，且可用于

• 機房數(shù)據(jù)遷移錯峰運行

通過以上方案，日支持 PB 級數(shù)據(jù) balance，線上975臺90%水位 DN5 個工作日完成均衡。

4. 計算遷移

計算服務(wù)更像是一個無狀態(tài)的服務(wù)，也不需要做單集群跨機房，做起來就比較輕松。只需要在新機房部署一個新的 YARN 集群就可以，也可以保證計算任務(wù)不會跨機房。在整個遷移過程以隊列為粒度，根據(jù)隊列映射機房，在遷移初期給任務(wù)更富裕的資源以保證任務(wù)運行更加穩(wěn)定。遷移期間會做一些灰度檢驗，此時需要業(yè)務(wù)配合，同時也會對遷移前后任務(wù)的運行情況做分析對比以確保遷移不影響業(yè)務(wù)的正確性。

整個遷移過程，期間由業(yè)務(wù)與平臺相互協(xié)作。業(yè)務(wù)主要評估遷移前后的差異，包括性能、成功率等。其他任務(wù)都是由平臺來做，分為離線、實時、Hbase 等部分，其中離線部分流程為：

新機房資源準備，業(yè)務(wù)梳理 -> 測試新機房性能 –> 業(yè)務(wù)一隊列粒度切換新機房 ->回收老機房資源 -> 搬遷至新機房擴容

實時任務(wù)遷移參考離線部分，大同小異。

整體遷移過程：先遷移計算和存儲再遷移 HDFS 等核心服務(wù)，核心服務(wù)通過域名化變更來遷移，這里在源生 Hadoop 做了改進增加了對異常捕獲的處理。

▌后續(xù)規(guī)劃

后續(xù)規(guī)劃主要對兩個方面，一個 Hadoop3.X，一個是云融合。

① Hadoop3.X

Hadoop 現(xiàn)在版本是在 CDH-Hadoop 2.6 做的定制，后續(xù)計算對 Hadoop 升級到 3.X。主要對 Hadoop3.X 兩個特性比較看好：

• 第一：對 EC ( erasure coding 糾刪碼 ) 的支持，可以節(jié)省很大的存儲空間

• 第二：對象存儲 ( ozone )

② 云融合探索

目前公司私有云主要支持在線的業(yè)務(wù)，大數(shù)據(jù)平臺主要支持離線的業(yè)務(wù)。在線業(yè)務(wù)一般晚上資源比較空閑，離線業(yè)務(wù)晚上資源比較繁忙，因此考慮是否可以錯峰相互借用資源以降低成本。

▌精選問題的回答

1. 批流統(tǒng)一怎么做？

答：目前在58 已經(jīng)在將 Storm 遷移到了 Flink，這個具體方案的文章已經(jīng)發(fā)布在 58 技術(shù)公眾號上，感興趣的同學(xué)可以去公眾號查看。另外 Spark Streaming 我們也建議業(yè)務(wù)可以遷移到 Flink 上，根據(jù)部分遷移業(yè)務(wù)來看，資源的使用有比較大的提升，而且在流方面整理來看 Flink 比 SparkStreaming 更有優(yōu)勢，無論是功能方面還是架構(gòu)方面，這些都有大量的文章介紹。

我們已經(jīng)基于 Flink 開發(fā)了一棧式實時開發(fā)平臺 Wstream，支持使用 Sql 開發(fā)實時程序，支持 DDL、Join。

2. OLAP 選型怎么做？

答：在58 OLAP 場景目前是使用 Kylin 來支持離線的業(yè)務(wù)，比如 BI 報表，Kylin 的話建議維度不要超過50維度，超過維度支持的會不友好；另外 Druid 來支持實時的場景，比如廣告效果的評估，用戶行為分析等。

Kylin 和 Druid 都是預(yù)計算的思想，因此查詢場景比較受限，而且對其他組件依賴較重導(dǎo)致維護成本較高，目前業(yè)界也有一些新的優(yōu)秀解決方案，比如 ClickHouse 這些沒有對其他組件的依賴相對來說比較輕量。這些組件性能上基本上都是采用列式存儲的思想，提高硬件使用效率等。

Kylin、Druid 目前從使用上來看是比較成熟的 ( 包括對 Sql 語法的支持等 )，58數(shù)據(jù)平臺目前也在做 OLAP 相關(guān)的調(diào)研，爭取盡早落地，屆時再與大家分享。

特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：
																																																																																																																																																																																																																																																																																						

																																																																																																																																																																																																																																																																																					

長按訂閱更多精彩▼
																																																																																																																																																																																																																																																																																						

																																																																																																																																																																																																																																																																																					
如有收獲，點個在看，誠摯感謝