今年個人的に気になったOSSをまとめてみる(2025)
はじめに
データエンジニアをやっておりますTaichiです。
個人的に今年気になったOSSを備忘録もかねてまとめようと思います。
データフォーマット/テーブルフォーマット
Apache Xtable
Iceberg / Delta / Hudi など異なるオープンテーブルフォーマット間の相互運用を目指すプロジェクトです。
実データ（Parquet等）には触れず、各フォーマットのメタデータを相互変換することで相互アクセスを実現しています。
相互変換には二つの同期モードがあり、増分モードを活用することで、同期するデータ量を減らし、パフォーマンスを向上させることが可能です。
- 増分同期モード
- フル同期モード
また、異種カタログ間でもテーブル同期をできることが大きな特徴です。現状HMS、AWS Glueのカタログのみサポートしており、今後Unity, Apache Polaris, Apache Gravitino, DataHubといったカタログもサポートしていくそうです。
公式ドキュメントを読むと、現状Copy-on-Write または Read-Optimized viewsのテーブルのみ対応しており、Merge-on-Readテーブルはサポートしていない制約はあるものの今後のアップデートが楽しみです。
おまけ
Databricksに似たような機能でUniForm機能があります。
Vortex
高速な分析処理を目的としたApache Parquetの次世代カラムナフォーマットです。公式では、Parquetが苦手としていたランダムアクセスなどの課題を克服していると謳われています。
Vortexのポイントは下記2つだと考えています。（個人的な意見）
- セグメントというメタデータ構造を持っており、Parquetより効率的にメタデータにアクセスできる。
- Layoutという抽象化レイヤにより、メタデータ構造を拡張性高くできる
Microsoftの検証によるとIcebergのデータフォーマットをVortexに変更することで、パフォーマンスが向上したとの発表がありました。Icebergのデータフォーマットとして採用するための動きも現在行われているようです。
Lance
LanceはマルチモーダルAIに対応したレイクハウスフォーマットと公式では紹介されています。
Lanceは下図のように、従来のオープンテーブルフォーマット(Iceberg等)とは異なり、ファイルフォーマット～カタログスペックまで自前で実装していることがポイントです。
テーブルフォーマットについて注目すると
Lance Table Formatは、Parquetが苦手とするランダムアクセスとベクトル検索をネイティブサポートしています。内部にベクトルインデックスを内包でき、構造化データと非構造化データ（埋め込みベクトル）を一括で高速クエリできる点が強みです。
データカタログ / メタデータ管理
Apache Polaris
Snowflakeが寄贈したIceberg REST Catalogです。
カタログ層を特定のクラウドベンダーから切り離し、マルチエンジン（Spark, Trino, Flink等）からテーブルを参照可能にします。権限制御はSnowflakeライクなRBACを採用しており、Snowfalkeユーザはとっつきやすい印象です。
他にも下記特徴があります。
- フェデレーション機能により異種カタログをマウントしIcebergテーブルを読み取りすることが可能です。
- Generic Table機能により、Icebergテーブルに限らずDeltaやcsvといったデータのカタログとして利用可能。（まだベータ版）
Apache Amoro
Apache Amoroは、レイクハウスを統合管理する製品です。
Iceberg等のテーブルに対して、バックグラウンドで Compactionなどの運用作業を自動実行します。
Amoroは大きく2つのサービスで下図のように構成されています。
対応しているテーブルフォーマット
現状対応しているテーブルフォーマットは下記になります。
- Apache Iceberg：Apache Iceberg のネイティブな形式
- Apache Paimon：Apache Paimon のネイティブな形式
- Mixed Iceberg：Iceberg をベースに、LogStore を活用して CDC（変更データキャプチャ）やストリーミング読み取りの性能を大幅に向上させた形式。
- Mixed Hive：Mixed-Iceberg と同等の機能を持ちつつ、既存の Hive テーブルとの互換性を維持した形式
ユースケース
下記を公式ドキュメントでは紹介していました。
- CDCなどのスモールファイルを大量に取り込む必要があるようなケース
- ストリーム/バッチ融合したデータパイプライン
クエリエンジン / 実行基盤
Apache Datafusion
Apache Arrow をin-memoryのデータフォーマットに採用した Rust 製の高速で拡張性の高いクエリエンジンです。
通常、データベースをゼロから作るのは膨大な時間がかかりますが、DatafusionはクエリエンジンをRustのライブラリとして提供することで、開発者は「SQLの解析」「クエリの最適化」といった複雑な実装をDataFusionに任せ、独自の機能開発に集中できます。
InfluxDB、LanceDBなど、多くの次世代製品がクエリエンジンとしてDataFusionを採用しています。
ストリーム処理
Rising Wave
PostgreSQL互換のインターフェースを持つストリーミングデータベースです。
従来のストリーム処理（Flink等）のような複雑なストリームパイプライン構築を不要にし、「Materialized Viewの自動更新」 という形に抽象化することでより簡単にストリームパイプラインを実現することを可能にしています。
ストリーミングソースから取り込んだデータは下図のように行ストアと分析用と向けにIcebergテーブルとして保持することができます。
Modern OLAP
Databend
Snowflakeにかなり似た製品でして、ストレージ・コンピューティング・メタデータの分離実現しています。こちらもRust製です。
テーブルデータ～AI向けのベクトル検索までAll in Oneで実現できるのが強みとなっています。
StarRock
StarRocksは、大規模なデータをリアルタイムで分析するために設計された、超高速なMYSQL互換のOLAPデータベースです。
独自のコストベースオプティマイザ（CBO）とベクトル化エンジンの組み合わせにより、複雑なJoinクエリに強いです。
Data Lake Analytics機能により、データをStarRocksにインポートしなくても、外部のParquetやIcebergなどのファイルを直接クエリできます。
その他
pg_mooncake
最後はDatabricksが買収したことで話題になったmooncakeです。 pg_mooncakeは、PostgreSQLの拡張機能で内部的にmoonlinkとpg_duckdbを用いてIcebergテーブルの操作機能を提供します。PostgreSQLという慣れ親しんだインターフェースを維持しつつ、レイクハウスへ拡張できる点が興味深いです。
- moonlink：OLTPで更新されたPostgreSQLのテーブルをIceberg形式で書き出す
- pg_duck：IcebergテーブルをDuckDBエンジンで読み取る
感想
個人的にIcebergが好きなので、関連するOSSを中心に今回は紹介しました。
いままでOSSというとHadoopやSparkに代表される「Java/JVMエコシステム」が中心のイメージだったのですが、最近のOSSを見ているとRust製というのが一つの大きなトレンドになっているなと感じました。
まだRustをちゃんと勉強できていないので、年末年始にいい機会なので本の一冊でもとってみようかなと思います。
Discussion