导读本次分享人为蚂蚁集团的王高航老师，分享题目为蚂蚁指标系统的设计与实践，王高航老师自 2016 年加入蚂蚁集团以来，一直在数据中台领域深耕。在此期间，参与了蚂蚁新老两代数据平台的研发并主导了多个核心子产品。目前，王高航老师负责蚂蚁数据中台的数据架构与治理、数据建模、资产管理、安全合规等产品的研发。
本次分享将从以下几个方面进行阐述：
1. 指标系统的问题定义
2. 指标系统设计
3. 指标系统设计——机制流程设计
4. 指标系统设计——产品化
5. 业务实践与未来展望
6. 问答环节

01 指标系统的问题定义

1. 什么是指标系统

首先需要明确什么是指标。从统计学角度看，指标是综合体现总体数量特征的概念和数值。在数据仓库体系中，指标是其核心产物，它是信息层面的一种载体。从 DIKW 模型的角度分析，指标必须满足一些基本要求，包括准确性、完整性、及时性和一致性。

另一方面，系统是由若干相互作用、相互依赖的组成部分构成的，具有特定功能的有机整体。这里的核心概念是“有机”，因为指标并不是一个孤立的技术，而是与人有着非常紧密的互动，构成了一个有机的整体。

指标系统包括三个层次：

首先，概念层，它是公司核心概念的载体，如交易额和日活用户等，虽然高度抽象，但对于整个系统来说至关重要。
在确立了概念之后，为了确保其权威性和持续性，需要建立一套与之配套的流程机制，这是第二层。这一层的作用是确保概念能够得到有效地实施和推广，为公司的业务发展提供有力的支撑。
最后，第三层是产品化的载体，通常是一个内容型产品，如指标平台或指标中台。第三层虽然重要，但在实践中发现，许多平台过于强调这一层，而忽略了上面两层的重要性。实际上，对于指标中台或指标系统来说，最重要的是上面两层，尤其是第一层。如果没有前两层的基础，仅靠产品化载体是很难实现其持续发挥效果的。

2. 指标系统的常见问题

（1）在概念层面

我们面临的主要是二义性的问题。具体来说，是同名不同义、同义不同名、或者指标间值冲突的情况。为了解决这些问题，需要对各个领域的概念达成共识。

（2）在流程机制层面

需要关注的是如何确保指标的持续保鲜和有效迭代。尽管在短期内研发一批指标相对容易，但长期保持这些指标的活力和有效性却非常有挑战性。为了解决这一问题，我们需要从机制和流程的角度出发，建立相应的保障措施，以确保指标的持续优化和更新。

（3）在产品层面

主要解决的是效率问题。这包括指标定义、研发运维以及进一步下钻分析的效率。为了提升效率，我们需要对相关结构进行优化，并借助人工智能技术进行辅助，提高指标工具和平台的使用效果，降低不必要的成本和时间消耗。

综上，我们需要在概念、流程机制和产品三个层面上分别解决二义性、持续保鲜和效率问题。通过共识领域概念、设计流程机制、核心结构优化及人工智能辅助等手段，更好地应对这些挑战，提升指标系统的有效性和应用价值。

02 指标系统设计

1. 如何进行概念共识

接下来介绍如何构建指标系统。首先从第一层开始，即概念共识。概念共识是整个指标系统的基石，没有概念共识整个指标系统只是一个空中楼阁，只能在短期、局部发布有限的价值。下面我们展开介绍一下如何进行概念共识。

（1）共识的模式

一是通过 BI 驱动的方式。因为 BI 是连接业务和数据工程师的桥梁，能够在实际沟通交流中进行一些抽象和翻译，从而形成完整的指标体系。

另一种方式是由数据架构师驱动。因为他们作为数据工程师的代表，对整个领域有更深入的认识，能够进行全局的抽象和概念定义。

对于无法实现全成员共识的情况，就只能在角色内部共识，然后在交互的时候进行语言的翻译，翻译的工作可以由数据工程师或 BI 来完成。

（2）关于共识范围的问题

