一、指標管理背景

常見的指標交付流程如下：

• DS 或運營提出指標需求
• 數據 BP 或數據產品梳理確認指標口徑
• 數倉工程師進行 ETL 開發

最終交付的指標會被應用到下游的各個數據產品中，比如管理駕駛艙、BI 報表以及分析工具。

1. 指標的基本要求

數倉交付的指標必須滿足準確性、及時性以及一致性的要求。同時，在指標交付的過程中，需要兼顧指標管理的效率。在滴滴數據體系 1.0 階段，整體的策略如下：

（1）準確性

• 開發環節：通過測試中心進行指標數據的測試驗收；通過配置數據質量規則監控指標新增分區的產出情況。
• 消費環節：通過配置指標監控監測數據異動。

（2）及時性

• 開發環節：在指標的生產任務上關聯對應的SLA基線，通過基線的智能預警，配合平臺的穩定性保障措施，保證指標的及時產出。
• 消費環節：根據指標等級進行分級保障，不同等級的指標掛靠不同級別的基線，通過基線倒推保障下游數據的及時產出。

（3）一致性

• 開發環節和消費環節：通過人工校驗和反饋的方式確保指標的一致性。

（4）管理效率

• 開發環節：基于統一的一站式開發平臺進行指標的開發。
• 消費環節：在下游各個數據產品中定義指標口徑和取數邏輯。

由此可見，在滴滴數據體系 1.0 階段，指標的口徑散落在各個數據產品中，不但對一致性提出了挑戰，也造成了各個數據產品的重復開發。

2. 解決方案發展

滴滴數據體系 2.0 階段，核心目標之一是建立規范的、標準化的指標體系。

（1）指標字典

為了提升指標管理的效率，最初采用的是傳統指標字典的解決方案，即提供統一的指標平臺，用于指標錄入、解釋指標口徑。

該方案存在以下問題：不規范的命名會造成指標口徑的二義性，譬如同義不同名、同名不同義等；指標管理的權責沒有明確的定義，指標錄入的流程沒有嚴格的管控，久而久之就會造成指標口徑的混亂以及指標體系的臃腫等問題，導致產品走向被棄用的結局。

（2）指標管理工具

為了解決上述問題，基于數倉的維度建模方法論構建指標管理工具。通過系統自動生成規范的中英文名稱，解決指標的重復建設問題，從而消除指標的二義性。同時明確了指標管理的權責，以及指標錄入的流程管控。

具體做法如下：

• 根據滴滴的業務屬性，劃分網約車、兩輪車等獨立的業務板塊。
• 在業務板塊下劃分數據域以及時間周期。時間周期主要是用于描述數據統計的時間范圍，數據域通常是業務過程或者維度進行抽象的集合。
• 在數據域下劃分業務過程。業務過程通常是企業業務活動的事件。
• 在業務過程下劃分原子指標以及修飾詞。原子指標通常是某個業務過程的度量，是業務定義中不可再分的指標。修飾詞通常是除維度以外的限定條件。原子指標和修飾詞以及時間周期構成了派生指標。

以網約車板塊下的“最近 1 天完單 GMV”為例，GMV 是原子指標，完單是修飾詞，最近 1 天是統計范圍。系統根據原子指標、修飾詞以及時間周期的中英文名稱自動生成派生指標“最近 1 天完單 GMV”的中英文名稱。

其次，指標管理的方法論由數據側強管控。其中，相對不變的數據域、以及通用的時間周期，由業務板塊管理員統一管控。和數據域強相關的業務過程、原子指標以及修飾詞，由數據域管理員統一管控。由于派生指標的中英文名稱是系統根據原子指標、修飾詞以及時間周期自動生成。所以，一旦原子指標或者修飾詞的口徑發生變更，下游派生指標就會自動級聯變更。此外，根據不同等級對指標的新增和變更流程進行強管控，譬如 T1 核心指標的變更，需要數據管理員、業務板塊管理員分別進行審批。

二、滴滴數據產品概況

1. 數據產品多樣，各自消費指標

