B 站的数据治理运营框架实践「内有案例分享」

Original 高隆 DataFunSummit

导读本文介绍了 B 站的数据治理运营框架实践。

主要内容包括以下几个部分：

1. 概要

2. 分析工具介绍：DAMA-Bok

3. 案例 1：存储水位风险

4. 案例 2：数据丢失复盘

分享嘉宾｜高隆 Bilibili 数据仓库工程师

内容校对｜李瑶

出品社区｜DataFun

概要

我今天的分享题目是 B 站数据治理运营框架的实践。大家可能对数据治理这个概念会觉得有点熟悉又有点陌生。希望今天我们分享完之后，大家对数据治理这个概念有多一些的了解。

我的岗位是数据仓库工程师，就是俗称的表哥，日常工作有一大部分的工作就是制作数据表格。以前我制作的业务数据比较多，最近几年我主攻数据治理，制作的数据更多的和元数据有关。最近一两年，我的工作开展主要参考的是 DAMA-Bok（数据管理知识体系）相关的方法论。在 B 站我实践 DAMA 数据管理方法论，主要的工作方向有两大块，一块是数据的成本治理，另一块是数据质量。

我的分享分三个部分，首先会快速介绍一下 DAMA-bok 方法，它是一个在数据管理过程中遇到问题后会用到的分析工具。接下来我会通过两个案例做展开，向大家介绍我们所说的数据治理运营框架怎么去做，数据治理的概念具体包括什么等等。

02 分析工具介绍：DAMA-Bok

首先介绍我们所说的数据管理知识体系：数据管理知识体系 -- DAMA-Bok。简单来说它可以分成四个部分。

第一个部分我们叫它车轮图，由 11 个数据管理当中比较重要的知识概念组成的，中间就是我们所说的数据治理。

每个知识点展开之后，是第二张图，就是这个六边形图，描述了做一个知识领域，如果要做好，可能有七件事情需要考虑，每一个知识领域都是这样子。

如果对于一个知识领域再进一步展开，那叫做上下文语境关系图。描述了六边形当中的七件事情具体是哪些。比如我要做一些活动，我要发布一些规则，这些活动和规则它的输入是什么，输出是什么，遇到问题之后谁能提供支持，输出的一些交付物，谁会继续去用它做下一步的生产。在遇到问题的时候，有哪些工具和方法我们需要去考虑，以及怎么衡量做这件事情做得好还是坏的指标，整个数据管理工作过程当中会遇到非常多的问题，需要去讨论和抉择。

数据管理知识体系 DAMA 当中有一个很重要的概念叫十二原则，当我们遇到问题之后要做一个统一的决策，这个时候该用什么样的标准衡量决策的好坏？如果没有指标没有案例，那么这十二原则就会变成比较重要的参考依据。我们在去年实践数据成本治理的时候，有一个原则非常重要：数据的价值的体现一定要用经济术语表示，其实这个原则在很多的问题当中都多次被使用到。

03 案例 1：存储水位风险

第一个案例是在 2022 年 5 月 11 号的时候，B 站经历了一次存储水位的风险。简单介绍一下 B 站的离线存储，我们所有的数据在后台每天做分析之前会存到一个离线存储环境当中。目前 B 站的离线存储集群大小在 EB 级别。

在 2022 年以前，我们每年基本都会经历 2 到 3 次的存储风险。这次 22 年 5 月 11 号的时候，同样也是要像例行的要做的一件事情一样，从早上 5:00 到晚上 9:00 要联系好多人，然后参与去讨论数据能不能删。

不一样的是在 2022 年，B 站自上而下发起了降本增效的大目标，在这个目标的前提之下，所有部门和集群再也不能随便申请资源。同时 2022 年基础架构部门有一个机房迁移的项目，会在相当长的一段时间令我们的存储占用翻倍。

基于上面两个问题，我们在下半年的时候推进了很多的专项治理，包括比如说无效数据的一个集中清理，包括数据的格式压缩或者是数据文件的 EC 转换。这些工作过程当中帮我们沉淀多了非常多的元数据，以及和各部门协作沟通的一些沟通机制。

在第四季度的时候我们做了一些复盘，认为数据治理已经迎来了一个特别好的契机，应该要做点什么。在数据平台部的号召下，我们成立了数据委员会，约定通过沟通协商的方式定期去沉淀公司数据规范，检查数据管理目标达成情况。数委会成立之后，我们发布的第一条规则就是部门申请的资源如果超过上限，那么就禁止新增数据资产。其实这个事情过去每年都提，但是一直都没有一个载体去推进落实。

