[レポート] Top 10 DCL Tips & Tricks – JOIN@Home: JOIN Virtual Data Conference 2020 #JOINdata

大阪オフィスの玉井です。

米国時間の2020年10月13日から16日の計4日間に渡って、Looker主催のバーチャルデータカンファレンス『JOIN@HOME』が開催されました。

当エントリでは、「Top 10 DCL Tips & Tricks」というセッションについてレポートしたいと思います。

セッション概要

アジェンダページに記載されている当該セッションの概要は以下の通りです。

セッションレポート

LookerのDCLとは

• Lookerには「Department of Customer Love」という名前の部署がある
• 部署のミッション
  • 顧客がLookerで素晴らしい仕事ができるよう支援する
  • Lookerが顧客にとって素晴らしいものになるよう支援する（顧客からのフィードバックをLookerに反映する）
• 業務内容
  • Lookerの機能やツールの使い方を教える
  • 顧客のユースケースを聞いて、Lookerがあなたの仕事を最高のものにするために必要なことを確認する

今回のセッションの概要

• Lookerのユーザー別に分けて、Lookerを使う上でのTipsやTrickを紹介する
  • Explore
  • Developer

Explorer向けのTips紹介

ダッシュボード

• 気になるLookを全部1つのダッシュボードにまとめようとしがち
  • 理論的にはとても素晴らしいように思える
  • しかし、これはハンマーだけで家全体を建てるようなものである
  • そんな家はハリケーンであっけなく倒壊するだろう
• 1つのツールだけで全てをやろうとしない

• ボードを使ってコンテンツをまとめる
  • 特定の方法でキュレーションできる
  • コンテンツを物理的に1箇所に集めるわけではないが、データのストーリーを伝えることはできる
• 1ダッシュボードに25個以上のタイルを配置しようとすると警告が表示される
  • 26個以上置いても、全部のタイルが消滅するようなことはない
  • Lookerのインスタンスが一気に処理できるクエリのボーダーラインが大体25個
  • そして、1人の人間（の脳）が処理できるデータの量も大体これくらい
  • （25個以上のタイルを配置したダッシュボードの全てを、一目で理解できる人間がいるか？という話）

オートリフレッシュ

• ダッシュボードのデータを自動更新できる
• 更新の間隔を短くすると、常に新鮮なデータが表示できる
  • しかし、データが1日間隔でしか更新されない場合、それ以上に頻度を上げる意味はない
• 更新頻度はETLに合わせること
  • DBへのクエリも最小限にできる

データのエクスポート（ダウンロード）

• Exploreのテーブルには、デフォルトで500件の結果が表示される
  • 500以上のデータのダウンロードが必要な場合は、DBから直接ダウンロードする方が良い

スケジュール

• ダッシュボードやLookのデータを定期送信する機能
• 大体の人は「月曜の午前9時」に配信を求める
  • これをそのまま実行すると、ジョブが9時に集中してLookerのパフォーマンスに影響がでる
• データがいつ更新されるか考えてスケジュールを設定する
  • データが深夜に更新されるのであれば、スケジュール実行も深夜のうちに済ませればよい
  • 午前9時に色々な人がLookerにアクセスするが、スケジュールジョブは無いので、パフォーマンスへの影響は少なくなる

Developer向けのTips紹介

modelの構築

• 「DBで早いクエリは、Lookerでも早い」ということを理解する
  • なぜなら、LookerはSQLを投げているだけだから
  • 逆にいうと、DBで遅いクエリはLookerでも遅い
• SQL Runnerを利用する
  • 実行計画を見ることが出来る
  • 結合やインデックス等について確認し、modelを改良する
• 派生テーブルの永続化（PDT）について
  • 「遅いけど必要なクエリ」があるかどうか見極める
  • そういったクエリはPDTにすることでパフォーマンスが改善できる
  • PDTの更新はETLのポリシーと合わせる
• システムアクティビティダッシュボード
  • （Lookerに接続している）DBのパフォーマンスを確認できる
  • Looker上の遅いクエリを容易に特定できる

ProjectとDRY原則

• includeは必要最低限にする
  • viewやmodelをDBから自動生成すると、デフォルトで全viewがincludeされていたりする
  • これはmodelの構築に全てviewをコンパイルする必要があることを意味する
  • 命名規則やフォルダ等を利用して、必要なviewだけをincludeする
• ProjectのImportを利用する
  • 既に存在するProjectを簡単に持ってこれる
  • 1からコードを書く必要が無くなる（時間節約）
  • 既存リポジトリからコードをインポートすることも可
• 不要なExploreを掃除する
  • 「コンテンツアクティビティ」を利用する
  • 使われていないExploreがわかるので、それらを掃除する

テーブル計算とマージリザルト

• テーブル計算
  • Explore上でアドホックに計算ができる素晴らしいツール
  • しかし処理は全てフロントエンドで行われる
  • DBのパワーを使わないので遅い
• マージリザルト
  • すごく便利だが、永続的に使用するものではない（こちらもフロントエンド処理なので遅い）
  • ユーザーがよく使うマージリザルト=必要な結合処理
  • よく使われているマージリザルトを確認して、それらはDB側に落とし込むべき

Lookerを学ぶためのリソース

• 既に知っている人も多いとは思う
  • しかし、私含め、DCLの社員はみんなこれらのリソースからLookerを学び始めた

training.looker.com

• DCLの社員は、サポートを始めるまでLookerについて何も知らなかった
  • DCLの社員は、このリソースでLookerを学び始めた
  • つまり、DCLも顧客も、同じリソースで学習している
• Explore向け、Developer向け、それぞれのトレーニングがある

docs.looker.com

• いわゆる「技術ドキュメント」
• こういうドキュメントってちょっとドライなものが多い
  • docs.looker.comは読んでて楽しい
  • 例を挙げて説明してくれる
  • Lookerだけでは出来ないことも発見できる
  • （登壇者は）週末にお茶を飲みながら読んでいる

discourse.looker.com

• Lookerのコミュニティフォーラム
• 以下の場合に有効
  • 特定のユースケースや具体例を探しているとき
  • 他のユーザーからアドバイスをもらいたい場合
• トピック別に記事が分類されている

help.looker.com

• DCLのエキスパートが特定のユースケースについてナレッジを投稿している
• DCLのサポート業務でも案内することがある
  • 特定のユースケースを説明
  • ベストプラクティスの紹介
• 今日話した内容もここに掲載されている

おわりに

Lookerの大事な基本トピックが網羅されており、何度も見返すことになるセッションだと感じました。

Looker – JOIN@Home: JOIN Virtual Data Conference 2020 ｜ シリーズ ｜ Developers.IO