基于Hadoop的58同城離線計(jì)算平臺(tái)設(shè)計(jì)與實(shí)踐（58同城離線提醒）

?

分享嘉賓：余意 58同城 高級(jí)架構(gòu)師

編輯整理：史士博

內(nèi)容來(lái)源：58大數(shù)據(jù)系列直播

出品平臺(tái)：DataFun

注：歡迎轉(zhuǎn)載，轉(zhuǎn)載請(qǐng)?jiān)诹粞詤^(qū)留言。

導(dǎo)讀：58離線計(jì)算平臺(tái)基于 Hadoop 生態(tài)體系打造，單集群4000 臺(tái)服務(wù)器，數(shù)百 PB 存儲(chǔ)，日40萬(wàn)計(jì)算任務(wù)，面臨挑戰(zhàn)極大。58大數(shù)據(jù)平臺(tái)的定位主要是服務(wù)數(shù)據(jù)業(yè)務(wù)開(kāi)發(fā)人員，提高數(shù)據(jù)開(kāi)發(fā)效率，提供便捷的開(kāi)發(fā)分析流程，有效支持?jǐn)?shù)據(jù)倉(cāng)庫(kù)及數(shù)據(jù)應(yīng)用建設(shè)。通常大數(shù)據(jù)平臺(tái)通用基礎(chǔ)能力包括：數(shù)據(jù)存儲(chǔ)、實(shí)時(shí)計(jì)算、離線計(jì)算、數(shù)據(jù)查詢分析，本次分享將聚焦大數(shù)據(jù)平臺(tái)離線計(jì)算和大家一起系統(tǒng)的探討58在離線計(jì)算平臺(tái)建設(shè)實(shí)踐的思路、方案和問(wèn)題解決之道。

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

• 58在集群快速增長(zhǎng)的過(guò)程中遇到的問(wèn)題以及解決之道；
• 58大數(shù)據(jù)集群跨機(jī)房遷移的相關(guān)工作，如何在5個(gè)月時(shí)間快速完成3000臺(tái)集群服務(wù)的遷移工作。

▌數(shù)據(jù)平臺(tái)部簡(jiǎn)介

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

• 數(shù)據(jù)接入：文本的收集，我們采用 flume 接入，然后用 kafka 做消息緩沖，我們基于 kafka client 打造了一個(gè)實(shí)時(shí)分發(fā)平臺(tái)，可以很方便的把 kafka 的中間數(shù)據(jù)打到后端的各種存儲(chǔ)系統(tǒng)上。
• 離線計(jì)算：我們主要基于 Hadoop 生態(tài)的框架做了二次定制開(kāi)發(fā)。包括 HDFS、YARN、MR、Spark。
• 實(shí)時(shí)計(jì)算：目前主要是基于 Flink 打造了一個(gè)一棧式的流式計(jì)算開(kāi)發(fā)平臺(tái) Wstream。
• 多維分析：我們主要提供兩組多維分析的解決方案。離線的使用 Kylin，實(shí)時(shí)的使用 Druid。
• 數(shù)據(jù)庫(kù)：在數(shù)據(jù)庫(kù)的這個(gè)場(chǎng)景，我們主要還是基于 Hbase 的這個(gè)技術(shù)體系來(lái)打造了出來(lái)，除了 HBase 提供海量的 K-V 存儲(chǔ)意外，我們也基于 HBase 之上提供 OpenTSDB 的時(shí)序存儲(chǔ)、JanusGraph 圖存儲(chǔ)。

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

在上圖的右半部分我們簡(jiǎn)單的介紹了幾個(gè)數(shù)據(jù)平臺(tái)的指標(biāo)。Flume 每天的日志采集量 240T，Haddop 單集群服務(wù)器臺(tái)數(shù)4000 ，F(xiàn)link 每天進(jìn)行超過(guò)6000億次的計(jì)算，Druid 已經(jīng)構(gòu)建超過(guò) 600 億條實(shí)時(shí)數(shù)據(jù)索引。

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

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

我們將從以下幾個(gè)方面來(lái)做介紹：

