入社1日目の方に向けてLookerの概要を説明する #Looker

これは何か

僕のチームに新しくインターン生が入ることになり、その方にLookerを触ってもらうことになりました。そこで、その方に向けてLookerの概要を説明するとともに、同じようにLookerを触り始めた人に向けて僕の知見を共有できればと思いこの記事を書きました。

Lookerとは（BIツールとは）

集計したデータを可視化してくれるBIツールです。データベースに接続し、そこにLookerからクエリを投げることで返ってきた集計データを、Lookerのダッシュボード上で表示します。
通常、DBにクエリを投げたときに集計データはテーブル形式で返ってきますが、Lookerではテーブル形式で返ってきたデータをグラフにしたり時系列にしたりすることで、そのデータがどんな示唆を持っているのか発見しやすくすることができます。例えば、13ヶ月の時系列データを作ることで売上のトレンドを追ったり、ファネルを作ることで顧客の離脱ポイントを把握したりすることができます。

引用：https://looker.com/blog/dashboard-design-updates-looker-3-46

Lookerでダッシュボードを作るまでの一連のプロセス

Lookerは下図の要素で構成されているのですが、これらがどのような機能を持ち、ダッシュボードを作る過程でどのような役割を果たすのか見ていきます

引用：https://docs.looker.com/ja/data-modeling/learning-lookml/lookml-terms-and-concepts

View

view: example {

  dimension: office_id {
    type: number
    sql: ${TABLE}.office_id
  }

  dimension: division {
    label: "部署"
    type: string
    sql: ${TABLE}.division
  }

  measure: revenue {
    label: "収益"
    type: number
    sql: ${TABLE}.revenue
  }

  measure: total_revenue {
    label: "合計売上高"
    type: sum
    sql: ${TABLE}.revenue
  }
}

viewは、dimensionやmeasureを定義する重要な役割を果たします。
上記のexample.viewの例で見ると、「部署」の定義はdivisionにあたり、「合計売上高」の定義はtotal_revenueにあたります。

Lookerでは、同じviewは各Looker Projectの中に複数存在させられないので、基本的にどのダッシュボードでも「部署」といったらこのexample.viewのdivisionを参照しますし、「合計売上高」も同様です。つまり、どれだけダッシュボードが存在していても、viewで定義を変更させるだけでその変更が全てのダッシュボードに適用されることになります。そのため、ダッシュボード間の定義のズレや、ダッシュボードの作成者による集計定義のズレがなくなります。

Model

connection: "bigquery-project-name"

# include all the views
include: "../views/**/*.view"

explore: office {}

explore: example {
  join: office {
    type: left_outer
    relationship: many_to_one
    sql_on: ${example.office_id} = ${office.id}
  }
}

modelは基本的に、viewをjoinする役割を持ちます。
typeでleft_outerやinner、right_outerといった結合条件を選択し、sql_onでon句を書きます。

Dashboard

引用：https://looker.com/blog/dashboard-design-updates-looker-3-46

DashboardはBIツールの最も重要な機能で、データを可視化してくれる場所です。
viewとexploreができたら最低限ダッシュボードを作る準備が整います。
そうしたら、ダッシュボードの編集機能から新しいタイルを作成し、dimensionとmeasureを設定して、その返り値をグラフ等で表現していきます。

引用：https://docs.looker.com/ja/exploring-data/visualizing-query-results

この画像は、dimensionやmeasure、filter等を設定してデータを集計する機能を持つexploreです。ここで集計項目を設定してSQLを生成し、それを接続したデータベースに投げることによってデータを取得します。
example.viewで「部署別の売上高」を出すグラフを作るときには、dimension（画像下部のAccidents Countryとなっているところ）にdivisionを設定し、measure（Accidents Serious Accidents Count, Fatal Accidents Count, Total Fatalities）にtotal_revenueを設定します。
そうすると、棒グラフの場合divisionを横軸、total_revenueを縦軸としたグラフができ上がり、その棒の高さで売上高を比較することができます。
また、example.viewにはmodel内でoffice.viewをjoinしたので、officeの持つカラムをdimensionやmeasureに置くことも可能です。
それから、フィルターを設定したり、ピボットテーブルを作ってクロス集計をすることもできます。

こうしてexploreで作ったグラフを一つにまとめてビジネス上の示唆を出すものがダッシュボードであり、このデータビジュアライゼーションのプロジェクトにおいて最も重要なアウトプットです。

思うように動かないとき

Lookerを使っていると、エラーが解決しない、エラーは出ないけど意図した通りに表示されない、こういう動きをさせたいけどLookerに実装されているか分からない、などいろいろな困難に衝突すると思います。
そのときには、

ググる
チームのメンバーに聞く
チャットサポートに聞いてみる

という形で進めてもらえたらと思います。
チャットサポートはかなりすぐレスポンスをくれるので、僕もよく利用させてもらっています。チャットに画像を貼って状況を説明することもできますし、サポートの人が僕たちのexploreを直接編集することもできるので、実際にどこをどう設定するのか見せてもらうことも可能です。

よくあるエラー

自分がエラーに遭遇したときに書き足します。

意図しない挙動

joinしたテーブルのmeasureが表示されない

joinしたテーブルにprimary_keyが振られていないと表示されません。（詳細）

view: view_name {
  dimension: field_name {
    primary_key: yes
  }
}

これでどこかのdimensionにprimary_keyを振りましょう。適切なカラムがない場合は、concatなどを駆使しながらユニークなdimensionを作ってそこにprimary_keyを振りましょう。

僕が思うLookerの良いところ

集計項目を一元管理できるところ
これはLookerの最大の特徴だと思います。人によって定義にブレが起きることが無くなりますし、一度定義してあったものを再定義してしまう無駄な手間も省けます。
僕は今developerとして開発をしていますが、exploreの人がLookを作るときもすでにdeveloperの方で定義した項目を使ってくれるので、安心感があります。
ブラウザベースなところ
URLで簡単に展開できるのは便利だと思います。スプレッドシートの延長線上にあるようなお手軽感
チャットサポート
非常にスムーズに困りごとを解決してくれます