快手数据治理的那些事

数据治理是企业实现数字战略的基础，在数据治理实际落地过程中，我们常常会遇到很多挑战和困难，就在刚过去的 2 月 23 日，InfoQ 邀约了 ArchSummit 全球架构师峰会（北京站）数据治理专题出品人徐波，通过直播的方式，为大家分享快手数据治理的一些经验与方法，本文为直播分享整理，期待对你有所启发。

编辑：李忠良

嘉宾：徐波

InfoQ：快手数据治理会有哪些挑战？

徐波：快手的数据挑战包含两方面。

一方面是大多数企业都会遇到的一些通用性挑战。例如组织协调意愿度，链路长等等问题，当然，数据治理肯定会涉及一些方法。这些数据治理的方法是否正确？数据治理的结果是否可衡量？大家是否有一个比较好的系统来承载治理的目标？等等都是要面对的难题。另外一方面是快手相对有特色的挑战——数据量非常大，快手的数据量每天可能有接近万亿级的数据。

不过快手的数据治理有一个明显的优势，那就是我们的数据团队是一个中心化的组织，所以比较容易推动数据的治理。

InfoQ：上述的可衡量以及中心化组织是指？

徐波：可衡量是指治理肯定都会有目标，打个比方，我们想做数据质量的治理，最核心的目标可能是故障的 Case 数量，采用了很多的方法，故障依然很多，这可能就不是一个好的方法。其他的一些指标，比如数据质量的二级拆解可能也有一些其他的指标，比如模型规范等等。

关于中心化的组织是这样的，快手的所有的数据团队是一个团队，这样的组织形态就会有比较强的组织保障，协同效率会比较高。很多公司的治理团队是“一号位”的工程，执行团队可能有一个中心化的规范设计和监督治理团队，具体的执行落地肯定是相对分散在各数据子团队，抓手相对较弱，效率不高。

InfoQ：快手的数据治理，您认为有哪些着手点？

徐波：快手数据治理的核心是数据质量治理，其次快手的数据量非常大，其存储与计算的成本会比较高，成本的治理也是一个着手点。然后再延伸一点，就是数据的采集，大家经常会说数据质量是业务的天花板，那数据治理天花板是什么？我认为是数据的采集，也就是常说的埋点，埋点也是快手最核心需要治理的方向。

InfoQ：我听说很多做数据的伙伴们，一进公司总是进行数据梳理，这个原因是什么？是否有较好的方法做这些数据梳理工作？

徐波：是的，老板们常常可能认为数据质量不太好，让我们进行梳理数据质量或者数据指标。这里的原因有两方面，一方面，指标常常会随着业务线而变化，指标的新增会特别特别多，它是一个相对发散的东西，量大且变化快，这是一个容易出让我们经常出问题的地方。

另一方面，大家的指标的梳理可能仅仅是停留在定义层面，它可能没有打通定义、生产以及最终的消费，它是一个孤岛，这样指标就不会融入到大家的日常工作，容易与后面的生产与消费脱节，时间跨度拉长，花了很大的力气搞规整的指标，可能过一段时间又混乱了。

InfoQ：有什么好方法进行指标梳理？

徐波：第一个是指标变化很快，我们需要尽量地把这些不变的东西，让它缩小在一定的范围内可控，然后对于变化的东西，我们用一套不变的东西再加一些规则，让它产生出可变的东西。

例如，我们要做的第一件事是词根的管理，词根它是一个收敛、相对可控的东西。指标的命名以及分类必须有规范和方法。

我们通常会听到的原子指标、衍生指标、复合指标等等，通过词根加这个规则，它可以衍生出非常多的业务能看得懂的指标，所以我们只要把这个规则确定下来，共识好，就做好了指标梳理的第一步工作。

那么第二个是指标发散的规则，快手的指标是不允许人肉定义的，指标必须来自于词根的拼接，当然我们也有指标变更的流程，比如说某一个指标的变化需要同步谁，需要谁决策，需要在那个系统里使用，当我们有了这样的规则规范，可以使得指标相对长效地得到保障。

当第一步指标梳理之后，我们接下来可能进入数据开发环节，我们要求数据开发工作者将指标与字段绑定一个映射关系。这样我们就可以知道，这张表里面字段代表的是什么样的定义，同时这也意味着，指标的定义与生产打通。

接下来看我们如何与消费侧打通的？当第一阶段打通了之后，我们有了大量的元数据。在调用的时候，我们可能就能够通过业务的需求，比如需要要什么指标、什么维度、什么时间、什么样的过滤条件，把这些需求拆成五要素，然后会传递快手的数据的知识引擎，引擎会通过一系列的加工的和计算的过程，会从相应的元数据抓取业务需要的数据。

InfoQ：如何合理的规划数据，让开发的指标跟数据产生关联？怎么样判断关联是否是正确的？

徐波：关于数据的合理的规划，有些类似于数仓的建立。

