Apache Hudiとは？レコード単位の更新と増分取り込みを支える仕組みを実装視点で解説【2026年版】

Apache Hudiは、S3などのオブジェクトストレージに置いたデータへ、レコード単位の更新と削除を持ち込むためのレイクハウス基盤です。名前はHadoop Upserts Deletes and Incrementalsの頭文字で、そのまま設計思想を表しています。追記しかできなかったデータレイクに、上書きと差分取得の機能を後付けする層だと捉えると輪郭がつかめます。

この記事では、Hudiが内部でどう一貫性を保っているのか、Copy on WriteとMerge on Readをどの条件で選ぶのか、インデックスとテーブルサービスの設定が運用コストをどう変えるのかを、実装者が判断できる粒度で整理します。版番号と数値は参照時点（2026年7月）の公式ドキュメントとリリース情報に基づきます。

まとめ：Apache Hudiの要点と採用判断の軸

• 正体は更新可能なテーブル層：Parquetなどのファイル群に主キーとメタデータを与え、upsertとdeleteを成立させるストレージ抽象。
• 一貫性の核はタイムライン：コミットやコンパクションといった操作が要求中・実行中・完了の状態付きで記録され、読み手は完了済みの地点までを見る。
• 書き込み方式は二択：COWは書き込みが重く読み取りが素直、MORは書き込みが軽い代わりに読み取りとコンパクション運用の負荷を負う。
• 性能を決めるのはインデックス：主キーからファイルへの引き当て方式（Bloom・Bucket・レコードレベル索引）の選択が更新スループットを左右する。
• クエリは3種類：最新断面・差分のみ・ベースファイル限定の使い分けが、下流の設計をそのまま決める。
• 参照時点の最新安定版は1.2.0系：1.1系で他フォーマットとの併存路線に舵を切り、1.2系ではFlink側の読み取り実装が刷新された。
• 採用が向く条件：更新と削除が高頻度、差分を下流へ流したい、遅れて届くデータの取り扱いが必要な案件。日次の洗い替えで足りるなら見送りが妥当。

Apache Hudiとは何か：レコード単位の更新を可能にするストレージ層

HudiはUberの社内基盤として生まれ、その後Apacheプロジェクトへ移りました。出発点の課題は、数分単位で届く大量の変更を、都度テーブル全体を作り直さずにデータレイクへ反映することです。この一点を解くために設計されたぶん、増分取り込みまわりの機能が他フォーマットより厚く積まれています。

前提として、データレイクそのものの性質はデータレイクとは？データウェアハウス・レイクハウスとの違いを実装視点で解説で整理しています。オブジェクトストレージは基本的に追記と全置換しかできず、1件のレコードを直すだけでもファイル単位の書き直しが発生する構造です。Hudiはこの制約を、ファイルの束をテーブルとして扱うメタデータ層で覆い隠します。

オブジェクトストレージ上でupsertとdeleteを成立させる仕組み

Hudiのテーブルは、ベースパス配下にパーティションのディレクトリが並び、その中にファイルグループが置かれる構造です。ファイルグループはファイルIDで一意に識別され、同じIDの下に世代の異なるファイルスライスが積み上がります。ひとつのスライスは、あるコミット時点で書かれたベースファイル（通常はParquet）と、それ以降の変更を記録したログファイルの組で構成されます。

各レコードには主キーに相当するレコードキーと、同一キーの新旧を判定するための順序フィールドを持たせます。書き込み時、Hudiはまずインデックスを引いてそのキーが既存のどのファイルグループに属するかを判定し、該当グループへ更新を差し込みます。新規キーなら新しいファイルグループを作る動きです。この「キーからファイルへの引き当て」がある点が、単なるParquetの集合との決定的な違いです。

ファイル形式そのものとテーブル形式の役割分担が曖昧になりやすい部分は、Apache IcebergとParquetの違い｜テーブル形式とファイル形式の関係を整理で切り分けています。Hudiにおいても、Parquetは中身の入れ物にすぎず、テーブルとしての振る舞いはメタデータ側が担います。

