滴滴實時計算髮展之路及平臺架構實踐

時間 2019-11-06

標籤滴滴實時計算發展之路平臺架構實踐欄目系統架構简体版

原文原文鏈接

---toc: truetitle: 滴滴實時計算髮展之路及平臺架構實踐date: 2019-08-25tags:git

Flink
大數據
---

滴滴的核心業務是一個實時在線服務，所以具備豐富的實時數據和實時計算場景。本文將介紹滴滴實時計算髮展之路以及平臺架構實踐。github

實時計算演進

隨着滴滴業務的發展，滴滴的實時計算架構也在快速演變。到目前爲止大概經歷了三個階段：sql

業務方自建小集羣階段；
集中式大集羣、平臺化階段；
SQL化階段。

下圖標識了其中重要的里程碑，稍後會給出詳細闡述：json

在2017年之前，滴滴並無統一的實時計算平臺，而是各個業務方自建小集羣。其中用到的引擎有Storm、JStorm、Spark Streaming、Samza等。業務方自建小集羣模式存在以下弊端：緩存

須要預先採購大量機器，因爲單個業務獨佔，資源利用率一般比較低；
缺少有效的監控報警體系；
維護難度大，須要牽涉業務方大量精力來保障集羣的穩定性；
缺少有效技術支持，且各自沉澱的東西難以共享。

爲了有效解決以上問題，滴滴從2017年年初開始構建統一的實時計算集羣及平臺。微信

技術選型上，咱們基於滴滴現狀選擇了內部用大規模數據清洗的Spark Streaming引擎，同時引入On-YARN模式，並利用YARN的多租戶體系構建了認證、鑑權、資源隔離、計費等機制。session

相對於離線計算，實時計算任務對於穩定性有着更高的要求，爲此咱們構建了兩層資源隔離體系：架構

第一層是基於CGroup作進程（Container）級別的CPU及內存隔離；
第二層是物理機器級別的隔離。

咱們經過改造YARN的FairScheduler使其支持Node Label。達到的效果以下圖所示：框架

普通業務的任務混跑在同一個Label機器上，而特殊業務的任務跑在專用Label的機器上。機器學習

經過集中式大集羣和平臺化建設，基本消除了業務方自建小集羣帶來的弊端，實時計算也進入了第二階段。

伴隨着業務的發展，咱們發現Spark Streaming的Micro Batch模式在一些低延時的報警業務及在線業務上顯得捉襟見肘。因而咱們引入了基於Native Streaming模式的Flink做爲新一代實時計算引擎。

Flink不只延時能夠作到毫秒級，並且提供了基於Process Time/Event Time豐富的窗口函數。基於Flink咱們聯合業務方構架了滴滴流量最大的業務網關監控系統，並快速支持了諸如乘客位置變化通知、軌跡異常檢測等多個線上業務。

實時計算平臺架構

爲了最大程度方便業務方開發和管理流計算任務，咱們構建瞭如圖所示的實時計算平臺：

在流計算引擎基礎上提供了StreamSQL IDE、監控報警、診斷體系、血緣關係、任務管控等能力。各自的做用以下：

StreamSQL IDE。下文會介紹，是一個Web化的SQL IDE；
監控報警。提供任務級的存活、延時、流量等監控以及基於監控的報警能力；
診斷體系。包括流量曲線、Checkpoint、GC、資源使用等曲線視圖，以及實時日誌檢索能力。
血緣關係。咱們在流計算引擎中內置了血緣上報能力，進而在平臺上呈現流任務與上下游的血緣關係；
任務管控。實現了多租戶體系下任務提交、啓停、資產管理等能力。經過Web化任務提交消除了傳統客戶機模式，使得平臺入口徹底可控，內置參數及版本優化得以快速上線。

實時規則匹配服務建設

在滴滴內部有大量的實時運營場景，好比「某城市乘客冒泡後10秒沒有下單」。針對這類檢測事件之間依賴關係的場景，用Fink的CEP是很是合適的。

