この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
Looker社によるロードマップ、顧客事例、パートナー企業によるセッションが堪能出来るデジタルイベント『BEACON Japan 2020』が2020年09月03日から2020年09月24日までの毎週木曜日、計4日間に渡り開催されています。
当エントリでは、その中から2020年09月10日に発表されたセッション「データは分散管理へ。Looker を活用した次世代データパイプライン」のレポートをお届けします。
セッション概要
公式サイトで紹介されているセッションの概要情報は以下の通りです。
データは分散管理へ。Looker を活用した次世代データパイプライン
登壇者：
・岩尾 一優 氏, システム本部 分析推進部 データプラットフォーム G グループマネージャー, 株式会社ディー・エヌ・エー
発表内容：
DeNA のデータエンジニアは全社のデータ活用水準の向上に日々奮闘しています。その取り組みの一貫として、昨年度 BI プラットフォーム Looker を全社導入しました。複数環境に分散したデータをどのように活用しているのか、『Looker を活用したデータパイプライン』と『アーキテクチャのポイント』について説明します。
セッションレポート
ここからは、当日に公開されたセッションの内容についてレポートします。画像にあるLookerのTシャツは今回のセッションのために岩尾様が自作されたもので、（こちらの画像だと文字がかすんでしまっていますが）Tシャツにある「Refine your data pipeline」には、Lookerを活用してデータパイプラインを洗練させていきましょう、というメッセージを込めているとのことです。
イベントのセッション動画については下記リンクにてアクセス可能です。
自己紹介
株式会社ディー・エヌ・エー（2018年7月～）
- データエンジニア/マネージャー
- メンバーとともに全社のデータ活用水準の向上に日々奮闘
- Lookerの全社導入を推進
（複業）株式会社Hogetic Lab（2019年4月～）
- 外部取締役CTO
- データ分析コンサル/組織コンサル
本日のゴール
- Looker活用の勘所を学ぶ
- Looker導入時の課題と解決に向けたアプローチを考える
本日お話しすること
- DeNAの分析組織とデータプラットフォームの変遷
- BIプラットフォームLookerを導入した経緯
- 分散したデータを活用する次世代データパイプライン
- 今後の展望
DeNAの分析組織とデータプラットフォームの変遷
2010年頃～
DeNAではブラウザゲームプラットフォーム事業が全盛の時になります。全社横断組織としてデータ分析組織が誕生しています。データプラットフォームとしてはシンプルで、Hadoopを中心としたアーキテクチャになっています。集計データの品質を重視していたため、基盤・データ集計処理の集中管理をしています。
2014年頃～
ゲームはスマホアプリに主戦場が移ってきました。ゲーム事業の分析組織は独立しており、利用部門のデータアナリストが活躍していった時期になります。データの流れも複雑化してきており、BigQueryやオンプレのVerticaの活用も開始しています。SQLベースのBIツールを内製しており、社内のデータ活用の民主化が前に進んだという時期になります。
最近
ゲーム以外にもライブストリーミング、ヘルスケア、スポーツなど、事業が多角化しております。それにともない、データパイプラインも多様化、取り扱うデータもログやデータベースといったサービス内のデータだけではなく、SNSなどの定性データも取り扱うようになってきました。アーキテクチャとして特徴的な部分は、オンプレを廃止しBigQueryに統一しました。この頃、現場での自由な分析は進んでいますが、集計データの品質維持が俗人化してきており、民主化とガバナンスの両立を課題として考えておりました。
機会として全社の戦略であるクラウド移行があり、次期BIツールの検討を開始したという流れになります。
以前はDeNAの使い方にマッチした既製のBIツールがなかったため、内製BIツールを開発して5年ほど使用しておりました。近年はLookerをはじめとして様々なBIツールがあり、内製BIツールを使い続ける合理性がなくなってきました。Lookerに関してはPoCという投資判断の検証期間を経て、2019年12月から正式採用しております。2019年の上期は次世代のBIツールに求められる要件の整理、2019年9月からのPoC期間中はどういった観点でPoCを行うのかを整理してきました。
次世代のBIツールに求められる要件として、以下の3点を定義しました。
1. データの民主化
SQLをかけなくてもデータ活用が可能であること、利用者がデータの意味を理解し適切に使えることが重要になってきます。内製BIツールではSQLスキルが必須であったため、新規事業などデータアナリストが不在であるとデータ活用がなかなかすすまないという状況がありました。データの民主化が期待値のひとつになっています。
2. データガバナンスの強化
データの信頼性と正確さが担保できることと定義しています。その背景として、内製BIツールでは数千のSQLクエリが存在し、数百行に及ぶこともあります。SQLクエリを作成する過程でコピー＆ペーストして一部改変していくうちに、少し間違いがあるだけで、そのクエリが使い物にならなくなってしまう。また、SQLクエリの変更の意図が不明になってしまうということもありました。
3. 既存ノウハウを活かせる
内製BIツールを全従業員の40%が利用してきているため、管理運用面を含めてDeNAの業務がスムーズに移行できることが非常に重要となります。
1番と2番に関しては事前の調査やLooker社とのディスカッションを通じてDeNAの期待値を概ね満たすと考えており、Lookerを実際に触って試してみようといった温度感になっていました。3番については、内製BIツールの業務に慣れている従業員がスムーズに移行できるのかを精緻に検証を行う必要がありました。
PoCで確認することを一言で表現すると、LookerがDeNAに馴染むかを検証していくことになります。
PoCで確認すべき観点を整理し、必要なプレイヤーを巻き込みながら、PoCを進めてきました。ユーザー機能では、LookMLの学習コスト、誰が書けるのか、誰が整備すべきものなのかといった勘所がなかったので、こちらについて確認すべきと考えました。また、データの民主化を進めるにあたって、企画職などビジネス側のメンバーも使いこなせるのかという確認しておく必要があると考えていました。管理運用面では認証/認可が既存の社内の仕組みとマッチするのか、それとも独自に運用する必要があるのか、業務面ではLooker導入後に各部門からの利用申請をどう扱うのかということも考える必要がありました。
PoCの結果、「LookerがDeNAに馴染むか」という観点では問題なさそうという判断になりました。LookMLはデータアナリストを中心に書くことができそうですが、設計や難易度の高い箇所についてはデータエンジニアの対応が必要な部分もあると判断しました。企画職などビジネス側のメンバーは、Exploreが設計されていれば容易にレポート作成が可能と判断しています。認証は社内でも標準で利用しているOkta連携、認可はGoogle Groupsを用いています。業務面でもkintoneを用いて申請フローを整えることができたので、特に問題はありませんでした。
認可については、2種類のGoogle Groupsを用いることで権限を管理しています。1つ目はユーザーごとの最高権限を定義したグループで、ライセンスの形態に紐づくものになります。2つ目はプロジェクトの権限を定義したグループです。たとえそのdevライセンスを持っていても、全てのプロジェクトを閲覧できる権限があるわけではありません。2つのグループを突き合わせることで、権限設定を行う仕組みとしました。こうした仕組みを用いて、ミスなく、効率的に権限を管理することができています。
また、一部ユーザー体験の維持を目的としてLooker ViewerとLooker Adminツールの開発を行っています。
Looker Viewerツール
Looker Viewerツールの開発は、内製BIツールに慣れたユーザー体験を維持したまま、Lookerの業務を行うということを目的としています。以下のスライド内のあるキャプチャの赤枠に関して、左ペインでダッシュボードやレポートの一覧をツリー表示する機能を搭載しています。DeNAでは非常に多様な事業を展開していますし、ゲームでも複数タイトルを分析していくため、一覧性が非常に重要視されているためこのような設計をしています。また、Spaceという概念でアクセス管理を実施しています。カスタマーサポートがいるSpace、外部のユーザーがいるSpaceなどいろいろありますが、それぞれ見たいデータ、見ていいデータというのが異なるため、各SpaceにGoogle Groupsやダッシュボードを紐づける形で、権限管理を行っています。
Looker Adminツール
Looker Adminツール開発は、定常業務の自動化、オペミスの防止を目的としています。Lookerの環境を立ち上げる際に、プロジェクトの作成やアカウントの作成、権限設定、コストを各利用部門に配布するという業務がありますが、そのメタ情報の管理する上でいろいろなものが必要となります。それを自動化するツールがLooker Adminツールになっています。
以下のスライドのキャプチャはConnectionやLookMLプロジェクトを立ち上げる時の画面になります。通常ですと、右側のコンソールを用いて全ての値を設定する必要がありますが、開発したAdminツールでは最小限の項目を設定するだけであとはLooker APIを通じて自動的に設定を行うというツールになっています。
分散したデータを活用する次世代データパイプライン
Lookerの活用状況について、プロジェクト数としては20以上あります。また、データアナリストはLookMLを習熟していて実装可能な状態になっています。ただ、全体設計であったり、データアナリストが不在の部門に関しては、データエンジニアが担当することもあります。新規にBI環境を構築する際はLookerで立ち上げることができるようになっています。
本日は3つの事例をご紹介します。
ゲーム事業における共通KPIの集計
NUU、リターンレート、DAUなど共通の計測すべき事業指標をどのように可視化しているのかについて、以下のスライドの一番左が共通コンポーネントからアクセスログや課金系のログを1つのBigQueryに集約されます。一次加工されたのち、各クエリのBigQueryに配布されるというパイプラインになっています。ここまででデータのスキーマというのはそろったのですが、可視化する際に定義がばらついていては横断的にデータを見ることができなくなってしまうという課題が発生してしまいます。共通指標定義用のLookMLプロジェクトを定義しており、View、Explore、LookMLダッシュボードなどを定義しています。こちらはLookMLマニュフェストの中で継承させるという設定を行うことで、共通データの使い方を統一しています。このようにデータがちらばっていても、Looker上でその可視化する定義を共通化していればデータの扱い方を統一できるという事例です。
メリットとして、データガバナンスの強化が挙げられます。それ以外にも新規タイトルリリース時の環境立ち上げを効率化することができます。Manifestの継承先を増やすだけなので、LookMLダッシュボードやExploreを個別に定義しなくても使用可能になります。運用していく中でダッシュボードやExploreの変更や追加についても、共通指標用のLookMLプロジェクトを修正するだけで他のものに適用することができます。
カスタマーサポートにおける定性データの分析
お客様の声をサービス改善に活かすためのレポーティングを、カスタマーサポートのメンバーが行っています。投稿数の推移やポジティブ/ネガティブの推移をブレイクダウンするような形で詳細を分析し、レポートを作成するという流れになっています。この仕組みを構築することで、サービスのアップデート時など大量の反響が入った際にも、すぐに重要な声をピックアップして改善することが可能な状態になっています。データパイプラインについては、まず、ご意見、お問い合わせ、各種SNSデータを1つのBigQueryに集約します。そのときにデータをそのワークフローエンジンのDigdagを用いて収集しています。Digdagの中でポジティブ/ネガティブの判定を行いますが、判定自体はCloud Natural Languageを用いています。ポジティブ/ネガティブのスコアや感情の起伏のスコアを算出し、BigQueryに書き戻す、そしてLookerを用いて可視化するということを行っています。
Lookerで可視化する際に工夫した点として、ドリルダウンとフィルターがあります。ドリルダウンは集計データをグラフに表示し、気になる個所をクリックするとその詳細を表示するような機能になっています。以下のスライドの例の場合、いつもよりネガティブな投稿が多いなとなった場合に、そこをクリックすると実際にどのような投稿があったのか詳細を確認することができます。フィルターは、ゲーム内イベントの期間内のみでの集計や、キャラクター名などの特定のキーワードが含まれる投稿のみを集計することで、効率的にレポーティングを行っています。ドリルダウンやフィルターはLookerに標準で搭載されている機能なので、何かしら発生した際にタイムリーに利用することができるので、カスタマーサポートのメンバーからも喜ばれています。
BigQueryのメタデータ分析
パターンAとパターンBの2つのパイプラインがありますが、まずパターンAではGCPプロジェクトからINFORMATION SCHEMAを収集するこいうことを行って、Lookerで可視化しているパターンです。実際には100程度のGCPプロジェクトからINFORMATION SCHEMAを収集しています。パターンBは、各CGPプロジェクトに対してLookerから直接接続するパターンです。案件の性質上、GCPプロジェクトの外にデータを持ち出したくないという場合に用いるパターンになっています。
Lookerで行っている工夫としては、まず1つはLooker Actionsを利用しています。先月一度も検索されなかったBigQueryテーブルを抽出し、スプレッドシートに保存するということに用いています。これは、BigQueryテーブルに無駄なコストがかかっているかもしれない、ということを検出して改善することを目的として作っています。その後Slack通知を行い、改善をしていくという流れになるのですが、Lookerのデータをスプレッドシートにエクスポートすることができるので、自前で開発する必要がありません。Lookerがあればこの棚卸業務を実現できているというところになります。
ダッシュボードごとドリルダウンするという機能を使っています。約100のGCPプロジェクトを全体俯瞰する必要があるので、全体俯瞰用のダッシュボードではプロジェクトごとのコストのランキングやサマリデータを表示しています。その中で気になるポイントを深堀りしたいという場合に、「このGCPプロジェクトの詳細を見る」というところをクリックすると、別で定義したダッシュボードに飛びます。指定したGCPプロジェクトにデータを絞り込むことができ、何か問題が発生した際にその原因の特定が容易になるように設計しています。
もう一点、パターンBのLookerからBigQueryに直接接続するパターンでは、Derived Tableというものを定義しています。データ自体はこの3つのプロジェクトに散らばっていますが、Derived Tableを定義しデータをユニオンすることで、あたかもデータが一ヶ所にあるかのように分析を行うことができるという点で、非常に便利だと思っています。
今後の展望
近年ではデータの民主化、ガバナンスの強化が重要であると説明をしました。この点に関して、Lookerの導入によってデータの民主化、データガバナンスの強化の下地が整ったという感触です。今後、全事業でLookerを導入していく上で、ビジネスよりの利用者の活用状況の改善、LookMLの品質管理の2点を検討していく必要があると考えています。
ビジネスよりの利用者の活用状況の改善
Lookerを導入しただけではデータの民主化は進みません。これまでビジネス寄りのユーザーは、SQLベースで分析を行わなければならないため直接データを触ってきておらず、現状Standardライセンスをうまく活用できてないという課題があります。この課題の解決に向けて、より使いやすいExploreの開発と、知見者によるLooker利用のサポートという2点のアプローチを考えています。
- Exploreの開発
Exploreが増えていく中で、その目的や対象者が理解できるようにDescriptionを定義する、ビューの中で定義している各カラムの中でディメンションやメジャーのディスクリプションを定義してデータの意味を誰でも理解できるようにする、ということが挙げられます。
- 知見者によるLooker利用のサポート
Looker社によるサポートの前段として、社内でお互いにサポートしあえるようになることを目指しています。すでにSlackチャネルがありサポートはしていますが、今後オフィスアワーなど気軽に質問できる場として提供していきたいと思っています。
LookMLの品質管理
DeNAは多様なサービスを提供しているため、全社のLookMLの開発をチームで担うのが現実的ではないという背景があります。そのため、ノウハウや開発体制、プロセスを整備して、全体に伝播していくような流れを作っていく必要があります。
- ノウハウの整備
すでに用意しているものとしては、実際にゼロからLookMLを学んだアナリストが中心となって、Wikiにはまりポイントやどのように学習したのかなどをまとめている学習コンテンツがあります。今後はLookML開発におけるDeNA流のベストプラクティスを整備して展開していく必要があると考えています。
- 開発体制・プロセスの整備
開発体制、プロセスは、ソフトウェアの開発と一緒でレビューが必要と考えています。現在もすでにGitHubのプルリクエストを活用し、レビューを通ったものをマスターとしてマージすることで、LookMLの品質の維持に努めています。
おわりに
最後に、Lookerを導入する中で思ったことが何でもLookerで解決しようとしないことが大事だと思っています。Lookerは非常に便利なプラットフォームですが、データパイプライン上で解決すべき課題と、Lookerで解決すべき課題があると思っています。データパイプラインのアーキテクチャ全体の中で、Lookerをどう位置付けるのかを考えて、アーキテクチャを組み立てていくことが大事だと思っています。そして、なぜLookerを導入したのかを忘れずに本質的な課題の解決に注力するという、これが非常に大事なことだと思っています。
さいごに
『BEACON Japan 2020』からセッション「データは分散管理へ。Looker を活用した次世代データパイプライン」のレポートをお届けしました。Lookerを導入の検討から活用、そして今後の課題までご紹介いただきました。特にこれからLookerの導入を検討されている方には、参考になるセッションだったのではないでしょうか。最後にお話のあった「何でもLookerで解決しようとしないこと」「なぜLookerを導入したのかを忘れずに本質的な課題の解決に注力する」という点については、どの製品を導入する上でも念頭におきたい大事なポイントであると感じました。
DeNA TechのTwitterアカウントでは、今回のセッションの振り返り記事も紹介したいと思っているとのことでした。よろしければチェックしてみていただければと思います。
複数環境に分散したデータの管理にLookerを活用
DeNAでは分散データの管理にLookerを活用してます。
こちらLookerによる改善ポイントなどご紹介します！
・複数タイトルでの共通KPI集計
・カスタマーサポートにおける定性データ分析
・BigQueryのメタデータ分析#BeaconJapanhttps://t.co/GNBqImqp2t— DeNA Tech (@DeNAxTech) September 10, 2020
5
