网易数帆数据治理演进

2022-12-21 00:00:00 数据指标治理标准基线

导读：本文将分享网易数帆数据治理的发展过程，以及对现代数据治理的概念和理念的理解，提出现代数据治理应该与数据开发和消费很好地衔接，具备开发治理一体化、形成治理的闭环、仓内仓外统一治理和建立数据资产门户等核心特点。

文章将从以下四个方面展开：

网易数帆大数据简介
统建中台：先设计后开发
见招拆招：运动式治理
治理体系：现代数据治理

分享嘉宾｜余利华网易数帆大数据产品线总经理

编辑整理｜许友昌每日互动

出品社区｜DataFun

网易数帆大数据简介

首先简单介绍一下网易数帆大数据产品体系的发展过程。

网易大数据团队早致力于分布式数据库、分布式文件系统和分布式搜索引擎。2009年开始基于 Hadoop 做数据分析和运维。2014 年大数据平台上线，并开始BI的产品化。2017 年正式对外做商业化的探索。在2018 年的时候，随着业务的发展，网易使用数据面临了很多的问题，所以开始建设数据中台，发布了数据中台的解决方案。2020 年通过网易数帆品牌正式提出了数据生产力的概念，提出不仅仅要建设数据中台，还要建设数据中台上的数据产品，提倡“人人用数据”的理念。2022 年数据治理 2.0 产品正式发布。

到目前网易数帆形成了一个相对全栈的大数据产品体系，分为四层：

下面是基础设施，这里有网易数帆自己的 NDH 发行版，也可以对接 CDH 或者 CDP，基础设施主要是提供存储计算能力，NDH 在回收站等方面也有加强，还做了一些存算分离、混合部署的工作。
在数据基础设施之上是数据研发，覆盖了从数据设计、开发、一直到测试、上线、运维的整个过程，希望能做成一个符合 DataOps 的数据研发产品。
在数据中台部分，我们提供了指标系统、模型设计、数据地图等产品，目的是帮助业务去建设数据中台。
在数据产品层，我们提供了很多工具，比如 BI 工具、数据门户，我们的理念是要利用低代码和无代码的方式，帮助用户、客户去打造面向场景化的数据产品，从而真正达成“人人用数据”的理念，实现数据生产力在企业落地。

统建中台：先设计后开发

网易数帆数据治理发展过程的个阶段为统建中台，先设计后开发。

当时的背景是网易的互联网业务在 2018 年的时候发展比较快，面临了很多的数据问题。以网易考拉海购为例，当时交易和主站供应链以及各个团队分别建设了自己的数据仓库，这样就造成烟囱式的开发，带来了很多的问题。

个问题是指标口径不一致，很多指标同名不同义、同义又不同名，不同部门之间的沟通存在很大困难。
第二个问题是缺乏数据建模规范，当时我们的数据团队非常辛苦，但还是不能满足业务上的需求，交付的速度还是非常慢，平均需要一周的时间，并且查询的效率又特别低，一个月范围内的查询要将近一分钟，一年内的查询要 300 多秒，找数据也特别困难，业务产生了几万张表，不知道哪里有数据，不知道怎么去找、怎么去用。
第三个问题是数据重复建设，有超过一半的数据是冗余的，数据量超线性增长。

在这种情况下，我们分析了原因，为什么数据研发的速度会慢？查询的效率会低？我们做了一些数据的分析，结果发现有超过 50% 的任务，是在直接读取原始数据，也就是 ODS 层的数据，并且有 30% 的 Ad-hoc 查询命中原始数据，原始数据加明细数据的查询比例高达 60%，另外超过 40% 的表都没有分层，这些其实都是烟囱式建设带来的问题。各个业务线都是从 ODS 层开始拉数据来建设，没有形成很好的数据公共层，数据复用程度不足。结果导致需求响应非常慢，查询效率特别低下，规范也特别不好，整体就是数据不好用。

我们提出的解决方案是先设计后开发，其实就是建中台。主要分为指标定义、模型定义、数据开发三个步骤。

