**​桔妹導讀：**隨著滴滴業務的高速發展，業務對於資料時效性的需求越來越高，而伴隨著實時技術的不斷髮展和成熟，滴滴也對實時建設做了大量的嘗試和實踐。本文主要以順風車這個業務為引子，從引擎側、平臺側和業務側各個不同方面，來闡述滴滴所做的工作，分享在建設過程中的經驗。 #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、實時、保障等底層引擎。雲平臺事業部大資料平臺部，主要負責公司內部通用平臺建設，包括一站式開發平臺，內建業界沉澱多年的資料開發流程及規範，滿足使用者對資料開發、資料安全、質量管理、資料管理需求。雲平臺事業部實時數倉團隊，主要負責滴滴內部各業務線的實時資料建設、以及實時資料規範的沉澱，中間層的資料建設等。 **作者介紹**  負責實時資料倉庫建設，多年資料相關工作經驗，專注資料建模、資料倉庫、實時資料技術等領域。  主要從事實時資料倉庫建設，專注實時和離線數倉技術，對數倉建模、資料研發和數倉中間層建設有一定積累。 **延伸閱讀** [](http://mp.weixin.qq.com/s?__biz=MzU1ODEzNjI2NA==&mid=2247499785&idx=1&sn=f0081ec223da05be049e7abde7f8762d&chksm=fc29aeaecb5e27b8839f090c79f730a0a6c487f8996918c2bdf6ebaad72a6ff9d40e87f272ef&scene=21#wechat_redirect) [](http://mp.weixin.qq.com/s?__biz=MzU1ODEzNjI2NA==&mid=2247499563&idx=1&sn=fdfd28499b25c8b7c12b23080649abfb&chksm=fc29918ccb5e189a768bfbed1bc4040e0ce5d264bdb4592035cd7d16bdae96746bab6f5f163a&scene=21#wechat_redirect) [](http://mp.weixin.qq.com/s?__biz=MzU1ODEzNjI2NA==&mid=2247497605&idx=1&sn=6e739a39a48d75ee1c530c640ec9bf25&chksm=fc299922cb5e10342d5e3295af85500bf99d1ed88d4363fc77dbb3f9f82e8607e23e7814c0e4&scene=21#wechat_redirect) 內容編輯 | Charlotte 聯絡我們 | [email protected]  滴滴技