摘要：杜雪芳：各位嘉宾，大家下午好。在数据驱动决策的时代，越来越多的企业将指标平台作为统一指标管理和赋能敏捷用数的核心基础设施。那围绕“指标平台选型标准、价值评估、指标平台项目实施、与 AI 融合创新”等话题，我们非常荣幸地邀请到四位行业嘉宾，与大家共同探讨指标平台

杜雪芳：各位嘉宾，大家下午好。在数据驱动决策的时代，越来越多的企业将指标平台作为统一指标管理和赋能敏捷用数的核心基础设施。那围绕“指标平台选型标准、价值评估、指标平台项目实施、与 AI 融合创新”等话题，我们非常荣幸地邀请到四位行业嘉宾，与大家共同探讨指标平台在企业中的落地实践。

他们分别是：

四位嘉宾均拥有丰富的数字化实践经验，接下来我们开始正式讨论。

话题一：在众多指标平台产品中，企业应如何结合自身情况进行选择？背后有哪些关键考量因素？

滕永铮：先自我介绍一下，我来自理想汽车，目前负责公司数智平台产品。选择合适的指标平台，我觉得主要有两点考虑：第一是生态构建能力。因为企业很难通过单一产品解决所有问题，而是需要基于该产品衍生出完整的生态。我们希望将生产力的数字化进一步拓展为生产关系的数字化，因此，指标平台必须具备开放性，能够支持丰富的 API 扩展和数据对接功能。

第二是数据加速能力。与传统互联网企业不同，车企的数据分布较为特殊。我们的业务数据量差异较大，部分业务数据量极高，而部分业务数据量极低。因此，在数据极高的场景下，我们需要指标平台具备良好的数据查询加速能力，以确保在使用过程中能够获得流畅的体验。

张巍：大家好，我是张巍，来自 lululemon。我觉得建设指标中台主要有三点考量：第一个考量点是数据治理与管理的需求。随着公司业务的发展，数据和报表的数量不断增加，管理难度也随之上升。所以我们需要一个有力的“抓手”来落地数据治理体系，确保数据的有序管理和高效利用。在考察了多款产品后，Aloudata CAN 在这方面功能强大，我们将其作为数据架构体系的中间层，向下梳理底层的数据仓库、数据湖中的各种资产，向上提供统一的指标服务。通过这种方式，指标中台成为我们数据治理的核心抓手。

第二个考量点是指标平台与现有数据仓库的集成情况与未来的发展潜力，我们湖仓使用的是 Databricks，Aloudata CAN 与 Databricks 的集成表现良好，能够很好地兼容现有技术架构。

最后一个考量点是从使用体验来看，Aloudata CAN 在数据治理、管理和产品功能方面都表现出色，操作便捷，能够满足我们的业务需求。因此我们选择了 Aloudata CAN 作为我们的核心数据组件。

陈润红：我做一个补充，可以从成本、灵活性和服务质量三个角度来考量。成本包括软硬件成本，部署、研发及后期运维的人力成本等，共同构成了整体成本。

灵活性指的是指标平台与企业内部的兼容性与灵活拓展度。因为对企业而言，它本身是外购的产品，所以能否快速落地在企业的生态里，往往取决于它以多块的速度去兼容适配原有的历史包袱，以及同企业内部其他系统快速打通。这一点是非常重要的。

第三个是交付团队的服务质量，包括在 POC 阶段的响应速度，运维阶段的响应效率，以及遇到问题双方的沟通和服务态度等。这些都是我们在选型时会考量的标准。

倪程伟：我这边主要谈两点。一是开放性，就是指标平台向上向下的开放性。向上是暴露出来的 API 的开放能力，能否与企业内部现有的系统和应用无缝集成；向下是指标平台能否与底层数据仓库、数据湖等基础设施顺畅连接。因为我们已经建了很多系统和应用，不可能用一个新的平台完全替代，而是希望新平台能够融入现有的技术生态，实现兼容并存。还有一个是灵活性。在当前的技术架构下，指标平台需要具备全面的能力来覆盖广泛的业务需求，包括指标的定义和计算等。这种灵活性直接决定了平台能够支持的业务广度，进而影响到企业整体的数字化运营能力。