另外在年底的时候，我们上线了数据治理平台，在之前专项治理及收集到的元数据的一些沟通机制，以及数委会的建立，还有数据平台的上线，这些东西构成了我们后续在 2023 年推进数据治理的一个基本的组成的基建。在上图中能够看到 2023 年初，各部门资源超上限的情况基本全都消失了，并且 23 年全年我们的存储水位一直维持在一个很稳定的状态。

在 2022 年以前我们一直是基于一套资源容量风险紧急预案应对这类问题，现在我们来复盘一下，为什么这个紧急预案很难起到效果。

这个预案，它是根据存储水位共分为 4 层，从存储水位超过 90% 开始，这个阶段的方法是通知数管，要执行数据治理相关的工作。这个事情落实不到位的主要的一个原因就是因为组织是会发生变更的，而且它每年可能要发生 2 到 3 次较大的变更；如果资产归属的人员也发生变更，那么每年发生的情况会更加频繁。

当存储水位超 93% 的时候，我们来到了第二层。这时要求所有人删除他们的无效访问数据。这件事情落实不到位主要的原因是，执行这个操作只有风险，没有收益。设想一下，有一份数据，现在删除了明天就没有了，不知道明天要不要用；但如果我不删别人删了，那我其实什么也不需要做。当一件只有风险没有收益的事情，如果让很多人参与去做，本质上这件事情是很难驱动去完成的。

当存储水位超 97% 的时候，会根据部门的一个资源分配进行写入的限制，我们虽然有这条规则，在数据委员会启动的时候，重申的第一条规则就是它。但事实上从来没有这么执行过，因为如果没有征得数据业务方的同意，停止正在使用的数据生产，风险是极高的，即便我们观察到数据已经多日没有被使用。

现在我们基于刚才的问题，拆解一下解决方案。

首先对于组织变更这个问题，在 DAMA 里面有一个原则就是数据管理需要领导力的承诺。简单来说就是所有的数据管理规范要落地的话，都是要有自上而下的一个力量去驱动。因此如果要开展数据治理，它必须获得组织赋予的权利。构建一个虚拟组织是一个不错的选择，它可以让业务组织变更与数据归属变更这两个事情间留有一定的缓冲空间。我们选择的办法就是建立一个虚拟组织 -- 数据委员会，由这个组织承担这样的职责。同时我们约定了一个虚拟的最小原子资产归属组织 -- 资产空间。有了这样两个虚拟组织结构，通过设定管理规则，参与其中的角色就有一种驱动力将数据资产尽可能合理地分配在各个空间中进行管理。

第二个问题是限制数据写入的风险很高，这个规则主要违反了数据需要按生命周期进行管理的原则。一份数据从生产到产生价值，再到最后数据退役，不同周期需要关注的风险是不同的。通常数据在创建之初就进行管理，它的风险是最低的，在这个阶段需要嵌入数据需求的成本评估。在数据退役时进行管理风险最高，在这个阶段需要有一套数据冷却、降频、归档的清理流程。

刚才我们提到的数据退役没有执行驱动力，这个经常违背的原则是：数据价值要用经济术语表达。在实践中，开始的时候我们认为只要算出一份数据的成本就可以推进治理了，但这其实远远不够。我们把一份数据想象成一份资产，在这份资产的负债表中至少需要包括它的资产市值、供应链成本。这就需要我们用元数据描述出数据的血缘、数据在各终端的热度及场景、数据在整条供应链中各环节的成本。以上这些统计和计算都必须要有好的元数据才能实现，目前 B 站在和 Gravitino 项目团队合作，持续推进系统元数据的整合。

把刚才我们说到的所有的思路总结成一张图的话，我觉得可能是这样的：

首先第一部分是我们需要有一个组织，这个组织需要定期使用我们的元数据，公布上个月或者是上个季度数据治理执行情况怎么样，因为数据如果不被使用的话，它不会产生价值，也没有人会关心它的质量。另外就是在这个会议当中，我们主要会做一些资源的分配，资产的确权以及规则的一些变更讨论。

第二块的话就是我们刚才说到的数据在不同的生命周期当中，需要有嵌入式的流程进行管理。在以前不能执行的 Quota Limit 机制，是在应用数据阶段，显然它是没有办法实施的。但是如果把它移动到新增数据的话，这件事情是完全可以做到的。然后在冷却数据和清理数据的时候，我们嵌入了数据治理工作流程，并将这个流程进一步拆分成冷却和归档两个部分，降低执行风险，并向数据负责人推送确认。

