爱奇艺数据中台的数据治理实践

Posted 2023-03-04 @SmartSi

1. 爱奇艺数据中台简介

爱奇艺从最初的单一视频网站发展至今，业务早已不仅只有视频业务。现已涵盖了内容生态的多种业务，以及内容相关的周边业务。随着业务变得越来越复杂多样，数据对于平时的运营和决策也变得越来越重要。

1.1 为什么要建设数据中台做数据治理

在平时的数据工作中，我们遇到了如下问题：

• 接入成本高：新业务或新场景所需数据要人工申请资源权限、采集、计算、同步、展示等。这个过程耗时长、效率低、易出错。
• 使用门槛高：在一些数据工作中，需要人员有专业的数据基础能力。
• 埋点质量低：埋点投递缺少标准化和流程管控的机制，导致埋点数据质量差。
• 数据可靠性低：数据不可靠会降低生产过程中业务的数据分析效率，最终对业务决策造成严重的影响。不仅会使数据链路过程很长，还会引入很多数据质量、生产时间延迟的问题，直接影响后续核心报表、推荐模型的优化。
• 跨业务难度大：缺少统一的数据建设规划、标准和规范，数据链路和数据生产的环节很难有一个标准化的过程。导致多个业务的数据难以融合，难以获取更大的数据价值，造成数据获取难度提高。
• 口径不一致：在使用过程中，各业务定义的计算口径不一致，导致数据使用和分析上的差异，降低业务数据分析的效果和效率，进而对业务决策造成比较严重的影响。
• 数据资产模糊：未对公司的数据资产做整体管理时，会导致对数据资产的级别及类型模糊，从而难以发挥数据的优势。
• 资源成本高：耗费了很多计算、存储、人力资源，却未带来相应的价值，导致资源的浪费。

1.2 爱奇艺数据流向

以埋点数据（Pingback）为主的各种数据源，经过数据层的收集，到Hadoop集群或实时的Kafka流中。再经过实时或离线的处理形成各种各样的数据表或实时数据，被下游的各种数据服务和数据应用所使用。

这张数据流向图是我们在建立了数据中台后，经过了一系列的数据治理，形成的一套较好的数据流向，其中已经涵盖了数据中台各个组成部分的支持，也运用了整体数据治理的能力。

在这套数据治理体系搭建完成之前，每个团队都负责其业务线的数据处理、报表开发、数据分析及模型处理。这种模式在单个体系类问题不大，但如果最终要输出并给横向的团队使用，比如做整体的推荐、运营、用户画像时，由于每个团队或业务线所覆盖的业务场景不一样，所以每个团队在处理数据的能力和标准也不一样，这样输出数据的质量和口径也就参差不齐，就会导致下游使用时各方面成本急剧增加。特别是当业务快速发展到一定程度时，问题就会显露出来。因此，建立数据中台对数据进行治理势在必行。

1.3 爱奇艺数据中台的组成

上图展示的是我们数据中台大致的组成。中台建设完成后，我们在组织架构上需要一个团队支撑，把数据的通用能力抽象出来，并且统一维护这套通用能力，把通用能力附加在每一条业务线上，把每条业务线及其输出的数据做一套标准化、流程化的数据体系，提供给下游使用。中台化让下游应用效率和口径有明显的提升。我们做中台化的建设目标就是避免烟囱式和重复建设，实现抽象通用的公用能力。在此背景下，我们有一项重要的工作就是提供标准和规范，让大家以统一的标准去开展工作，这样的标准化流程产出的数据或其它技术能力可以快速复用。

再回到这张图上，我们数据中台最底层的是统一的云服务，包括了大数据平台（最底层的Hadoop，Spark基础服务）、调度引擎（对资源进行统一调配，对工作流进行统一调度使用）。在此基础上，建立了统一数据生产/接入，包含数据源的管理服务、离线采集、实时采集，以及对来自各数据源的数据进行数据集成。同时提供了统一的数据开发平台Babel，在这个平台中可以对数据的离线处理进行开发，以及对数据的实时处理进行流计算的开发。在此基础上引入了AI能力，将AI算法进行包装，提供统一接入的AI 开发平台。在统一数据接入和开发之上，形成了统一数据层，其主要提供数据湖和数据仓库。对于不需要建设数据仓库的比较离散的数据，比如QOS，还有自定义的埋点，将其放在数据湖中供业务使用。对于需要进行业务数据建模，形成整体数据仓库体系的数据，会对其进行统一的建模和ETL处理，形成统一的数据仓库。在统一数据层的基础上建立了统一数据服务，为业务前台提供规范化和配置化的API服务，还包括元数据的服务（提供数据资产的元数据服务能力，便于业务前台进行集成）、推理服务（可自动化发布在线推理服务，实现AI的全托管能力）。在这些模块的基础上，就可以进行统一的数据治理，主要关注点是数据质量、生产保障、数据资产价值评估、资源考核，及整个数据的使用审计和数据安全。