可是社區版本的CEP不支持描述語言，每一個規則須要開發一個應用，同時不支持動態更新規則。爲了解決這些問題，滴滴作了大量功能擴展及優化工做。功能擴展方面主要改動有：

支持wait算子。對於剛纔例子中的運營規則，社區版本是表達不了的。滴滴經過增長wait算子，實現了這類需求；
支持DSL語言。基於Groovy和Aviator解析引擎，咱們實現了以下圖所示的DSL描述規則能力：

單任務多規則及規則動態更新。因爲實時運營規則由一線運營同窗來配置，因此規則數量，規則內容及規則生命週期會常常發生變化。這種狀況每一個規則一個應用是不太現實的。爲此咱們開發了多規則模式且支持了動態更新。

除了功能拓展以外，爲了應對大規模運營規則的挑戰，滴滴在CEP性能上也作了大量優化，主要有：

SharedBuffer重構。基於Flink MapState重構SharedBuffer，減小每次數據處理過程當中的狀態交互。同時剝離規則和用戶數據極大下降每次匹配的時候從狀態中反序列化的數據量；
增長訪問緩存（已貢獻社區）。緩存SharedBuffer數據中每次處理所須要更新的引用計數，延緩更新；
簡化event time語義處理。避免key在很分散狀況下每次watermark更新時要遍歷全部key的數據；
複用conditionContext（已貢獻社區）。減小條件查詢時對partialMatch元素的反覆查詢。

以上優化將CEP性能提高了多個數量級。配合功能擴展，咱們在滴滴內部提供瞭如圖所示的服務模式：

業務方只須要清洗數據並提供規則列表API便可具有負責規則的實時匹配能力。

目前滴滴CEP已經在快車個性化運營、實時異常工單檢測等業務上落地，取得了良好的效果。

StreamSQL建設

正如離線計算中Hive之於MapReduce同樣，流式SQL也是必然的發展趨勢。經過SQL化能夠大幅度下降業務方開發流計算的難度，業務方再也不須要學習Java/Scala，也不須要理解引擎執行細節及各種參數調優。

爲此咱們在2018年啓動了StreamSQL建設項目，在社區Flink SQL基礎上拓展瞭如下能力：

擴展DDL語法。以下圖所示，打通了滴滴內部主流的消息隊列以及實時存儲系統(StreamSQL內置打通消息隊列及實施存儲)：

經過內置常見消息格式（如json、binlog、標準日誌）的解析能力，使得用戶能夠輕鬆寫出DDL語法，並避免重複寫格式解析語句。
拓展UDF。針對滴滴內部常見處理邏輯，內置了大量UDF，包括字符串處理、日期處理、Map對象處理、空間位置處理等。
支持分流語法。單個輸入源多個輸出流在滴滴內部很是常見，爲此咱們改造了Calcite使其支持分流語義。
支持基於TTL的join語義。傳統的Window Join由於存在window邊界數據突變狀況，不能知足滴滴內部的需求。爲此咱們引入了TTL State，並基於此開發了基於TTL Join的雙流join以及維表join。
StreamSQL IDE。前文提到平臺化以後咱們沒有提供客戶機，而是經過Web提交和管控任務。所以咱們也相應開發了StreamSQL IDE，實現Web上開發StreamSQL，同時提供了語法檢測、DEBUG、診斷等能力。

目前StreamSQL在滴滴已經成功落地，流計算開發成本獲得大幅度下降。預期將來將承擔80%的流計算業務量。

總結

做爲一家出行領域的互聯網公司，滴滴對實時計算有自然的需求。

過去的一年多時間裏，咱們從零構建了集中式實時計算平臺，改變了業務方自建小集羣的局面。爲知足低延時業務的需求，成功落地了Flink Streaming，並基於Flink構建了實時規則匹配（CEP）服務以及StreamSQL，使得流計算開發能力大幅度下降。將來將進一步拓展StreamSQL，並在批流統1、IoT、實時機器學習等領域探索和建設。