第三块是元数据，为了持续运转数据委员会，以及治理流程，我们需要有一个元数据底座做支撑。对数据管理最重要的两个元数据，一个数据资产归属资源的分配，还有一个就是我们所说的数据的成本，数据的价值。

然后刚才说的三点我们展开讲一下；首先我们讨论一下组织。

前面提到对于一个企业来说，它的目标是为社会创造价值，运转企业流程。但是所有的工作开展过程当中一定会产生数据。所以数据治理、数据孤岛的问题是怎么产生的，就在于我们在运转业务过程当中，这个过程的组织结构和我们生产数据过程当中的组织结构，往往是不匹配的。比如在做某个业务的时候，两个衔接的部门可能分别要出各自的报表，但是在数据组织视角下他们用到的数据其实是一份数据，所以如果我们重新把组织想象成它是一个生产数据为目标的公司的话，那么它的结构可能就是这样的三层。

首先这里的底座，它的目标要解决 80% 到 85% 的问题，比如它可能有的一个职责就是确保所有的数据可以映射到公司的统一资产目录中，或者一份数据必须要有明确的属主。在中间这层是我们的数据委员会，主要解决规则的变更以及定期的数据晾晒问题。然后最上面还要放一层，解决工作开展过程当中可能会遇到的冲突。

数据委员会目前是按季度进行运转的，每个季度我们会发布目标，然后做上一个季度目标检查，同时每月我们会收集各个空间数管、部门数管在工作开展中遇到的问题，与各方进行协作沟通，看是改变产品功能还是改变规则。

这是我们在数据委员会发布的一些议题，供大家参考。这里很重要的一项要与各方约定规则红线，实际上所有的流程都是在有了明确的红线之后才能进行沟通和落实的。

第二部分，我们讨论嵌入式治理。

在 2022 年以前，我们没有月度沟通机制，当时做资源分配，基本上是年初做一次预算的规划，然后年终的时候和年底的时候会做资源分配。这件事情其实对所有的参与人来说都是非常有挑战的。我需要在 12 月的时候计划明年一整年需的资源，如果这个时候没有想明白需要开展的项目，可能就会有预算申请不足的问题，所以各方都有一种倾向是多报预算；但这块的评估不准确，势必会导致第二年的预算浪费。于是我们增加了数据委员会，明确了资产的归属，再加上我们的治理平台，我们现在每月可以做这样的一次检查。过去那些盘不清楚的资产，现在每月都可以知道到底有多少数据在下个月可以进行清理，这些预计可被清理的资产，现在也就变作了我们的备用资源。

我们的元数据的应用，它的首要应用就是资产账单。我们用元数据找到系统各个物理组件的分摊成本，描述出它被占用一段时间后需要花费的金额，再把这笔金额分摊到数据生产的归属方，这样就能描述出各方的数据生产成本了。

为了做出各方可信服的资产账单，一份好的基础元数据是不可或缺的。目前我们用的元数据可以通过右边这张图展示。

我们目前治理元数据的基础数据主题大概有 50 多个，除了刚才说的账单外，还支持了 14 个治理场景的数据应用。整个元数据模型包括了这样几个部分：

资源占用对象：它描述了一种资源最细粒度的资源占用；
资产对象：它描述了一份数据资产怎么关联到资产占用对象上的；
资源归属：它描述了一份资产对象是怎么归属到组织上的。

当我们要开展一个新的资产或者资源的治理的时候，套用元模型找到目前我们在系统当中能找到最好的一些原数据。如果能构造出这样的一个 ER 关系的话，我们就认为这件事情大概率是数据上是可行的。接下来去做一些数据质量的校验，然后做一些数据标准就可以了。

在 23 年开展数据成本治理工作过程中，我们发现数据质量的管理其实基本上也可以套用这个元模型。只要把我们的资源容量替换成一个质量的目标，把我们的资源的占用量替换成我们质量的一些风险的指标就可以基本上是无缝切换，所以今年我们来做的一些主要工作也是套用元模型去开展数据质量方面的治理。

有了刚才我们介绍的元模型作为基础数据，我们就可以在它的基础上进一步去加工指标和标签了。那么比如说我们说的一个无热度数据的治理策略，首先它就需要有热度数据，还有它的资产归属的一些数据。我们生成热度的标签，再加上资产的一些分类的标签，排除掉一些有风险的项。接着就可以把它作为治理问题推送给相关的人员实施治理了。