1. 規(guī)模擴(kuò)展

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

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

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

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

• Hive Scratch：我們經(jīng)過(guò)分析 Hive Scratch 的臨時(shí)目錄在 RPC 調(diào)用占比中達(dá)到 20%，對(duì)于 Hive Scratch 實(shí)際上每個(gè)業(yè)務(wù)不需要集中到一個(gè) NS 上，我們把它均衡到多個(gè) NS 上。
• Yarn 日志聚合：Yarn 的日志聚合主要是給業(yè)務(wù)查看一些日志，實(shí)際上他沒(méi)有必要那個(gè)聚合到 HDFS 上，只需要訪問(wèn)本地就可以了。
• ResourceLocalize：同樣把它均衡到各個(gè) NS 上。

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

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

• DN BlockReport：即 DataNode 全量塊匯報(bào)，目前 DN 都是大存儲(chǔ)的機(jī)器，存在單機(jī) 60T 數(shù)據(jù)、100w Block，這種情況下單機(jī)做一次 BlockReport 對(duì)性能的影響非常大。針對(duì)這種情況，我們的改進(jìn)措施是降低匯報(bào)頻率，從1小時(shí)/次 降低到 10小時(shí)/次 ；
• DN IBR ( Incremental Block Report )：即 DN 的增量塊匯報(bào)。在集群比較繁忙的時(shí)候，增量塊匯報(bào)的規(guī)模也是比較龐大的，在這塊的優(yōu)化中參考社區(qū)新版本的 issue，就是我們使用批量塊匯報(bào)的方式來(lái)降低增量塊匯報(bào)的頻率；
• DN Liveless：即 DN 假死。有時(shí)候 NN 或者 DN 比較繁忙的時(shí)候會(huì)出現(xiàn)心跳超時(shí)的情況，這樣會(huì)導(dǎo)致 NN 會(huì)對(duì)心跳超時(shí)的情況做冗余操作，單個(gè) NN 的塊數(shù)量非常大，做冗余的話對(duì) RPC 的性能壓力也是很大的。這里的做法是使用獨(dú)立心跳，避免"假死"導(dǎo)致百萬(wàn) block 冗余。

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

• PermissionCheck —減少持鎖時(shí)間
• QuotaManager —避免遞歸，提高效率
• ReplicationMonitor —增加吞吐
• choseTarget —提高匹配效率

3. NS 間負(fù)載均衡

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

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

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

• 降低 Young GC 的頻率和時(shí)間：通過(guò)一些參數(shù)來(lái)減少它的頻率和參數(shù)
• CMS GC initialmark & Remark
• 避免 Concurrent mode failure 和 Promotion failure ，避免它做 Full GC

5. 慢節(jié)點(diǎn)問(wèn)題

慢節(jié)點(diǎn)問(wèn)題是我們遇到典型問(wèn)題之一，主要有三個(gè)場(chǎng)景：

慢節(jié)點(diǎn)問(wèn)題一：DN IO Util 100%

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

• 第一：10min 間隔 CheckDir 的操作，改進(jìn)措施：不檢查所有，只檢查父目錄，這樣會(huì)做到基本無(wú) IO 消耗。
• 第二：10min間隔 du 操作，改進(jìn)措施：改成 df 實(shí)現(xiàn)，改進(jìn)后基本無(wú) IO 消耗。由于 du 會(huì)掃描磁盤上的所有的塊，是非常重的一個(gè)操作，事實(shí)上在這里我們不需要那么精確，使用 df 是完全可行的。
• 第三：6h 間隔 directoryScan 操作，改進(jìn)措施：掃描限速 & 低峰執(zhí)行，改進(jìn)后 IO 控制在30%。做限速避免持續(xù)占用帶寬，避免高峰期執(zhí)行操作，58 的高峰基本在凌晨至早晨時(shí)間 0：00 -9：00，我們?cè)谶@個(gè)時(shí)間段不做這個(gè)操作，放在空閑時(shí)間。

慢節(jié)點(diǎn)問(wèn)題二：讀數(shù)據(jù)

