このアーキテクチャで得られるもの
| 利点 | 説明 |
|---|---|
| 一貫したテーブル更新 | テーブル状態へのアトミックな commit により、同時書き込みが発生してもデータの破損や不完全なデータは生じません。これにより、生のデータレイクにおける最大の課題の 1 つを解決できます。 |
| スキーマ管理 | 検証の強制とスキーマ進化の追跡により、スキーマの不整合が原因でデータが使えなくなる「データスワンプ」問題を防げます。 |
| クエリパフォーマンス | 索引、統計情報、データスキッピングやクラスタリングといったデータレイアウトの最適化により、SQL クエリを専用のデータウェアハウスに匹敵する速度で実行できます。さらに ClickHouse の列指向 engine と組み合わせることで、この特性はオブジェクトストレージに保存されたデータにも当てはまります。 |
| ガバナンス | カタログとテーブルフォーマットにより、行レベルおよびカラムレベルできめ細かなアクセス制御と監査が可能になり、基本的なデータレイクでは不十分だったセキュリティ制御を補えます。 |
| ストレージとコンピュートの分離 | ストレージとコンピュートは、汎用オブジェクトストレージ上でそれぞれ独立してスケールでき、独自仕様のウェアハウスストレージより大幅に低コストです。こうした分離は最新のクラウドウェアハウスでは一般的ですが、オープンフォーマットであれば、データに合わせて どの コンピュートエンジンをスケールさせるかを選べます。 |