Omniの初期セットアップ（Connection作成・dbt連携・権限設定・etc）をやってみた
さがらです。
dbtと連携機能が豊富で、GUIベースで操作したフィールド定義やJOIN定義などを自動でコード化できるBIツールであるOmniについて、改めて新規のConnection作成を行う機会があったので、初期セットアップに必要となる手順を本記事にてまとめてみます。
初期セットアップとは
初期セットアップですが、主に以下6つの項目に分けて実施していきます。
- Connection作成
- dbt連携
- 1つ目のModelのGit連携
- 1つ目のTopic作成
- ユーザー・グループ・権限設定
- Organizationレベルの各種設定
前提条件
使用するDWHはSnowflakeで、DEV・STG・PRODという環境ごとに1アカウント内でデータベースを分ける仕様としています。
リポジトリについては、1つのリポジトリ内でdbtのコードもOmniのコードもルート階層でフォルダを分けて管理するとします。（dbtの開発・実行環境はdbt Projects on Snowflakeです。）
1. Connection作成
まず、OmniからSnowflakeに対するConnectionを作成します。
Omniの画面で左下のSettingsから、Connectionsを押します。
右上のAdd Connectionを押します。
接続するDWHを選択します。今回はSnowflakeを選択します。
表示されたセットアップ画面で、各情報を入力していきます。入力が終わったら末尾左下のCreate Connectionを押します。
私は下図の通り入力しました。特筆すべき点を以下にまとめます。
Include Schemas：対象のデータベースで開発用のスキーマやStagingレイヤーのスキーマなどOmniが使用することがないスキーマが存在する場合は、Omniで使用するスキーマだけ指定することを推奨します。- 今回私は、Stagingレイヤーのスキーマや管理用のスキーマも混在していたため、
DWH,MARTという2つのスキーマに絞っています。
- 今回私は、Stagingレイヤーのスキーマや管理用のスキーマも混在していたため、
Authentication Type：パスワード認証とキーペアから選択できます。- 今回はキーペア認証を選択しました。
Enable DW Semantic View Integration：SnowflakeやDatabricksのSemantic Viewに該当するオブジェクトを定義していると、その内容をOmniのViewとして連携することが可能です。- 詳細はこちらのブログをご覧ください。
Base Access：このConnectionを利用できる全ユーザーのデフォルト権限を設定できます。デフォルトがQuerierなのですが、Querierだとフィールドの定義を変更してSharedへのプルリクエスト発行ができる権限を広く渡すことになってしまうため、ViewerかNo Accessに設定して、Groupなど使って個別により強い権限を渡すことを推奨します。
先程キーペア認証を選択していたため、下図のようにキーペアを設定する画面が表示されます。
今回は事前に作成済みのキーペアがあるため、Add existing keyを押し、秘密鍵を登録します。
秘密鍵の登録後、Active列を見るとDisabledになっているため、クリックして有効化します。下図２枚目の通りになっていればOKです。
この後Settingsタブに移動し、末尾左下のUpdate and Test Connectionを押します。これで下図のように表示されたら、接続が無事に成功している状態となります。
最後に、Settingsタブの右上のSchema欄から、Build Schemaを押します。これを押すことで、接続先のSnowflakeのテーブル・ビューの定義を読み取り、Omniで使用するためのSchema modelを作成してくれます。
Build Schemaを押すと、Developの画面に自動で移動し、新しいModelが作られます。
2. dbt連携 ※データ変換にdbtを使用している場合のみ
続いて、今回のデータではdbtを使用して変換処理を行っていたため、dbtとの連携設定を行います。
dbtとの連携設定は「Connection」レベルで行います。
OmniのConnectionでの設定～Deploy keyの登録
先程作成したConnectionで、dbtタブを開き、下図のように設定を行います。入力したらSaveを押します。
特筆すべき設定は以下です。
Folder：連携先のGitリポジトリでdbtに関するファイル定義がルート階層ではなく特定のフォルダ内でされている場合、そのパスを入れます。今回連携するGitリポジトリはルート階層でフォルダを分けて管理しているため、dbtに関するファイルを定義しているフォルダ名を入れています。Enable Virtual Schemas：この設定を有効化すると、Dynamic Schemaの機能を有効化して、dbtのEnvironmentを開発・本番と切り替えてOmniからダッシュボードの編集・開発ができるようになります。- **後で有効化すると既存のviewを参照している箇所を全てContent Validatorで
omni_dbt__<view名>に置き換える必要があるため、dbt連携時は一番最初から有効化することを強く推奨します。
- **後で有効化すると既存のviewを参照している箇所を全てContent Validatorで
Auto-generate primary keys and relationships from dbt constraints：dbt constraintsを設定している場合、Omniのviewファイルでのprimary keyの設定やrelationshipsオブジェクトの定義を自動で行ってくれます。今回連携するGitリポジトリではdbt constraintsを使用していたため、有効化しています。
するとOmniの画面下部にPublic Keyが表示されるため、これをコピーして連携先のGitリポジトリのDeploy keysから登録を行います。Allow write accessにチェックを入れるのがポイントです。
Deploy keyの追加後、Omniの画面に戻りTest Connectionを押します。押した結果下図のように表示されて問題なければ、Saveを押します。
Environmentの設定
続いて、本番環境に該当するEnvironmentの設定を行います。
対象のConnectionのdbtタブの最下部で、Add Environmentを押します。
新しいEnvironmentの設定画面が表示されるため、dbtの本番環境に該当するtargetの定義をprofiles.ymlなどから確認して、下図のように入力して右下のSaveを押します。
Healthの画面に切り替わり、下図のように表示されたら問題なしです。右上の✕を押してこの表示を消します。（警告は、Connection設定時にstagingスキーマを連携対象から外していたために表示されています。）
Schema modelのリフレッシュ
この後、Schema modelをリフレッシュしてdbtのメタデータを連携するため、ConnectionのSettingsタブに移動し、Refresh nowを押します。
リフレッシュ完了後にIDEから各ファイルを見てみると、dbt constraintsを設定していたため、primary_keyやrelationshipsオブジェクトの定義が自動で行われていることがわかります。
任意：modelファイルに対してignored_schemasを設定
これでdbtと連携した開発はできるようになったのですが、dbtと連携した直後の状態だと、新しいExploreを立ち上げた時に下図のようにDWHとomni_dbt_dwhと2つ同じようなスキーマが表示されてしまい、分析を行うユーザー目線でとてもわかりづらいです。（ちなみにここで選ぶべきはomni_dbt_dwhです、これを選ぶことで後で開発環境のEnvironmentを追加した際に数クリックで参照先を開発環境に切り替えることができるようになります。）
このため、不要なDWHを表示させないように、modelファイルの内容を変更します。（公式Docにも記載がある方法です。）
下図のように、ignored_schemasと入力し、連携しているスキーマ名をカンマ区切りで入れてあげます。その後、右上のSave changesを押します。
すると、Virtual Schemaだけが表示されるようになります。
この上で再度Exploreを立ち上げてみると、利用できるスキーマがOmniのVirtual Schema1つだけになったため、最初からViewの一覧が表示されます。（Virtual Schemaが2つ以上ある場合は、スキーマを選択する画面から表示されます。）
任意：Connectionの設定で、dbtの開発環境と連携
Omniではdbtと連携することで、dbtの開発環境に参照先をすぐに切り替えることができるDynamic Schema機能があります。
設定方法としては、対象のConnectionのdbtタブで下図のように新しい開発環境に該当するEnvironment設定します。（開発環境のスキーマを環境変数で切り替えている場合は、Environment Variableも設定します。）
また、開発環境のデータベースが別れている場合は、ConnectionのSettingsタブでInclude Other Databasesに対象のデータベース名を入れて、dbtの開発用スキーマも読み取れるようにInclude SchemasでDBT_*も追加し、末尾左下のUpdate and Test Connectionを押します。（この設定を行わないと、開発用のデータベースに含まれるテーブルを参照できません。）
設定後、スキーマのリフレッシュも忘れずに行います。
これで、下図のようにdbtの開発環境に参照先をすぐ切り替えることができるようになります。
あとはおまけですが、modelファイルのignored_schemasの値も変更して、ユーザーに不要なスキーマが見えないようにしておくことも推奨します。
3. 1つ目のModelのGit連携
次に、OmniのModelをGitで管理できるように設定をしていきます。
作成したModelをIDEから開き、Git Settingsを押します。
表示された画面で、下図のように設定します。（Git followerの設定は、より厳密に開発～検証～リリースを切り分けることが出来る機能です。Embedの利用や地域間で同じOmniのModelを展開したい場合などに役立つと思います。詳細は公式Docをご覧ください。）
Git連携に関する各種設定を行います。基本的にはPull request requiredのみ有効化すれば問題ないと思いますが、以下にパッと見ただけではわかりづらい設定についての説明を記しておきます。（詳細は公式Docもご覧ください。）
Require for system syncs：有効化すると、スキーマリフレッシュなどによるviewファイルの書き換えなどのシステム操作もプルリクエストを必要とするようにします。Always create branches：有効化すると、接続されたリポジトリ内のプルリクエストによって、Omniに対応するブランチが作成されます。Model path：デフォルトではリポジトリのルート階層から見てomni/<model-name>という形でフォルダが作られるのですが、この作成先をカスタムすることが出来ます。
続いてプルリクエストマージ後にOmniのSharedのコードもすぐに反映するようにするため、Webhookの設定をしていきます。
OmniのGit設定画面の末尾のDeploy Keyをコピーし、連携先のGitリポジトリのDeploy keysから登録を行います。Allow write accessにチェックを入れるのがポイントです。
この後、OmniのGit設定画面の末尾のPayload URLとWebhook secretをコピーし、連携先のGitリポジトリのWebhooksの画面から下図のように設定を行います。Which events would you like to trigger this webhook?ではPull Requestだけ選ぶようにします。（Pushのチェックは外してください。）
この後、OmniのGit設定画面の最上部のTest git connectionを押し、下図のように表示されたら設定完了です！
4. 1つ目のTopic作成
続いて、ユーザーの分析導線がスムーズとなるように、Topicを作成していきます。
Topicとは
Topicは、Omniのmodel内で定義できるユーザー向けのデータソースのような役割で、LookerでいうExploreに近い概念の機能です。ユーザー向けに、事前にJoinの定義や、ユーザーごとの行レベル・列レベルの表示制御を適用させることも可能です。詳細については、以下の公式Docをご覧ください。
公式からはベストプラクティスも提供されています。内容を一部だけ抜粋すると、万人向けの巨大Topicは避けて部門や用途に合わせて対象を絞り、最初から完璧を目指さずに小さなTopicをまずは作成してフィードバックを受けながら育てていくこと、base_viewを最もトランザクション性の高いテーブルにしてmany-to-oneの結合条件にすること、labelやdescriptionやsample_queriesを定義してTopicの使い方をすぐ理解できるようにすること、などの言及があります。
また、公式からは業態ごとのTopicのイメージも提供されています。
Topicの作成
Topicの作成は「WorkbookでのGUI操作」と「IDEでのコード編集」の2通りが用意されているのですが、簡単なフィールドやJOIN定義などであれば「WorkbookでのGUI操作」で充分です。
Topicの作成～Shared modelに反映する手順については、以下のブログが参考になると思います。
今回は下図のようなTopicを作成して、Shared modelへの反映まで行いました。
5. ユーザー・グループ・権限設定
続いて、ユーザー・グループ・権限についての設定を行っていきます。
まず始めに：権限設定の方針決定
どのツールでもそうですが、どのように権限を設定していくかの方針を決めることが重要です。
具体的には、「どの部署・役割の人に、どのOmniの操作を許可するか」という点になります。
以下は操作権限を振り分ける場合のイメージです。各ロールの違いはこのブログでも後で触れますが、詳細はこちらの公式Docをご覧ください。
- データエンジニアユーザー
- Omniで付与させたい権限：Connectionの編集や、Shared modelの編集まで行う
- Omniで付与するロール：
Connection adminかModelerを付与
- 分析パワーユーザー
- Omniで付与させたい権限：自由にWorkbookの作成を行い、Sharedへの反映をしたい場合はプルリクエストを発行する
- Omniで付与するロール：
Querierを付与
- 分析一般ユーザー
- Omniで付与させたい権限：自由にWorkbookの作成を行えるが、Sharedへの反映はできない
- Omniで付与するロール：
Restricted querierを付与
- 閲覧だけのユーザー
- Omniで付与させたい権限：作成されたWorkbookを閲覧だけ行う
- Omniで付与するロール：
Viewerを付与
権限管理に関するベストプラクティスも、少しですがOmniの公式Docで公開されています。
ユーザー招待＆Organization roleの確認
Omniのトップページ左下のSettingsから、Usersを押すことでユーザーの招待・管理が可能です。
基本的に各ユーザーは招待するだけで良いのですが、Omniで全ての操作を行えるOrganization Adminをもし付与したい場合には、対象のユーザーをクリックしてOrganization Adminに変更してください。 ※Organization Adminは非常に強い権限のため、限られたユーザーにだけ付与するようにしてください。
グループ作成＆ユーザーの割当
次に、部署や役割に応じたグループの作成を行います。
Omniのトップページ左下のSettingsから、Groupsを押すことでグループの作成が可能です。
右上のNew Groupを押すと、下図のようにグループの作成画面が立ち上がります。
グループを作成すると、グループに対してユーザー追加を行える画面に移行しますので、各グループに対してユーザーを追加してください。
権限設定
続いて、権限設定を行います。権限に関しては、大きく「Connection Role」と「Content permissions」の2つに分けられます。
- Connection Role：以下の6つのロールに別れた、Connection/Modelレベルで設定できるOmniでの操作権限
No access：何の権限も持たないViewer：作成されたWorkbook(ダッシュボード)の閲覧が可能Restricted querier：Workbookを作成できるが、Topicベースでしかグラフを作成できないなど一部制限ありQuerier：Restricted querierに加えて、Shared modelへ反映するためのプルリクエスト発行などが行えるModeler：Querierに加えて、Shared modelを直接編集、ブランチのマージなどが可能（ただしConnectionの権限/設定管理は不可）Connection admin：対象のConnectionと関連するModelについての全権限を持つ
- Content permissions：OmniでのWorkbook自体に対する操作権限で、アカウントレベル・フォルダレベル・Workbookレベルで設定可能
グループに対するConnection Role設定
先程作成したグループに対して、Connection Roleを設定していきます。
各Connectionの詳細画面を開き、Permissionsタブを押すことで、Connection Roleの設定画面を開くことが出来ます。
Connection Roleの設定欄を見ると、Connectionから作成したModelごとに各グループ名が表示されているため、各グループの行のAccess列から、どのConnection Roleをグループに設定するか決めることが出来ます。
Content permissions
アカウントレベル～各Workbook(ダッシュボード)レベルで、コンテンツの権限管理を行うことが出来ます。
Content permissionsでは、閲覧から編集までの権限や、アカウントレベルではAI機能など各種機能をどこまで許可するか、という設定が可能です。
Accountレベル
SettingsのContent permissionsから設定可能です。
フォルダレベル
まずフォルダですが、Omniでは「Hub」でフォルダを作成して、Omni内で共通利用するWorkbook(ダッシュボード)を管理できます。
対象のフォルダのShareの設定を開くことで、このフォルダ内のWorkbookについてどのグループに対してどの操作権限を付与するか設定することが出来ます。
各Workbook(ダッシュボード)レベル
フォルダ内で管理されているWorkbookごとに権限を変更したい場合は、対象のWorkbookのShareの設定を開くことで可能です。
また、Settingsを押すことで、アカウントレベルでも設定できた各操作についての許可設定も可能です。
より高度な権限設定
Omniには他にも、多様な権限設定機能を備えています。具体的には、User attribute(ユーザー属性)を用いた、行レベルセキュリティ、Topicレベルのアクセス制御、フィールドレベルのアクセス制御、などが可能です。
詳細は以下のドキュメントをご覧ください。
6. Organizationレベルの各種設定
最後に、Omniのアカウント全体（Organizationレベル）の各種設定方法について確認していきます。（各項目の詳細な説明は割愛します。）
基本的に、Omniのトップページ左下のSettingsから設定可能です。
General
デフォルトのタイムゾーンなどの設定変更が可能です。
AI
AI関係の機能の有効化設定と、AIチャット機能のロゴやプロンプトのプレースホルダーなどの変更が可能です。
最後に
改めて新規のConnection作成を行う機会があったので、初期セットアップに必要となる手順を本記事にてまとめてみました。
Omniのセットアップ時の参考になると幸いです！