指标代表的是数据中台的需求层面，所以要从指标开始抓起，就是从源头开始抓起，只有源头的需求明确，设计才能清晰，产出的数据才能好用。所以我们引入了数据中台指标定义的方法论，建设了指标系统产品，系统地梳理了我们的指标，包括原子指标、派生指标，并且给这些指标划分了数据域和业务过程。完成指标梳理之后，当年考拉电商的指标数目下降了一半左右。这里原子指标与派生指标的区别在于，原子指标是带口径的，派生指标不带口径。所以数据团队的核心，就是要管控好原子指标，这样就会避免指标口径不一致的问题。

有了指标定义之后，就进入到模型设计的层面。我们引入了维度建模的方法。并且打造了自己的一个模型设计中心的产品，把维度建模的理论落地进去。当时为了推进模型的规范化、标准化，我们甚至把 ODS 层的数据都给收回了，这样强制大家要去用公共数据，发现公共数据不足的时候给我们提需求，以这样的方式来推动数据建设。

建好指标、建好模型之后，就是数据开发过程。在建设数据中台或者说在重构我们的数仓之前，我们首先要思考，如何衡量模型建得好不好？数据中台建设得完不完善？我们提出了模型设计的度量标准，主要从三个方面来考虑：

是完善度，可以分为两类，首先是查询的覆盖度，就是 ADS 层的表能满足多少比例的查询，这个比例越高说明建设得越完善，越能满足客户的需求；另外就是跨层的引用率，DWS 层直接引用 ODS 层，就叫跨层引用，跨层引用率越低越好，我们希望一层层往上叠加，不要产生跨层引用的情况。
第二是复用度，一个模型被下游模型引用的次数越多越好。
第三是规范度，是否存在不规范的表，没有分层的表，没有主题域的表等等。

通过模型的重构，数据中台的建设，取得了显著成果，跨层引用率从 30% 下降到了10% 以下，模型的复用度从 2.4% 提升到了 9.6%，在这个过程中下线了 3.4 万个模型。通过这样的中台建设，我们的模型更加优化，使得我们的交付速度和查询的性能也得到了显著提升。这就是阶段，建设了数据中台，先设计后开发，把模型的问题解决了。但是并没有解决所有的问题，后面又出现了各种各样其他的问题，下一阶段我们主要是针对出现的问题见招拆招。

见招拆招：运动式治理

1. 成本问题

在见招拆招的过程中，首先是成本问题，表现在三个方面：

投入产出低：每个业务部门都有很着急的需求，一方面是需求做不完，另一方面是做出来的很多数据没有人用，我们有时发现有超过一半的表都是 30 天内没有人访问过，不得不怀疑这样的需求是否正确；
资源使用不合理：数据开发天天抱怨数据分析师的 SQL 写得太烂太占资源，分析师天天埋怨 SQL 跑得太慢，每周都有因为资源使用不当导致造成的事故；
成本指数增长：不停地加机器，已经非线性增长，老板也要问，这些机器到底用在了哪些业务？产生了什么价值？哪些可以做哪些可以省略不做？

针对这些问题，我们需要更精细的成本管理。

我们的解决方案是建设一个数据资产中心。

首先，核算每个查询任务和表存储资源，然后折算到钱。网易是做内部结算的，所以我们能够把所有的任务折算到钱，而且可以把这些钱分摊到每个数据表、报表，分摊到每个数据的应用，这样就特别清楚了。
第二，采用“剥洋葱”式数据下线。从下游不再被使用的数据应用开始，逐层向上游任务和上游数据去下线。这里的下线不是马上下线，而是把它先暂存起来，让其不可访问，如果需要可以马上恢复。
第三，预估任务和查询成本，对高消耗的任务和查询进行审批和管控。

整体效果比较理想，当年累计下线数据达到 69P，云音乐、严选分别优化了 47.6% 和 61.0% 的表，也节省了 38% 的计算资源。

2. 质量问题