不能期待所有成员都能达成共识，特别是在一个比较大的组织内。因此，共识的范围需要根据具体情况进行划分。可以通过组织架构视角、业务领域视角或消费场景视角来实现。例如，按公司级、部门级或团队级进行划分，或者基于业务领域抽象进行范围划分。或者，也可以根据具体的消费场景来决定共识的范围。

在选择共识模式和范围时，没有绝对的标准，需要考虑各种因素。如全成员共识的优点是共识程度高，但难度也较大，对于核心角色的能力要求很高；角色内部共识的难度较低，但效果相对较差；按组织架构视角共识的难度较低，但稳定性较差；按业务领域共识的稳定性较好，但难度较高；按消费场景共识的灵活性高，但共识程度较低。

经过探索与实践，在蚂蚁内部，核心指标主要按照业务领域进行范围划分，并在领域内实现全成员的共识的方式。这样既可以保证共识程度，也能保证其稳定性。

2. 指标语义层的位置

指标是业务语义的核心载体，在架构层面语义层有三种不同的方式。

（1）第一种是将语义层与数据层融合。

即直接在数仓中定义语义层。这种方式的好处是前期实施成本较低，只需要将已有的表、视图等进行相应的调整即可。此外，由于数据通常由独立的数据团队集中管理，因此具有组织保障。然而，这种方式的缺点也很明显，主要表现在敏捷性不足。由于是集中式团队作业，只能由数据同学进行定义，可能会缺乏业务输入和全局视角，导致理解成本相对较高。此外，由于语义层与物理层过度耦合，访问性能和灵活性会受到一定限制。

（2）第二种方式是将数据独立于数据仓库层

把语义层单独抽出来成为独立的一个产品。这种方式的好处在于逻辑层与物理层的解耦，可以统一数据的访问模型，支持各种湖仓的场景，并通过自动优化提高性能。由于是独立出来的，因此业务理解和维护成本相对较低，BI 等人员也有共同参与构建的可能性。此外，集中式管理使得治理程度较好，可以减少一些二义性的问题。然而，这种方式的缺点在于前期成本较高，需要独立抽取这一层，同时复杂性也相对较高。

（3）第三种方式是集成在数据的消费工具中

这种方式的好处在于高度的灵活性和敏捷性。然而，由于各自分散，很难实现一致性，且跨平台工具难以复制和复用。因为这一层会有很多贴近消费的特殊优化，对于其他工具来说很难复用。

这三种方式没有绝对的好坏之分，应根据公司的具体情况而定。根据模式定义和倾向性，如果只是角色内部控制，可以选择第一种和第三种方式；如果是全成员共识，第二种方式可能更加适合；如果按组织架构共识，第一种方式较为合适；如果是业务领域共识，独立于一层的方式更好；如果是按消费场景共识，则应选择第三种方式。

3. 构建概念共识

为了构建这个概念共识，需要借助一些工具或方法论作为支撑。

从本质上讲，概念共识是统一语言的过程，而阿里之前提出的 OneData 方法论，是一个指标语言标准化的工具。这套工具对于从事指标工作的各位来说并不陌生。然而，随着时间的推移，我们发现仅依赖这一套工具并不足够。主要原因是，它在实践层面更多的是从微观的视角出发，缺乏宏观视角。

为了弥补这一不足，我们引入了领域驱动设计这一思想。领域驱动设计并非我们的创新，而是在工程领域被广泛采纳的一种思想。引入它的目的在于增强宏观视角，更具前瞻性以适应不断变化的业务需求。此外，随着数据业务化的趋势，我们需要实现更大范围、更深层次的语言共识。领域驱动设计的一些方法论在此过程中发挥了重要作用。

领域驱动设计的核心在于领域模型与统一语言。领域模型是对业务本质的抽象，基于业务本质进行建模。在实际操作中，需要关注两个结合点。

首先，在宏观层面上，基于业务本质对数据域进行划分，这有助于领域知识的交流与共享。如果划分仅按组织进行，那么领域知识也只能按组织划分，这无疑增加了交流的难度。

其次，我们需要进行更大范围的业务术语讨论。这意味着在线应用架构师与数据架构师之间需要有一定的交流，能够一起讨论类似的问题，确保彼此的语言是相通的。

03指标系统设计——机制流程设计

