一、爱奇艺数据中台概况

　　1.数据中台支撑业务发展　　

　　上图展示了爱奇艺的数据业务链路。数据中台的主要职责是制定数据标准，集成来自用户、业务和合作方的数据。通过规范和系统，数据中台对数据进行综合管理和治理，确保数据安全，并为上层业务提供服务支撑。

　　数据科学家们利用数据中台提供的数据服务，提取有价值的信息，为上层决策提供支持并推动创新。通过科技创新，赋予内容生产与分发更强的能力，为用户提供在各种智能终端上的卓越视听互动体验。　　

　　数据中台的核心使命是有效管理和治理所有数据，并以尽可能低的成本实现数据的最大价值。

　　为了达成这一目标，我们需要对数据体系的各个环节进行标准化操作，并制定相应的衡量标准。这不仅有助于确保数据的质量，还能提高数据处理的效率，从而确保数据治理工作的顺利进行。

　　在此基础上，我们构建了高效的数据处理链路，以形成完整的数据体系，满足各业务部门对数据的需求。通过结合数据处理技术和人工智能技术，我们能够显著提高数据处理效率，使得不同层次的用户、运营人员、数据分析人员及数据科学工作者都能轻松地使用数据，并从中获取有价值的洞察和决策支持。这不仅有助于推动业务创新和增长，还能提升公司的整体竞争力。

　　2.数据工作发展过程　　

　　1）零散态

　　在早期，我们直接将原始数据生成到数据报表层级，并存储在Hadoop集群中，这种方式在业务较为简单时能极大发挥生产效率。然而，随着业务变得越来越复杂，理解和寻找数据的难度逐渐增加。普通用户需要反复询问数据如何使用、如何查找，或者将数据需求交给数据工作者完成，这会对整体效率产生很大的影响。

　　2）平台化

　　从2018年开始，我们致力于构建一个平台化系统，以提高数据生产、收集的效率。我们建立了离线开发平台和实时开发平台，为用户提供更便捷的数据获取和处理方式。

　　3）标准化

　　为了更好地规范数据使用，我们重新定义了数据标准，并为所有行为制定了相应的埋点投递规范。这不仅提高了埋点工作效率，还降低了业务埋点错误率，使产品更好地了解设计埋点的方法。

　　同时，我们规范了数仓体系，统一了维度和指标，以建立更好的数据服务平台。

　　4）智能化

　　基于以上建设基础，我们建立了机器学习平台和深度学习平台，以提高数据质量要求。通过建立数据质量模型，我们可以更好地监控和处理数据。

　　5）体系化

　　从2021年开始，数据中台牵头成立了数据规范工作组，定义了整体数据规范，并提供衡量标准，对数据治理工作进行整体效果评估。

　　同时，我们引入新技术以提升数据处理效率，为用户提供更优质的服务。

　　6）立体化

　　通过调研业界新技术，我们引入了数据湖和流批一体处理技术，并对链路进行了近实时化改造。通过对链路进行近实时化改造，我们实现了更高效、更灵活的数据处理和分析，从而更好地支持业务决策。

　　二、数据湖体系介绍

　　在数据的早期阶段，由于数据的分散和难以获取，形成了许多数据孤岛，这些孤岛未能及时得到有效的整合和管理，逐渐形成了数据沼泽。

　　为了解决这个问题，我们开始进行数据治理，首先对数据仓库进行治理，重新制定了数据仓库的统一规范，建立了统一数据仓库和和数据集市，进而形成了数据池。在这个基础上，我们对整个数据体系进行了梳理和整合，建立了一个能够存储所有数据、方便查找和使用的数据湖体系。

　　1.数据链路　

　　上图描绘了爱奇艺数据链路的构成情况。

　　在数据生产层，数据来源主要分为两类，即C端和B端。

　　C端数据，主要源自用户终端，具体包括终端埋点数据和终端日志。而B端数据，则来自身服务后端日志、合作方数据，以及视频信息、内容信息等重要业务数据。

　　这些数据经过接收层和采集层的收集，收集到数据中台。在加工层，部分数据会被处理成为统一数据仓库，整体以数据湖方式提供，专业的数据工作者对这些数据进行分析，进一步挖掘其价值。

　　他们会进行用户画像，通过数据来描绘出每个用户的特征和喜好；也会进行内容理解，将数据拆解成不同的内容模型，以提供决策支持；此外，他们还会进行报表分析，报表是使用最广泛的数据呈现方式，各级用户可以通过观察报表的数据变化，直接了解业务情况。