第二个严重的问题是质量问题，平均每周会有 10 个数据质量问题在群里被反馈，更糟糕的是其中 90% 的问题是由业务方发现的。还有一些非常严重的缺陷甚至会导致资损，比如曾有一次事故就是因为某个任务节点配置的问题，导致把老客户当成了新客户，造成了 30W 的营销资源损失，造成了 P1 的事故。

我们对于数据质量问题的解决方案是早发现、早恢复。

首先，建全链路的数据质量跟踪体系，从数据源到数据中台模型再到数据应用建立全链路监控。那半年里做了 1000 多个任务的监控，基本覆盖了所有重要数据源，特别是涉及资损的重要数据，保证数据正确性。
第二，构建智能基线运维体系，早我们是基于单个任务去管，报警特别多特别繁琐难以管控，所以我们做了基于基线的运维体系，把任务划分了一些基线，把任务都挂到基线上去。为基线规定了产出时间，并且做了一个特别有用的功能——基线预警，可以提前预知到基线的问题，使得问题可以早发现早挽救，避免事故。
第三，任务影响分析，在真正出现了事故和延迟的时候，就需要做任务的影响分析，根据全面的血缘精准评估数据影响了哪些下游的 API、报表、应用，根据应用反推应该如何去修复高优先级的数据。

一个典型的案例，有个数据研发收到了报警说基线要破线了，在群里问是不是有人改了依赖？另外一个人就去看，确认问题，马上就把问题解决了，避免了事故。这就是基线预警的效果。

3. 安全问题

我们也曾经踩了很多安全方面的坑。比如曾经某数据开发建一个数据库，把数据库的根目录指定在了整个数仓的根目录上，然后他把整个数仓都给干掉了，更糟糕的是 HDFS 的回收站是有缺陷的，删除文件过多的话，就不会进到回收站。即使调用 HDFS delete API 直接删除，系统也会绕开回收站，这就导致了当年一次很大的删库事故，幸好我们当时马上把 NameNode 上面的镜像 Download 下来，把 NameNode 给停掉，把数据恢复出来。

其他的安全问题，还有权限粒度不够精细、权限审批不方便等，有时不知道如何给予授权，不知道由谁来审批，不知道是否应该授权。

针对以上问题我们也做了各种的应对能力，比如设置了公共的回收站，改造 HDFS 回收站，使得删掉数据一定能进回收站；实现了目录冻结，比如数仓的根目录不能删除；备份恢复，数据备份到其他集群，即使整个集群出问题，也不会造成数据丢失；实现了行级的权限、队列的权限，实现了标签的权限控制，也实现了自定义的审批流程，比如每个部门每种级别的数据可以制定自定义的审批流程。

以上就是我们在成本、质量、安全方面的工作，遇到问题解决问题。虽然我们总能见招拆招，但是总觉得有填不完的坑，那怎么办呢？为什么会这样？我们也一直在思考这个问题。

治理体系：现代数据治理

传统的大数据治理分为三个过程，首先是开发，产生数据资产；然后消费数据资产，产生价值；治理在中间，想方设法让我们的数据资产质量更好、更安全，更容易被使用。这是数据治理的目标，但是这样的模式存在一些问题：

，先污染再治理，开发环节无法保证数据的出厂质量，出来的数据就不是很合格，过多依赖事后去治理数据，效率不高。
第二，运动式治理，缺少统一的数据治理的衡量标准，不确定效果，也缺乏持续优化的机制，这是存在于治理环节的问题。
第三，存在于数据消费的环节的问题是，消费者找不到、看不懂也信不过这些数据，导致数据很难被利用起来产生价值。
第四，只能治理大数据平台内的数据，无法管理其他系统的数据。通常互联网公司都把数据集中在大数据平台，但是我们在服务客户的过程中也发现了在很多行业不可能如此，因为他们有建设了不同系统来满足不同的场景需求，所以我们的治理平台能不能治理大数据平台以外的数据也是一个问题。

