快手指标中台系列 - 快手指标中台发展史及经验教训
导读： 快手数据平台在《2022 DataFun快手指标中台专场》论坛进行了指标中台领域的专题分享，论坛介绍了快手在指标中台领域的最佳技术实践。我们将该论坛分享内容整理成系列文章，本文是快手指标中台系列第一篇文章。
快手指标中台已经发展超过三年时间，经历了从单一指标元数据管理到全公司全业务的统一指标中台的演化过程，在公司得到全面的应用，真正实现了指标的“一处定义,多处使用”。本文重点介绍快手指标中台的发展历程、思考迭代、架构设计等经验。
主要包括以下内容：
- 01 快手以及快手大数据介绍
- 02 指标领域介绍
- 03 快手指标中台心路历程
- 04 快手指标中台系统建设
- 05 快手指标中台应用实战
- 06 QA环节
分享嘉宾｜刘一凡 快手 大数据服务负责人
编辑整理｜张建闯
出品社区｜快手、DataFun
01 快手及快手大数据
本章将一起重新认识下快手以及快手大数据技术。
快手是一个普惠的数字社区，其使命是提升每个人独特的幸福感。快手打造了短视频＋直播的平台，在平台之上构建了电商、招聘、本地生活等业务生态。
截止2022Q3，公开财报数据，快手有 平均日活3.63亿 ，平均月活是6.26亿的用户，用户体量和规模较大，同时整体业务保持着快速的增长。在业务增长的背后，是快手强大的技术支持，当然也包含快手数据平台的技术。
在快手内部，我们搭建了面向全公司的数据平台，使命： 提升数据决策效率，利用数据助力业绩提升。 最终目标是通过数据赋能业务，让数据产生价值。整体数据平台围绕 数据基建 +数据能力建设：
1、在数据基建方面，最底层是大数据存储和计算引擎，在之上有面向全链路的一站式的数据采集和开发管理工具，在工具之上我们把快手所有的数据全部都汇聚在大数据平台，再进行连接融通，形成一体化的数据仓库，通过引擎+工具+数仓就形成了数据平台的基建。
2、在数据能力方面，数据能力构建在数据基建之上，解决多场景的数据分析诉求，同时让数据真正产生价值。包括：分析决策的产品矩阵，解决在BI场景的分析的决策效率；实验分析产品，解决实验的分析决策场景；有价值的数据资产，让数据赋能业务。
数据平台有万级别的集群规模、EB级数据量、PB级日新增数据量，数据量是海量的，这也给快手数据平台的大数据技术带来巨大挑战。
为此，如果要构建面向全公司的指标中台，其一要解决业务的复杂性，其二需要持续提升面向海量数据的查询性能，因此对于指标中台的构建会面临较大挑战。
02 指标领域介绍
本章将一起认识指标领域，作为后续介绍的基础。
2.1 背景介绍
首先介绍下指标领域基础概念，让大家对于指标有初步的了解。
提到指标，对于非大数据领域同学可能会感觉比较陌生，其实指标一直伴随在我们日常工作中，可以通过以下案例说明：作为公司员工，我们会获取公司的 近7日按日期分城市的活跃用户数以及同环比。
从指标领域的视角，这个需求可以拆解为：
- 近7日：时间范围
- 日期和城市：维度
- 活跃用户数：指标
- 同环比：算子
根据以上例子，可以给出几个关键术语的定义：
- 指标定义：是对业务的一个度量，用来衡量我们的业务做的好不好；
- 维度定义：是观测指标的视角，例如是从日期的视角看还是从城市的视角看；
- 算子：是对于指标/维度二次计算处理，不涉及对指标维度口径定义改变。例如同环比是算子，有人会认为这也是一个指标，但在我们来看同环比其实是对指标做的二次计算，因此是算子。
至此，我们对指标/维度概念有初步的理解。那么为什么在大数据建设中，对于指标体系的建设尤其重要呢？对此有三方面的理解：
1、指标是在物理技术之上构建的语义抽象层，即实现了数据从物理层->语义层的转变，对数据进行了更高维度的抽象。通常情况下，技术同学在日常对接时，会通过hive表、ES索引等，这些都是底层的物理技术。而有了指标语义层之后，就可以上升到指标维度视角，从而屏蔽底层技术差异；
2、指标可以统一口径。例如：张三说要用户数，李四说要DAU，术语不统一，就会造成两人口径不能对齐。但有了指标的统一定义后，活跃用户数就是日活，后续的对接就可以用统一的术语去沟通，从而统一数据口径；
3、指标是分析领域的数据表达。例如：要分析业务好不好，活动效果怎么样，其实就是要看指标情况怎么样。我们会在BI层面构建报表和看板，同时也会构建数仓，指标存在数仓DWS之上的这些层次中。因此指标在数据全链路都会存在。
所以指标体系会在整个大数据体系中起着呈上启下，贯穿全链路的至关重要作用。换句话****说，基于指标体系，可构建大数据统一语义层，并实现数据口径统一，打通数据全链路。
2.2 大数据领域两大难题
在大数据领域，通常会面临两大难题，让我们一一道来：
难题1 数据不一致（质量） ：通过烟囱式的数仓、指标以及数据服务，形成一系列的数据烟囱孤岛，各数据孤岛之间数据不互通，导致口径不一致，进而影响企业决策的正确性；
难题2 分析效率低（效率） ：通过人工支持各类数据分析需求，需求会经历：提需求、排期、对口径、数据开发、数据验证、最后交付 六个环节，整个交付周期非常长，导致分析效率低，进而导致企业决策效率低下。
2.3 解决大数据领域两大难题 - 企业级别指标中台
为了解决以上面临的领域两大难题，结合指标体系的价值所在，因此我们 需要构建企业级别的指标中台OneMetric 。
在指标中台中，可以统一管理指标的口径定义以及指标的计算逻辑，通过指标的元信息，驱动整体大数据链路：
- 向下驱动数据生产，可自动化生成DWS/TOPIC的聚合表，也就是业界在提的一些NoETL思路；
- 向上驱动数据分析，可提供提供统一化的数据服务能力OneService，统一消费端指标口径，虽然数据会被丰富多样化的下游应用消费，但是由于都来自于OneService，所以其数据口径会保持统一。
总结来看，指标中台能够做到：
- 高质量的数据服务，以统一OneService实现消费指标统一口径；
- 高效率的分析决策：通过指标的自动化，可以实现数据分析自动化支持；
- 低成本的资源消耗：通过统一的口径，实现数据之间连接、复用，降低大数据的成本。
2.4 如何构建企业级别指标中台
那么如何构建企业级的指标中台呢，先介绍近年来行业内的一些相关趋势：
- Headless BI：将BI的指标服务部分进行抽离，并平台化，让指标只需要定义一次，可以在所有应用使用；
- 低代码：通过可视化拖拉拽的形式，构建数据应用平台，无需开发代码可构建数据应用；
- 智能建模：通过历史的查询日志以及表的元信息抽取，智能构建数据关系。
这些趋势为企业级指标中台的搭建提供了较好的指引，例如做统一化的服务，引入低代码思想等。为此行业对于指标中台的解决方案有两种：
| 实现方案 | 复杂度 | 优点 | 缺点 |
|---|---|---|---|
| 方案一：通过构建指标中台来驱动生产链路：基于指标元信息定义，设计聚合表模型；基于设计自动化加工聚合表 | 实现复杂度中等 | 落地比较彻底，从源头就控制数据的生产 | 通常会实现不够灵活，如果业务比较复杂，不能支持所有业务场景 |
| 方案二：通过构建指标来驱动分析链路：数仓已经构建好了，接下来构建指标中台，再把数仓接入到指标中台，通过指标中台提供统一化的服务 | 实现复杂度较高 | 数仓不会受到限制，可以支持很灵活的场景 | 质量保障不彻底，因为数仓是事后接入指标中台，质量保障会有风险 |
03 快手指标中台心路历程
本章将分享快手指标中台过去发展的心路历程，其中有不少经验教训可以作为大家后续规划的参考。
3.1 快手指标中台发展史
快手用5年建设了面向全公司的指标中台，整体分成4个阶段：
- 探索阶段 ：早在18年，当时属于摸着石头过河的阶段，探索了一些方向，但最终还是没有找到一个符合领域发展以及适合快手的方向；
- 面向分析建设阶段 ：随着快手的业务高速发展，对数据的要求越来越高，数据领域的两大难题暴露越来越明显，所以在20年开始面向分析打造了指标管理和指标服务，并与BI平台全面打通；
- 全面推广阶段 ：指标中台初成，开始在公司范围全面推广，推动全公司数据内容全面接入指标中台，并得到了全面使用；
- 面向生产建设阶段 ：AB问题开始凸显，AB有特殊性但是其场景也比较固化，会基于一些原始数据加工聚合数据（需要关联AB分流表）。早期的模式，通过DE开发AB指标，研发效率非常低。基于指标中台，期望能做到AB指标的自动化生产。
3.2 快手指标中台探索阶段
大家说需要做指标中台，我们就搭建了指标中台web产品，管理指标的元信息。存在的问题是没有把产品和生产链路、分析链路进行打通，这样我们管理的元信没有产生很大的价值，没有价值就没有动力管好，也没有动力使用，所这个结果可想而知。
当时也发现了这个问题，所以开始探索第二阶段，希望根据指标自动化的加工数据，并提供统一化的服务，建设思路整体是符合第一章介绍业界方案。但仍然得到大范围的使用，原因主要是当时数仓已经初步成型了，没有很强的意愿去使用。
总结经验教训，我认为有两点值得大家参考：
- 指标管理不能只维护信息，要利用这些有价值的元信息去驱动数据链路；
- 对于数仓比较成型的公司，更适合去面向分析去建设。
3.3 快手指标中台面向分析建设阶段
经过以上的层层铺垫，我们终于找到了一条适应快手发展的指标中台建设道路：快手数仓成熟，业务复杂，所以需要从面向分析建设指标中台开始，即向上驱动消费。
分析场景会很多产品满足不同的分析场景，在没有指标中台时，每个产品背后都会构建一套查询服务，会有以下几个问题：
- 烟囱式服务，case by case的建设服务端，重复建设严重；
- 口径不一致：烟囱之间会存在指标口径不一致的问题，导致数据质量故障；
- 人工分析：BI大量依赖DA人工的支持各种分析需求，人力得不到释放，也是业务发展的瓶颈。
为了解决这些问题，我们在数据之上构建了统一的指标管理，再把统一的指标管理和统一的指标服务进行打通，通过指标服务对外提供统一服务OneService，实现数据管理驱动服务，一处变更，全局生效。
3.4 快手指标中台面向分析建设阶段
快手指标中台整体思路先解决分析的问题，再解决生产的问题，所以快手的指标中台道路继续延伸：基于指标中台，大家指标自动化生产平台，即向下驱动消费。
通常在大数据领域，有两个比较大的数据链路：一个是AB链路，另外就是分析链路。早期在快手的现状是：AB会有自己的指标管理，会通过人工的配置指标生产任务，做AB的指标加工，再基于AB的服务提供AB的分析能力。存在的问题：
- 首先可以看到AB链路和分析链路指标管理不统一，两边都有各自的指标管理；
- AB数据生产偏人工，数据生产效率会比较低，可能成为瓶颈；
- 部分服务不统一，AB有一套自己的链路。
所以，22年我们基于统一的指标管理之上，搭建了统一指标生产的服务，基于指标维度进行AB的指标生产，整体理念是 基于指标中台可以做到指标低代码生产（无需人工开发），而通过用户的行为数据，可以做到指标自动化，即通过消费驱动生产。 所以AB有生产推导模块，推导出用户关注了哪些指标、维度，自动化调用生产做自动化的指标生产，最后通过对外的统一指标服务对接上面的AB和分析链路，做到分析和AB链路的全面打通。
未来，希望将指标自动化进行全面的拓展到分析领域，进而做到AB与分析统一数据源头，统一分析出口，数据全面归一。
3.5 快手指标中台经验教训总结
最后总结，要搭建一个企业级的指标中台，需要从三个视角去考虑：
- 组织层面，搭建企业级的指标中台，组织非常重要，组织需要把相关团队粘在一起，对齐目标，拉齐推进节奏。因为其实指标中台牵扯到面非常广，涉及到几乎所有的引擎、工具、数据团队，需要大家齐力共建才能造成一个完整的指标中台。同时还需要建抓手，通过抓手把指标中台用起来；
- 规范层面，要让指标可持续的产生价值，有一个基本盘很重要，就是指标管理高质量、不混乱、不泛滥。所以就需要有流程规范来指导和管理指标，让大家持续的维护好我们指标中台管理的内容；
- 工具层面，不能把规范落到纸上，要沉淀到工具里面，约束大家。同时，也可以通过不断完善工具，将我们大数据生产力解放出来，让大家做更有价值的事情。
从这三个视角就能三位一体的做好企业级别指标中台。
04 快手指标中台系统建设
本章将详细介绍，快手指标中台系统如何设计。
4.1 快手指标领域标准
首先在搭建系统之前，对于领域抽象很重要，我们定义了面向指标领域的统一开放标准。
在标准中，数据分成了4层，实现了数据从物理层到语义层的转变。
1. 数据源 ，直接会和各个物理世界对标，一个Mysql 表，一个ES 索引我们可以笼统成为它是数据源；
2. 数据表 ，数据源到数据表可以做一些逻辑化的处理，包括schema化等，这样就能把所有的数据源都对应到数据表这个实体上；
3. 数据模型 ，数据表与数据表之间形成关系成为数据模型，也就是业界提的数据语义。数据生产以及数据分析，是强需要表与表之间形成数据关系，非常有价值；
4. 数据集 ，数据模型或者指标维度的集合形成数据集。从提供统一化的数据服务视角，可能会存在多模型的联合查询，就需要有更高维的实体去承载，所以我们抽象数据集，通过数据集对外提供Headless BI的能力。
4.2 快手指标中台全景
基于指标开放标准，构建了快手的指标中台。在标准之上，搭建了统一的指标管理，管理这些口径定义的元信息，在之上搭建统一的语言体系，基于以上基础能力打造了面向指标分析的全链路的产品，以及面向指标生产的全链路的产品。
对于指标分析，构建了数据建模，在建模之上构建了统一的指标服务，提供统一化的指标服务能力，最上层是提供应用场景的指标视角产品，例如与BI分析全面打通，基于指标视角的归因，以及指标的一些查询，满足指标的分析场景。
对于指标生产，构建了面相指标生产的数据建模，搭建统一的指标生产服务，构建指标生产的能力。
同时基于指标的视角，构建指标的全链路保障能力，原来都是物理（Hive表等）的视角保障，有指标中台后，需要从指标的视角去构建这些保障能力。
4.3 快手指标中台分析侧技术方案
指标分析侧在数据源层之上，构建了数据服务层。首先构建了统一的查询引擎Octo，解决跨引擎的查询计算，以及分布式计算的能力；其次，在Octo之上搭建了语义层，指标中台与数据建模去构建指标模型；在此基础上，构建了统一化的数据集服务（Headless BI服务），通过数据集提供数据集+指标+维度的服务化能力，数据应用产品全都对接数据集服务获取数据，在数据服务里面抽象了统一的开放的分析语言OAX（后续系列文章会介绍）。
整体来看快手的指标中台在分析侧有3个特点
- 指标中台+BI形成了快手的特色BI，后续系列文章会介绍；
- 指标中台+低代码，通过这种方式高效的建设垂直的应用产品，形成了快手的数据应用工厂，后续系列文章会介绍；
- 指标中台+开放API，形成快手的Headless BI的开放生态。
4.4 快手指标中台生产侧技术方案
基于统一指标管理构建了统一的生产服务，它向上提供基于指标维度视角的生产能力，会把生产需求转化成物理的生产任务，交给底层的任务编排服务发起调度执行，这里会有生产任务的优化，比如性能、效率、资源层面等。
在生产体系，目标是希望支持会有自动化和手动生产两大场景：
- 自动化会生产：结合BI场景和AB场景识别出哪些数据是有价值或高热度的查询，会自动推导出要自动化生产的数据；
- 手动生产：数据建模即手工的生产服务，可以基于指标的维度去设计模型，然后去做生产，这块是一个还在规划当中的能力。
05 快手指标中台应用实战
本章将简单介绍，我们如何使用快手指标中台，让其发挥价值。
指标中台把整个数据分成了两大角色，以数据集作为载体，大家通过数据集进行对接：
- 数据生产方：只需要构建数据分析的元数据，构建数仓，接入到指标中台，构建数据集的矩阵，最终以数据集作为需求的交付物；
- 数据分析方：拿到数据集，可以做BI分析，同时也可以直接通过OAX对接外部的运营系统来获取数据。
快手指标中台经过几年的发展，做到了分析端的全面覆盖，数据生产端也开始实践：
- 质量：没有重大质量故障
- 效率：10倍以上的效率提升
- 成本：会有极大的复用度的提升
- 指标管理：快手所有核心业务线全部接入到指标中台，目前指标数3w+
- 指标消费：应用数30+，查询次数每天有300w次的查询
- 指标生产：当前也在解决AB指标的生产效率问题，目前接入的指标有300+
以上就是快手指标中台建设思路和怎样用好指标中台，接下来也欢迎大家做技术交流。
06 QA环节
Q：指标中台听起来是一个BI分析里的共性需求，现在有哪些开放的指标中台的类似的产品可以使用？
A：国内：kyligence的zen，国外：Qlik，同时现在有部分BI厂商逐步也开始在做指标中台。目前相关成熟的产品并不多，但是大范围用起来较少。
Q：指标中台从数据收集到最后的指标展示路径非常长，虽然统一指标口径了，但是统一的指标口径不一定能满足每一个业务的需求，比如业务方有新的需求，那我们又要从数据收集清洗做起，这样还是case by case的解决，这个是怎么解决的？
A：指标中台并不能完全替代数仓，无法做到从埋点到最后展现的全自动化。所以底层的数据我们需要按照数仓要求清洗好，接下来就利用指标中台去提供服务。
对于一致性的问题：刚刚提到了两个方式：
- 第一是定义指标，基于指标生产，这样可以很彻底定义整个生产链路，能达到很理想的一致，但场景有限，从生产去做的话，有些场景可能过于复杂，并不能描述出来；
- 第二是从分析场景构建，先构建到数仓，再接入指标中台，指标中台提供一致性的保障。在快手会在几个卡点去保障，元数据层面把控定义的指标唯一性；数据层面校验上游数据源同一指标的一致性；服务需要对接指标中台的数据服务保证统一性；核心指标做事后多链路检测，确保事后一致。
对于不能满足所有业务需求：公司的核心指标是相对确定的，一旦确定是非常严肃的，不能说变就变。部门的一些小指标，不排除有一些朝令夕改的指标，但是如果某些指标定义明确，也不会有频繁改动，也就做到了一处定义多处使用。
Q：指标如何与数仓打通？数仓中可能有多张表，可能都有相同指标，如何避免歧义？
A：事后会把指标和数仓进行绑定，多张表会做一致性的验证，如果有多张表生产这个指标，则验证这几张表生产的指标的一致性。
Q：指标中台适合单独建设，还是作为各业务自己搭建？
A：指标中台最好是统一化的建设，本身就要统一指标口径，如果单独建设的话，能解决域内的一个问题，但要无法解决面向全公司指标口径的问题。所以需要统一化建设指标中台，统一化的对外提供数据服务，能够很好的避免数据的二义性。
Q：和业界同类的metric store的方案有啥异同？比如Airbnb，kylin、美团这些公司已经做了的方案。
A：大的思路都类似，Airbnb更强调指标生产，定义指标后自动化生成pipline，去生产数据，并提供统一的服务，相对来讲Airbnb做的比较全，生产和消费都有；kylin主要从多维分析的视角自动化的构建cube；美团更多从消费视角去建设。快手是更加全面的推进了指标中台建设，并且在全公司进行推广使用，其实指标中台单部门建设都好建，但是要建统一的指标中台还是挺难的，前面也介绍了一些经验教训。
｜分享嘉宾｜
刘一凡
快手 大数据服务负责人
2020年加入快手，有大数据和搜索领域实战经验，过去主导过美团、快手多个大数据相关领域系统从0到1的建设。持续深耕大数据中台领域，保持对大数据开源技术以及发展趋势的高度关注。
