Data Platform構築プロジェクト推進の事例と学び

Data Platform Meetup #1（https://data-platform-meetup.connpass.com/event/142822/）の発表資料です。

エウレカのData Platformとそれを支える組織構成の概要の紹介と
実際にData Platform構築プロジェクトの立ち上げ〜推進をどのように計画実行し、しくじりカバーしてきたかを実例と共に載せています。

Transcript

1. 1 Data Platform構築 プロジェクト推進の事例と学び Data Platform Meetup #1 @Retty Sep.5, 2019 eureka, Inc Tamaki Tetsumoto
2. 2 自己紹介 インターンからエンジニアとして新卒入社、データ分析チームを立ち上げ Data Platformに従事 エンジニア時代 2011 インターン開始（現在最も古株のエンジニア） 2013 PHPエンジニアとして新卒入社 　　 受託開発・テクニカルディレクター 2014 Pairsサーバーサイドエンジニア データ時代 2015 Goフルスクラッチ データマイグレーション 2016 Analyzeチーム設立 2017 BIチーム設立 2019 Data Platform 基盤構築従事 ※プライベートモード会員のため検索には出てきません
3. 3 会社・サービス紹介 グローバル展開のオンラインデーティングアプリと新規事業の結婚コンシェルジュアプリ Pairs Pairs エンゲージ
4. 4 Agenda 1. エウレカにおけるData Platformの概要 2. プロジェクト立上編 3. プロジェクト推進編 4. 今後やっていくこと 具体例や失敗も交えながら話します。 参考になれば幸いです。 今日お話しすること と、今日は話さないけど、話せること（懇親会で話しましょう！） 話せること • Data Platform 運用編 • エウレカBIのチームビルディング • Tableau導入のあれこれ • Finance・Marketing・Productとの関わり ...etc
5. 5 5 eurekaにおける Data Platform
6. 6 分析環境はGCPで構築 データベースはBigQueryを、ETLはCloudComposerを採用
7. 7 各データベースの定義と関係 DataLakeの拡張・精度担保とDataMartの洗練によりDataWareHouseを強化する DataLake DataWareHouse DataMart データをほぼ そのまま保存 しているDB 分析用の下処理 を施したDB ビジネス観点 で整備したDB XXX Log Master Data Service Data Data Source Tableau Workbook 拡張 精度担保 洗練 強化
8. 8 冪等性とは | ある操作を1回行っても複数回行っても結果が同じであることをいう概念 存在意義 マスキング済みのデータのコピーがあることで • Productに影響を与えない分析環境を用意できる • プライバシーリスクを犯さずにデータを扱える • ロジックが介在しないのでデータの定義が変わらない (冪等性) Data Lakeの役割はDWHの可能性を拡げること Productに影響を与えずに冪等性を担保しながら、扱うデータの精度向上と対象範囲拡張を担う XXX Log Master Data Service Data
9. 9 Data WareHouseの役割はデータ活用の下処理を最小化すること 必ず通る道を整備しておくことで、本当に発揮するべき所で時間と能力を使えるように 存在意義 • 前処理工程をなくすことによる、作業・集計の パフォーマンスの向上 • 前処理忘れによる定義違いを防止し、 データを扱うハードルを下げる = データ民主化 エウレカでは... • 必ず行う前処理の処理済みデータを DWHとして準備している ◦ 時差計算 / 非正規化 / テストデータの除去 ...etc user_id job_id registered_at 1 1 2019-09-01 01:10:23 UTC 2 3 2019-09-01 15:24:23 UTC ... ... user_id job_name registered_date 1 エンジニア 2019-09-01 2 デザイナー 2019-09-02 ... ...
10. 10 1. 冪等性の罠 BQはレコードの削除・更新に制限があり、 特定の日にこけたワークフローの再実行が気軽にできなかった → 日付分割テーブルで作り直し、日単位でテーブルの再生成を可能に テーブルタイプ 分割 分割基準 Day フィールドで分割 event_at 初期設計（内部Partition） Data WareHouse設計でのしくじり パフォーマンス重視で内部 Partitionを選択してハマった2つの罠...冪等性を優先するべし user_id event_at（TIMESTAMP型） 1 2019-09-01 17:10:00 UTC 2 2019-09-01 17:12:00 UTC 1 2019-09-02 19:10:00 UTC ... ... user_login user_id event_datetime（DATETIME型） 1 2019-09-01T17:10:00 2 2019-09-01T17:12:00 ... ... user_login_20190901 user_id event_datetime（DATETIME型） 1 2019-09-02T19:10:00 ... ... user_login_20190902 最新設計（日付分割テーブル） テーブル設定
11. 11 2. TIMESTAMP型の罠 内部Partition機能はTIMESTAMP型のフィールド指定が必要だが、 時差考慮済みのデータがUTC表示されるため、ミスの誘発に繋がった → 日付分割テーブルにすることで型の制限が外れたので、 　DATETIME型のフィールドで作り直した テーブルタイプ 分割 分割基準 Day フィールドで分割 event_at 初期設計（内部Partition） Data WareHouse設計でのしくじり パフォーマンス重視で内部 Partitionを選択してハマった2つの罠...冪等性を優先するべし user_id event_at（TIMESTAMP型） 1 2019-09-01 17:10:00 UTC 2 2019-09-01 17:12:00 UTC 1 2019-09-02 19:10:00 UTC ... ... user_login user_id event_datetime（DATETIME型） 1 2019-09-01T17:10:00 2 2019-09-01T17:12:00 ... ... user_login_20190901 user_id event_datetime（DATETIME型） 1 2019-09-02T19:10:00 ... ... user_login_20190902 最新設計（日付分割テーブル） テーブル設定
12. 12 Data Martの役割は誰でも簡単に正しく使えること 刻々と変化する状況やニーズに追従するには、誰もが触れる環境とセットで初めて価値が最大化する 存在意義 • ビジネス観点の指標が取り込まれており、使うことで意思決定や事業理解に繋がる • 取り扱う手段も提供されており、組織内のデータリテラシー向上を後押しする エウレカでは... • 可視化ツールにTableauを導入し、全社員が触れる環境へ（ DataMartとセットで順次拡大中） • 誰もが一目でわかる命名 ◦ 例）経過日数の表記ルール ▪ 起点日を 0 とする / 期間は [N]to[M] / 一定数以上は [N]andMore で表記する
13. 13 データ活用に責務をもつBIを中心に、Data Platfromチームを結成 SREチームとの連携でパフォーマンスや精度を担保しながら活用を推進する 組織構成 • サービス開発（Pairs/Engage） • 横断（CTO） チーム構成 - BI • 各Projctに専任アナリストを配置 • Data Platform専任を独立配置 チーム構成 - Data Platform • BI・SREから専任を配置
14. 14 再利用 既存のData Platform基盤を使い すぐに 使えるDWHの実現 DWH運用におけるチーム内の役割 各PRJ専任のBIメンバーが開拓した活用データを仕組み化し、新規事業に還元するエコシステムを実現 データ活用の開拓 集中と機動力を重視 Adhoc分析歓迎 仕組み化 ニーズを汲み取り共通化して Data Platform構築へ
15. 15 15 プロジェクト立上編
16. 16 プロジェクト立ち上げ期の 3 Step ステークホルダーを初めから巻き込むこと、計画段階でのスコープマネジメントが鍵を握っている 1. データ活用の理想から全体像を描く ◦ データの活用サイドと提供サイドの両軸と一緒に話す ▪ いつまでにどうありたいか、どんなデータを使いたいかの夢を語る ◦ 依存関係や現状とのGAPを可視化し、Roadmapに落とし込む 2. 対象データのスコープを決める ◦ プロジェクト実施に向け、説明とチェックのためのメトリクスを取る ▪ 分析者がクエラーになりがちの状況なら、依頼の分類とリードタイムの計測など ◦ 対象の優先度をステークホルダーと合意することで、腰を据えて開発に集中できる状況にする 3. データパイプライン構築のスコープを決める ◦ 価値を考えるにあたってがDL/DWH/DMの切り口が適しているが、構築段階では切り口を変える ◦ SREとの会話で「収集/整形/活用」のデータパイプライン毎に切り分けられたのが大きかった
17. 17 Step1. データ活用の理想から全体像を描く 各所からデータ活用の理想を集め、 AsIsToBeを作ってギャップをRoadmapに落とし込む データ活用に対する理想を出し合い、 依存関係と優先度のすり合わせを実施 Product BI AI SRE AsIs (現状) ToBe (理想) 全体設計に落としこみ、理想と現実のGAPを 付箋でマッピング。依存関係と優先度を整理
18. 18 Step2. 対象データのスコープを決める 長期プロジェクトの新規実施に向けて、チームのリソース状況を可視化し、対象を選定 ビジネスサイドとの合意 MTGの目的 • ビジネススピードの要所を落とさずに 新規プロジェクトに集中するため 説明に用いたメトリクス • 分析業務・差し込みの発生件数 • 分析業務・差し込みの事業部別構成比 • 事業部別分析業務のリードタイム 決定事項 • DWH構築対象の優先度決定 • 事業部毎の相談窓口・基準の見直し 発生件数 事業部別 構成比 リードタイム
19. 19 リードタイムとは、発注から納品までに要する時間 BIでは業務をチケット管理し、 Cumulative Flow Diagramで可視化可能に
20. 20 リードタイムとは、発注から納品までに要する時間 チケット作成からのステータス変化を可視化することで、事業部毎の課題を整理できる 事業部 A 事業部 B 定期的に作成が急増し、 TODO状態が長い → 捌き切れず、機会損失になっている可能性 作成は安定しているが、 Review状態が長い → 不要なタスクが発生している可能性
21. 21 Step3. データパイプライン構築のスコープを決める 構築段階ではデータパイプライン毎にスコープを分ける。 SREはデリバリーのプロとして参画。 1 2 3 4
22. 22 22 プロジェクト推進編
23. 23 チーム構成はスコープに合わせて変化させる 他チームを巻き込むことでニーズを引き出し、推進力とフィードバックが得られる 1. 初期の基盤構築段階でSREを巻き込む 現実的なものを作れているか？ → 長期の運用を見据えたフィードバック 2. 活用基盤構築で利用者(PM)を巻き込む 使えるものを作れているか？ → 成果物(DataMart)へのフィードバック 3. 必要に応じた人事異動 データ活用を描いた低レイヤー知識が必要 → 本人の希望もありデータマネジメントに責務をも つSREが誕生し、BIの架け橋へ Next Scope
24. 24 Scope2-1. 活用基盤の構築 いち早く基盤を構築し、試行錯誤する体制を整えるためにスクラムを採用 スクラムを選んだ理由 複雑で変化の激しい問題に対応するためのフレームワー クであり、可能な限り価値の高いプロダクトを生産的かつ 創造的に届けるためのものである 1. 利用者の価値起点での設計を常に意識 2. 成果物のPDCAサイクルの体制構築 3. キャパシティ管理の強化 いち早く触れるモノを作りフィードバックをもらい、軌道修正 可能なチームにするため、 「価値重視の計画」と「一心不乱の開発」のタイムボックスを 切り分けた
25. 25 1週間Sprintで計画・開発・FBを高速に繰り返し、洗練させる 構築における負債を返す期間を別に設け、とにかく作って FBを得ることに集中 • DataMartはスクラップ&ビルドを前提とし、負債を許容してでも触れるものを作ることに注力 • 開発メンバーが途中で直したいと感じたものはバックログに積み、負債を返すスプリントで回収 負債 負債回収期間
26. 26 素早く対応するべき 短期ニーズと 将来の投資としての 長期ニーズの間で 開発メンバーが板挟みに ... Data Platform作りでのしくじり Platformは長期目線のプロジェクト。短期目線のプロジェクトとの適切な距離感が重要 Before After アナリストをプロジェクト専任化し、 短期ニーズへの対応スピードを維持しつつ Data Platformにフィードバックする体制へ
27. 27 1. 負債覚悟でまずは具現化、改修可能な開発体制を築く ◦ Data Platformは育てるもの、という前提で初めから完璧を目指さない ◦ 計画・開発・改修のタイムボックスを明確に切り分ける 2. 柔軟な組織変更が一番効く ◦ フェーズ毎に他チームを巻き込む ▪ プロジェクト立上期から巻き込んでいたため、理解協力が得られやすかった ▪ BI→SREへの人事異動による協力関係の強化 ◦ 短期・長期目線を同時に実現するのはチーム力 ▪ どちらにも対応しつつシナジーを産むために、チーム内で役割を分担する ▪ Engineer→BIへの人事異動とプロジェクト専任化の実現もこのタイミングで ◦ 異動希望を伝えやすく叶えやすい、変化に強い組織があってこそ プロジェクト推進期にやってよかったこと 基盤づくりは組織力を痛感。普段からの横のつながりと立上期からの巻き込みが効いてくる
28. 28 28 今後
29. 29 3 Data Lakeの拡張と精度向上へ データ収集スコープのデリバリーの安定化とデリバリーするデータ自体の担保も視野に ✔ ✔ 3 4 ログ送信基盤の刷新 ログQAの強化 5
30. 30 命名にこだわる • データの解釈がもっともコミュニケーションコストを使い、リスクである • 用語の定義を徹底し、用語集の整備 ◦ 絶対に共通言語を作るべきもの ▪ セグメント ▪ 指標 ◦ これを決めておくことで、誰でも DMの構築活用ができるようになる データパイプラインの順番は飛ばしていい • まずは速さ重視でDMをDLから作る。 ◦ 共通化できるDWHに切り離していく ◦ 長期を見据え、パフォーマンスチューニングをする ◦ 依存関係の洗い出し方、検証の仕方のパターンナレッジを貯めておく Pairs Engageの立ち上げでやっていること
31. 31 Pairsエンゲージのアナリスト枠、採用開始しました Prodict/Marketing/Financeと指標決定〜エンジニアと協力して DLの強化・DWH/DMの構築をしています https://www.wantedly.com/projects/353221