从根本上来讲，数据治理之所以会产生源源不断的问题，是由于我们的数据治理是个旁路的系统，在开发和消费的边上，它既不深入到上游数据开发的环节，和下游数据消费的环节也是脱节的。所以我认为数据治理应该拓展它的范围，要与数据开发和消费很好地衔接在一起，这就是现代数据治理，特点总结如下：

，开发治理一体化，从源头开始控制，实现新产出的数据都能得到治理，未来产生的数据也得到保障。
第二，形成治理的闭环，这点主要是针对存量的数据。
第三，仓内仓外统一治理，不仅仅是针对大数据平台内的数据，还可以治理数据库、MPP 等现存的一些非平台内的数据，非中台内的数据。
第四，建立数据资产门户，我们通过数据资产门户或者数据目录这样的方式，能够让数据更好地被消费。

要符合这四个特点才能把数据治理真正落地，下面展开介绍。

数据开发治理一体化，核心是在事前解决质量和安全的问题，将数据治理融入到数据开发的体系中，整个开发的过程就会变成：

是要先定义数据标准，数据标准的核心是数据元，比如身份证就是一个数据元类型，数据元就会规定它是一个字符串的类型，它的取值范围是什么样的，长度是多少，校验质量、校验规则是什么样的，还有设定身份证的隐私条件，比如是保密的，所有的质量安全规则都会绑定在身份证这个数据元上。
有了这样的数据元之后，第二步，是定义指标口径，明确指标的业务含义。
然后有了标准和指标规范之后，才是建设模型。指标规定了模型业务方面的需求，而标准规定了模型上的质量、安全规则，规定了类型和命名。
定义好模型之后，再进入到数据研发环节。

如何真正的使得开发治理一体化落地呢？我们建设了数据标准产品，并与其他子产品做联动、关联，才能确保数据治理能落在数据研发的全生命周期里面，能够紧密结合起来。比如数据标准要和数据质量结合，数据质量就会自动的去开启关于某个字段或者关于某个表的稽核规则；标准要与数据传输去做很好的联动，从数据源到目的地会做自动的表的映射、字段的映射、表数据字典、枚举值的映射。然后数据标准也需要跟模型设计去做关联，这样字段和表的命名就能标准，并且数据目录分类也会标准。标准还要跟数据安全中心去关联，安全中心就会自动得到安全等级是什么，其加密和脱敏的规则是什么，安全审批的流程是什么样，更高等级的数据通常需要更高、更复杂的审批流程。数据标准还可以跟离线开发结合，利用一些 SQL 模板自动做一些 ETL 任务的生成。通过这样一个紧密的关联才能实现研发和治理的一体化。

第二是治理要形成闭环。形成闭环主要包含三个方面的内容，首先是发现问题，也就是我们希望通过多维度健康度的评估，去发现数据中的问题。第二是有了问题之后还得有解决方案，我们通常配了一些专题的优化工具，比如推荐下线、生命周期管理、任务优化等。有了解决方案之后，还得有运营的手段，比如我们有治理的红黑榜，甚至跟考核或是资源申请挂钩。

量化衡量数据资产的分数，我们通常从安全、成本、价值、质量、标准等维度去给资产评分，用户登录到我们的系统，就可以看到某个资产的评分、自己的评分、组织的评分。我们会给评分打一些排行榜，如果用户发现评分有点低，可以具体点进去看到哪里做得不好，比如可能发现自己有一张表，30 天内都没有人访问，那这个时候他可以使用我们产品提供的自助灰度下线的功能，去做一个优化。由此我们能够对数据资产进行全局的衡量。

持续运营还需要有流程，很多公司里面有数据治理的部门，治理部门会给每个数据设上正确的 Owner，一旦数据消费者发现数据有问题，就会依据这个在我们的产品里发起一个数据治理申请的工单，数据治理部门收到工单之后就会在一定的时间内响应，当然他不一定要亲自动手来干这个事情，他会依据公司的相关政策，把工单派给各个业务部门数据治理的专员，让他们去解决问题。通过这样的流程能保证我们的数据质量一直在提升，不会一直腐化下去，数据有问题能得到很好的修正，让用户拥有比较好的体验。

