第3回 読んでおきたい、SokoPの「Google Cloud 実践ガイド」

Looker独自のデータモデリング言語「LookML」とは

“データの混沌”から民主化を実現する「Looker」のデータモデリング

文●SokoP(浦底博幸)/Google Cloudパートナーエンジニア 編集● ASCII

  • この記事をはてなブックマークに追加
  • 本文印刷

 みなさん、こんにちは。 Google Cloud のパートナーエンジニア「SokoP」こと浦底 (@urasoko)です。

 今回は「データモデリング」を中心として、前回記事に引き続き「Looker」がデータの民主化を実現するために備える各種管理機能をご紹介いたします。

データのサイロ化を抜け出してから陥る「データの混沌化(カオス化)」

 前回ご紹介したLookerのビジュアライゼーションやアクション、豊富なデータソースで、すべてのユーザーが各自で柔軟なデータドリブン ワークフローを実現できたとします。あるユーザーはダッシュボードにおける可視化のカスタマイズという方法で、また別のユーザーはデータソースからのデータ抽出という方法で、それぞれ分析を実現していたとします。この2人が見ている情報が、ビジネス上同じ意味をもつ情報だったとしたら――いったいどんなことが起きるでしょうか。

 データの分断化(サイロ化)を解消し、各ユーザーが必要なデータにアクセスして各自の視点で分析ができるようになったとして、次に潜むのが「データの混沌化(カオス化)」です。共通のデータソースを参照していたとしても、個々に自由なデータの抽出/集計方式を使って分析を行った場合、たとえば「集計値が異なる」「明細が異なる」「絞り込むと値が異なる」など、自由であるがゆえの新たな課題が露呈します。

 たとえば、さまざまな商品とその売上額が格納されたデータベースがあり、ここからある商品カテゴリの半期売上を集計したいとしましょう。一般的には、データベース操作に特化したDSL(ドメイン特化言語)であるSQLを用いて、集計する期間や対象データを絞り込んでデータを抽出するはずです。SQLには集計関数もあるため、コードを書いてプログラミングするよりも、容易かつ直感的にデータ集計が可能です。

 しかし、皆さんもご存じのとおり、商品カテゴリの構成や半期の定義は企業によって異なります。したがって、自社の定義に沿って抽出できるSQLを書かなければなりません。さらに集計対象の期を前後に動かしたり、過去の特定の期を集計したり、あるいは複数の商品カテゴリや複数の期を合わせて集計したりと、さまざまな集計ニーズが出てくると、そうしたパターンに合わせてSQLを毎回カスタマイズしなければならず、複雑度が増します。

 上述の例はシンプルなため実感が薄いかもしれませんが、ポイントは「実体としては一意な存在であるデータでも、分析のさまざまな軸に応じてそれぞれ異なる意味を持つ」ということです。それをSQLなどのデータ操作レイヤーで吸収する、はたまたデータベース自体に一時データとして保持するのは、複雑ですし手間がかかってしまいます。

 そうした課題に対して、BIとデータ分析の観点から必要とされるさまざまな要件を抽象化するレイヤーを独自に定義したのがLookerであり、そのデータモデリングを定義する言語が「LookML」です。

分析における統合指標をはじめ、SQLを拡張する定義を実現する「LookML」

 読者の中には「現状の分析業務はすべてSQLで解決できている」と考える方もいらっしゃるかもしれません。また「新たな言語を習得、運用していくのは障壁が高い」と懸念される方もいると思います。そこでここからは、LookerとLookMLが備える利点をご紹介します。

 BIとデータ分析の観点から求められるビジネスロジックの定義において、現状は「すべてSQLで解決している」ケースが大半だと思います。つまり、ビジネスロジックはすでにデータベースとSQLに集約されているわけです。そこでLookerでは、LookMLのモデルを既存のデータベース情報から自動作成します。テーブル定義の正しい情報からベースとなるモデルが作られるのです。

 次に、BIとデータ分析の観点から求められる要件を、独自のマークアップ言語で定義します。たとえば、このテーブルとこのテーブルを結合して、この数値を集計し、この情報はしかるべき形に編集して表示する、といった要件です。ここまではSQLでも定義可能でしょう。そもそもLookMLはSQLをベースに開発されており、SQLをさらに拡張するものとなっています。そのため、SQLの知識がある方のほうが、LookMLの習得や導入の障壁が低いと言えます。さらにLookMLならば、ドリルダウンや絞り込みのフィルタなど、BIに求められる分析のバリエーションまでも抽象化し、モデリング可能なのです。

 前回ご紹介した「ビジュアライゼーション」や「アクション」といったLooker Blocksにも、LookMLが用いられています。つまり、Lookerが実現するデータドリブンのワークフロー自体がLookMLで定義可能なのです。ワークフロー上に必要なインサイトやアクションが共通に定義され、それぞれのユーザー用途に組み合わせて活用できることで、統合された指標をもとに一貫したアクションを取れる基盤となるのです。

