各位嘉宾、朋友们，下午好。今天上午，我们公司的 CEO 已经在主会场的第一场分享了关于我们公司的情况。可能大家对 Aloudata 还不太熟悉，我们是一家成立不久的初创公司。之前我们的团队成员在阿里蚂蚁工作了一二十年，深知数据领域尤其是供给侧在服务业务时存在许多痛点。因此，我们希望通过一些新技术来帮助大家解决日常工作中的问题。

我今天的分享主要分为三部分。第一部分，我们将探讨在当前业务对接过程中存在的问题，以及是否有新的方法可以帮助我们解决这些问题。第二部分，我将介绍我们创业后开发的产品化解决方案——第三代指标平台。我会说明这个产品具备哪些能力，以及它能为企业带来哪些价值。第三部分，我将分享这个产品在不同行业客户中的一些真实落地案例。

一、ETL 的原罪与 NoETL 全新思路

首先，我们知道，近年来每个企业和行业都在进行数字化转型。在这个过程中，数据人员收到的业务部门数据需求越来越多，对数据的时效性要求也越来越高。我们发现，传统的数据从业人员通常通过开发大量面向业务场景的宽表和汇总表来快速响应业务需求。这导致整个数据管道和数据链路变得越来越长。许多数据同学会抱怨，他们的数据加工链路有上百层，一旦出现问题，他们很难快速排查并定位问题。

需求的显著增长让数据管理的难度越来越大。我们认为，这背后的问题主要是因为传统 ETL 作业进行了大量的反范式宽表和汇总表的加工。这种加工方式使得在整个数据处理过程中，很难在效率、质量和成本之间达到平衡。例如，如果一个业务需求需要快速响应，我们可能就没有时间去进行充分的数据校验和优化。

此外，如果需要避免重复开发，需要不同业务线的 ETL 工程师彼此沟通，是不是我们数仓里面已经沉淀了这么一张表，是不是已经开发好了这个字段。这种协同沟通的成本会很高，时间可能会很长。所以，在这种情况下，为了保证效率，可能就会存在数据的大量重复开发，会存在口径的差异。可能不同的业务提的需求是同一个指标，但拿到的结果是不同的。

如果我要解决这个质量问题，避免重复开发，那前期就要投入大量的协同沟通成本，要把这个模型设计得很好。这个时候，业务可能又等不及，因为业务会觉得我只是提了一个简单的需求，为什么要等这么长时间。所以就导致我们现在陷入了这种成本、效率、质量的不可能三角。

那到底有没有可能破解这个不可能的三角呢？其实从整个 MECE 原则来拆分，我们刚刚讲到导致不可能三角的原罪是因为做了大量的反范式 ETL 开发宽表和汇总表的作业。那我们是不是可以不去加工宽表汇总表，这样就把这个问题的源头解决掉了？

大家也知道，今天企业的数据量越来越大，那今天我们的查询引擎技术还没有发展到足够支撑这么大的数据量的直查，所以看起来这条路是不可行的。

那我们换个思路，如果要通过人工保证它的质量，保证不要做重复开发，需要很大的协同沟通成本，那是不是能够把人工的工作变成由系统来做，因为系统会知道到底开发了哪些表，做了哪些指标的加工。这里我们先给出一个结论就是可以从原来的人工加工变成 NoETL 自动化，并基于该理念开发了一款自动化的指标平台——Aloudata CAN。

Aloudata CAN 如何实现 NoETL 自动化呢？其核心机制主要依托于两项关键技术能力。首先是语义化，其次是自动化。

每个企业都有其独特的行业特征和指标建模需求，这些都是各企业之间差异化的体现。如何让系统准确理解该如何处理数据和开发指标，这就需要第一项能力——强大的指标定义能力。这意味着系统必须能够识别出每一个指标应当采用的开发逻辑，在传统模式下，这些逻辑的开发通常由数据仓库的 ETL 工程师编写 SQL 来完成。现在，我们希望通过低门槛的配置方式实现语义定义，让业务人员可以通过业务语义的配置表达向系统明确各项指标的业务计算逻辑。一旦系统掌握了这些逻辑，我们便能够确保数据仓库和 ETL 工程师专注于数据资产的沉淀。

