滴滴基於 Flink 的實時數倉建設實踐 - 知乎

簡介：隨着滴滴業務的高速發展，業務對於數據時效性的需求愈來愈高，而伴隨着實時技術的不斷髮展和成熟，滴滴也對實時建設作了大量的嘗試和實踐。本文主要以順風車這個業務爲引子，從引擎側、平臺側和業務側各個不一樣方面，來闡述滴滴所作的工做，分享在建設過程當中的經驗。

隨着滴滴業務的高速發展，業務對於數據時效性的需求愈來愈高，而伴隨着實時技術的不斷髮展和成熟，滴滴也對實時建設作了大量的嘗試和實踐。本文主要以順風車這個業務爲引子，從引擎側、平臺側和業務側各個不一樣方面，來闡述滴滴所作的工做，分享在建設過程當中的經驗。

1.實時數倉建設目的

隨着互聯網的發展進入下半場，數據的時效性對企業的精細化運營愈來愈重要，商場如戰場，在天天產生的海量數據中，如何能實時有效的挖掘出有價值的信息， 對企業的決策運營策略調整有很大幫助。

其次從智能商業的角度來說，數據的結果表明了用戶的反饋，獲取結果的及時性就顯得尤其重要，快速的獲取數據反饋可以幫助公司更快的作出決策，更好的進行產品迭代，實時數倉在這一過程當中起到了不可替代的做用。

1.1 解決傳統數倉的問題

從目前數倉建設的現狀來看，實時數倉是一個容易讓人產生混淆的概念，根據傳統經驗分析，數倉有一個重要的功能，即可以記錄歷史。一般，數倉都是但願從業務上線的第一天開始有數據，而後一直記錄到如今。但實時流處理技術，又是強調當前處理狀態的一個技術，結合當前一線大廠的建設經驗和滴滴在該領域的建設現狀，咱們嘗試把公司內實時數倉建設的目的定位爲，以數倉建設理論和實時技術，解決因爲當前離線數倉數據時效性低解決不了的問題。

現階段咱們要建設實時數倉的主要緣由是：

• 公司業務對於數據的實時性愈來愈迫切，須要有實時數據來輔助完成決策
• 實時數據建設沒有規範，數據可用性較差，沒法造成數倉體系，資源大量浪費
• 數據平臺工具對總體實時開發的支持也日漸趨於成熟，開發成本下降

1.2 實時數倉的應用場景

• 實時 OLAP 分析：OLAP 分析自己就是數倉領域重點解決的問題，基於公司大數據架構團隊提供的基於 Flink 計算引擎的 stream sql 工具，Kafka 和 ddmq (滴滴自研)等消息中間件，druid 和 ClickHouse 等 OLAP 數據庫，提高數倉的時效性能力，使其具備較優的實時數據分析能力。
• 實時數據看板：這類場景是目前公司實時側主要需求場景，例如「全民拼車日」訂單和券花銷實時大屏曲線展現，順風車新開城當日分鐘級訂單側核心指標數據展現，增加類項目資源投入和收益實時效果展現等。
• 實時業務監控：滴滴出行大量核心業務指標須要具有實時監控能力，好比安全指標監控，財務指標監控，投訴進線指標監控等。
• 實時數據接口服務：因爲各業務線之間存在不少業務壁壘，致使數倉開發很難熟悉公司內所有業務線，須要與各業務線相關部門在數據加工和數據獲取方面進行協做，數倉經過提供實時數據接口服務的方式，向業務方提供數據支持。

2. 滴滴順風車實時數倉建設舉例

在公司內部，咱們數據團隊有幸與順風車業務線深刻合做，在知足業務方實時數據需求的同時，不斷完善實時數倉內容，經過屢次迭代，基本知足了順風車業務方在實時側的各種業務需求，初步創建起順風車實時數倉，完成了總體數據分層，包含明細數據和彙總數據，統一了 DWD 層，下降了大數據資源消耗，提升了數據複用性，可對外輸出豐富的數據服務。

數倉具體架構以下圖所示：

從數據架構圖來看，順風車實時數倉和對應的離線數倉有不少相似的地方。例如分層結構；好比 ODS 層，明細層，彙總層，乃至應用層，他們命名的模式可能都是同樣的。但仔細比較不難發現，二者有不少區別：