滴滴數據產品包括面向高管的駕駛艙、面向業務的 BI 看板、面向 DS 的分析工具等，這些數據產品消費指標的模式分為兩種：傳統數倉模式和敏捷 BI 模式。

傳統數倉模式下，數據 DS 提出指標需求，數據BP確認指標口徑，并將指標錄入指標管理工具。數倉工程師在數據開發平臺上進行指標加工，產出各個業務方向的 APP 表。下游的各個數據產品基于 APP 表構建數據集，并在數據集上定義指標的取數邏輯。

該模式存在以下問題：

• 指標管理工具和指標生產、消費鏈路是脫離的，指標管理工具等同于一個規范化的線上 wiki，指標管理的業務價值難以評估。
• 下游各個數據產品各自維護指標的計算口徑, 指標口徑的一致性無法得到保障。
• 下游用戶只能基于數倉提供的APP表中包含的維度進行數據分析，無法進行靈活的下鉆分析。

2. 敏捷 BI 難以管控指標口徑

傳統數倉模式下，所有數據需求都要經過數倉的排期開發，在業務需求快速變化的場景下，數倉的開發效率以及需求響應速度就成為業務發展的瓶頸。由此誕生敏捷 BI 模式。

敏捷 BI 模式倡導“人人都是分析師”，即支持業務人員在 BI 工具中定義和加工指標，通過短平快的方式解決需求快速變化時的分析效率問題。在這種模式下，數倉提供的是大寬表，業務人員基于大寬表進行指標的加工以及靈活的分析。

該模式存在以下問題：

• 指標的計算口徑由業務人員維護，并且散落在各個數據產品以及數據集中，導致指標口徑的一次性問題變得更加嚴峻。
• 指標加工對于業務人員來說，存在一定的門檻。

3. 問題總結

綜上所述，整個指標交付流程存在以下問題：

• 指標生產成本高。數倉面向應用層去構建 APP 表，可復用性差，譬如需要在 APP 表中冗余存儲維度屬性，針對衍生維度或者計算指標需要做二次計算。此外，開發和運維成本高，譬如針對于不同時間粒度下的同一個指標，數倉需要開發多張 APP 表，指標的生產成本高進而影響數倉的交付效率。
• 指標消費效率低。在傳統數倉模式下，基于 APP 表的交付方式很難支撐業務進行靈活的自助分析。在敏捷 BI 模式下，如果業務需要分析某個指標，首先需要在指標管理工具中找到該指標，然后基于指標對應的物理表和計算口徑手寫 SQL 進行取數驗數，不但流程長，而且使用門檻高。
• 指標口徑存在一致性問題。由于指標的取數邏輯沉淀在各個數據產品以及數據集中，所以會造成不同數據產品間指標數據的不一致，乃至同一數據產品上不同BI看板間指標數據的不一致。
• 規范執行落地難。由于指標管理游離在指標生產和消費鏈路之外，導致指標管理的規范執行程度難以評估。其次，指標管理的成本較高，而下游消費指標場景比較單一，導致指標管理的收益不足，進而影響數據BP的錄入意愿，從而加重了指標管理執行的難度。

三、指標標準化建設

1. 整體方案

指標標準化建設的整體目標是打通指標管理、生產、消費的全鏈路，解決指標口徑的一致性問題，提升指標生產消費的效率。整體建設思路和業界的 headless BI 模式類似，核心是將指標從數據生產、消費鏈路中抽離出來，作為獨立的一層，不同的數據產品通過對接同一個指標平臺，實現屏蔽指標技術口徑，確保指標口徑一致性的目的。

指標定義標準化建設的整體架構分為三個部分：

• 指標定義標準化：基于指標管理工具，進行指標的標準化定義以及流程管控。
• 指標實現邏輯化：通過邏輯模型隔離指標生產和消費，提升物理模型可復用性，保障指標交付質量。
• 指標消費統一化：基于指標維度的統一查詢 DSL，降低下游消費門檻，通過接入統一查詢服務，保障指標口徑一致性，通過數據虛擬化技術增強 OLAP 的分析能力，提升取數靈活性。

2. 解決方案：指標定義標準化

