网易严选数据任务治理实践

在过去的2020年，网易严选在数据任务治理方面存在一些迫切希望改善及提升的点，2020年初在部门负责人和杭研数科领导的带领下，正式组建团队以“共建”的方式来解决这些希望改善或提升点，经过这一年的项目共建，在解决严选数仓实际问题的同时，沉淀了几个比较好的产品和比较有亮点特色的建设思路及经验。

在2020.12.20号DataFunTalk年终大会中作为嘉宾分享了《网易严选数据任务治理实践》，总结了一下分享给大家，希望对大家有一定的启发和帮助。在严选数仓建设过程中，会陆续面对新的挑战，这些挑战促进了严选数仓逐渐向更成熟和更好的方向演进，那么2020年严选数仓面对哪些挑战呢？（如：任务及时准确稳定产出、减少报警且报警后可干预、具备任务链路感知能力、降低资损事件发生、重大事故快速恢复等），面对这些挑战又是如何来解决的？本文会以事前>事中>事后的思路和大家一起分享这些建设经验。背景
在过去的2020年，网易严选在数据任务治理方面存在一些迫切希望改善及提升的点，2020年初在部门负责人和杭研数科领导的带领下，正式组建团队以“共建”的方式来解决这些希望改善或提升点，经过这一年的项目共建，在解决严选数仓实际问题的同时，沉淀了几个比较好的产品和比较有亮点特色的建设思路及经验，此项目在集团获得了2020年度“技术共享共建奖”，在此感谢两位领导大力支持和平时沟通及指导，同时也为两个团队成员保质保量高效执行的优秀表现点赞。严选数仓在2020年有哪些希望待改善和提升点？

• 模型

  希望在模型设计开发方面有更多的规范、制度、知识沉淀。

• 任务运维希望任务能及时、准确、稳定产出，同时出现问题可以快速定位问题、影响评估和辅助解决问题。
• 报警优化减少晚上值班由于任务出错或异常报警次数，并有一些干预措施。
• 链路感知任务血缘（任务之间的依赖）复杂，希望有一些链路感知能力（某一任务变更对上下游任务有提示及流程管控能力），此链路感知目前用于减少资损事件发生场景。
• 测试卡点在建设之前严选数仓还没有相应的测试环境，也没有测试辅助功能来协助数据开发进行测试，希望有测试环境及相关辅助测试功能，同时QA同学可以对核心或重点任务进行测试卡点及审核，从而提升任务和数据的质量。
• 重大事故快速恢复严选一些核心任务或源头数据出现问题后，在项目建设之前恢复可能需要1~2天左右时间，严重影响了数据的正常使用，希望可以从技术层面来协助快速解决，从而提升用户体验。

1 事前——模型上线前第一道防线模型上线前的第一道防线主要总结为5个保障，分别为流程保障、模型设计保障、数据质量保障、测试保障、链路感知保障，这些保障中有些是原来存在的，有些做了一些补充完善，有些是新增的，便于大家能从整体上对于事前保障有所了解，所以会整体说明。1.1 流程保障严选数仓研发一直有比较好的研发流程和规范，本次进行了一些补充，主要有以下三个阶段组成，下面对这三个阶段做一些说明，如下：第一阶段为需求阶段，目前需求来自业务人员、分析师、产品经理等，并通过jira的形式来管理，需求阶段会明确需求背景、主要内容（如：涉及指标口径）、产出价值、希望完成时间等。需求阶段会完成需求评审，评审时再次明确相关指标口径，没问题后由产品经理录入到指标管理系统（仓颉）中。第二阶段为研发阶段，在需求评审后数仓开发依据需求内容进行模型设计并形成模型设计文档，会组织一次模型设计评审会议，此次会议中会再次明确在模型设计中有异议的指标和问题，并重点给出后端开发时使用模型的注意事项（例如：模型粒度、不可累加性指标如何计算，如何关联模型汇总数据等），模型设计后会将模型设计通过模型设计中心进行相关设计沉淀；接下来是任务开发，数据开发有一些公共的规范约定，如：要求单任务产出单模型，任务名和模型名要一致，如果任务存在需要将模型数据同步传输到其它DB（如hbase,mysql,kylin,es等）供统一服务来对外部系统提供服务，则要求与同步任务分开（避免同步任务耗时过久造成后续依赖任务等待）设计，还有很多规范在此不做阐述；任务开发之后便进入了测试阶段，目前在测试阶段会有工具来辅助形成测试报告，后续会详细讲解；测试之后由需求提出方来进行验收（明确没问题后在jira中确定验收通过），自此研发阶段基本完成。第三阶段为生产阶段，生产阶段主要核心内容为数据质量稽核配置和任务运维，数据质量稽核是由数仓开发在数据质量中心对待稽核表或字段进行稽核规则配置（说明：稽核规则配置实际执行时可以在研发阶段或者上线后配置，本文中暂时归到生产阶段）；生产阶段中任务运维相关事项由任务运维中心来承载，主要包括任务异常报警通知处理、补数据、重跑、问题处理及复盘，若发生重大事故还会进行事故定级定责等，同时也会有相关考核指标对生产阶段任务稳定性和值班情况进行监控考核。1.2 模型设计保障严选数仓关于模型设计有一个很好的设计理念：先设计后开发，首先会有相应的数仓主题域和数仓架构层次（rdb>dwd>dws>dm）划分，主题域中由相应的业务过程组成，模型的维度、维度属性、度量、指标、最细粒度等相关信息都可以在模型设计中心沉淀，模型设计之后通过模型跨层依赖率指标（是指上层计算指标或应用时，需要取主题域的dwd模型，此时可能来不及通过rdb设计生成dwd模型而直接引用rdb模型）来评估模型设计质量，对于短期来不及设计生成dwd模型的情况可以暂时直接使用rdb模型，数仓主题域开发负责人会尽快设计dwd模型并推动下游任务由rdb引用切换到dwd模型，模型的评估指标也在不断的建设完善中，例如评价模型使用指标模型热度；在模型设计过程中有时发现大家对于数仓层次定位及职责并不是很清晰，或者出现过度冗余设计的问题，有时也会听见同事说”没有需求我怎么设计dwd模型？业务单据中哪些应当设计成维度？”，在此给大家再明确一下，如下图