只要告诉系统指标的业务计算逻辑和业务含义是什么，它就可以让系统去执行。这是第一点——语义化。第二点，可能大家会有疑问，因为前面提到现在数据量很大，如果只是告诉了系统计算逻辑，它是一个虚拟化的逻辑化的，怎么能解决大数据量下的查询性能问题呢？是否对存储计算资源要求很高？

这就涉及到我们讲的第二个能力：自动化。当我们面对大数据时，并不是真正地“干掉”了宽表和汇总表，而是把这部分从人工工作变成了系统自动化去做。系统会根据定义的业务计算逻辑自动翻译成 SQL，自动地进行链路编排，生成面向业务场景的宽表和汇总表。

接下来再展开讲一下这两方面具体技术的实现逻辑。在语义化方面，Aloudata CAN 包含了六个核心能力。

第一个核心能力是让系统知道指标的计算逻辑是什么，这背后需要我们提供一个标准的指标定义能力。

我们在做指标定义时经常需要跨表定义指标。如果说数仓不做宽表的加工了，那我们怎么能够实现跨表的指标定义？我们的解法是构建一个语义模型，再在这样的一个语义模型基础之上，把指标拆解成一些最原子的要素，比如说原子指标、时间限定、业务限定、衍生方式等。有了这个拆解之后，实际上我们给到业务的体验是一些语义化、配置化的模板，不需要去写 SQL 了。

如果不需要去写 SQL，但系统查的是一个 SQL，怎么能够实现这种复杂的表达呢？这背后实际上是依赖于第二点核心能力——一个强大的指标函数体系。

这个函数体系也是我们自研的，里面包含了常规日期文本、聚合函数，也包含了复杂的窗口函数和分析函数。我们会把这样的一个函数抽象成一些模板化，对于用户来讲，他只要去点点选选就可以在界面上配置出来一个复杂的指标，比如说我们要去配置一个门店的销售金额，例如在华东地区的排名。原来需要在数仓写 SQL，写开窗函数去实现，但在 Aloudata CAN 里面，只需要通过配置化的方式，不会写 SQL 也能定义出来。

第三点核心能力是自动构建多层次、多聚合的任务 DAG（有向无环图）。例如，在构建指标的第一阶段，系统会先计算每个门店的销售量；第二阶段，根据销售量进行排名；第三阶段，得出排名结果。基于这种方式，无论指标多复杂，都可以通过多层次、多聚合的方式构建 DAG。

接着，系统会根据用户配置的多层次、多聚合要求，自动将这些配置转化为 SQL 语句，这是第四大能力。

此外，在 SQL 翻译过程中，也涉及性能优化问题。这就涉及第五点核心能力——查询 SQL 优化。一是基于指标计算本身的优化，如关联下推、多层 AGG 合并和裁剪；二是基于规则优化器（RBO）进行的优化，如 Limit 下推、子查询裁剪和列裁剪等。

第六点核心能力是自建内存计算引擎提升查询效率。这个计算引擎是专门针对指标场景开发的，包括指标分析器、RBO 和 CBO 的拆分、DAG 构建、任务管理、算子级别执行器、缓存等。

基于这六大能力支持的语义化能力，我们通过定义少量的原子指标，就可以轻松实现大量派生指标的应用场景。在很多企业中，实际需要的原子指标数量并不多，一条业务线可能只需要大约一百个原子指标。过去，企业可能会基于这些原子指标定义上千个派生指标，导致了巨大的指标管理变更成本。Aloudata CAN 的方案则可以降低这一成本，提升企业数据分析的效率与效果。

首先，我们希望通过定义少量的原子指标来覆盖更多派生指标的场景。其次，从指标管理的角度来看，我们知道企业中存在指标口径不一致的问题。虽然企业可能通过一些指标管理工具或指标口径登记工具来进行管理，但这并不能完全解决问题。我们发现，要真正解决这一问题的核心在于，需要将指标的定义逻辑从数据仓库转移到指标平台，这样才能实现自动化的同名同义校验，确保指标计算逻辑沉淀在指标平台上，从而实现口径的统一管理和一致性。

