作者 | 樑李印

責編 | 唐小引

出品 | CSDN（ID：CSDNNews）

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

實時計算演進

隨著滴滴業務的發展，滴滴的實時計算架構也在快速演變。到目前為止大概經歷了三個階段，第一階段是業務方自建小叢集；第二階段是集中式大叢集、平臺化；第三階段是 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 我們聯合業務方構架了滴滴流量最大的業務閘道器監控系統，並快速支援了諸如乘客位置變化通知、軌跡異常檢測等多個線上業務。

實時計算平臺架構

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

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

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

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

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

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

圖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 已經在快車個性化運營、實時異常工單檢測等業務上落地，取得了良好的效果。

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

總結

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

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

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

2018 中國大資料技術大會

◆

BDTC 2018

◆

BDTC 2018中國大資料技術大會攜主題“大資料新應用”再度強勢來襲。本次大會由華東師範大學副校長、教授周傲英，百度商業智慧實驗室主任熊輝，阿里巴巴副總裁李飛飛三位會議主席對大會內容把關，多位兩院院士參與指導，由最瞭解行業痛點的一線從業者為同行打造。

掃描下方二維碼或閱讀原文快速購票。現在購票還有機會獲得大資料圖書一本（中國科學院院士梅巨集主編的《大資料導論》或華中科技大學教授金海主編的《大資料處理》），數量有限！