• 與離線數倉相比，實時數倉的層次更少一些
• 從目前建設離線數倉的經驗來看，數倉的數據明細層內容會很是豐富，處理明細數據外通常還會包含輕度彙總層的概念，另外離線數倉中應用層數據在數倉內部，但實時數倉中，app 應用層數據已經落入應用系統的存儲介質中，能夠把該層與數倉的表分離。
• 應用層少建設的好處：實時處理數據的時候，每建一個層次，數據必然會產生必定的延遲。
• 彙總層少建的好處：在彙總統計的時候，每每爲了容忍一部分數據的延遲，可能會人爲的製造一些延遲來保證數據的準確。舉例，在統計跨天相關的訂單事件中的數據時，可能會等到 00:00:05 或者 00:00:10 再統計，確保 00:00 前的數據已經所有接受到位了，再進行統計。因此，彙總層的層次太多的話，就會更大的加劇人爲形成的數據延遲。
• 與離線數倉相比，實時數倉的數據源存儲不一樣
• 在建設離線數倉的時候，目前滴滴內部整個離線數倉都是創建在 Hive 表之上。可是，在建設實時數倉的時候，同一份表，會使用不一樣的方式進行存儲。好比常見的狀況下，明細數據或者彙總數據都會存在 Kafka 裏面，可是像城市、渠道等維度信息須要藉助 Hbase，MySQL 或者其餘 KV 存儲等數據庫來進行存儲。

接下來，根據順風車實時數倉架構圖，對每一層建設作具體展開：

2.1 ODS 貼源層建設

根據順風車具體場景，目前順風車數據源主要包括訂單相關的 binlog 日誌，冒泡和安全相關的 public 日誌，流量相關的埋點日誌等。這些數據部分已採集寫入 Kafka 或 ddmq 等數據通道中，部分數據須要藉助內部自研同步工具完成採集，最終基於順風車數倉ods層建設規範分主題統一寫入 Kafka 存儲介質中。

命名規範：ODS 層實時數據源主要包括兩種。

• 一種是在離線採集時已經自動生產的 DDMQ 或者是 Kafka topic，這類型的數據命名方式爲採集系統自動生成規範爲：cn-binlog-數據庫名-數據庫名 eg：cn-binlog-ihap_fangyuan-ihap_fangyuan
• 一種是須要本身進行採集同步到 kafka topic 中，生產的topic命名規範同離線相似：ODS 層採用：realtime_ods_binlog_{源系統庫/表名}/ods_log_{日誌名} eg: realtime_ods_binlog_ihap_fangyuan

2.2 DWD 明細層建設

根據順風車業務過程做爲建模驅動，基於每一個具體的業務過程特色，構建最細粒度的明細層事實表；結合順風車分析師在離線側的數據使用特色，將明細事實表的某些重要維度屬性字段作適當冗餘，完成寬表化處理，以後基於當前順風車業務方對實時數據的需求重點，重點建設交易、財務、體驗、安全、流量等幾大模塊；該層的數據來源於 ODS 層，經過大數據架構提供的 Stream SQL 完成 ETL 工做，對於 binlog 日誌的處理主要進行簡單的數據清洗、處理數據漂移和數據亂序，以及可能對多個 ODS 表進行 Stream Join，對於流量日誌主要是作通用的 ETL 處理和針對順風車場景的數據過濾，完成非結構化數據的結構化處理和數據的分流；該層的數據除了存儲在消息隊列 Kafka 中，一般也會把數據實時寫入 Druid 數據庫中，供查詢明細數據和做爲簡單彙總數據的加工數據源。

命名規範：DWD 層的表命名使用英文小寫字母，單詞之間用下劃線分開，總長度不能超過 40 個字符，而且應遵循下述規則：realtime_dwd_{業務/pub}_{數據域縮寫}_[{業務過程縮寫}]_[{自定義表命名標籤縮寫}]

• {業務/pub}：參考業務命名
• {數據域縮寫}：參考數據域劃分部分
• {自定義表命名標籤縮寫}：實體名稱能夠根據數據倉庫轉換整合後作必定的業務抽象的名稱，該名稱應該準確表述實體所表明的業務含義
  樣例：realtime_dwd_trip_trd_order_base
  

2.3 DIM 層

