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
   

   View Slide

2. 2
   自己紹介
   インターンからエンジニアとして新卒入社、データ分析チームを立ち上げ Data Platformに従事
   エンジニア時代
   2011 インターン開始（現在最も古株のエンジニア）
   2013 PHPエンジニアとして新卒入社
   　　 受託開発・テクニカルディレクター
   2014 Pairsサーバーサイドエンジニア
   データ時代
   2015 Goフルスクラッチ データマイグレーション
   2016 Analyzeチーム設立
   2017 BIチーム設立
   2019 Data Platform 基盤構築従事
   ※プライベートモード会員のため検索には出てきません
   

   View Slide

3. 3
   会社・サービス紹介
   グローバル展開のオンラインデーティングアプリと新規事業の結婚コンシェルジュアプリ
   Pairs Pairs エンゲージ
   

   View Slide

4. 4
   Agenda
   1. エウレカにおけるData Platformの概要
   2. プロジェクト立上編
   3. プロジェクト推進編
   4. 今後やっていくこと
   具体例や失敗も交えながら話します。
   参考になれば幸いです。
   今日お話しすること
   と、今日は話さないけど、話せること（懇親会で話しましょう！）
   話せること
   ● Data Platform 運用編
   ● エウレカBIのチームビルディング
   ● Tableau導入のあれこれ
   ● Finance・Marketing・Productとの関わり
   ...etc
   

   View Slide

5. 5
   5
   eurekaにおける
   Data Platform
   

   View Slide

6. 6
   分析環境はGCPで構築
   データベースはBigQueryを、ETLはCloudComposerを採用
   

   View Slide

7. 7
   各データベースの定義と関係
   DataLakeの拡張・精度担保とDataMartの洗練によりDataWareHouseを強化する
   DataLake DataWareHouse DataMart
   データをほぼ
   そのまま保存
   しているDB
   分析用の下処理
   を施したDB
   ビジネス観点
   で整備したDB
   XXX Log
   Master Data
   Service Data
   Data Source
   Tableau
   Workbook
   拡張
   精度担保
   洗練
   強化
   

   View Slide

8. 8
   冪等性とは
   | ある操作を1回行っても複数回行っても結果が同じであることをいう概念
   存在意義
   マスキング済みのデータのコピーがあることで
   ● Productに影響を与えない分析環境を用意できる
   ● プライバシーリスクを犯さずにデータを扱える
   ● ロジックが介在しないのでデータの定義が変わらない (冪等性)
   Data Lakeの役割はDWHの可能性を拡げること
   Productに影響を与えずに冪等性を担保しながら、扱うデータの精度向上と対象範囲拡張を担う
   XXX Log
   Master Data
   Service Data
   

   View Slide

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
   ... ...
   

   View Slide

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
    最新設計（日付分割テーブル）
    テーブル設定
    

    View Slide

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
    最新設計（日付分割テーブル）
    テーブル設定
    

    View Slide

12. 12
    Data Martの役割は誰でも簡単に正しく使えること
    刻々と変化する状況やニーズに追従するには、誰もが触れる環境とセットで初めて価値が最大化する
    存在意義
    ● ビジネス観点の指標が取り込まれており、使うことで意思決定や事業理解に繋がる
    ● 取り扱う手段も提供されており、組織内のデータリテラシー向上を後押しする
    エウレカでは...
    ● 可視化ツールにTableauを導入し、全社員が触れる環境へ（ DataMartとセットで順次拡大中）
    ● 誰もが一目でわかる命名
    ○ 例）経過日数の表記ルール
    ■ 起点日を 0 とする / 期間は [N]to[M] / 一定数以上は [N]andMore で表記する
    

    View Slide

13. 13
    データ活用に責務をもつBIを中心に、Data Platfromチームを結成
    SREチームとの連携でパフォーマンスや精度を担保しながら活用を推進する
    組織構成
    ● サービス開発（Pairs/Engage）
    ● 横断（CTO）
    チーム構成 - BI
    ● 各Projctに専任アナリストを配置
    ● Data Platform専任を独立配置
    チーム構成 - Data Platform
    ● BI・SREから専任を配置
    

    View Slide