　　基于这些数据，数据工作者还通过对用户个性化推荐，对内容更为智能地进行分发，让用户能够接触到自己最感兴趣的内容。

　　2.数据架构　　

　　基于数据链路情况，我们结合数仓建模和数据湖的思想，打造了融合了数据湖思想的数据中台架构。

　　底层数据层主要囊括各种数据来源，Pingback是埋点数据，主要用来收集用户行为，业务数据主要存储在各种关系型数据库和NoSQL数据库；数据层的数据通过传输层的各收集工具，存储在存储层。

　　存储层从根本上来说都是存储在HDFS这个分布式文件系统中，原始文件直接存储在HDFS，其他结构或非结构数据，存储在Hive、Iceberg或HBase。

　　在计算层，使用离线引擎Pilot驱动Spark、MapReduce或Trino进行离线计算，使用调度引擎Gear进行工作流调度。使用Europa调度流式计算，经过几轮迭代，目前流式计算主要使用Flink作为计算引擎。

　　在计算层之上的开发层，通过对计算层和传输层的各个服务模块进一步封装，提供了用来开发离线数据处理工作流、对数据进行集成，开发实时处理工作流，开发机器学习工程实现等完成开发工作的工具套件和中间服务。

　　其中数据湖平台，对数据湖中各个数据文件与数据表的信息进行管理，数仓平台数仓数据模型、物理模型、维度、指标等信息进行管理。

　　纵向，投递管理工具管理数据中台最主要的数据，Pingback埋点数据的规范、字段、字典、时机等元信息；

　　元数据中心、资源中心等模块用来维护数据表或数据文件的元信息，以及保障数据安全；

　　数据质量中心和链路治理平台保障数据质量和数据链路生产；

　　底层服务由云服务团队提供私有云和公有云支持。

　　上层提供数据图谱作为数据目录供用户寻找所需要的数据。提供魔镜、北斗等自助应用，供不同层次的用户自助进行数据工作。

　　整个架构体系，在数据的集成和管理上，更加灵活，可以容纳所有数据，并通过对自助工具的优化升级，降低用户使用门槛，满足不同层次用户的需求。提高数据使用效率，提升数据价值。

　　3.数据体系　　

　　数据中台建立的目的是解决数据的激增与业务的扩大而出现的统计口径不一致、重复开发、指标开发需求响应慢、数据质量低、数据成本高等问题。两者在一定程度上目标一致。我们结合数据湖的理念，对数据中台的数据体系进行了优化升级。

　　在数据中台建设的初始阶段，我们对公司的数仓体系进行统一，对业务进行调研，并整理已有的字段维度信息，归纳出一致性维度，并建立统一指标体系，制定出统一数仓规范，构建了统一数仓的原始数据层(ODS)、明细数据层(DWD)、聚合数据层(MID)，并构建了设备库，包含累积设备库和新增设备库。

　　在统一数仓之上，数据团队根据不同的分析统计方向和业务具体诉求，构建了主题数仓和业务集市。主题数仓和业务集市包含进一步处理的明细数据、聚合数据以及应用层数据表，数据应用层使用这些数据，向用户提供不同的服务。

　　在统一数仓体系中，原始数据层及以下是不开放的，用户只可以使用数据工程师处理加工后的数据，不可避免的会有数据细节损失。在日常使用中，常常会有具有数据分析能力的用户希望能够访问底层原始数据，进行个性化的分析或者排查问题，所以我们引入数据湖的数据治理理念，以数据湖的分区管理方式对数据进行整理，同时对数据元数据进行丰富，构建好数据元数据中心。

　　经过数据湖理念的治理，将原始数据层和其他原始数据，比如原始日志文件，归置到原始区，该区域有数据处理能力的用户可以申请权限使用。

　　统一数仓的明细层、聚合层以及主题数仓、业务集市归置在产品区，这些数据已经经过数据团队的数据工程师加工处理作为最终数据成品提供给用户使用，该区域的数据经过数据治理，对数据质量有保障。

　　为敏感数据存放划分敏感区，重点管控访问权限；

　　用户以及数据开发人员日常产生的临时表或个人表，该区域的数据表由用户自行负责，可以有条件的开放给其他用户使用；

