一、指標管理背景

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

• DS 或運營提出指標需求
• 數(shù)據(jù) BP 或數(shù)據(jù)產(chǎn)品梳理確認指標口徑
• 數(shù)倉工程師進行 ETL 開發(fā)

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

1. 指標的基本要求

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

（1）準確性

• 開發(fā)環(huán)節(jié)：通過測試中心進行指標數(shù)據(jù)的測試驗收；通過配置數(shù)據(jù)質量規(guī)則監(jiān)控指標新增分區(qū)的產(chǎn)出情況。
• 消費環(huán)節(jié)：通過配置指標監(jiān)控監(jiān)測數(shù)據(jù)異動。

（2）及時性

• 開發(fā)環(huán)節(jié)：在指標的生產(chǎn)任務上關聯(lián)對應的SLA基線，通過基線的智能預警，配合平臺的穩(wěn)定性保障措施，保證指標的及時產(chǎn)出。
• 消費環(huán)節(jié)：根據(jù)指標等級進行分級保障，不同等級的指標掛靠不同級別的基線，通過基線倒推保障下游數(shù)據(jù)的及時產(chǎn)出。

（3）一致性

• 開發(fā)環(huán)節(jié)和消費環(huán)節(jié)：通過人工校驗和反饋的方式確保指標的一致性。

（4）管理效率

• 開發(fā)環(huán)節(jié)：基于統(tǒng)一的一站式開發(fā)平臺進行指標的開發(fā)。
• 消費環(huán)節(jié)：在下游各個數(shù)據(jù)產(chǎn)品中定義指標口徑和取數(shù)邏輯。

由此可見，在滴滴數(shù)據(jù)體系 1.0 階段，指標的口徑散落在各個數(shù)據(jù)產(chǎn)品中，不但對一致性提出了挑戰(zhàn)，也造成了各個數(shù)據(jù)產(chǎn)品的重復開發(fā)。

2. 解決方案發(fā)展

滴滴數(shù)據(jù)體系 2.0 階段，核心目標之一是建立規(guī)范的、標準化的指標體系。

（1）指標字典

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

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

（2）指標管理工具

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

具體做法如下：

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

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

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

二、滴滴數(shù)據(jù)產(chǎn)品概況

1. 數(shù)據(jù)產(chǎn)品多樣，各自消費指標

滴滴數(shù)據(jù)產(chǎn)品包括面向高管的駕駛艙、面向業(yè)務的 BI 看板、面向 DS 的分析工具等，這些數(shù)據(jù)產(chǎn)品消費指標的模式分為兩種：傳統(tǒng)數(shù)倉模式和敏捷 BI 模式。

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

該模式存在以下問題：

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

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

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

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

該模式存在以下問題：

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

3. 問題總結

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

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

三、指標標準化建設

1. 整體方案

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. 解決方案：指標實現(xiàn)邏輯化——邏輯建模

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

邏輯模型改變了數(shù)倉交付數(shù)據(jù)、下游消費數(shù)據(jù)的方式。數(shù)倉從原先的交付表變?yōu)榻桓吨笜耍掠螐南M表變?yōu)橄M指標，從而對用戶屏蔽指標的技術口徑實現(xiàn)。

邏輯模型解耦了指標生產(chǎn)和消費。 

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

4. 解決方案：指標實現(xiàn)邏輯化——指標質量保障

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

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

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

5. 解決方案：指標實現(xiàn)邏輯化——指標質量保障

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

指標消費統(tǒng)一化的整體架構分為三層：

最上層是統(tǒng)一的查詢?nèi)肟冢峁┙y(tǒng)一的查詢服務，通過 DSL 描述指標維度的查詢請求，DSL 包含指標、維度、過濾條件、時間范圍四個要素?；谥笜司S度的查詢方式對下游屏蔽了計算口徑的實現(xiàn)，由統(tǒng)一的查詢服務完成從指標定義到計算口徑的轉化，主要實現(xiàn)流程如下：

（1）構建指標 DAG

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

（2）模型篩選

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

（3）模型擇優(yōu)

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

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

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

（4）模型查詢樹

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

（5）生成聯(lián)邦查詢

基于模型查詢樹生成聯(lián)邦查詢 SQL，發(fā)送至最下層的數(shù)據(jù)虛擬化層。

數(shù)據(jù)虛擬化層主要用于執(zhí)行聯(lián)邦查詢及擴展自定義計算函數(shù)。其中，聯(lián)邦查詢 SQL 分為兩個部分：

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

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

6. 重塑消費體系

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

7. 收益總結

（1）標準化管理

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

（2）指標質量保障

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

（3）指標高效消費

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

（4）指標治理

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

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

（1）生產(chǎn)側

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

（2）消費側

• 構建靈活、低門檻、高效的指標應用?；谶壿嫶髮挶砗蛿?shù)據(jù)虛擬化的方案，構建可復用的指標池，支撐下游用戶進行靈活的自助分析，提升指標消費的效率?；谥笜司S度的統(tǒng)一查詢服務，對所有用戶屏蔽指標的計算口徑實現(xiàn)，降低指標消費的成本。

四、后續(xù)規(guī)劃

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

（1）打造全生態(tài)體系的產(chǎn)品矩陣

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

（2）持續(xù)為數(shù)據(jù)體系提效

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

（3）實時指標標準化

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

以上就是本次分享的內(nèi)容，謝謝大家。

五、Q&A

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

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

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

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

Q2：針對指標調(diào)用，上游的數(shù)據(jù)產(chǎn)品準入策略是什么？

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