• 預(yù)讀支持：對(duì)于大數(shù)據(jù)量下客戶端讀 DN 的比較慢的情況，hadoop 本身提供的預(yù)讀方案是在隨機(jī)訪問(wèn)情況下的優(yōu)化，但是對(duì)于離線計(jì)算基本是順序讀的場(chǎng)景不能使用，我們對(duì)此做了擴(kuò)展，對(duì)順序讀提供了預(yù)讀支持。
• 千兆機(jī)器持續(xù)負(fù)載優(yōu)化：在58異構(gòu)情況非常嚴(yán)重，之前1000多臺(tái)千兆機(jī)器，千兆機(jī)器會(huì)持續(xù)打滿負(fù)載。針對(duì)這種情況我們使用社區(qū)關(guān)于 DataNode 快速重啟的方案 ( HDFS-7928 )，基本可以在30S時(shí)間內(nèi)重啟 DN，這樣我們通過(guò)快速重啟 DN 的方式把客戶端的請(qǐng)求分配到其他的節(jié)點(diǎn)上再還給他。

慢節(jié)點(diǎn)問(wèn)題三：寫 pipeline 無(wú)限重試

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

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

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

穩(wěn)定性：

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

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

• YARN-4741：升級(jí)過(guò)程中大規(guī)模的 NM 重啟的時(shí)候容易出現(xiàn)千萬(wàn)級(jí)的冗余事件，這樣會(huì)造成 NM OOM 從而集群會(huì)掛掉，因此需要對(duì)冗余事件過(guò)濾。
• 異常 APP 過(guò)濾：在做 RM 切換的時(shí)候遇到的 App 異常狀態(tài)，導(dǎo)致 RM 直接掛掉
• DNS：DNS 服務(wù)掛掉導(dǎo)致集群宕機(jī)，主要是通過(guò) cache 機(jī)制來(lái)解決，包括在集群層面、硬件層面做 cache。

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

• 業(yè)務(wù)方面：提供標(biāo)簽調(diào)度隔離，把業(yè)務(wù)做物理隔離保證重點(diǎn)業(yè)務(wù)的執(zhí)行
• Quene & APP 方面：提供優(yōu)先級(jí)的支持，保證高優(yōu)先級(jí)的任務(wù)先拿到資源
• 節(jié)點(diǎn)層面：container 做 Cgroup 的隔離，保證 container 的穩(wěn)定性

③ 過(guò)載保護(hù)：

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

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

• 減少調(diào)度規(guī)模怕從而減輕壓力：HiveSql 切換 sparkThriftServer，因?yàn)?sparkThriftServer 是一個(gè)常駐的服務(wù)，在初始化時(shí)申請(qǐng)下資源后基本不會(huì)再去向 YARN 申請(qǐng)資源，切換后可以減少吞吐。
• 錯(cuò)峰：核心任務(wù)優(yōu)先保證，在空閑階段再跑一些非核心業(yè)務(wù)。
• 調(diào)度優(yōu)化：YARN 調(diào)度主要有三個(gè)線程，三個(gè)線程共享一把鎖來(lái)做各自的鎖邏輯，所以一個(gè)優(yōu)化思路就是解決這個(gè)鎖競(jìng)爭(zhēng)的問(wèn)題，另一個(gè)思路是對(duì)核心的調(diào)度邏輯做優(yōu)化。

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

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

核心計(jì)算邏輯 Profiling：

核心邏輯 Profiling 的幾種思路：

• 一是降低時(shí)間復(fù)雜度，社區(qū)使用的歸并排序的思想，復(fù)雜度為 O(N * logN)，實(shí)際上調(diào)度的時(shí)候我們只需要找到一個(gè)適配的節(jié)點(diǎn)，通過(guò)優(yōu)化可以將復(fù)雜度降為 O(n k * logN)；
• 二是通過(guò)空間換時(shí)間的思想，比如通過(guò)預(yù)計(jì)算、預(yù)取數(shù)來(lái)減少計(jì)算次數(shù)；
• 三是在做排序的時(shí)候?qū)τ谝恍┮呀?jīng)不需要排序的，不需要資源的地方做優(yōu)化。

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

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

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

