羅江宇：Flink Streaming在滴滴的大規模生產實踐

【IT168 專稿】本文根據羅江宇老師在2018年5月12日【第九屆中國資料庫技術大會】現場演講內容整理而成。

講師簡介：

   

羅江宇，滴滴出行資深研發工程師。浙江大學碩士，曾就職新浪微博，2016年加入滴滴出行，目前從事Flink業務支援，叢集穩定性保障和研發工作。

摘要： 

為了應對滴滴資料量爆炸性增長和對實時計算低延遲的高要求，滴滴引入Flink 實時計算框架，目前Flink Streaming已在滴滴的實時監控，實時BI，實時CEP ，和線上業務等領域有了廣泛的應用。本次演講主要介紹Flink Streaming在滴滴大規模生產的應用場景，以及分享生產中遇到的問題以及解決方法，從中獲取的經驗。

分享大綱：

1、Flink Streaming平臺化

2、Flink Streaming在滴滴的實踐

3、Flink Streaming展望與規劃

正文：

1、Flink Streaming平臺化

首先，我介紹一下滴滴引入Flink Streaming的背景，主要分為三部分：一是滴滴存在豐富的資料及應用場景，比如乘客、司機、交易以及軌跡資料等，在使用者下單過程中也會產生很多日誌資料；二是業務實時性要求越來越高；三是公司很多Storm或JStorm小叢集需要及時升級整合。由於Flink Streaming原生相容Storm和JStorm，因此轉向Flink Streaming的成本相對來說比較低。

作為滴滴大資料架構部，我們改造的主要目的，一是希望降低使用Flink Streaming服務的門檻，二是整合公司內的小叢集，降低運維成本，提升機器利用率；三是提升服務的穩定性與問題定位的效率。 

 

上圖為滴滴實時計算平臺整體架構，底層儲存使用HDFS、ES以及Druid，再上一層是Yarn排程層，再向上是目前滴滴正在使用的計算引擎——Flink Streaming和Spark Straeming， 最上層主要包括應用管控、WeblDE，SQL（建設中）以及診斷系統。

 

在Yarn計算資源管理部分，我們主要分為兩大類，一類是穩定性要求較高的業務獨佔機器（基於Label機制）；二是普通業務混布機器（基於CGroup機制）。如上圖下方所示，Label一般基於業務，每個業務分成一個Label，穩定性要求較高的業務使用佇列繫結Label，普通業務基本就是No-Label, 執行在混布環境。

為了支援平臺化Flink Streaming改造，我們做得第一件事是支援HDFS應用資源，主要因為flink提交應用不支援HDFS；二是限制JobManager至多執行一個應用；三是基於應用DAG情況進行計算資源申請；四是支援計算資源的動態縮擴。下面重點介紹下基於計算資源的動態縮擴。

 

上圖是計算資源擴容示例圖，比如我現在需要進行應用升級，原來的50個並行度變為100個並行度，我並不是先把申請的50個資源全部回收，再重新申請100個，而是直接在50個的基礎上追加。首先由應用管控部分提交應用到JobManager，JobManager計算應用所需資源後進行縮擴check，如果需要擴容，JobManager會先向Yarn RM申請，Yarn RM再向Hadoop Yarn申請擴容資源。會新增相應的TaskManager，這個過程還會涉及到調整networkbuffer。

   

縮容示意圖如上所示，同樣是由應用管控提交應用，計算所需資源之後進行縮擴check，JobManager主動check進行realease一些TM。在縮擴容的過程中，最重要的兩件事情就是計算所需資源和保持該資源。

接下來講講Flink流式任務開發與管控，Flink流式任務開發主要有三種方式，一是通過Web IDE，二是通過Streaming SOL（建設中），三是線下開發。流式任務管控就是管控web化，不需要客戶機，並且簡化提交應用的引數配置。

 

流式任務開發及管控整體流程如上所示，Web IDE、SQL以及線下開發接入應用管控平臺，整體再接入診斷系統，診斷系統主要用於分析調優。

 

上述為Web IDE介面，我們會在Web IDE上提供一些基本模板，可以多位使用者協同開發。在Web管控提交頁面，我們會列出叢集、所屬專案、公共使用者、任務名稱、任務類別、主程式等資訊，使用者基本不需要配置太多資訊。

Flink流式任務診斷體系如下圖所示，主要分為兩部分：Flink日誌和流式指標。 

 