　　通过元数据中心维护各数据的元数据，包含表信息、字段信息，以及字段所对应的维度和指标，同时维护数据血缘，数据血缘包含表级别的血缘和字段级别血缘；

　　通过数据资产中心维护数据的资产特性，包含针对数据级别、敏感性和权限的管理。

　　为了让用户更好地自助使用数据：

　　在应用层提供数据图谱，作为数据目录，供用户查询数据，包含数据的用途，维度、指标、血缘等元数据，同时作为权限申请的一个入口；

　　同时提供自助分析平台，为数据用户提供自助分析的能力。

　　4.数据湖是一种治理数据的理念　　

　　在我们数据中台体系建设过程中，数据湖是作为数据治理的手段使用的。

　　数据湖作为一种数据治理思想的价值在于：

　　1）能够存储所有数据，不管是当前用到的，还是暂时用不到的,确保数据需要使用的时候能够查到需要的数据；

　　2）数据湖存储的数据经过科学的管理，不再需要数据工程师高度参与，用户可以自助地查找数据和使用数据。

　　更灵活更便宜的数据存储：HDFS存储，从三备份到单备份辅之其他校验方式，进行无损存储，进而节省机器资源。引入Iceberg表尽量替代Hive表，表存储更加灵活。

　　更全的数据：提高数据及时性，存储更全的数据，保证原始数据开放，以备不时之需。但存储是有条件的，要遵循一定的生命周期。

　　更容易的数据查找：以尽可能低的成本存储更多的数据，赋能数据查找，所以开发数据图谱工具，方便用户查找数据。

　　更便捷的数据集成：开发BabelX、Acciolog、Venus工具。

　　更高效的数据使用：魔镜是自助查询工具，用户可定制计算。Babel供开发者在此平台上开发自己的数据处理流程。北斗是运营分析工具，对用户标签进行分析，比如分析内容的不同受众。

　　更可靠的数据管理：元数据平台、数仓平台、数据链路治理平台、数据资产平台。

　　5.数据湖是一种数据技术实现　　

　　数据湖也是一种数据技术实现。因为数据湖的特点存储所有数据，从技术角度来看，必然研究如何高效集成和处理数据，由此产生了新的存储格式和流批一体架构。数据湖的优势是，能够支持海量数据实时更新，降低存储、计算成本，解决传统数据处理流程的痛点。

　　三、数据湖技术对比

　　调研数据湖技术的过程中，调研过被广泛使用的三种数据存储格式：Delta Lake、Hudi和Iceberg。

　　1.Delta Lake vs Hudi vs Iceberg　　

　　上图是三种技术的特性对比表格，记录了调研当时的情况。

　　经过综合评估，我们选择了Iceberg作为数据表的存储格式。

　　2.Iceberg是一种表格式　　

　　Iceberg是一种新设计的开源表格式，它支持对象存储、HDFS文件存储，其存储表支持行级更新和行级事务。它并不是查询引擎，只是能够更好地存储数据。

　　3.Hive vs Iceberg　

　　相对于Hive表，Iceberg表最大的优势是可以更好的支持行级更新，数据时效性可以提高到分钟级，所以在数据处理时，数据及时性可以极大提升，于是在数据处理ETL上，可以方便地改造既有的Lambda架构，实现流批一体架构。

　　四、数据湖业务落地

　　1.在服务日志数据的应用　　

　　在改造之前，我们使用Venus工具从不同的服务物理机中抽取日志并发送到Kafka。然后，通过实时通路将这些数据插入到Elasticsearch中，以便在查询平台进行查询。然而，Elasticsearch的部署成本相对较高，因此整体成本也居高不下。

　　除此之外，Elasticsearch还存在稳定性方面的问题。如果Elasticsearch出现单节点故障，可能会影响到写入和查询功能的正常使用。因此，我们决定使用Iceberg替换Elasticsearch。通过直接使用Spark或Trino，我们可以查询Iceberg表中的数据。

　　由于Iceberg是构建在HDFS之上的，因此我们可以利用HDFS集群进行存储，从而有效地降低了存储成本。

　　在将数据从Elasticsearch迁移到Iceberg的初期，我们注意到查询速度有所下降。然而，对于整体应用来说，这种差异是可以接受的。在进行日志查询时，5分钟和2分钟的查询时间差异并不大。因此，我们一直在持续优化查询性能，目前已经能够实现秒级查询。

