网易数据治理大赛：数据管治建设实践

数据学堂 2022-11-08

The following article is from 网易有数 Author 建伟

导读：本篇是首届网易数据治理大赛一等奖的作品分享，来自于网易传媒大数据团队。传媒的数据管治实践解决了资源使用负载高、不可控的痛点，搭建了数据资产登记和成本运营体系，保障了数据生产长期稳定，为自动化数据治理提供了一个很好的落地方案。

大家好，我是来自网易传媒大数据团队的建伟，首先感谢网易有数的同事们组织了此次数据治理大赛，我参赛的题目是《网易传媒数据管治建设实践》。我将从四个部分向大家展开介绍，第一部分是传媒的业务介绍，第二部分是数仓建设演进，第三部分是数据管治体系，最后再介绍下我对数据治理体系化建设的一些展望。

业务介绍

1.1 业务介绍

首先介绍下传媒的业务，网易是从新闻门户起家，从门户网站到新闻客户端，我们的目标是让用户在短时间内，去中心化的获取内容信息。整体的业务流程是，内容生产者生产内容、平台分发、用户消费。

在这个过程中，我们大数据团队是工作职责是：支撑业务运营日报等核心数据报告产出、支撑AB实验平台、运营平台、渠道分析等各个系统的数据产出、提供个性化自助报表以及数据多维分析服务、客户端埋点数据采集以及埋点规范化建设等。

1.2 数据架构

我们的数据架构体系，整体可分为4层，从下到上分别是数据接入层、数据计算层、数据服务层、数据应用层。

数据接入层：将业务数据库的数据（内容生产数据、用户信息、网易号信息等）、公司数据（用户画像、渠道数据等）、客户端日志、服务端日志等结构化和半结构化的数据，统一接入数仓。

数据计算层：目前是Lambda架构，离线计算和实时计算分离。离线侧技术选型主要是Spark on Hive。实时侧技术选型主要是Flink。离线和实时数仓分层统一，从下到上分为ODS层、DWD层、DWS层和APP层。

数据服务层：数据服务层包括2部分，一部分是工具层的数据存储，主要包括：有数MPP数据库、ClickHouse、HBase、MySQL、Redis等，把数据计算层产生的面向分析主题建设的宽表明细和汇总数据、维度主数据等数据集输出到对应的数据容器存储。另一部分是数据标准服务，我们会把数据库中的数据，通过统一的API接口平台对外提供，满足各类取数需求。在数据服务层，标准化、统一化了数据输出。

数据应用层：一块儿是内部业务数据应用，主要包括有数BI自助取数工具，管理层日报、推荐数字化、编辑考核等数据产品；另一块儿是外部团队数据应用，主要包括算法特征底层数据、新闻热榜APP端数据、网易号薪资结算系统数据支持等。

数仓建设演进

2.1 数仓1.0~2.0

数仓1.0，也就是15年之前。当时的背景是，公司业务还处在门户资讯的阶段，内容形式单一，以文章、图文为主，数据丰富度低、数据量级小。数据需求以面向公司整体运营的数据报表为主。当时没有数据团队，所有数据需求统一由平台组支撑。

随着公司业务发展，从门户向泛资讯转型的过程中，内容载体不仅仅是文章、图文，陆续引入了视频、直播等新的载体；内容生产方也不仅仅是编辑老师，又引入了PGC 和 UGC，内容生产多元化。平台运营也朝着精细化发展，逐步衍生出了内容运营平台、编辑考核平台等平台，数据需求得不到及时响应。另一方面，数据统计逻辑也大多在app层，没有在底层统一收口，导致数据口径不统一，对数、问题排查成本极高。

由此，我们开启了数仓2.0，从0到1搭建数据团队。数仓建模，采用维度建模的方法，自下而上进行数据建设，以高效支持业务需求为目的。取得如下效果，确定了清晰的数据分层，面向业务过程的数仓主题；统计逻辑，底层标签化，影响范围可控。数据输出产品化，衍生了传媒数据报表门户、内容数据运营平台等数据产品，较好的支持了定制化的数据产品，支持了业务的精细化运营。

2.2 数仓2.0~3.0

