一、網(wǎng)易數(shù)帆大數(shù)據(jù)產(chǎn)品介紹

1、網(wǎng)易數(shù)據(jù)分析的發(fā)展歷史

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

網(wǎng)易在數(shù)據(jù)分析領(lǐng)域積累了豐富的技術(shù)、應(yīng)用及解決方案層面的經(jīng)驗。

2、網(wǎng)易 EasyData 產(chǎn)品矩陣

網(wǎng)易有數(shù)的整體產(chǎn)品矩陣，自底向上包括：

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

以上四層構(gòu)成了網(wǎng)易 EasyData 的產(chǎn)品能力矩陣，體現(xiàn)了產(chǎn)品的豐富性和完整性。

下面，詳細介紹其中的指標系統(tǒng)，包括指標開發(fā)、治理、集市、應(yīng)用等模塊。

二、網(wǎng)易數(shù)帆指標中臺

1、為什么要構(gòu)建指標中臺？

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

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

針對指標應(yīng)用的服務(wù)模式，商業(yè)客戶方提出：

• 物化到業(yè)務(wù)庫：由于 Hive 源數(shù)據(jù)和下游應(yīng)用庫分屬不同團隊管理，客戶期望將指標中臺的加工結(jié)果，物化到下游業(yè)務(wù)系統(tǒng)庫。
• 指標目標管理：在指標計算的基礎(chǔ)上，客戶關(guān)注指標目標達成情況的在線查看、關(guān)聯(lián)指標的進展查看等，需要考慮指標業(yè)務(wù)目標的管理能力。
• 統(tǒng)一調(diào)度引擎：企業(yè)內(nèi)部已有成熟的調(diào)度平臺，如 Apache DolphinScheduler 等，采用統(tǒng)一的調(diào)度平臺可以方便指標上下游任務(wù)統(tǒng)一管理，使計算依賴管理成為可能，加快指標生產(chǎn)。

2、網(wǎng)易數(shù)帆指標中臺解決方案

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

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

三、指標中臺核心技術(shù)解析

1、構(gòu)建跨數(shù)據(jù)源的統(tǒng)一邏輯語義模型層

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

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

邏輯語義模型層設(shè)計的三大原則：

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

2、構(gòu)建簡潔高效的指標分析查詢語言

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

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

第一步：簡化指標定義

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

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

第二步 實現(xiàn)指標組合和復用

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

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

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

第三步 簡化時間口徑定義

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

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

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

目前，平臺已經(jīng)支持：

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

3、構(gòu)建統(tǒng)一指標查詢語義層

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

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

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

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

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

調(diào)度引擎適配，通過在服務(wù)端，把調(diào)度服務(wù)管理能力進行抽象；根據(jù)調(diào)度引擎去實現(xiàn)組件任務(wù)管理；在調(diào)度服務(wù)注冊后，到點就開始執(zhí)行，獲取執(zhí)行指標查詢的計算插件，在客戶端適配，將信息轉(zhuǎn)化成對應(yīng)參數(shù)，完成調(diào)度適配。

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

四、未來規(guī)劃及展望

未來數(shù)帆指標中臺將持續(xù)迭代，提供：

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