?桔妹導讀：隨著滴滴業務的高速發展，業務對于資料時效性的需求越來越高，而伴隨著實時技術的不斷發展和成熟，滴滴也對實時建設做了大量的嘗試和實踐，本文主要以順風車這個業務為引子，從引擎側、平臺側和業務側各個不同方面，來闡述滴滴所做的作業，分享在建設程序中的經驗，

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 是表還是流，來區分批處理任務和流處理任務，從產品層面上實作批流一體化效果，

團隊介紹

本文內容涉及三個滴滴云平臺事業群團隊，云平臺事業部大資料架構團隊，主要負責大資料底層引擎的建設，建設并維護公司內部，離線、OLAP、實時、保障等底層引擎，云平臺事業部大資料平臺部，主要負責公司內部通用平臺建設，包括一站式開發平臺，內置業界沉淀多年的資料開發流程及規范，滿足用戶對資料開發、資料安全、質量管理、資料管理需求，云平臺事業部實時數倉團隊，主要負責滴滴內部各業務線的實時資料建設、以及實時資料規范的沉淀，中間層的資料建設等，

作者介紹