杜雪芳：就像各位老师刚刚提到的，在指标平台选型过程中，不仅要关注指标平台的定义能力、加速能力，也要关注产品本身与企业已有的技术基础设施的适配性、开放性，以及指标平台提供商的服务能力和交付能力等，需要做综合的考量。

话题二：如何评估指标平台的 ROI？在落地之后有哪些效果？

陈润红：我先分享一下。我会从两个视角去看：一个是业务视角，另一个是技术视角。从业务视角来看，评估指标平台的价值在于投入产出比的衡量。在成本方面，就我刚刚提到的硬件、软件、人力投入等整体成本。产出价值方面，我们需要看指标平台需能覆盖多少关键业务场景，并带来可量化的业务收益。例如，在麦当劳门店运营中，通过指标监控实现能耗节省、用油优化等，直接转化为成本节约和效率提升。因此，企业应确保指标平台在成本可控的前提下，显著提升业务价值，从而做出明智的选择。

从技术视角来看。当建设指标平台时，需要综合考虑对研发人员和产品经理的好处，以及前期建设与后期维护的人力投入。例如对研发人员能简化开发流程、提高开发效率，助力技术成长；对产品经理提供统一指标体系，助力精准决策，提升业务价值并降低沟通成本等。

倪程伟：我也谈两点。短期内要看指标平台对业务的价值，能否解决实际的业务痛点，比如口径不统一、查数用数困难等。从长期发展来看，在选择指标平台时，不仅要关注其当前的业务覆盖能力，更要考虑其是否具备适应未来技术迭代和应用场景扩展的能力，以提供更灵活的分析和洞察功能，成为企业智能化的数据新基建，从而帮助企业充分发挥数据价值，在技术变革中保持竞争力。

张巍：我觉得给我们公司带来的最大价值，是通过指标平台，加速了指标开发和交付。之前报表开发周期较长，有时要一、两个月才做一张报表出来。有了指标平台后，如果事先定义好指标，基本上都是以天为单位来进行交付。这个是我觉得最大的一个进步。

滕永铮：我觉得应该从两个角度来看。第一个角度就是直接收益，体现在指标平台的使用者效率的提升，包括开发效率提升，以及更多角色参与到指标定义和管理之中。第二个角度就是间接收益，例如通过指标平台，我们实现了指标口径的统一，减少了业务反复沟通和数据差异等问题，做到了及时止损。

杜雪芳：对，从我们的角度来说，把直接收益算清楚、做好是关键，无论是指标开发周期从月到天，效率的显著提升，还是人力、存算成本的大幅降低，都是我们希望通过指标平台为企业带来的价值。当然，像陈老师和滕老师刚刚讲到的，给企业创造的间接价值等，一样也很重要。

话题三：如何梳理指标体系？指标平台落地后与原有数据仓库的定位与关系是什么？

陈润红：我们落地指标中台刚好也有一年多了，以下谈些我的个人观点。在企业梳理指标体系的过程中，首先需要勾勒出整体的框架，明确企业需要涉及的指标分域大致范围。其次，要分点式地逐步补充和完善指标体系，因为企业并非从零开始，往往存在大量历史包袱。

面对这种情况，我们要怎么办呢？我个人觉得应结合业务需求，由业务需求去触发去建设，然后通过“拔出萝卜带出泥”的方式，像拼图一样逐步完善整体的指标体系。在我看来，这是一个更实际的方法，因为在企业内部，一个项目不可能没有业务需求，就争取到各个资源的支持，然后高举高打去落地。所以，我们需要抓住源源不断的业务需求，将其转化为指标体系中的每一块拼图，这样才更符合实际情况。

倪程伟：我觉得梳理指标体系需要先梳理业务流程，因为业务流程的梳理往往承接于公司的战略和规划，是自上而下层层分解来的。指标体系的意义则在于反映业务的运行情况和效果，通过对业务的度量、追踪和调整，为业务经营管理的决策提供有力支持。所以，只有通过完整的业务流程梳理，才能构建出有效的指标体系。同时，我们还要让组织架构中的人员清楚自己的职责和需要追踪的指标。