1. 机制流程的设计

机制流程的设计是为了确保指标的持续建设及保鲜。我们在实践过程中发现，指标系统的建设相对容易，但持续的维护和运转却非常困难。从因果图上看，良好的建设和维护能够促进消费者的使用；用的人多了，也就能促进建设和维护。但现实中这个增强回路很难运转起来，主要从建设角度看，往往是可建可不建的状态，有部分同学更倾向于维护在离线的 excel 中，一旦维护不足指标不保鲜，消费者就丧失信心转而线下问人；对于消费者，指标的使用场景有限，只是偶尔去看一下的话增量价值没有那么大，不一定会持续去推动生产者进行指标维护。

为了解决这个问题，有两个思路，一是通过产品化及 AI 能力，提升指标管理、指标研发的效率，让在线的指标维护管理效率高于线下表格；二是通过与消费平台的深度集成，提升找数、取数、分析的效率。当然在前期，我们还需要依靠一些管理机制来确保系统的冷启动。

2. 权责定义

在管理机制中，有几个关键角色需要详细阐述。

首先，业务负责人是负责提出需求和建立指标模型的人。他们通常是 BI 或数据架构师，具有深厚的业务背景和专业知识。业务负责人对指标原子或业务限定有最终解释权，需要在负责领域内制定无歧义的标准，确保指标建模的准确性和标准化。

接下来，技术负责人负责实现指标模型。他们需要选择实现方式，确保准确实现并及时产出。技术负责人需要与业务负责人保持密切沟通，确保对指标口径的理解保持一致，避免歧义。

最后，消费者是指标的最终使用者。他们享有知情权，对指标口径的变更需及时了解。消费者有责任准确理解指标口径，合理使用数据，避免滥用。

在管理机制中，各角色需明确职责，相互协作，确保指标建模、实现和消费的顺利进行。

3. 变更流程

基于权责划分，我们设计了一套变更的流程。在流程中，业务负责人拥有最终解释权，并承担着明确实现口径的责任，具备审批权。消费者则拥有被通知的权利，业务负责人和技术负责人应确保消费者及时获悉相关信息。

04 指标系统设计——产品化

1. 产品化载体

产品化的载体就是指标平台，其目标是解决效率问题。平台服务于数据管理者、指标建模者、指标研发者和消费者。

数据管理者的主要诉求是确保指标数据的准确性，避免出现任何歧义，同时关注数据质量和投入成本。指标建模者主要关注的是建模效率和建模门槛。指标研发者关心研发效率。而消费者，则更关心数据质量和消费效率。

基于这些核心诉求，指标平台需要具备四个核心能力：

首先是标准化的指标口径定义和管理能力，确保数据的准确性和一致性。
其次是高效的指标研发能力，快速响应业务需求。
第三是通过便捷的消费能力，使数据更易于获取和使用。
最后是便捷的指标下钻分析能力，帮助用户快速定位问题并进行优化。

2. 指标平台常见结构

在业界，指标平台已经得到了广泛的应用。阿里集团和蚂蚁集团内部也有多个指标平台，有些是作为业务管理平台中的指标模块，而有些则是独立的指标平台。

从结构上看，指标平台通常包括统一词库管理、原子指标管理以及业务限定管理。基于这些基础，通过派生指标，可以形成一个庞大的指标库。在这个库中，可以进行简单的指标运维、衍生以及提供看数、取数或指标 API 等服务。最终，物理指标会在研发平台中完成，并异步挂载到 ADM 或 DWS 表中。

然而，从我们对指标平台能力的要求上看，现有的指标平台也存在一些问题。

首先是标准化指标口径定义和管理的能力。这个结构只标准化了逻辑口径，没有标准化物理口径，它的物理口径通常隐藏在复杂的 SQL 中。因此，它只能解决单指标的二义性，无法解决多指标间的二义性，只能通过组织流程保障和统一中间层资产建设来缓解。

第二是指标下钻分析能力。因为基于 ADM 或 DWS 有很多复杂 SQL，要做到下钻明细是比较困难的，无法做到自动的下钻分析，只能人为地查看 SQL 去理解口径。

