簡介：隨著滴滴業(yè)務的高速發(fā)展，業(yè)務對于數(shù)據(jù)時效性的需求越來越高，而伴隨著實時技術的不斷發(fā)展和成熟，滴滴也對實時建設做了大量的嘗試和實踐。本文主要以順風車這個業(yè)務為引子，從引擎?zhèn)取⑵脚_側(cè)和業(yè)務側(cè)各個不同方面，來闡述滴滴所做的工作，分享在建設過程中的經(jīng)驗。

隨著滴滴業(yè)務的高速發(fā)展，業(yè)務對于數(shù)據(jù)時效性的需求越來越高，而伴隨著實時技術的不斷發(fā)展和成熟，滴滴也對實時建設做了大量的嘗試和實踐。本文主要以順風車這個業(yè)務為引子，從引擎?zhèn)取⑵脚_側(cè)和業(yè)務側(cè)各個不同方面，來闡述滴滴所做的工作，分享在建設過程中的經(jīng)驗。

1.實時數(shù)倉建設目的

隨著互聯(lián)網(wǎng)的發(fā)展進入下半場，數(shù)據(jù)的時效性對企業(yè)的精細化運營越來越重要，商場如戰(zhàn)場，在每天產(chǎn)生的海量數(shù)據(jù)中，如何能實時有效的挖掘出有價值的信息， 對企業(yè)的決策運營策略調(diào)整有很大幫助。

其次從智能商業(yè)的角度來講，數(shù)據(jù)的結(jié)果代表了用戶的反饋，獲取結(jié)果的及時性就顯得尤為重要，快速的獲取數(shù)據(jù)反饋能夠幫助公司更快的做出決策，更好的進行產(chǎn)品迭代，實時數(shù)倉在這一過程中起到了不可替代的作用。

1.1 解決傳統(tǒng)數(shù)倉的問題

從目前數(shù)倉建設的現(xiàn)狀來看，實時數(shù)倉是一個容易讓人產(chǎn)生混淆的概念，根據(jù)傳統(tǒng)經(jīng)驗分析，數(shù)倉有一個重要的功能，即能夠記錄歷史。通常，數(shù)倉都是希望從業(yè)務上線的第一天開始有數(shù)據(jù)，然后一直記錄到現(xiàn)在。但實時流處理技術，又是強調(diào)當前處理狀態(tài)的一個技術，結(jié)合當前一線大廠的建設經(jīng)驗和滴滴在該領域的建設現(xiàn)狀，我們嘗試把公司內(nèi)實時數(shù)倉建設的目的定位為，以數(shù)倉建設理論和實時技術，解決由于當前離線數(shù)倉數(shù)據(jù)時效性低解決不了的問題。

現(xiàn)階段我們要建設實時數(shù)倉的主要原因是：

• 公司業(yè)務對于數(shù)據(jù)的實時性越來越迫切，需要有實時數(shù)據(jù)來輔助完成決策
• 實時數(shù)據(jù)建設沒有規(guī)范，數(shù)據(jù)可用性較差，無法形成數(shù)倉體系，資源大量浪費
• 數(shù)據(jù)平臺工具對整體實時開發(fā)的支持也日漸趨于成熟，開發(fā)成本降低

1.2 實時數(shù)倉的應用場景

• 實時 OLAP 分析：OLAP 分析本身就是數(shù)倉領域重點解決的問題，基于公司大數(shù)據(jù)架構團隊提供的基于 Flink 計算引擎的 stream sql 工具，Kafka 和 ddmq (滴滴自研)等消息中間件，druid 和 ClickHouse 等 OLAP 數(shù)據(jù)庫，提升數(shù)倉的時效性能力，使其具有較優(yōu)的實時數(shù)據(jù)分析能力。
• 實時數(shù)據(jù)看板：這類場景是目前公司實時側(cè)主要需求場景，例如“全民拼車日”訂單和券花銷實時大屏曲線展示，順風車新開城當日分鐘級訂單側(cè)核心指標數(shù)據(jù)展示，增長類項目資源投入和收益實時效果展示等。
• 實時業(yè)務監(jiān)控：滴滴出行大量核心業(yè)務指標需要具備實時監(jiān)控能力，比如安全指標監(jiān)控，財務指標監(jiān)控，投訴進線指標監(jiān)控等。
• 實時數(shù)據(jù)接口服務：由于各業(yè)務線之間存在很多業(yè)務壁壘，導致數(shù)倉開發(fā)很難熟悉公司內(nèi)全部業(yè)務線，需要與各業(yè)務線相關部門在數(shù)據(jù)加工和數(shù)據(jù)獲取方面進行協(xié)作，數(shù)倉通過提供實時數(shù)據(jù)接口服務的方式，向業(yè)務方提供數(shù)據(jù)支持。

