Apache Flink数据湖流式摄取实践：Uber实现分钟级数据新鲜度与成本优化

在 Uber，数据湖是支撑公司所有分析和机器学习工作的基础平台。过去，数据通过批处理作业摄入数据湖，其新鲜度通常以小时为单位。随着业务对近实时洞察的需求日益增长，我们重新设计了数据摄取流程，将其迁移至 Apache Flink® 之上。这一转变实现了数据新鲜度的大幅提升、成本的显著降低，以及 PB 级别的可扩展运维能力。

过去一年，我们构建并验证了名为 IngestionNext 的全新流式数据摄取系统。我们已在 Uber 的一些核心数据集上验证了其性能，设计了能够管理数千个作业的控制平面，并解决了流式摄取特有的挑战，如小文件生成、分区倾斜和检查点同步。本文将介绍 IngestionNext 的设计与初步成果，这些成果表明，相比传统的批处理摄取，IngestionNext 在提升数据新鲜度与运行效率方面成效显著。

为何转向流式处理？

我们转向流处理主要基于两个关键考量：数据新鲜度与成本效益。

随着 Uber 业务高速发展，配送、乘客、出行、财务和市场营销等分析部门持续要求获取更实时数据，以支持敏捷实验和模型开发。批量导入数据会引入数小时甚至数天的延迟，从而限制了迭代和决策速度。通过将数据摄取迁移至 Flink 平台，我们将数据新鲜度从小时级缩短至分钟级。这一转变直接加速了模型发布、提升了实验效率与分析准确性，使公司整体受益。

从成本角度看，基于 Apache Spark™ 的批处理作业设计本身资源消耗较大。它们以固定的时间间隔调度，执行大规模的分布式计算，即使工作负载发生变化。对于 Uber 这样的规模——涉及数千个数据集和数百 PB 的数据——这意味着每天需要动用数十万个 CPU 核心。流式处理消除了频繁的批处理调度开销，使资源能够更平滑、更高效地随数据流量伸缩。

架构概览

IngestionNext 摄取系统由多个层次构成。

图 1：IngestionNext 架构。在数据平面，事件到达 Apache Kafka®，由 Flink 作业消费。这些作业以 Apache Hudi™ 格式写入数据湖，提供了事务性提交、回滚和时间旅行功能。数据的新鲜度与完整性从源头到目标端全程可测。

大规模的数据摄取管理需要高度的自动化。我们设计了一个控制平面，用于处理作业的完整生命周期（创建、部署、重启、停止、删除）、配置变更以及健康状态验证。这使得跨数千个数据集进行一致且安全的数据摄取成为可能。

该系统还设计了区域故障转移和回退策略以确保高可用性。当故障发生时，数据摄取作业可以跨区域转移，或临时切换至批处理模式运行，从而保障数据连续性与零数据丢失。

核心挑战与解决方案

小文件问题

流式数据摄取往往会生成大量小型的 Apache Parquet™ 文件，这会显著损害查询性能，并增加元数据与存储开销。在数据持续到达且需要近乎实时写入的场景下，这是一个普遍挑战。

传统的合并方法是逐条记录进行的：需要先解压每个 Parquet 文件，将其从列式解码为行式，合并后，再重新编码和压缩。这种方法虽然可行，但由于重复的编码/解码转换，计算开销巨大且速度缓慢。

图 2：逐条记录合并 Parquet 文件。

为克服此问题，我们引入了行组级合并，它直接作用于 Parquet 原生的列式结构。这种设计避免了代价高昂的重新压缩，并将压缩速度提升了十倍以上。

像 Apache Hudi PR #13365 这样的开源项目探索了使用填充和掩码来对齐不同模式的模式演化感知合并，但这带来了巨大的实现复杂性和维护风险。

图 3：行组合并与数据掩码。

我们的方法通过强制模式一致性来简化流程——仅合并具有相同模式的文件。这消除了对掩码或底层代码修改的需求，从而降低了开发开销，同时实现了更快、更高效、更可靠的压缩。

图 4：通过强制模式一致性简化行组合并。

分区倾斜

我们遇到的另一个问题是，下游短暂的性能下降（例如垃圾回收暂停）会导致 Flink 子任务间消费 Apache Kafka 数据的不平衡。这种数据倾斜会降低压缩效率并拖慢查询速度。

我们通过操作调整（使并行度与分区数对齐、调整提取参数）、连接器级别的公平性策略（轮询、对繁忙分区暂停/恢复、设置分区配额）以及增强的可观测性（每个分区的延迟指标、感知倾斜的自动扩缩容和针对性告警）来解决这一问题。

检查点与提交同步

我们还发现，Flink 检查点追踪的是已消费的偏移量，而 Hudi 提交追踪的是写入操作。若在故障期间两者发生错位，则可能导致数据被跳过或重复写入。

为此，我们扩展了 Hudi 的提交元数据，在其中嵌入了 Flink 检查点 ID，从而在回滚或故障转移期间实现确定性的恢复。

成果

我们将多个数据集迁移至基于 Flink 的数据摄取平台后确认，该平台能够提供分钟级的数据新鲜度，同时相比之前的批处理方式，计算资源消耗降低了 25%。下图展示了数据新鲜度的提升效果。

图 5：流式摄取实施前后的数据新鲜度对比。

未来规划

通过 IngestionNext，我们显著降低了数据摄取延迟，实现了从在线 Kafka 到离线原始数据湖的流式摄取。然而，原始数据在下游的转换与分析环节仍可能无法保证同等的新鲜度。为了真正加速端到端的数据流动，我们必须将这种实时能力扩展到整个链路——从摄取到转换，再到实时洞察与分析。这一点至关重要。

Uber 的数据湖为配送、出行、机器学习、乘客、市场、地图、财务和营销分析等多个部门提供支持，数据新鲜度是这些领域的首要任务。大多数数据集始于摄取环节，但如果下游的转换和访问速度跟不上，数据在用于决策时仍然会过时。这会影响实验、风险检测、个性化和运营分析等方方面面——过时的数据会延缓创新、降低响应速度，并限制企业做出主动的、数据驱动决策的能力。

结论

从批处理到流式处理的转变，是 Uber 数据平台演进的一个重要里程碑。通过在 Apache Flink 上重构数据摄取流程，IngestionNext 为 Uber 的 PB 级数据湖带来了更新鲜的数据、更高的可靠性以及更具扩展性的效率。该系统的设计强调自动化、弹性与运维简易性，使工程师能够专注于构建数据驱动型产品，而非管理复杂的数据管道。

对工程师而言，IngestionNext 的吸引力不仅在于其扎实的技术基础——流式数据摄取、检查点同步和容错控制平面——更在于它所代表的系统性思维转变：将数据新鲜度视为数据质量的一个核心维度。IngestionNext 已在生产环境中得到验证，其下一步发展方向是扩展流式 ETL 与分析能力，从而完善实时数据闭环，赋能 Uber 的所有团队，使其能够更加自信地加速业务发展。