[レポート] dbtとLookerを使ってデータガバナンスを効かせる #dbtcoalesce

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

2020年12月7日〜11日の間、Fishtown Analytics社がcoalesceというオンラインイベントを開催していました（SQLを触っている方はピンとくるイベント名ではないでしょうか）。

「Fishtown Analytics社って何やってる会社？」という感じですが、dbtというツールを開発しているベンダーです。dbtについては、下記をご覧ください。

今回は、その中からPerfect complements: Using dbt with Looker for effective data governanceというセッションを受講したので、レポートを記します。

イベント概要

公式

• Coalesce 2020 online - December 7-11, 2020
  • Perfect complements: Using dbt with Looker for effective data governance - Coalesce 2020 online - December 7-11, 2020

概要

Learn how a rapidly growing software development firm transformed their legacy data analytics approach by embracing analytics engineering with dbt and Looker. In this video, Johnathan Brooks of 4 Mile Analytics outlines the complementary benefits of these tools and discusses design patterns and analytics engineering principles that enable strong data governance, increased agility and scalability, while decreasing maintenance overhead.

私なりの要約

Lookerは優れたBIツールですが、その高機能ゆえ、DWH側（の設計）を無視したまま使い続けてしまうことが多々あります。この場合、Looker上のLookMLは、ごちゃごちゃしたViewやExploreが大量発生して、いずれLookerは破綻します。そういう時、dbtを一緒に使うことで、データガバナンスを効かせたデータ分析環境を実現することができます。

dbtとLookerを一緒に使うメリットが紹介されたセッションでした。

セッションレポート

はじめに

• このプレゼンで話すこと
  • dbtとLookerは非常に相性が良いという事（その理由も）
  • 機能の面で相性が良い
  • データチームに何をもたらすか、という観点でも相性が良い

自己紹介

• ジョナサン氏
  • 4 Mile Analyticsのソリューションアーキテクト
• 4 Mile Analyticsについて
  • フルスタックデータコンサルタントの会社
  • Modern Data Stackと呼ばれるサービスでソリューションを構築している
  • Lookerやdbtも使う

• 今まで150くらいのLooker案件をやってきた
  • これは初代ポケモンの数と同じ
  • （これにかけて、スライドの画像がポケモンのコスプレ）

アジェンダ

• dbtとLookerがデータ分析において完璧にマッチする理由をお話する
• Lookerの視点から「なぜdbtは効果的なのか」について説明する
• dbtとLookerのそれぞれの役割について説明する
  • 二者は共通する機能と異なる機能が混在する
• FAQ
  • （プレゼン自体の質疑応答ではなく、事前に用意された質問と回答を紹介する形）
• 最後に、強力なデータ文化を構築することに関する話をする

データ分析における共通課題

• Lookerユーザーが直面している課題について見てみる

ケーススタディ

• グローバルなソフトウェア開発会社の事例
• 最初は小規模なデータチームでスタート
  • Excelで手動レポートを作成していた
• しばらくして、Lookerを使用開始
• DWHはSnowflake

• このチームが使用しているデータスタック
  • SnowflakeやBigQueryをDWHとして使用
  • FivetranでデータをDWHにロード
  • LookerがBIの役目を果たす

• 2年間で会社は急成長した
• 複数の部署がこれらのデータを頼りにしている状態となった
• Lookerは本当に効果的だった

• データチームは迅速に素晴らしいことをした
  • Lookerで生データからviewファイルを構築し、ダッシュボードを開発した
• しかし問題も発生した
  • 急成長中の企業において、新しいテーブル等が追加されることはよくある
  • その度にviewをどんどん量産していった
  • その結果、1つのExploreの中に30以上のviewが結合される結果となった
  • 物凄い重いダッシュボードが誕生した
• ダッシュボードが、ビジネスユーザーにとって使いづらいものとなってしまった
  • テーブルを片っ端からJOINしまくるのは基本的に良くない

Lookerにおける、よくある課題

• Lookerは非常に短い時間でデータ分析ができる
  • そのため、皮肉にも、データウェアハウス側の設計をスキップしてしまうことがある
• Lookerをしばらく使っているとPDT（永続派生テーブル）の存在に気づくかもしれない
  • データをDWH側に書き戻せる
  • データのスクレイプに利用できるが、少し制限がある