1.4 爱奇艺数据中台的特点

爱奇艺数据中台主要有以下特点：

• 平台化：通过建立统一开发平台、数仓平台、治理平台的方式，将数据中台的能力以可视化的方式提供给用户，为用户提供一站式的处理能力。
• 标准化：通过制定埋点规范、数仓规范、接入规范的方式对生产、采集、处理、存储和使用各个环节进行标准化的处理，降低数据理解的成本。
• 中心化：通过建设数据仓库和数据湖将数据中台打造成整个公司的数据集散中心，提高数据交换和使用效率，同时可对数据进行有效的管理。
• 智能化：通过打造机器学习和深度学习的AI平台，降低业务使用AI的技术门槛，通过托拉拽的方式就可以进行模型训练和样本特征、模型的管理，推动业务前台智能化的提升。
• 服务化：提供统一的数据服务和元数据服务能力，方便用户和业务对接，来直接管理元数据，避免数据服务的开发成本。
• 价值化：对数据中台的能力输出进行价值化评估，对各个数据的存储、计算成本、数据产生的应用价值进行整体的衡量，让有价值的数据得到更多的保障。

2. 数据治理

接下来我们简要介绍爱奇艺数据中台的数据治理实践情况，通过对数据规范的统一、元数据的集中采集和管理，提升整体数据一致性、易用性，提高资源利用率。

2.1 统一规范

2.1.1 埋点规范体系

数据离不开埋点投递，埋点投递是记录用户行为的一连串数据信息。如果投递过程缺少标准化或流程管控，就会导致埋点数据质量比较差。在我们中台建设、埋点治理之前，我们只出了针对视频播放体系的统一埋点规则，且只针对网页端，这导致后来在业务高速发展期间，各业务的埋点规则出现高度自定义的情况，进而引起了如下问题：

• 埋点体系缺少整体规划，投递数据使用难度大。使用时，不同业务中同一字段含义不一，或者在同一业务种不同时间字段含义不一。比如投递视频类型，一年之前用的是movietype，一年后用的是playertype，造成下游用户使用时产生疑惑。
• 管理力度不足，后期维护成本非常高，导致出现随用随投的情况历史延续性差、维护成本高。同时，如果管理力度过高，业务使用时可能出现约束性较强，整体埋点效率降低，这也是一把双刃剑。所以没有规范、工具和平台统一维护管理的话，大家会以各种形式传递信息，导致沟通成本高。
• 缺少共通约束和校验环节，埋点质量难以保证。没有统一的规范，就会导致后续对埋点治理的校验和监测过程中没有一个统一的标准，最终导致埋点质量难以保证。
• 字段定义不一致，导致跨业务数据使用和打通很困难。作为有不同业务、业务情况多样的公司，我们的数据在各业务线发挥的价值也就远远小于数据能跨业务打通的价值。当字段跨业务线定义产生较大差异的时候，或完全不一致的情况下，跨业务数据就很难打通，造成数据价值流失特别严重。所以我们花了很大功夫对公司业务进行重新梳理，输出了新的投递规范Pingback2.0规范。在这个规范中，我们统一对事件进行了重新定义，将投递的事件归纳为启动、退出、播放、展点、阅读、QOS等大类型，这也是我们后面在制定数仓业务域划分的依据。同时，我们统一定义了字段，建立了统一字段库，并且为枚举类型的字段定义了统一的字典，避免不同业务之间的字典歧义。我们还对埋点投递规则进行了统一的定义，各种埋点应该带有什么信息做了明确定义，并且埋点需要投递出的时机，各种各样的埋点事件在什么情况下会被触发都做了明确定。针对新的埋点规范，我们对公司的相关员工进行了培训，让大家深刻理解埋点投递的价值，对产品运营情况有深入分析。
• 在平台和工具这个角度，我们封装了Pingback SDK，来满足不同端的埋点投递工作。比如在安卓、iphone、PC上，我们都针对其平台特点，封装了不同的SDK。通过Pingback SDK，帮助业务实现埋点发送这样通用化的工作，让对应的业务开发将主要精力集中到业务上，同时帮助埋点规范制定的同学提供管理平台，并且在数据使用中提供统一的埋点测试平台和灰度阶段数据监测的平台。
• 依据Pingback埋点规范建设的Pingback埋点平台来对整体的规范进行统一的管控。业务通过Pingback SDK将埋点数据投递上来后，我们通过接收服务器，经过统一收集层进行收集和ETL后，落在hive中，同时将质量监测数据再输出到测试平台和灰度监测平台上，通过这两个环节对数据进行校验。尽可能将投递问题在上线前解决。