此外，我们还支持一些复杂的原子指标和派生指标的定义，这些都是通过模板化的配置来实现的。以上可以表明，Aloduata CAN 具备了将指标计算逻辑告知系统的语义能力，系统知道如何计算这些指标。

在处理大数据量时，我们可能会遇到性能问题，因此需要第二个能力——自动化能力。这种自动化能力实际上是通过系统的方式来平衡性能成本和时效性。

在自动化方面，Aloudata CAN 是通过系统的方式来平衡性能成本和时效性。其核心步骤有四个。

首先是基于前面讲述的指标语义，Aloudata CAN 能够自动构建进行物化视图，将查询请求转变成 DAG 的构建，然后再将其拆分成多层不同的物化视图，以此来保障整个查询的性能和灵活性。同时也支持人工指定构建物化视图，例如在管理驾驶舱中，领导可能需要根据特定指标和维度进行快速响应，因此可以手动选择这些指标和维度，系统将自动创建物化视图进行预计算，类似于以前在数据仓库中人工创建的汇总表。

在物化视图的多层构建策略中，越贴近明细数据的物化视图灵活性越高，越接近结果的物化视图性能越高。前者适用于灵活分析场景，后者适用于管理驾驶舱和一些固定报表的场景。在两者之间，我们还可以针对复杂指标（如先计算均值再计算排名）的整体构建物化视图，以及构建行间偏移类指标（如最近 30 天的日均交易客户数等）的物化视图。

在整个物化视图的构建过程中，我们可以根据需要调整加速的粒度，以实现性能和成本的最优平衡。此外，Aloudata CAN 支持视图依赖视图的构建方式，例如基于日常的聚合视图来构建行间偏移的物化视图。系统自动生成视图依赖关系有助于避免重复构建。如果系统检测到已存在相应的物化视图，就不会进行重复的构建工作。

Aloduata CAN 的物化加速策略遵循了数据仓库中的最佳工程实践。

第一个策略是冗余维度打宽。即针对常用的维度，将其与明细事实表进行预打宽，这样上层在使用时就可以基于该明细宽表进行计算，可以减少多次关联带来的计算消耗。

第二个策略是同事实同实体合并计算。如针对订单表的多个不同的指标，可以放在一起进行计算，减少对事实表的多次扫描。

第三个策略是长周期依赖短周期。如已有物化视图是基于“天”粒度构建的，那么，派生指标中的近 7 天、本月、近 30 天等等，都可以基于该天粒度的物化视图进行构建。

第四个策略是细粒度上卷聚合计算。如已有物化视图的维度是 A、B、C、D，当用户新构建的物化加速方案是基于 A、B 两个维度时，则可以来 A、B、C、D 四个维度的物化视图进行上卷，避免了从原始数据进行计算。

以上四种例子较为常见，Aloudata CAN 还设置了许多其他加速数据处理的策略。

第二步是物化视图的调度更新机制。如果上游数据发生变化，我们需要知道何时刷新物化视图的数据。这可以通过两种方式实现：一是与上游任务对接，通过调度通知触发实时更新；二是设置定时更新机制，系统会自动处理物化视图的变更和刷新。这种机制能够识别哪些指标受到影响，并针对这些指标进行更新。

Aloudata CAN 基于指标的血缘关系，形成一个网络算子图谱。例如，如果一个维度表或事实表发生变更，我们不会对所有指标进行回刷，而是只针对受影响的指标进行局部回刷，以尽量减少回刷范围。

第三步是物化视图的命中改写能力。用户在使用时通常不需要知道背后使用的是哪种表，查询时，系统可以根据用户的查询行为将查询路由到最匹配的物化视图上。

Aloudata CAN 通过逻辑树的方式判断用户的查询应该路由到哪一个物化视图，或是直接下推进行实时计算。这种判断可能基于 BI 工具发起的查询，也可能是来自我们的 APP 或业务系统的查询。在发起查询时，Aloudata CAN 会遍历物化视图。

