一、整体思路与框架
首先是整个欧拉平台建设的思路和框架。
企业面临本质问题是数据体系的信息熵太大、信息量小，数据治理本质是打造一个对抗熵增的系统。信息熵往往就等价于确定性，比如我们看到一份数据，如果不知道它用来算什么指标、有什么价值、上下游的应用和所占用的成本，确定性就很低，信息熵就很大。因此我们需要从数据的可理解性、规范性、易用性、可靠性、安全性、成本几个方面来提升确定性。
1、平台主旨
怎么能让一个杂乱无序的系统变得规整？在物理学中，一个封闭系统要对抗熵增，通常会对外做功，这有点像事后治理的概念。例如，对于已有存量的数据，需要通过扫描元数据进而发现问题来进行事后治理。这是大家普遍知道的做法，也就是先污染后治理。
物理学上其实还有一种方法，即建立一个内部自治的耗散结构。就像人体，即使躺在那里没有外部做功，也不会马上生病，因为人体本身是一个自调节的耗散结构。
因此，我们在数据治理过程中 也可以尝试建立生产即治理的耗散结构，使得数据在整个生产和使用过程中都是规范和自调节的，缓解熵增（变混乱）过程。
本文内容正是关于如何建立从数仓到指标生产即治理的耗散结构。
2、评价体系
首先我们需要过资产分来量化数据体系的信息熵，建立一个评价体系，形成对数据现状、治理效果的共识，进而牵引、推动治理平台的落地。资产分高越则数据的信息熵越低、数据的确定性越高。在此基础上，基于欧拉平台，配合治理专项不断提高资产分。
3、数据痛点及平台应对方案
很多企业在数据治理的时用了各种方法仍然避免不了 3 个问题——治理难、维护难、使用难。数据治理的成果像沙子堆的碉堡，缺乏骨架，经不起风吹草动。而腾讯欧拉这样生产即治理的平台工具就可以成为骨架。
因此，欧拉数据生产即治理的理念是从业务角度出发，重点关注标准化、可信数据资产的沉淀和交付。将数据资产交付分为主要3步：
第一步：数据体系规划。即数据的业务、概念建模。定义业务域、主题域、业务过程等，定义和管理数据标准，例如字典、命名规范、度量、单位、词根等，以及质量标准。
第二步：数据建模。通常是逻辑建模、物理建模，形成一个Uni-Model，即统一模型。
第三步：数据发现与应用。酒香也怕巷子深，要呈现可信数据资产，需要将建模后的元信息和元数据集成起来，形成一个上层应用能够使用的统一数据服务和资产目录，供大家查找、发现、使用和申请数据。
4、欧拉的服务框架
接下来介绍欧拉平台服务的框架，主要有3个子产品——资产工场、指标中台和数据发现。
欧拉数据资产工场，定位是在湖、仓、流上构建标准化的数仓模型。
在数仓模型上是tMetric，也就是指标中台，基于headless BI理念在数仓之上定义指标，提供统一指标服务。
资产工场和指标中台，其实面向数据建模和生产，数据发现则是面向数据消费端，把标准化生产的数据的元信息通过各种方式集成到一起。
元数据分为技术元数据和业务元数据。技术元数据主要是数据的存储位置、存储结构、存储大小、存储格式等。在技术源数据之上会补充很多业务信息，比如此数据代表的业务过程、业务含义、口径、分类等，最终形成一个统一的数据知识索引库。上层是一个数据发现产品，大家在这里找数据、共享数据、申请数据、洞察数据。
欧拉在整个现代数据栈中的位置如下图：
这里欧拉治理引擎则是一个偏事后治理工具，即采集全链路元数据后，扫描问题、发现问题、修复问题。
二、数仓与指标建模
接下来是数仓和指标建模以及它们所面临的问题和应对方法，还有指标中台、资产工场、数据发现三个平台的设计。
1、典型数据问题案例
通常，数据集成入仓后会形成一个结构化的ODS层的表。在这个表上，数据工程师会进行维度扩展或逻辑建模，将一些维表与ODS表关联，如关联用户年龄、性别和渠道信息。这样，就会形成一个明细的DWD宽表，可能还会进行一些transform操作或格式转换。
在这个DWD表格的基础上，我们会进行轻度的汇总，形成DWS表，基于DWS表再构建应用层的ADS表，ADS表直接用来配置报表或者用作数据分析，典型问题case 如下图所示：
（1）三个 ADS 表指标口径不一致，理论上它们的曝光次数加起来是一样的，但是因为这个三个 ADS 层它的加工逻辑不一样，开发的负责人不一样，可能会导致口径未对齐，这是最典型的问题。
（2）数据依赖错综复杂，维护、修改、口径排查困难，同层依赖、跨层依赖，甚至下层依赖上层都有可能。
（3）过度重复冗余，DWD表、ODS表占用存储大，数据冗余度高。
（4）使用难，对于曝光次数这个指标，在不同的地方都会有不同的取值，这会让人困惑应当以哪个出口的数据为准。很多业务中表的命名可能是英文的，没有明确的中文描述、分类或分域定义，我们也不知道它们代表的业务过程是什么，要临时取数用哪个表合适。
2、关键思路
本质是数据的确定性差，下面讲述如何一步步解决这些问题。
第一个关键思路是具备标准化企业数据模型构建和管理的能力。数据建模可以分为三个层面：物理建模、逻辑模型和概念模型。物理建模层主要涉及到具体执行引擎上定义数据的具体实现，比如编写一段SQL或Python代码，通过Spark 、Hive来统计表格等。
逻辑模型层则定义数据之间的逻辑流向和组织关系，通常会使用ER模型、星型模型或其他可视化方法来表示这些关系，并不需要关注底层技术。例如无论底层是Hive、Spark还是Clickhouse等等，在逻辑模型中应当使用一种统一的数据逻辑描述语言。最上层是概念模型，定义数据的范畴、业务过程等。通常会使用分层分域或流程图等方式表示。
至于物理模型，这方面已经很成熟了。
总结一下，我们在数据建模的过程中往往缺乏的是概念模型和逻辑模型的构建和管理能力，这会对数据的确定性造成很大影响，导致可理解性降低，重复冗余严重，同名不同义、同义不同名等一些列问题，数据空间感极差。就像在图书馆找一本没有目录和描述的图书。
如果没有良好的数据架构支持，数据管理也会变得十分困难。所以，需要加强对概念模型和逻辑模型的建立和管理。
第二个关键思路就是基于DataOps 理念的物理建模。我们原来的开发模式是：数据集成到hive数仓或数据湖里，并撰写一些SQL、Python代码，配置调度作业。
有些情况下，我们可能会在本地的编辑器里编写好代码，将它复制粘贴到调度系统或者作业配置系统，再提交到Git。然而，这种开发流程与软件开发的devops有很大的差距，从逻辑上讲，数据工程也可以被软件工程化，甚至可以说是必然趋势。这可以解决数据工程中的研发、版本、测试、集成、部署、以及质量等问题，因此我们也需要一个数据资产的CMDB。
3、如何实现数仓建模CRCD
这部分会说明如何实现数据开发流程的软件工程化。
在进行前后端开发时，我们要遵循软件工程的理念，常听到的一个词就是面向对象编程。这种编程方式先声明一个对象，这个对象可能有很多属性方法，其它对象也可以继承这个对象。
在数据开发中，我们往往是面向表格的开发和交付，表格包含：基础信息、生产代码、scheme定义、调度配置，这些都可以代码化。打通发布流水线，就可以实现数据开发的DevOps，也可以在整个工程实践中增加很多事前、事中、事后的检测约束，保障数据开发规范落地。
4、数据工程的编码抽象
除了CR、CI、CD的流程，数据工程代码也需要一定的抽象能力。如果我们只用纯 SQL 来开发表格，就会产生许多问题，SQL代码难以实现可测试性、可读性。当 SQL 代码过于庞大时，可读性会降低，难以进行单元测试或单步调试，也无法实现流程控制，代码复用性也比较低。在软件工程中有一条原则叫做“don’t repeat yourself”，意思是要尽量避免重复。
Python 和 SQL 结合是一种不完美、但能实现一些流程控制的放式，抽象公共脚本，实现类似宏的功能，也能引用一些模块化的公共脚本（如下图demo）。
5、规范化的概念模型
我们可以将dataops视为一种软件工程化的物理建模。在开始物理建模之前，我们需要先进行概念建模和逻辑建模。
概念建模，也是定义数据的业务模型。定义业务过程与业务主题域，可以采用树形结构的方式进行定义。此外，业务过程域下还会定义一些词根以及业务域主题的描述等。创建数据库表时，必须要将其挂载在具体的业务域和主题域下。表名可以根据前后缀和关键点以及业务所在的业务过程来自动生成。如果没有完整的概念模型，就无法形成这种统一的数据资产目录，除非采用人工的方式事后进行整理。
6、规范化的逻辑模型
逻辑建模，通常定义一个星型模型或雪花模型，或可视化定义一个pipeline（这是一个数据加工逻辑的可视化方式，易于理解）。
因此，概念模型实际上形成了一个虚拟的逻辑表。这个逻辑表与底层引擎无关，可以提交到Hive或spark等平台运行物化。整体产品效果如下图：
7、指标治理面临的主要问题
前面讲了数仓建模，那么指标存在哪些问题呢？答案是“不知道口径”或“口径不一致”，原因是重复（同意不同名、同名不同义也是一种重复）。那么为什么会出现重复？同样的指标在不同的平台被多次重复定义，导致难以保证口径的一致性，从而经常出现同名不同义或同义不同名的问题。
我们的方案是以Headless BI为导向，建立一个指标中台。我们希望统一构建一个指标库并向下游提供SDK、API或类似SQL的方式来查询这些指标。我们能确保这个指标库中的指标不会重复。例如，如果出现多个DAU，它们的名称也不同，它们的口径也不同，我们可以轻松区分它们。
然后下游系统便可以统一对接指标查询服务，无需重复定义和计算该指标。而这个核心思想的关键在于"headless"，这个概念其实早在中台概念提出之前就已存在。
"headless"其实就是前后端分离，由后端以API方式为上层的可视化展现层提供服务。可视化展现层可以是多个，应用层业务也可以有多个场景。提供统一API服务，同一个指标或服务的API保障一致性。
8、指标中台与敏捷分析
基于这一理念，可能会有一个问题，指标中台和敏捷分析有什么关系？因为指标是用于分析的。这是否会导致降低分析的敏捷性？
实际上，我们应该从提升数据分析效率的角度来考虑问题。影响数据分析效率的因素有多种，例如找数据的效率、计算效率、确认数据是否正确的效率等。
如果数据不准确，整体的数据分析效率也不会提高。指标和维度的广义定义是无限的，数据分析同学可能会随时提出不同的指标定义或维度想法。敏捷分析通过提倡快速定义指标维度并即时分析。指标中台的定位是规范地定义指标并提供统一指标服务，在某种程度上会与敏捷矛盾。
如果规范能保证每次查找指标时都快速定位，且结果正确，那么我认为它的分析效率也会大幅提升。因此，欧拉指标中台也在提供规范化、标准化的统一指标服务前提下，尽可能地提高指标定义的敏捷性。
9、tMetric的领域模型
接下来我们要讲的是指标中台的领域模型。
第一步：在多种数据源上创建数仓模型（基于星型模型的逻辑表或者物理表）。
第二步：在数仓模型之上 定义原子指标、派生指标以及指标的维度
第三步：会有2个场景，①基于指标定义，创建物化视图或者预计算的cube；②是基于指标定义自助生产数仓ADS表。
第四步：对外提供统一的指标查询API或者SDK，也可以直接在实验平台、Adhoc分析等引用指标口径。
10、如何标准化的定义指标
那么指标的定义呢如何标准化指定呢？例如：以最近七天的体育类视频播放时长为指标，度量是视频总播放时长，维度是性别、年龄等，业务限定体育类。统计周期为最近七天。最终确定了指标定义之后，自动生成计算SQL。这是一个基本的语义模型。
11、tMetric的的体系架构
接下来讲一下整体框架。
应用生态：对接决策智能平台、报表平台、实验平台和目标管理平台等。所有这些平台都可以接入指标库，使用指标 API 或类 SQL API 获取指标数据。在这些平台看到同一个指标时，口径一定是相同的。
- 查询层：包括缓存、查询协议、转换和路由策略等。
- 语义层：指标、维度的标准化定义和元信息维护。
- 数仓模型层：数仓逻辑表、物理表定义以及统一数仓模型元数据服务。
- 物化加速层：我们提供了一个统一的物化服务，并针对不同的指标查询场景实施不同的物化策略。这些策略包括 OLAP 的物化策略和预计算的物化策略。
12、tMetric的物化加速方案
根据不同的场景选择不同的物化加速方式：
场景一：如果这个指标常被观测，其维度组合也已知，且维度基数不高，那么我们会选择预计算方式，定义好指标和需要使用的日常维度组合，预计算是一个cube。这种方式优势是查询速度快、存储、计算成本都比较低，缺点是多维分析的灵活性较低。
场景二：指标可能具有多个维度，而未来可能需要使用的维度不确定，这时可以使用StarRocks或Clickhouse等OLAP引擎支持任意维度的OLAP查询。通常会根据一些使用频率较高的维度创建物化视图。
场景三：在配置指标时，需要快速预览其定义以确保指标定义正确性。为了实现快速预览，使用MPP内存计算引擎，如Presto、Impala。不过，这并不是一个频繁的操作，通常只在定义指标时进行预览查询。
13、效果展示
三、数据发现
前面讲了指标生产和数仓建模，接下来就需要让用户方便地找到和使用这些数据资产——有哪些指标API可以使用？指标库包含哪些指标？数仓表中包含哪些重要表？这些问题需要通过清晰的呈现来得到解答。
首先我们需要统一的元数据底座-Uni-Meta。它可以从各种不同的数据系统中获取元数据，形成一个数据资产目录，或者说一个全域的数据知识图谱和资产现状概览。
四、未来展望
现在大家都在谈论ChatGPT，也有很多人在讨论AI for BI在企业中应用的一些可能性。例如数据分析师在进行指标分析时面临的痛点，不仅仅是知道指标数值，关键痛点是连贯的顺畅的渐进式的分析。如果AI可以解决这个痛点，那将会是质的飞跃。
但如果数据未经治理，没有统一的数据标准和数据框架，那么即使把所有的元数据信息都采集，AI的回答也会似是而非。
举一个例子，假设用户问昨天新闻各媒体渠道曝光的量如何，假设有一张表，我们明确知道表的用途、字段及含义，那么就可以构造prompt来写一段SQL统计各媒体渠道曝光量。
这个问题的难度在于如何构造Prompt，如果 Prompt 基于一个或是几个标准化的模板来构造出来，让 AI 填空，写出来的SQL就能直接运行。如果没有标准化的模板，写出来的SQL 大概率错误，只能作为一种辅助。
因此，如果我们数据治理能力足够强，AI辅助下连贯的顺畅的渐进式的分析是很可能实现的。
五、Q&A
Q1：腾讯如何统一指标的？
A1：这个问题可以从三个层面来回答。一个层面是如何统一指标的口径，比如战略层面的一些指标如“DAU 怎么算”、“各个业务大家是不是一致认可的”等。在这方面，我们有一个数据治理的工作组，工作组和业务的数据分析人员会有一个类似数据决策委员会的组织，在战略层的一些关键的指标口径达成共识。
另一方面是技术保证口径一致。其实就是我前面讲的，我们基于headless BI 的理念，建设一个统一的指标中台tMetric，把一些常用的指标都定义在这个指标库里面，下游的各个地方引用时都统一从这个指标库里获取指标。
第三个层面，就是日常的临时洞察分析。广义上的指标其实是无法穷举的。数据分析人员可能会忽然想到临时指标来统计分析，此时用户的痛点在于怎么算这个指标。这种场景往往是基于日常例行观测指标的衍生指标，也就是说如果知道日常例行观测指标怎么算，大部分情况也能推理出自己新构造的指标怎么算。
Q2：环境分为开发环境、测试环境还有生产环境吗？
A2：我们现在只有测试环境跟生产环境，没有预发的过程。但未来我们也会有预发，在一些很严苛的场景，数据测试完后可以发布到预发环境可试跑几天，确认没有问题再整个上线。
Q3：指标库的规模大概是多大？
A3：坦白说现在指标的数量只有 6000 多个，但是维度的数量比较多，一个指标可能有特别多的维度，我认为能从各个维度去看这个指标才是最大的挑战。
Q4：系统地讲一下在数据治理中用到了哪些 AI 技术？
A4：我觉得是两个方面。
一个是通过 AI 手段来提升数据治理的自动化的水平。通过 AI直接自动化治理是比较难的，毕竟数据治理有很强的业务性，需要理解业务模式和数据专家经验。但 AI 的一些技术可以加强数据治理工具能力，比如有些表可能没有描述，之前要人工梳理和补充表描，但现在 AI 可以根据表的一些数据的样本自动补充描述，自动给数据分类。
第二个是 AI 对数据治理的促进作用，也就是用 AI 做增强分析。但如前文所言，这需要极高的数据治理的水平，需要数据治理的平台化和生产即治理的模式，事后治理不能满足 AI for BI的需求的。
Q5：枚举值的最初来源是埋点信息吗？
A5：枚举值的来源有三部分。第一部分是埋点信息，比如说一个APP的启动方式的枚举值可能在埋点系统定义。第二个部分是直接提取一些表的字段的枚举值。第三个就是人工补充。需要注意的是，枚举值的定义一定是可枚举的。不是所有维度都要枚举，比如维度是用户ID，就不可枚举。
Q6：概念模型和逻辑模型在没有平台化管理的情况下，应该怎么迭代管理？
A6：目前没有很好的方案。如果没有平台管理，而是通过 wiki 、文档等去梳理，你那么维护成本极高。
Q7：腾讯如何量化评估指标资产的价值？
A7：这个是大家都很关心的问题，其实也就是数据治理。
那么我们如何让老板知道投了这么多资源的最终效果呢？其实数据治理本质上就是 4 个方面：成本、质量、安全风险和效率。单点治理时，切入点可以选成本，好度量。质量也有一些评估的方法，比如数据的及时性、数据问题反馈率和数据异常率等。
数据安全和效率的效果量化困难比较困难，可以先组织大家形成共识，确定必须要做的事，在这个前提下再定义量化指标来牵引结果。我们的组织是数据治理工作组，量化指标是我前面讲的资产分，通过量化评估把大家的治理水平拉到一个评价标准上，谁的资产分低，说明说谁的治理效果可能存在问题。
总结来讲，先通过组织共识目标（要做什么），再定义量化指标牵引目标达成，量化指标的定义也要注意，粗略的正确好过精确的错误。
Q8：如果构建了指标体系，传统的数仓会不会做的比较薄？
A8：数仓应该会下沉，比如说原来数仓有大量的ADS 表，现在就收敛到DWD或者少数DWS表，我认为可以通过指标中台的指标定义，自动化或半自动化地生产大量应用层的表。
Q9：最后一问题的话是说现在经济环境不好，那业务都要敏捷，那数据治理怎么敏捷跟上业务的发展？
A9：我认为现在整个行业更偏向像保守的方向，倡导降本增效。数据治理的目标就是降本增效，刚好符合现在的企业诉求，原来不重视数据治理，同一个指标可能会反复统计多次，计算跟存储成本会非常高。现在数据治理想办法帮业务降本增效。做好这点，就是对业务发展最好的帮助。
