本日開催された「Data Platform Meetup#2」に参加しました。
勉強会メモ Data Platform Meetup#2 本日開催された「Data Platform Meetup#2」に参加しました。
data-platform-meetup.connpass.com
- 全体を通した所感
- 挨拶
- 長部 和仁さん：「プロダクト中心のデータ駆動を推進していくために大事なこと」
- Hashimoto Yuki さん：「データを用意しただけだと使われないので、使ってもらえるようにした努力」
- Inuzuka Shintaroさん：「DWHを活用したクックパッドの機械学習プロジェクト」
- Kurimuraさん：「アプリデータの分析を楽に効果的に！FirebaseAnalyticsとお友達になると良い３つの理由。(仮)」
- Takeno Shunsukeさん：「DWH デザインパターン 〜 テーブル設計編 〜」
全体を通した所感
- 前半２つのデータ駆動推進、使ってもらえるようにした努力の発表については、泥臭く挑むエンジニア達の姿に感じるものがありました。エンジニアとビジネスサイドという異質の組織間をつなぐ上で発生する場合、人に優しく寄り添うという姿勢の大事さ。
- 機械学習データの活用事例や、アプリログを効率良く活用するためのFirebaseAnalyticsの活用については、純粋に面白そうなのでやってみたい。
挨拶
内容
- 挨拶は、Retty平野さん
- DPMの趣旨
- 事業会社でDMPを担当してる人がノウハウを発表
- 開催の背景
- データレイクが整備されてきた、既存コミュニティで議論されていない内容(DWHの設計など)、課題感が自社内に閉じているのでノウハウの共有の場
- DPMの趣旨
- 会場のご案内は、pixiv高橋さん
- 本日の会場提供頂いたpixivのデータ駆動推進室の方
- データ駆動推進室：https://inside.pixiv.blog/jaggy/6421
- データ活用をサポート業務を担当
- 本日の会場提供頂いたpixivのデータ駆動推進室の方
長部 和仁さん：「プロダクト中心のデータ駆動を推進していくために大事なこと」
内容
- 長部さんの自己紹介
- データ基盤エンジニアの方
- データ基盤にpixiv本体しかない状況から、周辺プロダクト（ECサイトなど）含めてデータを含めて集約にご尽力
- 話すこと
- データ活用が求められる背景
- データ活用のための組織構造について
- pixivではどうしたか？
- 民主化する際の壁
- 分析スキル：担当者がSQLを覚える必要がある
- データ理解：開発者視点での謎のデータ構造への理解
- ガバナンス：それぞれが好きにデータを触れるため、正しくないデータ集計となる可能性
- pixivのデータ駆動推進室のやったこと
- 推進室は直接の分析課題を解決せず、現場が解決する。間接的に支援を行う。
- データ基盤操作のテンプレート化
- BIツールLookerの導入
- 互助会機能を充実：analystチャンネル、データエンジニア交流会、分析わくわくタイム
- 分析わくわくタイム：https://t.co/B8y4pOzAcr?amp=1
- チュートリアルリソースの充実
- 取り組みの結果
- 現在の課題感
- 中間テーブルの管理
- 管理ができない部分の発生
- 非プロダクトへの適用
質問タイム
- Q.学習教材の用意は、非エンジニア向けにも提供した？
- A.ビジネス系の人向けのチュートリアルも行なった。
- Q.BQは従量課金なので、跳ね上がる可能性もあるがどう抑制しているのか？
- A.監視はしているが、個人に任せている。悪いクエリを発行した人は呼び出して注意される！
- Q.推進側のモチベーションの維持ってどうやっているのか？KPIをどう設定している？
- A.データ利活用の課題意識を持っている人が集まってきた感じ。
Q.LookerはLookMLをかけないと使えないが、そのあたりは誰が対応しているのか？
- A.定義も各部署に開発者がコミットするようにしている。データ推進室がレビューなどを行いデータガバナンスを担保している。
個人的に伺った質問
所感
- データ集計の民主化事例として良かった。（自分で取り組んでいるが、他人に勉強してもらうというのはとても大変。）
- Looker導入はコストはかかるので、今すぐに真似できるものではない。ただし、テンプレート化、チュートリアルリソース追加、互助機能は真似していけそう。
Hashimoto Yuki さん：「データを用意しただけだと使われないので、使ってもらえるようにした努力」
内容
- 概要
- （データを用意しただけときに）かつて発生していた要望
- 使い方がわからない、データがわからない
- 分析の仕方が分からない などなど
- そこから、エンジニアがポスピタリティを発揮して使ってもらえるようにした施策を紹介
- ドキュメントを整える
- ユーザガイド
- 機能や、それを使うと出来ることの概要を書く
- データ欠損情報や更新履歴も記載
- 事業部の様子を偵察（事業部が色々があるので、それぞれ偵察しにいく）
- 各事業、プロダクトの担当を選任で設定する
- 各事業部の定例MTGに参加する
- プロダクトの動きを先回りして抑えておく
- 事例共有会
- 実際に分析基盤に使っているアナリストやディレクターに分析事例のプレゼンをお願いする（寿司とかお酒も出したりする。）
- ドキュメントを整える
- 結果
- 年々プレゼンスが高まった。フィードバックもらえたり、リリースしやすくなった。
質問
- Q.事業部制でバラバラの中、一箇所に集める上で、データガバナンスをする上での工夫は？
- A.事業部側からデータ分析基盤に追加依頼をもらう。定型で依頼内容を容易しておいた。マスキングしないといけない個人情報の有無など。
所感
- 使ってもらえるようにしたという施策について納得感があった。
- ツールの利活用推進って内部向けだから簡単なわけもなく。外部ベンダーがフォローアップするような施策をしっかりとやらないと推進できない。システムだけを形だけ導入だけで後は進むということはない！が腑に落ちた。
- ドキュメント、事業部への入り込み、事例共有会など泥臭くやってて大変さが伝わってきた。
Inuzuka Shintaroさん：「DWHを活用したクックパッドの機械学習プロジェクト」
自分が気になったポイント
- DWHを使った機械学習プロジェクト
- 特徴抽出を行う際
- Redshiftに直接接続してしまうと様々な問題
- 推論結果（学習後データの活用フェーズ）の際
- 機械学習プロジェクトで作ったデータを使ってもらうためにdmemoで定義を記載
- dmemo: https://techlife.cookpad.com/entry/2016/08/08/103906
- 特徴抽出を行う際
所感
- 機械学習で作った特徴データの説明もdmemoで管理するのは良さそう。（ユーザ側で発生したものではないので無意識に区別してたけど、活用するという観点では同じデータだった。）
Kurimuraさん：「アプリデータの分析を楽に効果的に！FirebaseAnalyticsとお友達になると良い３つの理由。(仮)」
自分が気になったポイント
- FirebaseAnalyticsの紹介
- FirebaseAnalyticsの活用状況
- 分析系テーブルが大きくなりにくいように、工夫している
- 3ヶ月分のDataMartは、1/10を無作為抽出！
- 2日以上前の後追いログが来るので、遡って更新する必要はある。
- 分析系テーブルが大きくなりにくいように、工夫している
質問
所感
- 前半のFirebaseAnalyticsの紹介ページがすごい良い。完全に理解できた！感じ。（注：完全に理解できた！）
- FirebaseAnalytics、色々と高機能なので、myアプリ作ってみて試してみたい。
Takeno Shunsukeさん：「DWH デザインパターン 〜 テーブル設計編 〜」
内容
- 分析上で発生するつらみ
- Join祭りが辛い。
- 乱立するダッシュボード
- 分析のためのデザイン
- Rettyでの事例：BigQuery上の対応
- 横持ちテーブルで対応
- イベントログ層やエンティティ層（ディメンジョンテーブル/非正規化テーブル）、PVやセッションなどの指標層（ファクトテーブル）
- 誰のためのデザイン
- 分析基盤とは、データ基盤開発者と分析者が関係する
- レポート分析基盤とは、分析者と意思決定者が関係する
質問
- Q.テーブルの設計、ディメンジョンとファクトを分ける。なぜこういうデータの持ち方をするのかというメンバー間の相違をどう解消したのか？
- A.規約にのっかるとこういう便利さがあるというメリットの認識を共有している。
所感
- 〜テーブル設計編〜とあったので、多分○○編などの続編があると期待。洗替え更新や差分更新などの更新編とか。
