この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
大阪オフィス所属だが現在は奈良県でリモートワーク中の玉井です。
2020年7月14日から9月8日までの数週間にわたってGoogle Cloudのデジタルイベント『Google Cloud Next '20: OnAir』が開催されました。
当エントリでは、その中から「Application Development」のセッションとして公開された『Building Data Applications Powered by Looker』の内容について紹介していきたいと思います。
セッション概要
公式ページで紹介されているセッションの概要情報は以下の通り。
Title(タイトル)：
Building Data Applications Powered by Looker
Building Data Applications Powered by Looker
Speakers(講演者):
Mike Xu (Architect / Google Cloud)
Nick Fogler (CEO / 4 Mile Analytics)
Description(説明):
Dive into the Looker development platform toolbox to learn the fastest ways to make powerful purpose-built data applications that operationalize insights and streamline workflows. This technical session demos: a 4 Mile SDK with a data service and React framework of reusable components built on top of the JavaScript library Storybook; the Looker embed SDK, the Looker JavaScript SDK using CORS, the new Looker extension framework, and more. Come learn product development tips and tricks across the full lifecycle of data. For product builders at organizations of any size, from early stage startups to the world’s largest enterprises.
（Looker開発プラットフォームのツールボックスに飛び込んで、知見の獲得を運用化し、ワークフローを合理化する強力な専用データアプリケーションを最速で作成する方法を学びましょう。このテクニカルセッションでは、JavaScriptライブラリの1つであるStorybook上に構築されたデータサービスと、再利用可能なコンポーネントのReactフレームワークを備えた、4Mile社が開発したSDK、Looker embed SDK、CORSを使用したLooker JavaScript SDK、新しいLooker Extention Framworkなどのデモを行います。データのライフサイクル全体にわたる製品開発のヒントとコツを学びましょう。 初期段階のスタートアップから世界最大の企業まで、あらゆる規模の組織の製品ビルダー向け。）
セッションレポート
はじめに（アジェンダ）
- 今回のセッションの内容の説明
- 「プラットフォームとしてのLooker」の紹介
- アプリケーションを開発するためのLookerの色々なリソースの紹介
- Lookerを用いたアプリケーション開発の事例紹介
Lookerの開発者向けリソース紹介
プラットフォームとしてのLooker
- Lookerとは
- アナリスト、マーケター、プロダクトマネージャーたちのためのビジネスインテリジェンス用分析ツール
- LookMLというコードでビジネスロジックを記述する
- エンドユーザーはコード（SQLとか）を一切書かずにデータからインサイトを得ることができる
- Lookerは他のアプリケーションと連携するプラットフォームとして進化している
- LookMLで構築したデータモデルに（外部から）アクセスできる
- Lookerのデータガバナンスやセキュリティを活用できる
- フロントエンドからも参照できる
- だから、今回はLooker自体の話はほとんどしない
- 「プラットフォーム」としての側面に焦点を当てていく
3つの開発者向けリソース
- Embedded
- LookerのExploreやダッシュボード等を他サイトに埋め込む
- API
- Lookerのデータを（Embeddedより柔軟に）取得できる
- オーダーメイドのデータエクスペリエンスをゼロから構築することができる
- Embeddedで表現できないものはAPI（とSDK）の使用を推奨する
- 後半で実施する事例紹介はAPIがメイン
- Extension Framework
- Lookerインスタンス上で独自のJavaScriptを実行することができる
Embeddedの紹介
- スライドにうつっているのは、とあるサーバーアプリケーションのコード
- これはLookerのJavaScript SDK
- Embed SDK
- 最初に認証ロジックを記述する
- 「どのLooker」からのEmbeddedをリクエストするのか
- アプリケーションをLookerに認証させるための共有シークレットを提供する
- Embedded機能を利用するためのユーザーの取り扱い
- アプリケーションとLookerを使用しているユーザーの追跡（特定）
- SSOを利用することもできる
- （もしあれば）アプリケーション側のユーザーIDをLookerに提供することもできる
- アプリケーション側から利用するLookerの機能を決めることも重要
- 前述した部分を記述し終えたら、インスタンス化する
- イベントバスを介してアプリケーションと連携させることができる
- うつしているサンプルは、アプリケーション側で、イベントリスナーをバインドすることで、ダッシュボードのインタラクションを動かすボタンを変更している
- 赤枠の外側がアプリケーション
- 赤枠の内側がLooker（Embeddedしている）
- Lookerのフィルターが無い形
- アプリケーション側でフィルタを構築している
- イベントバスを介してEmbeddedダッシュボードと連携している
APIの紹介
- ダッシュボード等をそのまま埋め込むだけでは（アプリケーションの）要件を満たせない場合がある
- そういう時はAPIを使う
- Lookerで直接できることは100%カバーしている
- ニック氏が4 Mile社で開発したAPIアプリケーションを紹介
- （スライドにうつしているのは）一見LookerのExploreのように見える
- 実際はAPIで別途開発しているもの
- ユーザーが異なるオーディエンスセグメントやコホートを意識して作業できるようになっている
- 複雑なフィルターグループを構築するのではなく、コホートを比較して、コホート間の結果を見ることができる
- ユーザーデータセット内で利用可能な属性を使って、コホートの1つを構築している
- コホートを構築したら、そのコホートに対してレポートを作成して、外れ値や、コホートの特定の領域内でのポジティブなパフォーマンスやネガティブなパフォーマンスを検索することができる
- まとめると…
- これは、コホート調査に力を入れているマーケターのために設計された、より軽量ではるかにカスタマイズされたアプリケーションである
- 先程とは別の（Looker APIを使った）アプリケーションの紹介
- グローバルペイメント社の事例
- マーチャント向けのポータル
- マーチャントは時間別に取引を見ることができる
- 取引に関連付けられたメタデータの種類も確認できる
- トップレベルのレポートも見ることができる
- 一日の全体的なキャッシュフローを見ることができる
Extention Frameworkの紹介
- EmbeddedやAPIとは大きく異なるもの
- 開発側が何か用意する必要はない
- アプリサーバー、バックエンド、フロントエンド、etc…
- 自分で開発したJSをLookerに送るだけ
- データソースやLookなどは保護される（Lookerの外に出ないから）
- 4 Mile社が開発したExtention Frameworkの紹介
- これは実はLooker自体の画面
- 一番上にLookerのメニューバーが確認できる
- Lookerネイティブより、非常にブランド化されたエクスペリエンスを提供できる
- ユーザーのネイティブコンテキストを意識してLookerを拡張している
- ユーザーがインサイトを発見し、アクション性を高まるようにしている
- Lookerを、（Extention Frameworkでカスタマイズすることで）よりHomeに感じることができる機能だと思う
- このダッシュボードはスポーツウェアの会社の靴に関するもの
- このダッシュボードは複数のメトリクスを重ねている
- 天候がサプライチェーンにどのような影響を与えているか、など
- 表やグラフだけでは必ずしもユーザーがインサイトを得るのに役立つとは限らないようなエクスペリエンスを構築するのにExtention Frameworkは役立つ
- カスタマイズされたユニークなものが欲しい場合はExtention Frameworkを使うことを推奨する
他の開発者向けリソースの紹介
- Looker Blocks
- Looker Blocks®＆アクションで分析を高速化 | Looker
- LookMLのスニペット的なやつ
- あなたのLookerに直接使用できる
- Community libraries
- LookML patterns
- Patterns – Looker Help Center
- 特定のデータセットに対する最適なLookMLを（Looker側が）すでに提供している
- そのデータセットを分析するための最良の方法がすでに用意されているので、私たちからそれを「盗む」ことができる
4 Mile社の事例
事例の概要
- Lookerのマイク氏たちと1年に及ぶ長期的な契約のもと、世界的な大手小売業者のためにLooker APIを使って大規模なデータアプリケーションを構築した
プロジェクトを開始した理由
- プロジェクトのきっかけは、顧客が以前に構築した内部分析アプリケーション
- 小売店にメトリクスを提供することが目的のアプリケーション
- 小売店とは
- 棚に何を仕入れるか、どのベンダーからどのように購入するか、どのように価格を設定するかなどの重要な意思決定を行う人々のこと
- この意思決定のサポートは非常に戦略的なもの
- このアプリケーションは約2年前から開発されていた
- 約100人以上の人が作業をしていた
- しかし、アプリケーション自体はあまり使われていなかった
- 投資に対するリターンも得られなかった
- スピードと俊敏性も不足していた
- 顧客はトップダウンな分析を行っていた
- いわゆる「one-size-fits-all」な分析
- 全部盛りの使いづらい1個の分析が用意されていた
- 要するに、アプリケーションが顧客の分析ニーズに追いついていなかった
- タイムリーで関連性のあるインサイトにアクセスできなければ、ユーザーは意思決定のためにデータを使用しない
- 4 Mile社の使命は、適切なタイミングで適切な人に適切なインサイトを提供すること
- 最終的には、データを介してビジネスの基礎を推進するための支援をする
プロジェクトの方針（アプリケーションをどう改修するか）
- どのようなBIツールも、複数のレイヤーが組み合わさっていると考える
- データを定義・探索するレイヤー
- アプリケーションレイヤー
- 4 Mile社は両レイヤーを促進する方法を考案した
- 顧客はThoughtspotを使用していた
- データエンジニアリングのワークフローは手動操作で、非常に時間のかかるものだった
- 製品担当者が新しいインサイトを公開しようとすると、それがビジネス価値があるかどうかを確認するために、数週間、時には数ヶ月かかることもあった
- 要するに、データ分析の反復サイクルに時間がかかりすぎていた
- 4 Mile社のデータ分析に対する考え
- データ分析の本当の素晴らしさは、良いアンサーが新しいクエスチョンを生むこと
- これを循環させる必要がある
- データ駆動型の組織と文化を構築するのであれば、この循環を活かすデータスタックが必要である
- Lookerはまさにこの問題を解決するために構築されている
- データを移動したり変換したりしなくても、LookerのデータモデルをLookMLで簡単に変更するだけで、新しいクエスチョンに答えることができる
- 技術的な熟練度の低い人でも、実質的にリアルタイムで行うことができる
- Lookerをデータスタックに採用するだけで、スピードと柔軟性が大幅に向上する
- アプリケーション側に対する対策
- 多くの詳細でカプセル化されていないコードを、今回開発したLooker App Dev Toolkitに置き換えた
- このツールキットは、高レベルの再利用性と非常に明確な機能の分離を提供する
- エンジニアは新しいデータのインサイトの獲得を速くし、複雑さを大幅に軽減することができる
Looker App Dev Toolkitについて
- このツールキットは2つのレベルで構成されている
- APIリクエストをLookerにプロキシする役割を担う「バックエンドデータサービス」
- データの可視化を構築できる「フロントエンド用のSDK」
- 既存アプリケーションのアーキテクチャは一連のマイクロサービスで構成されていた
- 認証
- ロギング
- Thoughtspot（データの可視化）
- 「Lookerバックデータサービス」を構築して、この既存のアーキテクチャに統合することにした
- 既存のアーキテクチャの一部を切り取って置き換える必要がないという大きなメリットがある
- 開発されたアプリケーションのコンテキストから切り離されて存在するので、様々な方法で再利用できる
- 他の内部アプリケーションや、顧客が収益化したいと考えている外部向けアプリケーションに使用することができる
- エンジニアチームはすぐにLookerバックエンドデータサービスを利用するようになった
- より少ない労力でより多くのことができるようになったから
- 今回は要件的にクラウドは使っていない
- クラウドが使えるのであれば、例えばApigeeのようなクラウドベースのAPI技術サービスを使用して、このようなアーキテクチャで同じことができるはず
- API 管理 | Apigee | Google Cloud
- フロントエンドのビジュアライゼーションを処理するために構築したSDKの話
- 再利用可能な一連のReactコンポーネントを構築した
- ライブドキュメントのような役割を果たす
- デベロッパー、プロダクトオーナー、UXデザイナーが、与えられたデータストーリーを伝えるための最良の方法についてコラボレーションできる
- コードをコミットする前にビジュアライゼーションの設定パラメータを調整して、ジャストフィットさせることができる
- これらのコンポーネントを先ほど説明したLookerデータサービスに接続する
- 事前に構築されたLookerクエリオブジェクトのアイデアを渡すことができるようにパラメータを設定する
- ビジュアライゼーションと接続されると、Lookerのクエリの結果が、実質的にリアルタイムで表示される
- 生成されたコードを、数行、Reactアプリケーションのコードベースにコピーするだけ
プロジェクトの成果
- Lookerの既存機能を活用し、顧客の価値を生み出すまでの時間を大幅に短縮するスケーラブルなアーキテクチャを構築することができた
- 複雑さも軽減できた
- 新しいインサイトを得るスピードとアプリケーションの公開にかかるスピードが10倍早くなった
- 必要なエンジニアリングリソースを約3分の1にすることができた
- 関連性のあるタイムリーなインサイトを自由に利用できるようになった
- 小売店のアプリケーション利用率もすごく向上した
- 定量的な成果は前述の通りで、おおむね目標達成したというところ
- しかし、実際のところは定性的な成果が非常に大きかったと感じてる
- トップダウンの分析アプローチが、セルフサービスな分析アプローチに変化した
- データの民主化を促進された
- 最終的にはビジネス全体でより良い意思決定ができるようになった
- その結果、厳しい経済環境の中で軌道修正を行うための準備が整った組織になった
まとめ
- 今回の話で、Lookerが「プラットフォーム」としても優れていることがわかったと思う
- データを利用したアプリケーションが迅速に開発できる
- 適切なツールを使って開発することで、アプリケーション開発の複雑さとメンテナンスコストを大幅に削減することができる
- LookerはGoogleのエコシステムの中の開発環境のツールセットの一部に過ぎない
- デベロッパーとアプリケーションを念頭に置いて設計されたツールは他にもたくさんある
- AppSheet: コード不要のアプリ開発 | Google Cloud
- その他参考
おわりに
技術的な部分について
EmbeddedやAPIの概要は知っていましたが、Extention Frameworkは初めて概要を理解できた気がします。Lookerインスタンス側でJSをゴリゴリ動かせるという感じですが、「他サイトに埋め込む」「他アプリと連携する」という考え方とは逆を行っている印象を受けました。とりあえずJavaScript勉強するか…。
驚いたのは、最後の「LookerはGoogleのエコシステムの中の1つに過ぎない」という発言です。買収こそされましたが、Lookerというプロダクト自体が、完全にGCPファミリーの一員として扱われています。
事例について
「定量的成果以上に定性的成果が大きかった」という部分が印象に残っています。特に素晴らしいのは、データ分析自体がやりやすくなったということ自体だけでなく、データ分析が活発になったことによって組織全体が（ビジネス的に）強くなったということです。そもそもデータ分析というのは、ビジネスをより良くしていくための手段なので、「データ分析を取り巻くテクノロジー」そのものにとらわれず、ビジネスの成果を上げるという本質に向かっているところが非常に良いと思いました。
24
