滴滴數據服務體系建設實踐

什麼是數據服務化

大數據開發的主要流程分爲數據集成、數據開發、數據生產和數據迴流四個階段。數據集成打通了業務系統數據進入大數據環境的通道，通常包含週期性導入離線表、實時採集並清洗導入離線表和實時寫入對應數據源三種方式，當前滴滴內部同步中心平臺已經提供了 MySQL、Oracle、MongoDB、Publiclog 等多種數據源的數據採集能力；數據開發 / 生產，用戶可以構建實時、離線兩種數據倉庫，並基於 SQL、Native、Shell 等多種任務方式下的數據建模；數據迴流通過將離線數據導入 OLAP、RDBMS 等，以提升訪問性能，下游服務直接訪問該數據源進行數據分析、數據可視化。

滴滴內部的數據夢工廠，就是提供一站式數據開發、生產的解決方案，核心關注的是數據開發、生產環節中的效率、安全和穩定性。

數據開發流程

爲了體系地將數據交付用戶，我們構建的是一站式的數據消費平臺，包含了數易、數據智能問答機器人、異動分析等通用數據消費產品，和橫向沉澱的內容產品北極星、集團展廳。一站式消費平臺需要通過查詢結構化、標準化的數據來提供可視化、分析能力。從數據消費產品的技術架構中，對查詢性能有一定要求，會根據查詢的方式迴流到合適的多維分析存儲引擎，最爲常見的是 MySQL、ClickHouse、Druid 和 StarRocks。因此，對多維分析存儲引擎的查詢收口、擴展計算能力擴展、性能優化實施和查詢穩定性保障等，對於消費類數據產品來說都是公共、通用能力。

此外，對於其他個性化數據產品、運營平臺、B 端 / C 端產品來說，都是亟需的數據訪問能力。這也是數據中臺建設，對於數據訪問能力統一化的核心問題：數據服務化能力。

對於該項能力建設，我們也不是一蹴而就的，主要分爲三個階段。

數據消費產品技術架構示意

階段一：

建設同步中心數據迴流能力

2019 年滴滴發起了數據體系 2.0 建設，作爲核心產出的數據夢工廠，其第一階段目標是建設一站式的數據開發、生產平臺，關鍵節點以同步中心的一站式建設完畢爲里程碑。同步中心通過自動化流程的建設，結束了通過提工單的方式，來人工構建數據源間同步任務的歷史，其核心產出是數據進入 Hive 鏈路的自主管理能力建設。另外，我們新建了 Hive 迴流到 MySQL、ClickHouse、Druid、Hbase 和 ES 鏈路，使得數據迴流完成平臺化建設。

基於數據迴流實現的數據服務化能力，使得服務分、北極星和數易等相關場景得以系統化覆蓋。核心解決了業務直接訪問大數據環境的性能問題，以數易爲例，通過數據迴流到 ClickHouse，使數據查詢性能 P90 從 5s 下降到 2s 以內，這樣的性能提升使數易的用戶體驗有質的提升。這個階段的數據產品的基本架構，尤其是查詢側，類似於下圖所示，都抽象出來了數據迴流和取數邏輯兩個模塊。

數據迴流實現數據導出到多維分析存儲引擎，並沉澱有任務的管理和運維能力，這些數據產品均深度打通了數據夢工廠，基於數據夢工廠強大的離線任務運維能力保障數據的產出。取數邏輯維護着具體的查詢邏輯，除了北極星，其他兩款產品均衍生出了基於查詢抽象的中間件，例如 InSight 的 QE(QueryEngine)、數易的查詢中心。數據迴流和取數邏輯，是數據產品的核心能力，也是建設成本極高的模塊。所以，這個階段，類似於數據智能問答機器人、數據門戶、複雜表格等產品，採用了基於數易數據集的查詢、加速能力，以快速驗證產品。

階段二：

建設數鏈平臺，統一數據服務化