タイムラインとファイルグループが一貫した読み取りを担保する仕組み

テーブルに対して行われた操作は、すべてタイムラインへインスタントとして記録されます。インスタントは、操作の種類（コミット、デルタコミット、コンパクション、ロールバック、セーブポイントなど）、単調増加するタイムスタンプ、そして要求中・実行中・完了のいずれかの状態を持ちます。

読み手が見るのは、完了状態になったインスタントまでです。書き手が途中まで書いたファイルは実体としては存在していても、対応するインスタントが完了へ移るまで読み手からは見えません。この一点で、部分的に書かれた状態が下流へ漏れる事故を防いでいます。障害でジョブが落ちた場合は、実行中のまま残ったインスタントをロールバックとして畳み、書きかけのファイルを無効化します。

タイムラインは同時に、時点指定の読み取りと差分取得の土台にもなります。ある時刻より後のインスタントだけを辿れば、その間に変わったレコードだけを取り出せるからです。

IcebergやDelta Lakeとの位置づけの違いをどう捉えるか

同じ層を担う実装として、Apache IcebergとDelta Lakeがあります。三者はいずれもオブジェクトストレージ上のファイル群にトランザクション性を与えますが、出自が違うぶん得意領域がずれています。Icebergは巨大テーブルの分析クエリ、Delta LakeはSparkとの統合、Hudiは高頻度の増分書き込みという整理が実態に近いところです。

三者の横並び比較と選定基準はオープンテーブルフォーマットとは？Iceberg・Delta Lake・Hudiの違いと選び方を実装視点で解説【2026年版】に譲ります。Delta Lake単体の構造を確認したい場合はDelta Lakeとは？データレイクに信頼性を与えるオープンテーブルフォーマットを実装視点で解説を参照してください。本記事は、Hudiを選んだあとに実装者が直面する内部構造と運用設定に集中します。

Copy on WriteとMerge on Readの使い分けと書き込み設計

テーブル作成時に決めるテーブルタイプは、後から変えにくいうえ、書き込み遅延・読み取り遅延・運用の手数のすべてに効きます。違いは、更新をいつマージするかという一点に集約されます。

Copy on Writeが書き込み増幅と引き換えに得る読み取り性能

Copy on Write（COW）は、更新が来た時点で対象のベースファイルを読み、変更を反映した新しいParquetを書き直します。テーブルの中身は常にParquetだけで、ログファイルは存在しません。

結果として、読み手は列指向ファイルをそのまま走査するだけで済み、外部エンジンからの互換性も高くなります。代償は書き込み増幅です。1件の更新でも、そのレコードが属するファイル全体を書き直すため、更新が散らばるほど無駄な書き込みが増えます。1時間に1回の取り込みで、更新対象が特定パーティションへ集まるようなワークロードならCOWが素直に効きます。

Merge on Readのログファイルとコンパクションの運用負荷

Merge on Read（MOR）は、更新を行指向のログファイル（Avro形式）へ追記するだけで書き込みを終えます。ベースファイルの書き直しは後回しにし、バックグラウンドのコンパクションがログをベースへ畳み込みます。

書き込み遅延は短くなり、数分間隔の取り込みにも耐えます。一方で読み手の負担は増えます。最新断面を見るクエリは、ベースファイルとログファイルをその場でマージする必要があり、ログが溜まるほど読み取りが遅くなるからです。MORを選ぶということは、コンパクションのスケジュールと実行資源を運用対象として抱え込むことを意味します。ここを設計しないまま本番投入すると、数週間後に読み取りが目に見えて遅くなる展開になります。

インデックス方式の選択が更新性能を左右する理由と実装での選び分け

書き込みのたびに「このキーはどのファイルにいるのか」を解く工程が入るため、インデックスの方式が実質的なスループットを決めます。代表的な選択肢は三つです。