随着业务团队扩张，新的业务功能在不断探索，我们承接了大量的临时跑数需求，业务方需要快速看到数据效果，来验证假设。大量的临时取数需求提到数仓后，需求交付效率大大降低，这是其中的一个问题。

另外一个问题是，随着个性化推荐场景的上线，我们先后接入了召回、排序、下发全链路日志以及用户画像等数据，一开始需求简单，直接引用推荐的数据表产出数据报告。随着需求增多，导致大量的推荐侧的数据表，直接扩张到了app层数据使用。上游推荐数据一修改，导致我们这边数据改动工作量极大。

基于以上问题，我们在今年年初，开启了数仓3.0。

针对临时数据需求，我们开始进行面向分析主题的宽表建设，再将我们的宽表模型产品化输出，和业务方定期宣讲我们的宽表模型以及自助取数工具使用，让业务方同学直接在产品层面探索、获取想要的数据，至此临时取数需求通过自助取数工具，开始收敛。

针对外部团队数据，在我们数仓侧app层泛滥使用的情况，在ods层，我们采用视图将数据解耦，统计口径底层标签化，数据影响范围达到可控。

另外我们还对数仓层级做了简化，将之前的6个分层，简化为了标准的4层。同时还确定了面向分析的主题、面向应用的主题。在数仓层级划分和数仓主题划分上，通过不断宣讲，保证了认知对齐。通过指标系统、数据模型设计中心，在工具层面保障规范的落地执行。

数据管治体系

3.1 数据管治背景介绍

在数仓演进的过程中，我们也遇到了数据资产难梳理、计算存储资源超限使用等问题，针对这些问题，介绍一下我们数据治理做的一些工作。

首先介绍下传媒这边开展数据治理建设的背景，传媒大数据团队是15年开始组建，近6年的时间，在数据规模上，我们线上调度的离线任务流达到4000+，数据报表个数1200+，服务的用户数340+，数据系统个数13个。

随着传媒业务快速发展扩张，数据团队也承接了大量的数据需求，同时在资源成本、数据质量以及研发效率也面临了很多痛点问题。

资源成本上有2痛点，第一块是资源使用负载高，比如：计算资源凌晨4~12点 cpu使用率是100% ，因为计算资源上午是打满的，数仓RD、分析师只能等到下午才能去做一些数据源探查、临时跑数的一些需求，这块儿受限于资源配额限制，工作效率也是大打折扣。另外一个问题是，资源使用不可控。因为历史原因再加上为了资源的最大化使用，数仓、分析师等所有使用离线开发功能的团队，大家所有的离线开发任务都是提交到一个计算队列上的，并且大家提交任务是没有限制的，一个占用资源大且不规范的任务提交上线后，影响核心报表的数据产出，是在所难免的。

数据质量层面，资源使用负载高、不可控，也使得数据SLA产出不稳定。资源负载高、数据质量不稳定，也必然降低了研发效率，进而导致数据交付周期长，业务满意度低。

从数据规模、资源成本、数据质量、研发效率这4个方面，我们对关键问题进行了归纳梳理，也确定了开展数据治理是必要的。

3.2 数据管理框架

接下来，介绍下传媒这边是如何开展数据治理的，我们的数据治理建设，是围绕DAMA数据管理指南展开，主要包括元数据、数据建模和设计、数据成本管理、数据资产管理、数据质量等10大模块。整上以元数据驱动数据治理。接下来，重点介绍下数据研发流程、元数据建设、数据资产管理和数据成本管理在传媒这边的建设实践。

3.3 数据研发流程

这里先介绍下数据的循环流转，包括2部分。第一部分是数据化运营，也就是用数据，这个阶段主要是让用户快速获取想用的数据，判断、解决问题。第二部分是运营数据，也就是养数据、管数据，这块儿主要完成收集数据，数据分层，面向主题建设，不断改善数据模型以及数据质量，让数据易用。