云窗 Hive –> SparkSql：

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

一是由于云窗 Hive 主要是和前端 JDBC 的使用方式，這時(shí)候用 SparkThriftServer 改造起來(lái)就非常簡(jiǎn)單；

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

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

SparkThriftServer 多租戶：

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

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

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

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

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

• Spark 自身穩(wěn)定性問(wèn)題種 Spark Driver 內(nèi)存管理的問(wèn)題
• 保障服務(wù)的穩(wěn)定性方面，通過(guò) HA 機(jī)制提供多臺(tái) SparkThriftServer 支持，另外在云窗上層提供重試策略，這樣在下游出現(xiàn)問(wèn)題但不影響上游情況下通過(guò)上游重試來(lái)提高運(yùn)行成功率
• 通過(guò)一些任務(wù)管控做集群的過(guò)載保護(hù)
• 降低集群壓力：Spark 對(duì)集群的壓力還是非常大的，特別是在不正確使用的情況下，我們需要對(duì)它對(duì) HDFS 的壓力做一些管控，比如輸入輸出這一塊

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

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

• 最優(yōu) Shuffle Partition： Partition 數(shù)量的指定在各個(gè)階段都是一樣的，事實(shí)上很難達(dá)到一個(gè)最優(yōu)的效果；
• Join 的策略：原生的 join 策略是根據(jù)初始數(shù)據(jù)來(lái)做 join 策略，我們可以通過(guò)一些中間結(jié)果來(lái)做一些策略的改變；
• 數(shù)據(jù)傾斜：在做 Sql 查詢中我們遇到的比較多的情況就是數(shù)據(jù)傾斜，我們也是做了自動(dòng)的數(shù)據(jù)傾斜的優(yōu)化。做完這些優(yōu)化后，線上的任務(wù)基本上都有2-3倍的提升，效果還是非常明顯的。

8. WSSM 平臺(tái)建設(shè)

對(duì)于大規(guī)模的集群，運(yùn)營(yíng)能力還是很重要的，否則集群開(kāi)發(fā)人員會(huì)花費(fèi)大量時(shí)間來(lái)做運(yùn)維。運(yùn)營(yíng)主要在存儲(chǔ)和計(jì)算。

海量存儲(chǔ)一站式運(yùn)營(yíng)管理：

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

海量計(jì)算自主運(yùn)營(yíng)分析：

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

我們是基于 LinkedIn 開(kāi)源的大象醫(yī)生 Dr-elephant 做的擴(kuò)展改進(jìn)，在改進(jìn)過(guò)程中主要解決幾個(gè)問(wèn)題：

• Dr-elephant 的擴(kuò)展性問(wèn)題，我們通過(guò) AppList 派發(fā)到多臺(tái) Dr-elephant 來(lái)支持?jǐn)U展性問(wèn)題。
• 對(duì) spark 的各個(gè)版本做了兼容性的實(shí)現(xiàn)，比如：Spark2.1，Spark2.3
• Dr-elephant 原生啟發(fā)式算法改進(jìn)。改進(jìn)后支持分析：MR 是否分配在慢節(jié)點(diǎn)上，container 的資源是否合理等。

下圖是我們運(yùn)營(yíng)管理的界面，其中左半部分是存儲(chǔ)方面，右半部分是計(jì)算方面的。

▌跨機(jī)房遷移

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

遷移背景：

• 全量遷移：3000臺(tái)機(jī)器，130P數(shù)據(jù)，40萬(wàn)計(jì)算任務(wù)
• 老機(jī)房資源緊張，無(wú)法擴(kuò)容，業(yè)務(wù)持續(xù)增長(zhǎng)
• 低成本遷移，控制時(shí)耗，Hadoop 機(jī)位半年內(nèi)騰空
• 其它：跨機(jī)房帶寬比較充裕 ( 2Tb )，延遲 2ms 左右 ( 機(jī)房?jī)?nèi) 0.1ms )；離線 Hbase 集群混部，80臺(tái) RS，100 表

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

常用方案——多集群多機(jī)房