第三是需要具备高效的研发能力。基于基础指标进行简单衍生可以快捷生产，解决一部分效率问题。

第三个问题是通用便捷的消费能力。这个结构在，挂载的指标只能以一个指标 code 这样一维的形式存在，但数据领域大部分消费还是以“表”这样的二维形式，因此，这个结构下的指标要消费只能是指标取数 api 的形式，或者需要与下游数据服务进行深度打通，不够通用。

综上所述，现有的指标平台结构虽然解决了很多问题，但仍不能完全满足能力的要求。

3. 蚂蚁指标平台结构

蚂蚁指标平台在近期进行了一次升级，主要涉及以下几个关键方面。

首先，在原子词库的框架下，我们为每个词设定了具体的物理口径。这种物理口径是基于数据模型进行确定的，以确保其二义性得到保障。

基于这些绑定的物理口径，构建了一个统一词库。这个统一词库依托标准化模板，可以自动计算指标并产出，省去了手动计算这一步骤。此外，我们还为这些指标赋予了一个载体，使其能够自动汇总到一张汇总逻辑表中。

这一结构具有几个优势。首先，它解决了口径不一致的问题。由于每个词库都绑定了物理口径，实现了逻辑口径与物理口径的标准化，因此可以更彻底地解决二义性问题。

第二点是它增强了研发效率及指标下钻分析的能力。指标实现了定义即研发，不需要在研发模块手动写任务再上挂到指标中，极大地提效。另外因为最终的指标是基于绑定口径的词库计算而来的，它有一个强血缘，因此很容易基于指标就回溯到相应的明细表，展开详细口径，进行进一步的分析。

最后针对自动研发的指标，我们将同粒度的指标自动汇总到一张“逻辑表”中，这样下游用户可以基于该表的模型进行数据消费，实现更通用的消费。

4. 辅助指标建模

为了解决指标建模中的难点，我们引入了指标辅助建模。在实践中，我们发现从指标抽取出四要素（如原子指标、业务限定）可能会遇到一些困难。困难主要在于缺乏统一的标准。例如，当需要查看昨日支付宝在国内线下成交金额数时，指标建模者或BI、架构师需要拆分原子指标、业务限定和统计周期。虽然统计周期相对容易处理，但原子指标和业务限定有多种拆分方式。因为没有明确的对错之分，这可能导致混乱。

为了解决这一问题，我们引入了一些指标的智能建模推荐。基本逻辑原理包括两条路线：一是基于基本指标进行分词，分词词库基于业务词条和指标词库。分词后，进行分类和同义词修正。例如，确定是“成交金额”还是“交易金额”，并确保每个指标的唯一性。另一条路线是利用大模型对业务词条和已有词库进行构建，并基于大模型直接给出推荐结果。通过这些方法，可以提高指标建模的准确性和效率。

5. 研发提效

关于指标 SQL 的研发提效问题，其基本原理是基于模板，每个模板对应一个基本元素，通过逻辑生成来解决问题。基础能力比较简单，关键在于如何提高场景的覆盖率。

起初，我们通过简单的单表模板或配置来解决问题，只能覆盖约 30% 的情况。接下来，我们引入维度或雪花模型的指标配置，将所有维度扩展成一张虚拟大宽表，进行指标配置，解决了约 60% 的问题。

为了解决 80% 的问题，我们进一步丰富关联关系和模型能力。例如，引入桥接表、层级维度以及复杂的关联关系。更进一步，解决 90% 的问题则需要处理二次汇总和自关联能力，比如一些二次汇总或者自关联的标签类指标。

对于更复杂的情况，我们仍在探索可能的解决方案。然而，任何解决方案都存在极限，无法达到 100% 的覆盖率。在未来，我们需要更加关注产品交互能力，或者使用更适合的 DAX 语言来处理复杂的分析指标。

6. 通用消费能力

最后，关于通用消费能力，可以通过汇总逻辑表将所有指标按维度汇总成一张虚拟宽表。用户可见的维度和指标可以作为表的字段进行展开。对于物理层，进行一些内部自动物化处理以提高效率。

