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

趙鈺瑩發表於2018-08-31

【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/,如需轉載,請註明出處,否則將追究法律責任。

相關文章