キャディでの Apache Iceberg 活用事例
参考になった
6
キャディ株式会社 / takumi_era
メンバー / バックエンドエンジニア
| 利用プラン | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|---|
OSS のためなし | 10名以下 | 2024年9月 | B to B |
| 利用プラン | OSS のためなし |
|---|---|
| ツールの利用規模 | 10名以下 |
| ツールの利用開始時期 | 2024年9月 |
| 事業形態 | B to B |
アーキテクチャ
アーキテクチャの意図・工夫
データ基盤システムのアーキテクチャパターンの一つである「データレイクハウスアーキテクチャ」を参考に、以下のツールを採用しました。
- クエリ: Trino
- メタデータ: Iceberg
- ストレージ: GCS（Google Cloud Storage）
処理の大まかな流れは以下の通りです。
- ユーザがアップロードした CSV をパースして Iceberg データとして保存する
- 図面の解析結果を一定間隔のバッチで受け取り Iceberg データとして保存する
- Iceberg データを用いてデータ同士の紐付けを解決し、図面に紐づく「関連データ」を UI に表示できるようにする
緑色の線が「ユーザが CSV をアップロードしてから Iceberg に登録されるまで」の流れを表し、赤色の線が「図面の解析結果が Iceberg に登録されるまで」の流れを表しています。別のジョブを通じてデータ同士の紐付けを解決して Iceberg に書き戻し、この「解決済み」のデータを REST API から返却して、ユーザ向けの画面に表示しています。
Trino は GKE クラスタ上に用意した専用のノードにデプロイして稼働させています。Trino Coordinator というコンポーネントがクエリを受信し、実行計画を立てて、Trino Worker に対して指示を送ります。Trino Worker は Trino Coordinator からタスクを受け取り、データを実際に処理します。負荷に応じて Trino Worker の台数をオートスケールさせることでコストを最適化しています。
Iceberg Catalog としては tabulario/iceberg-rest（現在は iceberg-rest-fixture）を利用しており、こちらも GKE クラスタ上にデプロイして稼働させています。カタログの情報は AlloyDB に永続化し、ファイルの実態は GCS に保存しています。
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
弊社では製造業データ活用クラウド CADDi Drawer を提供しています。
「製造業の図面管理 SaaS」としてサービスを開始した CADDi Drawer ですが、2024年7月より「製造業におけるエンジニアリングチェーン・サプライチェーン上のあらゆるデータを対象にデータ活用を実現する SaaS」としてコンセプトをアップデートしています。
製造業の世界には、図面、CAD、仕様書、コスト、品質データなど、多種多様なデータが存在します。
これらのデータを活用可能にするためには、まず、非構造化データや半構造化データをなんらかの方法で構造化する必要があります。その上で、データ同士をなんらかの方法で紐づけて、データ同士の連関がわかるようにする必要があります。
データのフォーマットは会社ごとに異なり、さまざまなバリエーションがあります。当然ながら「データ同士がどうすれば紐づくか」は一意には決まりません。加えて、企業の規模によっては一億件近くのデータが存在するケースもあります。
- さまざまなスキーマのデータを柔軟に取り扱うことができ、
- データ同士をどのカラムで紐づけるべきかを柔軟に選択でき、
- 大規模なデータセットを取り扱える
新しいコンセプトの実現にあたっては、データの分析と関連付けのために、上記のような性質のデータを取り扱える基盤が必要であると考えました。
どのような状態を目指していたか
以下のアーキテクチャ特性を満たすサービスを構築し、CADDi Drawer から利用可能にすること。
- さまざまなスキーマのデータを柔軟に取り扱うことができ、
- データ同士をどのカラムで紐づけるべきかを柔軟に選択でき、
- 大規模なデータセットを取り扱える
また、選定した基盤を用いて中長期的に期待するパフォーマンスが出せることを目指していました。
比較検討したサービス
- RDBMS
- BigQuery
- その他サードパーティの DWH 製品
比較した軸
- 目的とするアーキテクチャ特性を満たせること
- 中長期的に期待するパフォーマンスが出せること
- （導入のタイミングではベータ版として機能を提供する想定であったため）利用料金および運用コストが高くないこと
選定理由
- クエリとストレージを分離することで、以下のメリットを得られる
- クエリに関しては、サーバ台数を増やすことでスケールさせやすい
- ストレージに関しては、GCS や S3 など耐久性の高いオブジェクトストレージにデータの管理を任せることができる
- Iceberg の仕様に従ってデータを保存することで、どのクエリエンジンを使うか（Spark、Hive、Flink、Trino など）がユースケースに応じて選択可能
また、導入を検討していたタイミングで AWS など BigTech 各社が力を入れ始めており、今後のエコシステムの成熟に期待できる点も決め手の一つでした。
導入の成果
Iceberg および Trino を採用したことにより、
- 顧客ごとに異なる、さまざまなスキーマのデータを柔軟に取り扱うことができる
- データ同士をどのカラムで紐づけるべきかを柔軟に選択できる
- 大規模なデータセットを取り扱える
といった、当初目的としていたアーキテクチャ特性を満たすサービスを構築できました。
データの書き込み性能のスループットに関しては、1000 万件規模のデータの登録が 15min 程度で完了し、読み込み性能に関しても一般的な Web アプリケーションとして違和感のないレスポンスタイムで安定して結果を返すことを確認できました。
導入時の苦労・悩み
Iceberg のメタデータ管理を行うミドルウェアである、Iceberg Catalog の選定に悩みました。
導入当時は Iceberg Catalog として決定版といえるようなものがなく、（後から Iceberg Catalog を変更することを前提として）tabulario/iceberg-rest を採用しました。
マネージドサービスである Google Cloud Dataproc Metastore の採用も検討しましたが、このサービスは Hive Metastore のマネージドサービスを提供するものであり、Iceberg のメタデータ管理のためだけに採用するのは少々オーバスペック気味に感じたため採用は見送りました。
導入に向けた社内への説明
上長・チームへの説明
スキーマが不定だったり、紐付け項目が一意に定まらなかったりするという特徴も相まって、RDBMS を素朴に利用してアプリケーションを設計すると、中長期的に期待するパフォーマンスが出せないのではないか、という懸念がありました。
そこで、ADR（Architecture Decision Record）を作成し、目的とするアーキテクチャ特性を満たすために Trino + Iceberg の構成を採用したい旨を説明しました。
BigQuery も採用候補にあがりましたが、不特定多数のユーザーに BigQuery を用いた機能を解放するとクエリコストのコントロールが難しくなりそうなため、候補からは外しました。
また、Trino + Iceberg の構成でパフォーマンステストを実施し、中長期的に想定される規模のデータに対して期待通りのパフォーマンスが出せることを検証しました。
活用方法
CADDi Drawer が扱うデータのうち、構造化データを扱うサービスで Iceberg を使用しています。
このサービスを CADDi Drawer に組み込むことで、図面に紐づく「関連データ」を UI に表示できるようにしています。
よく使う機能
Iceberg はあくまで Open Table Format と呼ばれるデータフォーマットの仕様のことを指すため、「よく使う主要機能」を挙げるのは難しいです。
ツールの良い点
- トランザクション管理、タイムトラベルクエリ、in-place table evolution などの便利な機能をデータ基盤に導入できる
- ユースケースに応じて Trino、Spark、Hive、Flink など様々なクエリエンジンを選択できる
- GCS や S3 など耐久性の高いオブジェクトストレージにデータの管理を任せることができる
- クエリエンジンを必要に応じてスケールイン/スケールアウトさせることでコストの最適化がしやすい
ツールの課題点
- （Iceberg に限らず Open Table Format 全体に言えることですが）変化の激しい分野のため、継続的なキャッチアップが必要
ツールを検討されている方へ
日本語情報も増えてきており、キャッチアップは比較的しやすい方だと思います。
以下の記事などを参考に環境構築をしてみるとイメージが掴めると思うので、興味のある方はぜひ試してみてください。
今後の展望
Iceberg を使った仕組みは、現在、あくまで CADDi Drawer の中の一機能という立ち位置です。
将来的には製造業AI 見積クラウド CADDi Quote のデータも横断して取り扱えるよう、サービスをアプリケーションとプラットフォームに分割し、複数のアプリケーションを横断して利用できるようにしていくことを検討しています。
Iceberg の機能をもっと使い倒し、製造業 AI データプラットフォーム CADDi を支えるデータ基盤として成長させていければと思います。
キャディ株式会社 / takumi_era
メンバー / バックエンドエンジニア
キャディ株式会社 / takumi_era
メンバー / バックエンドエンジニア
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法