　　2.在用户标签的应用　　

　　用户标签是通过对用户数据进行深入分析，并为每个用户打上特定的标签，为运营、广告、推荐等业务提供重要参考。

　　在旧的架构中，我们通过将消息写入Kafka队列，再实时写入到HBase，部分离线数据天级批量补入Hbase对数据进行修正，标签服务基于HBase通过接口提供服务，定期从Hbase导出快照到Hive提供离线分析。

　　然而，这种架构存在一些问题。

　　首先，数据导出速度较慢，只能实现天级别的导出，导致分析时效性较差。其次，在后续使用中发现Impala运维成本较高且性能不稳定。

　　引入Iceberg后，我们对架构进行了调整。目前，写入数据的同时，会将实时更新信息和HBase的更新信息一并写入Iceberg。由此可以实现近实时的数据通路。使用Spark SQL或Trino进行查询时，查询效率非常高，大大提高了确认效率和数据通路效率。

　　改造后的业务效益显著提高。我们不再需要完全依赖HBase，实现了资源复用和低运维成本。同时，我们提高了数据处理速度和查询效率，更好地支持了广告推荐等业务场景。

　　1）旧架构痛点

　　实时写，通过开发实时写入到HDFS中，进行离线处理，从离线数仓批量写入HBase中进行数据校正。我们的服务主要是基于HBase进行接口支持。离线分析是将HBase全面导出到Hive表里，实现离线支持。

　　在旧架构中，使用HBase为参与引擎。由此，数据导出速度慢，天级才能导出，分析时效性较差。另一方面，在后续使用中发现Pilot性能及运维成本较高。

　　2）改造后业务效益

　　引入Iceberg后，将架构调整成写入Iceberg的同时，将实时更新信息及HBase的更新信息写入，使用近实时的通路。通过Spark SQL或Trino查询时，查询效率非常高，提升确认效率和数据通路效率。

　　3.在CDC订单数据的应用　　

　　CDC订单数据的应用场景是通过MySQL实时分析binlog，将数据更新到Hadoop集群，实现离线查询。

　　在引入Iceberg之前，我们使用MySQL每天全量导出到Hive或增量同步到Kudu的方式进行离线查询，难以适应即席查询的场景。此外，旧架构还存在时效性差、成本高等问题。

　　通过引入Iceberg，我们实现了流程简化、查询效率提高和时效性从天级降低到分钟级的效果。

　　同时，不再需要Kudu节点，实现了资源复用和低运维成本。改造后的业务效益显著提高，为我们的数据处理和分析提供了更加高效和灵活的解决方案。

　　4.在广告数据的应用　　

　　广告数据涵盖了广告点击日志与用户观影日志，这些日志支撑着广告算法模型的及时更新，为广告引擎投放广告提供助力。

　　原本的处理途径是使用Hive进行离线数据分析，天级或小时级更新数据模型，然后于Hive和Kudu中形成可供算法调用的新模型。

　　目前我们引入了Iceberg，以Kafka的实时数据为基础，通过流批一体方式进行离数据处理，这些数据进入Iceberg表后，我们利用Spark和Trino进行算法侧的分析，并快速加载到引擎侧。这样的处理方式将原本需要半小时以上的全链路流程缩短至7-10分钟，同时将原本的几套架构体系简化为Iceberg流批一体的架构。

　　5.在埋点投递的应用　　

　　Pingback埋点投递是整个数据通路中最重要的通路，Pingback埋点数据包括用户的启动退出、页面展示点击和观影数据，整体业务基本围绕着这些数据进行，是数据中台统一数仓的主要数据来源。

　　在引入数据湖技术之前，数据中台的数仓处理，使用离线处理和实时处理结合的方式提供离线数仓和实时数仓。

　　全量数据通过传统离线解析处理的方式，构造成数仓数据，以Hive表的形式存储在集群。

　　实时性要求高的数据，单独通过实时链路生产，以Kafak中的Topic的形式提供给用户使用。

　　这样的架构有以下几个问题：

　　实时和离线两条通路，除了最核心的处理清洗逻辑，需要维护两套代码逻辑，在有规则更新时，需要实时离线同时更新，否则会产生不一致；

　　离线链路小时级更新，且有1小时左右的延迟，即00:01的数据可能在02:00才能查到，部分有一定实时要求的下游业务接受不了，需要支持必须上实时链路；