14. 14
    再利用
    既存のData Platform基盤を使い
    すぐに 使えるDWHの実現
    DWH運用におけるチーム内の役割
    各PRJ専任のBIメンバーが開拓した活用データを仕組み化し、新規事業に還元するエコシステムを実現
    データ活用の開拓
    集中と機動力を重視
    Adhoc分析歓迎
    仕組み化
    ニーズを汲み取り共通化して
    Data Platform構築へ
    

    View Slide

15. 15
    15
    プロジェクト立上編
    

    View Slide

16. 16
    プロジェクト立ち上げ期の 3 Step
    ステークホルダーを初めから巻き込むこと、計画段階でのスコープマネジメントが鍵を握っている
    1. データ活用の理想から全体像を描く
    ○ データの活用サイドと提供サイドの両軸と一緒に話す
    ■ いつまでにどうありたいか、どんなデータを使いたいかの夢を語る
    ○ 依存関係や現状とのGAPを可視化し、Roadmapに落とし込む
    2. 対象データのスコープを決める
    ○ プロジェクト実施に向け、説明とチェックのためのメトリクスを取る
    ■ 分析者がクエラーになりがちの状況なら、依頼の分類とリードタイムの計測など
    ○ 対象の優先度をステークホルダーと合意することで、腰を据えて開発に集中できる状況にする
    3. データパイプライン構築のスコープを決める
    ○ 価値を考えるにあたってがDL/DWH/DMの切り口が適しているが、構築段階では切り口を変える
    ○ SREとの会話で「収集/整形/活用」のデータパイプライン毎に切り分けられたのが大きかった
    

    View Slide

17. 17
    Step1. データ活用の理想から全体像を描く
    各所からデータ活用の理想を集め、 AsIsToBeを作ってギャップをRoadmapに落とし込む
    データ活用に対する理想を出し合い、
    依存関係と優先度のすり合わせを実施
    Product
    BI
    AI
    SRE
    AsIs (現状)
    ToBe (理想)
    全体設計に落としこみ、理想と現実のGAPを
    付箋でマッピング。依存関係と優先度を整理
    

    View Slide

18. 18
    Step2. 対象データのスコープを決める
    長期プロジェクトの新規実施に向けて、チームのリソース状況を可視化し、対象を選定
    ビジネスサイドとの合意 MTGの目的
    ● ビジネススピードの要所を落とさずに
    新規プロジェクトに集中するため
    説明に用いたメトリクス
    ● 分析業務・差し込みの発生件数
    ● 分析業務・差し込みの事業部別構成比
    ● 事業部別分析業務のリードタイム
    決定事項
    ● DWH構築対象の優先度決定
    ● 事業部毎の相談窓口・基準の見直し
    発生件数
    事業部別
    構成比
    リードタイム
    

    View Slide

19. 19
    リードタイムとは、発注から納品までに要する時間
    BIでは業務をチケット管理し、 Cumulative Flow Diagramで可視化可能に
    

    View Slide

20. 20
    リードタイムとは、発注から納品までに要する時間
    チケット作成からのステータス変化を可視化することで、事業部毎の課題を整理できる
    事業部 A 事業部 B
    定期的に作成が急増し、 TODO状態が長い
    → 捌き切れず、機会損失になっている可能性
    作成は安定しているが、 Review状態が長い
    → 不要なタスクが発生している可能性
    

    View Slide

21. 21
    Step3. データパイプライン構築のスコープを決める
    構築段階ではデータパイプライン毎にスコープを分ける。 SREはデリバリーのプロとして参画。
    1
    2
    3
    4
    

    View Slide

22. 22
    22
    プロジェクト推進編
    

    View Slide

23. 23
    チーム構成はスコープに合わせて変化させる
    他チームを巻き込むことでニーズを引き出し、推進力とフィードバックが得られる
    1. 初期の基盤構築段階でSREを巻き込む
    現実的なものを作れているか？
    → 長期の運用を見据えたフィードバック
    2. 活用基盤構築で利用者(PM)を巻き込む
    使えるものを作れているか？
    → 成果物(DataMart)へのフィードバック
    3. 必要に応じた人事異動
    データ活用を描いた低レイヤー知識が必要
    → 本人の希望もありデータマネジメントに責務をも
    つSREが誕生し、BIの架け橋へ
    Next Scope
    

    View Slide