2. 滴滴順風車實時數(shù)倉建設舉例

在公司內(nèi)部，我們數(shù)據(jù)團隊有幸與順風車業(yè)務線深入合作，在滿足業(yè)務方實時數(shù)據(jù)需求的同時，不斷完善實時數(shù)倉內(nèi)容，通過多次迭代，基本滿足了順風車業(yè)務方在實時側(cè)的各類業(yè)務需求，初步建立起順風車實時數(shù)倉，完成了整體數(shù)據(jù)分層，包含明細數(shù)據(jù)和匯總數(shù)據(jù)，統(tǒng)一了 DWD 層，降低了大數(shù)據(jù)資源消耗，提高了數(shù)據(jù)復用性，可對外輸出豐富的數(shù)據(jù)服務。

數(shù)倉具體架構如下圖所示：

從數(shù)據(jù)架構圖來看，順風車實時數(shù)倉和對應的離線數(shù)倉有很多類似的地方。例如分層結(jié)構；比如 ODS 層，明細層，匯總層，乃至應用層，他們命名的模式可能都是一樣的。但仔細比較不難發(fā)現(xiàn)，兩者有很多區(qū)別：

• 與離線數(shù)倉相比，實時數(shù)倉的層次更少一些
• 從目前建設離線數(shù)倉的經(jīng)驗來看，數(shù)倉的數(shù)據(jù)明細層內(nèi)容會非常豐富，處理明細數(shù)據(jù)外一般還會包含輕度匯總層的概念，另外離線數(shù)倉中應用層數(shù)據(jù)在數(shù)倉內(nèi)部，但實時數(shù)倉中，app 應用層數(shù)據(jù)已經(jīng)落入應用系統(tǒng)的存儲介質(zhì)中，可以把該層與數(shù)倉的表分離。
• 應用層少建設的好處：實時處理數(shù)據(jù)的時候，每建一個層次，數(shù)據(jù)必然會產(chǎn)生一定的延遲。
• 匯總層少建的好處：在匯總統(tǒng)計的時候，往往為了容忍一部分數(shù)據(jù)的延遲，可能會人為的制造一些延遲來保證數(shù)據(jù)的準確。舉例，在統(tǒng)計跨天相關的訂單事件中的數(shù)據(jù)時，可能會等到 00:00:05 或者 00:00:10 再統(tǒng)計，確保 00:00 前的數(shù)據(jù)已經(jīng)全部接受到位了，再進行統(tǒng)計。所以，匯總層的層次太多的話，就會更大的加重人為造成的數(shù)據(jù)延遲。
• 與離線數(shù)倉相比，實時數(shù)倉的數(shù)據(jù)源存儲不同
• 在建設離線數(shù)倉的時候，目前滴滴內(nèi)部整個離線數(shù)倉都是建立在 Hive 表之上。但是，在建設實時數(shù)倉的時候，同一份表，會使用不同的方式進行存儲。比如常見的情況下，明細數(shù)據(jù)或者匯總數(shù)據(jù)都會存在 Kafka 里面，但是像城市、渠道等維度信息需要借助 Hbase，MySQL 或者其他 KV 存儲等數(shù)據(jù)庫來進行存儲。

接下來，根據(jù)順風車實時數(shù)倉架構圖，對每一層建設做具體展開：

2.1 ODS 貼源層建設

根據(jù)順風車具體場景，目前順風車數(shù)據(jù)源主要包括訂單相關的 binlog 日志，冒泡和安全相關的 public 日志，流量相關的埋點日志等。這些數(shù)據(jù)部分已采集寫入 Kafka 或 ddmq 等數(shù)據(jù)通道中，部分數(shù)據(jù)需要借助內(nèi)部自研同步工具完成采集，最終基于順風車數(shù)倉ods層建設規(guī)范分主題統(tǒng)一寫入 Kafka 存儲介質(zhì)中。