日誌部分實時接入ES，我們可以通過Kibana和ES SQL查詢。由於ES層的資料只能保留有限的時間，如果使用者需要保持較長時間的資料進行分析，我們會考慮將日誌接入HDFS，然後通過Hive和UI檢視。流式指標直接接入Druid，然後通過監控大盤檢視流量和延遲，以及其他指標。

2、Flink Streaming在滴滴的實踐

Flink Streaming在滴滴的主要應用場景有四個：實時ETL、實時報表、實時監控和實時業務。接下來，我先分享一下實時閘道器日誌監控，一是主要支援select、groupby、filter和一定時間範圍內的window計算規則；二是支援計算規則的動態更新；三是基本覆蓋整個公司的閘道器日誌；四是資料量高峰期可達到每秒300萬以上；五是通過閘道器日誌監控提升線上業務排查問題效率。

   

以上是實時閘道器日誌監控整體圖，日誌Agent採集資料到Kafka，Flink Streaming會定時從計算規則後設資料管理中心拉取後設資料，Metric上報可進行自監控，最終結果輸入ES，業務方通過查詢ES進行DashBoard展示和告警； Flink Streaming計算應用的metric 上報到監控平臺，提供對監控計算應用的監控。 

 

以上是實時閘道器日誌監控規則，基本涵蓋groupby、select等指標。在這個過程中，我們遇到的問題大概可分為以下五類：一是資料量暴漲，計算資源不夠，這種情況常見於節假日前夕，提供兜底的方案是基於計算規則的降級方案。

二是機房網路可能存在故障，在我們實際生產中有兩個機房，為了防止因機房故障導致服務不可用，我們做了異地多活。

三是聚合結果明顯不正確，造成這種現象的原因可能是資料跨度較大，延遲資料較多，進而造成資料聚合結果不正確，我們的解決方案是構建延遲資料監控。

四是其他異常處理，主要包括Checkpoint異常和Kafka 異常，針對監控對時間延遲要求高，對延遲一定時間的資料沒有意義的情況，對checkpoint異常的處理策略進行優化和監控；而Kafka 的異常，主要發生在kafka的傳送的時候，由於kafka叢集升級或者網路抖動，導致kafka 傳送失敗的情況，針對kafka 傳送失敗的情況，提供合理的retries 和在最大retries 失敗後的skip策略。 

 

在實時規則引擎部分，其支援DSL和CEP程式碼規則，支援CEP規則動態更新，目前已上線的應用場景是實時運營，實時發放券和實時風控，並且由原來天級別的處理時間提升為實時處理。

實時規則引擎整體架構如上圖所示，從MQ和Kafka接入資料清洗，我們做了CEP規則後設資料管理中心，提供動態CEP運算元，通過Groovy方式解析規則並生成NFA，然後進行資料處理，這匹配過程中可能需要依賴外部特徵資料查詢，最後匹配結果輸出到Kafka，下游根據傳送到Kafka的匹配結果進行進一步處理。

   

實時規則描述部分從上至下依次為規則、序列運算元、condition描述和輸出運算元。在序列運算元層加入了wait和abortwith運算元，condition描述就是程式碼級別，此處主要是SQL。假如，beginwith是yes，followba是yes，wait是yes，abortwith是no，則最後輸出運算元。

實時規則引擎遇到的問題主要有以下四類：

1. pattern無法動態載入，每次更新需要重啟應用。解決方案是採用groovy動態語言，改造cep operator動態載入update NFA生效。

2. sharedBuffer的效能問題，每次元素到來會需要將之前匹配到的中間元素都rocksdb中獲取出來導致效能很差，基於社群的優化patch，在中間加了一些快取優化很好的滿足了業務需求。

3. cep的原本實現條件表達複雜，需要寫很多內部類利用aviator的表示式解析引擎，和json表達很好的簡化了資料匹配條件的描述。

4. cep本身無法表達notFollowedBy結尾型別的條件，而業務中確有很多類似的需求，通過開發類似wait語義的運算元將滿足了類似 begin().notFollowedBy().wait()這種業務需求的表達 。

3、Flink Streaming展望與規劃

根據滴滴的應用情況，我們總共提出了五點規劃：一是完善動態CEP，接下來會將考慮動態CEP與風控相結合，提升風控的實時性；二是構建Streaming SQL平臺，進一步降低使用門檻與開發成本；三是支援Flink Streaming任務平滑升級，主要滿足穩定性要求極高的應用的升級；四是支援流與維表Join和雙流Join(不借助外部儲存) ；五是拓寬Flink Streaming應用場景，未來可能會考慮向機器學習和IOT等方向擴充。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31077337/viewspace-2213334/，如需轉載，請註明出處，否則將追究法律責任。