数仓层次划分及定位：

• rdb：数据源，保持和业务系统一致。
• dwd：面向业务过程设计，不需要需求输入，通常由业务过程中单据组成，dwd包含维度及度量（通常来自业务系统数值型字段，例如数量及金额等），定位职责为维度设计（如角色维度、层级维度、缓慢变化度、杂项维度、微型维度、桥接表等）、事实设计（如事物事实、周期快照事实和累积事实等）、代理键设计、数据集成（如严选多交易系统数据集成）、数据清洗（如来自采购库存数量及库存中心库存数量，最终明确使用哪个度量确定唯一来源）、异常值处理（如空值、时间、明确规则的替换）等，相关指标不要在此层设计沉淀，跨主题域相关数据不要进行冗余。
• dws：面向需求设计，可以是单业务过程、单主题域内多业务过程或者跨主题域多业务过程，核心指标沉淀在此层，通常会做明细和汇总设计。
• dm：面向需求设计，定位为数据应用及相关数据集市（如从分析维度可以建设用户集市、商品集市等，从业务线划分可以建设营销集市、服务集市等），不做核心指标沉淀，可以做部分非核心指标沉淀，建议指标统一沉淀到dws层。
• 维度提炼：在维度提炼的过程中，通常从业务过程或单据中相关的who、where、when、how、what、why的角度来提炼，详情参考《维度建模权威指南第3版》。

