简介
在 Uber，数据湖是支持整个公司分析和机器学习的基础平台。历史上，进入数据湖的摄取（Ingestion）是由批处理作业驱动的，其数据新鲜度（Freshness）以小时衡量。随着业务需求向近实时洞察演变，我们重新构建了基于 Apache Flink® 运行的摄取架构，实现了更新鲜的数据、更低的成本以及 PB 级规模的可扩展运营。
在过去的一年里，我们构建并验证了 IngestionNext，这是一个以 Flink 为核心的新型流式摄取系统。我们在 Uber 一些最大的数据集上证明了它的性能，设计了用于操作数千个作业的控制平面，并解决了流处理特有的挑战，如小文件生成、分区倾斜和检查点同步。本博客描述了 IngestionNext 的设计，以及显示出其相比批处理摄取具有更高的新鲜度和显著效率提升的早期结果。
为什么要流式处理？
促使我们要从批处理转向流式处理的两个关键驱动因素是：数据新鲜度和成本效率。
随着业务发展速度加快，Uber 的交付、乘客、出行、财务和营销分析组织不断要求更新鲜的数据，以支持实时实验和模型开发。批处理摄取提供的数据会有数小时的延迟——在某些情况下甚至数天——这限制了迭代和决策的速度。通过在 Flink 上重新搭建摄取平台，我们将新鲜度从数小时缩短到了数分钟。这一转变直接加速了全公司的模型发布、实验速度和分析准确性。
在考虑成本效率时，Apache Spark™ 批处理作业在设计上就是资源密集型的。它们按固定间隔编排大型分布式计算，即使工作负载有所变化也是如此。在 Uber 的规模下——数千个数据集和数百 PB 的数据——这意味着每天有数十万个 CPU 核心在运行。流式处理消除了频繁批处理调度的开销，使资源能够以更平滑、更高效的方式随流量进行扩展。
架构概览
IngestionNext 摄取系统由多个层组成。
图 1：IngestionNext 架构。
在数据平面，事件到达 Apache Kafka® 并被 Flink 作业消费。这些作业以 Apache Hudi™ 格式写入数据湖，提供事务提交、回滚和时间旅行（Time Travel）功能。新鲜度和完整性是端到端衡量的，从源端到目标端。
大规模管理摄取需要自动化。我们设计了一个控制平面，用于处理作业生命周期（创建、部署、重启、停止、删除）、配置更改和健康验证。这使得能够一致且安全地跨数千个数据集运行摄取。
该系统还设计了区域故障转移和回退策略以维持可用性。在发生中断的情况下，摄取作业可以跨区域转移或暂时以批处理模式运行，从而确保连续性且无数据丢失。
主要挑战与解决方案
小文件
流式摄取通常会生成许多小的 Apache Parquet™ 文件，这会显著降低查询性能并增加元数据和存储开销。当数据连续到达且必须近实时写入时，这是一个常见的挑战。
传统且最常见的合并方法是逐记录（record by record）操作的，需要对每个 Parquet 文件进行解压缩，从列式格式解码为行格式，进行合并，然后再重新编码和压缩。虽然这种方法功能上可行，但由于重复的编码/解码转换，其计算量大且速度慢。
图 2：逐记录合并 Parquet 文件。
为了克服这个问题，我们引入了行组（row-group）级合并，它直接在 Parquet 的原生列式结构上操作。这种设计避免了昂贵的重新压缩，并将压缩（compaction）速度提高了一个数量级（10倍）以上。
开源社区的努力（例如 Apache Hudi PR #13365）探索了感知模式演变（schema-evolution-aware）的合并，利用填充和掩码来对齐不同的模式，但这增加了大量的实现复杂性和维护风险。
图 3：带有数据掩码的行组合并。
我们的方法通过强制模式一致性简化了该过程——仅合并共享相同模式的文件。这消除了对掩码或底层代码修改的需求，在减少开发开销的同时，提供了更快、更高效且更可靠的压缩。
图 4：通过对模式进行分组实现的简化行组合并。
分区倾斜
我们面临的另一个问题是，短暂的下游减速（如垃圾回收暂停）会导致 Flink 子任务之间的 Kafka 消费不平衡。数据倾斜会导致压缩效率降低和查询速度变慢。
我们通过运维调优（将并行度与分区对齐，调整拉取参数）、连接器级别的公平性（轮询、对重负载分区进行暂停/恢复、每个分区的配额）以及改进的可观测性（每个分区的滞后指标、感知倾斜的自动扩缩容和针对性警报）解决了这个问题。
检查点和提交同步
我们还发现，Flink 检查点跟踪已消费的偏移量，而 Hudi 提交跟踪写入操作。如果在故障期间它们出现错位，可能会导致数据丢失或重复。
为了解决这个问题，我们扩展了 Hudi 提交元数据以嵌入 Flink 检查点 ID，从而在回滚或故障转移期间实现确定性的恢复。
结果
我们将数据集接入到基于 Flink 的摄取平台，并证实基于 Flink 的摄取提供了分钟级的新鲜度，同时相对于批处理减少了 25% 的计算使用量。下面是一个数据新鲜度得到改善的例子。
图 5：流式摄取前后对比
后续步骤
通过 IngestionNext，我们将从在线 Kafka 到离线原始数据湖的摄取方式由批处理转变为流式处理，从而显著改善了数据摄取延迟。然而，新鲜度在下游的原始数据转换和分析环节仍然停滞不前。为了真正加速数据新鲜度，我们必须将这种实时能力扩展到端到端——从摄取到转换，再到实时洞察和分析。这在当下尤为关键。Uber 的数据湖支持着交付、出行、机器学习、乘客、市场、地图、财务和营销分析组织，这使得数据新鲜度成为这些领域的重中之重。大多数数据集源于摄取，但如果没有更快的下游转换和访问，数据在决策点仍然是陈旧的。业务影响涵盖实验、风险检测、个性化和运营分析——在这些领域，陈旧的数据会延缓创新，降低响应能力，并限制做出主动的、数据驱动决策的能力。
结论
我们从批处理到流式处理的旅程标志着 Uber 数据平台演进中的一个重要里程碑。通过在 Apache Flink 上重构摄取架构，IngestionNext 在 Uber 的 PB 级数据湖上提供了更新鲜的数据、更强的可靠性和可扩展的效率。该系统的设计强调自动化弹性和操作简便性，使工程师能够专注于构建数据驱动的产品，而不是管理数据管道。
对工程师而言，其吸引力不仅在于技术基础——流式摄取、检查点同步和容错控制平面——还在于思维方式的系统性转变：将新鲜度视为数据质量的一等维度。随着 IngestionNext 在生产环境中的验证，下一个前沿领域在于扩展流式 ETL 和分析，以完成实时数据闭环，赋能 Uber 的所有团队充满信心地更快行动。
封面照片归属：“Fast running stream. Nikon D3100. DSC_0384” 由 Robert.Pittman 拍摄，依据 CC BY-NC-ND 2.0 协议授权。
Apache Flink、Flink 和 Flink 标志、Apache Spark、Apache Parquet、Kafka 和 Hudi 是 Apache Software Foundation 在美国和其他国家的注册商标或商标。 Presto® 是 LF Projects, LLC 的注册商标。