利用逻辑表的查询翻译引擎，将用户所有的 SQL 转化为逻辑表，并进一步将逻辑表转换为物理表的 SQL。这个引擎是整个系统中的核心组件。

在此基础上，建立接入层。在这一层，我们实现了多种协议，包括 HTTP、RPC 以及 JDBC 等，以满足不同用户的需求。此外我们还对蚂蚁内部的 Max Computer 引擎进行查询协议的代理，用户只需切换一个 endpoint，就可以方便地查询逻辑表。

为了提高查询效率，我们还引入了逻辑表加速技术，以满足一些需要快速响应的指标服务的需求。

7. 专家经验平民化

基于业务模型的特性，通过专家经验的积累，可以有效提升数仓的执行效率。为了实现这一目标，主要采取了以下几个策略：

（1）同源表同粒度的合并计算，以减少重复计算。

（2）长短周期的渐进计算优化，避免不必要的重复计算。

（3）粒度上卷的优化，基于新粒度的上卷，提高计算效率。

（4）自动构建 BitMap 优化，进一步简化计算过程。

（5）在纯 SQL 层面，通过 count distinct 转 group by、full outer join 转 union all、自动 map join 等优化。

这些策略对于专家来说是常见的优化手段，但对于刚上手的同学来说可能并不容易掌握。因此，我们通过内置优化方法，有效提升数仓的平均执行效率，为业务提供更好的支持。

8. 基于 ROI 的智能物化

在逻辑表物化层面，我们根据下游的消费频率和时间要求，对指标所在的汇总表进行智能的物化拆分和冗余处理。拆分和冗余的决策主要基于 3 个因素：

一是消费者对每个指标的时效要求，如果所有的表都被整合在一张物化表中，它受限于产出时间最慢的指标，使整体产出时效很长，所以在物化的时候需要根据时效进行分组，例如要求在九点产出数据，那么七点和七点二十的数据可以合并到同一张物化表中。同样地，根据十点的要求，九点和九点二十的数据也可以合并在一起。

二是在逻辑表内基于消费的频率进行计算与存储的取舍，如果下游经常需要将某些字段频繁地连接在一起，我们会在物化表内部进行冗余处理。

三是跨表的冗余。在实际使用时，许多维度属性会被一起使用。为了提高性能，我们会针对一些维度属性进行冗余处理。例如，用户的一些信息，如姓名和性别会被冗余存储在另一张物化表中，由系统来保障一致性。

05业务实践及未来展望

1. 业务实践情况

在蚂蚁集团，当前已有近三万个派生指标，其中 70% 是自动化研发的。基于 codeless 定义和自动物化的策略，数据二义性问题明显有所改进，尤其是基于自动化的效率实现了数量级的提升。在指标计算性能方面，由于各种物化的自动化策略的应用，研发提效 10 倍以上，指标计算成本下降 20%。

在网商银行这一典型场景中，主要面临的问题是口径的统一，因为各子模块间存在口径性的冲突，导致子业务报表合在一起时数据无法对齐。此外，敏捷性和灵活性也是指标交付中需要关注的问题。一旦指标交付出现异常波动或问题，进行二次分析的难度较大。

在指标系统的实践中，我们采取了统一的数据模型为基础，构建了指标模型。在此基础上，建立了统一的指标库，并与业务制度分析平台进行了深度结合，这种结合使得我们能够进行线上分析。目前已构建了数千个派生指标，其中自动化率高达 90% 以上，保证了口径的一致性，并提升了效率。

在蚂蚁安全领域，主要面临的问题包括口径问题、重复研发导致的计算和存储浪费、成本增速超过预算以及依赖混乱的计算成本压力。为了解决这些问题，数据工程师聚焦于数据建模和指标建模，而业务同学则负责派生指标的构建。通过这种方式，我们实现了上万个派生指标，自动化率达到了 85%，交付周期从两天缩短到一小时，计算成本平均下降了百分之三十左右。同时，指标安全性问题也得到了较好的解决。

2. 未来展望

未来将更加关注大模型的运用。大模型为语义层带来了一个宝贵的机会。

一方面大模型能够辅助建模，降低语义层构建的成本。但短期内，大模型不会完全替代，因为业务的抽象以及一些子领域基础数据仍比较稀缺。

