全文将围绕以下四部分展开：
- 传媒业务介绍
- 数仓建设演进
- 数据管治体系
- 数据管治展望
01传媒业务介绍
1. 业务介绍
网易从门户网站到新闻客户端，我们的目标是让用户在短时间内去中心化地获取内容信息。整体的业务流程可以简单理解为：内容生产者生产内容，平台负责分发，用户去消费这些内容。
大数据团队的工作职责是：支撑业务运营日报等核心数据报告的产出，支撑ab实验平台、运营平台、渠道分析等各个系统的一个数据产出，提供个性化自助报表及数据的多维分析服务，客户端买点的数据采集以及买点规范化的数据建设。
2. 数据架构
数据架构从上到下分为数据接入层、数据计算层、数据服务层和数据应用层。
- 数据接入层：将业务数据库的数据（比如内容生产数据、用户信息）、公司集团的数据（如用户画像等），还有客户端日志、服务端日志等，这些结构化和半结构化的数据统一接入数仓。
- 数据计算层：采用Lambda架构，离线计算和实时计算分离，离线计算采用Spark on Hive，实时计算采用Flink，离线和实时数仓分层是统一的，从下到上分别是ODS层、DWD层、DWS层和APP层。
- 数据服务层：包括两部分，一部分是数据工具层的存储，另一部分是数据标准服务，我们标准化、统一化了数据输出。
- 数据应用层：包括内部数据应用和外部数据应用。
02 数仓建设演进
接下来给大家介绍传媒的数仓建设的演进历程。
1. 从1.0到2.0
2015年之前，当时的背景是我们公司业务还处在一个门户资讯的阶段，这个时候的内容形式比较单一，大多是以新闻文章、图文为主，数据的丰富度比较低，数据量级也很小，数据需求以面向公司整体的运营的数据报表为主。当时没有专业的数据团队，所有的数据需求都统一是平台组去支撑。
随着公司业务发展，我们从门户资讯向泛资讯转型，内容载体不再只是图文文章，陆续引入了视频、直播等新的载体。内容生产方也不仅是编辑老师，而是增加了PGC、UGC，内容生产更加多元化，同时也衍生出了很多平台，数据需求常常得不到及时响应。另一方面，之前的数据统计逻辑大多在APP层，数据口径不统一，对数、问题排查的成本极高。
我们开启了数仓2.0，从零到一去搭建数据团队，数仓建模采用维度建模的方法，自下而上进行数据建设，以高效支持业务需求为目的。我们也取得了如下的成果，确定了一个清晰的数据分层，确定了面向业务过程的数仓主题后使得影响范围是可控的，数据输出产品化，衍生了传媒数据报表门户、内容运营平台等数据产品，较好地支持了定制化的数据产品需求，也较好的支持了业务的精细化运营。
2. 从2.0到3.0
我们在今年初开启了数仓3.0，针对临时数据需求，开始进行面向分析主题的一个宽表建设，再加宽表模型产品化输出，和业务方定期宣讲我们的宽表模型以及自助取出工具使用，让业务方直接在产品层面界面化的探索，获取自己想要的数据。我们还对数仓层级进行了简化，将原来的六个层级，在逻辑层面简化为了标准的四层，并在ODS层引入了视图，将数据解耦。
03 数据管治体系
1. 开展数据管治的背景
传媒业务快速发展，数据团队承接了大量的数据需求，同时在资源成本、数据质量以及研发效率上面临了很多痛点问题：
- 成本：资源使用负载高，资源使用不可控，为了资源最大化使用，所有离线任务都是提交到一个队列上，没有限制，一个不规范的任务占用大量资源，影响核心报表产出的情况在所难免。
- 质量：由于资源使用负载高和不可控，导致数据SLA不稳定，并且数据质量建设体系缺失。
- 效率：资源的限制也限制了研发效率，使得数据需求交付周期长。
综合以上问题，我们确定数据治理是非常必要的。
2. 数据管理框架
数据治理建设围绕DAMA数据管理指南展开，分为十个模块，整体是以元数据驱动数据治理。本次将重点介绍在数据建模与设计、元数据管理、数据资产管理和数据成本管理方面的实践。
①数据建模与设计
数据的循环流转包括两部分：第一部分是数据化运营，也就是用数据，让客户快速获取想要的数据；第二部分是运营数据，也就是养数据、管数据，主要包括收集数据、数据分层、面向主题建设，不断改进数据模型、提升数据质量，让数据变得更加易用。
基于数据的循环流转，我们规范了数据的研发流程。从用数据到养数据，再到用数据，形成了数据应用的闭环。
②元数据管理
随着数据产生速度的加快，元数据成为数据迁移和集成中不可或缺的一部分。随着存储能力的提升，元数据管理的作用也越来越重要。我们参考了DAMA数据管理指南，确定了元数据的语境关系图，描述了元素据体系建设落地流程：确定元数据管理的目标-元数据的实施-从技术出发实现对元数据解析和影响分析。
- 元数据管理之元数据构成
我们将元数据体系分为四块：业务元数据、技术元数据、过程元数据和安全元数据。
- 元数据管理之数据地图
第一块是数仓表导引，基于数据的使用频率以及业务的重要性，将数仓每个主题域下的一些核心的数据表对外开放，大家可以对数仓产出的所有的数据有个全局性的了解。
第二块是数据洞察，当前只是初步实现了帮助用户找数据、用数据的功能。
③数据资产管理
第一步，定义数据资产等级，分为L1-L4四个等级。第一块是l4等级，是具有全局影响的一个数据资产，像项目的管理层日报等；第二块是l3等级，是具有局部影响的数据资产，主要包括支撑业务的决策分析，就某个核心业务线独有的一些核心指标和核心维度；第三块是l2等级，是具有一般影响的数据资产，这块儿出现问题几乎不会带来影响，或者带来的影响非常小。最后一块是l1等级，这块是具有未知影响的一个数据资产。有了数据资产等级的定点，然后接下来就是如何去落地去执行了。
第二步，落地执行：数据是从业务系统中产生的，然后经过同步工具进入到数仓，最后再通过同步工具输出到数据产品中进行消费。不同的数据产品划分等级，再根据数据的血缘关系打上资产等级标签，不同等级采取相应保障措施。核心资产的占比会控制在30%以内，同时会有准入准出的一个严格的审核流程。通过数据资产等级体系，确定了四个资产等级，36个核心数据报表，153个核心的数据生产任务。
④数据成本管理
资源成本优化分三块：存储成本治理、计算成本治理、资源成本运营体系。
- 存储成本治理
通过存储使用监控、僵尸文件管理、生命周期管理、存储格式压缩和数据模型优化的举措，近几年数据的物理存储降低25%，当前周期内数据存储的占用值处在稳定阶段。
- 计算成本治理
搭建计算成本的监控体系，设计相应维度和指标。
通过僵尸任务治理、邮件任务迁移等策略执行，今年2月以来CPU使用率逐步降低且趋于稳定。资源空闲下来，数据使用方可以及时获取数据，调整运营策略。
- 资源成本运营体系
建设了资源成本运营体系，分为事前、事中、事后。
事前对资源消耗场景进行了拆解，确定了每个场景的资源使用方，制定了《离线数据研发规范》等，并定期组织串讲。事前主要保障大家对研发规范的认知对齐，减少不规范数据的提交。
事中主要是对数据任务的上限审核。目前是主要围绕数据任务占用计算资源、存储资源、SQL代码规范以及调度信息设置四块进行审核，避免不规范的任务上线，从而影响核心报表的一个数据产出。
事后的资源治理，一是对资源成本治理进行分类：计算成本治理主要包括无效任务的治理、超长任务的优化，以此提高资源的使用率；存储成本治理上主要包括冷热数据的管理、数据模型的优化、数据生命周期的管理等；数据采集上主要包括日志上下游的应用监控、无效买点的清理下线。二是在计算资源方面，根据CPU和内存的资源消耗统计了资源使用任务的排行榜，定期去优化计算资源占用top的数据任务和存储资源。
小结：从资源视角看，通过存储治理策略，近一年数据存储减负25%，通过计算治理策略，CPU占用率降低了25%，通过建立资源成本的保障体系，资源使用稳定、流程合理。从业务视角看，部分数据报表产出从12：00提升到10：00前，产出时间稳定，运营、编辑、分析师、产品人员可以在上午处理数据需求。
04 数据管治展望
结合DAMA的数据管理成熟度评估以及传媒业务的实际情况，我们认为数据治理主要有四个阶段。
第一阶段是初始阶段，大家使用有限的工具集进行通用的数据管理，很少或者根本没有治理活动，然后数据处理过程中的角色和责任在各个部门中是分开定义的，数据质量问题也是普遍存在的，基础设施的支持也处于业务的单元级别。
第二阶段是可重复级别。这个阶段有一致的工具集或和角色来支持数据治理流程的执行，开始使用集中化的工具去展开数据治理活动。在这个阶段是主要是解决一个或者几个非常关键的问题，在治理实施的过程中，大多还是依靠人为手动处理问题，组织也开始关注数据质量的问题。
第三阶段是管理级，引入了可扩展的数据管理流程并且将它制度化。从数据生产的链路、整体的视角去集中规划数据治理的一些相关功能。这个时候组织开始关注管理与数据相关的风险，并且确定数据管理评价，可量化的一些指标体系。
最后阶段是优化级，从前面的三个级别中获取的一些经验积累，然后结合强大的元数据体系，使得数据治理活动自动化，并且是高度可预测的。
网易传媒2021年从零到一去开展数据治理，主要解决了资源使用负载高、不可控的痛点，搭建了数据资产的等级体系和资源成本的保障、运营体系，使得数据生产可长期稳定可控。接下来希望依赖完善的元数据体系，实现数据治理活动的标准化、自动化。
05 Q&A
Q：数据链路监控需要监控整个卡夫卡的集群还是监控写入和读取的数据就可以了？上升到数据质量是怎么做的？
A：我们会对卡夫卡、MySQL以及Oracle过来的数据进行数据一致性的监控，监控范围包括接入数仓后的数据量和原来数据的数据量是不是一致，我们会根据资产等级体系对核心数据进行监控保障数据整体质量。
Q：数据治理中数据量化比较难，有没有好的方法或者一些实践？
A：我们在做数据治理推动的时候，一个是治理可以对业务带来哪些价值，明确了治理效果才能推动落地执行。第二是元数据的覆盖度和准确性。
Q：传媒的数据治理的数据量多少？用到什么框架？
A：涉及到数据表的元数据大约4000张，数据报告超过1200，还有一些不能衡量的元数据。我们这边参考DAMA数据管理知识体系，整体上以元数据驱动整个治理工作的展开。
Q：传媒血缘体系如何实现的，是否需要人工介入，准确度有多少？
A：我们这边的血缘体系主要包括两块，一块是数据表的血缘关系，通过Hive的插件扫描SQL的代码实现。第二块是数据表对应的数据任务的血缘关系，主要靠大家在猛犸的离线开发建立任务。两块都会结合，以数据任务的血缘关系为准。