关于指标平台和数仓的定位及关系，我觉得我们还是在探索阶段。因为早期建设时，我们较为理想化地认为，将所有系统直接连接起来就 OK，但很快发现，原有的数仓并不像我们期望的那样规范和干净，其中存在诸多问题。这些问题可能在过去的 ETL 阶段被各种 SQL 脚本掩盖，但在引入指标平台后，这些问题就被暴露出来，所以需要被正视并解决掉。因此，我们正在努力解决这些问题，以优化指标平台与数仓的架构，支持更灵活的分析和更深入的洞察。这一过程仍在持续进行中。

张巍：我也谈一下个人的一些想法。首先我觉得如果从指标体系与 BI 的区别来看，BI 更多是从业务需求出发，自下而上地开发报表。而指标体系则是基于公司的愿景或目标，自上而下地拆解目标并确定相应指标，与业务连接更紧密。指标体系也应追求精简而非繁多，以避免随着报表增多形成冗余。

滕永铮：我觉得指标体系的建立过程应该包含两个方面：第一是自上而下的拆解，从公司整体的战略北极星目标出发，逐步拆解到部门，再细化到每一个可执行的指标；第二是自下而上逐步推进的实施，由于我们存在非常多的历史包袱，所以无法从 0 到 1 一次性完成，所以需要结合实际情况，逐步推进指标体系的建设。可能在实际落地的过程中，会有一个两端逐渐走到一起的这么一个过程。

亚马逊他们有一个叫“逆向工作法”。强调了输出指标与可控输入指标的概念。在指标拆解过程中，企业需要从具有观测性的输出指标出发，将其拆解为逻辑上相关且可控的输入指标，通过管理和优化这些输入指标来影响输出指标，从而实现业务目标。这种方法体现了自上而下的指标拆解逻辑，有助于将战略目标转化为可执行的行动方案。关于数仓与指标平台的定位关系，目前也没有特别想好。因为这不是一个从零开始的全新项目，而是在众多历史包袱基础上去逐步推进。在这个过程中，我们要面临诸多思考、尝试和曲折，是一个需要结合企业自身特点长期摸索、逐步完善的过程。

话题四：实施了指标平台后，如何规划存量指标和报表的迁移路径？

陈润红：从技术层面去考量的点是，当接到一个新的业务需求，或考虑将存量报表迁移到指标平台时，关键在于数据的一致性和整合的必要性，需要评估数据同步机制，以确保不同系统间数据的一致，同时还要处理好并发冲突和缓存一致性的问题。当然，如果实时性要求不高，可延缓整合，采用异步处理机制。另外一个是流程上的考量。在启动指标平台建设时，需要动员多个角色协同参与。这就要求我们深入到业务部门，与产品经理等各方沟通，明确他们参与的动机和必要性。是由于现有应用需求交付无法满足，还是其他原因。只有搞清楚各方参与的动机和协作流程，才能有效推动项目的开展。

倪程伟：对，我也觉得这个问题是一个挺头疼的问题。因为数据领域经常面临新旧系统过渡的难题。新建系统上线后，旧系统如何处理是一个棘手问题，无法实现从旧系统到新系统的一步到位迁移。所以我们采取的策略是，绝大部分业务功能都在新建的指标平台上实现，对于旧系统，随着业务梳理和与业务部门的沟通，逐步进行迁移或改造。由于业务每年都有变动，对于变动频繁或重要的业务，优先进行迁移或改造，而对于变动不频繁或不重要的业务，可能会暂时保留一段时间。

张巍：从我的经验来说，将旧报表迁移到指标平台，还要看它的投入产出比。如果迁移后的收益显著高于投入，那么就是值得的，否则就是不必要的。在我看来，从长远看，统一指标体系是必然趋势，但在实施过程中需要权衡优先级，因此，需要根据业务的重要性和变动频率，决定哪些报表优先迁移，哪些可以延缓甚至不迁移。

滕永铮：说说我的理解。我觉得从指标管理角度来说，可以对指标进行分级：核心指标、关键指标、一般指标，明确其重要性和优先级。核心指标对公司战略和关键业务目标有直接影响，需在指标平台上统一管理；关键指标对特定业务领域重要，可按需迁移；一般指标若现有体系能满足需求，则可暂时保留。所以我们应该根据指标重要性和业务需求，决定是否迁移至新的指标平台，合理分配资源，避免带来额外成本。