首先检查是否能命中顶层的物化视图，即是否能直接得到查询结果。如果顶层的物化视图没有命中，我们会继续向下遍历，检查是否有符合行间偏移的物化视图。如果这一层也未命中，我们将继续查找是否有符合特定粒度（如按天）的普通物化视图。如果这些都未命中，最后我们会尝试兜底的星型模型物化视图。如果连兜底的物化视图都未命中，那么我们将直接查询底层的明细数据，并进行实时计算。

查询如果命中多个物化视图，Aloudata CAN 会选择一个最优的。这个最优选择基于几个原则：数据量是否最小，指标是否与业务需求最匹配，以及时间范围是否最接近。

最后一步是关于物化视图生命周期的管理。在传统的数据仓库环境中，发布新表容易，但下线旧表难，因为 ETL 工程师不容易判断下游是否还在使用这张表。现在，系统能够自动识别物化视图是否被下游消费，从而实现无效物化视图的自动回收，减少了维护成本和风险。

总结一下：传统人工进行的宽表和汇总表加工可以通过 NoETL 自动化完成。这得益于两个核心技术能力。首先是语义化能力，它允许任何指标的计算逻辑被定义并统一管理，这是自动化的前提。其次，一旦所有复杂的指标都能被表达，我们就能实现这些指标的快速计算，从而保证在大数据量下也能有良好的性能和业务响应效率，同时确保数据的一致性。

二、第三代指标平台的能力与价值

我们将 Aloudata CAN 定义为第三代指标平台，即 NoETL 自动化的指标平台。在讨论第三代指标平台之前，我们先简单回顾一下第一代和第二代指标平台的特点。第一代指标平台主要是将原本线下通过 Excel 维护的指标字典转移到线上，实现了指标口径的登记和管理。但在这一代中，指标的定义和开发是分离的，无法实现自动化生产和统一管理。

第二代指标平台受到近年来国外 Headless BI 概念的启发，将指标平台作为一个独立层，位于数据仓库和 BI 工具之间。这一代指标平台尝试解决了一些自动化和语义化的问题，但仍然存在局限性。由于缺乏强大的语义化和自动化能力，许多复杂的指标仍需回到数据仓库中由 ETL 工程师处理，因此第二代平台仍然依赖于 IT 部门来开发复杂的宽表。

第三代指标平台的核心在于实现指标的定义、开发和应用的一体化，即所谓的“管研用一体化”。这种一体化的背后，是四大核心能力的支持。首先是指标的规范定义能力，这不仅仅是对指标进行定义，还包括了指标的治理。与以往在数据已经开发完成后才进行治理不同，第三代平台希望通过事前的规范定义来避免问题的发生。由于指标的语义已在平台上得到了很好的沉淀，我们可以利用这些语义进行同名同义的自动校验，从而提高治理效率和准确性。

总的来说，第三代指标平台通过强化语义化和自动化，以及实现指标管理的高度集成，为企业带来了更高效和统一的指标管理解决方案。就是比如说同样的一个指标，可能每个人首先看到的是名称相同，我只允许它存在一个。其次，它的语义表达，即业务的口径是一样的，但原来可能有不同的名称。例如在零售或电商领域，有的指标叫 GMV，有的叫交易金额。实际上它们背后的逻辑是一样的，我们的系统能够自动识别这一点，因为我们使用的是自动翻译的 SQL，我们知道它们的逻辑是相同的。因此，我们也会认为它是一个同义不同名的指标，并且只允许定义一次。

其次，指标定义完成后，就可以立即使用。如果没有性能问题，实际上因为我们存储的是逻辑数据，不需要像传统数仓那样进行测试、发布或运维调度任务等。通过界面化配置完成后，就可以直接使用。如果在过程中遇到性能问题，就可以使用我们之前提到的自动化指标生产，通过这种方式可以实现一级生产功能。