持续运营还包括文化的建设，我们在网易内部每年都要组织数据分析大赛、数据治理大赛。数据治理大赛看起来比较抽象，但每年都有超过 20 个团队来参加，我们选择其中比较的评奖，并在公司发全员邮件进行表彰，也会做可视化的大赛等等。我们也提供了一些培训，数据开发工程师、数据分析工程师的资格认证培训。我们有些业务部门要求我们给他的员工先出个证，要是没有这个证是不允许去线上操作的。在组织方面也可以建设数据治理部门，也可以在业务部门配置数据治理专员，这样才能更好地把数据治理落地。

在仓里仓外数据统一治理方面，我们自己实现了一个逻辑数据湖统一治理的方案，通过元数据注册、扫描、采集、元数据发布，把一些仓外的表，比如 Oracle 的表，MySQL 的表能够映射为我们平台内的一个模型，然后把这个模型关联到不同数据源的物理表。在此之上我们建立了统一开发和统一治理的流程，使得仓里仓外能够统一治理。

在数据资产消费方面我们提供了一站式的数据消费平台。通过这样的消费平台，业务人员可以在数据资产门户上看到企业到底有哪些数据、哪些报表、哪些资产，很方便地去申请权限，无缝的在上面跳转到 BI、自助取数，或是其它各种消费数据的地方。管理员也可以根据资产的访问情况进行运营。管理数据就像管理商品一样，如果是不好的数据就应该给予下线，好的则应该给予更好的展示位。

后总结一下，我理解中的现代数据治理的主要思想：

首先是研发治理一体化，防患于未然，保证数据出厂质量。

第二点是成果可以衡量，形成治理改进的闭环。

第三是关注数据的消费，毕竟数据治理的目标是为了数据的消费，发挥数据的价值，所以必须关注数据的消费。

问答环节

Q1：在网易内部是什么团队统一制定数据标准、指标标准是业务还是数据治理团队？

A1：网易是事业部制，内部每个业务之间相对比较独立，事业部各自负责各自的标准制定，通常事业部也会有自己的数据部门和他内部的业务部门。我们的外部客户里面，比如说我们接触到很多金融行业的客户，是有专门的数据治理部门，数据治理部门的来制定、牵头制定相关的标准、数据发布审核，需要每个业务部门出数据治理的专员负责治理的落地，数据团队则负责提供数据，修复数据和元数据问题。

Q2：治理基线可以大致介绍一下吗？是通过试运行实现治理任务基础基准的吗？

A2：基线可以理解为一组相互依赖的，需要统一管理的任务，这组任务有一定的 SLA。基线可以方便管理，我们可以为基线设定一个预期产出时间，并配置一个值班表，每天预测基线预期产出时间，一旦预测要破线风险，可及时告警到当天的值班人员。基线是很多任务组成，任务相互依赖形成一个复杂的图状结构，那根据任务的运行历史以及当次的运行情况，是可以预测到基线未来的产出时间是不是破线，如果是破线的话就可以提前来进行告警，使得我们能够有充足的时间能够处理，避免事故发生。

Q3：目前可以实现落标对标的功能吗？

A3：我不知道是不是指一些行业的标准或者企业的标准如何去落地，传统上我们做数据标准其实是一件很难的事情，比如证券行业，我们理解原来就有很多数据标准了，但是些标准通常是落在纸面上，就是说有规定这个标准是什么样子的。我觉得落标的核心，还是把标准以产品化的形式来承载，把这个标准贯穿到我们事前事后的整个过程，在数据研发过程中确保产出的数据就是符合标准的，事后我们也可以拿到这个标准，拿原数据扫描的结果去比对，看看是不是符合标准，然后根据治理的闭环再去治理。所以我认为个是落在产品上，第二个是跟其他研发环节做关联，跟治理环节全链路做关联，这样才能很好地落地。

相关文章

​网易数帆数据治理演进

网易数帆数据治理演进