一、网易数帆大数据产品介绍
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，实现基于自然语言的指标查询。
