導讀：58離線計算平臺基於 Hadoop 生態體系打造，單集羣4000+臺服務器，數百 PB 存儲，日40萬計算任務，面臨挑戰極大。58大數據平臺的定位主要是服務數據業務開發人員，提高數據開發效率，提供便捷的開發分析流程，有效支持數據倉庫及數據應用建設。通常大數據平臺通用基礎能力包括：數據存儲、實時計算、離線計算、數據查詢分析，本次分享將聚焦大數據平臺離線計算和大家一起系統的探討58在離線計算平臺建設實踐的思路、方案和問題解決之道。
本文主要內容包括：
-
58在集羣快速增長的過程中遇到的問題以及解決之道；
-
58大數據集羣跨機房遷移的相關工作，如何在5個月時間快速完成3000臺集羣服務的遷移工作。
▌數據平臺部簡介
數據平臺部是負責58統一大數據基礎平臺能力建設。平臺負責的工作主要包括以下幾部分：
-
數據接入：文本的收集，我們採用 flume 接入，然後用 kafka 做消息緩衝，我們基於 kafka client 打造了一個實時分發平臺，可以很方便的把 kafka 的中間數據打到後端的各種存儲系統上。
-
離線計算：我們主要基於 Hadoop 生態的框架做了二次定製開發。包括 HDFS、YARN、MR、SPARK。
-
實時計算：目前主要是基於 Flink 打造了一個一棧式的流式計算開發平臺 Wstream。
-
多維分析：我們主要提供兩組多維分析的解決方案。離線的使用 Kylin，實時的使用 Druid。
-
數據庫：在數據庫的這個場景，我們主要還是基於 HBase 的這個技術體系來打造了出來，除了 HBase 提供海量的 K-V 存儲意外，我們也基於 HBase 之上提供 OpenTSDB 的時序存儲、JanusGraph 圖存儲。
我們綜合以上技術框架支撐了公司上層的業務：如商業、房產、招聘等核心業務。 此外，整個數據平臺部打造了統一的運營管理平臺，各個用戶在整個數據平臺上 ( 包括離線平臺、實時平臺等 ) 使用的是同一套主賬號在管理平臺上做數據方面的管理，包括：元數據管理、成本預算、數據自助治理、以及運營監控的一些細節。
在上圖的右半部分我們簡單的介紹了幾個數據平臺的指標。Flume 每天的日誌採集量 240T，Haddop 單集羣服務器臺數4000+，Flink 每天進行超過6000億次的計算，Druid 已經構建超過 600 億條實時數據索引。
▌Hadoop 平臺建設優化
我們的 Hadoop 集羣從17年的1600臺->18年的2800臺->19年的4000臺。可以看到集羣的增長速度還是非常迅速的。在整個集羣中：HDFS 存儲數據150P+，YARN 每天調度超過8000萬的 Container， MR/Spark 每日計算任務總數40萬+、中間處理數據量超過 14P。在此基礎上集羣規模也在不斷增長，集羣穩定性能和效率對我們來說是一個比較大的挑戰。下面我將給大家介紹在上述背景下，我們關於 Hadoop 平臺建設以及優化的具體實踐。
我們將從以下幾個方面來做介紹：
1. 規模擴展
首先，對於大規模 HDFS 集羣可擴展性這一塊，我們採用的解決方案是 HDFS Fedoration。HDFS 最大的痛點的話是 NameNode 單點瓶頸的問題，這其中包括內存的問題以及小文件的問題。通過 Fedoration 使用多個 NN 來緩解元數據內存的壓力以及均衡元數據訪問的 RPC。
其次，通過 ViewFileSystem 對業務做統一。ViewFileSystem 有一個好處是它在客戶端實現，這樣它的穩定性和性能就有保證。當然，社區原生版本有一些缺點，就是不支持跨 mount 點 mv，這一點我們對它做了修復。另外，它的維護成本比較高，在58我們是通過控制用戶規模來保證低維護的成本，具體如下：通過58數據平臺運營管理一套主賬號體系，我們給每個業務一個大的根目錄，在第一層子目錄下只分配四個目錄，通過這種方式來管控目錄的數量來保證低成本維護，同時這樣做在發生業務變更時影響也非常小。
2. 穩定性殺手
雖然有 Fedoration 機制來均衡各個 NN 的壓力，但是對於單個 NN 壓力仍然非常大，各種問題時刻在挑戰 HDFS 穩定性，比如：NN RPC 爆炸，我們線上最大的 NS 有15億的 RPC 調用，4000+ 併發連接請求，如此高的連接請求對業務穩定影響很大。針對這個問題，我們使用"拆解+優化"的兩種手段相結合的方式來改進。拆解就是說我們把一些大的訪問，能不能拆解到不同的集羣上，或者我們能不能做些控制，具體案例如下：
-
Hive Scratch：我們經過分析 Hive Scratch 的臨時目錄在 RPC 調用佔比中達到 20%，對於 Hive Scratch 實際上每個業務不需要集中到一個 NS 上，我們把它均衡到多個 NS 上。
-
Yarn 日誌聚合：Yarn 的日誌聚合主要是給業務查看一些日誌，實際上他沒有必要那個聚合到 HDFS 上，只需要訪問本地就可以了。
-
ResourceLocalize：同樣把它均衡到各個 NS 上。
經過這種拆解就可以降低單個 NS 的壓力。
對於 RPC 的性能瓶頸還有很多，本文主要介紹以下幾種典型案例：
-
DN BlockReport：即 DataNode 全量塊彙報，目前 DN 都是大存儲的機器，存在單機 60T 數據、100w+ Block，這種情況下單機做一次 BlockReport 對性能的影響非常大。針對這種情況，我們的改進措施是降低彙報頻率，從1小時/次 降低到 10小時/次 ；
-
DN IBR ( Incremental Block Report )：即 DN 的增量塊彙報。在集羣比較繁忙的時候，增量塊彙報的規模也是比較龐大的，在這塊的優化中參考社區新版本的 issue，就是我們使用批量塊彙報的方式來降低增量塊彙報的頻率；
-
DN Liveless：即 DN 假死。有時候 NN 或者 DN 比較繁忙的時候會出現心跳超時的情況，這樣會導致 NN 會對心跳超時的情況做冗餘操作，單個 NN 的塊數量非常大，做冗餘的話對 RPC 的性能壓力也是很大的。這裏的做法是使用獨立心跳，避免"假死"導致百萬 block 冗餘。
核心鏈路優化：我們對線上出現的一些問題對核心鏈路做的優化，主要思想是提高並行度，比如：
-
PermissionCheck ---減少持鎖時間
-
QuotaManager ---避免遞歸，提高效率
-
ReplicationMonitor ---增加吞吐
-
choseTarget ---提高匹配效率
3. NS 間負載均衡
對於 NS 間負載均衡，提供了 FastCopy 工具來做數據的拷貝，因爲 Fedoration 已經做到了很好的數據本地化，沒有必要去做跨集羣拷貝，通過 FastCopy HardLink 的機制可以直接將 block 指向到目標 block。當然這種方案在做 NS 之間元數據拷貝的時候，還是有一些遷移的成本，這時候就需要業務來做一些配合。
4. GC 調優
在 GC 這塊，NN 線上最大堆內存達到了 230G，GC 調優我們使用的 CMS GC，這是一個比較成熟的調優方式。主要通過下述手段：
-
降低 Young GC 的頻率和時間：通過一些參數來減少它的頻率和參數
-
CMS GC initialmark & Remark
-
避免 Concurrent mode failure 和 Promotion failure ，避免它做 Full GC
5. 慢節點問題
慢節點問題是我們遇到典型問題之一，主要有三個場景：
慢節點問題一：DN IO Util 100%
我們線上集羣在業務快速擴增的過程中，曾經出現過大量 DN IO Util 100%的現象，而且 DN IO Util 100%的持續時間很有可能會超過二十分鐘甚至半個小時，這會導致業務讀取數據非常緩慢，甚至超時、失敗。對我們核心業務的影響是非常大的，比如對於某個有很多業務依賴的上游業務，如果這個上游業務的延時比較長，那麼所有的下游業務的延時將會不可控。針對這個問題，我們分析主要是由以下三個操作會導致這個問題的出現並做了改進，改進整體效果良好，改進後計算任務的執行時間提速了 25%。
-
第一：10min 間隔 CheckDir 的操作，改進措施：不檢查所有，只檢查父目錄，這樣會做到基本無 IO 消耗。
-
第二：10min間隔 du 操作，改進措施：改成 df 實現，改進後基本無 IO 消耗。由於 du 會掃描磁盤上的所有的塊，是非常重的一個操作，事實上在這裏我們不需要那麼精確，使用 df 是完全可行的。
-
第三：6h 間隔 directoryScan 操作，改進措施：掃描限速 & 低峯執行，改進後 IO 控制在30%。做限速避免持續佔用帶寬，避免高峯期執行操作，58 的高峯基本在凌晨至早晨時間 0：00 -9：00，我們在這個時間段不做這個操作，放在空閒時間。
慢節點問題二：讀數據
-
預讀支持：對於大數據量下客戶端讀 DN 的比較慢的情況，hadoop 本身提供的預讀方案是在隨機訪問情況下的優化，但是對於離線計算基本是順序讀的場景不能使用，我們對此做了擴展，對順序讀提供了預讀支持。
-
千兆機器持續負載優化：在58異構情況非常嚴重，之前1000多臺千兆機器，千兆機器會持續打滿負載。針對這種情況我們使用社區關於 DataNode 快速重啓的方案 ( HDFS-7928 )，基本可以在30S時間內重啓 DN，這樣我們通過快速重啓 DN 的方式把客戶端的請求分配到其他的節點上再還給他。
慢節點問題三：寫 pipeline 無限重試
客戶端寫一個塊的操作會在三個節點上都一個塊，我們線上遇到的一個比較嚴重的問題：在寫的過程中如果一個節點出現故障，會去不斷的重試將集羣中所有的幾點重試一遍然後失敗，這種情況社區也有對應 issue ( HDFS-9178 )，原因是在做 DN 的 pipeline 恢復的時候把異常的節點當成了正常的節點來做 pipeline 恢復的對象。
6. YARN 建設優化
Yarn 調度的優化主要是兩個方面：一個是穩定性，另一個效率方面。
穩定性：
① 服務穩定性：
服務穩定性主要針對於系統的核心模塊，下面介紹下線上易出現的核心問題：
-
YARN-4741：升級過程中大規模的 NM 重啓的時候容易出現千萬級的冗餘事件，這樣會造成 NM OOM 從而集羣會掛掉，因此需要對冗餘事件過濾。
-
異常 APP 過濾：在做 RM 切換的時候遇到的 App 異常狀態，導致 RM 直接掛掉
-
DNS：DNS 服務掛掉導致集羣宕機，主要是通過 cache 機制來解決，包括在集羣層面、硬件層面做 cache。
② 計算穩定性：
-
業務方面：提供標籤調度隔離，把業務做物理隔離保證重點業務的執行
-
Quene & APP 方面：提供優先級的支持，保證高優先級的任務先拿到資源
-
節點層面：container 做 Cgroup 的隔離，保證 container 的穩定性
③ 過載保護：
-
在集羣層面有過載保護措施，比如：最大用戶數，最大 APP 數，最大 container 數等。
YARN 調度吞吐保證：
-
減少調度規模怕從而減輕壓力：Hivesql 切換 sparkThriftServer，因爲 sparkThriftServer 是一個常駐的服務，在初始化時申請下資源後基本不會再去向 YARN 申請資源，切換後可以減少吞吐。
-
錯峯：核心任務優先保證，在空閒階段再跑一些非核心業務。
-
調度優化：YARN 調度主要有三個線程，三個線程共享一把鎖來做各自的鎖邏輯，所以一個優化思路就是解決這個鎖競爭的問題，另一個思路是對核心的調度邏輯做優化。
持鎖時間優化：
通過 Profiling 發現調度進程在排序操作的過程種需要消耗90%的 CPU 時間，而且在做排序的時候基本上只是讀的操作，沒有必要去拿鎖。另外調度的三個線程沒有必要都用排他鎖，我們可以做一個鎖降解，對於更新線程 updateThread 用讀鎖就可以了，另外我們需要做一個加鎖順序的保證來避免死鎖的情況。
核心計算邏輯 Profiling：
核心邏輯 Profiling 的幾種思路：
-
一是降低時間複雜度，社區使用的歸併排序的思想，複雜度爲 O(N * logN)，實際上調度的時候我們只需要找到一個適配的節點，通過優化可以將複雜度降爲 O(n + k * logN)；
-
二是通過空間換時間的思想，比如通過預計算、預取數來減少計算次數；
-
三是在做排序的時候對於一些已經不需要排序的，不需要資源的地方做優化。
整體優化完成以後調度系統提高到 3000 container/s，基本上滿足了我們的需求。
7. 計算引擎優化
接下來我們來介紹下關於計算引擎方面的優化，主要是下面幾個方面：
雲窗 Hive –> SparkSql：
雲窗是 58 使用非常廣泛的 Sql 查詢平臺，主要用在即席查詢場景。之前一直存在一個痛點問題：查詢引擎只有 Hive，因此查詢效率很受侷限。17年底的時候我們開始將查詢引擎由 Hive 轉向 SparkSql，在做即席查詢引擎轉換升級的時候我們做了一些調研，對比了 Impala，Presto 等等，結合 58 現狀我們最終使用 SparkSql 來替換了 Hive。當時 Spark 最新版本爲 Spark 2.2，基於穩定性考慮沒有激進的選擇使用最新的版本而是選擇了比較穩定的版本 Spark 2.1.2。另外支持 SparkSql 引擎，也對 SparkThriftServer、Zeppelin 等解決方案做了調研，綜合以下幾個方面我們選擇了 SparkThriftServer：
一是由於雲窗 Hive 主要是和前端 JDBC 的使用方式，這時候用 SparkThriftServer 改造起來就非常簡單；
二是需要在應用性上做些保證，比如業務可以實時查詢執行進度，可以組取消等相關操作；
三是雲窗 Hive 是提供給多個用戶使用需要，所以需要支持多租戶。
SparkThriftServer 多租戶：
多租戶的問題主要在權限這一塊，需要把各個業務的權限打通，這樣各個業務在做查詢的時候做到安全隔離；此外在計算方面，由於 SparkThriftServer 業務使用公共資源，也需要把重點業務的資源做隔離。
SparkSql 兼容 Hive 的實現：
我們需要保證雲窗 Hive 用戶的查詢和 SparkSql 的查詢做到一致性。主要用到下面四個問題：UDF 支持問題，語法兼容性問題，數據質量問題，參數兼容問題。這塊的解決方案比較簡單，當時是把雲窗 Hive 的所有語句遷移到 SparkSql 來做測試，根據測試的結果來修復相關的問題，最後修復了50+個 issue 把成功率提高到95%以上。
SparkThriftServer 平臺穩定性建設：
SparkThriftServer 平臺穩定性建設也做了比較多的工作，重點說以下幾點：
-
Spark 自身穩定性問題種 Spark Driver 內存管理的問題
-
保障服務的穩定性方面，通過 HA 機制提供多臺 SparkThriftServer 支持，另外在雲窗上層提供重試策略，這樣在下游出現問題但不影響上游情況下通過上游重試來提高運行成功率
-
通過一些任務管控做集羣的過載保護
-
降低集羣壓力：Spark 對集羣的壓力還是非常大的，特別是在不正確使用的情況下，我們需要對它對 HDFS 的壓力做一些管控，比如輸入輸出這一塊
SparkSql 上線運行後發現的一些問題：
比如在雲窗上 Hive 和 Spark 默認情況下使用了同樣的配置，在雲窗上用戶不會關心使用的是 Hive 還是 SparkSql，這樣存在一個問題就是很難對業務做一個針對性的調優，這裏我們做了一些優化，優化過程中主要參考了 Intel SparkAE 的一些特性。
-
最優 Shuffle Partition：Partition 數量的指定在各個階段都是一樣的，事實上很難達到一個最優的效果；
-
Join 的策略：原生的 join 策略是根據初始數據來做 join 策略，我們可以通過一些中間結果來做一些策略的改變；
-
數據傾斜：在做 Sql 查詢中我們遇到的比較多的情況就是數據傾斜，我們也是做了自動的數據傾斜的優化。做完這些優化後，線上的任務基本上都有2-3倍的提升，效果還是非常明顯的。
8. WSSM 平臺建設
對於大規模的集羣，運營能力還是很重要的，否則集羣開發人員會花費大量時間來做運維。運營主要在存儲和計算。
海量存儲一站式運營管理：
存儲運營有很多要做，比如目錄配額管控，權限控制，告警機制，成本的優化等。我們主要是通過 FSImage + EditLog 的方式拿到需要分析的數據存儲信息，集羣運營者分析獲取到的信息然後做相應的存儲優化策略。使用 FSImage + EditLog 一個好處就是對 NN 無影響。我們集羣運營每天可以對4000萬+目錄做冷熱、增長等方面的分析；運營用戶可以根據數據目錄的冷熱情況自定義生命週期等策略來管理數據目錄，通過目錄增長信息用戶可以知道數據的增長情況是否正常。我們也提供了自動化目錄壓縮的接入，業務想做數據治理的化可以一鍵接入；自動化壓縮有以下幾個特點：冷數據使用 GZIP 壓縮，熱數據使用 LZO 壓縮；提供數據完整性校驗機制。數據壓縮帶來效果還是比較明顯的，以19年實踐爲例：通過壓縮數據累計節省了 100P+ 空間，相當於千臺服務器的節省。
海量計算自主運營分析：
海量計算自助運營分析平臺可以避免很多重複工作，減少資源的浪費，提高業務開發以及集羣運維開發的工作效率。
我們是基於 LinkedIn 開源的大象醫生 Dr-elephant 做的擴展改進，在改進過程中主要解決幾個問題：
-
Dr-elephant 的擴展性問題，我們通過 AppList 派發到多臺 Dr-elephant 來支持擴展性問題。
-
對 spark 的各個版本做了兼容性的實現，比如：Spark2.1，Spark2.3
-
Dr-elephant 原生啓發式算法改進。改進後支持分析：MR 是否分配在慢節點上，container 的資源是否合理等。
下圖是我們運營管理的界面，其中左半部分是存儲方面，右半部分是計算方面的。
▌跨機房遷移
下面給大家介紹下數據平臺部在19年下半年做的跨機房遷移這方面的事情。
遷移背景：
-
全量遷移：3000臺機器，130P數據，40萬計算任務
-
老機房資源緊張，無法擴容，業務持續增長
-
低成本遷移，控制時耗，Hadoop 機位半年內騰空
-
其它：跨機房帶寬比較充裕 ( 2Tb )，延遲 2ms 左右 ( 機房內 0.1ms )；離線 Hbase 集羣混部，80臺 RS，100+表
方案預研以及選型結果：
常用方案——多集羣多機房
-
新機房搭建同套環境，穩定性好，改造少 ( 新版本特性可以直接使用 )
-
業務配合 ( 數據一致性驗證等 )，影響大，時間不可控
-
機器成本高
58方案——HDFS 單集羣多機房
-
業務透明 -> 影響小
-
老機房下線機器，擴容新機房 -> 成本低
-
先遷移數據節點，後遷移主節點
跨機房網絡
-
壓測跨機房性能影響15% 以內，網絡延時較好，可控
-
老機房峯值網絡吞吐 1.3T，帶寬充足
下面介紹遷移具體方案和實踐：
1. 單集羣跨機房 HDFS 數據遷移
數據從老機房遷移到新機房主要用到了 HDFS 的 Decommision 特性。這裏我們針對 decommision 存在的一些問題做了一些改進，改進後性能提升超過6倍，具體問題與方案如下：
不可指定機房：decommision 的數據目標節點是不確定的，如果直接使用 decommision 會產生較多的數據冗餘，所以我們在數據路由上做了改進，讓 decommision 可以支持指定機房，這樣下線的時候就可以將數據直接 decommision 到新機房。
性能：decommision 本身性能較差吞吐量小且對 NameNode 的壓力較大，在這裏做了如下的改進：
-
dfs.namenode.replication.max-streams
-
降低 NN RPC 負載，充分利用 DN 機器帶寬 ( HDFS-7411，HDFS-14854 )
穩定性：decommision 存在一些穩定性問題，比如：不能正常結束，這裏我們參考社區 issue(HDFS-11847)，做了 decommision 的監控工具，分析 decommision 不能結束的具體原因然後做針對性的處理。另外在 decommision 的執行過程中可能會出現塊丟失問題，線上曾經出現丟失幾百萬個塊，還好後來數據做了及時修復，此處參考 HDFS-11609。
此外，我們是在低峯期執行 decommision 以降低影響。爲保證服務穩定下線速率保持在每天下線50臺，基本在5個月的時間內完成集羣遷移。
2. 網絡
在實踐過程中，我們發現網絡急劇增長，最大到 1.8T 接近上限，非常危險了，針對這個問題我們做了如下分析。
-
第一，因爲集羣是異構的，集羣中有大量千兆機器，在遷移過程中千兆機器在持續的下線，這樣很多計算落在了萬兆機器，從而增長了帶寬；
-
第二，在遷移完成後，我們會千兆機器的網卡升級到萬兆，因爲網絡的性能提升，把帶寬提升上去了。
在網絡降低帶寬方面的優化策略：
-
跨機房讀寫策略，整體策略完成後跨機房帶寬降低50%，具體如下：首先需要支持機房網絡拓撲結構，支持本機房寫。另外考慮到老機房很少有存儲的情況，這裏做動態配置策略：默認是本機房寫，通過修改配置可以隨機寫或者指定機房寫。在讀方面優先級順序由高到低爲: 同節點 -> 同機架 -> 同機房 –> 跨機房
-
控制大業務帶寬，主要是以下兩點：一是 Flume sink HDFS 實現壓縮機制，峯值帶寬 200Gb 降低到 40Gb 左右；二是分析計算依賴，對計算遷移控制跨機房計算的規模。
-
其他管控：比如硬件層面保證控制流優先，這樣即使帶寬打滿也不會發生心跳信息無法傳遞導致集羣崩潰
3. 新機房磁盤傾斜
在遷移過程中，遇到第二個比較大問題：新機房磁盤傾斜比較嚴重，大量機器存儲超過了95%，此時節點出現 unhealthy 情況。由於機器在計算方面做了標籤隔離，如果存儲佔滿對重要業務運行穩定性影響非常大，需要有一個快速均衡方案來均衡高負載節點。這裏我們使用 HDFS Balance 作爲一個解決方案，同時優化了 HDFS Balance 的幾個痛點問題：
-
支持可指定源節點，目的節點
-
直接從 DN 獲取 Blocks 信息，減輕 NN 壓力同時提高併發
-
源節點避免寫，控制讀
-
支持限速，水位可控，且可用於
-
機房數據遷移錯峯運行
通過以上方案，日支持 PB 級數據 balance，線上975臺90%水位 DN5 個工作日完成均衡。
4. 計算遷移
計算服務更像是一個無狀態的服務，也不需要做單集羣跨機房，做起來就比較輕鬆。只需要在新機房部署一個新的 YARN 集羣就可以，也可以保證計算任務不會跨機房。在整個遷移過程以隊列爲粒度，根據隊列映射機房，在遷移初期給任務更富裕的資源以保證任務運行更加穩定。遷移期間會做一些灰度檢驗，此時需要業務配合，同時也會對遷移前後任務的運行情況做分析對比以確保遷移不影響業務的正確性。
整個遷移過程如上圖所示，期間由業務與平臺相互協作。業務主要評估遷移前後的差異，包括性能、成功率等。其他任務都是由平臺來做，分爲離線、實時、Hbase 等部分，其中離線部分流程爲：
新機房資源準備，業務梳理 -> 測試新機房性能 –> 業務一隊列粒度切換新機房 ->回收老機房資源 -> 搬遷至新機房擴容
實時任務遷移參考離線部分，大同小異；Hbase 集羣遷移請參考另一篇關於58 大數據平臺分享第三期：Hbase 專場。
整體遷移過程：先遷移計算和存儲再遷移 HDFS 等核心服務，核心服務通過域名化變更來遷移，這裏在源生 Hadoop 做了改進增加了對異常捕獲的處理。
▌後續規劃
後續規劃主要對兩個方面，一個 Hadoop3.X，一個是雲融合。
① Hadoop3.X
Hadoop 現在版本是在 CDH-Hadoop 2.6 做的定製，後續計算對 Hadoop 升級到 3.X。主要對 Hadoop3.X 兩個特性比較看好：
-
第一：對 EC ( erasure coding 糾刪碼 ) 的支持，可以節省很大的存儲空間
-
第二：對象存儲 ( ozone )
② 雲融合探索
目前公司私有云主要支持在線的業務，大數據平臺主要支持離線的業務。在線業務一般晚上資源比較空閒，離線業務晚上資源比較繁忙，因此考慮是否可以錯峯相互借用資源以降低成本。
▌精選問題的回答
1. 批流統一怎麼做？
答：目前在58 已經在將 Storm 遷移到了 Flink，這個具體方案的文章已經發布在 58 技術公衆號上，感興趣的同學可以去公衆號查看。另外 Spark Streaming 我們也建議業務可以遷移到 Flink 上，根據部分遷移業務來看，資源的使用有比較大的提升，而且在流方面整理來看 Flink 比 SparkStreaming 更有優勢，無論是功能方面還是架構方面，這些都有大量的文章介紹。
我們已經基於 Flink 開發了一棧式實時開發平臺 Wstream，支持使用 Sql 開發實時程序，支持 DDL、Join，關於這些會在58大數據平臺分享第二期做具體介紹。
2. OLAP 選型怎麼做？
答：在58 OLAP 場景目前是使用 Kylin 來支持離線的業務，比如 BI 報表，Kylin 的話建議維度不要超過50維度，超過維度支持的會不友好；另外 Druid 來支持實時的場景，比如廣告效果的評估，用戶行爲分析等。
Kylin 和 Druid 都是預計算的思想，因此查詢場景比較受限，而且對其他組件依賴較重導致維護成本較高，目前業界也有一些新的優秀解決方案，比如 ClickHouse 這些沒有對其他組件的依賴相對來說比較輕量。這些組件性能上基本上都是採用列式存儲的思想，提高硬件使用效率等。
Kylin、Druid 目前從使用上來看是比較成熟的 ( 包括對 Sql 語法的支持等 )，58數據平臺目前也在做 OLAP 相關的調研，爭取儘早落地，屆時再與大家分享。
往期推薦
▬
初識ClickHouse：來自戰鬥民族的OLAP利器
大數據之數據交換和存儲序列化利器 Avro
認識 Delta Lake：讓數倉進化到數據湖
MapReduce Shuffle 和 Spark Shuffle 結業篇