Bloomフィルタ索引は追加の保存領域が要らない反面、キーがランダムだと候補ファイルが絞れず、探索コストが膨らみます。バケット索引は探索が定数時間で済むものの、バケット数を後から変えにくい点が制約です。レコードレベル索引はメタデータテーブル自体の保守が増えるかわりに、ランダム更新でも安定した引き当てを返します。UUIDを主キーにする設計なら、Bloomフィルタ索引のままで押し切らないほうが無難です。

3つのクエリ種別とテーブルサービスの実行方式を運用視点で押さえる

同じテーブルに対して三つのクエリ種別が用意されており、下流の用途ごとに読み方を使い分ける前提で設計されています。

スナップショット・増分・ベースファイル限定の3クエリの使い分け

スナップショットクエリは、最新のコミット時点における全レコードを返します。MORではベースとログを動的にマージするため、鮮度は最も高く、コストも最も高い読み方になります。BIツールや日次集計の既定はこれです。

増分クエリは、指定したコミット以降に変わったレコードだけを返します。下流のテーブルを差分更新する処理や、変更をイベントとして後段へ流す用途で効く読み方です。テーブル全体を再スキャンせずに済むため、パイプラインの段数が増えるほど費用差が開く構造です。Hudiを選ぶ理由の相当部分は、この読み方が標準で使える点にあります。

三つ目は、ベースファイルだけを読む方式です。ログの取り込みを省くぶん最新の更新は反映されませんが、列指向ファイルの素の性能が出ます。多少の遅延を許容できる分析用途で、MORテーブルの読み取り費用を抑える手として使えます。

コンパクション・クラスタリング・クリーニングの実行タイミング

Hudiはテーブルサービスと呼ばれる保守処理を内蔵しています。実装者が把握しておくべきものは主に三つです。

実行方式は、取り込みジョブと同じプロセスで走らせるインライン型と、別ジョブとして非同期に走らせる型に分かれます。インラインは構成が単純ですが、取り込みの遅延にコンパクション時間が乗ります。取り込み間隔が短い構成では、非同期側へ寄せて資源を分けるのが定石です。クリーニングの保持世代は、時点指定の読み取りをどこまで遡れるようにするかとの兼ね合いで決めます。保持を厚くすれば巻き戻せる範囲は広がり、そのぶん保管費用が乗る構造です。

SparkとFlinkでの取り込み実装とAWS上での動かし方の勘所

書き込み側の実装は、Sparkのデータソース経由、Sparkの内蔵取り込みツール、Flinkのストリーム処理のいずれかを使うのが一般的です。バッチで既存テーブルを取り込むならSparkのデータソース、変更データを継続的に流し込むならFlink、という住み分けになります。読み取り側はSparkとFlinkに加え、TrinoやPrestoからも参照できます。

AWS上では、EMRとGlueがHudiを同梱しており、追加のライブラリ管理をせずに書き込みと読み取りを始められます。ただし同梱されるHudiの版はサービス側のリリースに紐づくため、本記事で触れる1.2系の機能を前提に設計する場合は、対象環境の同梱版を先に確認してください。カタログ登録の方式（Glueデータカタログへ同期するか否か）も、下流のクエリエンジンから見えるかどうかを直接左右します。

レイクハウス全体の構築順序はデータレイクハウス実装の手順6ステップ｜アーキテクチャ選定と移行判断を実務視点で解説に、アーキテクチャの前提はデータレイクハウスとは？データレイク・DWHとの違いとアーキテクチャを実装視点で解説にまとめています。

1.1系と1.2系で変わった点を参照時点の一次情報で確認する

Hudiは1.0系のGA以降、系列が細かく枝分かれしています。参照時点（2026年7月）で公式のダウンロードページが最新として掲げているのは1.2.0で、GitHubのタグ日付は2026年5月23日です。その前が1.1.1（2025年12月18日）と1.1.0（2025年11月17日）にあたります。

1.1系が持ち込んだ複数テーブル形式への対応という位置取りの変更