• 企業によっては、このくらい複雑なデータ構造かも
  • Lookerで片っ端からviewにすれば、分析はできるが、この運用は問題である
  • その運用はいずれ破綻する（複雑すぎる）

dbtと一緒に使うという発想

• この課題は、別のツールで補いたい
  • dbtがベストだと考えている

dbtとLooker

dbtとLookerの違い

• スライドに記載しているのは、それぞれのツールのメイン機能
• dbt
  • 複雑なデータ変換に最適
  • DAGを生成できる
  • データ変換処理や、DWHのデータに関するドキュメントを生成できる
  • データ変換処理等に対して自動テストできる
  • 増分変換（インクリメンタルビルド）も可能
• Looker
  • 主な役割はセルフサービスBI
  • ダッシュボードやビジネスデータモデルを使ってデータ分析を実施する
  • LookMLというコードでデータモデリングを行う
  • エンベッド、アラート、データ配信等も可能

dbtとLookerの共通点

• ビジネスロジックをバージョン管理できる
  • Analytics Engineeringの原則を満たす
  • リリースに気を配ることができる
• コードでデータモデリングできる
  • SQL、yamlファイル、LookML
  • dbtとLookMLの書き方は似ている
  • 良い意味で本質的に似ているのであって「微妙に異なるから混乱する」わけではない
• 独立した開発環境をもてる
  • dbtは開発スキーマ
  • Lookerは開発モード
• 「DRY」なコードが書ける
  • dbtのref
  • Lookerの置換参照
  • ロジックを再定義する必要がない
• Analytics Engineeringの原則と哲学を促進するツール
  • この考え自体はdbt（Fishtown Analytics）発信だが、Lookerにもフィットすると思う

共生するメリット

Analytics Engineeringの価値を再確認する

• 元々はFishtown Analytics社が提唱したものだと思う
  • 4Mile社がBI分野にもフィットするようにちょっと変えた
• データアナリストは、ソフトウェア開発と同様の実践基準とツールに適応する必要がある
  • 複雑なアナリティクスロジックやビジネスデータモデルを表現するため
• 重要なデータ分析インフラは、複雑なデータパイプラインに隠れてはならない
  • ユーザーが管理して、アナリストが利用できるようにする
• 分析チームは、データの完全性と信頼性を犠牲にすることなく、迅速に反復処理を行い、新しいユースケースに拡張できるようにしなければならない
• dbtもLookerも、やはりこれらの原則を満たすツール
  • GUIではなくコードでビジネスロジックを表現
  • ソフトウェア開発のようにデータモデリングができる
  • データソースから変換後データまで辿れる
  • データの信頼性を犠牲にすることなく迅速にデータ分析が可能

Lookerダッシュボードのデータが何のデータソースからできているのか辿る

• 私はAnalytics Engineeringの原則を実現したい
  • 特に、複雑なデータ分析インフラを隠さないこと
• dbtはデータソースがどこにあるのか示すことに優れている
  • ソースデータが、どのようにして、分析に適したテーブルやデータマートに変換されるのか知りたい
  • これをLookerでやってみる
• スライドはLookerのダッシュボード
  • ビジネスユーザーとして、Eコマースのファネルがどう構築されているかを追ってみる

• 左上の画像（ファネルのタイル）
  • 右上にある小さいメニューからExplore画面（右下）へ移動できる
• 右下の画像（Explore）
  • 使用されているdimentionやmeasure、フィルタ等が確認できる
• ここでは、例として、「all session」というメトリクスが何なのか知りたい
  • さらにメニューから詳細を辿れる

• 先程の画面からLookMLの記述のところに来れた
  • all sessionという定義が確認できる
  • labelを付与していることも確認できる

• Looker上の「all session」が、何のテーブルのカラムが元になっているかが、先程の手順で判明した
• これをdbt上で確認する
  • Lookerのviewの元になっているテーブルがわかる
  • そのテーブルの説明、定義、実施されているテストもわかる
  • 作成される過程もわかる（DAG）
  • dbtのドキュメントを確認すると、「all session」の測定値が表示されている
• ソースデータから、Looker上の値がどう生成されているのか判明できた
  • Lookerとdbtを使って、データソースから何が構築されているのかが、全て明確にすることができた

冒頭のケーススタディのその後