另一方面语义层是大模型不可替代的领域知识中心，通过将语义层与大模型结合，将极大提升消费效率，包括自然语言找数、自然语言取数和自然语言分析等。

最后，蚂蚁集团数据治理平台正在招聘 Java 研发工程师，如有兴趣，可以通过以下邮箱联系我：gaohangwang@gmail.com

06 问答环节

Q1：物理口径是如何做到绑定的？

A1：在物理口径的绑定方面，我们需要在定义原子指标时，直接为其指定相应的口径。具体的绑定过程可以分为两个主要步骤。首先，选择主表，并为其添加相应的原子指标计算口径。其次，业务限定通常与维表相关，这可能涉及到主表或其关联的表。在绑定过程中，我们通常不需要对时间周期进行绑定，只需要在主表指定时间字段和格式就可以了。

Q2：指标是单独存储的吗？如果是单独存储的，是不是按照列式存储比较好？如果维度不太固定或者多变的情况，有什么好的方案吗？

A2：首先，指标存储分为两个层级。第一层是最基础的层级，通常不会进行单独的存储。在物化视图方面，如果原始数据是采用列式存储，那么物化后依然会保持列式存储。

对于加速后的指标服务存储，存在多种选择。一种方式是我们可以内置一些加速存储的功能。另一种方式则是做加速，并存储到目标消费平台中。不过，数据并不会单独存储在目标消费平台中。

此外，对于维度不太固定或者可能会变化的情况，我们需要考虑一些好的解决方案。目前汇总逻辑表是按照同维度进行聚合的。当维度发生变化时，比如增加或减少维度，这通常不是建表的问题。

如果引入新的维度，我们需要考虑如何迭代表结构。对于新表，我们会创建另一张汇总逻辑表，而不是在同一张表上进行操作。因为不同维度很难聚合在一起。如果硬要聚合，可能会导致数据表变得庞大而难以管理。

为了避免这种情况，我们可以考虑使用分区表来管理不同维度的数据。通过合理设置分区键和分区策略，可以有效地将不同维度的数据分散到不同的分区中，从而实现高效的数据存储和管理。同时，我们还可以利用数据库的分区功能进行查询优化，提高查询效率。

Q3：指标平台应该是从明细事实表开始计算，还是从业务部门的中间表去计算？

A3：关于指标的定义，我认为应该基于语义，即数据模型这一层面。中间表和明细表是不同的概念，对于明细表，也需要具体分析。有些明细表在规范上相对收敛，而有些则较为发散。为了确保一致性，我们应从概念模型开始，这一层面具有一定的抽象性。通过这种方式，明细内层不会过于分散，明细与概念能够更好地结合，从而更易于达到一致性。

Q4：指标的查询对于 BI 看板来说，性能要求会比较高，性能应该从哪几方面保障呢？

A4：关于性能这一方面，我们在蚂蚁金服并没有进行过多的研究和涉猎。主要原因在于，我们将这一领域的工作主要交给了底层引擎来处理，例如逻辑表加速等，这些都是由引擎来负责的。在我们的工作中，我们更专注于构建语义层这一块，而不是过分关注技术层面的优化。

对于性能优化，我们采取了两种策略。首先是把相关工作交给引擎处理，这样可以利用它们的专业性能优化技术。其次，对于逻辑表的加速，我们并不需要处理所有的数据存储问题，而是选择性地加速到业务的数据分析平台，例如 Power BI 等。这些平台拥有专业的性能解决方案，能够提供更加完备的性能优化服务。

Q5：派生指标是包含维度和原始指标吗？是由业务同学来编写吗？

A5：对于派生指标的定义，存在不同的观点和理解。

在实践操作中，我们的派生指标包含统计粒度和维度两个方面。

至于派生指标的确定，我认为业务团队的参与是非常关键的。但是，这种参与是有前提条件的。首先，业务团队需要对建立的模型和相关概念有统一的认识。如果业务团队和数据团队使用不同的语言，那么派生指标的确定将非常困难。此外，对于数据建模抽象能力的要求也比较高。数据工程师需要扮演数据架构师或数据建模师的角色，构建出能够适应各种业务需求的优质模型。这样的一种模式是比较理想的选择，能够确保派生指标的有效性和实用性。