• 公共維度層，基於維度建模理念思想，創建整個業務過程的一致性維度，下降數據計算口徑和算法不統一風險；
• DIM 層數據來源於兩部分：一部分是 Flink 程序實時處理ODS層數據獲得，另一部分是經過離線任務出倉獲得；
• DIM 層維度數據主要使用 MySQL、Hbase、fusion(滴滴自研KV存儲) 三種存儲引擎，對於維表數據比較少的狀況可使用 MySQL，對於單條數據大小比較小，查詢 QPS 比較高的狀況，可使用 fusion 存儲，下降機器內存資源佔用，對於數據量比較大，對維表數據變化不是特別敏感的場景，可使用HBase 存儲。

命名規範：DIM 層的表命名使用英文小寫字母，單詞之間用下劃線分開，總長度不能超過 30 個字符，而且應遵循下述規則：dim_{業務/pub}_{維度定義}[_{自定義命名標籤}]：

• {業務/pub}：參考業務命名
• {維度定義}：參考維度命名
• {自定義表命名標籤縮寫}：實體名稱能夠根據數據倉庫轉換整合後作必定的業務抽象的名稱，該名稱應該準確表述實體所表明的業務含義
  樣例：dim_trip_dri_base
  

2.4 DWM 彙總層建設

在建設順風車實時數倉的彙總層的時候，跟順風車離線數倉有不少同樣的地方，但其具體技術實現會存在很大不一樣。

第一：對於一些共性指標的加工，好比 pv，uv，訂單業務過程指標等，咱們會在彙總層進行統一的運算，確保關於指標的口徑是統一在一個固定的模型中完成。對於一些個性指標，從指標複用性的角度出發，肯定惟一的時間字段，同時該字段儘量與其餘指標在時間維度上完成拉齊，例如行中異常訂單數須要與交易域指標在事件時間上作到拉齊。

第二：在順風車彙總層建設中，須要進行多維的主題彙總，由於實時數倉自己是面向主題的，可能每一個主題會關心的維度都不同，因此須要在不一樣的主題下，按照這個主題關心的維度對數據進行彙總，最後來算業務方須要的彙總指標。在具體操做中，對於 pv 類指標使用 Stream SQL 實現 1 分鐘彙總指標做爲最小彙總單位指標，在此基礎上進行時間維度上的指標累加；對於 uv 類指標直接使用 druid 數據庫做爲指標彙總容器，根據業務方對彙總指標的及時性和準確性的要求，實現相應的精確去重和非精確去重。

第三：彙總層建設過程當中，還會涉及到衍生維度的加工。在順風車券相關的彙總指標加工中咱們使用 Hbase 的版本機制來構建一個衍生維度的拉鍊表，經過事件流和 Hbase 維表關聯的方式獲得實時數據當時的準確維度

命名規範：DWM 層的表命名使用英文小寫字母，單詞之間用下劃線分開，總長度不能超過 40 個字符，而且應遵循下述規則：realtime_dwm_{業務/pub}_{數據域縮寫}_{數據主粒度縮寫}_[{自定義表命名標籤縮寫}]_{統計時間週期範圍縮寫}：

• {業務/pub}：參考業務命名
• {數據域縮寫}：參考數據域劃分部分
• {數據主粒度縮寫}：指數據主要粒度或數據域的縮寫，也是聯合主鍵中的主要維度
• {自定義表命名標籤縮寫}：實體名稱能夠根據數據倉庫轉換整合後作必定的業務抽象的名稱，該名稱應該準確表述實體所表明的業務含義
• {統計時間週期範圍縮寫}：1d:天增量；td:天累計(全量)；1h:小時增量；th:小時累計(全量)；1min:分鐘增量；tmin:分鐘累計(全量)
  樣例：realtime_dwm_trip_trd_pas_bus_accum_1min
  

2.5 APP 應用層

該層主要的工做是把實時彙總數據寫入應用系統的數據庫中，包括用於大屏顯示和實時 OLAP 的 Druid 數據庫(該數據庫除了寫入應用數據，也能夠寫入明細數據完成彙總指標的計算)中，用於實時數據接口服務的 Hbase 數據庫，用於實時數據產品的 MySQL 或者 Redis 數據庫中。

命名規範：基於實時數倉的特殊性不作硬性要求。

3. 順風車實時數倉建設成果