2.1.2 数据仓库规范体系

埋点数据关系到数据生产，数据生产后要对其进行加工，所以需要建立数据仓库。建立新的数据仓库规范体系主要是解决以下几个痛点：

• 数据重复建设和资源浪费。这个资源浪费不仅是存储和计算资源的浪费，人力资源浪费更加明显。不同业务对于同样的业务可能做的同一件事，不管对人力和计算成本都造成极大的浪费。
• 维度和指标定义混乱。能描述同一个统一指标，但是口径和名称完全不一样，或者从名称上无法知道具体算什么。另外，维度也有相同问题。口径不统一，在算转换率的时候，跨业务的统一口径，或者同一个业务在不同需求下的口径都不一致，导致后续在数据使用过程中经常出现数据撞车的情况，这就花费大量人力经历排查解决。这种排查可能还不能有结果，因为大家的口径和出发点都不一样。
• 业务处理逻辑比较复杂，每个业务都有自己特有的处理逻辑。在投递过程中可能会产生一些埋点投递的问题，所以在数据处理过程中都要把这些问题修复掉，但是修复过程中如果没有统一的处理结点，会造成每处下游都需要额外的处理，在不同下游都在进行。增大了逻辑复杂度和资源浪费。造成数据质量参差不齐。

基于此，我们重新规划了数仓规范体系。对于数据源，我们定义了埋点数据、业务数据库和第三方外部数据。这些通过数据收集形成到原始数据层，原始数据层和数据源的数据几乎是一一对应的，原始数据也就是我们在数仓中说的ODS层。在ODS层的基础上进行一定的数据清洗，形成DWD统一明细层。在DWD上对其中核心的维度进行聚合形成统一聚合层也就是MID层，同时产出累计设备库和新增设备库。有了这些数据后，在其之上，可以针对各个业务的分析主题，建立各个业务不同的数据集市，也可以针对不同的主题建设不同的主题数仓，比如可针对流量主题，围绕流量定义，去建设流量的数仓体系。为这些提供基础就是维度和指标的统一。以此为基础，对上层的报表分析等应用提供技术支持。

为了支持规范的落地，我们建设了数仓的管理平台。数仓的管理平台对数据维度和指标管理提供系统性的支持，提供了统一的维度和指标的管理工具，对外可以输出统一的指标和维度。同时从这个统一的管理和维度平台可以查到标准的维度定义和指标口径定义。同时从此系统拿到一个集中管理的元数据。同时，支持数据建模体系的完整性。在拿到一个数据后，可以在数仓平台上进行三步建模流程。首先，针对业务特点进行数据建模。在数据建模后，针对物理特征进行物理建模，最终落地到符合约束条件的数据表。同时基于此平台，我们的数据信息有更好的可描述性，因为在创建表的过程中，可以把我们需要的业务信息描述的足够清晰，方便后续的使用过程。同时，因为有这个平台的存在，数据关系有了可追溯性，因为通过数仓的建设和建模过程，后续的数据表和字段之间相互关系有记录可查询，也就是我们所说的数据序言的关系，这样用户获取数据就变得非常容易。比如用户想计算昨天《叛逆者》最新一集的播放量用户是多少，以及其中和《爱上特种兵》播放最新一集的重合用户有多少比例，那么我们就只需要明确我们需要计算指标是视频播放的UV另外是视频播放的重复UV，维度是视频ID。通过数仓平台，可以检索出我们需使用的数据模型和对应的数据表，这样开发人员和分析人员就可以去对应的表中进行数据查询。同时基于这些信息也可以做一些智能化的事情，比如结合NLP，运营人员可以通过输出一个自然语言，我要知道昨天《叛逆者》最新一集的播放用户量，然后通过我们的数据智能辅助工作，从这个语言中提取出需要计算的指标及其对应的口径和维度，以及口径和维度最适合的数据源，来自动生成查询，直接获取数据结果。

