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开展数据治理,我们解决了资源使用负载高、不可控的痛点,搭建了数据资产等级体系、资源成本运营体系,保障了数据生产长期稳定、可控。接下来是依赖完善的元数据体系,实现数据治理活动的标准化、自动化。