基于数据的循环流转，我们规范化了数据研发流程，主要包括，业务方(产品、运营同学等) 提出数据需求给到数据PM，数据PM接到需求后，分析需求，之后与数据RD、数据需求方三方确认可行后，数据PM产出数据PRD。数据同学接收到数据PRD后，开始数据源探查，产出数据探查文档，数据探查可行后，进行数仓模型设计以及评审，评审通过后将PRD的指标录入指标系统，之后开始进行数据开发、数据自测，将数据表交付数据PM进行测试，测试通过后，数据RD在DQC配置数据质量监控，任务上线，进行数据SLA评估，核心数据报表加入基线运维保障，最后交付需求方。

以上是我们数据侧的整个数据研发流程，从用数据到养数据，再到用数据，在一套规范的流程体系内运转，衍生了数据应用的闭环，解决了数仓RD直接对接需求方，带来的数据需求烟囱式开发以及维度指标规范不一致等问题。

3.4 元数据体系建设

接下来和大家介绍下我们的元数据体系建设。元数据组成我们分为4块：

第一块是业务元数据(主要包括：数据需求管理、维度/指标管理、数据报告管理)；

第二块是技术元数据(主要包括：源数据管理、表模型管理等)；

第三块是过程元数据(主要包括：任务生产信息、数据使用信息等)；

最后一块儿是安全元数据(主要包括：安全密级、安全审计等)。

基于以上，我们具象了一张数据表的元数据构成，主要包括表的模型分层、数据表安全密级、生命周期、任务信息、数据任务owner、血缘关系、表存储大小、表的访问热度等信息。

3.5 数据资产管理

有了元数据，接下来我们开始了数据资产管理体系建设。首先是数据资产等级定义，对齐了有数的任务优先级，主要包括4个等级：

第一是L4等级，具有全局影响的数据资产；

第二是L3等级，具有局部影响的数据资产，主要包括支撑业务决策分析，某个核心业务线独有的核心指标和核心维度；

第三是L2等级，具有一般影响的数据资产，出现问题几乎不会带来影响或者带来的影响极小；

第四是L1等级，具有未知影响的数据资产，这些数据资产，不能明确说出数据的应用场景。

我们将L4、L3定义为核心数据，我们会将该等级对应的数据任务也纳入到基线值班运维，保障数据SLA。为了保证分级的ROI，核心资产的占比会控制30%内，同时会有准入准出的审核流程。

以上数据资产等级的标准以及数据内容，由分析师、数仓、数据PM三方组成的数据管理虚拟小组统一审核归纳。

有了数据资产等级的定义，接下来就是如何落地了。我们的数仓有近4000张数据表，如何给每一份数据都打上一个等级标签呢？

数据是从业务系统中产生的，经过同步工具进入到数仓，在数仓中进行ETL后，再通过同步工具输出到数据产品中进行消费。可以得出结论，在数据产品中使用的都是经过数仓加工后的产出表。

可以通过不同的数据产品划分数据资产等级，再依靠数据任务的血缘关系，就可以将整个消费链路打上等级标签。针对不同的等级，采取不同的数据保障措施。比如L4、L3等级，定义为核心数据，我们会将该等级对应的数据任务纳入到基线值班运维，保障数据SLA。

通过数据资产等级体系，我们确定了4个资产等级，36个核心数据报表，153个核心数据生产任务，同时也保障了核心数据资产的数据质量。

3.6 数据成本管理

对于如何进行资源成本优化，主要包括存储成本治理、计算成本治理以及资源成本的运营体系。

在存储成本治理上，我们通过僵尸文件清理，数据生命周期管理，存储压缩以及多个同粒度数据模型归并优化，近1年时间内，数据存储减负25%，且当前周期内存储占用处在稳定值。

在计算成本治理上，首先搭建了计算成本监控体系，分析维度包括了日期维度、使用场景、角色等维度，指标上包括规模类的指标，如:当日运行任务数，当日消耗cpu总核数等；新增类指标，如:近7天新增的任务数量等；最后是排行榜，如：计算资源按任务按负责人使用排行榜。

通过hive mr 到 hive on spark的迁移、计算资源占用top的任务优化、僵尸任务下线以及不规范任务迁移优化等策略的执行，从今年2月至今，cpu使用率逐步降低并趋于稳定，整体降低35%。资源空闲下来了，数仓RD、分析师上午就能跑一些临时查数需求了。另外部分核心数据报表从12点产出提升到了7点前，产品、运营、编辑等数据使用方，可以及时的获取数据，调整运营策略。