截止目前，一共爲順風車業務線創建了增加、交易、體驗、安全、財務五大模塊，涉及 40+ 的實時看板，涵蓋順風車所有核心業務過程，實時和離線數據偏差<0.5%，是順風車業務線數據分析方面的有利補充，爲順風車當天發券動態策略調整，司乘安全相關監控，實時訂單趨勢分析等提供了實時數據支持，提升了決策的時效性。

同時創建在數倉模型之上的實時指標能根據用戶需求及時完成口徑變動和實時離線數據一致性校驗，大大提升了實時指標的開發效率和實時數據的準確性，也爲公司內部大範圍建設實時數倉提供了有力的理論和實踐支持。

4. 實時數倉建設對數據平臺的強依賴

目前公司內部的實時數倉建設，須要依託數據平臺的能力才能真正完成落地，包括 StreamSQL 能力，數據夢工程 StreamSQL IDE 環境和任務運維組件，實時數據源元數據化功能等。

4.1 基於StreamSQL的實時數據需求開發

StreamSQL 是滴滴大數據引擎部在 Flink SQL 基礎上完善後造成的一個產品。

使用 StreamSQL 具備多個優點：

• 描述性語言：業務方不須要關心底層實現，只須要將業務邏輯描述出來便可。
• 接口穩定：Flink 版本迭代過程當中只要 SQL 語法不發生變化就很是穩定。
• 問題易排查：邏輯性較強，用戶能看懂語法便可調查出錯位置。
• 批流一體化：批處理主要是 HiveSQL 和 Spark SQL，若是 Flink 任務也使用 SQL 的話，批處理任務和流處理任務在語法等方面能夠進行共享，最終實現一體化的效果。

StreamSQL 相對於 Flink SQL （1.9 以前版本）的完善：

• 完善 DDL：包括上游的消息隊列、下游的消息隊列和各類存儲如 Druid、HBase 都進行了打通，用戶方只須要構建一個 source 就能夠將上游或者下游描述出來。
• 內置消息格式解析：消費數據後須要將數據進行提取，但數據格式每每很是複雜，如數據庫日誌 binlog，每一個用戶單獨實現，難度較大。StreamSQL 將提取庫名、表名、提取列等函數內置，用戶只需建立 binlog 類型 source，並內置了去重能力。對於 business log 業務日誌 StreamSQL 內置了提取日誌頭，提取業務字段並組裝成 Map 的功能。對於 json 數據，用戶無需自定義 UDF，只需經過 jsonPath 指定所需字段。
• 擴展UDX：豐富內置 UDX，如對 JSON、MAP 進行了擴展，這些在滴滴業務使用場景中較多。支持自定義 UDX，用戶自定義 UDF 並使用 jar 包便可。兼容 Hive UDX，例如用戶原來是一個 Hive SQL 任務，則轉換成實時任務不須要較多改動，有助於批流一體化。

Join 能力擴展：

• 基於 TTL 的雙流 join：在滴滴的流計算業務中有的 join 操做數據對應的跨度比較長，例如順風車業務發單到接單的時間跨度可能達到一個星期左右，若是這些數據的 join 基於內存操做並不可行，一般將 join 數據放在狀態中，窗口經過 TTL 實現，過時自動清理。
• 維表 join 能力：維表支持 HBase、KVStore、Mysql 等，同時支持 inner、left、right、full join 等多種方式。

4.2 基於數據夢工廠的 StreamSQL IDE 和任務運維

StreamSQL IDE：

• 提供經常使用的SQL模板：在開發流式 SQL 時不須要從零開始，只須要選擇一個 SQL 模板，並在這個模板之上進行修修改改便可達到指望的結果
• 提供 UDF 的庫：至關於一個庫若是不知道具備什麼含義以及如何使用，用戶只須要在 IDE 上搜索到這個庫，就可以找到使用說明以及使用案例，提供語法檢測與智能提示
• 提供代碼在線DEBUG能力：能夠上傳本地測試數據或者採樣少許 Kafka 等 source 數據 debug，此功能對流計算任務很是重要。提供版本管理功能，能夠在業務版本不斷升級過程當中，提供任務回退功能。

任務運維：任務運維主要分爲四個方面