　　实时链路虽然实时性在秒级，但成本较高，且大多使用者不需要秒级更新，五分钟级足够满足需求，且Kafka流的消费没有数据表方便。

　　对于这些问题，Iceberg表+流批一体的数据处理，可以较好的解决上述问题。

　　主要的优化操作是对ODS层的表和DWD层的表进行Iceberg改造，同时将解析和数据处理加工改造为Flink任务。

　　在具体实施时，为了保障数据生产的稳定以及数据的准确性不受影响，我们采用如下措施：

　　先从非核心数据开始切换，根据实际业务情况，决定先以QOS投递和自定义投递作为试点；

　　对离线解析逻辑抽象后，形成了统一的Pingback解析入库SDK进行实时离线统一部署，使代码统一；

　　Iceberg表部署完成并开始生产后，先进行了两个月的双链路并行跑，并对数据进行常规化的对比监测；

　　确认没问题后，对上层使用进行无感知切换；

　　核心数据相关的启动、播放数据，待整体验证稳定后再进行流批一体改造。

　　改造后，收益如下：

　　qos和自定义投递数据链路整体实现了近实时化。小时级延迟的数据达到五分钟级更新。

　　除特殊情况，流批一体链路已可以满足实时需求，既有QOS和自定义相关实时链路和离线解析链路可以下线，节省资源。

　　五、数据湖性能优化

　　1.性能优化——小文件智能合并　　

　　在流批一体数据处理落地过程中遇到了很多问题，其中最典型的是小文件问题。

　　与Hive的存储方式不同，Iceberg在数据分区时对于每个文件的大小控制不够灵活，这使得解决小文件问题较为棘手。

　　Iceberg支持行级更新，这使得每次更新都会生成一个单独的Iceberg文件。在频繁更新和表规模较大的情况下，会产生大量的微小文件。随着这些文件的数量增加，HDFS的性能会受到影响，甚至可能导致Name Node的负载过重。

　　查询性能随着需要访问的文件数量增加而降低。大量的微小文件严重拖慢了查询速度。因此，我们需要实施有效的优化策略以合并这些小文件。

　　1）定时合并

　　除了控制写入参数之外，我们还会定期合并小文件。然而，选择合适的合并时机并非易事。例如，我们可能会选择每三小时合并一次小分区，这在一定程度上解决了大部分业务问题。

　　但在某些场景下，例如收集硬件信息和更新订单时，整体数据量巨大且数据更新的频率非常高。

　　这种情况下，三小时后小文件数量已经累积得非常高。对于其他业务，定时三小时合并是有效的，但对于这些特定的业务，三小时后文件数量就已经很多了。

　　因此，合并后的短时间内查询性能会提高，但随着文件数量的增加，查询性能会逐渐下降。在接近定时合并的时间阈值时，可能会出现无法瞬间查询的情况。

　　1）智能合并

　　为了更有效地解决这个问题，我们参考了Netflix的一篇文章，并制定了一个智能合并方案。该方案基于分区下文件大小均方差来自动选择需要合并的分区。

　　对于不同的业务线，我们可以设置不同的权重阈值，从而实现智能化的合并策略。当达到分区文件数域值时，该方案能直接触发文件合并。这种智能合并策略可以同时处理不同业务线的需求，及时合并文件，避免因业务更新量瞬间激增导致设置的时间阈值失效。

　　2.性能优化——BloomFilter　　

　　和Impala、Kudu对比，Iceberg存在性能较差的情况。经过深入分析发现Impala和Kudu利用索引来加速查询。但是Iceberg对索引支持有限，查询时往往是全表扫描。自Parquet1.12版本开始，Parquet已支持BloomFilter。为了提升查询性能，我们对Iceberg源码进行修改，激活了对BloomFilter的支持。

　　经过优化，查询速度显著提高，订单ID查询时间从900多秒大幅降低到10秒，整体性能现已接近Impala+Kudu的架构。虽然会占用更多存储空间， 但考虑到其卓越的整体性能，性价比依然很高。

　　六、后续计划　　

　　对于数据湖在数据中台应用的后续规划，主要从两方面：

　　从架构层面，会继续细化各个模块的开发，让数据中台提供的数据更加全面，更加易用，让不同的用户可以自助使用；

　　从技术层面，继续对数据链路进行流批一体改造，同时继续引入合适的数据湖技术，提高数据的及时性，降低生产成本。