• この企業に最終的に推奨したのは、dbtとLookerを併用すること
• Looker上に記述していた変換ロジックをdbtへ移行した
  • PDTもdbtに移行
• ビジネスユーザー向けのデータ分析はLookerで実施
• データチームが、dbtとLookerの使用において、ソフトウェア開発のベスプラを一部適用し始めた
  • 良い傾向である
  • この過程でDWHを使用していることを再認識し、ディメンショナルモデルについても考え始めた
• 分析チーム側にも変化があった
  • 修正と管理のサイクルを終わらせることができた
  • Lookerだけでは難しかったデータ変換の可視化がなされたので、データ分析自体に焦点をあてられるようになった
  • LookMLで、よりクリーンなセマンティックレイヤーを構築できた
• 組織全体がデータドリブン型になった

• 信頼性とパフォーマンスが高いセルフサービス型データ分析が実現できている
• （ヒトカゲがリザードンに進化したレベル、という意味？）

FAQ

Lookerを使用していて、データ変換をdbtに移行したい場合、どれくらい大変か？

• まず、そんな大変なものではない
• SQLの初期移行は「数日」レベル
  • 週レベルではない
• 本番は移行してからだと思う
  • dbtを効果的に使用するためのフェーズ2
  • その後、さらなる最適化作業
• dbtの機能を活用していく
  • ドキュメンテーション
  • インクリメンタルモデルやエフェメラルモデルの導入し、巨大なサブクエリを分解する（モジュール化）
  • Jinjaの使い方を覚える

カラムの説明はどっちで定義すればよいか？

• 上流でやる方が良い
  • だからdbtでやるべき
• dbtでカラムの説明を定義する
  • そのメタデータをLookerに渡す
  • 必要に応じてLooker側で補足する
  • RefinementsやExtendsを使用する方法も考えられる
• 現在、Lookerの「crate view from table」はdbt側のdescriptionはスルーする
  • 4Mile社がオープンソースのツールを準備している

ビジネスロジックやデータ変換はLookerでやるべきか？

• 一般的に、データ変換はdbtで実施するべき
  • いくつか例外あり
• ダッシュボード上のユーザーの操作に応じてクエリを変えたい場合（パラメータ、テンプレートフィルタ）
  • この場合はLooker側でロジックを持ったほうが良い
• ステージングデータを利用したダッシュボードのデータアラート
  • Lookerのaccess grantsを使用する
  • 本番以外のデータについて、特定のユーザーのみにアクセスを絞ることができる
  • ビジネスユーザーに変なアラートがいかないようにできる

新しいデータ分析を実施する場合、dbtとLooker、どちらで開発を開始すればいいか？

• 厳密には、そのチームによると思う
• ダッシュボードを作ってすぐにテストをしたい、というユースケースを想定した場合、Lookerでやるのがいいかも
  • 既に存在するdimention等を再利用できる
• 新しいデータセットや、複雑なデータリストが必要な場合は、dbtからはじめるのが良い
  • ロジックを定義するのには最適な場所である

強力なデータ文化を創るために必要なこと

• データの信頼性
  • ユーザーが見たものをユーザー自身が信頼できるようにする
• データの民主化
• 新しいことに対応するための敏捷性

まとめ

• Lookerとdbtを組み合わせることは、データドリブン文化を進めるための燃料のようなものだと思う
• dbtから見たLooker
  • Analytics Engineeringの原則を満たしている
• Lookerから見たdbt
  • dbtでデータ変換を管理することで、処理の可視化とデータガバナンスが得られる
  • dbtのSQLとYAMLベースの記法は、LookML開発者にとって馴染みやすい

• dbtとLookerを併用するという観点
  • データの信頼性を高め、強力なデータ文化とアナリティクスの成熟度を高めるのに役立つ
  • ビジネスユーザーがデータに基づいた意思決定を行うため、アナリストはインサイトと新しい要件に集中することができる
  • 新しい要件を迅速に構築できるスケーラブルなデータ分析基盤となる

おわりに

dbtとLooker（LookML）は似ていて、どういう使い分けをすればいいかわからなかったため、セッションを視聴しました。

一緒に併用することが正解である、というのはわかったのですが、もう少し部分部分の使い分け事例がほしいところでした（ちょっとだけFAQで触れられていますが、ちょっと物足りない…）。