為了提升指標的語義化表達能力，在基礎派生指標之上，引入了計算指標以及復合指標。計算指標和復合指標不需要落表開發。

• 基礎指標：對應于物理表上的某個字段。
• 計算指標：基于其他指標四則計算得到。
• 復合指標：基于其他指標復合維度得到。

此外，支持四種維度類型：

• 維表維度：對應于一張維表，維表包含唯一的主鍵以及其他的維度屬性，譬如城市維度。
• 枚舉維度：用來描述可枚舉的 k-v 鍵值對，譬如業務線維度，key 是業務線 ID，value 是業務線名稱。
• 退化維度：某些場景下，一些維度在不同的物理表上有不同的計算邏輯，但代表的是同一個維度。退化維度主要用于解決這種場景。
• 衍生維度：和退化維度類似，區別在于衍生維度的計算邏輯比較通用，可以進行集中化管理。

基于四種維度類型可以構建邏輯維度，用于描述維度間的關聯關系，通過邏輯維度可以構建數倉的雪花模型。

除了對指標維度的定義規范進行標準化之外，還需要對指標維度的錄入流程進行標準化。

• 將 DS 提指標需求、數據 BP 錄入指標、數據開發交付指標的流程進行線上化。
• 對指標的變更流程進行強管控，當指標口徑發生變更時，所有下游指標會自動級聯變更，并通知到所有的下游應用。

為了規范指標在下游的安全使用，構建了完善的指標權限體系，包括指標權限以及行級權限。指標權限對應于指標的列權限，擁有指標權限才能使用指標。行級權限主要控制指標的數據可見范圍，比如某個大區運營只能看到該大區下的指標數據。

為了防止平臺上錄入無用指標導致指標泛濫，需要進行常態化的指標維度治理。

• 在看清方面，構建了從基礎指標、時間周期、修飾詞到基礎指標，基礎指標和維度到計算指標和復合指標的全鏈路血源。
• 在治理措施方面，針對長期未使用的指標維度，會自動進入廢棄狀態，針對公共的指標維度，支持跨業務板塊引用和管理。

綜上所述，基于指標維度的標準化定義規范以及流程管控，確保指標定義標準化。通過配合常態化的指標維度治理，達到長期的指標定義標準化。

3. 解決方案：指標實現邏輯化——邏輯建模

指標的技術口徑是由物理表字段、聚合方式和維度共同決定。在指標實現邏輯化部分，通過抽象出邏輯模型，構建指標維度和物理表字段的映射關系，同時定義指標的聚合方式，從而實現指標的技術口徑定義。

邏輯模型改變了數倉交付數據、下游消費數據的方式。數倉從原先的交付表變為交付指標，下游從消費表變為消費指標，從而對用戶屏蔽指標的技術口徑實現。

邏輯模型解耦了指標生產和消費。 

• 邏輯模型可以適配不同的計算引擎，對用戶屏蔽了不同引擎的計算差異。
• 邏輯模型可以適配不同的表粒度，對用戶屏蔽 cube 表、groupingsets 表以及普通表在數據存儲上的差異。
• 邏輯模型可以適配不同的數倉架構，不僅支持 APP 表的接入，也支持直接接入 DWM 和 DWD 表。
• 邏輯模型可以實現配置即開發。譬如針對同一指標不同時間粒度的情況，數倉只需要開發天粒度的指標，自然周、自然月指標可以基于最近一天指標上卷得到，譬如計算指標和復合指標可以通過實時計算得到，無需落表開發，譬如通過邏輯維度可以自動構建數倉的星形模型和雪花模型。

4. 解決方案：指標實現邏輯化——指標質量保障

為了支持同一個指標在不同模型中同時存在，需要保證指標在不同模型間的數據一致性。

• ETL 階段：當指標的生產任務變更時，需要產出指標的測試報告后方可準入。同時在 DQC 上配置指標的數據質量規則，用來檢測新增分區的產出質量。
• 邏輯模型階段：在模型發布前，需要針對模型上的指標進行驗數，并且需要和線上版本的數據進行比對，以確保模型的正確配置和變更。為了保證指標的一致性，針對模型上的所有指標進行不同模型間的一致性校驗，只有數據一致才允許發布到線上。同時，平臺會默認監聽模型分區的變更，并自動進行系統一致性校驗，一旦出現數據不一致的情況則會及時告知用戶。