第三点是，指标定义完成后，我们的系统会自动生成一个以指标为目录的企业统一指标体系。传统上可能依靠工程师或分析师在自己的文档中维护企业指标体系，但对于企业来说，我们在与客户交流时会询问企业有多少指标，每个业务有多少指标，这些指标是如何构成的。很少有企业能够清楚地回答出来，因为他们可能从未盘点过或者盘点的难度非常大。但有了这样的一个指标平台，它会自动生成一个指标目录，我们能清楚地看到企业里总共有多少指标，每个指标的业务逻辑是什么，每个指标的血缘加工逻辑是什么，是基于我们数仓的哪张表，通过哪个字段加工出来的。

此外，我们经常会发现，可能在业务发展过程中，会存在指标的口径版本变更。原来的版本变更可能在数仓中进行了版本维护，也可能没有。比如我之前在阿里做分析师时，我们会发现给业务看的数据下面都会有一个补充说明，比如什么时候我对这个口径进行了调整，因此调整前后数据可能会有变化。在我们的指标目录中，我们提供了指标的多版本管理功能，这使我们能够清楚地了解一个指标在历史上经历了多少次口径的变更，并且可以明确每一个版本口径的差异。如果需要回溯到之前的版本，我们也可以通过一键操作简单地回到历史版本，这是指标目录中的一项重要功能。

此外，指标目录的另一个重要特点是能够将企业的业务知识通过产品化的方式沉淀下来。在当前高员工流动的环境中，很多企业面临的一个问题是，员工离职后，之前在数据仓库中加工的逻辑信息交接不到位，新接手的员工往往需要投入大量工作量来理解和继续之前的工作。通过 Aloudata CAN，原有的加工逻辑可以被完整地承接下来，即使发生人员变动，也能快速对接上这些指标的逻辑。

在指标消费方面，我们通过标准的 JDBC 和 API 接口，可以实现与企业现有的 BI 工具、业务系统以及管理驾驶舱的无缝对接。

通过这四大能力，我们希望为企业带来以下效果：首先，业务人员能够更加清晰地理解指标的口径和计算方式，因为指标平台使得加工链路可视化、变更历史可查询。其次，对于数据人员和管理人员而言，由于所有逻辑都是在项目初期通过严格的校验确定的，并且通过语义化的定义，我们可以实现一个指标定义一次，大量派生指标无需重复定义，从而实现高效管理。最后，对于业务人员来说，他们可以更灵活地使用指标，从各个维度消费和分析数据，甚至可以下钻到背后的明细数据，并基于任意维度进行筛选。这大大提高了业务人员的工作效率和满意度。基于我们的语义模型能力，它也能实现跨多个事实表的多个指标和来自多个维度表的多个维度的综合分析，而无需通过技术同学将多个事实表进行汇总开发。

我们将 Aloudata CAN 的价值从供给侧（IT）和消费侧（业务）进行了总结。对 IT 的价值体现在能够实现应用层 NoETL，大大减少了开发和运维的工作量。这是因为，传统数仓通常有四层结构：从贴源层到公共层，再到 DWS 层，最后是集市层或应用层。现在，我们让 IT 人员专注于公共层的资产开发，业务场景端的集市层可以通过我们的指标语义层来替代，通过指标的定义来取代集市层的开发。这样不仅减少了大量的开发和运维工作量，也减少了与业务沟通和协作的成本。

对业务侧的价值体现，首先，我们提供了一种以指标为中心的业务自主分析体验。传统上，许多 BI 工具还是基于数据集、表和字段这种技术逻辑的方式。现在，我们提供了一种用户只需知道他们想要分析的指标，这些指标实际上更贴近他们的业务语言，因此他们可以直接拖拽指标和维度进行分析，只要有权限即可。正如我之前提到的，他们可以选择来自不同事实表的指标和来自不同维度表的维度，将它们放在一起进行图形化分析。

此外，我们还支持一种情况指标标签化的灵活需求。例如，在电商或金融行业，我们可能会经常举办一些活动，在活动期间，我们经常会收到大量的临时取数需求。这些临时取数的需求主要是希望通过特定指标将某些客户群体标签化或维度化，以便在活动期间圈选出特定的人群。具体来说，可以通过选择满足特定条件的用户 ID，例如最近一个月交易次数超过三次的用户，来查看他们在活动期间是否访问了活动页面、领取了优惠券或购买了商品。Aloudata CAN 使业务部门能够自主完成这些操作。