2.2 元数据

2.2.1 管理

元数据是描述数据的数据，我们建立元数据中心就是统一管理需要给用户展示的信息，包括基础信息、数据资产。除开这些元数据之外，我们还有些数据标准是通过元数据的管理对外进行呈现的，这些信息构成的是结构化的信息，我们可以将这些信息构建成有导向性的业务图谱，在需要查询这些信息时，我们可以从业务角度出发，一层层圈定出需要查看的数据资产信息。把这些元信息集中收集管理后，就形成我们元数据图谱。元数据图谱可使数据使用方更快更高效找到所需数据，对数据的理解和使用也更简单。

2.2.2 数据血缘

数据血缘是元数据中比较重要的方面。数据血缘我们主要关注数据资源的上下游，即数据从哪里来，有哪些下游继续使用，这些下游的产出又都是什么。通过数据上下游关系，我们可以构建出数据的全链路序列，可以自动或人工标注出链路的重要性，比如依赖多的数据重要性比较高，同时根据下游的重要性，向上综合计算出数据本身的重要性，这也是对其影响度的分析。有一些新上线的资源本身很重要，但依赖还不多甚至没有依赖，这个时候需要人工标注这个数据是不是重要数据。

2.2.3 数据变更检测

基于血缘链路的分析，可以把另外一件事简单实现，就是对于数据变更的检测和周知。在平时数据生产中，一件非常容易出问题的工作就是在发生数据Schema或处理逻辑变更时，或在数据需要修复重跑时的下游通知问题，如果我们没有完整的数据血缘关系，下游又非常多，我们的通知就可能发生遗漏，甚至有时变更一些数据定义或Schema时，没有完善的流程约束，就可能忘记通知下游。所以基于数据图谱和开发平台，构建了一套可以自动过监测数据变更的系统，同时在监测到数据变更之后，会自动对所有下游进行通知。下游在确认接到通知后，可以决定是否要对其计算进行重新执行或逻辑上的调整。能构建这样一个平台就是因为我们对数据所有的Schema元信息以及生产相关的记录都会保存在数据图谱中，开发平台所产生的工作流的变更记录也会写入图谱中，这样数据图谱就会很容易自动感知到数据变化，结合自己存储的血缘信息，就可以将变更通知一层层向下传递。

2.2.4 自动采集

接下来看一下元数据自动采集的架构。血缘采集就是把数据资产通过血缘的形式体现出来，让每个数据知道自己的上下游，在变更时及时通知。这个采集一方面通过Hive、Hook的采集，来采集Hive表之间的序列，或通过SparkHook来采集Spark的生产数据，还有通过埋点系统里存储的一些信息，知道这个数据是从Pingback来的，还有数据开发中工作流的信息，来辅助明确数据的生产上下游，以及数仓平台中的维度指标以及数仓平台中定义出的数据模型和埋点之间的关系，来获取数据上下游的信息。另一方面从各个系统中采集数据元数据定义，比如从Hive Metastore取数据表的元数据定义，从Kafka中获得实时流的定义域以及从各种数据库、数据报表、数仓中获得报表的上游、下游，数仓各个层级表的关系。这些消息通过消息队列和API自动进入到数据图谱的处理流程，将这些信息包装成技术元数据或者业务元数据，存储到ES或JG中，供下游进行使用。

2.3 数据安全

数据安全方面，我们是通过业务信息、资产评级以及敏感程度来评估的安全评级，这样决定了资源审批和审计的几个级别。通过权限系统来管理业务开发项目，以及用户和具体数据资源之间的联系，决定一个用户对一个资源是否有读或写的执行权限。所有的数据资源必须经过审批才能使用，包括对数据的查询和二次开发，相关的申请记录、开发记录、消费记录都会记录在审计信息中，然后再存储到元数据图谱中，以为后续审阅。

2.4 治理收益

通过对埋点规范统一和治理，下线了40%的无用埋点，极大节省了代码的存储资源，提升了APP性能，节省了计算资源。通过下线埋点数据和对数仓进行重构，下线无用的数据表，节省了45%的存储资源和35%的计算资源。

3. 生产治理

生产治理主要为了保证数据质量，数据产出的及时性和准确性。

3.1 数据质量保障