但从业务角度来说，业务肯定希望指标能够实现中心化管理，确保在多个产品、看板和平台中保持一致。因此，在考虑迁移时，需要找到合适的时间点。例如，在企业发展的某个阶段，如当下两个月业务相对平稳、落地事务不多、人力相对充裕时，可以利用这一时机推进迁移工作。同时，要结合企业当前的发展阶段、业务重点以及指标的重要程度，制定合理的迁移策略，逐步实现指标的中心化管理和一致性。此外，我们还要综合评估指标在这种自然时间状态下的质量、对业务的影响等因素。

杜雪芳：刚刚各位老师也提到了，我们在迁移前，要考虑历史资产、要考虑 ROI，以及指标应用场景的重要性，包括现有资产的质量等因素，这些都会影响到迁移的策略和方法。当企业拥有了一套全新的指标平台，不可能一下子将所有的历史资产全部替换，而是跟随着业务的发展情况、重要性和当前资产可能存在的问题，进行逐步迁移。

话题五：指标平台在落地过程中面临的最大挑战是什么？如何解决分工协作等问题？

陈润红：分前、中、后期。在指标平台建设的前期，主要挑战在于构建数据资产和指标体系的全图，设定规范流程以及明确各部门和角色的权责，为后续落地实施奠定基础。进入中期，重点转向保障平台的性能与稳定性，搭建运维团队，确保平台能够稳定运行并满足业务需求。到了后期，挑战则集中在指标治理上，包括下线无用指标、处理重复指标，并与研发团队探讨治理手段，以优化指标体系，提升平台效率和质量。

倪程伟：在落地新的指标平台和理念时，确实面临很多挑战。因为这是一套新的体系，需要解决的问题很多。首先，就要说服业务部门和其他相关人员，让他们理解为什么要进行这一变革。其次，在实施过程中，由于这不是从无到有的全新建设，而是基于历史资产的迁移过程，还需要思考新体系相较于旧体系的价值和意义。但从整体来看，因为我们已经经过了充分的技术研究和论证，所以我觉得我们是在坚持做一件正确的事，接下来就是解决遇到的各种问题，努力变得更好。

张巍：我觉得遇到的最大挑战还是整个体系的建立，以及怎么更有效率地去运行。因为整个指标体系包含业务和技术两大块。那这两大块该如何协同，这在初期会是一个挑战，之后可能会随着系统的逐步运行和优化，情况变得更加顺滑，慢慢也就大家能理解其运行逻辑和协同机制，也就不会像一开始那样比较抽象。

滕永铮：我觉得指标平台的建设不仅仅是技术问题，更是大家合作关系和责任划分的改变。以前，对于指标的责任归属，一直都是模糊不清的，在数据产品、数据研发和业务部门之间饱受争议。现在我们可以将指标视为一种独立的数据资产，它的管理、定义和流程也跟着发生了变化。这就可能要求原本不在相关圈子的人，不得不接受新的角色和责任，甚至可能团队和组织的角色发生了变化需要重新组织。因此，在这件事上，大家的意识、企业文化和对数据的理解都需要相应调整，以适应这种变化。

杜雪芳：在我看来，指标平台它不仅仅只是一个技术工具，更是企业指标管理思想的体现，也是我们整个企业文化的载体。例如通过指标平台，我们可以看到企业的战略方向、业务重点及绩效评估标准等，从而更好地引导员工向同一个目标发力。所以，建设指标平台，需要综合考虑多方面因素，包括平台建设目标与企业战略对齐、赋能业务降本增效、保障数据准确安全等，以充分发挥其价值。

话题六：大模型的火热对企业指标平台建设有哪些影响，以及未来的发展方向？

陈润红：刚才提到的 Chat BI 是未来的一个发展方向，但大模型是不是只能用在 Chat BI 的场景呢？其实不一定。我觉得随着指标平台的建设和发展，在积累了大量语义信息后，可以通过大模型实现更主动的业务问题诊断，而不需要只是对话的形式。这种从被动到主动的转变，能够帮助企业在数据分析和决策支持方面实现更深层次的智能化。我们也在思考另外一个方向，就是其实当数据的管理和生产方式发生一定转变的时候，我们自己的数据团队内部的运营方式，是不是也可以通过指标化结合大模型来实现赋能。我觉得这也是蛮有想象空间的。举个例子，比如说我们是不是可以对一些项目的运营过程制定指标，利用这些指标来驱动运营流程的优化。

