レイクハウステーブルフォーマットの三強の中で、Apache Hudiは「いちばん地味だけど、特定の領域では強い」立ち位置にいます。2017年にUberが社内開発し、ライドシェアの大規模で頻繁な更新を支えるために生まれました。「データの更新と削除を、レイクで効率よく扱う」というニーズに、もっとも素直に答えるツールです。
採用人口ではIceberg・Deltaに譲りますが、CDC（Change Data Capture）中心のリアルタイム連携や、IoTのような大量の更新が発生する業務領域では強みを発揮します。設計と使いどころを整理します。
Hudiの基本構造
Hudiは、データファイル（Parquet）とコミットメタデータ（.hoodieディレクトリ）で構成されます。Iceberg/Deltaと似た構造ですが、Hudiの特徴は「2つのストレージタイプ」を使い分けられることです。
| ストレージタイプ | 動作 | 向く場面 |
|---|---|---|
| Copy-on-Write (CoW) | 書き込みのたびに該当ファイルを書き直す | 読み取り中心、更新頻度が中程度 |
| Merge-on-Read (MoR) | 変更を差分ログに記録し、読み取り時にマージ | 書き込み頻度が高い、リアルタイム連携 |
CoWは読み取り性能が高く、シンプル。MoRは書き込み性能が高く、ストリーミング向け。テーブルごとに使い分けられるのが、Hudi独自の柔軟性です。
Hudiの強み：CDCとリアルタイム取り込み
HudiのもうひとつのウリがDeltaStreamerと呼ばれる、CDCに特化した取り込みツールです。Kafkaやデータベースのbinlogから直接Hudiテーブルに書き込むパイプラインを、設定で組めます。
# Hudi DeltaStreamerでKafkaからHudiテーブルを構築する例
spark-submit \
--class org.apache.hudi.utilities.deltastreamer.HoodieDeltaStreamer \
...
--table-type MERGE_ON_READ \
--source-class org.apache.hudi.utilities.sources.JsonKafkaSource \
--target-base-path s3://bucket/orders \
--target-table orders \
--op UPSERT「UPSERT」が標準操作として用意されており、主キーが一致すれば更新、なければ追加という動きが、フレームワーク側で最適化されています。レイクで頻繁にUPSERTする場合、Hudiは設計上のアドバンテージがあります。
Iceberg・Deltaとの比較
| Iceberg | Delta | Hudi | |
|---|---|---|---|
| 強み | ベンダー中立・メタデータ管理 | 運用成熟・Databricks統合 | 更新・CDC・リアルタイム |
| 標準的な書き込み | INSERT/MERGE | INSERT/MERGE | UPSERT/DELETE/INSERT |
| ストレージタイプ | 1種類 | 1種類 | CoW/MoRの2種類 |
| CDC連携の出来合い | 標準では限定的 | 標準では限定的 | DeltaStreamerで最適化 |
| 採用人口 | 大・拡大中 | 大 | 中 |
| 主要DWHでの読み取り | 広く対応 | 広く対応 | 限定的 |
「IcebergとDeltaに対するHudiの存在意義」を実務で考えると、UPSERT中心の業務領域に絞られます。CDCを大規模に動かす、IoTで毎秒数千の更新が来る、というような場面では、Hudiの設計が刺さります。
クラウドDWHでの対応状況
| DWH | Hudi対応 |
|---|---|
| Databricks | サポート（OSS Spark経由） |
| Snowflake | External Tablesで限定的に読み取り |
| BigQuery | BigLake経由で限定的 |
| Athena | 読み取り対応 |
| EMR/Spark | ネイティブ対応 |
| Trino | Connectorで対応 |
HudiはIceberg/Deltaに比べて、主要DWHでの読み取り対応が遅れています。「同じデータを複数のDWHから読みたい」要件があるなら、Iceberg優位です。クラウドDWHの基本はクラウドDWH入門を参照してください。
運用上のハマりどころ
- CoWとMoRの使い分け：MoRは書き込み速いが、読み取り時のマージコストがある。コンパクションの頻度で読み取り性能が左右される。
- 主キー設計：UPSERTの動作が主キー依存なので、設計段階での主キー決定が重要。後から変えにくい。
- コミット履歴の管理：書き込み履歴が積もる。`cleaner`で古いコミットをクリーンアップする運用を組む。
- 採用人口の少なさ：Iceberg/Deltaに比べてStack OverflowやGitHubでの情報量が少なく、トラブルシュートが大変。
向く・向かない場面
- 向く：CDC中心のリアルタイム連携、UPSERTが頻繁な業務領域、IoTのような大量更新、Spark/Flink中心の処理基盤
- 向かない：分析中心で更新が少ない（→IcebergまたはDelta）、複数DWHから読みたい（→Iceberg）、コミュニティの規模を重視（→IcebergまたはDelta）
まとめ
- Apache HudiはUber発、UPSERT・CDC・リアルタイムに強みを持つテーブルフォーマット。
- Copy-on-WriteとMerge-on-Readの2つのストレージタイプを使い分けられる。
- DeltaStreamerでKafkaやbinlogからの取り込みパイプラインを構築できる。
- 採用はIceberg/Deltaに後塵を拝するが、特定領域（CDC・IoT）では強い選択肢。
- 「データの更新を、レイクで効率的に扱いたい」が要件の中心なら検討の価値あり。
全体像はレイクハウステーブルフォーマット比較、隣接の選択肢はApache Iceberg とは・Delta Lake とはにあります。Hudiの導入や、CDCアーキテクチャの壁打ちは、DE-STKの初回相談（30分・無料）もご利用ください。
よくある質問（FAQ）
Q. UberはまだHudiを使っていますか？
A. はい、Uberの中核データ基盤として現役で動いています。さらに、Onehouseという商用化スタートアップが2022年に創業され、Hudiの開発と商用サポートを進めています。OSSとしての活動も継続しており、定期的にメジャーバージョンがリリースされています。
Q. IcebergやDeltaもUPSERTできるのに、なぜHudi？
A. IcebergやDeltaもMERGEでUPSERTは可能ですが、Hudiは「UPSERT中心のワークロード」に最適化された設計思想を持ちます。MoRストレージタイプは書き込み速度を優先しており、IcebergやDeltaの標準動作とは性質が違います。「毎秒数千のUPSERT」が常態化する業務領域で、性能差が出てきます。
Q. SnowflakeからHudiテーブルを読めますか？
A. Snowflakeの External Tablesで読み取れますが、Iceberg/Deltaに比べると対応が限定的です。「HudiでデータをためてSnowflakeで読む」構成は現状やや無理筋で、Sparkや Athenaを介する方が素直です。Snowflake中心の組織なら、Iceberg を選ぶのが現実的です。Snowflakeの詳細はSnowflakeとはを参照してください。
Q. CDCならDebeziumと組み合わせるのですか？
A. はい、典型的なパターンです。Debeziumがデータベース（MySQL/Postgres等）のbinlog/WALを読み、Kafkaに流す。Hudi DeltaStreamerがKafkaから読んでHudiテーブルにUPSERTする、というパイプラインがよく構築されます。これにより「業務DBの変更をほぼリアルタイムでレイクに反映する」が実現できます。データ取り込みの選定はEL vs ETLとデータ取り込みツール選定もあわせて参考にしてください。