平臺上的流程規范和監控手段，只是為了幫助用戶快速并及時地發現問題，核心需要自上而下的目標牽引，以及對指標質量的高度重視。

5. 解決方案：指標實現邏輯化——指標質量保障

在指標標準化建設前，下游各個數據產品各自維護指標的取數邏輯，導致各個應用間的指標一致性無法得到保障。期望通過構建統一的指標消費體系，解決指標口徑的一致性問題。

指標消費統一化的整體架構分為三層：

最上層是統一的查詢入口，提供統一的查詢服務，通過 DSL 描述指標維度的查詢請求，DSL 包含指標、維度、過濾條件、時間范圍四個要素。基于指標維度的查詢方式對下游屏蔽了計算口徑的實現，由統一的查詢服務完成從指標定義到計算口徑的轉化，主要實現流程如下：

（1）構建指標 DAG

根據用戶的查詢請求構建指標查詢樹，每個節點代表一個指標，節點間的邊代表指標間的依賴關系。

（2）模型篩選

針對每個指標，篩選出滿足查詢條件的模型列表。主要會進行維度、權限、時間的篩選。維度篩選用來過濾維度不匹配的模型，權限篩選用來過濾不包含鑒權維度的模型，時間篩選用來過濾數據范圍不匹配的模型。

（3）模型擇優

模型篩選后，指標和模型間是多對多的關系。針對每個指標，需要進一步確定最優的查詢模型，即模型擇優，主要采取性能為主，調控為輔的思路。主要包括以下幾種策略：

• 周期排序：譬如自然月指標同時存在天模型和月模型中，優先選取月模型，通過減少計算數據量提高查詢速度。
• 引擎排序：譬如指標同時存在 Hive 模型和 SR 模型中，優先選取 SR 模型，充分利用 OLAP 引擎的計算能力。
• 粒度排序：譬如指標同時存在 Cube 表模型和普通表模型中, 優先選取 Cube 表模型，通過指標的預計算提高查詢速度。
• 效率排序：譬如優先選取能夠滿足更多指標查詢請求的模型，針對同一個模型上的指標進行查詢請求的合并，通過減少查詢次數提高查詢速度。

最后支持在模型上配置推薦度，輔助人工進行策略調控。

（4）模型查詢樹

模型擇優后，確定了每個指標的查詢模型。由于不同的指標可能對應同一個模型，需要對同一個模型的指標查詢進行合并，將指標查詢樹轉變成模型查詢樹，模型查詢樹的每個節點代表一個模型以及可查的指標列表，節點間的邊代表模型間的關聯關系。

（5）生成聯邦查詢

基于模型查詢樹生成聯邦查詢 SQL，發送至最下層的數據虛擬化層。

數據虛擬化層主要用于執行聯邦查詢及擴展自定義計算函數。其中，聯邦查詢 SQL 分為兩個部分：

• 引擎 SQL：描述同一模型上所有指標的查詢 SQL，不同模型的引擎 SQL 會根據引擎類型發送到不同的數據引擎執行數據查詢。
• MPP SQL：描述不同模型間指標的計算關系，用于匯聚不同模型間的指標并進行二次計算，比如周、月、季、年的上卷，XTD，最近 N 天的上卷以及同環比均值等。

數據虛擬化層基于開源的 MPP 實現。通過擴展查詢協議，支持聯邦查詢 SQL 的語義化描述；通過擴展自定義 connector，實現基于聚合下推的聯邦查詢能力，提升跨源查詢的性能；通過擴展自定義計算函數，提升下游取數的靈活性。

6. 重塑消費體系

通過指標消費統一化，實現指標的一處定義，全局消費，重塑下游數據產品消費指標的方式。目前已經覆蓋滴滴內部絕大部分的數據產品，譬如駕駛艙，BI報表看板、復雜表格和探索分析，以及各種分析工具等，同時也支持各個業務的數據產品接入，未來也會接入實驗分析領域的相關產品。