倪程伟：我这边也谈一下。随着 DeepSeek 等大模型的兴起，我们也投入了许多精力去研究，并在不同场景中进行尝试。其中在数据分析、逻辑推理以及文档处理等工作中，大模型表现出色。然而，在更多的实际应用中，我们也意识到引入大模型是有成本的，而企业内部原本就存在一套固有的逻辑来处理一些工作。

所以我们也在思考引入大模型的必要性，还要权衡成本与收益，以确保其应用能够真正带来价值。以指标归因功能为例，大模型虽然具备分析能力，但需投入较大的资源才能获得准确的分析结果。而传统的指标平台或其他工具也能在特定维度或基于指标间业务关系进行归因。那我们在实践中，就必须要思考这两种方式的投入成本与业务效果，才能够确定出更优的方案。另外，尽管大模型成本有所降低，但并非免费，仍需权衡其投入产出比。

张巍：我也谈谈我们的看法。可能大家认为数据或者指标都是很重要的，但我们觉得未来企业需要的不仅仅是数据和指标，更重要的是知识。因此，我们会将知识的体系化建设作为 AI 的应用方向，指标和报表都是知识体系的一部分。所以我们可能会探索如何将指标、报表以及其他相关元素集成到一个 AI 知识体系中，这样可以大幅降低知识获取的门槛，成为大家快速获取知识的一个渠道，一种工具。

滕永铮：我讲三个方向。第一个可能大家比较清楚的就是我们的“理想同学”。这个除了在车上有，我们也有一个手机 APP 版。通过“理想同学”，比如孩子说要画张图，它可以帮你画。未来我们还将继续探索大模型在更多场景的应用。

第二个方向是利用 AI 能力解决数据相关问题，以提升数智平台产品的效能。比如说，通过 AI 技术对血缘行为进行精准解析，优化产品功能和服务；借助 AI 分析大量日志，快速定位和排查系统错误，提升系统稳定性；利用 AI 帮助用户优化编写不佳的 SQL 语句，提高查询效率和数据处理速度。这些应用场景是平台建设中对 AI 能力的一些需求，以不断提升数据处理和分析的效率与质量。

第三个方向讲一个与指标平台相关的应用，也就是对话式分析能力，但这不是我们的终极目标。具体而言，我们同时在推进 NL2SQL 和 NL2Metrics 两个方向，并将两者结合用于数据准确性的校验。我们发现，在多表状态下，NL2SQL 的质量存在一些问题，尽管我们尝试了多种方法，但仍有一些盲区。因此，我们通过两种数据的校验和场景的交叉使用，来提升数据的准确性。这是我们在企业内部对大模型应用的一个重要实践。

杜雪芳：刚刚各位老师也提到了，大模型的应用不仅局限于数据分析，还能够帮助我们实现数据开发的提效，为业务赋能。但大模型广泛应用的前提是，低成本（less cost），这一点各位老师达成的共识也与我们提出的“Less cost，more intelligence”的观点相呼应。如果应用大模型比我们人工成本还高的话，那我们还是选用现有的方式，一是我成本低，二是人工“白盒化”更有保障。所以，我们希望在推进大模型应用的进程中，既要使其不断降低成本，也要持续提升其智能化水平。

现场观众互动问答

Q1：刚才听各位老师在讲指标平台的过程中，也有提到指标和大模型的结合。我这边想问一下，对于大模型的微调和推理两大环节，各位老师是如何看待和推进的？比方说微调需要编写训练代码，推理则需要推理代码，然后我们去创建项目，输入、输出数据，最终得到理想的模型。所以在目前的工作中，我们是更侧重训练微调，还是推理？是自己在推进，还是找专业的具备大模型和大模型框架基因的企业合作布局？