1.3 数据质量保障在数据质量保障方面，严选数仓也沉淀了比较好的建设经验，相关需求以产品功能的形式在数据质量中心落地。数据质量中心从数据的完整性、唯一性、有效性、一致性、精确性出发通过稽核规则的形式来实现，稽核规则粒度到表级和字段级，同时区分强规则和弱规则，强规则任务执行稽核规则不通过任务会阻塞，阻塞后会多种形式（如电话、短信、邮件、网易内部popo等）通知到负责人或值班人员，弱规则任务执行稽核规则不通过会继续执行，同时也会收到相关的通知；稽核规则的配置也可以通过sql方式灵活实现，便于对复杂稽核规则的配置（如指标波动、多表关联等）；在数据质量中心也提供了相应的质量大盘、质量排行、质量评分等功能模块，可以对大家的任务进行排行和打分，这些也促进了大家积极的配置稽核规则；在下图虚线框内容关于问题分类、发起问题工单、问题处理、知识沉淀、流程优化以及沉淀知识反哺问题处理等功能还未实现，未来是希望由数据质量中心或任务运维中心来承载。

 1.4 测试保障测试中心也是今年项目落地的一个产品，定位于QA在任务上线前对任务及数据测试卡点，分为两个阶段，第一阶段为严选数仓测试环境搭建，第二阶段为上线测试中心相关功能并推动使用。第一阶段严选数仓测试环境搭建，在测试中心建设之前严选数仓还没有测试环境，数据开发在猛犸平台开发环境上开发自测没问题后直接提交任务到线上环境(开发和测试环境使用同一集群和DB)，由于同一套DB则在开发的同时可能操作线上数据，这增加了数据的不稳定和不准确性，为此和杭研同事一起推动了严选数仓测试环境的搭建，严选的测试环境搭建核心点为测试环境和生产环境使用相同的元数据，同时对核心库(dwd、dws、dm、dim)创建测试库并以_dev结尾，测试环境可以读取线上环境的数据写入到测试库中，测试环境和生产环境中哪个做为数据源或目标库则可以通过“${库名}.模型名”灵活转换，测试环境搭建的过程中也遇到了很多兼容性问题，如部分自定义udf函数兼容、hive版本或spark版本不同带来的自身函数兼容性等。第二阶段上线测试中心核心功能，现阶段测试中心主要有两个核心功能，分别为数据比对和形态探查，数据比对功能可以选择不同的模型，设置比对分区和比对字段等，比对后会从模型和字段两个粒度给出相关一致性统计指标数据，并可查看不一致明细信息；形态探查可以对模型的构成信息进行探查（如数量、字段长度、空值占比、最大最小值、枚举值等），测试中心的上线很好补充了整个研发流程测试环节的缺失（QA测试），也为后续测试在整个数据研发流程中更深入的参与及把控数据质量奠定了基础，提升了数据和任务的质量。1.5 链路感知保障首先解释一下什么是链路感知？如何设计链路感知流程？应用场景？链路感知：下图中从上到下分别是数据源层>rdb层>dwd层>dws层>dm层，则dwd层模型9变化后其下游模型(10、11、12、13)都会有相应感知。链路感知流程设计：首先提供末级模型（例如模型13）打标入口，在相应入口页面对末级模型进行打标，打标后任务中心根据模型血缘对上游模型整体打上相关标签，在上游模型对应任务变更提交时则会有相应提示或流程管控。应用场景：目前主要应用在防资损事件发生场景，举例说明：dm模型13是发红包或优惠券用户模型，模型13依赖模型9的数据，则模型9变更调整就需要重点关注，目前支持在模型9对应的任务提交时提示其影响资损模型13，同时发起QA审批流程，按照QA要求准备好相关内容（如需求jira，测试中心比对测试报告等）提交进行审批。

 2 事中——基于「基线」任务运维

关于任务运维，在项目建设前面临待改善的具体点有哪些呢？如下：

• 任务配置多个报警，造成报警混乱对值班造成干扰。
• 任务级别没有清晰划分，很难针对不同级别任务采取不同策略动作。
• 任务完成考核指标需要细化，原考核指标为04:30完成90%任务数量。
• 不能提前预警，例如在半夜01:00不能预测早上07:00任务完成情况，并给出相应预警提示。
•  发现问题后由于任务依赖链路复杂而不能快速定位到问题，同时也需要给出一些影响评估信息。

• 如何设计让整个值班流程（发现问题>报警>问题定位>问题影响评估与通报>问题处理）良性的运转起来？

基于以上这些具体待改善点，最终以功能产品的形式完成了任务运维中心建设，建设思路主要可以归纳为及时发现问题>快速定位问题>全面影响评估>辅助解决问题，在建设过程中提出了基线的概念，通过不同基线对任务级别进行划分，从而可以针对不同基线任务采取不同的策略动作（如：资源限制、优先级高的基线优先配置高优队列、优先级低的任务可以查杀、核心任务重点保障等），下面就任务运维中心一些比较核心的点进行讲解。
2.1 基线划分原则及目前基线配置情况基线划分原则主要从任务配置的必要性、重要性、需提前预警几个方面考虑的，目前基线划分的原则如下：基线上的任务为天调度任务，对于小时、分钟、周、月、季、年等任务暂不做基线配置。核心应用需要挂载到基线上，目前严选数仓核心应用主要有vipapp（管理层移动端看数应用）、有数（杭研BI报表工具）重点报告、易信等。核心指标对应的模型需要挂载到基线上（如gmv、用户数、pv、uv等）。预留破线时间buffer，首先针对基线设计了两个时间概念，一个基线预警时间，另一个是基线破线时间，例如07:30基线，预警时间设置为提前三分钟07:00，破线时间为07:30，则程序在01:00时（预估程序预估时间点和频次可配置）预估07:30基线在07:00是否可以完成，若不能完成给出相应的报警（报警方式、报警次数、报警间隔可配置，一般预警只做短信提醒），若在07:30时，07:30基线上的任务还未运行完成则代表破线了，破线会给出报警（此时一般会配置为电话报警）。严选数仓目前配置了如下几条基线，详情如下：

