[Cube] データモデリングでのcubesとviews の使い分け
記事の目的
Cubeとは、Cube Devが提供しているSemantic Layer構築ツールです。
この記事は、Cube上でMetrics定義・実装をするために行った調査の結果を共有します。
viewsを使用してcubesで定義された情報をエンドユーザーに提供する方法、cubesとviewsの違い、およびそれらの使い分けに焦点を当てました。
※注意点
この記事は、cube v0.34.40 に基づいた内容で記載しています。
cubes と views について
cubes の概要
Cubeの公式ドキュメントによれば、cubesはデータウェアハウスからの参照定義を行います。
これは、LookerのLookMLに類似しており、フィールドを定義する必要があります。
dimensionとmeasureといったフィールド定義に加えて、他のcubes（テーブル）との関係性もここで定義します。
また、SQL APIを通じてcubesを直接参照することも可能です。
views の概要
同じく公式ドキュメントによれば、viewsはエンドユーザー向けに構成されたcubesです。複数のcubesから必要なdimensionやmeasureだけをピックアップし、アクセス制御も行います。
views の2つの設計方針
ガイドによれば、viewsを設計する際には大きく2つの方針があります。
Entity-first
Entity-firstのアプローチでは、viewsはデータモデルのエンティティを中心に構築されます。
これは、BIで使用するための集計済みテーブルやエンドユーザー向けのデータマートに近いイメージです。一つのエンティティを参照するだけで使えるため、利用状況に合わせて最適化されています。
Metrics-first
Metrics-firstのアプローチでは、viewsはデータモデルのmeasure（Metrics）を中心に構築されます。これはSemantic LayerにおけるMetrics管理に近いアプローチで、Metricsごとにviewsの定義ファイルを作成します。
利用時には使いたいMetricsを選択していくため、柔軟性がありますが、各Metrics-viewsを必要に応じて複数選択する必要があります。
2つの整理
Entity-first
- 利用用途に合わせてviewsを組み立てていく。
- Metricsに関してはSSOT（Single Source of Truth）な管理が難しい。
Metrics-first
- Analytics EngineerチームがMetricsを定義し、viewsで実装する。
- Metricsがカタログ化されており、利用者は探しやすい。
- 複数のMetricsを使用する場合、viewsを組み合わせる必要がある。
まとめ
Cube上でのデータモデリングにおいては、cubesとviewsを使い分け、さらにviewsに関してはEntity-firstとMetrics-firstの2つのアプローチで設計することが紹介されていました。
Entity-firstは利用用途をイメージしやすいが、Metricsそのものの管理が難しそうな印象です。
Metrics-firstは反対にMetrics管理を推進できますが、どう使うかは利用者側に委ねられていて、浸透させるには一定のフォローが必要そうです。
Discussion