陈润红：我觉得大模型能力走到今天，已经初步成熟了。对于模型的调试，可能并不是我们这些应用型企业去考虑的。我们去考虑的更多应该是业务规则的梳理。举个例子，比如业务决策的归因，指标树应该是什么样子，整个思路应该怎么展开，报告的关注点是什么等。这些反而是更重要的。如果面向业务交付的需求，那么在指标平台的应用中，知识库或提示词的注入，以及结果的反复校验，校准与业务的联动，这些环节可能更为重要。我们需要将这些关键动作进一步拆解，以确保它们能够更好地支持业务交付，而不是仅仅侧重于模型的训练或推理环节。

倪程伟：对，我理解现在 Agent 的建设，主要还是在于一些提示词的优化，以及基于 RAG 的知识库的建设，可能会更重要和有效一点。微调可能并不是当务之急，因为业务交付的核心在于如何通过精准的提示词和丰富的知识库来生成符合业务需求的结果，并确保这些结果能够与业务流程形成紧密联动。

张巍：我这边的看法是这样的。在 AI 应用中，假设你有 RAG，他可能写小作文的生成能力非常强。但是你让他去查个数，可能并没有你想的那么准。所以我们要用指标这一层去简化计算任务，避免让模型直接编写复杂的 SQL 语句，而是通过调用相关指标的 API 去获取数据，这样大大提高查数的精准度。

滕永铮：我们现在主要集中在提示词和知识库的建设工作上。对目前的指标，基于指标平台进行了二次开发，做了一个新的平台，我们可以叫它知识库管理系统。在这个系统里边，我们补充了大量有助于模型推理的内容，有一部分是作为提示词直接指导模型，也有一部分是作为知识外挂提供额外参考。我们更多的是希望，让整个模型实现能力内化与知识外挂的这么一种方式，在我们输入错误信息时，可以及时纠正，从而更好地满足业务需求。

Q2：各位老师好，我这边有三个问题想要咨询一下。第一个问题就是刚刚韩旭老师，已经跟我们分享过了指标平台和 Quick BI 的深度结合。但是我想在座的各位嘉宾应该除了 Quick BI 以外，有使用其他的一些 BI 工具。所以我想问一下，目前是怎么和指标平台进行一个深度的结合？第二个问题，我是想咨询一下，在指标平台里面，有一些指标是难以进行定义的，那么针对这种情况我们是怎么样做管控的？第三个问题，是想要咨询一下指标平台里的大模型，怎么和我们公有云上的大模型进行一个深度的融合？

陈润红：我觉得三个问题都提的很好很专业，那我就先回答第一个问题，剩下两个问题交给其他几位老师。在我们在企业内部，由于历史原因，会有一些存量的 BI 工具，那如何和指标平台结合，我们分两个视角去看。在应用场景上，对于增量部分，我觉得指标平台更多是去嵌入到各个系统的一个服务的调用之中，包括手机端的调用，甚至是一些 IoT 设备的调用上。这些其实跟 BI 工具并没有关系，但随着更广泛的应用场景的覆盖，指标平台就会形成“农村包围城市”的趋势，把 BI 工具给包围，这是第一个思路。

第二个思路是对于一些存量报告。刚才也提到一些治理命题。随着业务需求增多，往往一个企业的指标口径是会变动的，那变动则意味着原有的一些报表需要推翻重建，而这就是一个时机，你可以重建这个指标，以及考虑工具的升级迭代，这是个非常好的一个时机。

倪程伟：那我就回答一下第二个问题。我觉得 Aloudata CAN 指标平台的定义能力，已经能够覆盖相对比较广的指标语义表达了，大部分都能够在指标平台上定义出来。当然，确实有一些业务逻辑比较复杂，我们就可能会拉着 Aloudata 团队一起分析，尝试通过其他方式去解决。如果实在没有办法实现出来的话，可能就会涉及到一些预计算。这样的话，我们就需要将预计算的任务进行有效管控。

张巍：对第三个问题我想是这样的，就是说如果想用 AI 来实现一些场景，以及跟指标中台如何集成，要考虑两点。第一点就是如果是用 API 的方式，就要考虑数据会不会泄露。这个可能跟每家公司的安全团队或者合规团队需要有一个共识（Alignment），这块很重要。因为现在很多 AI 应用可能会把数据传出去，使用 API 的话安全上会有很多风险。