階段一提供了數據迴流在線存儲能力，提升了相關係統調用性能，爲數據產品發展做出了階段性貢獻。隨着業務發展，數據表數量提升，取數邏輯隔離沉澱在不同系統問題凸顯出來，管理成本不斷提升。爲了提升取數性能，除了加速到多維分析存儲引擎之外，還需要對數據進行高度聚合，構建數據量較少的 APP 層。APP 層表和業務需求有着強相關性，因此，需求的變化常常導致需要變更 APP 表支持業務。階段一中，取數邏輯場景散落在不同的系統內部，APP 表變更將是比較大的工作量，包含了不同看板的數據源切換，看板質量的再次驗收，過程十分繁雜。

數據迴流和取數邏輯在不同的數據產品內進行重複建設，也增加了數據產品構建的效率。爲了提升效率，內部產品基本都依賴數易數據集進行建設，例如數據智能問答機器人、複雜表格。

但這不是最優的解決方案，問題主要體現在：

• 基於數易數據集，加速、限流、隔離等措施建設都非常複雜、龐雜。尤其，數易數據集加速方式分成一級的 SQL 任務加速、二級 ClickHouse 加速，形式固化。

• 數易的查詢都是基於 MPP 建設，對於相對高的併發查詢、點查很難支撐。

• 運維保障能力較弱，加速任務都由平臺代持，用戶感知較弱，且無法運維。

• 數易數據集是數易的強依賴，剝離建設服務化能力難度較大，當時對於數易來說也不是第一優先級考慮的事情。

綜上所述，構建一個統一的數據服務化平臺，有着較強的業務收益。從 2021 年初開始，數鏈平臺應運而生，其基本思路在於對加速鏈路、查詢邏輯進行統一管理，並提供統一、完備的查詢網關。

數鏈的基本能力在於：

• 多樣化的數據源：支持 ES、MySQL、ClickHouse、Hbase、Druid 等數據源的訪問；

• 多場景的數據訪問：支持 key/value 鍵值對的高併發查詢、支持複雜的多維分析和支持數據下載能力；

• 統一的接入標準：統一的訪問網關、統一數據訪問協議、統一的數據運維和統一的 API 管理能力；

• 數據安全管控：支持對敏感數據訪問的審計，數據下載外發管控能力。

數鏈平臺構建之後，數據 API 構建時間從天級別下降到分鐘級別，實現了白屏化 API 建設能力。當前，數鏈的 API 數量已經超過 4000，周活 API 數量也超過了 1600，服務了 200 多個應用，覆蓋了所有的業務線，達成既定建設目標。

階段三：

建設數鏈標準指標服務化

通過階段二的平臺建設，收益的數據產品主要是監控、看板、門戶、運營系統和安全相關係統。這些系統主要看中數鏈構建 API 的效率，API 業務邏輯的管理能力和 API 的運維能力。但是，數易、北極星等早期建設，有相關能力閉環的產品，很難找到接入數鏈的突破口，或者說收益很難看到。

當前，大數據中指標交付，長期通過 Hive 表和沉澱在指標管理工具的指標描述來交付，也就是說，數倉會提供給業務方一張 Hive 表，和描述性的取值邏輯。業務方通過 Hive 表構建看板、臨時取數時，需要反覆校驗取數邏輯，效率比較低下。同時，同一個指標常常在北極星、數易等產品展示，最爲尷尬的是常常出現數值的不一致，也就是指標消費的一致性問題凸顯。

指標管理工具是根據指標管理方法論，構建的指標、維度元數據管理系統。爲了錄入指標、維度，數據團隊花費非常大的成本。指標管理工具僅僅提供指標錄入和檢索能力，指標規範性建設只能依賴於自上而下的管理，無法有效自運轉。對於指標一致性，只能是確保指標來自一個來源，並且交付方式不能是 Hive 表，而是指標本身，指標需要提供直接消費能力。

第二階段服務化建設的困境，北極星、數易指標消費的二義性問題，以及指標管理工具的本身困局，標準指標服務化建設應運而生。基本思路如圖所示，一個是指標管理工具提供模型管理，把指標和物理表進行關聯，另外，就是數鏈提供統一的消費網關，讓數易、北極星等數據產品打通這個消費渠道。

標準指標服務化建設，元數據管理需要擴展指標、維度的表達能力，並通過邏輯模型去關聯指標、維度和具體物理表的具體字段。爲了簡化下游消費邏輯，標準指標服務化需要提供一定的自動化取數邏輯能力。通常一個指標會在不同的物理表中實現，通過不同物理表間指標實現的一致性校驗，有效避免指標的二義性。