単発/独立のSQLスクリプトではなく、チームで開発するLookMLコード

 Lookerのプラットフォームには、データ分析に利用する機能だけでなく、LookMLの活用に必要な各種機能も揃っています。たとえば、LookMLの開発に用いる統合開発環境(IDE)も提供されており、実際のテーブル定義やデータ、集計されたビジュアライゼーション、作成されるSQLなどを確認/テストしながら開発を進めることができます。LookML自体にテストコードを定義することも可能です。

 この開発作業は「開発モード」と呼ばれる、実際の分析環境とは分離された環境で進行されます。これにより、実務上の分析には影響を与えることなく、市場や経営の変化に合わせた分析基盤の拡張が可能となっています。

 そしてこの開発サイクルを実現する仕組みとして、開発者にとっては標準となりつつある「Git」が用いられています。Gitを用いることで、チームによる分散かつ一貫したリポジトリ上での開発が可能となっており、差分やバージョンの管理もGitのお作法で、柔軟かつ迅速に制御することが可能なのです。コードのバグだけでなく、分析者から上がる要望に対して、実務環境に影響を与えず、迅速にリリースもしくはロールバックができるプラットフォームが、分析基盤全体としての品質を高く保ち続けるわけです。

データ抽出効率、ガバナンス、データソースもカプセル化するLookML

 BIとデータ分析に求められる要件を「抽象化」「カプセル化」できるのも、LookMLのメリットです。ある機能を利用する際、利用者はその機能から得られるメリットと、それに作用させるための選択肢やパラメータだけを意識すればよく、その機能が内部でどのような機構で動作しているかを理解している必要はないとの考え方です。

 たとえば車の運転をする際に、アクセルやブレーキが車の中でどのような仕組みになっているかまで詳しく知っている必要があるとすれば、利便性は大きく下がります。アクセルやブレーキを踏むことで、それぞれの機能がどう作用するかが分かっていれば十分なのです。反対に、車の内部構造まで利用者が直接操作できるようなインターフェースになっていたとすると、専門家でもないかぎり、便利などころかたちまち危険な車になってしまいます。

 もちろん、ユーザーから何の指定もできず一方的に機能が提供されるような仕組みであれば、これも利便性が下がる理由になります。その機能がもたらす結果が求めるものとは違っても、ユーザーにはなすすべがない、このような状態をブラックボックス化と呼びます。

 BIとデータ分析において、不用意にデータアクセスが多発すると、データベースの負荷も高まりますし分析のパフォーマンスも落ちます。それを解消するのがキャッシュ機能ですが、ツール側が自動でキャッシュ機能を活かしデータ抽出を効率化したとしても、ブラックボックス化されていることにより、しかるべきデータに対して、キャッシュを使うべきか、最新のデータを取得しに行くべきかが、みなさんのビジネス ロジックに適さない可能性も出てきます。

 Lookerにもデータ抽出を効率化する機能が存在します。Lookerの場合、その定義をビジネス ロジックにあわせて定義可能です。たとえばレコードの合計件数が増えていればデータベースから最新のデータを取得する、レコードの更新日時が新しければデータベースから最新のデータを取得するなど、といったものです。ツールが備える機能を活かしつつも、ビジネス ロジックを柔軟に定義できるのもLookMLの特徴です。

 それでは逆の視点から、皆さんがデータ分析をされたいとして、データベースへのアクセスやデータの操作は必要でしょうか。また、複数のデータベースからデータを抽出するのに、それぞれのデータベースでの抽出方式の差異に困惑されていたりしないでしょうか。

 LookMLでモデルを定義すると、データベースへ問い合わせを行うSQLはLookerによって最適な形に翻訳され、対象のデータベースに合わせた形で処理されます。これが「カプセル化」のメリットです。LookMLで定義された統合指標上で分析ロジックを定義すれば、そのユーザーにデータベースへのアクセス権を与える必要もありませんし、不用意なデータ操作でデータベースに影響を与えるリスクも減らせます。これにより、事実上のデータガバナンスが保たれるわけです。もちろん分析におけるアクセス制御もLooker上で定義可能です。

アナリストとエンジニアの協力で実現するデータの民主化

 さて、“データの混沌”からデータの民主化に至る道筋が見えたでしょうか。今回ご紹介したものにとどまらず、Lookerには、継続的に改善し続けるデータドリブン ワークフローを、統合的に定義できる機能が揃っています。データ分析を担うデータアナリストに並んで、みなさんの事業に沿ったデータモデリングを実現するデータエンジニアも一緒に、Lookerの活用をご検討されてみてはいかがでしょうか。

 次回は、BigQueryとLookerを組み合わせた事例をご紹介する予定です。最後までお読みいただきありがとうございました。

■関連サイト

過去記事アーカイブ

2021年
03月
04月
05月
06月
07月
2020年
04月
05月
08月
09月
10月
11月
12月
2018年
09月
2017年
06月
2014年
07月