• 日誌檢索：Flink UI 上查詢日誌體驗很是糟糕，滴滴將 Flink 任務日誌進行了採集，存儲在 ES 中，經過 WEB 化的界面進行檢索，方便調查。
• 指標監控：Flink 指標較多，經過 Flink UI 查看體驗糟糕，所以滴滴構建了一個外部的報表平臺，能夠對指標進行監控。
• 報警：報警須要作一個平衡，如重啓報警有多類如 ( 機器宕機報警、代碼錯誤報警 )，經過設置一天內單個任務報警次數閾值進行平衡，同時也包括存活報警 ( 如 kill、start )、延遲報警、重啓報警和 Checkpoint 頻繁失敗報警 ( 如 checkpoint 週期配置不合理 ) 等。
• 血緣追蹤：實時計算任務鏈路較長，從採集到消息通道，流計算，再到下游的存儲常常包括 4-5個環節，若是沒法實現追蹤，容易產生災難性的問題。例如發現某流式任務流量暴漲後，須要先查看其消費的 topic 是否增長，topic 上游採集是否增長，採集的數據庫 DB 是否產生不恰當地批量操做或者某個業務在不斷增長日誌。這類問題須要從下游到上游、從上游到下游多方向的血緣追蹤，方便調查緣由。

4.3 基於數據夢工廠的實時數據源元數據化(meta化表)

將 topic 引入成實時表，metastore 統一管理元數據，實時開發中統一管理 DDL 過程。對實時數倉來講，經過元數據化，能夠沉澱實時數倉的建設成果，使數倉建模能更好的落地。

目前數據夢工廠支持的元數據化實時數據源包括 Postgre、DDMQ、MySQL、Druid、ClickHouse、Kylin、Kafka。

5. 面臨的挑戰和解決方案思考

雖然目前滴滴在實時數倉建設方面已初具規模，但其面臨的問題也不容忽視。

5.1 實時數倉研發規範

問題：爲了快速響應業務需求，同時知足數倉的需求開發流程，迫切須要建設一套面向實時數據開發的規範白皮書，該白皮書須要涉及需求對接、口徑梳理、數據開發、任務發佈、任務監控、任務保障。

目前解決方案：目前由數據 BP 牽頭，制定了一套面向實時數據指標的開發規範：

常規流程：需求方提出需求，分析師對接需求，提供計算口徑，編寫需求文檔。以後由數倉 BP 和離線數倉同窗 check 計算口徑，並向實時數倉團隊提供離線 Hive 表，實時數倉同窗基於離線 Hive 表完成數據探查，基於實時數倉模型完成實時數據需求開發，經過離線口徑完成數據自查，最終交付給分析師完成二次校驗後指標上線。

口徑變動--業務方發起：業務方發起口徑變動，判斷是否涉及到實時指標，數倉 BP 對離線和實時口徑進行拉齊，向離線數倉團隊和實時數倉團隊提供更口口徑和數據源表，實時數倉團隊先上測試看板，驗收經過後切換到正式看板

存在的不足：

• 當針對某個業務進行新的實時數據建設時，會有一個比較艱難的初始化過程，這個初始化過程當中，會和離線有較多耦合，須要肯定指標口徑，數據源，並進行大量開發測試工做
• 在指標口徑發生變動的時候，須要有一個較好的通知機制，目前仍是從人的角度來進行判斷。

5.2 離線和實時數據一致性保證

目前解決辦法：由業務、BP、離線數倉共同保證數據源、計算口徑與離線一致，數據加工過程，逐層與離線進行數據比對，並對指標結果進行詳細測試，數據校驗經過並上線後，根據離線週期進行實時和離線數據的校驗。

待解決的問題：結合指標管理工具，保證指標口徑上的一致性，擴展數據夢工廠功能，在指標加工過程當中，增長實時離線比對功能，下降數據比對成本。

6. 將來展望：批流一體化

雖然 Flink 具有批流一體化能力，但滴滴目前並無徹底批流一體化，但願先從產品層面實現批流一體化。經過 Meta 化建設，實現整個滴滴只有一個 MetaStore，不管是 Hive、Kafka topic、仍是下游的 HBase、ES 都定義到 MetaStore 中，全部的計算引擎包括 Hive、Spark、Presto、Flink 都查詢同一個 MetaStore，實現整個 SQL 開發徹底一致的效果。根據 SQL 消費的 Source 是表仍是流，來區分批處理任務和流處理任務，從產品層面上實現批流一體化效果。

原文連接

本文爲阿里雲原創內容，未經容許不得轉載。