Q6：有出现下钻的时候，就是出现算子不相同的问题吗？比如说一开始下钻的某一层级需要去重。

A6：具体来说，我们需要将这一层向下转换，以揭示其核心口径，也就是还原到明细模型这一层级。一旦还原到明细模型层，系统会默认展示原子指标的算式。然而，要进行更高级的分析，你可能需要使用其他算式或添加额外条件。这就需要与我们的分析平台相结合，轻松地替换这些算式、限定、周期或维度。

这样的调整不仅扩大了探讨的空间，还突出了基于明细模型的灵活性。另外，我想补充一点，我们的指标通常基于数据模型来定义聚合算子，这可能涉及多层聚合。这时，我们可以借助 BI 工具，进行二次或三次上卷分析。我理解一些特别复杂的分析可能会更需要借助这些工具和语言来处理。

Q7：所有的指标都是持久化之后的吗？有没有一些指标是动态的？比如我们实时查询三月份到现在的成交额。

A7：根据您提供的原始内容，以下是经过改写的严谨、稳重、理性、官方风格的语言：

在数据仓库中，指标通常都是持久化的。对于一些衍生指标，例如 a 加 b 或 a 除以 b，我们不会一概而论地进行物化，而会根据实际需求和情况来决定是否将其物化。

Q8：指标的计算口径都是通过图形化界面配置的吗？还是可以基于 SQL 语句配置？

A8：关键是看结构，以原子指标与基本算子级别的口径绑定为例，涉及到图形与 SQL 的结合的，有些是选择定义 SQL。在定义好这些基础要素后，系统将生成相应的指标，这个过程可以通过图形化界面进行展示。

Q9：词根的二义性怎么解决？

A9：关于词根的二义性问题，其实我们之前已经有所涉及。要实现业务词条的统一语言，主要有三种模式选择：基于领域、基于组织或基于消费场景。在确定模式后，后续工作就会变得相对简单。

如果是基于领域，就需要领域专家共同合作，采用领域驱动的方法，根据业务用例进行抽象，达成词根的统一。基于组织的模式可能相对简单一些，而基于消费场景的方式可能无法解决根本的安全性问题，因此建议采用基于领域的方式。

另外，关于机制流程的变动，需要非常谨慎地进行。关于领域设计的展开，需要强调的是，这些词并不是一次性录入系统就结束了。要让领域词在各种日常交流、文档和需求提案中得到广泛应用，以规范使用标准的词汇。只有不断加深对词根的印象，才能真正达成共识，解决二义性问题。

Q10：指标主要是离线计算吗？是存算分离的吗？

A10：我们在此进行计算时，主要集中在最基础的一层，采用离线计算方式，因为离线计算在效率上更具优势。在线计算则主要用于加速和执行一些简单的衍生操作，如组合或聚合。至于存算分离，我认为它更多地取决于底层技术架构中引擎的存算分离特性。如果底层引擎支持存算分离，我们也会采用这种架构。

Q11：派生出来的指标一般是单个类型的指标落表。但是 BI 看板经常会需要拿各种类型的派生指标，这个怎么处理？

A11：对于处理多个派生指标的问题，确实需要谨慎处理。

首先，考虑到我们现有的指标已经聚合在汇总逻辑表中，如果在 BI 工具中引入这个表，可能会出现数据量过大的情况。特别是当我们面对的是拥有数千个指标的大型逻辑表时，按需引入是必要的。

其次，为了提高效率和准确性，我们也可以考虑与下游的平台进行整合。这样，下游平台可以直接引用指标列表。之后，我们可以自动将相关的数据集或底层逻辑表、物理表传输到下游平台，从而帮助它们构建自己的数据模型。这种方式可以实现更为流畅和高效的数据传输和处理。

总结来说，处理多个派生指标的问题需要我们综合考虑数据量、效率和准确性等多个方面。通过按需引入数据、与下游平台深度整合等策略，我们可以更好地满足业务需求并提升数据处理的整体效果。

本文来自公众号：DataFunSummit

原文阅读