• 02:30基线：一般dwd层模型对应的任务会配置到此基线上，定位为主题域层模型对应的任务做产出保障。
• 04:30基线：一般dws层模型对应的任务会配置到此基线上，定位为对指标层模型对应的任务做产出保障。
• 07:30基线：定位为核心产品应用对应的模型做产出保障（如vipapp）。
• 09:30基线：定位为数仓全部主题域、指标、应用模型产出做保障。
• 数仓默认基线：不重要的任务可以挂在默认基线上，若出现集群资源紧张情况，则可以对此基线任务进行查杀。

2.2 报警过多措施在前面有提到报警过多的原因主要是单任务可以配置多个报警导致的，以基线设计的运维中心上线后，任务挂到基线上，且任务归属于唯一的一条基线，这就自然的解决了任务报警配置混乱的问题；任务中心在设计报警时，将报警分为两类：一类为基线上预计破线和破线报警，另一类为基线关联任务失败报警（若基线关联的上下游任务没有在基线上则不作报警处理）；若收到报警则还可以对报警进行干预，目前可以设置免打扰时间，例如04:30基线收到报警，值班人员判断后续此基线是否在一定时间范围内不需要报警，若不需要则可以设置一个时间段不进行报警。经过上面的措施后为什么还存在报警过多的问题呢？原因是任务运行异常后一段时间内不进行处理会多次报警，此外如果一个任务例如在02:30基线上，破线时还未处理成功，则可能会影响后续基线上任务按时完成，后续基线上的任务会级联预警及破线报警，这就存在报警爆炸的风险，针对这些问题设计了一些报警策略：

