寫在前面
随着滴滴内部技術棧的不斷統一，實時相關技術元件資源的不斷整合，各業務線實時資料相關開發經驗的不斷沉澱，基本形成了一套面向公司不同業務場景需求的最佳技術選型和具體落地方案。但同時我們也發現，大部分實時開發同學在做實時資料建設過程中會籠統的把實時資料建設等同于 flink 資料開發，常常把實時資料處理過程中的其他相關元件放在邊緣位置，無法高效的整合資料處理元件來完成不同業務場景的實時需求。為此，我們從目前公司内的典型實時資料開發方案出發，整理了不同場景下的實時資料建設技術選型，幫助大家更好的進行實時資料建設，為業務持續輸出高品質且穩定的實時資料價值。
本篇文章分為：
1. 實時資料開發在公司内的主要業務場景
2. 實時資料開發在公司内的通用方案
- 資料源
- 資料通道
- 同步中心
- 實時開發平台
- 資料集
- 實時資料應用
3. 特定場景下的實時資料開發元件選型
- 實時名額監控場景
- 實時 BI 分析場景
- 實時資料線上服務場景
- 實時特征和标簽系
4. 各元件資源使用原則
5. 總結和展望
1. 實時資料開發在公司内的主要業務場景
目前公司内各業務線使用實時資料的主要場景分為四塊：
實時名額監控：例如産研側名額穩定性監控，業務側實時名額異常波動監控，營運大盤業務健康度監控等。這類場景的主要特點是對資料及時性要求很高，且高度依賴時間序列，主要依賴時間軸作為分析度量，資料分析複雜度一般。
實時BI分析：主要面向資料分析師和營運同學配置實時看闆或者實時報表，包括公司營運大盤、實時核心看闆，展廳實時大屏等。這類場景的主要特點是對資料準确性要求極高，對資料及時性容許有一定延遲，需要支援較複雜的資料分析能力。
實時資料線上服務：主要以 API 接口的方式提供實時名額，多用于為資料産品提供實時資料。這類場景對資料及時性和準确性要求較高，名額計算複雜度一般，對接口查詢QPS 要求非常高，在提供實時資料的同時需要保證整個服務的高可用。
實時特征：主要用于機器學習模型更新、推薦預測、推薦政策、标簽系統等方面。這類場景對資料及時性、準确性、查詢 QPS 要求一般，但其本身實作邏輯對實時計算引擎的使用要求較高，要求實時計算引擎有較強的實時資料處理能力，較強的狀态存儲能力，較豐富的外部元件對接能力。
2. 實時資料開發在公司内的通用方案
公司内實時資料開發通用方案元件主要包括：實時資料采集、資料通道、資料同步、實時資料計算、實時資料集存儲、實時資料應用共六個部分，目前這六個部分使用的元件基本穩定，各元件都可以在相應的平台上靈活使用。
資料源
目前公司主要的實時資料來源是 MySQL 産生的 binlog 日志和業務伺服器上産生的 puliclog日志，MySQL 的 binlog 日志是通過阿裡開源的采集工具 Canal 完成，Canal 的工作原理是把自己僞裝成 MySQL slave，模拟 MySQL slave 的互動協定向 MySQL Master 發送 dump 協定，MySQL master 收到Canal發送的 dump 請求，開始推送 binary log 給 Canal，Canal 解析 binary log 最終把結果發送給 DDMQ 中；Public log 是公司内規範定義的業務日志，通過在業務伺服器上部署 LogAgent，由 Agent Manager 進行處理并生成采集配置，在 Agent 通路 Agent Manager 拉取采集配置之後，采集任務開始執行，最終把日志發送到 kafka 中。
資料通道
公司主流的消息通道是 DDMQ 和 kafka，所有的binlog日志源頭都來自 DDMQ，DDMQ 是滴滴2018年底開源的産品，他使用 RocketMQ 和 kafka 作為消息的低層存儲引擎，主要特點是支援延遲和事務消息，同時也支援複雜的消息轉發過濾功能；public log 主要使用 kafka 作為消息通道，實時任務中間鍊路的開發也主要使用 kafka 作為存儲媒介，其主要特點是高可擴充性和生态完善，與 Flink 配合開發效率極高，元件運維很友善。
同步中心
主要功能是把從源頭采集的資料，根據業務需要進行離線和實時資料分離。平台對離線場景所需的資料以 DataX 為基礎開發的資料鍊路同步功能，完成資料端到端的資料同步并把結果落盤到 hdfs 中。對實時場景所需的資料，使用内嵌實時計算引擎的 Dsink 任務完成資料采集配置并把結果推送到 kafka 消息隊列中，同時也會把資料落盤到 hdfs 中建構離線增量或全量 ods 表。
實時開發平台
目前公司内實時任務開發已經全部整合到數夢（一站式資料開發平台）的實時開發平台上，支援 flink jar 和 flink sql 兩種模式，截止2022年6月平台上運作的實時任務中 jar 任務占8%，sql 任務占92%。在日常的實時任務開發中推薦使用 Flink 1.12的 SQL 文法完成實時任務的開發，一方面保證名額口徑的一緻性，另一方面也能提高實時任務的可維護性。使用者在任務開發過程中，建議引入并使用本地調試功能，盡可能規避實時任務開發過程中的錯誤，提高實時任務上線成功率。通常我們在實時開發平台上主要完成的工作是ETL操作或輕度彙總名額的計算，然後把處理結果寫入下遊 sink 中。
圖為本地調試功能流程圖
資料集
計算結果的下遊 sink 一般包括 Kakfa、druid、Clickhouse、MySQL、Hbase、ES、fusion 等。對于實時任務的中間結果或者實時數倉的 dwd 層資料我們會寫入 kafka 中；對于用于名額監控報警的資料我們會寫入 Druid 中，利用 druid 時序資料庫的特性提高實時名額的監控性能；對于業務bi分析的場景可以把資料寫入 Clickhouse 中來配置多樣化BI看闆；使用flink完成名額計算的結果資料也可以直接寫入 mysql，Hbase，ES 或者 fusion 中，這裡的具體選型我們将在下一章具體業務場景下做具體說明。目前各下遊 sink 已經整合進平台，對于使用 druid 的情況一般需要在 Woater（統一名額監控平台）上配置 Datasource，對于使用 Clickhouse 的情況一般需要在數易（BI分析平台）上配置資料集。
監控報警
實時BI分析
實時資料應用
對于實時結果資料，常用的使用方式包括在 Woater （統一名額監控平台）平台上建立實時名額，同時配置對應的實時看闆或者實時監控報警，滿足業務分鐘級的結果名額監控和實時曲線分析。也可以在數易（BI分析平台）上使用數夢流表( Druid 的 Meta 化表）或者 ClickHouse 資料集來配置實時報表，滿足業務側不同的BI分析需求。
3. 特定場景下的實時資料開發元件選型
以上鍊路是目前實時任務開發的主要開發鍊路，在實時開發過程中，結合業務具體需要和各平台的能力優劣，我們需要具體問題具體分析，根據不同業務場景，選擇最合适的開發選型。
實時名額監控場景
場景特點：對時間序列依賴明顯，對名額及時性要求較高，對名額精确度一般，對查詢 QPS 要求較高，對實時資料産出穩定性要求較高。
具體鍊路：
該類場景建議在 Woater （統一名額監控平台）上配置 DataSource，基于監控要求設定對應的名額列和次元列，為提升查詢效率需要配置聚合粒度，常用聚合粒度為30s或1min，同時對于需要計算UV類名額的場景，需要把對應的名額列字段設定為 hyperUnique 類型來提高計算性能，通過設定 druid 的消費分區來提高 druid 消費 topic 資料的能力，一般建議 topic 分區數是 druid 分區數的偶數倍。通過 DataSource 配置的實時名額用于配置實時監控看闆和實時監控報警。
核心重保鍊路：對于核心的監控場景，為了保障實時鍊路的穩定性和及時性，需要進行雙鍊路開發。
從原始資料源開始做實時資料處理過程的雙鍊路，包括 FLink 任務雙活，結果 topic 雙活，Druid 表雙活三個部分，同時需要支援實時名額級别的雙活切換，實作穩定的名額查詢，也避免下遊監控報警出現誤報的情況。
實時 BI 分析場景
場景特點：不完全依賴時間序列，對實時名額準确性要求高，能容許一定的時間延遲，對查詢 QPS 要求一般，需要支援靈活的次元+名額組合查詢。
具體鍊路：
這類場景的主要方案是在 flink 任務中把需要的次元資訊都盡可能打平，然後把打平的實時資料微批寫入到 Clickhouse 的本地表中。我們以 ClickHouse 的 local 表作為底表，下遊根據各類業務需要配置不同的物化視圖表，對于需要基于主鍵做實時去重的場景可以使用CK的 ReplacingMergeTree 引擎實作，之後使用實時去重物化視圖表作為數易（BI分析平台）的資料集或者數鍊（資料服務化平台）接口查詢底表供下遊配置BI看闆；
對于确定次元和名額的看闆場景為了提高查詢性能也可以在 ClickHouse 的 local 表基礎上，基于業務需要的次元字段使用 AggregatingMergeTree 引擎建立聚合視圖表。這樣可以滿足下遊數易配置看闆或者提供數連結口的需求；最後一種是不需要實時去重和預聚合的普通場景，可以把 fink 大屏的資料或者初步預聚合的資料寫入CK的普通分布式表中，直接配置數易資料集讓使用者自行配置業務所需的名額看闆。
三類表選擇的主要原則：
- 對業務名額準确性要求極高且有明确去重主鍵的業務場景，建議使用CK的實時去重視圖表。
- 對業務名額準确性較高，有明确的次元和名額定義，且查詢邏輯較複雜或者查詢 QPS 較高的場景，建議做預聚合操作，使用CK的聚合視圖表。
- 對業務量不大，業務變更邏輯頻繁的場景，建議前期直接使用CK的分布式普通表提供下遊看闆配置，滿足業務的快速疊代和取數需求。
實時資料線上服務場景
場景特點：對實時名額準确性要求高，對查詢 QPS 要求較高，對資料及時性要求一般
具體鍊路：
這類場景主要特點是需要把所需的實時名額做各類前置處理，一種方式是把所需要的實時名額在 flink 任務中完成計算，把最終的結果實時寫入到 Mysql 或者 Hbase 等支援實時更新的存儲中，供下遊資料服務平台進行接口封裝。這類方案适用于業務邏輯變更不頻繁且需要提供資料服務的場景；另一種方式是把聚合邏輯下移，flink任務主要做資料内容打寬和簡單的預聚合，主要的名額統計工作交由下遊的 OLAP 引擎計算，資料服務平台通過封裝 OLAP 引擎來提供接口查詢服務。這樣做的好處是在業務名額邏輯頻繁變更的情況下也能使用 OLAP 的預聚合能力提供高效的實時名額服務，缺點是對 OLAP的查詢壓力較大，需要提供更多的資源供 OLAP 消耗才能保證服務的高 QPS。
實時特征和标簽系統
場景特點：對實時名額準确性要求一般，對查詢 QPS 要求較高且涉及到較大的實時狀态運算，需要支援實時和離線名額融合的情況。
具體鍊路：
該類場景一般會有明确的名額列和次元列，需要把大量的實時特征或者名額标簽接入平台，方案一是直接通過 topic 讓平台消費資料，平台封裝後提供特征或者标簽服務，方案二是利用 Hbase 和 Fusion 基于強大的主鍵更新能力，把實時和離線标簽都灌入其中後接入平台的方式提供特征服務或者标簽服務，供下遊算法同學使用。
4. 各元件資源使用原則
實時資料開發涉及到的元件較多，各元件在使用過程中建議遵循基本原則，做到資源充分利用，在滿足實時任務開發的前提下，節約大量不必要的成本開銷。
資料采集：單一采集原則，對于業務需要的實時名額開發，上遊資料源盡可能做到複用，保證明時和離線 ods 層統一。
ddmq：一個 flink 任務對應一個 ddmq 消費組，支援多個 topic 使用一個消費組，不建議同一個消費組在不同實時任務中使用。
kafka：單分區流量建議不超過3MB/s，重要的實時任務kafka存儲時間需要控制在48~72小時左右，至少保證能回溯2天的曆史資料。
Flink：kafka 和 ddmq 的 source 并發數需要嚴格與 kafka 和 ddmq 設定的分區數一緻，這樣的消費性能最佳。公司内 flink 任務的單TM資源是固定的 slot = 2、taskmanagermemory = 4096、containers.vcores = 2 根據業務場景不同可以做适當調整，對于純ETL場景可以适當調大單TM的slot數量，對于含有較大記憶體占用的任務可以适當調大 taskmanagermemory 數值。在正常實時任務開發過程中消費 kafka 任務的全局并發建議和 source 并發一緻，消費 ddmq 的全局并發需要根據 ddmq 的流量确定，流量在(1000±500)區間的場景全局并發設定為3，超過的場景更加該比例折算，具體需要根據業務計算邏輯中算子耗時最大值預估。
druid：建立druid表時一定要設定聚合粒度，建議粒度為30s或者1min，資料存儲周期預設為3個月，在确定的業務場景中建立的 druid 表需要明确次元和名額字段，次元字段盡可能使用 String 類型，Druid 對 String 類型做了 bitmap 和反向索引優化；名額字段在滿足業務使用的前提下，盡可能使用預估類型來提高實時名額的計算性能。
Clickhouse：Flink 實時寫入任務預設間隔不小于30s，寫入并行度盡量控制在10以内，CK表資料存儲周期控制在1個月左右，必須按照時間作為分區字段，其他類型的字段無法作為分區。實時資料寫入場景推薦使用 Flink2Ck native connector 模式寫入，提高實時寫入的穩定性，同時減少CK的CPU消耗；Flink2CK寫入吞吐量建議控制在20M/s（單并發）以内，間接保障CK叢集的穩定性。
5. 總結和展望
本文主要從目前滴滴具體的業務場景出發總結了主流的實時任務開發方案以及技術棧，為使用者從離線開發轉向實時資料開發提供一定的入門基礎，同時為産品和營運同學提供了較好的實時鍊路開發科普，一定程度上降低了實時資料建設的開發門檻。之後通過滴滴典型的四個業務場景實時名額監控、實時BI分析、實時資料線上服務、實時特征來具體說明各業務場景下實時元件的選型差異和遵循原則。可以幫助業務開發同學根據具體資料需求指定合理的實時開發方案并快速落地。最後本文對實時任務開發過程中的主要元件提供了配置建議，保證在完成使用者實時任務開發的前提下盡可能降低開發成本，提高資源總體使用效率，降本提效。
作者:朱峰
來源:微信公衆号:滴滴技術
出處:https://mp.weixin.qq.com/s/Dwl2xOL_QmLsmv3lBamPkg