📊

Lookerを使いこなす、たった1つのコツ

2024/06/06に公開

1. はじめに

株式会社 Hogetic Labの古畑です。

今回は、Googleが提供するBIツール「Looker」についてお話しします。

LookerはBIツールだけにはとどまらない機能を多く有しており、昨今では様々な企業で利用されているツールの1つとなっています。
一方で、操作に独自言語が必要など扱いが難しく、かつ日本語で解説された書籍・記事が少ないため、Lookerを導入したはいいものの使いこなせていないという声も挙がっています。

この記事では、まだLookerを触ったことのない方のために基本的な概要・特徴に触れつつ、既にLookerを利用されている方に向け、私の考える「Lookerを使いこなす、たった1つのコツ」についてご紹介していきます。

2. Lookerの概要・特徴

Lookerとは

ダッシュボード画像
引用元:Google Cloud 公式ドキュメント

  • GCPで提供されているデータアプリケーションプラットフォーム
    • 2020年2月にGoogleがLooker社を買収し、Google Cloudサービスの一つとなっています
  • データを統合、分析・可視化し、様々なデータソースからデータを取り込める
    • 既存のアプリケーションやWebサイトに組み込むことも可能です
    • データベースを物理的に保持しておく必要もありません

Lookerでできること

  • データの可視化
    • 動的なダッシュボードを作成し、リアルタイムに可視化を行うことが可能
    • 専門的な知識のないユーザでもUI上で手軽に操作可能
  • データソースへの直接アクセス
    • データを移動する時間や工数を短縮できる
    • データが複数箇所に散らばってしまう問題を回避できる
  • SQLの生成/データ定義の管理
    • 独自言語である「LookML」を利用し、集計やデータ同士の関係を記述可能
    • データ定義が作成者ごとに異なってしまう問題を回避できる

LookML画像
引用元:Google Cloud 公式ドキュメント

  • データモデリング
    • 上記のLookMLを利用し、処理の依存関係などを簡単に記載できる
    • SQLと組み合わせることで、専門的な知識のないユーザでもデータを取り回せる
  • その他
    • データビジュアライゼーション
      • 仕様に合わせて直接CSSを変更することができる
      • カスタム ビジュアライゼーションを用いて、柔軟な表示法を実現できる
      • さらに拡張フレームワークを用いることで、表示周りを独自に定義できる
    • Looker API
      • 諸機能を統合した独自のデータアプリケーションを作成できる
      • より柔軟な表示法の導入が可能に

Lookerを利用するメリット

  • 言葉や指標の定義、計算式等が一元管理できる
    • 既存のデータマートの拡張や変更を一元的に行える
    • 全てのダッシュボードに対し、分析価値を高める機能を一括アップデートできる
  • モデリング層で擬似的に理想的な構成を作成できる
    • わざわざETL/ELTワークフローを変更する必要がない
    • 誰でもLookMLを利用して、データモデリングをUI上で調整できる

3. 使いこなすたった1つのコツ

ここまで、Lookerの様々な機能やメリットについて解説してきました。
ここからは、私がLookerを利用する中で感じた「たった1つのコツ」について解説していきます。

Lookerを使いこなすたった1つのコツは、「余計な機能を使わない」ことです。
言い換えるならば、「事前の設計をきちんと行わない限り、現在実現できていないことをLooker上でやろうとしない」ことになります。

「2. Lookerの概要・特徴」で触れた通り、Lookerは単なるBIツールにとどまらず、アプリケーションの作成やデータのモデリングなど様々な機能を有するのが大きなメリットです。
そのため、Lookerを導入したからには様々な機能を導入して最先端のデータモデリング・ダッシュボードを実現したくなるのは自然なことです。

しかし、業務を通じてLookerの運用に困っている方のお話を伺うと、「1つのLookMLが1,000行を超えており、それぞれの依存関係が掴みにくい」「分析者がそれぞれ独自に定義を作成してしまい、LookMLファイルが100個以上あって区別できない」「Looker上のモデリング層を分析者が好き勝手に調整したことで、かえって保守性が下がった」など、データマートの時点で設計に失敗している方が多くみられます。

ER図画像
引用元:作図の手間から開放する、ダイナミックER図の試作してみた

運用開始直後であればイチから作り直すこともできますが、定常運用に乗ってしまうと、もはや環境を壊すこともできず、読み解くのに手間のかかる既存のLookMLファイルを避けて都度新規にファイルを作成し、ますますファイルの数が増え、より複雑怪奇になっていく…という悪循環にハマってしまいます。

Lookerはデータエンジニアリングのいわゆる『銀の弾』ではなく、あくまで「拡張性の高いデータマートを簡便に試作・運用できるツール」です。
だからこそ、従来のデータマート構築と同様に事前の設計が重要であり、適切な設計なしに作り始めたLookMLは必ず運用上失敗すると言っても過言ではありません。

何らかの課題を感じてLookerを導入した方がまず行うべきことは、課題解決のために機能を採用することではなく、Lookerで解決すべき課題と、データパイプライン上で解決すべき課題を切り分けることなのです。

4. まとめ

今回はLookerの基本的な概要・特徴に触れた上で、Lookerを使いこなすたった1つのコツについて解説しました。

Lookerは非常に便利なプラットフォームですが、データパイプライン上で解決すべき課題と、Lookerで解決すべき課題があります。
データパイプラインのアーキテクチャ全体の中で、Lookerをどう位置付けるのかを考えて、アーキテクチャを組み立てていくことが大事です。

Lookerを導入してみたい方、Lookerの運用でお困りの方がいらっしゃいましたら、以下よりお気軽にご相談ください。
お問い合わせはこちら

GitHubで編集を提案
Hogetic Lab

Discussion