命名規(guī)范：ODS 層實時數(shù)據(jù)源主要包括兩種。

• 一種是在離線采集時已經(jīng)自動生產(chǎn)的 DDMQ 或者是 Kafka topic，這類型的數(shù)據(jù)命名方式為采集系統(tǒng)自動生成規(guī)范為：cn-binlog-數(shù)據(jù)庫名-數(shù)據(jù)庫名 eg：cn-binlog-ihap_fangyuan-ihap_fangyuan
• 一種是需要自己進行采集同步到 kafka topic 中，生產(chǎn)的topic命名規(guī)范同離線類似：ODS 層采用：realtime_ods_binlog_{源系統(tǒng)庫/表名}/ods_log_{日志名} eg: realtime_ods_binlog_ihap_fangyuan

2.2 DWD 明細層建設

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

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

• {業(yè)務/pub}：參考業(yè)務命名
• {數(shù)據(jù)域縮寫}：參考數(shù)據(jù)域劃分部分
• {自定義表命名標簽縮寫}：實體名稱可以根據(jù)數(shù)據(jù)倉庫轉(zhuǎn)換整合后做一定的業(yè)務抽象的名稱，該名稱應該準確表述實體所代表的業(yè)務含義
  樣例：realtime_dwd_trip_trd_order_base

2.3 DIM 層

• 公共維度層，基于維度建模理念思想，建立整個業(yè)務過程的一致性維度，降低數(shù)據(jù)計算口徑和算法不統(tǒng)一風險；
• DIM 層數(shù)據(jù)來源于兩部分：一部分是 Flink 程序?qū)崟r處理ODS層數(shù)據(jù)得到，另外一部分是通過離線任務出倉得到；
• DIM 層維度數(shù)據(jù)主要使用 MySQL、Hbase、fusion(滴滴自研KV存儲) 三種存儲引擎，對于維表數(shù)據(jù)比較少的情況可以使用 MySQL，對于單條數(shù)據(jù)大小比較小，查詢 QPS 比較高的情況，可以使用 fusion 存儲，降低機器內(nèi)存資源占用，對于數(shù)據(jù)量比較大，對維表數(shù)據(jù)變化不是特別敏感的場景，可以使用HBase 存儲。

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

• {業(yè)務/pub}：參考業(yè)務命名
• {維度定義}：參考維度命名
• {自定義表命名標簽縮寫}：實體名稱可以根據(jù)數(shù)據(jù)倉庫轉(zhuǎn)換整合后做一定的業(yè)務抽象的名稱，該名稱應該準確表述實體所代表的業(yè)務含義
  樣例：dim_trip_dri_base

2.4 DWM 匯總層建設

在建設順風車實時數(shù)倉的匯總層的時候，跟順風車離線數(shù)倉有很多一樣的地方，但其具體技術實現(xiàn)會存在很大不同。

第一：對于一些共性指標的加工，比如 pv，uv，訂單業(yè)務過程指標等，我們會在匯總層進行統(tǒng)一的運算，確保關于指標的口徑是統(tǒng)一在一個固定的模型中完成。對于一些個性指標，從指標復用性的角度出發(fā)，確定唯一的時間字段，同時該字段盡可能與其他指標在時間維度上完成拉齊，例如行中異常訂單數(shù)需要與交易域指標在事件時間上做到拉齊。

第二：在順風車匯總層建設中，需要進行多維的主題匯總，因為實時數(shù)倉本身是面向主題的，可能每個主題會關心的維度都不一樣，所以需要在不同的主題下，按照這個主題關心的維度對數(shù)據(jù)進行匯總，最后來算業(yè)務方需要的匯總指標。在具體操作中，對于 pv 類指標使用 Stream SQL 實現(xiàn) 1 分鐘匯總指標作為最小匯總單位指標，在此基礎上進行時間維度上的指標累加；對于 uv 類指標直接使用 druid 數(shù)據(jù)庫作為指標匯總?cè)萜?#xff0c;根據(jù)業(yè)務方對匯總指標的及時性和準確性的要求，實現(xiàn)相應的精確去重和非精確去重。

第三：匯總層建設過程中，還會涉及到衍生維度的加工。在順風車券相關的匯總指標加工中我們使用 Hbase 的版本機制來構建一個衍生維度的拉鏈表，通過事件流和 Hbase 維表關聯(lián)的方式得到實時數(shù)據(jù)當時的準確維度