24. 24
    Scope2-1. 活用基盤の構築
    いち早く基盤を構築し、試行錯誤する体制を整えるためにスクラムを採用
    スクラムを選んだ理由
    複雑で変化の激しい問題に対応するためのフレームワー
    クであり、可能な限り価値の高いプロダクトを生産的かつ
    創造的に届けるためのものである
    1. 利用者の価値起点での設計を常に意識
    2. 成果物のPDCAサイクルの体制構築
    3. キャパシティ管理の強化
    いち早く触れるモノを作りフィードバックをもらい、軌道修正
    可能なチームにするため、
    「価値重視の計画」と「一心不乱の開発」のタイムボックスを
    切り分けた
    

    View Slide

25. 25
    1週間Sprintで計画・開発・FBを高速に繰り返し、洗練させる
    構築における負債を返す期間を別に設け、とにかく作って FBを得ることに集中
    ● DataMartはスクラップ&ビルドを前提とし、負債を許容してでも触れるものを作ることに注力
    ● 開発メンバーが途中で直したいと感じたものはバックログに積み、負債を返すスプリントで回収
    負債
    負債回収期間
    

    View Slide

26. 26
    素早く対応するべき 短期ニーズと
    将来の投資としての 長期ニーズの間で
    開発メンバーが板挟みに ...
    Data Platform作りでのしくじり
    Platformは長期目線のプロジェクト。短期目線のプロジェクトとの適切な距離感が重要
    Before After
    アナリストをプロジェクト専任化し、
    短期ニーズへの対応スピードを維持しつつ
    Data Platformにフィードバックする体制へ
    

    View Slide

27. 27
    1. 負債覚悟でまずは具現化、改修可能な開発体制を築く
    ○ Data Platformは育てるもの、という前提で初めから完璧を目指さない
    ○ 計画・開発・改修のタイムボックスを明確に切り分ける
    2. 柔軟な組織変更が一番効く
    ○ フェーズ毎に他チームを巻き込む
    ■ プロジェクト立上期から巻き込んでいたため、理解協力が得られやすかった
    ■ BI→SREへの人事異動による協力関係の強化
    ○ 短期・長期目線を同時に実現するのはチーム力
    ■ どちらにも対応しつつシナジーを産むために、チーム内で役割を分担する
    ■ Engineer→BIへの人事異動とプロジェクト専任化の実現もこのタイミングで
    ○ 異動希望を伝えやすく叶えやすい、変化に強い組織があってこそ
    プロジェクト推進期にやってよかったこと
    基盤づくりは組織力を痛感。普段からの横のつながりと立上期からの巻き込みが効いてくる
    

    View Slide

28. 28
    28
    今後
    

    View Slide

29. 29
    3
    Data Lakeの拡張と精度向上へ
    データ収集スコープのデリバリーの安定化とデリバリーするデータ自体の担保も視野に
    ✔
    ✔
    3
    4
    ログ送信基盤の刷新
    ログQAの強化
    5
    

    View Slide

30. 30
    命名にこだわる
    ● データの解釈がもっともコミュニケーションコストを使い、リスクである
    ● 用語の定義を徹底し、用語集の整備
    ○ 絶対に共通言語を作るべきもの
    ■ セグメント
    ■ 指標
    ○ これを決めておくことで、誰でも DMの構築活用ができるようになる
    データパイプラインの順番は飛ばしていい
    ● まずは速さ重視でDMをDLから作る。
    ○ 共通化できるDWHに切り離していく
    ○ 長期を見据え、パフォーマンスチューニングをする
    ○ 依存関係の洗い出し方、検証の仕方のパターンナレッジを貯めておく
    Pairs Engageの立ち上げでやっていること
    

    View Slide

31. 31
    Pairsエンゲージのアナリスト枠、採用開始しました
    Prodict/Marketing/Financeと指標決定〜エンジニアと協力して DLの強化・DWH/DMの構築をしています
    https://www.wantedly.com/projects/353221
    

    View Slide

32. View Slide