1.1系の目玉は、テーブルフォーマットを差し替え可能にする枠組みの導入です。従来はHudi独自の形式で書くことが前提でしたが、この枠組みによってIcebergやDelta Lakeの形式を扱う道が開きました。フォーマットの陣取り合戦から一歩引き、書き込み側の機能で勝負するという位置取りの変更だと読めます。

実装者にとっての意味は、フォーマット選択が以前ほど不可逆でなくなった点にあります。ただし変換や併存には相応の検証が要るため、乗り換え前提の設計にするかどうかは案件ごとの判断です。

1.2系のスキーマ刷新とFlink側の読み取り実装の入れ替え

1.2.0では、Avroスキーマへの依存を置き換える内部スキーマ表現が導入され、decimalやdate、timestamp、UUID、variantといった型の扱いが整理されました。Flink側には新しいソース読み取り実装が入り、分割の列挙、述語の押し下げ、パーティションの刈り込み、変更データの分割取り扱いに対応しています。ストリーム取り込みを主用途に据える構成では、この刷新が効いてきます。

ほかに、COWテーブルでのLance形式のベースファイル対応、SparkのSQL関数として提供される近傍探索、コミット単位のクラスタリング戦略やファイルグループの分割、コミット前の検証枠組みが挙がっています。実行基盤側はSpark 4.0.1に対応し、最小のJDKが11へ引き上げられ、Flinkは2.1に対応しました。JDKの下限が上がっている点は、既存環境からの移行時に見落としやすい制約です。

旧0.x系の保守リリースが続いている状況とアップグレード判断

興味深いのは、1.2.0の公開後も0.14.2（2026年6月8日）や0.15.1（2026年5月21日）といった旧系列の保守リリースが出ている点です。マネージドサービスの同梱版や既存パイプラインが0.x系に張り付いたまま動いている現場が相当数あることの裏返しでもあります。

移行判断としては、新規構築なら1.2系を素直に選び、稼働中の0.x系は「テーブル形式のバージョンが上がる」性質の変更を伴うため、読み取り側のエンジン互換とロールバック手順を確認したうえで計画的に上げるのが安全です。稼働テーブルを直接アップグレードする前に、複製したテーブルで下流のクエリが通ることを確かめる工程を挟んでください。

Apache Hudiを採用すべき条件と見送るべき場面の判断基準

ここまでの構造を踏まえて採否の線を引きます。Hudiは解いている課題がはっきりしているぶん、要件から外れたときの持ち出しも大きい技術です。

Apache Hudiの採用が費用に見合う三つの条件を言い切る

採用が費用に見合うのは、次の三条件のうち二つ以上が当てはまる場合です。第一に、更新と削除が継続的に発生し、日次の全件洗い替えでは間に合わないこと。基幹データベースの変更を数分から数十分の遅延でレイクへ反映したい要件は、この典型にあたります。

第二に、変わった行だけを下流へ流したいこと。増分クエリを前提に段を組めば、集計テーブルの再構築コストが桁で下がります。第三に、遅れて到着するデータの取り扱いが避けられないこと。数日前の実績が後から訂正されるような業務では、主キーによる差し替えが標準機能として使える価値が大きくなります。

加えて、削除要求への対応が制度上求められる場合も採用側へ傾きます。レコード単位の削除が、テーブル再作成なしに実行できるからです。

Hudiを見送るべき場面と代わりに選ぶべき構成をあらかじめ決める

見送るべき場面もはっきりしています。取り込みが日次のバッチのみで、既存データを書き換えず追記だけで足りるなら、Hudiの機能はほぼ余剰です。パーティション単位の入れ替えで運用したほうが、構造も運用も軽く済みます。

データ量が数百GB程度に収まり、クエリの主戦場がBIだけという構成でも、素直にデータウェアハウスへ載せたほうが総コストは下がります。テーブルサービスの運用に人を割けない体制も、見送りの根拠になります。MORを選んでコンパクションを放置した基盤は、半年後に読み取り性能と保管費用の両方で問題を出すからです。運用要員を確保できない前提なら、COW限定で使うか、マネージド寄りの構成に切り替える判断を先にしておいてください。

