爱奇艺数据湖实战

01

   什么是数据湖？

数据湖概念于2010年[1]首次提出，经过多年的演变，目前演化出两种不同的定义——公有云数据湖、非公有云数据湖。  

 公有云数据湖 

AWS [2]、Google Cloud [3] 以及国内的阿里云、腾讯云等公有云厂商对数据湖的定义是一个集中的、近乎无限空间的数据存储区，支持结构化、半结构化、非结构化等各种类型数据。在公有云厂商的语境下，数据湖一般就是各家的云存储产品，比如 AWS S3、Google Cloud Storage、阿里云 OSS 等。

在云计算出现之前，公司数据主要分散在不同的业务数据库中，由于存储空间有限，存放的是经过处理后的结构化数据，丢失了部分原始信息。随着业务发展，这类传统的数据库/数据仓库已不能满足多样化的数据应用场景需求。开源 Hadoop及公有云云存储的出现正是为了解决这一痛点，将不同类型的业务数据导入到Hadoop 或云存储中进行后续不同场景的处理，随用随取，因此被称为数据湖。

关于各家公有云的数据湖架构及解决方案，可以参看这篇介绍文章：《数据湖 | 一文读懂 Data Lake 的概念、特征、架构与案例》[4]。

 非公有云数据湖 

Hadoop、公有云存储支持文件级别的操作，如上传文件、删除文件，不支持对文件内容里行级别的操作，如添加/删除/更新某行。因此，基于 Hadoop 或公有云存储构建的数据仓库不支持实时增量数据更新、不支持流式数据，延迟通常在小时级乃至 T+1。

为此，Uber、Netflix、Databricks 等几家公司在 2017-2019 期间相继推出了Hudi[5]、Iceberg[6]、Delta Lake 等，试图在 Hadoop、公有云存储层之上提供一个通用的表格格式（Table Format）层。国内（非公有云场合）一般称这三者为数据湖。这种叫法是不准确的，但业界一般都这么称呼，我们也跟着“将错就错”。在非公有云场合，如果不特别说明，数据湖一般就是指 Hudi、Iceberg、Delta Lake 三者之一。

 爱奇艺数据湖 

综合以上两种定义，我们理解的数据湖应当具备以下几个特性：

• 统一存储：支持灵活的存储底座（公有云/私有云、HDD/SSD/缓存），具备集中的、足够大的存储空间

• 通用数据抽象/组织层：支持结构化、半结构化、非结构化等不同数据类型，并抽象出一层统一的数据组织形式，Hudi、Iceberg、Delta Lake等目前仅统一了结构化数据格式

• 支持批处理、流计算、机器学习等不同计算类型

• 统一的数据管理（元数据中心、生命周期、数据治理等），避免形成数据孤岛

这类数据湖，我们称之为广义数据湖，与之对应的狭义数据湖就专指Hudi、Iceberg、Delta Lake。我们目前启动了多个项目推进广义数据湖建设，后续会另有专文阐述，本文及本系列后续文章将集中介绍狭义数据湖（下文简称“数据湖”）。

02

   为什么需要数据湖？

在上一节解释数据湖的定义时，已大体介绍了业务对数据湖的需求，本节将结合三个典型的场景来说明业务为什么需要数据湖。

 场景一 - 事件流实时分析 

事件流实时分析是大数据中常见的需求，典型的业务场景如分析广告投放效果、视频实时运营、日志排障等。而相应的技术产品也非常多，表 2-1 归纳了常见的产品及其特点：

表 2-1 各OLAP引擎特点比较

从表 2-1 可以看到，数据湖相比其他产品有如下核心优势：

• 时效性好：数据湖里的数据近实时（ 1-5 分钟）可见，比 Hive 离线延时优势明显，能满足大部分业务的要求

• 规模大：数据湖存储使用的是 HDFS，写入吞吐几乎无瓶颈

• 成本低：数据湖无需单独服务器，机器成本低，运维成本低

• 查询支持：数据湖支持明细数据查询，也支持各种复杂的联合分析

• 数据分享：数据湖支持 Spark、Trino、Flink 等各类引擎分析，而数据进入 ElasticSearch、Kudu、Druid、ClickHouse 后都只能使用专用的查询引擎分析，数据分享需额外导出为 Parquet 等格式

传统上受规模、成本等限制，业务仅最终报表或者关键链路会使用实时分析，其他场景仍以离线分析为主。随着业务发展，需要一种更大规模、更便宜的近实时分析手段，数据湖就提供了这样的解决方案。

 场景二 - 变更数据分析 

数据变更有如下几种类型，一种是行级变更，如 MySQL 中会员订单，用户特征等，其拥有确定的行主键，且列变更频繁，对于此类数据进行聚合分析主要有如下方案：

图2-1 大数据支持行更新常见方案

• 离线导出：缺点是同步延迟大，通常是 T+1；另一方面是同步代价大，每次需全量导出，给数据源 MySQL/HBase 带来较大读压力；

• 实时同步进 Kudu：面临规模小、成本大等痛点

数据变更的另一种形式是新增行或列。Hive 若一个分区计算已经完成，那么晚到的数据只能丢弃，否则需要覆写整个分区。Hive 历史分区新增一个列也需要覆写整个分区。

数据湖解决了业务的上述痛点，业务能将 MySQL、MongoDB 中的变更近实时地入湖。新增行仅需将相应行写文件即可，新增列也支持单独写列文件，无需覆写分区。

 场景三 - 流批一体 

爱奇艺大量业务采用图2-2上半部分所示的 Lambda 架构，实时链路采用 Kafka+Flink 技术，为业务提供实时推荐、实时监控等能力；离线链路采用 HDFS+HiveQL 技术，用于校准数据和扫描查询，该架构具有如下痛点：

• 离线通路时效性差、而实时通路容量低

• 维护两套逻辑，开发效率低

• 容易出现数据不一致

• 维护两套服务机器，成本高

图2-2 传统Lambda架构和数据湖流批一体架构

而使用数据湖业务能实现流批一体，消费 Kafka 数据近实时入湖（5分钟延迟），既能满足离线的批量扫描、数据覆盖场景，也能满足大部分实时场景（需要秒级延迟的除外）。由此具有如下优势：

• 支持海量数据近实时更新

• 一套代码，避免重复开发

• 避免数据不一致

• 服务存储和计算成本更低