一、網易數帆大數據產品介紹

1、網易數據分析的發展歷史

網易自 2006 年開始使用大數據技術組件，如分布式數據庫、分布式文件系統、分布式搜索引擎，支撐了網易互聯網 2.0 時代的產品。自 2009 年開始基于 Hadoop 構建數據分析及運維相關工作。在 2014 年上線了大數據平臺猛犸、網易有數等產品，加速了網易內部大數據的規模化應用。針對很多企業產生的開展數據分析的訴求，網易在 2017 年啟動對外商業化產品推廣，并在 2018 年將數據中臺構建覆蓋到網易嚴選、考拉、音樂、新聞等業務，形成了“全鏈路數據中臺”解決方案，并對外發布。在 2020 年，網易提出“數據生產力”的理念，倡導“人人用數據、實時用數據”。在 2022 年發布了數據治理和數據開發一體化“數據治理 2.0”解決方案，2023 年發布了全新產品 ChatBI、指標中臺。

網易在數據分析領域積累了豐富的技術、應用及解決方案層面的經驗。

2、網易 EasyData 產品矩陣

網易有數的整體產品矩陣，自底向上包括：

• 底層數據計算、存儲引擎的組件封裝研發，涵蓋 HDFS/S3、Amoro（實時數據湖）、Yarn/K8s、Spark、Hive、Impala、Flink 等，還構建了自動化運維管理能力；
• 基于 DataOps 全生命周期數據開發產品套件，涵蓋數據集成、數據開發、數據測試、任務運維等能力；
• 打造了包括數據標準、元數據管理、數據地圖、指標系統、數據質量、數據資產中心、模型設計中心、數據安全、數據服務等九大產品，來滿足不同場景下的開發和管理訴求；
• 最上層，由有數 BI、機器學習、標簽畫像，作為應用層對大數據技術或平臺進行業務化價值挖掘。

以上四層構成了網易 EasyData 的產品能力矩陣，體現了產品的豐富性和完整性。

下面，詳細介紹其中的指標系統，包括指標開發、治理、集市、應用等模塊。

二、網易數帆指標中臺

1、為什么要構建指標中臺？

綜合內部實踐和外部交流，指標使用問題主要集中在以下六大方面：

• 指標口徑不一致：常規數據質量問題統計中，約有 31% 涉及指標口徑問題。
• 指標入口不統一：缺少一個企業級的統一消費入口，不知道從哪去找，拿到了不知道口徑是否一致、是否可信。
• 指標價值難以量化：難以跟蹤和量化指標的使用，報表開發成本涉及存儲資源、計算資源、開發資源等多方投入，如果長時間無人訪問，就是一種浪費。
• 指標開發效率低：指標開發涉及多部門、多角色協同，業務人員無法獨立完成，數據分析團隊成為指標開發的瓶頸。
• 重復計算大量消耗資源：大量的中間表計算冗余、復用度低等，涉及到分層設計加工。
• 指標質量差：問題溯源難度大，排查效率低；因為加工路徑長，開發引入的問題占比超 60%，而且其中 90% 由業務先發現。

針對指標應用的服務模式，商業客戶方提出：

• 物化到業務庫：由于 Hive 源數據和下游應用庫分屬不同團隊管理，客戶期望將指標中臺的加工結果，物化到下游業務系統庫。
• 指標目標管理：在指標計算的基礎上，客戶關注指標目標達成情況的在線查看、關聯指標的進展查看等，需要考慮指標業務目標的管理能力。
• 統一調度引擎：企業內部已有成熟的調度平臺，如 Apache DolphinScheduler 等，采用統一的調度平臺可以方便指標上下游任務統一管理，使計算依賴管理成為可能，加快指標生產。

2、網易數帆指標中臺解決方案

網易數帆指標中臺（EasyMetrics）介于數據中臺和下游的數據應用（主要是 BI）之間，提供了指標的標準化能力。通過“一次定義，多次復用”（Build once , use many），為業務決策和管理提供單一、可信的數據來源，解決長期以來指標口徑不一致的問題。指標中臺，構建在跨數據源（Catalog）的統一邏輯語義模型層之上，內置了一套指標定義語言，提供了獨立于第三方計算引擎和調度系統的指標自動計算的能力，通過配置化的方式可以自動完成指標的開發，大幅度提高了指標開發的效率。

如圖所示，網易數帆指標中臺方案處于中臺和下游系統之間，數據來源于數據中臺的 DWD 層（事實數據），經過指標平臺加工后，提供給下游系統應用。通過邏輯語義模型層屏蔽上游不同數據源的差異，通過引入統一語義層簡化了指標的定義，通過獨立的第三方引擎&調度，實現了指標開發、消費、管理一體化的服務平臺能力。

三、指標中臺核心技術解析

1、構建跨數據源的統一邏輯語義模型層

統一邏輯語義模型層，是構建在數據倉庫和下游數據應用之間的獨立層(stand-alone layer)，它可以屏蔽不同的數據來源差異，來統一應對下游的數據應用。

如上圖所示，邏輯語義模型層主要包括事實表和維度表，多事實表、維度表之間的關系，可以在邏輯語義模型層說明。如客戶表、產品表、訂單表、銷售管理表等。度量字段主要有產品銷售量、產品銷售價格等，包括客戶維度、商品類型維度、訂單屬性等維度。

