什麼是資料服務化
大資料開發的主要流程分為資料內建、資料開發、資料生産和資料回流四個階段。資料內建打通了業務系統資料進入大資料環境的通道，通常包含周期性導入離線表、實時采集并清洗導入離線表和實時寫入對應資料源三種方式，目前滴滴内部同步中心平台已經提供了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支援同環比、四周均值等擴充函數，并支援在此基礎上的上卷能力。
總結與展望
滴滴資料服務體系的發展，經曆了原始的資料回流任務方式、統一資料服務化平台建設、标準名額服務化建設，一步步在建設更好的資料服務體系。标準名額服務化建設，是今年的重頭戲，在數倉研發、産品和平台研發的鼎力協作中高速發展。
現在的資料服務體系，解耦了資料生産和資料消費的關系。接下來，需要推進資料生産的标準化，進一步解決名額一緻性問題，提升數倉建設效率，并通過名額視角提升資料品質等等。标準名額服務化，将是一場一步步推進的資料平台重要演化，并在業界已經慢慢拉開帷幕。