数据湖在爱奇艺数据中台的应用

从架构层面，会继续细化各个模块的开发，让数据中台提供的数据与服务更加全面，更加易用，让不同的用户都可以方便地自助使用;在技术层面，我们将继续对数据链路进行流批一体改造，同时继续积极引入合适的数据技术，提高数据的生产和使用效率，降低生产成本。参考文献1. Dixon, James (14 October 2010). "Pentaho, Hadoop, and Data Lakes". James Dixon’s Blog.2. Iceberg: A modern table format for big data3. Apache Iceberg: An Architectural Look Under the Covers4. Iceberg Table Spec5. Apache Flink6. Alex Gorelik. The Enterprise Big Data Lake.

这在数据处理中具有重要意义，因为数据及时性的提升可以极大地改进数据处理ETL的效率。

因此，我们可以方便地对现有的Lambda架构进行改造，实现流批一体架构：

在引入数据湖技术之前，我们采用离线处理与实时处理相结合的方式，提供离线数据仓库和实时数据仓库。

全量数据通过传统的离线解析处理方式，构建成为数仓数据，并以Hive表的形式存储在集群中。对于实时性要求高的数据，我们单独通过实时链路生产，并以Kafka中的Topic的形式提供给用户使用。

然而，这种架构存在以下问题：实时和离线两条通路需要维护两套不同的代码逻辑。当处理逻辑发生变化时，实时和离线两条通路都需要同时更新，否则会出现数据不一致的情况。离线链路的小时级更新以及1小时左右的延迟，使得在00:01的数据可能在02:00才能查询到。对于部分实时性要求较高的下游业务来说，这是无法接受的，因此需要支持实时链路。虽然实时链路的实时性可以达到秒级，但其成本较高。对于大多数使用者来说，五分钟级别的更新已经足够满足需求。同时，Kafka流的消费不如直接操作数据表方便。针对这些问题，通过使用Iceberg表与流批一体化的数据处理方式，可以较好地解决。优化过程中，我们主要对ODS层和DWD层表进行Iceberg改造，并将解析和数据处理加工重构为Flink任务。为确保改造过程中,数据生产的稳定性和准确性不受影响，我们采取以下措施：1. 首先从非核心数据着手进行切换。根据实际业务情况，我们以QOS投递和自定义投递作为试点。2. 通过对离线解析逻辑进行抽象处理，形成统一的Pingback解析入库SDK，实现了实时与离线的统一部署，使代码更加规范化。3. Iceberg表以及新的生产流程部署完成后，我们进行了两个月双链路并行运行，并对数据进行常规化对比监测。4. 确认数据和生产都没有问题后，我们对上层进行无感知切换。5. 对于核心数据相关的启动、播放数据，我们将在整体验证稳定后再进行流批一体改造。改造后，收益如下：1. qos和自定义投递数据链路整体实现了近实时化。小时级延迟的数据达到五分钟级更新。2. 除特殊情况外，流批一体链路已可以满足实时需求。因此，我们可以下线与QOS和自定义相关的既有实时链路和离线解析链路，从而节省资源。通过对数据处理的改造，未来一段时间内，我们的数据链路会如下图所示：05 后续规划对于数据湖在数据中台应用的后续规划，主要从两方面：从架构层面，会继续细化各个模块的开发，让数据中台提供的数据与服务更加全面，更加易用，让不同的用户都可以方便地自助使用;在技术层面，我们将继续对数据链路进行流批一体改造，同时继续积极引入合适的数据技术，提高数据的生产和使用效率，降低生产成本。参考文献1. Dixon, James (14 October 2010). "Pentaho, Hadoop, and Data Lakes". James Dixon’s Blog.2. Iceberg: A modern table format for big data3. Apache Iceberg: An Architectural Look Under the Covers4. Iceberg Table Spec5. Apache Flink6. Alex Gorelik. The Enterprise Big Data Lake.