第二点就是需要看你希望达成什么样的效果。因为如果是让 AI 写小作文，肯定是用越大的模型越好。但是如果是针对用数需求，返回的结果是要更准确的，可能不一定需要依赖大型的外部模型，更多还是出于安全考虑，能够本地部署就本地部署，要么自己买 GPU，要么部署在自己的服务器上，这样会更安全，而且能够更容易地满足企业安全、合规以及内部业务团队对方案可靠性的要求。

滕永铮：你是不是还有第四个问题？（哈哈）我补充一下第一个问题吧。最近我们在对接外采的 BI 工具时也遇到了一些痛点，上周正在与芳雪（杜雪芳）团队讨论相关的问题。今天我们看到 Quick BI 已经与 Aloudata CAN 完成对接，通过 DSL 协议实现上下游的连接，所以这个给了我们一些启发，为外采的 BI 工具结合提供了新的方向。

杜雪芳：我也补充一下。今天，我们的指标平台和 Quick BI 实现了结合，并与理想汽车探索更多合作机会，这标志着我们在 BI 工具对接方面迈出了重要的第一步。所以，我们希望与更多 BI 厂商开展更深度的合作，以帮助更多客户进一步优化指标管理和智能分析能力。第二个问题，就是刚刚平安证券倪老师也提到，在落地实践过程当中，我们希望 99% 的指标，都能在指标平台上直接定义。就像我们在产品介绍里面讲到，强大的指标定义能力是我们产品的一个核心优势，并且我们会持续优化。所以，我们相信在指标平台上，绝大多数指标都能完成定义，而无需返回到数仓中再去加工处理，这是指标平台的价值履约的一个重要前提。

Q3：各位老师好，刚刚在分享过程中有听到老师提到自动物化编排，就想请教下各位老师，在引入指标平台过程中，是如何考虑物化加速 的？有做一些优化措施吗？

倪程伟：我觉得物化是一个很重要的能力。因为物化可以通过系统化的方式管理或者说简化 ETL 流程，当然，NoETL 并不是说完全摒弃 ETL，而是以更高效、自动化的方式进行管理。这种做法有几个优势：一、通过物化，ETL 流程变得更加可控，数据血缘关系清晰可追溯；二、系统化的管理方式能够提高 ETL 流程的稳定性，减少因手动操作或复杂流程导致的错误；三、也就是刚刚宁至（肖裕洪）提到的，基于物化能力，有助于智能化的建设，因为元数据都可以被有效管理和获取，及时掌控数据的运行时间、运行状态等信息，为进一步分析和优化提供了更多空间。但在这种背景下，如何合理拆分 ETL 任务，怎么把它拆分的更好、更稳定，这个可能是需要不断的去优化的一个目标。

杜雪芳：我补充一下。与传统 ETL 不同，传统 ETL 中的 ADS 表之间通常是没有关联关系的，而我们的物化能力则具备物化加速上卷的功能。另外我们也在规划一些新的功能，例如智能物化加速策略的推荐，可以根据用户的查询行为，对于频繁使用的指标和维度组合，或者是在查询性能较慢的场景，自动化建议物化加速方案。

Q4：我想请教下各位老师，在指标平台选型过程当中，我们发现指标平台跟数仓有一些功能重叠。所以想了解下关于指标平台跟数仓，两个平台之间的衔接以及定位问题。

杜雪芳：从我们产品理念上来讲，我们希望通过 NoETL 的方式，实现指标的“管研用”一体化，打造轻量化的数据仓库，也就是“做轻数仓”。但这并不是说完全不需要数仓，而是将原来数仓中经常根据业务需求灵活变化的集市层的功能，转移到指标平台上进行自动化开发和统一管理。前面陈老师和倪老师分享的时候也讲到，很多我们的数仓集市层，都逐步的不需要去做，而是更专注做好公共层资产的建设，做好我们的资产治理。

陈润红：我用两句话简单总结一下这两者的关系：第一句，让数仓更好地支持指标建设；第二句，让指标平台赋能数仓，让数仓的价值得到更好的发挥。

杜雪芳：由于时间问题，今天我们的研讨会到此结束。如果各位嘉宾还有什么问题，可以在我们的公众号留言，届时由我们的技术专家为您做详细解答。最后，再次感谢各位嘉宾的莅临。

来源：Aloudata大应科技