命名規(guī)范：DWM 層的表命名使用英文小寫字母，單詞之間用下劃線分開，總長度不能超過 40 個字符，并且應遵循下述規(guī)則：realtime_dwm_{業(yè)務/pub}_{數(shù)據(jù)域縮寫}_{數(shù)據(jù)主粒度縮寫}_[{自定義表命名標簽縮寫}]_{統(tǒng)計時間周期范圍縮寫}：

• {業(yè)務/pub}：參考業(yè)務命名
• {數(shù)據(jù)域縮寫}：參考數(shù)據(jù)域劃分部分
• {數(shù)據(jù)主粒度縮寫}：指數(shù)據(jù)主要粒度或數(shù)據(jù)域的縮寫，也是聯(lián)合主鍵中的主要維度
• {自定義表命名標簽縮寫}：實體名稱可以根據(jù)數(shù)據(jù)倉庫轉(zhuǎn)換整合后做一定的業(yè)務抽象的名稱，該名稱應該準確表述實體所代表的業(yè)務含義
• {統(tǒng)計時間周期范圍縮寫}：1d:天增量；td:天累計(全量)；1h:小時增量；th:小時累計(全量)；1min:分鐘增量；tmin:分鐘累計(全量)
  樣例：realtime_dwm_trip_trd_pas_bus_accum_1min

2.5 APP 應用層

該層主要的工作是把實時匯總數(shù)據(jù)寫入應用系統(tǒng)的數(shù)據(jù)庫中，包括用于大屏顯示和實時 OLAP 的 Druid 數(shù)據(jù)庫(該數(shù)據(jù)庫除了寫入應用數(shù)據(jù)，也可以寫入明細數(shù)據(jù)完成匯總指標的計算)中，用于實時數(shù)據(jù)接口服務的 Hbase 數(shù)據(jù)庫，用于實時數(shù)據(jù)產(chǎn)品的 MySQL 或者 Redis 數(shù)據(jù)庫中。

命名規(guī)范：基于實時數(shù)倉的特殊性不做硬性要求。

3. 順風車實時數(shù)倉建設成果

截止目前，一共為順風車業(yè)務線建立了增長、交易、體驗、安全、財務五大模塊，涉及 40+ 的實時看板，涵蓋順風車全部核心業(yè)務過程，實時和離線數(shù)據(jù)誤差<0.5%，是順風車業(yè)務線數(shù)據(jù)分析方面的有利補充，為順風車當天發(fā)券動態(tài)策略調(diào)整，司乘安全相關監(jiān)控，實時訂單趨勢分析等提供了實時數(shù)據(jù)支持，提高了決策的時效性。

同時建立在數(shù)倉模型之上的實時指標能根據(jù)用戶需求及時完成口徑變更和實時離線數(shù)據(jù)一致性校驗，大大提高了實時指標的開發(fā)效率和實時數(shù)據(jù)的準確性，也為公司內(nèi)部大范圍建設實時數(shù)倉提供了有力的理論和實踐支持。

4. 實時數(shù)倉建設對數(shù)據(jù)平臺的強依賴

目前公司內(nèi)部的實時數(shù)倉建設，需要依托數(shù)據(jù)平臺的能力才能真正完成落地，包括 StreamSQL 能力，數(shù)據(jù)夢工程 StreamSQL IDE 環(huán)境和任務運維組件，實時數(shù)據(jù)源元數(shù)據(jù)化功能等。

4.1 基于StreamSQL的實時數(shù)據(jù)需求開發(fā)

StreamSQL 是滴滴大數(shù)據(jù)引擎部在 Flink SQL 基礎上完善后形成的一個產(chǎn)品。

使用 StreamSQL 具有多個優(yōu)勢：

• 描述性語言：業(yè)務方不需要關心底層實現(xiàn)，只需要將業(yè)務邏輯描述出來即可。
• 接口穩(wěn)定：Flink 版本迭代過程中只要 SQL 語法不發(fā)生變化就非常穩(wěn)定。
• 問題易排查：邏輯性較強，用戶能看懂語法即可調(diào)查出錯位置。
• 批流一體化：批處理主要是 HiveSQL 和 Spark SQL，如果 Flink 任務也使用 SQL 的話，批處理任務和流處理任務在語法等方面可以進行共享，最終實現(xiàn)一體化的效果。