受託開発でHudi基盤を設計するときの体制と検証工程の見積もり

受託でHudi基盤を組む場合、見積もりで落としやすいのが検証工程です。テーブルタイプとインデックス方式の組み合わせは、実データの主キー分布と更新パターンで結果が変わるため、机上の比較では決まりません。本番相当のデータで、取り込み遅延・スナップショットクエリの応答・コンパクション所要時間の三点を実測する期間を、あらかじめ工程へ入れておくのが安全です。

書き込み側の実装者と下流のクエリ担当が分かれている場合ほど、クエリ種別の使い分けを明文化しておく価値があります。全員がスナップショットクエリだけを叩く運用になると、MORの利点が消えて費用だけが残るためです。

データ基盤の構成選定、更新可能なレイクの設計、既存パイプラインからの移行まで、Hudiを含むレイクハウス層の実装はデータ分析基盤構築・MLOps構築支援で相談を承っています。テーブル形式の選定から運用引き渡しまで一貫して対応します。

よくある質問

Q1. Apache HudiとIcebergはどちらを選ぶべきでしょうか

更新頻度で分かれます。数分単位の増分取り込みや遅れて届くデータの差し替えが主役ならHudi、巨大テーブルへの分析クエリとエンジン間の互換性を重視するならIcebergが第一候補になります。両者の比較軸と判断表は、オープンテーブルフォーマットの記事にまとめました。

Q2. Copy on WriteとMerge on Readはあとから変更できますか

テーブルタイプは作成時に決まり、既存テーブルの設定を切り替えるだけでは移せません。変えたい場合は、新しいタイプでテーブルを作り直し、データを移す形になります。切り替え費用が小さくないので、検証段階で両方を実測して決めておくべき箇所です。判断がつかないうちはCOWで始め、書き込み遅延が要件に届かないと分かった時点でMORへ移す進め方が現実的でしょう。

Q3. Hudiのテーブルを扱うのにSparkは必須になりますか

書き込みは実質的にSparkかFlinkのいずれかが前提になります。読み取り側はTrinoやPrestoからも参照でき、AWSのマネージドサービス経由で触ることも可能です。ただしテーブルサービスの実行には処理エンジンが要るため、コンパクションやクリーニングを回す資源は別途確保しておく必要があります。

Q4. コンパクションを止めたままにすると何が起きるのですか

MORテーブルではログファイルが積み上がり、スナップショットクエリのたびにマージ対象が増えて読み取りが遅くなります。ストレージ使用量も、同じデータを二重に持つ状態が続くぶん膨らみます。ジョブの成否とログファイル数を監視対象に入れてください。

Q5. 既存のParquetのデータレイクからHudiへ移行できますか

移行できます。既存ファイルを読み込んで書き直す方法のほか、既存のParquetをそのまま参照しつつメタデータだけを付与する取り込み方式も用意されています。後者は初期の書き込み量を抑えられる反面、扱いに制約があるため、対象テーブルの規模と更新頻度で選び分ける判断です。いずれの場合も、レコードキーと順序フィールドをどの列に割り当てるかを先に決める作業が要ります。

関連記事

• オープンテーブルフォーマットとは？Iceberg・Delta Lake・Hudiの違いと選び方を実装視点で解説【2026年版】
• Delta Lakeとは？データレイクに信頼性を与えるオープンテーブルフォーマットを実装視点で解説
• データレイクハウスとは？データレイク・DWHとの違いとアーキテクチャを実装視点で解説
• データレイクとは？データウェアハウス・レイクハウスとの違いを実装視点で解説
• データレイクハウス実装の手順6ステップ｜アーキテクチャ選定と移行判断を実務視点で解説
• Apache IcebergとParquetの違い｜テーブル形式とファイル形式の関係を整理