爱奇艺数据中台建设方案
数据中台的产生：数据工作的痛点、数据中台的产生、中台的实质
爱奇艺数据中台的定义：理解数据中台、数据中台的发展历程、输出和定位
爱奇艺数据中台的建设：中台建设、Pingback体系、数仓体系、数仓平台、离线数仓架构、大数据平台、数据平台架构
数据中台的应用场景：统一化、个性化、定制化
使用门槛高：数据工作是一个专业性特别强的一个工作，对于人员的要求比较高。
口径不一致：在使用数据过程当中，口径不一致是特别常见的一种问题，这种问题可能会导致一种数据使用和分析的差异，而且会降低业务的数据分析效率。
数据可靠性低：在生产过程中，降低业务的数据分析效率，最终会对业务决策造成严重的影响，不仅数据链路过程很长，其中还会引入很多数据质量问题。
跨业务难度大：因为缺少一个统一的数据建设的规划、标准和规范，所以难以指导各个业务或者整个生产链路的各个环节，以拥有一个标准化的生产和处理过程，就导致了多个业务的数据难以融合，难以发挥更大的数据价值。
接入成本高：如果有新的业务接入或者新的场景需要使用数据，很多工作都需要人工处理。去申请各种资源、权限、找数据并且串联整个数据的采集、生产、计算、同步和展示等各个环节，这是一个耗时长、效率低，最终还是很容易出错的过程。
投递质量低：说到数据的话肯定离不开投递，投递是用来记录用户行为的一连串的数据信息。如果投递过程缺少标准化或者流程管控的话，都会导致投递质量比较差。
获取数据难：数据的生产到最终使用，中间可能要经历一个比较长的时间周期或者一个比较宽的团队跨度，用户可能无法很快地找到想要的数据，或者数据团队生产出来的数据并没有真正触达到业务，来达到它的数据价值。 数据资产模糊：这个点可能和获取数据难有一点点关联，数据资产模糊的话更多的是在说需要对公司的数据资产做一个整体的管理，如果没有这个整体的管理，就会导致对数据资产的级别和拥有什么数据资产都很模糊。最终就是导致数据的优势难以发挥出来，而且虽然耗费了很多计算资源、人力资源、存储资源，但没有带来相应的价值，最终导致资源效率极低。
数据中台更像一种企业架构，是一套结合互联网技术和行业特性，在企业发展的不确定性中，寻找确定性，并且持续沉淀和抽象企业核心能力，最终支持企业快速、高效、低成本进行业务创新和增强的企业架构。
数据后台：
大家平时更多用到了大数据集群，也就是说Hadoop、Spark、Flink以及其他OLAP工具。但是这些只是数据后台的一个概念，并没有做成一个标准化、通用化、门槛相对来说比较低的中台化的概念。
数据中台：
数据中台其实是一个数据即服务的产品概念，它包括了数据服务、数据平台、数据中台产生的数据以及在所有的数据工作中产生的标准和规范，这一些组成了我们所谓的数据中台。
数据前台：
数据前台就是我们实际的产品落地的具体例子，主要包括了几个大的方向：
分析体系，比如说用户分析、内容分析、业务报表等；
数据应用，比如说即席查询、可视化查询工具；
数据产品，类似于画像和推荐业务，可能都是一些数据最终形成的产品，直接面向用户服务。
所以数据中台抽象出来，就是指“平台+服务+数据+标准化”的概念，它是将数据的生产、收集、处理、存储和服务进行封装，并且面向不同层级的用户提供不同的服务形式。在数据标准化过程中，数据中台可以防止数据重复建设，避免口径问题，提高数据的使用效率。
说到数据中台定位，因为数据中台和前台、后台都需要有一个明确的划分，数据中台定位提供了这种抽象通用的能力来支持前台团队在此基础之上进行定制化，最终在复用通用能力的同时，能够满足业务快速发展的个性化的需求，达到一个全局最优化的状态。
主要从五个角度去输出中台能力，分别是服务、数据、平台、投递、标准/规范。在爱奇艺数据中台的实施过程中，划分出了三个大方向：
生产，也就是我们所说的投递体系；
数据，也就是统一数仓的体系，是数据的核心；
大数据平台能力：包括开发、治理、服务。
日志投递：
这部分输出了投递规范，进一步针对投递规范，需要对公司的相关员工进行培训，让大家深刻地理解投递是为了做什么，并且怎样才能达到我们对于用户的行为足够深入的分析要求。
大数据平台：
有一线开发、对应的运维管理、实时开发对应的运维管理，以及数据治理、数据图谱、数据服务和即席查询。即席查询是我们数据服务里的一个子项，但是因为应用面比较广，就单独拎出来了。
统一数仓：
统一数仓的能力也就是为下游提供离线和实时的两种数仓能力。为了方便大家实现跨离线和实时混合使用的场景，需要进行标准化的工作，也就是离线输出的字段、定义、口径、格式和实时数据要尽可能一致，即实时数据向离线数据看齐。
数仓在提供数据本身的能力之外，还要维护整个公司级别的指标体系和统一维度，让所有的数据系统平台和都会对接到统一的维度指标体系。而且，为了帮助数仓建设过程中的数据建模和统计指标的管理，建设了一个对应的数据平台，也是按照数据规范的标准建设，以此来支持使用方使用平台依照规范去建设数仓的流程化工作。
Pingback的体系就是投递体系，那么具体为什么要做这个事情呢？
投递工作面临的问题主要有以下几个点：
数仓体系几个要解决的痛点：
数仓平台的特性：
数据表创建的约束性：比如我们需要对表有的命名规范要求，如果没有一个工具去管理，可能会因为大家对规范的理解不一致，最终导致落地过程中依然存在各种各样的差异性； 数据信息的可描述性：指在创建表的过程中，为了快速地满足业务，很少去添加一些相关的描述信息，导致数据缺少描述性。所以需要通过平台，要求用户在数据创建的过程中把信息描述的足够精细，方便后续的数据使用过程； 数据建模体系的完整性：指我们需要一个三步的建模过程，即业务建模后，有对应的数据建模；数据建模之后，针对这个数据建模，有不同的物理建模的形式。整体是一个流程化的工作，避免用户为了快速地满足业务需求跳过某些过程，最终导致建模的扩展性较差； 数据关系的维度与指标管理的系统性：通过提供一套统一的维度和指标管理体系来作为一个中心，对外输出统一的指标和维度，让大家在使用的过程中，可以使用这些标准化后的并且集中管理的元数据； 数据关系的可追溯性：是指通过数仓建设、建模的过程，促使我们后续数据表和字段的相互关系是有记录可查询的，也就是我们所说的数据血缘关系。
下面是数仓的简化架构，主要是体现了离线数仓部分。其中带颜色的一部分是统一数仓，其他的浅颜色的就是一些数据应用，包括数据集市和主题数仓。
爱奇艺大数据平台经历了五个阶段：
开发：在第一阶段完成了整个数据开发的平台化、可视化能力，降低了开发门槛，并提升开发标准化。
运维：在开发之后，需要提升任务的管理和运维能力。通过建设运维管理模块的建设，保证用户更方便地对任务进行管理，并且对任务产出的稳定性和数据产出的时效性实现了有效的监控。
质量：在提供了数据开发和管理相关能力之后，需要进一步对数据产出进行质量校验，避免生产出的数据在未关注数据质量的情况下直接被使用，造成数据问题的快速扩散。
使用：数据使用也是一个数据发现的过程。比如生产了很多数据，如何让用户看到这些数据，并将其更好地应用在业务需求当中。针对这个痛点，完成数据图谱模块的发布，把各种的数据元信息进行收集、加工、管理，最终把完整的数据信息以一种更友好的形式提供出来，帮助大家快速地发现数据，进一步去了解数据元信息、快速准确地使用数据。
治理：是数据生态的最后一个环节，也是打造健康生态闭环的重要部分。有的公司可能是把治理放到比较靠前的环节，但是在一些场景下，比如说业务快速发展的过程中，治理往往是跟不上业务需求的。所以爱奇艺采取的方式是，等业务发展到一定程度，再去补充数据治理的能力，对存量去治理，对增量去管控。治理工作的内容主要包括对数据和任务进行日常审计，然后通过数据血缘和使用情况，对数据的冗余度进行有效评估，并进行相应的优化，以减少资源和人力的浪费。
最底层是数据层，比如投递服务器的日志，包括业务的数据或者其他数据来源，通过采集层和传输层达到我们的计算层。
计算层，更多的是大数据集群服务，也包括一些任务调度能力。
平台层包括离线和流式任务的开发管理、机器学习平台、数仓平台，然后下面是对于整个的数据的ETL的一个平台化的处理，还有外部数据的一个同步能力的模块，称为数据集成。在拥有这些开发能力或管理能力的同时，还需要对投递管理、数据安全、数据质量、数据图谱做一些有效的建设，并且在整个数据体系中去做数据治理工作。
服务层是以即席查询、实时分析，数据服务、元数据服务多种形式对下游提供服务能力。
数据中台的应用场景，面向不同阶段来提供不同的接入方式：
第一个阶段是统一化的形式。有一套通用的模板，它的优点和缺点都很明显，优点是接入起来很简单，缺点就是不够个性化和定制化，只能支持这种通用的数据能力。所以它比较适合于业务初期，能够进行快速接入，并且自动化地完成这种数据的处理和服务； 第二个阶段是个性化的能力。把整个流程确定下来，业务在使用过程中可以针对某些环节做定制化的开发，拓展现存数据模块的能力来满足一些个性化需求，所以它更适用于业务的成长期的阶段； 第三个阶段是定制化的能力。定制化更多面向一些特别成熟的业务，也就是对于数据这一块的需求有多方面的、深层次的使用场景，并且通用的和个性化的架构已经不足以满足数据需求的情况下，可以采用定制化的能力。定制化能力也就是我们提供数据模块化的能力，然后业务再根据自己的需求去对应选取这些模块化能力，并进行组装和扩展，来满足自己定制化的需求。
作者：马金韬 原文：dbaplus
end
公众号(zhisheng)里回复 面经、ClickHouse、ES、Flink、 Spring、Java、Kafka、监控 等关键字可以查看更多关键字对应的文章。
点个赞+在看，少个 bug 👇