刚才讲到数据和标签，这里简单介绍一下我们对数据价值的一些看法。我们认为数据它如果能产生价值，它一定是能做到这样一件事情：人在看了数据之后能有行为；如果人看了数据之后，他没有行为的话，你可以认为做这份数据和不做这份数据是一样的，这份数据可能不需要做，或者说做这个数据可能没有价值。

那么从这个数据的产生到人能产生行为这条链路去看的话，你会发现我们收集到的数据，它应该是那种偏动词的数据。如果收集到的数据是动词的数据的话，我能看到不同时间段这些动作的变化趋势。我们对动作做一些分类之后，可以对这些数据进行指标化，标签化产生一个标准的名词和术语之后的话，一个团队里，各个成员都可以去理解这份数据，产生相同的一些行为，工作流程就可以在此基础上产生了。

为了让整个数据的价值的链条可以运转的更快，我们才需要去把数据治理好。比如说我们一直说的在数据管理当中要去做数据建模，很多人都不太理解是为什么。但如果你想要让更多的人去理解你的数据，让整个的数据的价值链可以转得更快的话，那么我们说的数据管理的 11 个知识领域可能都是要去实践的。

刚才说到的数据治理运营框架，我们快速过一下它。首先最重要的是包括了一个数据管理的组织 -- 数据委员会，它消费我们的元数据消除数据治理过程中的信息不对称性，同时也让元数据价值和质量得到提升。有了足够好的元数据之后，我们就可以描述数据资产对象，描述它的价值，描述它的成本和它的问题。通过治理平台我们发送治理策略，让更多的人参与处理治理问题。接着要解决治理问题，执行的驱动力问题我们可以在数委会定义红线，超过资源分配之后，通过嵌入组织的流程，要求某些行为必须要发生。当各方做了治理工作后，他会对做这件事的价值产生疑问，我们用资产账单告诉他，你今天花了多少时间为公司节省了多少钱，你做了这些事情之后，你的数据的价值翻倍了，用这种方式给他参与数据管理持续的动力。

再看整个运营框架，它好像还是静态的，它的运转也需要有一个驱动力。目前这种驱动力更多的是来源于业务目标、数据目标、技术目标、监管要求，另外来源于我们在运转整个治理运营框架中发现和收集到的数据问题。

案例 2：数据丢失复盘

第二个案例是数据丢失复盘，在B站我们做数据复盘主要是用 2 线 6 问这种方式。2 线分别是数据链和问题发生的时间线。数据链主要描述了数据是怎么从源头流到应用场景的，时间线主要是看问题到底是怎么产生的。

如果发生一个问题之后，我们从事后来看怎么样去把这个问题能够更好更快速的修复或不让它发生，我们定了 6 个问题，所有的数据开发过程当中发生的问题或者运营过程发生的问题，我们都会用这种方式去做分析，不断的完善我们刚才提到的 SLA、SLO 这样的一些指标。

在这个案例中，时间线最长的部分是问题的发现，我们的数据在数据同步入仓的后两天，发现表全空才发出的告警，那是不是发现有连续几个小时为空的话就可以发出告警呢？这个地方有优化空间。

再看这个问题它是一个组件问题，还是一个非偶发问题，这个组件是快退役的组件，它缺少很多元数据，缺少质量的 SLA、SLO，这些欠缺是需要组件进行补充的。

再来整理一下数据链，刚才提到一条数据链抽象起来的话，数据质量有 5 个维度，在不同的位置上应该有不同质量维度的检查，在复盘时根据这些质量维度进行检查和思考，就更容易发现数据质量问题了。

这里再介绍下 6 问，制作 6 问的目的是帮助我们在开复盘会的时候可以最后对问题的各项信息记录和各方做一次对齐，是数据开发操作问题还是数据组件问题？是否有质量 SLI、SLO 能描述问题以及问题的程度？问题属于数据质量的什么维度问题？监控设置是否到位？这些达成过共识的问题会在后续的工作开展中用以设定新的目标或者检查目标是否达成。

最后我们做一个总结，如果大家对数据管理这个话题感兴趣的话，建议去学习一下 DAMA 的 11 个知识领域，可以对数据管理数据治理有一个通盘的了解。接着是刚才说的数据价值链，所有的数据它都是条管道，从现实一直不断的抽象出一些名词概念，到你能理解之后你会产生行为，这种对产生行为有帮助的数据我们就说它创造了价值。第三是我们的数据治理运营框架，它的作用就是把这条数据的价值链做好，让它更高效的进行运转的话。目前我们的实践还是偏成本和质量，期待未来如果我能做分享的话，可以把数据价值这件事情讲好。