元數據管理

標準指標服務化最爲關鍵的元數據：指標、維度和邏輯模型。下面依次進行介紹。

指標

指標管理方法論主要介紹爲了提升指標表達語義能力，引入的計算指標和複合指標。派生指標是指物理表 (Hive/Starrocks/ClickHouse) 開發後可以直接對外服務的指標，也就是一定物化在物理表上對應字段的指標。計算指標是根據已註冊派生指標計算生成的指標，可以不物化到物理表上對應字段的指標，當前計算方式只支持加減乘除四則運算。例如，應答後取消率 = 應答後取消訂單量 / 當日應答訂單量。複合指標是指已註冊派生複合維度生成的指標，可以不物化到物理表上對應字段的指標，例如，“網花出 GMV”是根據指標 “含 openapi 含掃碼付 GMV”，複合維度“訂單聚合業務線”，維值爲“網 + 出 + 花” 生成的。如下圖所示，複合指標和計算指標可以相互嵌套，當前複合指標在嵌套鏈中最多隻能出現一次。

圖片

緯度

緯度類型，當前構建了四種：

• 維表維度：獨立的維表，維表會有唯一主鍵，以及其他屬性信息。維表維度可以構建數倉的星形模型。如果還有存在外鍵，則可以構建多層維表依賴的雪花模型。例如，城市維表維度 whole_dw.dim_city。

• 枚舉維度：key/value 鍵值對，鍵值對集中管理。例如：性別維度，對應的鍵值對男 (M)/ 女 (F)。

• 退化維度：維度邏輯無法集中管理，在不同物理表有着不同的實現，但表示的是同一個維度。例如，北極星的業務線維度，不同板塊下的業務線 id 轉換到北極星的業務線 id 有着不一樣的轉換邏輯，需要在具體實現中確定。

• 衍生維度：與退化維度不一樣的情況，維度邏輯可以集中化管理，該邏輯是一段處理代碼。

邏輯模型

邏輯模型在不同地方有不同的解讀，指標管理工具中的邏輯模型是指標、維度和物理表綁定的載體。邏輯模型可以綁定派生指標、計算指標、複合指標三種指標，也可以綁定維表維度、枚舉維度、衍生維度和退化維度四種維度。綁定到邏輯模型的指標、維度，可以直接綁定到物理表的字段，也可以綁定到根據物理表字段構建的計算字段。計算指標、複合指標還能根據計算邏輯或者複合邏輯，非物化的綁定。邏輯模型可以綁定多個指標、多個維度，反過來，一個指標、維度可以綁定到多個邏輯模型中。更通俗的說，一個指標的多種實現方式，是通過邏輯模型指定的。

邏輯模型在指定物理表的時候，還對物理表的存儲引擎、物理表的數據佈局、數倉層級進行了指定。當前數鏈支持 Hive、SR、ClickHouse 三種存儲引擎；數據佈局支持一般 APP 表、Cube 表和 GroupingSets 表；數倉層級支持 APP、DM、DWS 和 DWD。

取數邏輯自動化

數鏈建設標準指標服務化中，取數邏輯自動化，一方面能實現集中管理（Single Source of Truth），另一方面也是提效過程。取數邏輯自動化，在標準指標服務化中主要體現在：

支持通過指標、維度取數，用戶只需要提供所需要的指標和維度，通過取數接口獲取數據。上面邏輯模型中提到，指標與邏輯模型是一對多關係。自動化的取數邏輯，會根據所需的指標、維度、分區範圍，以及性能最佳的取數方式去選擇合適的邏輯模型。需要重點指出的是，當計算指標依賴的派生指標只能通過不同的模型獲取時，該取數過程支持通過聯邦查詢完成。

支持多種數據佈局的表，當前已經支持一般 APP 表、Cube 表和 GroupingSets 表。在取數中，已經屏蔽了不同數據佈局的取數邏輯，用戶無需關心原先表的數據佈局方式。

支持多樣的數倉建模模型，數倉建模規範產出中，可以是單例、星形和雪花模型。雪花和星形模型，自動化取數邏輯已經可以通過自動關聯所需的維表，實現維表維度中的不同維度屬性上卷等複雜的取數邏輯。

