GUI上の操作で試行錯誤した結果をコード化してSemantic Layerとして共通利用できるBIツール「Omni」を試してみた
2024.08.18さがらです。
2022年に創業された、GUI上の操作で試行錯誤した結果をコード化してSemantic Layerとして共通利用できるBIツール「Omni」を試してみたので、本記事でまとめてみます。
Omniとは
Omniですが、2022年2月にOmni Analytics社が設立され、2022年8月に「Omni」という名称でBIツールのプロダクトがリリースされています。
Omniを創業したのは、LookerでChief Analytics OfficerをされていたColin氏、LookerでVP ProductをされていたJamie氏、StitchでCTO→買収後のTalendではVP of EngineeringをされていたChristopher氏、という3名で、データプラットフォームを構築する製品に非常に造詣が深いメンバーにより創業されています。
実際に私も触ってみて、かなりLookerに近い印象を受けました。しかしそれだけでなく、GUIベースの操作で行ったJOINやmeasureなどの定義をコードに反映させたり、スプレッドシートのような操作感で計算式を追加したり、dbtと連携してdescriptionを同期したりOmniでの集計結果をdbtのModelとしてプッシュしたり、より柔軟性を持った機能を備えております。
試すこと
本記事では、シンプルにSnowflakeと接続して、Omniの特徴でもあるGUIベースでJOINや計算式を含むmeasureの定義を行った後にその内容をコード化して反映させることを中心に試してみます。
使用するデータは、jaffle-shopリポジトリをクローンしてMetricsのDescriptionやlabelを日本語化した、下記のリポジトリをビルドしたテーブルやビューを使用します。
OmniとSnowflakeを接続
まず、OmniからSnowflakeへの接続設定を行っていきます。
※今回は事前に使用するユーザー・ロール・データベースなど各種オブジェクトはセットアップ済とします。
Omniの画面で、Add Connectionを押したあと、Snowflakeを押して認証に必要な情報を入れていけばOKです。
Modelの開発
Snowflakeとの接続を終えると、Modelの開発ができるようになります。
Omniの知識として、Omniは以下の3つのモデリングレイヤーから構成されています。Connectionの設定を行うと、1番のデータベース内にある各テーブルをミラーしたモデルが自動で生成されます。2番と3番に関しては、ユーザー側でカスタマイズの必要があります。
- A schema model that mirrors the database
- A shared, virtualized data model for global business metrics and definitions
- A workbook model for ad hoc analysis that extends the core data models
また、Model自体にもバージョン管理的な考えで2種類存在します。（今回は試していないですが、Gitとも連携することで、Workbookでの変更をSharedに反映する前にプルリクエストを必要にしたり出来るみたいです。）
Shared：全ユーザーが共通で使用するrelationshipや計算式を定義した、統制された指標やロジックを管理するWorkbook：各ユーザーが分析を行う画面(Workbook)で定義したrelationshipや計算式を含むフィールドを含む。デフォルトではWorkbook内の定義はWorkbook内に閉じているが、Sharedへの反映も可能
ということで、Modelの開発をしてみます。上記でいうSharedのModelを変更することになります。
Omniの画面で左のメニューのDevelopを押した後に、先ほど作成したConnection名が表示されているため、それをクリックします。
すると、下図のように表示されます。今回は指定したデータベースの中でもPRODスキーマに限定していたので、PRODスキーマ内の各テーブルごとに自動でviewが生成されました。（参考までに、SharedのModelを見ているため上部にSharedと表示されています。）
この後、topicsというオブジェクトをmodel上で定義していきます。topicsは、定義したview同士のJOINや共通のフィルターなどを定義し、ユーザーが使用する分析画面をコードで定義できるオブジェクトです。（LookerでいうExploreのようなものです。）
今回はあえてシンプルに、1つのテーブルだけを使用するtopicsを定義します。理由としては、この後GUIベースの操作で新しいJOINやmeasureを定義することが出来るため、その機能によってどのような変化があるかをわかりやすくするためです。
modelの中で、下記のように入力し、Save changesを押します。スキーマ名__view名となっているのがポイントです。（私はこの表記がドキュメントを見ても見つからず、結構時間を喰いました…）
これで、Workbook上でグラフを作成したり、新しいJOINやmeasureの定義ができるようになりました。
Workbookでの分析（簡易的なグラフ作成）
ということで、SharedのModelの定義を終えたので、実際にWorkbookを立ち上げてみます。
Omniのホーム画面に戻り、右上のNew Analyticsを押します。すると、新しいWorkbookが立ち上がります。
まず、画面左から使用するTopicsを選択します。先程Model上で定義したOrdersを選択します。
すると、viewで定義されたフィールドがずらっと表示されます。白色がdimension、緑色がmeasureと分かれています。
実際に、フィールドを選択してグラフを作成してみます。Is Drink OrderとOrders Countを選択すると、右側に下図のように集計された結果が表示されました。
次に、Chartを押すと、棒グラフが表示されました。右側のオプションからも色々な形式のグラフを選択することが可能です。
Workbookでの分析（新規のJOINやmeasureの追加も含め）
次に、新規のJOINやmeasureの定義をWorkbook上で行ってみます。
JOINの定義
フィールド選択欄の一番上のview名の横の「…」をクリックし、Joins→New Joinを押してみます。
すると、下図のようにOrdersのviewと他のviewのJOINの定義を行える画面が出てきますので、任意のviewと結合用のフィールドを選択し、Addを押します。
すると、新しくJOINの定義を行ったOrder Itemsがフィールド選択欄に追加されました！
Primary Keyの追加
また、Lookerと同じように各viewにPrimary Keyを定義していないとJOINが関わる集計がうまくできない仕様がOmniにもあります。そのため、Primary KeyをWorkbookから設定してみます。
OrdersのOrder IDの横の「…」を押し、Modelingを押すと、Primary Keyという項目があるのでこれを押します。
Order Itemsでも同様に、Order Item IDの横の「…」を押し、Modeling→Primary Keyを押します。
新しいmeasureの追加
次に、新しいmeasureを追加してみます。
シンプルな集計measureの追加
まず、SUMやAVERAGEなどのシンプルな集計measureを追加してみます。
シンプルな集計measureを追加したいdimensionの横の「…」を押し、Aggregatesを押すと、どの集計方法でmeasureを追加するかが表示されます。
今回はSUMを押してみます。すると、Product Price Sumというmeasureが新しく追加されます！
ロジックを含むmeasureの追加（スプレッドシート感のある操作で）
次に、もう少しロジックを含むmeasureを追加してみます。Omniの特徴でもある、スプレッドシートのような操作を元にしたmeasureの追加をしてみます。
操作を省略しましたが、下図のようにOrder IDごとに注文の合計額を示すOrder Total Sumと消費税の合計額を示すTax Paid Sumというmeasureを作り、選択した状態からスタートします。
この状態で、集計結果の上部にあるAdd new columnを押します。
すると、Calculationという新しい列が追加されるので、Order Total SumからTax Paid Sumを引いてみます。
=と入力した後、対象のセルを選択してスプレッドシートのような操作感で計算式を入力し、Enterを押します。
すると、下図のようにOrder Total SumからTax Paid Sumを引いたロジックを含むmeasureが新しく追加されました。Calculation欄をダブルクリックすることで、表記を変えることが出来るので、Order Total Sum without Taxとしておきます。
ロジックを含むmeasureの追加（SQLベースで）
次に、SQLベースの記法で新しくmeasureを追加してみます。
追加する内容としては、先程と同じくOrder Total SumからTax Paid Sumを引いた結果を出すmeasureを出してみます。
Workbookの画面の左下から、Add fieldを押します。
下図のように入力し、右下のAddを押します。各フィールドを参照する${prod__orders.tax_paid_sum}のような記法は、対象のフィールドの横の「…」からModeling→Copy referenceを押すとこの形式でコピーできます。
すると、フィールド選択欄に新しくOrder Total Sum Without Tax 2が追加され、measureとして使えるようになりました。
Workbookの内容をShared Modelに反映
これまで、JOINの定義や新しいmeasureの定義をWorkbook上で行ってきました。
この内容を、ベースとなるSharedのModelに反映してみます。Workbookで試行錯誤した結果をそのままSemantic Layerの定義にできるのが、Omniの強みだと私は感じています。
まず、画面左のModel Changesを押します。
すると、WorkbookでどのようなJOIN定義やMeasureの追加を行ったのか、一覧が出てきます。これらの変更がどのようにコードで定義されるのかを見るために、上のOpen in IDEを押してみます。
IDEが立ち上がると、Workbookでの変更内容がどのようにコードで定義されているのかがわかります。
- JOINの定義の追加（
relationships内に自動入力）
oreder_items.viewにprimary keyとmeasureの定義の追加
orders.viewにprimary keyとmeasureの定義の追加 ※注目すべきは、スプレッドシート感のある操作で追加したmeasureは反映されていないということです。 ドキュメントを見る限り出来るものと出来ないものがあるようですが、ちょっと今回の検証範囲では掴みきれなかったですね。
これらの内容を反映するため、またWorkbookの画面に戻り、Promote to sharedを押します。（参考までに、各変更点の右横にあるボタンを押すと、項目ごとにSharedへ反映させることも出来ます。）
この後で、SharedのModelを見てみます。Workbookから閲覧する場合は、上部のModel→Edit model→Sharedを押せばOKです。
すると、下図のように、SharedのModel定義においても、Workbookで追加したJOINやmeasureが反映されていることがわかります。
参考：コードを直接記述してModelを編集することも可能
参考までに、Workbookを介さなくても直接ModelのIDE上でコードを記述すれば、その内容をユーザーに利用させることも可能です！(Lookerに近しい開発体験になります。ただしOmniの場合はGit連携が必須となっていないため、Git連携も設定したほうがよりガバナンスを保てるとは感じました。)
ダッシュボードの作成
OmniもBIツールのためダッシュボードを作成することが可能です。簡単にどのような操作感で作成できるのかやってみます。
まず、Workbook上でグラフを作成したあと、右上の+ Dashboardを押します。
すると、ダッシュボードの名前や作成先を入力する画面が出てきます。設定を終えたら、右下のSave & create dashboardを押します。
すると、下図のようにダッシュボードの編集画面に移行します。あとはLookerに近い感じで、Tileを拡充していけばOKです。
参考：ダッシュボードの作例
Omniのサンプルダッシュボードを元に、どのようなことができるかを確認してみます。
まずは下図が標準的なダッシュボードとなります。よく見る形のダッシュボードですね。
また少しカスタマイズを入れることで、下図のように、色分けをアレンジしたり、画像を埋め込んだダッシュボードを作ることが出来ます。
また、Omniの特徴として、Markdownを記述したTileも追加可能です。
最後に
GUI上の操作で試行錯誤した結果をコード化してSemantic Layerとして共通利用できるBIツール「Omni」を試してみました。
Lookerやdbt Semantic Layerを知っている人間からすると、「GUIの分析画面で試行錯誤した結果をそのままコード化してSemantic Layerにできる」という体験は新鮮で面白かったです！
