作者 | 梁李印

責編 | 唐小引

出品 | CSDN（ID：CSDNNews）

滴滴出行作為一家出行領域的互聯網公司，其核心業務是一個實時在線服務。因此具有豐富的實時數據和實時計算場景。本文將介紹滴滴實時計算髮展之路以及平台架構實踐。

1.實時計算演進

隨著滴滴業務的發展，滴滴的實時計算架構也在快速演變。到目前為止大概經歷了三個階段，第一階段是業務方自建小集群；第二階段是集中式大集群、平台化；第三階段是 SQL 化。圖 1 標識了其中重要的里程碑，下面給出詳細闡述。

圖 1 滴滴實時計算演進之路

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

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

為了有效解決以上問題，滴滴從 2017 年年初開始構建統一的實時計算集群及平台。技術選型上，我們基於滴滴現狀選擇了內部用以大規模數據清洗的 Spark Streaming 引擎，同時引入 On-YARN 模式。利用 YARN 的多租戶體系構建了認證、鑒權、資源隔離、計費等機制。相對於離線計算，實時計算任務對於穩定性有著更高的要求，為此我們構建了兩層資源隔離體系。

第一層是基於 CGroup 做進程（Container）級別的 CPU 及內存隔離。第二層是物理機器級別的隔離。我們通過改造 YARN 的 FairScheduler 使其支持 Node Label。達到的效果如圖 2 所示：普通業務的任務混跑在同一個 Label 機器上，而特殊業務的任務跑在專用 Label 的機器上。

圖 2 基於 Node Label 的資源隔離體系

通過集中式大集群和平台化建設，基本消除了業務方自建小集群帶來的弊端，實時計算也進入了第二階段。伴隨著業務的發展，我們發現 Spark Streaming 的 Micro Batch 模式在一些低延時的報警業務及在線業務上顯得捉襟見肘。於是我們引入了基於 Native Streaming 模式的 Flink 作為新一代實時計算引擎。Flink 不僅延時可以做到毫秒級，而且提供了基於 Process Time/Event Time 豐富的窗口函數。基於 Flink 我們聯合業務方構架了滴滴流量最大的業務網關監控系統，並快速支持了諸如乘客位置變化通知、軌跡異常檢測等多個線上業務。

2.實時計算平台架構

為了最大程度方便業務方開發和管理流計算任務，我們構建了如圖 3 所示的實時計算平台。在流計算引擎基礎上提供了 StreamSQL IDE、監控報警、診斷體系、血緣關係、任務管控等能力。以下分別介紹各自的作用：

• StreamSQL IDE。

  下文會介紹，是一個 Web 化的 SQL IDE；

• 監控報警。

  提供任務級的存活、延時、流量等監控以及基於監控的報警能力；

• 診斷體系。

  包括流量曲線、Checkpoint、GC、資源使用等曲線視圖，以及實時日誌檢索能力。

• 血緣關係。

  我們在流計算引擎中內置了血緣上報能力，進而在平台上呈現流任務與上下游的血緣關係；

• 任務管控。

  實現了多租戶體系下任務提交、啟停、資產管理等能力。通過 Web 化任務提交消除了傳統客戶機模式，使得平台入口完全可控，內置參數及版本優化得以快速上線。

圖3 實時計算平台架構

3.實時規則匹配服務建設

在滴滴內部有大量的實時運營場景，比如「某城市乘客冒泡後 10 秒沒有下單」。針對這類檢測事件之間依賴關係的場景，用 Flink 的 CEP 是非常合適的。但是社區版本的 CEP 不支持描述語言，每個規則需要開發一個應用，同時不支持動態更新規則。為了解決這些問題，滴滴做了大量功能擴展及優化工作。功能擴展方面主要改動有：

• 支持 wait 運算元。

  對於剛才例子中的運營規則，社區版本是表達不了的。滴滴通過增加 wait 運算元，實現了這類需求；

• 支持 DSL 語言。

  基於 Groovy 和 Aviator 解析引擎，我們實現了如圖 4 所示的 DSL 描述規則能力。

圖4 通過 DSL 描述 CEP 規則

• 單任務多規則及規則動態更新。

  由於實時運營規則由一線運營同學來配置，所以規則數量，規則內容及規則生命周期會經常發生變化。這種情況每個規則一個應用是不太現實的。為此我們開發了多規則模式且支持了動態更新。

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

• SharedBuffer 重構。

  基於 Flink MapState 重構 SharedBuffer，減少每次數據處理過程中的狀態交互。同時剝離規則和用戶數據極大降低每次匹配的時候從狀態中反序列化的數據量；

• 增加訪問緩存（已貢獻社區）。

  緩存 SharedBuffer 數據中每次處理所需要更新的引用計數，延緩更新；

• 簡化 event time 語義處理。

  避免 key 在很分散情況下每次 watermark 更新時要遍歷所有 key 的數據；

• 復用 conditionContext（已貢獻社區）。

  減少條件查詢時對 partialMatch 元素的反覆查詢。

以上優化將 CEP 性能提升了多個數量級。配合功能擴展，我們在滴滴內部提供了如圖 5 所示的服務模式。業務方只需要清洗數據並提供規則列表 API 即可具備負責規則的實時匹配能力。

圖 5 實時規則匹配服務模式

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

4.StreamSQL 建設

正如離線計算中 Hive 之於 MapReduce 一樣，流式 SQL 也是必然的發展趨勢。通過 SQL 化可以大幅度降低業務方開發流計算的難度，業務方不再需要學習 Java/Scala，也不需要理解引擎執行細節及各類參數調優。為此我們在 2018 年啟動了 StreamSQL 建設項目。我們在社區 Flink SQL 基礎上拓展了以下能力：

• 擴展 DDL 語法。

  如圖 6 所示，打通了滴滴內部主流的消息隊列以及實時存儲系統。通過內置常見消息格式（如 json、binlog、標準日誌）的解析能力，使得用戶可以輕鬆寫出 DDL 語法，並避免重複寫格式解析語句。

圖 6 StreamSQL 內置打通消息隊列及實時存儲

• 拓展 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%的流計算業務量。

5.總結

作為一家出行領域的互聯網公司，滴滴對實時計算有天然的需求。過去的一年多時間裡，我們從零構建了集中式實時計算平台，改變了業務方自建小集群的局面。為滿足低延時業務的需求，成功落地了 Flink Streaming，並基於 Flink 構建了實時規則匹配（CEP）服務以及 StreamSQL，使得流計算開發能力大幅度降低。未來將進一步拓展 StreamSQL，並在批流統一、IoT、實時機器學習等領域探索和建設。

作者簡介：梁李印，滴滴出行大數據架構部高級技術專家，負責滴滴實時計算、OLAP 引擎研發、平台構建、業務支撐等工作。前阿里巴巴 Hadoop 集群雲梯負責人之一。《Hadoop 硬實戰》第一譯者。

本文為作者原創投稿，如需轉載，請與 CSDN 聯繫。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！