7. 收益總結

（1）標準化管理

通過指標維度的標準化定義規范及流程管控，保證了指標維度的標準化管理，為指標的質量保障奠定基礎。

（2）指標質量保障

通過邏輯模型隔離指標生產和消費，基于平臺化的監控手段以及自上而下的目標牽引保障指標口徑的一致性，為基于指標維度消費奠定基礎。

（3）指標高效消費

基于指標維度的統一查詢服務，對下游屏蔽了指標的計算口徑。通過邏輯大寬表加數據虛擬化的方案，提升下游取數的靈活性，從而促進指標的高效消費，增強指標維度治理的動力。

（4）指標治理

指標維度的動態治理，進一步促進指標維度的長期標準化，實現指標標準化價值的正循環，推進了指標標準化建設從「可做可不做——不得不做——愿意做」的過程演變。

指標標準化建設對于數據體系來說也是意義非凡。

（1）生產側

• 通過邏輯大寬表和數據虛擬化的方案，使得部分指標維度無需落表開發，降低數倉的開發成本，提升數倉的需求交付效率。
• 通過提供系統化的指標質量保障方案，保障指標口徑的一致性，降低數倉的運維成本。
• 通過構建完善的指標維度血緣，為數倉治理提供可靠的依據，降低數倉的治理成本。

（2）消費側

• 構建靈活、低門檻、高效的指標應用。基于邏輯大寬表和數據虛擬化的方案，構建可復用的指標池，支撐下游用戶進行靈活的自助分析，提升指標消費的效率。基于指標維度的統一查詢服務，對所有用戶屏蔽指標的計算口徑實現，降低指標消費的成本。

四、后續規劃

滴滴指標標準化建設的發展歷程總結為三個階段：探索、拓展和深入。當前處于拓展階段，未來將走向深入階段。主要包含以下三個方面：

（1）打造全生態體系的產品矩陣

• 打通實驗分析領域，保證實驗指標和 BI 指標口徑的一致性。
• 通過自助分析產品，提供更加靈活的取數方式，為 DS 及運營提效, 提升指標標準化建設的價值感知。
• 探索基于大模型的指標取數方式，進一步降低下游取數的門檻。

（2）持續為數據體系提效

• 從指標錄入效率和模型構建靈活性等方面，進一步提升指標管理和開發的效率。
• 基于統一的指標監控告警能力，進一步保障指標的交付質量。
• 打通指標生產鏈路，實現指標生產自動化，進一步降低數倉的開發成本。

（3）實時指標標準化

指標標準化建設拓展至實時指標體系。實時場景不同于離線場景，對于 QPS 和查詢性能有著更高的要求，需要進行更加完善的穩定性建設。

以上就是本次分享的內容，謝謝大家。

五、Q&A

Q1：是否支持同一請求里查詢不同模型？不同引擎查詢速度不同，多個結果要出來一起再給出，中間是否有超時處理?

A1：支持在一次請求里查詢不同的模型，按照公共維度關聯。針對不同模型查詢速度存在差異的情況，推薦用 join 性能較好的 StarRocks，當前方案不做中間存儲，在 MPP 層并行處理。

針對查詢速度做過一系列的性能優化，譬如在統一查詢層實現了查詢緩存，在數據虛擬化層實現了聚合下推、字段裁剪等，未來考慮實現查詢預熱、自動物化等性能優化手段，譬如針對 Hive 模型進行預計算和加速。

指標管理的成本較高，指標錄入和開發的效率提升是未來的核心方向之一，主要是通過提供指標的批量錄入和變更，以及自動化構建模型等能力。

Q2：針對指標調用，上游的數據產品準入策略是什么？

A2：指標主要服務于數據產品，沒有應用到線上。數據產品包括BI報表、駕駛艙、各種分析工具等，離線指標整體的 QPS 不高。在查詢性能方面，未來重點是指標的自動生產、自動物化，提升整體查詢效率。