StreamSQL 相對于 Flink SQL （1.9 之前版本）的完善：

• 完善 DDL：包括上游的消息隊列、下游的消息隊列和各種存儲如 Druid、HBase 都進行了打通，用戶方只需要構建一個 source 就可以將上游或者下游描述出來。
• 內(nèi)置消息格式解析：消費數(shù)據(jù)后需要將數(shù)據(jù)進行提取，但數(shù)據(jù)格式往往非常復雜，如數(shù)據(jù)庫日志 binlog，每個用戶單獨實現(xiàn)，難度較大。StreamSQL 將提取庫名、表名、提取列等函數(shù)內(nèi)置，用戶只需創(chuàng)建 binlog 類型 source，并內(nèi)置了去重能力。對于 business log 業(yè)務日志 StreamSQL 內(nèi)置了提取日志頭，提取業(yè)務字段并組裝成 Map 的功能。對于 json 數(shù)據(jù)，用戶無需自定義 UDF，只需通過 jsonPath 指定所需字段。
• 擴展UDX：豐富內(nèi)置 UDX，如對 JSON、MAP 進行了擴展，這些在滴滴業(yè)務使用場景中較多。支持自定義 UDX，用戶自定義 UDF 并使用 jar 包即可。兼容 Hive UDX，例如用戶原來是一個 Hive SQL 任務，則轉(zhuǎn)換成實時任務不需要較多改動，有助于批流一體化。

Join 能力擴展：

• 基于 TTL 的雙流 join：在滴滴的流計算業(yè)務中有的 join 操作數(shù)據(jù)對應的跨度比較長，例如順風車業(yè)務發(fā)單到接單的時間跨度可能達到一個星期左右，如果這些數(shù)據(jù)的 join 基于內(nèi)存操作并不可行，通常將 join 數(shù)據(jù)放在狀態(tài)中，窗口通過 TTL 實現(xiàn)，過期自動清理。
• 維表 join 能力：維表支持 HBase、KVStore、Mysql 等，同時支持 inner、left、right、full join 等多種方式。

4.2 基于數(shù)據(jù)夢工廠的 StreamSQL IDE 和任務運維

StreamSQL IDE：

• 提供常用的SQL模板：在開發(fā)流式 SQL 時不需要從零開始，只需要選擇一個 SQL 模板，并在這個模板之上進行修修改改即可達到期望的結(jié)果
• 提供 UDF 的庫：相當于一個庫如果不知道具有什么含義以及如何使用，用戶只需要在 IDE 上搜索到這個庫，就能夠找到使用說明以及使用案例，提供語法檢測與智能提示
• 提供代碼在線DEBUG能力：可以上傳本地測試數(shù)據(jù)或者采樣少量 Kafka 等 source 數(shù)據(jù) debug，此功能對流計算任務非常重要。提供版本管理功能，可以在業(yè)務版本不斷升級過程中，提供任務回退功能。

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

• 日志檢索：Flink UI 上查詢?nèi)罩倔w驗非常糟糕，滴滴將 Flink 任務日志進行了采集，存儲在 ES 中，通過 WEB 化的界面進行檢索，方便調(diào)查。
• 指標監(jiān)控：Flink 指標較多，通過 Flink UI 查看體驗糟糕，因此滴滴構建了一個外部的報表平臺，可以對指標進行監(jiān)控。
• 報警：報警需要做一個平衡，如重啟報警有多類如 ( 機器宕機報警、代碼錯誤報警 )，通過設置一天內(nèi)單個任務報警次數(shù)閾值進行平衡，同時也包括存活報警 ( 如 kill、start )、延遲報警、重啟報警和 Checkpoint 頻繁失敗報警 ( 如 checkpoint 周期配置不合理 ) 等。
• 血緣追蹤：實時計算任務鏈路較長，從采集到消息通道，流計算，再到下游的存儲經(jīng)常包括 4-5個環(huán)節(jié)，如果無法實現(xiàn)追蹤，容易產(chǎn)生災難性的問題。例如發(fā)現(xiàn)某流式任務流量暴漲后，需要先查看其消費的 topic 是否增加，topic 上游采集是否增加，采集的數(shù)據(jù)庫 DB 是否產(chǎn)生不恰當?shù)嘏坎僮骰蛘吣硞€業(yè)務在不斷增加日志。這類問題需要從下游到上游、從上游到下游多方向的血緣追蹤，方便調(diào)查原因。

