本日開催された「Data Platform Meetup#1」に参加しました。
data-platform-meetup.connpass.com
- 全体を通した所感
- 挨拶
- 竹野 峻輔さん:「カルチャーとエンジニアリングを繋ぐデータプラットフォーム」
- yuzutas0さん:「データレイク構築後の四方山話」
- 鉄本 環さん:「DataPlatform構築プロジェクト推進の事例と学び」
- 石田 祥英さん:「大規模サービス開発における分析用データの必要要件」
全体を通した所感
- データ基盤ではなく、データプラットフォーム(Data Platform = DP)という表現かっこいいので、使っていこう。
- DPアーキテクトの基本構成は、Google BigQueryと、Cloud Composer(Airflow)。
- DPテーブルの基本構成は、Data Lake(DL), Data WareHouse(DWH), DataMart(DM)の3層構造。
- DPを使いこなす上では、人の巻き込み方、組織体制が重要。
- 利用状況モニタリング、依頼チケットのリードタイム計測など、施策PDCAの考え方も使える。
挨拶
- 平野さん
- データ分析チームのマネジャー
- データアナリスト、データ周りすべてを担当
趣旨説明
取り扱いテーマ
- DWHの設計〜活用(データレイク・データウェアハウス・データマート)
- データ活用に関わる組織・仕組みの設計(データアナリストとデータエンジニアの役割分担など)
- BIツールの設計・利用方法
- 分析に関する品質担保(ダッシュボードの品質・冪等性の担保など)
- 運用を見据えた管理・統制(権限設定・マスキングなど)
背景
所感
- 初めてのData Platform系MeetUpじゃないか?ということで、データアナリストやデータエンジニアにとって非常に貴重会であったと思う。
竹野 峻輔さん:「カルチャーとエンジニアリングを繋ぐデータプラットフォーム」
内容
データにまつわる課題
- データが汚すぎ、パイプライン、ワークフローが長すぎ。
kagglerの時間対応割合のアンケート
- 時間の50%をクレンジングなどデータの準備だけに時間を使っている。
Retty
- 4000万人が利用。
- 2017年にデータ分析チームが発足。
- 2017/11時点で月4000 -> 2019/08で月46000にクエリの数が増大。
ポイント
質問
Q: DWHを分析者のスコープだと思うが、データエンジニアのスコープはどこまでか?
- A: 自動化ツール、例えばテストを簡単に書けるようにする。そのようなツールを提供して分析者に手離れしてもらう。
Q:どういうデータを揃えておくか?
- A: どういうキーワードで流入してくるか?、サイト内アクセスなど。データ分析者が欲しいというものは、基本全部とる。
所感
- 「データ基盤エンジニアが全てやると、データアナリストにドメイン知識などの知見が貯まらない。データ基盤は分析者にとってのプロダクトとする。」
- DPについては、データアナリストをスクラムのPOやPMに据えるのは正しいと思う。
yuzutas0さん:「データレイク構築後の四方山話」
内容
ターゲット
- データは入れたけど、データ基盤をどう進化させていけば良いか困っているデータアナリスト。
コメント
- データを疎通したデータアナリストは、素晴らしい!
- イシュー駆動して欲しい。
質問に答えていくスタイル
- 中間テーブルを作るとき
- 権限管理
- 処理の遅延
- 途中で継ぎ足されたテーブルなどで処理が遅くなっていく
- データ未更新、データが落ちている
- 不整合データをどこで吸収するか
- ETLでクレンジングだけでは足りない。勇気を持って、開発担当者などにFBを返そう。
- 擬似的に履歴データを作りたい
- 日次バッチでスナップショットを取る、できれば、プロダクト側で履歴を持つのが良い。
- 法令的に残っていることが必要な場合が多い。
- 中間テーブルの作成はKPIから効果をブレイクしていく。
質問
- Q: 履歴を持つデータの設計のベタープラクティス
- Q: DWH/DMなどの過去訴求が、大変かつユーザー影響があるけど、どうやるのが良いか?
- A: A/B面作戦で、まずは_tempを作り、データ移行した後に切り替えるのが良い。
所感
- 明日から使える、DPトリビアだらけ。ひたすら感謝。
- DPの利用状況モニタリング、クエリのテスト方法やメタテーブルによる欠損の監視など、もう一度読み込みたい。
- 参考文献も豊富なので、隙がない。
鉄本 環さん:「DataPlatform構築プロジェクト推進の事例と学び」
内容
エウレカのData Platformチーム
- BIを起点に、Data Platformチームを作る。
- BIメンバーが開拓した活用データを仕組み化していく仕事。
DPプロジェクト立ち上げ
- データ活用の理想から全体像を描く。
- AsIs-ToBeを作って、ギャップをRoadMapに落とし込む。
- 対象データのスコープを決める。
- チケット対応のリードタイムを可視化して、重要度とリードタイムの幅を見て、データ基盤を整備するか判断する。
データパイプライン構築のスコープ
- SREも巻き込む。
体制の作り方
- フェーズごとに他チームを巻き込む。
- 基盤構築段階でSRE, 活用基盤構築時点でPM。
- スクラムを組んで対応している、POもいる。
- Data Platformは長期目線のプロジェクトなので、現場メンバーは短期目線と長期目線の板ばさみ。
- プロジェクト専任のBIメンバーを作って、現場の短期ニーズを吸収して、BI内で検討できるようにした。
- フェーズごとに他チームを巻き込む。
- データ活用の理想から全体像を描く。
今後やっていくこと
- 収集の強化。
- ログ送信基盤の刷新やログQAの強化。
- サービス:Pairs Engageの立ち上げ。
- 用語の定義の徹底、セグメントや指標など。
- DWHを後回しでDL→DMで速度優先。
質問
- Q: DPのスクラムオーナーをどうやって見つけるか?
- A: プロダクトに対する気持ちが強い人が向いている。
- Q: DPのプロジェクトについてかかった期間
- A: 半年ほど(すごい早い!)。
所感
- DPのプロジェクトに立ち上げに関して、アーキテクチャだけでなく、フェーズと体制、動き方とかが体系的に整理されている。
- これは初めて見た知見でとても参考になった。特にDP構築でスクラムを取り組んでいるのはユニークではないだろうか。(たぶんその方が進めやすい気もする。)
石田 祥英さん:「大規模サービス開発における分析用データの必要要件」
- ガチ広告系データエンジニアからビジネス系データアナリストになっためずらしい経歴の方。
内容
大規模サービスデータの三重苦
- 広い(多い)、データ量が数十TBなのでBQでも処理が重い、メルカリのJPだけでも1000人体制なので意思疎通が大変。
データアナリティクスが活躍する3つの領域
- お客様の行動・事業進捗の把握、UX計画・効果予測、効果振り返り。
メルカリの分析環境
- 物理
- 基本生データ全部がBQにある(恵まれている環境だ。。。)
- 組織
- 職能(Data Analyst)とプロジェクト(売上、出品者、横断的なUX改善)の掛け算。
- 思想
- どの施策を選択するか?、どのお客さんをターゲットにすべきか?などの目的先行でのデータを使った意思決定で進める。
- 物理
横断モニタリングPRJ
- 全体をモニタリングする責任者がいなかった。ので、作った。
- イベントレベルまで詳細なモニタリングダッシュボードを作成。
- 効果としては、追えていなかった数字が見え、新たな問題を築けた。
誰でも中間テーブル
ログ漏れ
- テスト設計、ログレビューを必須とする。
- BIチーム内で仮説や検証をダブルチェック。
- 効果検証フォーマットでチェック。(走る施策多くてレビューが大変そう。。。)
- ABテストでわからないことを明示しておくのが良い。
今後やりたいこと
- 元テーブルと、中間テーブルの数値チェック。
- 体系的なデータマートの整える。など
質問
Q: モニタリングは指標が少ない、絞る方が良いのではないか?
- A: 異常検知や全体的なモニタリングは、カバレッジが重要と思ったので、多い方が良いと思う。
Q: 定義したKPIをどう運用していくか?データマート作成が大変そう。
- A: 常に更新していく方針。更新が多いので、データマートは作成していない。変更があればクエリだけ更新している。Lookerで対応している。
所感
- 横断モニタリングに関して、全部を見てバランスよく判断するのは、難しいと思う。この取り組みついては、今後も注視したいと感じた。
- 施策の効果測定のガバナンスを利かす上でも、テスト設計やログ設計や仮説、検証を、レビューする体制を整えたのは、素晴らしい。
- しかし、同時にBIチームがボトルネックになって、スケールしなくなる気もするけど、どううまく対応しているのだろうか、気になる。