Data Driven Knowledgebase

Lookerとは
LookerとはBIツールでありながら表示の際にクエリを投げることで、従来DWH側で行う必要のあったデータの構造や整形の定義までまとめてBI側で行うことができるほか、リアルタイムなデータアクセスを実現させているBIツールです。BIツール上で完結した処理が可能なので、データ駆動型の意思決定を迅速に統合された環境で行うことのできるツールとなっています。

この記事で対象とすること
Lookerはデータソースの変換や整形を行うことができるために、従来のBIツールよりも複雑で込み入った構造をしています。ここではそれらの構成される要素を紹介した上で、データアクセス制御を中心に説明していきます。

データアクセス制御を理解するには、プロジェクトやモデル、ビューなどの関係を理解している必要があります。まず、それぞれについて紹介いたします。全体の構成図は以下の通りです。


LookMLプロジェクト
LookMLプロジェクトは、取り扱うデータベースごとに決定する単位です。アクセスするデータベースごとに作るとよいと思います。複数のデータベースに接続することも可能です。
ただし、そのプロジェクトに対してデフォルトの権限セットのdeveloper以上の権限を持つようなユーザーに関しては、プロジェクトの接続しているデータベース上にあるすべてのデータにアクセスできてしまう(後述)ので、そのようなケースについては権限をカスタマイズや接続設定の再構成などが必要となります。

viewファイル
データを定義する部分に当たります。プロジェクトのなかで作成し、そのうちのいくつかをモデルで読み込むことによってデータを定義します。
1つのテーブルやデータにつき1つのviewファイルを作るのが一般的で、データベース上のテーブルを表すviewと、そのカラムに当たる部分を表すdimensionやdimension_group、集計などを行った結果を保持するmeasureと呼ばれる要素を定義します。これらの要素を定義することによって、データベース上のテーブルのカラムやその集計結果をLookerで使用することができるようになります。
なお、デフォルトの権限セットではdeveloper以上の権限でないと編集できません。

modelファイル
exploreやダッシュボード(後述)の定義、複数のviewの結合、その他細かい権限の設定などを記述します。このファイルごとにmodelが作成されます。こちらもデフォルトの権限セットではdeveloper以上の権限でないと編集できません。
今回ご紹介するデータ制御はこの単位で行います。そのため、この部分を編集できる権限を持つユーザーはデータベース上の全てのデータにアクセスすることが可能となります。

explore
model上で定義し、viewやviewの結合結果などに対して、実際にSQLクエリを投げてデータベースから取ってきて可視化まで行う一連の操作を表します。exploreの際に使用した設定(どのカラムを使うか、どのような可視化を行うか)をLookという形でフォルダやダッシュボード上に保存できます。
ただし、大事なのは設定を保持するだけなので、保存先を開いた際にもキャッシュの有効期限が切れていればSQLクエリが投げられますし、データベースのデータが変われば(再度読み込みは必要)違う出力になります。

ダッシュボード
基本的にはLookを複数まとめて保存する機構です。モデルファイルの中で定義されるLookMLダッシュボードと個人定義のダッシュボードに分けられます。後者についても共有が可能ですが、前者ではgitによる管理が行えます。

データアクセス制御とは、ユーザーに対してどのデータにアクセスできるのかを制御することです。ここでは、複数の部署のユーザーがデータを参照するためにアクセスする状況を想定し、ユーザーに対してロールとモデルによって制御することを考えます。

ロールについて
ロールとは、ユーザーやユーザーグループに紐付け(アタッチ)ることで、その人のできることが決定する権限の基本単位です。Lookerにおけるロールは、以下の2つの組み合わせで表現されます。

1. 権限セット: アタッチしたユーザーやユーザーグループが、何をできるのかを表す
2. モデルセット: その権限をどのモデルに使えるのかを表す

プロジェクトを分けない制御方法
ユーザーグループ(ユーザー)に権限を与える際の適用範囲として、モデルの組を使用します。また、今回のシナリオでユーザーに与える権限はviewer権限でよく、viewファイルやmodelファイルが編集される恐れがありません。
従って、部署の扱うデータ(ユーザーが見ることの許されるデータ)を扱うモデルごとにモデルセットを分けて、それをviewer権限と組み合わせて部署ごとのロールを作成したのち、部署を表すユーザーグループにアタッチすれば、ユーザーごとに見ることのできるデータを限定させることが可能です。なお、例えば複数の部署を統括するような立場の方には、そのすべての部署にあたるユーザーグループをアタッチするだけで自然な拡張が可能となります。


この制御の利点
この形で制御するとプロジェクトは単一のものとなるので、管理者側は一元的に管理することができます。また、ユーザーグループを最小の単位として設計することで、グループのアタッチにより様々な権限レベルを作成できます。

viewer権限を与えたユーザーに対して、そのユーザーの属する部署に応じてアクセス可能なデータを限定するには、部署ごとにモデルの分割とロール・ユーザーグループの作成を行えば良いことがわかりました。データにそもそもアクセスできないようにしコンテンツアクセスによってアクセスを制御するよりも安全性は高いと考えられるため、データへのアクセス制御をする際には、ぜひ検討してみてください。