UberがIngestionNextを発表：ストリーミング優先のデータレイクで遅延と計算量を25%削減
Uberは、データレイテンシを時間単位から分単位に短縮し、コンピュート使用量を25%削減するストリーミングファーストのデータレイクインジェストプラットフォーム「IngestionNext」を発表した。
キーポイント
IngestionNextの発表
Uberが新たなデータレイクインジェストプラットフォーム「IngestionNext」をローンチした。
性能向上の数値
データレイテンシを時間単位から分単位に短縮し、コンピュート使用量を25%削減する。
技術基盤
Kafka、Flink、Apache Hudiを基盤として構築されている。
スケールと用途
数千のデータセットをサポートし、グローバルな分析、実験、機械学習ワークロードを高速化する。
影響分析・編集コメントを表示
影響分析
大規模データ処理のリアルタイム化とコスト削減を両立する実用的なソリューションであり、データ駆動型企業の効率化に寄与する。特にUberのようなグローバル企業での実績は、同様の課題を抱える他社への導入を後押しする可能性が高い。
編集コメント
実運用での数値（25%削減）が示されており、技術発表に留まらない実用性の高さが特徴。基盤技術がオープンソースである点も、業界全体への波及効果が期待できる。
Uber のエンジニアたちは、同社のデータレイク取り込みプラットフォームを再構築し、スケジュールされたバッチジョブからストリーミングファーストシステムへと移行しました。このプラットフォーム「IngestionNext」はイベントストリームを継続的に処理することで、取り込み遅延を数時間から数分に短縮し、分析や機械学習ワークロードの可用性を大幅に向上させています。
従来、取り込みパイプラインは Apache Spark に依存しており、スケジュールされたバッチジョブとして実行されていました。大規模な処理能力を備えていましたが、バッチパイプラインによりデータが分析や実験で利用可能になるまでに時間がかかるという課題がありました。
グローバルフィールド CTO の Kai Waehner 氏は LinkedIn の投稿で次のように述べています：
この取り組みは、データの鮮度をデータ品質の重要な次元として扱うことに尽きます。
IngestionNext は、データをデータレイクにコミットする前にイベントストリームを継続的に処理するストリーミングファーストパイプラインを導入しました。イベントは Apache Kafka を経由して流れ、Flink jobs（Apache Flink によるジョブ）によって処理され、トランザクションコミット、ロールバック、タイムトラベル機能を備えた Hudi テーブルに書き込まれます。データの鮮度と完全性はエンドツーエンドで測定されます。
このアーキテクチャは数千のデータセットと大規模なグローバルデータボリュームをサポートしており、分析ダッシュボード、実験プラットフォーム、機械学習モデルにおけるデータの可用性を高速化します。コントロールプレーンがジョブのライフサイクル、設定、ヘルスモニタリングを自動化し、地域間のフェイルオーバーおよびフォールバック戦略により、障害発生時の継続性を維持し、データ損失を防ぎます。
IngestionNext アーキテクチャ（出典：Uber Blog Post）
ストリーミングインジェクションモデルへの移行は、いくつかの技術的課題をもたらしました。その一つは、データレイク内で多数の小ファイルが作成されることで、クエリパフォーマンスやストレージ効率が悪化する問題です。この課題に対処するため、エンジニアらは Parquet ファイルに対して行グループレベルのマージ戦略を実装し、継続的なデータインジェクション中に効率的なファイルレイアウトを維持するためのコンパクションメカニズムを追加しました。Apache Hudi を含むオープンソースの取り組みでは、異なるスキーマを整合させるためにパディングとマスキングを用いたスキーマ進化対応型のマージが探求されましたが、これには実装の複雑さとメンテナンスオーバーヘッドが増加するという課題があります。
チームはまた、分散ストリーミングパイプラインにおけるチェックポイント処理、パーティションの偏り、および障害回復を扱うメカニズムを実装しました。このシステムはアップストリームストリームからのオフセットを追跡し、コミットを調整することで、インジェクションジョブがデータの整合性を維持し、障害発生時に確実に復旧できるようにしています。
エンジニアらによると、ストリーミングインジェクションへの移行によりリソース効率も向上しました。スケジュールされたバッチワークロードを、流入するデータ量に応じてスケーリングする継続実行型のストリーミングジョブに置き換えたことで、計算資源の使用量を約 25% 削減することに成功しています。
Uber Engineering ブログの共著者である Suqiang Song は、自身の LinkedIn Post で次のように述べています：
これにより、インジェクションから変換、分析に至るまで、完全なエンドツーエンドのリアルタイムデータスタックが可能になりました。
新しいインジェストプラットフォームはデータレイクに流入する生データの鮮度を向上させますが、エンジニアたちは、下流の変換や分析パイプラインにおいて追加の遅延が発生し続ける可能性があることを認めています。今後の取り組みでは、データ処理スタック全体にストリーミング機能を拡張し、鮮度改善が分析ワークフロー全体に波及するようにすることを目指します。
著者について
Leela Kumili
Leela はスターバックスのリードソフトウェアエンジニアであり、スケーラブルでクラウドネイティブなシステムや分散プラットフォームの構築において深い専門知識を有しています。彼女はリワードプラットフォーム全体にわたるアーキテクチャ設計、納品、運用上の卓越性を主導し、システムの近代化、スケーラビリティの向上、信頼性の強化に向けた取り組みを率いています。
技術的なリーダーシップに加えて、リーラは組織の AI チャンピオンとしても活動し、LLM ベースのツールを活用して開発者の生産性とワークフローを改善する機会を特定し、AI 導入のためのベストプラクティスを確立しています。彼女は本番環境で運用可能なシステムの構築、開発者体験の向上、そしてエンジニアが技術面と戦略面の両面で成長できるよう指導することに情熱を注いでいます。彼女の関心領域には、プラットフォームエンジニアリング、分散システム、開発者の生産性、そして技術的ソリューションとビジネス・製品目標をつなぐことが含まれています。
Show moreShow less
原文を表示
Uber engineers have re‑architected the company’s data lake ingestion platform, moving from scheduled batch jobs to a streaming‑first system. The platform, IngestionNext, processes event streams continuously, reducing ingestion latency from hours to minutes and enabling faster availability for analytics and machine learning workloads.
Previously, ingestion pipelines relied on Apache Spark and ran as scheduled batch jobs. While capable of large-scale processing, batch pipelines delayed data availability for analytics and experiments.
As noted by Kai Waehner, global field CTO, in a LinkedIn post:
This move is all about treating data freshness as a key dimension of data quality.
IngestionNext introduces a streaming-first pipeline that continuously processes event streams before committing them to the data lake. Events flow through Apache Kafka and are processed by Flink jobs, which write to Hudi tables with transactional commits, rollbacks, and time travel. Freshness and completeness are measured end-to-end.
The architecture supports thousands of datasets and high global data volumes, enabling faster availability for analytics dashboards, experimentation platforms, and machine learning models. A control plane automates job life cycle, configuration, and health monitoring, while regional failover and fallback strategies maintain continuity and prevent data loss during outages.
IngestionNext architecture (Source: Uber Blog Post)
Moving to a streaming ingestion model introduced several technical challenges. One challenge was creating many small files in the data lake, which can degrade query performance and storage efficiency. To address this issue, the engineers implemented row-group-level merging strategies for Parquet files and added compaction mechanisms to maintain efficient file layouts during continuous data ingestion. Open-source efforts, including Apache Hudi, explored schema-evolution-aware merging using padding and masking to align differing schemas, though this adds implementation complexity and maintenance overhead.
The team also implemented mechanisms to handle checkpointing, partition skew, and recovery in distributed streaming pipelines. The system tracks offsets from upstream streams and coordinates commits to ensure that ingestion jobs maintain data correctness and can recover reliably in the event of failures.
According to the engineers, the transition to streaming ingestion also improved resource efficiency. By replacing scheduled batch workloads with continuously running streaming jobs that scale with incoming data volume, the system reduced compute usage by roughly 25%.
Suqiang Song, who co-authored the Uber Engineering blog, mentioned in his LinkedIn Post:
This enabled a fully end-to-end real-time data stack, from ingestion to transformation to analytics.
While the new ingestion platform improves the freshness of raw data entering the data lake, engineers acknowledged that downstream transformations and analytics pipelines may still introduce additional latency. Future work will focus on extending streaming capabilities into the data processing stack to ensure freshness improvements propagate across the entire analytics workflow.
About the Author
Leela Kumili
Leela is a Lead Software Engineer at Starbucks with deep expertise in building scalable, cloud-native systems and distributed platforms. She drives architecture, delivery, and operational excellence across the Rewards Platform, leading efforts to modernize systems, improve scalability, and enhance reliability.
In addition to her technical leadership, Leela serves as an AI Champion for the organization, identifying opportunities to improve developer productivity and workflows using LLM-based tools and establishing best practices for AI adoption. She is passionate about building production-ready systems, enhancing developer experience, and mentoring engineers to grow in both technical and strategic impact. Her interests include platform engineering, distributed systems, developer productivity, and bridging technical solutions with business and product goals.
Show moreShow less
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み