支持日、周、月、季粒度的上卷，在之前不同時間粒度的數據，只能通過開發不同的表實現。在查詢性能有保障的情況下，現在可以實現時間粒度的上卷能力。

一致性校驗

除了通過取數邏輯自動化實現取數提效之外，指標一致性也是數鏈建設標準指標服務化的核心出發點。指標一致性，一方面是通過統一的消費接口，另一方面，則是根據指標的實際現狀，進行被動和自動的校驗。

被動指標校驗，由用戶在平臺配置所需要的進行校驗的指標，如下圖所示，像 “最近一天全集團 GMV” 一樣，可能在多個邏輯模型中實現。因此，校驗邏輯是在幾個邏輯模型產出後，進行一次週期性的校驗。還有一種情況則是，“最近一天全集團 GMV”，可以通過 “最近一天網約車 GMV”+“最近一天兩輪車 GMV”+“最近一天貨運 GMV” 實現。因此，如下圖所示，檢驗邏輯可以是左側的邏輯模型_1 和右側的邏輯模型_1‘、邏輯模型_2’、邏輯模型_3‘產出後，進行一次週期性的校驗。

自動指標檢驗，檢驗的邏輯跟被動指標校驗的區別在於，模型拆解方式由系統自動生成，另外，可以進行校驗的指標也由系統篩選出來。

接入 & 查詢流程

當下接入數鏈標準指標服務化的服務有北極星、數易和 InSight，這三個產品也是滴滴最核心的數據產品。標準指標服務化在打通這三個產品的時候，都具備不同的挑戰，具體會在其他同學分享的文章進行詳述。這裏只簡單介紹下數據產品接入、查詢的基本流程。

通常流程中，數據 BP 將會根據指標管理工具依次錄入指標、維度，數據開發同學依據不同的數據架構方式構建數倉，並創建邏輯模型，和指標、維度進行關聯綁定。管理好的元數據，會被實時同步到數鏈。

數易、北極星、InSight 通過元數據接口，對報表、看板進行構建。發起數據查詢時，請求將發送到數鏈，並經過模型篩選、優化，生成最終的執行 SQL，查詢的數據再返回數據產品側。

數據服務體系整體架構

數鏈平臺旨在打造一站式規範、高效、穩定和安全的數據服務化平臺。當前服務的業務場景主要分爲本地數據服務化、離線數據服務化、特徵服務化和標準指標服務化。數鏈平臺分爲網關層和引擎層。網關實現的是統一的入口，並提供了鑑權、限流、緩存、路由、監控等能力。引擎層將實現場景分成了 key/value 鍵值對場景、多維分析場景和標準指標服務化場景。key/value 鍵值對場景主要服務特徵服務化，即牛盾、地圖特徵等業務場景。多維分析場景，主要服務於本地數據服務化和離線數據服務化，即 Horus、九霄等業務場景。key/value 鍵值對場景、多維分析場景是階段二的核心能力，標準指標服務化場景則是階段三的核心能力。

爲了支撐多樣、複雜的數據查詢訴求，我們還建設了統一的查詢中間件：DiQuery。DiQuery 依託於 MPP 的強大查詢能力，構建了統一的查詢能力，服務於數鏈、數易等數據產品。DiQuery 除了支持單表查詢能力之外，還支持了聯邦查詢、LOD 複雜函數查詢能力。DiQuery 支持同環比、四周均值等擴展函數，並支持在此基礎上的上卷能力。

總結與展望

滴滴數據服務體系的發展，經歷了原始的數據迴流任務方式、統一數據服務化平臺建設、標準指標服務化建設，一步步在建設更好的數據服務體系。標準指標服務化建設，是今年的重頭戲，在數倉研發、產品和平臺研發的鼎力協作中高速發展。

現在的數據服務體系，解耦了數據生產和數據消費的關係。接下來，需要推進數據生產的標準化，進一步解決指標一致性問題，提升數倉建設效率，並通過指標視角提升數據質量等等。標準指標服務化，將是一場一步步推進的數據平臺重要演化，並在業界已經慢慢拉開帷幕。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/7QjfQx1zmjpotbOjZLjZwA