羅江宇: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/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Flink CDC 系列 - Flink MongoDB CDC 在 XTransfer 的生產實踐MongoDB
- Flink MongoDB CDC 在 XTransfer 的生產實踐|Flink CDC 專題MongoDB
- Node 在滬江的大規模實踐
- Flink 引擎在快手的深度優化與生產實踐優化
- 位元組跳動 Flink 大規模雲原生化實踐
- Serverless 在大規模資料處理的實踐Server
- RocketMQ DLedger架構在小米的大規模實踐MQ架構
- 大規模 Hadoop 升級在 Pinterest 的實踐HadoopREST
- 基於 Flink 的實時數倉生產實踐
- Redis中國使用者組|唯品會Rediscluster大規模生產實踐經驗Redis
- 阿里超大規模 Flink 叢集運維實踐阿里運維
- 大規模機器學習在愛奇藝視訊分析理解中的實踐機器學習
- 劉博宇:Druid在滴滴應用實踐及平臺化建設UI
- Flink CDC 在大健雲倉的實踐
- 阿里巴巴開源限流降級神器Sentinel大規模生產級應用實踐阿里
- 用資訊科技打造大規模定製的生產模式模式
- 滴滴推理引擎IFX:千萬規模裝置下AI部署實踐AI
- Presto在滴滴的探索與實踐REST
- BES 在大規模向量資料庫場景的探索和實踐資料庫
- 機器學習與微博:TensorFlow在微博的大規模應用與實踐機器學習
- FLINK 在螞蟻大規模金融場景的平臺建設
- Apache RocketMQ 在阿里雲大規模商業化實踐之路ApacheMQ阿里
- 開源大資料生態下的 Flink 應用實踐大資料
- 騰訊大規模Hadoop叢集實踐Hadoop
- 影片生產大映象最佳化實踐
- RocketMQ Streams在雲安全及 IoT 場景下的大規模最佳實踐MQ
- docker搭建大規模測試環境的實踐Docker
- 實時數倉在滴滴的實踐和落地
- 服務網格在百度核心業務大規模落地實踐
- HDFS3.2升級在滴滴的實踐S3
- Flink在唯品會的實踐
- 攀登規模化的高峰 - 螞蟻集團大規模 Sigma 叢集 ApiServer 優化實踐APIServer優化
- Docker生產實踐(六)Docker
- Nebula Graph 在大規模資料量級下的實踐和定製化開發
- 資訊公交服務在滴滴的應用實踐
- Apache Flink在唯品會的實踐Apache
- Flink在美團的實踐與應用
- Flink 在米哈遊的落地實踐