通过在不同阶段的一些治理手段，对整个数据的质量进行保障。在测试阶段对数据的合理性进行验证，在测试阶段通过一定的验证规则确认产出的数据是合理的，它的上下游数据是一致的。同时通过各种交叉检验去确定数据是不是准确的。如果验证通过的话，可以进行上线。数据在线上监管的过程中有一个监控的机制，对数据质量进行监控，如果发现生产过程中出现数据异常，就会对生产流程进行拦截，并报警。避免错误数据发布到下游。发出错误数据比数据生产延迟更加严重。发现异常之后会对数据进行治理，治理主要是对问题进行排查定位，根据排查定位得到原因，进行修复。修复后重新上线，如确认问题不是问题的话，直接进行放开。

3.2 埋点数据的质量保障

埋点数据的质量保障是数据质量保障的根本。在需求阶段就要求产品经理在将需求相关的数据定义和场景定义要描述清楚，制定出清晰合理的规范，确定规范是合理且必要的。需求提交后，会有专人对埋点定义的合理性、完整性和对于需求的覆盖情况进行评估和审核。开发阶段，具体的开发基于需求文档进行业务开发，通过埋点SDK将数据进行上报。测试阶段，测试人员根据在埋点平台中定义的埋点规范和场景管理定义的埋点场景进行自动化测试。测试没问题就进行灰度上线，灰度上线会对于数据核心指标和场景埋点规则进行实时监测，有问题就会下发给开发进行处理。没问题就可以直接上线，线上过程中持续不断对数据质量进行监控。

3.3 数据生产链路保障

数据生产链路保障主要是基于统一数据开发平台所提供的能力，对工作流进行统一的开发和管理，所有的工作流上线前都会经过一个测试。测试关注可靠性、稳定性及处理前后的数据是否有问题。上线后，统一开发平台会对业务提供管理和运维的功能支持，同时提供监控和报警的功能，主要是对数据质量规则进行监控。

出于灾备的考虑，统一数据开发平台还提供生产链路HA的功能。我们一般重要的工作流都是在双集群或者更多的集群运行，如果其中一个集群出问题，或者运行较慢，另外一个集群先产出，会使用正常产出的集群的数据，最大程度保障数据的可靠性和稳定性。

3.4 数据质量检测平台

为了更好监测数据质量，我们建设了数据质量监测平台。在此平台中，我们基于事先制定好的监测规则把它配置到这个平台里去。通过对数据整体和抽样统计，对数据各种变化情况进行监测。比如可以监测增长率，字段值分布比例的变化，把前一天、上周同一天的数据进行同比和环比变化情况的校验，以及对数据绝对值进行校验。

数据检测平台所输出的监测规则和任务是可以作为一个工作流的结点集成在之前数据开发的工作流中，起到对工作流进行拦截的效果。一般拦截会发生在数据生产完毕后，如果发现数据疑似有问题，会暂停数据完成标识。如果确认数据没问题，直接触发生产表示。这也避免数据误报，就会浪费计算资源和时间。

在做质量监测的时候，我们发现在校正当前数据中，更多的是对历史一段时间数据规律切合的校验。在这个过程中，有时并不会发现数据有问题，或者临时的数据异动，比如节假日产生的用户状态的变化，可能造成异常的数据波动，但这数据波动没问题，会出现比较多的误报警误拦截。所以为解决这个问题，在调研各种技术后，发现可以通过Prophet提供的基于时序预测的功能来进行数据质量监测。Prophet对于明显有一个时序内在规律的行为数据进行数据预测比较使用，最好有一年以上的历史数据，进行每小时、每天或每周的观察，并且有一个比较强的季节趋势，这很符合我们流量对于季节的特征，在节假日流量很高。在这种情况下，用Prophet就很合适。通过实践，我们发现在今天的元旦和春节，基于时序的预测校验有一个不错的效果，整体的误报非常低。

4. 后续规划

后续，我们想在智能化上进行一个深入的建设。结合全链路机器学习和深度学习能力来进行资源的智能调配，对数据资源进行智能监测，如果出现问题，对问题进行自动分析和排查。

服务化会升级元数据服务能力，让业务更容易使用数据中台提供的数据支持。

价值化针对各种数据进行资源消耗的评估，同时结合数据的使用情况和流行度进行ROI的评估，来保障高价值数据的可靠性。通过对查询任务和数仓表分析来评估数仓建设的合理性和健康度，对数仓建设内容进行实时调整。对使用率过低的表进行合并或下线，对平台使用的底层表进行更上层的汇聚来提升ROI，降低资源消耗。

原文：数据口径多，埋点质量低，难治理？数据中台解困局！