• 新機(jī)房搭建同套環(huán)境，穩(wěn)定性好，改造少 ( 新版本特性可以直接使用 )
• 業(yè)務(wù)配合 ( 數(shù)據(jù)一致性驗(yàn)證等 )，影響大，時(shí)間不可控
• 機(jī)器成本高

58方案——HDFS 單集群多機(jī)房

• 業(yè)務(wù)透明 -> 影響小
• 老機(jī)房下線機(jī)器，擴(kuò)容新機(jī)房 -> 成本低
• 先遷移數(shù)據(jù)節(jié)點(diǎn)，后遷移主節(jié)點(diǎn)

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

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

下面介紹遷移具體方案和實(shí)踐：

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

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

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

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

• dfs.namenode.replication.max-streams
• 降低 NN RPC 負(fù)載，充分利用 DN 機(jī)器帶寬 ( HDFS-7411，HDFS-14854 )

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

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

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

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

• 第一，因?yàn)榧菏钱悩?gòu)的，集群中有大量千兆機(jī)器，在遷移過(guò)程中千兆機(jī)器在持續(xù)的下線，這樣很多計(jì)算落在了萬(wàn)兆機(jī)器，從而增長(zhǎng)了帶寬；
• 第二，在遷移完成后，我們會(huì)千兆機(jī)器的網(wǎng)卡升級(jí)到萬(wàn)兆，因?yàn)榫W(wǎng)絡(luò)的性能提升，把帶寬提升上去了。

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

• 跨機(jī)房讀寫策略，整體策略完成后跨機(jī)房帶寬降低50%，具體如下：首先需要支持機(jī)房網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，支持本機(jī)房寫。另外考慮到老機(jī)房很少有存儲(chǔ)的情況，這里做動(dòng)態(tài)配置策略：默認(rèn)是本機(jī)房寫，通過(guò)修改配置可以隨機(jī)寫或者指定機(jī)房寫。在讀方面優(yōu)先級(jí)順序由高到低為: 同節(jié)點(diǎn) -> 同機(jī)架 -> 同機(jī)房 –> 跨機(jī)房
• 控制大業(yè)務(wù)帶寬，主要是以下兩點(diǎn)：一是 Flume sink HDFS 實(shí)現(xiàn)壓縮機(jī)制，峰值帶寬 200Gb 降低到 40Gb 左右；二是分析計(jì)算依賴，對(duì)計(jì)算遷移控制跨機(jī)房計(jì)算的規(guī)模。
• 其他管控：比如硬件層面保證控制流優(yōu)先，這樣即使帶寬打滿也不會(huì)發(fā)生心跳信息無(wú)法傳遞導(dǎo)致集群崩潰

3. 新機(jī)房磁盤傾斜

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

• 支持可指定源節(jié)點(diǎn)，目的節(jié)點(diǎn)
• 直接從 DN 獲取 Blocks 信息，減輕 NN 壓力同時(shí)提高并發(fā)
• 源節(jié)點(diǎn)避免寫，控制讀
• 支持限速，水位可控，且可用于
• 機(jī)房數(shù)據(jù)遷移錯(cuò)峰運(yùn)行

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

4. 計(jì)算遷移

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

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

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

實(shí)時(shí)任務(wù)遷移參考離線部分，大同小異；Hbase 集群遷移請(qǐng)參考另一篇關(guān)于58 大數(shù)據(jù)平臺(tái)分享第三期：Hbase 專場(chǎng)。

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

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

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

① Hadoop3.X

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

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

② 云融合探索

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

▌精選問(wèn)題的回答

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

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

我們已經(jīng)基于 Flink 開(kāi)發(fā)了一棧式實(shí)時(shí)開(kāi)發(fā)平臺(tái) Wstream，支持使用 Sql 開(kāi)發(fā)實(shí)時(shí)程序，支持 DDL、Join，關(guān)于這些會(huì)在58大數(shù)據(jù)平臺(tái)分享第二期做具體介紹。

2. OLAP 選型怎么做？

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

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

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

本次的分享就到這里，謝謝大家。