其次，关于指标的智能归因，虽然许多 BI 工具提供了归因能力，但关键在于归因算法所使用的数据是明细数据还是汇总数据。传统模式下，归因算法多数使用的是已经聚合过的数据。而在我们的指标平台上，建议的最佳实践是基于公共层的明细数据来定义指标，这样可以进行更深入的维度拆解，实现从广度到深度的归因分析。

最后，关于大模型的应用。OpenAI 等机构已经提出，直接使用自然语言处理（NL to SQL）可能难以保证百分之百的精准度。许多企业的 AI 团队也发现，尽管进行了多次调优，应用场景仍然有限，覆盖的场景不够广泛，或精准度不足。因此，背后需要一个强大的语义模型来支撑大模型，确保数据质量和业务知识的有效沉淀，这对于提高大模型的应用效果至关重要。

我们发现，指标与数据模型的结合，在许多企业内被认为是打造交互式对话分析体验的最佳途径。我们也正与不同行业的客户共同创造这样的体验。当然，目前我们尚未推出 ChatBI 的产品，我们正在与一些顶尖的金融客户合作，他们拥有自己的数据模型，我们的任务是将这些底层能力与他们的模型能力相结合。我们也在考虑，下半年将朝这个方向进一步发展。

做个总结：第三代指标平台给我们 IT 部门带来的体验改变，表现在大幅减少指标重复开发的工作量和运维变更的工作量。对业务部门来说，它提供了真正处理“最后一公里”自主分析问题的体验，让业务人员能够自助完成分析工作，而不需要为增加字段或维度而频繁联系 IT 部门。

三、第三代指标平台做轻数仓实践

以上内容是关于技术与产品的一些介绍。接下来，我们分享在一些企业中真实落地的实践情况。由于我们团队来自阿里巴巴和蚂蚁集团，对电商和金融领域有深入了解，因此，我将举例介绍金融行业的两个案例，涵盖证券和银行业务。

首先是来自证券行业的一个客户案例。先来了解一下这家公司的 IT 团队。他们没有复杂的专职分析岗位，仅有一个技术部，而负责数据的技术人员人数也非常有限。

在与我们合作前，他们面临三个主要的痛点。首先，为了满足业务需求，这些 IT 人员需要开发和维护大量的数据表，ETL 的运维工作量巨大，尤其在他们人手非常有限的情况下。

另外一个痛点是，证券行业的专业知识要求高，理解业务逻辑背后的细节极其困难。这常常导致 IT 人员与业务部门之间沟通不畅。即使 IT 部门开发了数据表，业务部门在验证时仍可能提出与 IT 理解不一致的需求，这样就需要重复调整指标口径，极大增加了工作量和沟通成本。这家公司希望能将指标定义的工作交由业务人员自行完成，以此减少重复沟通的时间和精力损耗。这是他们的第二个痛点。

第三个痛点就是数据响应效率的问题。现在所有企业都越来越依赖数据进行业务决策，而这家客户的数据团队人手非常有限，快速响应业务需求的挑战非常大。

在我们提供的解决方案中，企业只需处理公共层面上的明细资产沉淀，并围绕行业十大模型进行资产沉淀。

于是，它实际上重新定义了指标开发的方式：从过去需要开发大量应用层的表，到现在简化为在公共层利用指标平台就可以轻松地实现。举例来说，在该企业的资管业务线上，我们将指标分为原子指标、派生指标和复合指标三种。资管业务作为证券行业的核心业务之一，业务人员便能够利用原子指标和维度自主组合出所需的派生指标。

这个企业，尽管人力资源有限，却成功地提供了一种以指标为中心的自主分析体验。业务人员可以使用简单直观的方式，灵活地进行分析。他们的 IT 团队仅开发了约 80 个基础和复合指标，但有超过 300 个可供业务人员自由组合的维度。

这样的做法，使得在指标开发上节省了大约 70% 的工作量。客户评估称，一个工程师原本一天只能开发约 3.12 个指标，但采用我们的产品后，他们半天就能处理超过 20 个基础指标，大幅提高了开发效率。此外，产品的配置化界面，还降低了操作复杂 SQL 的门槛，让应届生和实习生也能轻松定义指标。

