文章整理自陈润红演讲内容(陈润红|麦当劳中国数据中台负责人)
各位老师好,今天很高兴能与大家分享麦当劳中国在指标中台建设方面的经验。过去一年,我们与 Aloudata 合作,成功在餐饮行业落地了指标中台,并将其应用于多个实际业务场景。希望通过今天的交流,能为大家带来一些启发。
Part 1. 关于麦当劳中国麦当劳
自 1990 年进入中国市场以来,已有 35 年的历史。截至去年年底,我们在中国的门店数量已突破 6800 家,并以每年约 1000 家的速度增长。目前,中国已成为麦当劳全球第二大市场,也是增长最快的市场。我们的门店遍布全国 280 多个城市,拥有 20 万名员工,每年服务超过 13 亿次顾客。
麦当劳中国之所以能在全球市场中保持领先地位,得益于我们的经营理念。我们提出了“更强大、更美好、更智慧”这一愿景,具体体现在 4D 超级网络的建设(Development 新店拓展、Drive Thru 得来速、Delivery 麦乐送、Digital 全渠道触达)、用户价值的提升和企业运营效率的持续优化。
Part 2. 麦当劳中国指标中台实践回顾
随着各类数智应用快速落地,我们逐渐衍生出许多数据需求。每年新开门店数量都在增加,单纯的开店扩张并不能带来规模化的优势,如果不提升运营效率,企业的整体经营效益也难以显著提高。
因此,我们的首要任务是提升运营效率。其次,客户营销也是我们关注的重点。中国的移动互联网和移动支付发展成熟度很高,我们拥有多种下单渠道。如何通过这些渠道进行精准营销,以及如何在门店管理中实现因地制宜、因店制宜,都是我们面临的挑战。这些问题不仅摆在整个公司面前,更是数据团队需要深入思考的。
面对这些挑战,业务部门需要查看各种数据。然而,尽管我们过去建立了数仓并积累了上万张表,业务部门的体验并不好。他们面对数万张表,会很困惑,很难找到正确的数据来解决问题。同时,随着智能应用的快速发展,应用工程师经常需要调取特定指标,会找到数据研发沟通取数,但复杂的表结构和字段含义沟通起来也很耗时。此外,数据产品经理也面临巨大的压力,需要应对海量的指标需求,包括复杂而灵活多变的指标的定义、拼接和口径调整。研发团队同样面临挑战。面对数万张表,研发人员也难以理清已经积累的数据资产和口径定义。数据治理团队也在海量数据中挣扎,指标的定义、审核和消费权责与流程不够明确。每个角色都有强烈的痛点。
归纳起来,我们遇到的问题与急需的能力与 Aloudata 所总结的非常一致:
- 我们的核心需求是指标的统一管理能力。在指标管理方面,最大的需求是口径一致。我们需要通过标准化的指标定义和管理流程,确保口径的一致性。
- 其次,研发团队希望有一个高效开发的工作台,避免重复制作宽表,能够通过统一的语义配置快速实现指标,满足业务需求,并实现一次开发、多处复用。
- 对于应用工程师和数据分析师,他们需要一个灵活的分析工作台或看板,能够支持多维度的分析和任意粒度的下钻。这些能力在数字化转型背景下显得尤为重要,也是我们与 Aloudata 合作建设指标中台的初衷。
那么,整体的解决方案是怎样的呢?大家可以看左边的图示,这是我们之前基于宽表的建设模式。从 DWD层的事实表和维表出发,向上衍生出大量的宽事实表和宽维表,再进一步面对各种需求时,又生成更多的汇总表和更大的宽表。这种模式不仅带来了之前提到的各种角色所面临的痛点,还导致了数据重复存储、指标口径的不一致以及开发链路的冗长。此外,在消费这些指标时,由于数据通过多种方式(如实时、离线、接口等)推送,整个链路非常分散。几年下来,我们自己也搞不清楚有哪些地方在消费着我们的数据。
在与 Aloudata 深入探讨后,我们构建了如右边所示的“管研用一体化”的指标中台架构。通过统一指标口径,我们实现了数据资产的标准定义,并将其注入到指标工作台中。研发团队可以通过工作台定义标准化的原子指标、派生指标和复合指标。这里有一个关键点:许多公司在搭建指标平台时,可能主要将其作为 BI 看板的供数工具。但如果仅限于 BI 场景,许多消费场景无法统一,口径一致的问题依然无法解决。为了实现真正的口径一致,我们将指标平台真正中台化,形成统一的指标服务。
在最上层的消费层,无论是经营报表、核心业务系统,还是餐厅内的智能设备、移动端的管理驾驶舱等,我们都统一通过调用指标平台的 API 来获取数据。这种设计真正实现了指标的统一定义和一次定义、多次复用。这是我们与 Aloudata 共同建设的指标中台的整体架构。
总结来说,我们从“管、研、用”三个方向来构建了指标中台的能力。在指标管理方面,我们实现了命名规范、上下线审批、权限控制和版本变更的标准化管理,确保指标的一致性和可追溯性。在研发方面,我们为研发团队提供了标准化的工作台,支持快速配置指标语义和物化加速方案,显著提升了开发效率。在使用方面,我们提供了指标目录、归因分析、指标预警、指标 API 服务以及指标分析看板等功能,全面赋能后端各类业务应用场景,满足多样化的数据需求。实现了更标准的指标管理、更高效的指标研发和更智能的数据分析。
此外,我们借助建设指标中台的契机,建立了多角色协同的工作流程。主要参与的角色包括业务用户、数据产品经理、数据研发和数据测试,他们各司其职,每个角色都与指标平台有相应的功能对接点,共同协作构建我们的指标体系。
以具体流程为例,业务用户提出需求后,数据产品经理负责定义指标和维度;数据研发则配置指标的语义,明确数据来源并生成相应的 API;数据测试根据不同的应用场景进行测试验证;最后,业务用户通过指标平台的数据分析功能校验数据。这套流程经过一年的运行,已经非常顺畅。
仅有研发能力还不够,我们还需要在运维保障层面进行确保指标中台的稳定运行。我们从系统层、应用层和内容层三个层面入手。
- 在系统层,我们关注底层基础设施的稳定性,包括机器 CPU、内存负载的监控,以及 OLAP 引擎性能和网关的监控,确保底层资源的健康运行。
- 在应用层,我们重点监控指标服务的状态,涵盖服务负载、应用存活情况、接口存活情况和调用链路等,确保服务的高可用性。
- 在内容层,我们采用的是多平台协作的模式。一方面,指标平台负责监控指标值的波动,设置阈值预警;另一方面,我们通过统一的数据服务平台实现服务的熔断和限流,以应对高并发或流量洪峰场景,确保系统平稳运行。此外,我们还搭建了数据研发平台,负责对表和字段进行稽核监控,确保数据质量。
通过这三层的分层监控以及多平台的协同合作,我们能够基本保障指标中台在日常业务需求中的平稳运行。
Part 3. 场景应用
在介绍具体场景之前,我们先总结下指标中台的落地效果。
首先是指标资产的构建。在指标中台上线后,我们马不停蹄地启动了数据指标的沉淀工作。结合麦当劳中国业务的各个环节,我们沉淀、思考、抽象、总结出 8 大主题,已经积累了近千个指标,并广泛应用于各个业务场景。其次看研发层面。首先是响应时效,我们通过测试发现,90% 的 API 响应时间在 1 秒以内,95% 在 3 秒以内,99% 在 5 秒以内。超过 5 秒的场景主要涉及数据量极大的实时查询。作为中台化服务,指标平台支撑了众多业务系统的调用,目前每天的调用量已达上百万次,并且还在持续增长,预计很快将翻倍。此外,指标平台显著提升了研发效率。
过去,基于宽表的开发模式通常需要两周甚至更长时间才能交付需求。而现在,简单的调整当天即可完成,新建指标也只需几天就能完成从 0 到 1 的构建和测试。在稳定性方面,我们实现了 99.99% 的服务质量保障。基于这些底层保障,指标平台被广泛应用于餐厅业绩监控、服务质量监控、员工培训考核、管理决策归因分析、员工 KPI 考核以及门店用电量、用油量等运营优化场景。接下来,我将分板块详细介绍这些在餐饮行业的具体应用场景。
第一个场景是餐厅运营。
在餐厅运营中, 指标中台整合了人、货、场的数据,作为餐厅运营的智能大脑,驱动业绩增长、运营降本和服务改善。比如,我们的餐厅配备了众多物联网(IoT)设备,这些设备实时采集各类信息,例如用电量、温度、油耗以及煎炉的启停状态等。这些数据都被智能化的物联网设备捕捉并记录下来。基于这些数据,我们开发了多种应用。例如,通过分析智能设备采集的用电量和用油量数据,我们可以识别出成本节省的机会,比如在不必要的时候开启空调或更换油料,或者发现用油过量的情况。
此外,员工管理也是餐厅运营的关键。例如,我们需要根据餐厅在不同时段的客流量合理安排员工数量。店长和员工都有各自的销售业绩 KPI,同时员工还需要完成日常的技能培训。通过数据监控,我们可以帮助员工实时了解绩效达成情况和培训完成进度,从而优化管理效率。
我们还会实时追踪餐厅的出餐速度、服务质量等关键指标,并通过发放问卷等方式收集更多数据。这些数据经过整合后,生成各类指标,并通过看板、API 服务等形式,推送到各类设备上,包括手机端的管理驾驶舱。此外,我们还会将监控预警信息推送到门店的智能化设备上,实时监控服务速度和质量,从而驱动企业内部员工管理和服务效率的持续优化。
第二个场景是营销增长。
接下来,我们来看下在餐饮行业很重要的营销增长这个场景中,指标中台扮演了怎样的角色。通常,我们在启动一场营销活动时,会遵循 PDCA 循环,即从计划制定、策略执行、过程监控到策略复盘。这一过程中,需要监控的指标非常多,例如营销目标、物料投放量、员工配置等。
过去,这些指标通常由多个部门分别负责,各自建立报表。供应链部门关注物料准备,运营部门负责员工调配,管理层则通过移动驾驶舱查看数据。然而,由于数据源和计算逻辑不一致,常常在营销活动进行到一半时,发现各部门的数据对不上,导致决策混乱。指标中台的落地解决了这一问题,它成为营销增长中的统一监控仪表盘。通过为各部门提供一致的指标查询服务,指标中台确保了公司内部的决策思路一致,从而驱动营销活动从准备、执行、监控到复盘的全流程高效协作。可以说,在营销增长场景中,指标中台是一个不可或缺的工具,为跨部门协作提供了强有力的支持。
第三个场景是管理决策。
最后,我们来谈谈每个公司都会涉及的管理决策场景。在传统模式下,我们通常依赖各种宽表和报告来支持决策。然而,当业绩不达标时,各部门往往会各自分析,临时取数或查看定制报表,缺乏统一的思路和一致的数据。这种临时性的分析通常匆忙且缺乏系统性,难以找到问题的核心。指标平台为我们提供了同一指标从总部管理层到餐厅经理视角的逐层下钻、自动归因,解决了这一问题。通过将业务部门的归因思路标准化,并结合阈值监控和告警推送,我们不仅确保了指标的统一性,还实现了归因思路的一致性和可沉淀性。这一过程还推动了企业内部指标和维度的定义标准化,沉淀了数据资产,并规范了数据创建和消费的流程。可以说,指标平台在管理决策场景中,为企业提供了更高效、更系统的分析支持。
Part 4. 对未来的几点思考
在分享完餐饮行业的几个应用场景后,我想抛砖引玉,谈谈对指标中台未来的一些思考。
在企业数据治理的过程中,我们常常面临技术工具、组织架构和流程机制等多方面的问题。如何将这三者通过工具化、流程化和线上化的方式协同起来,是我们在思考和探索的一个方向。
我们认为指标中台在这一过程中可以发挥重要作用。它不仅提供了技术工具,还推动了流程机制的建立和完善。例如,指标的定义、审批、生产、消费以及权限控制等环节,无论是每个环节的权责角色还是流程规则都需要一个统一的工作台来管理,而指标平台正是这样一个工具。从我们的观察来看,指标中台至少在四个方面为企业治理赋能。
首先是标准治理。指标平台通过规范化的指标构建(如原子指标、派生指标和复合指标),逐步形成企业内部统一的 KPI 语言,避免了各部门“各说各话”的情况。
其次是质量治理。通过中心化的查询服务,指标平台确保了“数出一处”,减少了因数据不一致带来的管理决策风险和沟通成本。
第三是安全治理。在提供数据时,我们必须审慎管理每个人的数据权限。麦当劳中国拥有 20 万名员工,角色层级复杂,从高层管理者到部门负责人,再到餐厅经理和普通员工,每一层级需要访问的指标和数据粒度都不同。传统的做法是在不同系统中分别申请和控制权限,但这不仅导致重复建设,还难以保证一致性。通过建立统一的指标中台,并与员工管理系统对接,我们可以实现指标与岗位的动态匹配。当员工在系统中更新岗位信息时,系统会自动授予相应权限;一旦调岗,权限也会即时撤销。这种自动化机制确保了所有使用指标中台服务的下游应用都能实现动态的权限控制,既提高了效率,又保证了数据安全。
最后是成本治理。通过指标语义的构建,我们消除了大量无效或重复的宽表,减少了存储成本。同时,我们持续监控指标的使用情况,及时下线长期未使用的指标,既减少了管理干扰,也降低了运维成本。通过这四个方面的治理能力,指标中台与业务部门、数据研发部门和数据治理部门协同,形成了一个稳定的“三脚架”工作流。随着指标平台的推广,我相信它将有力推动企业整体数据治理的进程。
最后,我想分享一下关于指标中台与大模型结合的未来发展方向的思考。
目前,业界已经对此进行了一些研究。Chat BI,目前主要有两种流行的实现方式:一种是自然语言直接转换为 SQL(NLtoSQL),另一种是自然语言先转换为中间语义层,再转换为 SQL(NL to Semantic to SQL)。NLtoSQL 目前的研究表明,其准确率比较低,并且高度依赖于库表元数据的准确性和完整性,以及提示词的专业性。通常,业务部门很难提出足够精准的问题来生成完全准确的 SQL 查询。
此外,大模型虽然能够生成 SQL,但对数据量的感知不深,可能会生成性能较差的查询。再者,数据安全风险也是一个重要问题。如果所有人都通过 Chat2SQL 方式查询数据,权限控制将变得困难,容易导致数据越权和泄露。因此,NLtoSQL 可能更适合那些 SQL 能力较强的数据研发人员,用于提高效率。但对于数据技能较弱的业务人员,这种方式并不适合。为了让数据真正普惠,我们需要一种门槛较低、精准度较高的交互方式。在这种情况下,构建中间语义层可以有效减少对库表元数据精准度和规范度的依赖,以及对提示词专业性的要求。语义层的引入不仅解决了这些问题,还使得在大模型调用指标平台时,过程更容易复现和调试,从而优化性能。
此外,语义层还能更好地控制权限。通过指标平台构建数据语义层,可以大幅提升 Chat BI 的准确性,并在权限和性能方面进行优化。我个人预测,NL to Semantic to SQL 将成为未来 Chat BI 的主流方式。随着指标的丰富,即使业务人员提出的问题不够专业,也能通过自然语言传达给指标平台,实现精确查询。
以上是我今天分享的全部内容,谢谢大家。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。