データは分散管理へ Looker を活用した 次世代データパイプライン

8a84268593355816432ceaf78777d585?s=47 DeNA_Tech
September 10, 2020

データは分散管理へ Looker を活用した 次世代データパイプライン

DeNA のデータエンジニアは全社のデータ活用水準の向上に日々奮闘しています。その取り組みの一貫として、昨年度 BI プラットフォーム Looker を全社導入しました。複数環境に分散したデータをどのように活用しているのか、『Looker を活用したデータパイプライン』と『アーキテクチャのポイント』について説明します。

8a84268593355816432ceaf78777d585?s=128

DeNA_Tech

September 10, 2020
Tweet

Transcript

  1. データは分散管理へ Looker を活用した 次世代データパイプライン 岩尾 一優

  2. Speaker 2 株式会社ディー・エヌ・エー(2018 年 7 月 〜) • データエンジニア /

    マネージャー • メンバーと共に全社のデータ活用水準の向上に日々奮闘 • Looker の全社導入を推進 (複業)株式会社 Hogetic Lab(2019 年 4 月 〜) • 外部取締役 CTO • データ分析コンサル / 組織コンサル 岩尾 一優 (イワオ カズマサ)
  3. 宣伝 BigQuery の利用におけるコスト削減の取り組み • Google Cloud Next '19 in Tokyo

    (2019/08/01) • BigQuery を使い倒せ!DeNA データエンジニアの取り組み事例 • https://cloud.withgoogle.com/next/19/tokyo/sessions?session=D2-2-S09 オンプレ(Hadoop/Vertica)から クラウド(BigQuery) への移行の詳細 • Google Cloud Data Platform Day #2 (2020/03/31) • Google Cloud を使ったデータプラットフォームへの変革と最新の活用状況について • https://cloudonair.withgoogle.com/events/jp-data-platform-day BigQuery の活用状況とデータマネジメント • 第 11 回 Google Cloud INSIDE Games & Apps: Online(2020/09/09) • DeNA のデータ活用を支える BigQuery データの民主化とガバナンス強化の軌跡 • https://cloud.google.com/blog/ja/topics/events/google-cloud-inside-games-apps-20200909?fbclid=IwAR334MUZG_372dpJZlGuP 5Li6seKSRcBEWaIXcgTbqIa8TVxwoOWreasrV4 3
  4. 本日のゴール Looker 活用の勘所を学ぶ Looker 導入時の課題と 解決に向けたアプローチを考える 4

  5. 本日お話すること 5 DeNA の分析組織とデータプラットフォームの変遷 BI プラットフォーム Looker を導入した経緯 分散したデータを活用する次世代データパイプライン 1

    2 3 今後の展望 4
  6. DeNA の分析組織と データプラットフォームの変遷 6

  7. 2010 年頃 〜 7 事業 / 組織 • ブラウザゲームプラットフォーム事業全盛 •

    プラットフォーマーとして多数のゲームの KPI を集計 • 数十の自社ゲームタイトルも投入 • 全社横断組織としてデータ分析組織が誕生(2011 年頃) data platform データの流れ データプラットフォームの立ち上げ • オンプレ Hadoop クラスタを構築 • 集計データの品質を重視 • 基盤・データ集計処理の集中管理 • KPI 横断集計システムの開発 (MapReduce、Pig、Hive、内製 KPI 可視化ツール) Hadoop mobage platform mobage platform KPIツール
  8. 2014 年頃 〜 8 事業 / 組織 • ゲームではスマホアプリに主戦場が移る •

    事業多角化(ゲーム領域以外)の検討も進む • 利用部門のデータアナリストが活躍 • ゲーム事業の分析組織が独立( 2016 年頃) • 他の事業部にもそれぞれ分析担当が所属 data platform データの流れ BigQuery 活用開始による 一部データの分散化 • BigQuery / オンプレ Vertica を活用 • サービス / ゲームタイトルごとに 独立したデータパイプラインの誕生 • SQL ベースの BI ツールを内製 ◦ 社内のデータ活用の民主化が 大きく進む (補足)データ活用の民主化 - SQL を書けなくてもデータ活用可能であること - 利用者がデータの意味を理解し適切に使えること Hadoop mobage platform Vertica App / Game Server 内製 BI ツール(Argus) BigQuery
  9. 最近 9 事業 / 組織 • 事業が多角化 • データパイプラインの多様化 •

    SNS などの定性データも取り扱うように • 全社のデータ活用水準を高めていく目的で分析推進部が発足 data platform データの流れ mobage platform App / Game Server 内製 BI ツール(Argus) BigQuery Cloud Storage App / Game Server SNS などの 定性データ データプラットフォームの分散化が進み 民主化とガバナンスの両立を目指す • オンプレを廃止し BigQuery に統一 • 現場での自由な分析が進んだ反面、集 計データ品質維持も属人化 • SNS などの定性データも活用 • Argus には数十プロジェクト存在 • 1 プロジェクトあたり数百のクエリ、 1 クエリの長さは数百行...etc (補足)ガバナンス: データの信頼性と正確さが担保できること
  10. これまでの変遷と次期 BI ツールの検討 10 2010 - 次期 BI ツールの検討を開始 2014

    - 最近 集中管理 + 品質維持 一部分散 + 民主化 民主化 + ガバナンス 【機会】 全社の戦略である クラウド移行
  11. BI プラットフォーム Looker を 導入した経緯 11

  12. • DeNA では長らく、内製 BI ツールである Argus を利用してきた • 世の中の BI

    ツールの進化により Argus を使い続ける合理性がなくなってきていた • DeNA 全社のクラウド移行プロジェクトをきっかけに Argus の代替を検討開始 • PoC(投資判断のための検証)期間を経て 2019 年 12 月より正式採用 / 利用開始 Looker 導入サマリー Looker 導入の経緯 12 2019 年度上期 • 次期 BI ツール検討 • 要件の整理 ◦ データの民主化 ◦ データガバナンス ◦ 既存ノウハウ活用 2019 年 9 月 ~ 11 月 • PoC を実施 ◦ ユーザー機能 ◦ 管理者機能 ◦ 運用 2019 年 12 月 1 日 • 正式採用 / 利用開始 • Rapid Deployment
  13. BI プラットフォームの Looker に期待していたこと 13 ①データの民主化 • SQL を書けなくてもデータ活用可能であること •

    利用者がデータの意味を理解し適切に使えること ②データガバナンスの強化 • データの信頼性と正確さが担保できること ③既存ノウハウを活かせる • 各業務(データ活用、管理、運用)が 滞りなく移行できること • 内製 BI ツールでは SQL スキルが必須 • 新規事業など専任のデータアナリストが不在で あってもデータ活用ができる状態としたかった • 内製 BI ツールに数千の SQL クエリが存在 (SQL クエリは数百行におよぶこともある) • SQL クエリのコピペ & 亜種 & 闇落ち • SQL クエリの変更の意図が不明 • DeNA では内製 BI ツールに慣れ親しんでいる (MAU 1000、全従業員の 40% が利用) • 管理・運用面においても同様
  14. BI プラットフォームの Looker に期待していたこと 14 • ①②については事前の調査や Looker 社とのディスカッションを通 じて

    DeNA の期待値を概ね満たす と考えていた • PoC では実際に Looker を触って みて感触を確かめてみようという温 度感 ①データの民主化 • SQL を書けなくてもデータ活用可能であること • 利用者がデータの意味を理解し適切に使えること ②データガバナンスの強化 • データの信頼性と正確さが担保できること ③既存ノウハウを活かせる • 各業務(データ活用、管理、運用)が 滞りなく移行できること
  15. BI プラットフォームの Looker に期待していたこと 15 • 内製 BI ツールでの業務に慣れた 我々が

    Looker にスムーズに業務を 移行できるのか? • PoC では主に③を検証する必要が あった ①データの民主化 • SQL を書けなくてもデータ活用可能であること • 利用者がデータの意味を理解し適切に使えること ②データガバナンスの強化 • データの信頼性と正確さが担保できること ③既存ノウハウを活かせる • 各業務(データ活用、管理、運用)が 滞りなく移行できること • ①②については事前の調査や Looker 社とのディスカッションを通 じて DeNA の期待値を概ね満たす と考えていた • PoC では実際に Looker を触って みて感触を確かめてみようという温 度感
  16. PoC で確認することを一言で表現すると Looker が DeNA に馴染むか 16

  17. PoC の進め方 • PoC で確認すべき観点を整理し、必要なプレイヤーを巻き込みながら進めた • 「Looker が DeNA に馴染むか」という観点では主に下記を確認した

    17 ユーザー機能面 • LookML ◦ 学習コストはどうか ◦ 誰が書けるのか (アナリスト?エンジニア?) ◦ 誰が整備すべきか • 企画職などビジネス側のメンバーが 使いこなせそうか 管理 / 運用面 • 認証 / 認可 ◦ どのような仕組みとすべきか • 業務 ◦ Looker 導入後、各部門からの Looker 利用開始申請やアカウント発行申請は スムーズに行えそうか
  18. PoC の結果 • 「Looker が DeNA に馴染むか」という観点では問題はなさそうであった • ユーザー体験の維持などを目的とし Viewer

    / Admin ツールの開発を行った(詳細は後述) 18 ユーザー機能面 • LookML ◦ 基本的にはデータアナリストを中心に 書くことができそう ◦ 設計や難易度の高い箇所はデータエン ジニアが対応(or サポート) • 企画職などビジネス側のメンバーであって も、良く設計された explore 上であればレ ポート作成が可能 管理 / 運用面 • 認証 / 認可 ◦ 認証は Okta ◦ 認可は Google Groups • 業務 ◦ kintone を用いて必要な申請フローを 整えた
  19. 認可についての補足 2 種類の Google Groups を利用 1. ユーザーごとの最高権限(admin, dev, standard,

    viewer)を定義したグループ 2. プロジェクトごとの権限(dev, standard, viewer)を定義したグループ 両グループを突き合わせ、Looker API を通じて権限設定を実施する仕組みとした 19 グループ 1 admin dev standard viewer グループ 2 プロジェクト A の dev プロジェクト A に対して dev 権限を持つ - - プロジェクト A の standard - プロジェクト A に対して standard 権限を持つ - プロジェクト A の viewer - プロジェクト A に対して viewer 権限を持つ
  20. Viewer / Admin ツールの開発 Looker の API を活用した下記のツールの開発を実施 • Viewer

    ツール ◦ Viewer ライセンスを持つユーザーが利用するツール ◦ ダッシュボードやレポートの閲覧が可能 • Admin ツール ◦ Looker の GUI でも行うことが可能な各種設定業務の自動化 20
  21. Looker Viewer ツール 開発の目的 • 内製 BI ツールに慣れたユーザーの体験を 維持し Looker

    への業務移行を行う 特徴的な機能 • 左ペインでダッシュボードやレポートの一覧 を ツリー表示 • Space(という独自概念)でアクセス管理 を実施 (分析用 Space、CS 用 Space...) • 各 Space に Google Group を紐付ける ことで、Google Group に所属するユーザー が閲覧可能な状態になる 21
  22. Looker Admin ツール 開発の目的 • 定常業務の自動化、オペミスの防止 特徴的な機能 • LookML プロジェクトやアカウントの作成

    • 費用負担部門を管理するためのメタ情報付与 • 認可を管理する Google Groups へのメンバー出入りを検知し、 毎月のアカウント棚卸しと利用状況をチェックを自動で行う仕組み 22
  23. (Looker コンソールの場合) Looker Admin ツール 画面の例 • connection、LookML プロジェクト、 権限設定などを以下の画面で実施

    • Looker API を利用 23
  24. • DeNA では長らく、内製 BI ツールである Argus を利用してきた • 世の中の BI

    ツールの進化により Argus を使い続ける合理性がなくなってきていた • DeNA 全社のクラウド移行プロジェクトをきっかけに Argus の代替を検討開始 • PoC 期間を経て 2019 年 12 月より正式採用 / 利用開始 • Viewer / Admin ツールの開発を行うことで、 「ユーザー体験の維持」や「定常業務の自動化、オペミスの防止」を実現 Looker 導入サマリー Looker 導入の経緯まとめ 24 2019 年度上期 • 次期 BI ツール検討 • 要件の整理 ◦ データの民主化 ◦ データガバナンス ◦ 既存ノウハウ活用 2019 年 9 月 ~ 11 月 • PoC を実施 ◦ ユーザー機能 ◦ 管理者機能 ◦ 運用 • Viewer / Admin ツールを 開発 2019 年 12 月 1 日 • 正式採用 / 利用開始 • Rapid Deployment
  25. 分散したデータを活用する 次世代データパイプライン 25

  26. Looker 活用状況 26 LookML プロジェクト数 20+ Looker 活用状況 • 利用部門に所属するデータアナリストが

    LookML を習熟し実装可能な状態 • LookML を用いたデータパイプラインの全体 設計や、データアナリストが所属しない部門 のサポートはデータエンジニアが担当 • 新規に BI 環境を構築する際には Looker で立ち上げ
  27. 代表例 27 ゲーム事業における共通 KPI の集計 カスタマーサポートにおける 定性データの分析 BigQuery のメタデータ分析 1

    つの GCP プロジェクトに集約されたデータを共 通ロジックで加工し、各ゲームタイトルの GCP プ ロジェクトに加工済みデータを配布するデータパ イプライン 各サービスごとに収集する「ご意見」「お問い合わ せ」「各種 SNS のデータ」 などの定性データを可 視化するデータパイプライン BigQuery の INFORMATION SCHEMA を活用 し、BigQuery の利用状況を可視化するデータパ イプライン
  28. サービス個別 BigQuery & LookML プロジェクト NUU、RR、DAU、ARPU などゲーム共通で計測すべき事業指標の提供 ゲーム事業における共通 KPI の集計

    28 共通コンポーネント (アクセス、課金関連 など) 共通 KPI の集計 共通指標定義 共通基盤コンポーネントのログを 横断集計用の BigQuery で一次加工し 各ゲームの BigQuery に Load(配布) 統一された方法での指標算出を サポートする LookML プロジェクト 各ゲームの LookML manifest で 共通プロジェクトを継承し、 共通データの扱い方を統一
  29. ゲーム事業における共通 KPI の集計 29 データガバナンスの強化 • 共通 KPI の扱い方を統一することで、データの信頼性と正確さを担保 新規ゲームタイトルリリース時の環境立ち上げの効率化

    • manifest の継承先を増やすのみで LookML ダッシュボード / Explore が使用可能 ダッシュボード / Explore の変更への対応が容易 • 共通指標定義用 LookML プロジェクトを修正すれば、 各ゲームタイトルへ即時適用可能
  30. カスタマーサポートにおける定性データの分析 お客様の声(ご意見、お問い合わせ、各種 SNS データなどの定性データ)を サービスの改善に活かすためのレポーティングの効率化 • 投稿数の推移 / ポジネガ推移など •

    サービスのアップデート時など大量の反響が入っても すぐに重要な VOC をピックアップしサービスを改善可能な状態 30 ご意見 お問い合わせ 各種 SNS データ Kubernetes Engine Cloud Natural Language API ポジネガ判定に利用 ワークフローエンジン digdag を用いて、必 要な処理を行う
  31. カスタマーサポートにおける定性データの分析 ドリルダウン • 集計データの気になる箇所をクリックするとその詳細を表示するよう設計 • 業務に沿ったダッシュボードの設計が可能 フィルター • ゲーム内イベントの期間内での集計 •

    特定キーワードが含まれる投稿のみの集計 31 (実際のデータはお見せできないが) どのような投稿がなされているのか詳細を確認することができる
  32. BigQuery のメタデータ分析 パターン A 各 GCP プロジェクトから管理用 GCP プロジェクトへ INFORMATION

    SCHEMA を収集し 可視化するパターン 32 パターン B 各 GCP プロジェクトに対して Looker から直接接続するパターン 一般的な案件での構成 案件の性質上 GCP プロジェクトの外に データを持ち出さない場合の構成
  33. BigQuery のメタデータ分析 Looker Actions の利用 • 先月一度も検索されなかった BigQuery テーブルを抽出しスプレッドシートに保存 •

    スプレッドシートの URL を Slack に通知 33 スプレッドシート Clients スプレッドシート Clients slack 通知 slack 通知
  34. BigQuery のメタデータ分析 ダッシュボードのドリルダウン • 約 100 の GCP プロジェクトを全体俯瞰し、ドリルダウンによって内訳を確認 34

  35. パターン B の工夫点 • Looker 上で各ゲームタイトル個別 BigQuery の データをUNIONで結合する Derived

    Table を定義 • この Derived Table を参照しプロジェクト横断で データプラットフォームの利用状況をモニタリング BigQuery のメタデータ分析 35 パターン B 各 GCP プロジェクトに対して Looker から直接接続するパターン 案件の性質上 GCP プロジェクトの外に データを持ち出さない場合の構成
  36. ポイントまとめ 36 ゲーム事業における共通 KPI の集計 カスタマーサポートにおける 定性データの分析 BigQuery のメタデータ分析 •

    各ゲームの LookML manifest で共通プロ ジェクトを継承し、共通データの扱い方を統 一 • Cloud Natural Language API による ポジネガ判定 • ドリルダウン • フィルター • Looker Actions(GSS) • ダッシュボードのドリルダウン • Derived Table
  37. 37 今後の展望

  38. 38 ここまで Looker 導入の経緯や 活用事例を紹介してきました

  39. 39 全てうまくいっているのか? 課題はないのか?

  40. 40 課題もたくさんあります (ということでここからはぶつかっている課題や今後の取り組みをご紹介します)

  41. 41 BI プラットフォーム Looker を導入した目的 2010 - 2015 - 最近

    集中管理 + 品質維持 一部分散 + 民主化 民主化 + ガバナンス 「民主化 + ガバナンス」が十分に実現されたか? 民主化 • SQL を書けなくてもデータ活用可能であること • 利用者がデータの意味を理解し適切に使えること ガバナンス • データの信頼性と正確さが担保できること
  42. 42 BI プラットフォーム Looker を導入した目的 2010 - 2015 - 最近

    集中管理 + 品質維持 一部分散 + 民主化 民主化 + ガバナンス Looker 導入により「データの民主化」「データガバナンス強化」の下地が整った 今後更に Looker の導入を進める上で、以下の 2 点を検討する必要がある • ビジネス寄りの利用者の活用状況の改善 • LookML の品質管理 「民主化 + ガバナンス」が十分に実現されたか? 民主化 • SQL を書けなくてもデータ活用可能であること • 利用者がデータの意味を理解し適切に使えること ガバナンス • データの信頼性と正確さが担保できること
  43. ビジネス寄りの利用者の活用状況の改善 43 課題と背景 Looker を導入しただけではデータの民主化は進まない • これまでは SQL ベースでデータ抽出や分析を実施していたため、 ビジネス寄りの利用者が直接データを触る文化がない

    • Standard ライセンスをうまく活用できていない より使いやすい Explore の開発 • Explore で description を定義し Explore の「目的」と「対象者」を理解できるようにする • View の demension / measure に対して label や description を定義し 利用者がデータの意味を理解できるようにする 知見者による Looker 利用サポート • Looker やデータに習熟したデータエンジニア / データアナリストによるサポート • slack チャネル / オフィスアワーなど、気軽に質問できる仕組みと空気をつくる 解決に向けた アプローチ
  44. LookML の品質管理 44 課題と背景 LookML の品質をどう保っていくか • DeNA は多様なサービスを提供しており、 Developer

    ライセンス保有者が多い • 全社の LookML 開発を 1 チームで担うのは現実的でない ノウハウの整備 • 初学者用の学習コンテンツの整備 • LookML 開発における DeNA 流ベストプラクティスの整備と展開 開発体制・プロセスの整備 • レビュワーとしてデータエンジニアをアサインする • github のプルリクエストを利用する 解決に向けた アプローチ
  45. 課題のまとめと今後の展望 課題のまとめ • Looker の導入を進める上で以下の対応が必要 • ビジネス寄りの利用者の活用状況の改善 • LookML の品質管理

    今後の展望 • 上記課題を解決しながら、全社のデータ活用水準を更に高めていく • 各事業(ゲーム、ライブストリーミングなど...) • マーケ、CS、管理会計、HR など... 45 • 社内の非効率を Looker によって取り除く ◦ コピペによる SQL クエリや秘伝のマクロにさようなら • データエクスペリエンスを一段引き上げる
  46. おわりに 46

  47. 47 本日お話したこと DeNA の分析組織とデータプラットフォームの変遷 BI プラットフォーム Looker を導入した経緯 分散したデータを活用する次世代データパイプライン 1

    2 3 今後の展望 4
  48. 本日のゴール(再掲) Looker 活用の勘所を学ぶ Looker 導入時の課題と 解決に向けたアプローチを考える 48

  49. 大事なこと Looker で何でも解決しようとしないこと なぜ Looker を導入したのか そのことを忘れず本質的な課題の 解決に注力すること 49

  50. DeNA Tech の Twitter アカウントでは、 DeNA のエンジニアリングに関する 登壇資料やブログを紹介しています! ぜひ Twitter

    をフォローしてみてください!
  51. Speaker 51 株式会社ディー・エヌ・エー(2018 年 7 月 〜) • データエンジニア /

    マネージャー • メンバーと共に全社のデータ活用水準の向上に日々奮闘 • Looker の全社導入を推進 (複業)株式会社 Hogetic Lab(2019 年 4 月 〜) • 外部取締役 CTO • データ分析コンサル / 組織コンサル Thank you 岩尾 一優 (イワオ カズマサ)