在快手内部，我们需要想清楚业务线的指标粒度的矩阵。指标矩阵是指对于业务线来说，你应该有什么样的观察视角，你希望给别人看到，比如说创作者、城市。或者是商品、用户这样的颗粒度。我们要规划清楚颗粒度，以及基于颗粒度的观测指标。单就这一点来说，每个公司或者每一个数仓的设计师可能都会不太一样，需要根据对业务的理解以及过往经验作出判断。

关于如何判断关联是否正确？说白了就是校验的问题，比如某一个数据人员把昨日的收入跟上周日的收入都把它关联到昨日收入上去了，这个时候我们在校验系统会发现同样的指标，取值是不一样的，这个时候就需要核验是计算的错误还是绑定的错误，这个时候能够会被发现出来。

InfoQ：应用和指标关联后，如何让多个应用保持一致性，快手是怎么做到的？

徐波：我们采用的是 One service 架构。当指标与数据表关联之后，我们就会产生大量的元数据，上层的应用系统的查询指令过来之后，进入 One service 系统架构，它就会根据元信息动态地选择一条最优的路径找到对应的数据。我们的上层的应用系统都需要接入到这套体系，这样的情况下多个应用便可以保持一致性。

InfoQ：上面我们说到数据治理方法，还有什么是在数据质量上是关键路径？

数据是业务的天花板，对于快手来说，埋点就是数据的天花板。关于埋点，我们也投入了巨大的人力物力

最开始的时候组织没有那么大，大家做埋点的相对比较容易，但是后期分析师、数仓同学、产品经理同学都去设计一些埋点，尤其是当跨业务线的数据理解，定义埋点的人与消费买点的人不同的时候，或者是有人员变化的时候，这个时候就会遇到巨大的问题。

所以这里的第一个核心是需要埋点元数据规范做好，第一步是要把埋点的原数据管理起来，并且要有统一的埋点规范，当时我们在做这个事情的时候，可能当时会有两个选项，

第一个选项是说我们自上而下建一个产品，然后建一套规范，让我们当时做埋点的各种角色，各种业务线的人来统一遵循来去做。

这个选项的优势是说数据部门可能付出的人力的成本可能没成本没那么大。因为埋点工作，毕竟不是我们在做，是业务同学在做，可能做一个工具搞一个规范可能就结束了。

这一方案的缺点是最终的结果是不可控的，而且想要达到这个结果，它的沟通的成本可能时效周期会拉得会比较长。

第二个方案埋点的事情这么重要，现在是零落零散的落在各个地方在做，我们是不是可能组建一个团队，把这种零散的工作收敛过来。所以我们组建了一个小的团队——埋点小分队，这样做的好处是，可以快速地把规范和把元数据快速地收敛。它的缺点是，需要投入很大的人力成本，并且短期需要面临非常大的压力，因为原来这个矛盾是分散的，现在把这个数据都归结到一个团队，这就需要短期火力非常猛。

当时我们顶住了压力，选择采用第二套方案，目前看，效果还是非常的不错。

InfoQ：数据治理未来的方向，有没有什么统一的方法？

徐波：从我的角度出发，我觉得数据治理的未来，我觉得可能还是强调元数据，我觉得当你有了清晰的治理目标，或者说你只有先了解清楚你的目标以及链路流程当前的状态，你才有了一个治理的基础。另外一点是当有了一个基于这个目标的方法，然后不断地监控治理目标是否在往好的方向演进。

这可能是我这边会一直持续探索的方向，可能这并不局限于数据的成本或者质量的治理，我可能也会把它衍生出来，可能会对于团队的组织，甚是对于一些资源的投入，我都会可能会用元数据的方法来进行。

当然除去这些问题之外，在直播区，听众也发起了很多有意思的问题，这里整理了问题合集，你可以观看视频查找答案，期待对你有所启发~

听众互动问答：

• 什么是数据治理，能通俗易懂地讲讲吗？

• 数据治理是几套系统交叉校验吗？

• 数据湖跟原数据血缘如何分析？

• 快手数据治理组织架构是如何设计的？产品和如何设计的产品和研发团队如何协作？

• 如何处理很多没用的历史任务？

• 快手的各团队，是如何协助数据治理落地的？

• 数据治理有延伸到业务系统吗？还是说只在数仓中？

• 敏感数据分析如何做，业务和数据负责人的认知差异大，怎么解决？

• 数据的维度主要体现在数据分类吗？

• 数据治理的业务价值怎么体现？

• 数据治理的 KPI 怎么定？

• 快手数据治理使用哪些工具？

• 埋点体系可以用建设平台去做统一化强制处理吗？

嘉宾介绍：徐波，拥有十余年大数据建设与应用相关经验，于 2019 年加入快手，带领团队全面落地了数据生产、治理、分析、应用等数据中台产品，建设了快手全业务数据内容与服务体系。目前专注于使用元数据驱动数据生产、服务、治理的方向应用与探索。