4.3 基于數(shù)據(jù)夢工廠的實時數(shù)據(jù)源元數(shù)據(jù)化(meta化表)

將 topic 引入成實時表，metastore 統(tǒng)一管理元數(shù)據(jù)，實時開發(fā)中統(tǒng)一管理 DDL 過程。對實時數(shù)倉來說，通過元數(shù)據(jù)化，可以沉淀實時數(shù)倉的建設成果，使數(shù)倉建模能更好的落地。

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

5. 面臨的挑戰(zhàn)和解決方案思考

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

5.1 實時數(shù)倉研發(fā)規(guī)范

問題：為了快速響應業(yè)務需求，同時滿足數(shù)倉的需求開發(fā)流程，迫切需要建設一套面向?qū)崟r數(shù)據(jù)開發(fā)的規(guī)范白皮書，該白皮書需要涉及需求對接、口徑梳理、數(shù)據(jù)開發(fā)、任務發(fā)布、任務監(jiān)控、任務保障。

目前解決方案：目前由數(shù)據(jù) BP 牽頭，制定了一套面向?qū)崟r數(shù)據(jù)指標的開發(fā)規(guī)范：

常規(guī)流程：需求方提出需求，分析師對接需求，提供計算口徑，編寫需求文檔。之后由數(shù)倉 BP 和離線數(shù)倉同學 check 計算口徑，并向?qū)崟r數(shù)倉團隊提供離線 Hive 表，實時數(shù)倉同學基于離線 Hive 表完成數(shù)據(jù)探查，基于實時數(shù)倉模型完成實時數(shù)據(jù)需求開發(fā)，通過離線口徑完成數(shù)據(jù)自查，最終交付給分析師完成二次校驗后指標上線。

口徑變更--業(yè)務方發(fā)起：業(yè)務方發(fā)起口徑變更，判斷是否涉及到實時指標，數(shù)倉 BP 對離線和實時口徑進行拉齊，向離線數(shù)倉團隊和實時數(shù)倉團隊提供更口口徑和數(shù)據(jù)源表，實時數(shù)倉團隊先上測試看板，驗收通過后切換到正式看板

存在的不足：

• 當針對某個業(yè)務進行新的實時數(shù)據(jù)建設時，會有一個比較艱難的初始化過程，這個初始化過程中，會和離線有較多耦合，需要確定指標口徑，數(shù)據(jù)源，并進行大量開發(fā)測試工作
• 在指標口徑發(fā)生變更的時候，需要有一個較好的通知機制，目前還是從人的角度來進行判斷。

5.2 離線和實時數(shù)據(jù)一致性保證

目前解決辦法：由業(yè)務、BP、離線數(shù)倉共同保證數(shù)據(jù)源、計算口徑與離線一致，數(shù)據(jù)加工過程，逐層與離線進行數(shù)據(jù)比對，并對指標結(jié)果進行詳細測試，數(shù)據(jù)校驗通過并上線后，根據(jù)離線周期進行實時和離線數(shù)據(jù)的校驗。

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

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

雖然 Flink 具備批流一體化能力，但滴滴目前并沒有完全批流一體化，希望先從產(chǎn)品層面實現(xiàn)批流一體化。通過 Meta 化建設，實現(xiàn)整個滴滴只有一個 MetaStore，無論是 Hive、Kafka topic、還是下游的 HBase、ES 都定義到 MetaStore 中，所有的計算引擎包括 Hive、Spark、Presto、Flink 都查詢同一個 MetaStore，實現(xiàn)整個 SQL 開發(fā)完全一致的效果。根據(jù) SQL 消費的 Source 是表還是流，來區(qū)分批處理任務和流處理任務，從產(chǎn)品層面上實現(xiàn)批流一體化效果。

更多 Flink 技術交流，可以釘釘掃碼加入 Flink 的社區(qū)大群～

原文鏈接：https://developer.aliyun.com/article/771440?

版權聲明：本文內(nèi)容由阿里云實名注冊用戶自發(fā)貢獻，版權歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權，亦不承擔相應法律責任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權保護指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權投訴表單進行舉報，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的滴滴基于 Flink 的实时数仓建设实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。