第二个案例是银行业的，这个合作中，客户面临三个主要问题：首先是 BI 工具的性能问题，查询 3s 打开率不到 70%，这是因为数据仓库的性能与灵活性之间需要平衡；其次，业务分析过程中，业务部门在查看数据后常有新的需求，需要 IT 部门准备数据，导致数据分析难以打通“最后一公里”的问题；第三，总行和分行选择了不同的 BI 工具，导致无法共享和复用数据。

这家银行拥有数百到上千人的 IT 团队，他们选择自建交互层面，仅在指标语义层使用了我们的服务。通过我们提供的 API 接口，客户能够自助地从数据准备到分析，实现一体化操作，显著提升了交付效率。此外，从只能进行客群级别的分析提升到了客户级别的分析，并且实现了总行和分行使用不同 BI 工具间的指标复用。

去年一期的合作成果包括：原本所有数据集都需要科技部 IT 团队处理，现在 65% 的工作可以由业务部门自主完成；原本在多个 BI 工具中沉淀的指标下沉到我们的指标平台实现了共享和复用；通过我们的自动化能力，实现了 95% 的查询在三秒内完成。这是一期的成果，今年我们也在继续进行第二期的工作。

在这个过程中，我们发现它改变了企业内部业务的协作模式，特别是 IT 人员和业务人员之间的协作。他们自己总结出了一种叫做“136”的协作模式。“136”指的是的科技人员负责语义模型关联关系的建立，以及整个企业的通用基础指标和原子指标的加工与定义，这部分指标占比 10%。其余的部分，许多业务部门都有自己的业务分析师，这些分析师围绕业务条件定义通用的派生指标，这部分占比 30%。最后，60% 的灵活需求则交给业务人员自己，让他们像搭积木一样选择指标和维度，以满足自己的需求。这就是“136”协作模式的核心内容。

Q1：关于指标中心，实际上有很多应用场景，比如用户需要提取一些清单数据。这种数据提取可以实现吗？

A1：是的，这里面主要分为两部分。第一部分是提取临时数据，这种数据通常是基于公共层的明细数据定义的，比如提取用户交易的明细数据，这种是常用的指标，如交易金额，我们的平台可以实现。第二部分是创新业务的指标，这种指标可能没有固定下来。对于这类指标，我们不建议在指标平台上处理，因为我们认为一个指标应该具有一定的通用性、适用性和持续性才适合进入指标平台。但是，我们发现很多企业的临时数据或指标实际上是可以通过在平台上叠加各种筛选条件来解决的。

Q2：您好，我想询问一下，大多数企业可能已经拥有数据仓库，并且已经建立了很多宽表，甚至已经部署了自己的指标系统，并拥有很多指标。当它们切换到您的系统时，如果在您的系统中定义了原子指标，它们还需要定义一些限定词，并配合定义复合指标。这些内容如何与我原有的宽表和指标系统绑定，以形成物理表上的关系？

A2：对，这确实是我们在与许多企业交流时经常遇到的问题。首先，我们已经落地的一些客户，他们原本拥有自己的指标平台，但那个平台仅用于指标口径的登记，不能实现指标的实际开发。在这种情况下，我们可以通过 API 接口，让他们在原有平台上录入指标的业务逻辑，而实际的计算口径则在我们的平台上进行开发。

其次，确实许多企业已经有了大量的宽表和汇总表。我们不要求客户放弃使用这些现有的表。您可以将宽表和汇总表接入到我们的指标平台，但这样做无法实现指标的灵活应用。

因此，我们通常建议企业在实施过程中采取逐步策略。例如，您可以从那些经常提出需求、痛点较为突出的业务线开始，先不动原有的宽表和汇总表，而是逐步进行优化。比如我们最近与一家大型股份制银行合作，他们的第二期项目名为“虚拟集市层”，他们计划逐步优化原有数据仓库中的内容。我们建议从业务条件通畅、需求较多的部分开始，慢慢过渡到这种模式，因为这是一个渐进的过程。