Looker開発者のためのガイドライン

注意

1年間のLooker運用経験＆登壇や他企業のユーザーさんとのやりとりを経て、
ちょこちょこ書き直したいポイントが出てきています。時間を見つけてブラッシュアップする予定です。

この記事について

• Lookerの基本思想と導入した理由をベースに、活用に向けた指針をまとめたものです。
  • 弊社ではこの通りに運用を開始したところです（201911時点）
• Tipsではなく、もう少し原理的なものをまとめたつもりです。
• 目的に応じて、意味が感じられないときには無理に則る必要はありません。

命名規則

• measureには、集計関数または一般的な用語を使って名前を付けるようにする。
  • 例: sumはtotal_[field]、countはnum_of_[field]、averageはavg_[field] など。
  • https://discourse.looker.com/t/naming-fields-for-readability/712
• 比率を示すmeasureには"何あたりの"という説明も必要。
  • 例: orders percent (注文の割合) → orders per purchasing customers (購入者顧客当たりの注文数)
• yes/noのどちらが何を示しているものなのかわからなくならないよう、yesnoフィールドには明確に名前を付ける。
  • 例: Returned (返品済み) → Orders Is Returned (返品済みオーダー)
• Lookerではディメンション名の最後に期間を追加するため、ディメンショングループ に「date (日付)」または「time (時刻)」などをつけないようにする。
  • 例: created_date は created_date_dateとなってしまう。
  • これは避けられない場合もあると思う。

データの持ち方とフィルタリングに関する指針について

• 前提となる考え方としては、データへのアクセス権限、定義変更等による管理コスト、ミスリードの回避の3点が重要です。

Project/Model/Explore/Viewの構造をどう決めるか

• 考慮すべき事項アレコレ
  • データソース別に参照権限を設定できる
  • ProjectごとにGitのレポジトリが充てられる
  • Projectをまたいだviewの参照はできない（厳密に言うとできなくはないが、Projectごとにアクセスの権限を分けていることが多いはずなのでイレギュラーという認識）
    • viewの中でmeasureの集計定義を行うため、同一のProject内で完結させないと集計定義の管理コストが増大する
  • Modelをまたいだviewの参照はできる

viewの定義

• 分析に必要のないfieldはview定義時に削除 or コメントアウトしておく。

• measureの定義時に一時集計を行うため、その他fieldの定義についてもgroup by句になる発想。

• その後切り口としてpivot/filterする可能性のあるfieldについては、group by句のイメージで保持しておく。

• Label/Descriptionはちゃんと書く

  • 文章を書ききる（例：新規有料 → 新規有料ユーザー数）
  • 使い方より成り立ちを書く（例:〇〇の時に使う → 〇〇が△△のユーザーの数）
  • DataDictionaryを使うときにも影響する

フィルタリングのタイミング指針

• すべてのユーザーのExploreから除外されている必要があるもの（テストユーザー、内部指示など）は【sql_always_where および sql_always_having】 にてフィルタリング
  • ユーザーが変更できないフィルタ設定。
  • UIには表示されない (生成されたSQLを参照しない限り見ることができない)
  • SQLで記述、LookMLの代替コードを使用可: ${field_name}
• 常にフィルタリングしたいが、その範囲を変える可能性があるものは 【always_filter】 を使う
  • 定義しておくと、Exploreに自動的に追加される。
  • ユーザーはフィルタの値を変更することはできるが、フィルタ自体を削除することはできない。
  • デフォルト値をLookerのフィルタ式として記述する。
• 負荷が高すぎるクエリを実行しないようにするためには 【conditionally_filter】 を使う
  * 指定された代替フィルタフィールドの少なくとも1つが選択されている場合に削除できる。

Connection Timezone設定（2020.7.15追記、最初にやっておけばよかった）

これを設定しておかないとDashboard/Look内の相対参照系フィルタ（過去7日間とか）がUTCで計算されてしまう
現在DWH側で持っているTime系カラムの調整を行っている…

• DatabaseTimezone：接続先DWHに合わせる（弊社の場合BigQuery・UTC）
• QueryTimezone：Asia - Tokyo