• 电话报警智能取消：20分钟内报警电话智能取消，例如02:00已经电话报警，则针对失败、预估破线等报警方式为电话的在20分钟内的报警智能取消。
• 报警时间间隔调整：可通过在任务运维中心设置报警时间间隔和报警次数来减少报警，例如预估报警可以设置从凌晨12:00开始每1小时预估一次，如果预估破线则报警，也可以设置每2小时预估一次，这样就减少了报警次数，当然也增加了破线未提前干预的风险。
• 重复报警整合：首先解释下重复报警，重复报警为任务失败后，报警间隔时间内检查一次任务状态，若未成功处理则进行第二次报警。经过和同事的沟通决定报警整合策略为第一次报警时间+报警间隔时间进行整合到下一个报警中，例如报警时间设置为00~24点，报警间隔时间为30分钟(00:00报警检查一次、00:30为第二次、01:00为第三次，以此类推），任务A 02:15失败则第一次报警，02:30的报警中不合并任务A的重复报警，会在03:00报警，这样做降低了重复报警的次数。

2.3 关键链路诊断关键链路诊断也是任务运维中心一个比较核心的功能点，在基线预警或破线时由于基线上可能配置成百上千个任务，是由于哪个任务运行异常（失败、运行时间延迟、运行完成时间延迟等）导致的基线预警或破线？人工定位是一件非常困难的事情，为此设计了此功能点，设计的关键点如下：

• 计算逻辑：基线上耗时最长的任务链路。
• 计算频次：每10分钟计算一次。

• 两条曲线对比：下图中蓝色曲线为基线任务近14天平均运行完成时间，黄色曲线为今天的任务运行情况，若查看的时间点任务未产出则使用预估时间进行替换。

从下图箭头所指的地方可以看出来由于某一个任务运行的延迟导致了整条基线的延迟，这就很好的帮助了数据开发同学在基线任务异常时快速定位问题。

2.4 影响评估当发生问题后领导最常问的问题是影响有多大？什么时间可以恢复？这也是通过关键链路诊断功能确定问题后值班人员直接面对的问题，接下来就可以通过影响评估功能来解释这些问题。当一个任务运行异常或失败，根据任务依赖血缘会给出影响的任务，以及任务相关的应用，目前影响评估还只是到模型、任务、服务这些粒度，后续计划到指标粒度，一个任务失败可以快速告知评估者影响了哪些指标，对于影响的指标目前还是有些难度的，例如一个任务下游有100个任务并对应100个模型，每个模型按照5个指标计算就有500个指标，500个指标可能存在相互之间的关联关系，如何梳理清楚并清晰的展现需要接下来逐步实现。3、事后——报警干预措施及常态化机制3.1 干预措施报警后值班人员可以进行一定的干预，干预措施总结如下：

• 对数仓默认基线任务进行查杀。
• 值班免打扰设置（根据预估执行时间推荐免打扰设置时间范围）。
• 关键链路诊断&影响分析：定位问题和评估影响。
• 集群队列资源动态平衡：及时平衡集群队列资源，避免过多任务等待或由于任务资源不足造成的耗时增加，此条并没有完全实现，后续是希望能做到任务由于资源问题运行时间延长时可以随时动态增加资源，有待解决。
• 问题处理知识库：通过问题日志，以及日常解决处理问题总结，给出异常问题的解决方法参考建议。

3.2 重大事故快速恢复如下图是一张任务执行的DAG图，若节点A和节点B执行的结果存在问题，需要重跑任务A和任务B，那么在新的任务运维中心建设之前存在哪些问题呢？如下：

• 问题1：重复运行，例如分别重跑任务A和任务B以及两个任务的下游任务，此时任务C执行两次，耗费平台资源的同时且容易造成数据异常。
• 问题2：停止异常任务及下游任务比较耗时且耗费集群资源，例如任务B执行结果数据异常，此时希望选择任务B然后执行停止操作，此操作可以级联停止下游正在运行或等待运行的任务，而不是下游任务手动一个一个选择然后进行停止操作，这样操作即耗时又消耗集群资源。

那么是如何解决的呢？在此引出了冻结池的概念，基本思路是这样的，首先会创建一个冻结池，然后为这个冻结池框选根源任务，例如上图中的任务A和任务B，然后执行冻结任务，执行任务冻结时程序会终止任务A和任务B及其下游正在运行中的任务，等待运行的任务不再运行，接下来执行解冻任务，解冻过程会进行任务的重跑，重跑的过程中可以设置任务执行的并行度，具体执行过程要比这复杂，在此不做累述。3.3 常态化事项在项目的建设过程中形成了比较好的常态化事项，在此列举下，相信对从事数据开发或运维的小伙伴有所帮助，如下：

• 冷任务定级：冷任务定级（一级任务上线到当前一个月未被下游使用，二级任务上线到当前三个月未被下游使用，三级任务上线到当前六个月未被下游使用），针对不同级别的任务采取不同的策略（如一级通知，二级通知及开发邮件补充未下线理由，三级进行直接下线）。
• 耗时任务优化：针对耗时任务进行排名、优化。
• 引擎切换：计算引擎从Hive切换到spark,提升计算速度。
• 任务长链路优化：针对几条任务依赖长链路（履约、营销玩法拆分等）进行任务拆解（运行慢指标逻辑部分拆分）、并优化后续依赖任务。
• 维表设计优化：维度表中相关标签类指标进行拆分到相应的扩展表中（如商品维表中针对sku_id的首销时间、首销金额等）。
• 任务报警兜底优化：对于任务运行或完成时间（后续时间可以配置）超过一定时间后，进行相应的报警。

3.4 监控复盘关于监控复盘，主要从两个角度设计的，一个是值班过程中，另一个是值班后。在值班过程中值班人员对于值班过程中发现的问题进行响应，依据响应的时间和响应次数等设计了如下指标：电话报警次数、有效响应次数、有效响应率、有效响应平均时长等，并在任务运维中心运维大盘中以图表的形式展现给值班人员；值班后在有数（杭研BI报表工具）上做了一些列监控报表，例如基线完成时间趋势图，基线预警及破线时未完成任务列表等，同时每周会在中心周会上针对一周任务运维出现的问题进行推进解决；通过这样的值班指标设计、一系列监控报表及周会复盘制度，很好的保障了任务及时、准确、稳定的产出。4 未来一些思考在后续还是有很多事情要做的，如下：

• 关键链路诊断：目前是单链路或输入任务，后续可以考虑多链路排序展示，开发人员来选择多条链路分析。
• 多基线任务问题联合定位：多条基线任务智能定位，发现单任务引起的多基线多报警问题，做智能取消处理。
• 影响分析进阶：指标层面影响分析，多任务影响联合分析。
• 报警配置优化：值班组报警配置向基线报警配置优化、报警接收方式、报警类型、报警次数拆分等。
• 数据质量评估体系：重点推进模型（复用、健壮、规范）、任务、指标等质量评估指标体系的建设。

未来严选数仓的建设会面对新的挑战，是挑战也是机遇，本人平时也会在大数据相关技术和理论方面做好深度和广度知识储备，伴随公司一起成长，向未来出发，加油！
作者简介静远，网易严选数仓资深数据开发工程师，目前主要负责服务线（供应链&财务）主题域架构设计和数据应用开发，具有丰富的数仓体系建设和维度建模经验（网易云课堂分享一系列维度建模课程，大家可以前往学习），在数据应用方面如：成本费用体系、财务结算、核算、对账、供应链履约降本考核监控策略支撑等具有丰富建设和应用经验，很好的推动了整个严选数仓体系、供应链和财务域的建设。