针对以上成本治理策略，我们建设了资源成本治理的运营体系，主要分为前、中、后。

事前，我们制定了《离线数据研发规范》、《数据抽取规范》等研发规范以及《SQL任务优化指南》，定期会在团队内组织串讲，同时也会把常用的SQL优化方法以及注意事项，定期和分析师团队分享，主要是保障大家研发规范的认知对齐，从而减少不规范数据任务的提交。

事中，主要是对数据任务的上线审核，目前主要是围绕数据任务占用的计算资源、存储资源、SQL代码规范以及调度信息设置这4块儿进行审核，避免不规范的任务上线，从而影响核心数据产出。

举一个我们使用过程中的真实案例，一位数据RD，需要开发一张app层的数据表，来配置对应的数据报表。这位同学按照我们的研发流程进行数据表设计、开发、测试，最后提交了一个离线数据任务到对应的审核同学，审核同学看到该任务测试执行，消耗的cpu core 大于1.5万核，运行时长超过1小时，review了下代码，发现SQL中依赖的用户曝光日志表重复引用了10余次，导致数据被重复扫描计算。审核人员将工单驳回，告知相关同学优化方式。优化后，任务的计算资源使用是1600左右的 cpu core，资源节省近10倍，同时运行时长也缩减到25min。通过事中对资源使用的审核机制，阻断了65+占用资源大且不规范任务的提交。

最后是事后的资源治理，计算资源这块儿，我们根据cpu和内存资源消耗，统计了资源使用任务排行榜，定期优化计算资源占用top的数据任务。存储资源这块儿，我们设置了表推荐下线相关规则,中间表近30天访问次数、日均job引用次数等指标为0，这些数据表会被定期推送给相关负责人，人工review后，再进行数据表的下线清理。数据生命周期也是类似，没有设置生命周期、且总存储占用或者单日新增存储占用较大的数据表，定期推送给表的负责人，人工review后，进行数据生命周期的合理设置。

以上是我们传媒这边资源治理建设的介绍。总结下来，从资源视角看，我们通过存储治理策略，近1年时间内，数据存储减负25%。通过计算治理策略，我们的CPU使用率降低了35%。通过建立资源成本治理的运营体系，使得资源使用稳定、流程化、合理化。从业务视角看，部分核心数据报表产出时间从中午12点提升到了7点前，报表产出时间稳定，运营、编辑、分析师上班前就能看到报表数据。另外凌晨4点到中午12点，计算资源得到优化后，数仓RD、分析师、产品上午就能跑一些数据源探查、临时查数的需求。

数据研发流程规范、元数据建设、数据资产管理，是我们数据治理今年的重点工作，接下来介绍下，对数据治理的一些认知以及展望。

数据管治展望

结合DAMA数据管理成熟度评估以及传媒业务实际情况，我们认为数据治理主要有4个阶段。

1级初始/临时。使用有限的工具集进行通用的数据管理，很少或根本没有治理活动。数据处理过程中，角色和责任在各部门中分开定义。数据质量问题普遍存在，无法得到解决，基础设施支持处于业务单元级别。

2级可重复。有一致的工具和角色定义来支持流程执行。开始使用集中化的工具(如:网易这边杭研的猛犸数据资产中心)展开数据治理活动，主要解决1个或几个关键的问题。在治理实施过程中，大多靠人为手动处理问题。组织开始关注数据质量问题。

3级已管理。引入可扩展的数据管理流程并将其制度化。从数据生产全链路，整体视角集中规划数据治理的相关功能。开始管理与数据相关的风险。确定数据管理评价可量化的指标体系。

4级优化。从1~3级获得的经验积累中，结合元数据体系，使得数据治理活动自动化并且是高度可预测的。

传媒在今年从0到1开展数据治理，我们解决了资源使用负载高、不可控的痛点，搭建了数据资产等级体系、资源成本运营体系，保障了数据生产长期稳定、可控。接下来是依赖完善的元数据体系，实现数据治理活动的标准化、自动化。

以上是我今天所有要介绍的内容，感谢大家。

作者简介

建伟，网易传媒数据研发，现负责传媒数仓架构以及数据治理相关工作。

<END>