邏輯語義模型層設計的三大原則：

• 屏蔽數據源差異：不同數據源的插件化擴展管理，構建 PF4J 庫，實現可插拔式的插件式數據源管理模塊；
• 逆向建模：基于現有物理表 DDL 能快速逆向建模出邏輯數據模型；
• 物化 DDL：建模出的邏輯數據模型，可以正向生成物化的 DDL，方便生成物理表。

2、構建簡潔高效的指標分析查詢語言

傳統 SQL 不像通用編程語言一樣支持組合繼承等能力，所以采用 SQL 寫任務往往有大量的冗余代碼，而這些冗余代碼也常常會因為邏輯不一致，導致指標的計算口徑不一致。

我們引入指標分析查詢語言來實現簡化指標定義、指標的組合和復用、簡化時間口徑定義等目的。

第一步：簡化指標定義

構建在語義模型的基礎上，不需要再定義 From、Join，天然支持多維分析。下圖示例計算某個子類下每個產品的總銷售額：左側為傳統SQL實現，有大量的 From 部分；右側為指標分析查詢語言實現腳本，Select 指定計算邏輯，where 指定計算限定條件，BY 指定分組匯總維度。

簡化之后，只需要指定口徑、限定和分組維度，就可以完成指標開發。將指標定義交還給業務，最大化實現業務用戶的自助開發，充分緩解數據分析人員的開發壓力。

第二步 實現指標組合和復用

創建和存儲指標來指定數據的“基本事實分析”(即單一事實來源)。存儲的指標可以在其他指標中重復使用。

如下圖示例：某銀行事實表存在“網齡千元橙分期完成數”、“今年網齡千元橙分期目標完成數量”兩個度量數據。通過日期派生生成指標“今年網齡千元橙分期完成數”，并進一步通過復合計算（‘/’），實現指標“網齡千元橙分期目標完成進度”定義。

因為指標的靈活復用，大大提高了指標定義效率。

第三步 簡化時間口徑定義

常規模式下，需要頻繁地基于 SQL 進行時間周期邏輯的開發，并且在多個 SQL 中重復編寫代碼，這樣容易出錯，且不容易動態調整。通過引入時間周期，自然簡化了時間口徑的定義。通過內置和自定義的方式，可以實現多種時間口徑的定義和管理，包括交易日歷等時間周期的支持。語法上可以把時間維度字段對應于一個時間周期，來限定時間口徑，從語法上統一，該時間口徑還能隨時間動態變化。

定義指標時經常需要包含時間口徑，我們可以通過簡單的語法直接使用時間周期，從而實現時間口徑的統一，并且支持上一個交易日等證券行業特色的時間周期（交易日歷），來滿足客戶的特定時間口徑需求。

實現層面，將指標分析查詢語言定義成 antir4 格式的詞法文件（MaqlLexer.g4、MaqlParser.g4），將指標、度量、屬性、維度周期都定義為詞法單元。經過詞法分析、語法分析、語義分析，將指標分析查詢語言表達式和邏輯語義模型層轉化為 MetricsDSL（統一的指標查詢語義）。

目前，平臺已經支持：

• AVG、COUNT、SUM 等 7 種聚合函數。
• AND、OR 等 10 種邏輯操作函數。
• +、-、*、%、ABS 等 11 種常用數據處理函數。
• 直接使用時間周期。

3、構建統一指標查詢語義層

通過構建統一的指標查詢語義層 MetricsDSL，將指標的查詢需求做進一步抽象，并且在語義層實現指標依賴消解等工作，屏蔽底層不同數據源的 SQL 語法差異，并且隔離不同的指標查詢需求（不同語法）對于底層數據源的入侵和影響，從而方便分別擴展不同的指標查詢語法和對接不同的數據源目標。

基于 Calcite 進行引擎 SQL 翻譯，完成 MetircsDSL 的解析：

• 邏輯模型和指標結果表信息作為上下文，使用 DSL 轉化為 Calcite RelNode 語法樹。
• 選擇性使用 RBO 優化器對 Calcite RelNode 進行優化，形成優化語法樹。
• 使用目標數據源方言翻譯 Calcite RelNode 為 SQL，形成目標數據庫引擎 SQL。

4、引擎解耦，靈活對接第三方引擎

為了能夠靈活對接第三方引擎，包括調度引擎、查詢引擎和計算引擎，我們通過適配組件來完成引擎和調度的對接，并基于抽象引擎的能力來完成指標中臺核心能力的建設。

調度引擎適配，通過在服務端，把調度服務管理能力進行抽象；根據調度引擎去實現組件任務管理；在調度服務注冊后，到點就開始執行，獲取執行指標查詢的計算插件，在客戶端適配，將信息轉化成對應參數，完成調度適配。

查詢能力和計算方面，也是類似的架構，將查詢和計算能力進行抽象，如 Impala、JDBC 等組件化方式，對接適配不同的計算組件，如 Spark、JDBC、Flink 等，完成計算。

四、未來規劃及展望

未來數帆指標中臺將持續迭代，提供：

• 深入指標應用場景：數據洞察、儀表盤、KPI 管理、指標地圖等。
• 對接更多 BI 系統，打通生產到消費的完整鏈路。
• 支持更多的數據源，例如 Doris 等 MPP 數據源。
• 接入 AIGC，實現基于自然語言的指標查詢。