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

63bfdf4cee5223385e33d320301492d2?s=47 tama
September 05, 2019

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

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

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

63bfdf4cee5223385e33d320301492d2?s=128

tama

September 05, 2019
Tweet

Transcript

  1. 2.

    2 自己紹介 インターンからエンジニアとして新卒入社、データ分析チームを立ち上げ Data Platformに従事 エンジニア時代 2011 インターン開始(現在最も古株のエンジニア) 2013 PHPエンジニアとして新卒入社

       受託開発・テクニカルディレクター 2014 Pairsサーバーサイドエンジニア データ時代 2015 Goフルスクラッチ データマイグレーション 2016 Analyzeチーム設立 2017 BIチーム設立 2019 Data Platform 基盤構築従事 ※プライベートモード会員のため検索には出てきません
  2. 4.

    4 Agenda 1. エウレカにおけるData Platformの概要 2. プロジェクト立上編 3. プロジェクト推進編 4.

    今後やっていくこと 具体例や失敗も交えながら話します。 参考になれば幸いです。 今日お話しすること と、今日は話さないけど、話せること(懇親会で話しましょう!) 話せること • Data Platform 運用編 • エウレカBIのチームビルディング • Tableau導入のあれこれ • Finance・Marketing・Productとの関わり ...etc
  3. 8.

    8 冪等性とは | ある操作を1回行っても複数回行っても結果が同じであることをいう概念 存在意義 マスキング済みのデータのコピーがあることで • Productに影響を与えない分析環境を用意できる • プライバシーリスクを犯さずにデータを扱える

    • ロジックが介在しないのでデータの定義が変わらない (冪等性) Data Lakeの役割はDWHの可能性を拡げること Productに影響を与えずに冪等性を担保しながら、扱うデータの精度向上と対象範囲拡張を担う XXX Log Master Data Service Data
  4. 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 ... ...
  5. 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 最新設計(日付分割テーブル) テーブル設定
  6. 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 最新設計(日付分割テーブル) テーブル設定
  7. 16.

    16 プロジェクト立ち上げ期の 3 Step ステークホルダーを初めから巻き込むこと、計画段階でのスコープマネジメントが鍵を握っている 1. データ活用の理想から全体像を描く ◦ データの活用サイドと提供サイドの両軸と一緒に話す ▪

    いつまでにどうありたいか、どんなデータを使いたいかの夢を語る ◦ 依存関係や現状とのGAPを可視化し、Roadmapに落とし込む 2. 対象データのスコープを決める ◦ プロジェクト実施に向け、説明とチェックのためのメトリクスを取る ▪ 分析者がクエラーになりがちの状況なら、依頼の分類とリードタイムの計測など ◦ 対象の優先度をステークホルダーと合意することで、腰を据えて開発に集中できる状況にする 3. データパイプライン構築のスコープを決める ◦ 価値を考えるにあたってがDL/DWH/DMの切り口が適しているが、構築段階では切り口を変える ◦ SREとの会話で「収集/整形/活用」のデータパイプライン毎に切り分けられたのが大きかった
  8. 18.

    18 Step2. 対象データのスコープを決める 長期プロジェクトの新規実施に向けて、チームのリソース状況を可視化し、対象を選定 ビジネスサイドとの合意 MTGの目的 • ビジネススピードの要所を落とさずに 新規プロジェクトに集中するため 説明に用いたメトリクス

    • 分析業務・差し込みの発生件数 • 分析業務・差し込みの事業部別構成比 • 事業部別分析業務のリードタイム 決定事項 • DWH構築対象の優先度決定 • 事業部毎の相談窓口・基準の見直し 発生件数 事業部別 構成比 リードタイム
  9. 23.

    23 チーム構成はスコープに合わせて変化させる 他チームを巻き込むことでニーズを引き出し、推進力とフィードバックが得られる 1. 初期の基盤構築段階でSREを巻き込む 現実的なものを作れているか? → 長期の運用を見据えたフィードバック 2. 活用基盤構築で利用者(PM)を巻き込む

    使えるものを作れているか? → 成果物(DataMart)へのフィードバック 3. 必要に応じた人事異動 データ活用を描いた低レイヤー知識が必要 → 本人の希望もありデータマネジメントに責務をも つSREが誕生し、BIの架け橋へ Next Scope
  10. 24.

    24 Scope2-1. 活用基盤の構築 いち早く基盤を構築し、試行錯誤する体制を整えるためにスクラムを採用 スクラムを選んだ理由 複雑で変化の激しい問題に対応するためのフレームワー クであり、可能な限り価値の高いプロダクトを生産的かつ 創造的に届けるためのものである 1. 利用者の価値起点での設計を常に意識

    2. 成果物のPDCAサイクルの体制構築 3. キャパシティ管理の強化 いち早く触れるモノを作りフィードバックをもらい、軌道修正 可能なチームにするため、 「価値重視の計画」と「一心不乱の開発」のタイムボックスを 切り分けた
  11. 27.

    27 1. 負債覚悟でまずは具現化、改修可能な開発体制を築く ◦ Data Platformは育てるもの、という前提で初めから完璧を目指さない ◦ 計画・開発・改修のタイムボックスを明確に切り分ける 2. 柔軟な組織変更が一番効く

    ◦ フェーズ毎に他チームを巻き込む ▪ プロジェクト立上期から巻き込んでいたため、理解協力が得られやすかった ▪ BI→SREへの人事異動による協力関係の強化 ◦ 短期・長期目線を同時に実現するのはチーム力 ▪ どちらにも対応しつつシナジーを産むために、チーム内で役割を分担する ▪ Engineer→BIへの人事異動とプロジェクト専任化の実現もこのタイミングで ◦ 異動希望を伝えやすく叶えやすい、変化に強い組織があってこそ プロジェクト推進期にやってよかったこと 基盤づくりは組織力を痛感。普段からの横のつながりと立上期からの巻き込みが効いてくる
  12. 30.

    30 命名にこだわる • データの解釈がもっともコミュニケーションコストを使い、リスクである • 用語の定義を徹底し、用語集の整備 ◦ 絶対に共通言語を作るべきもの ▪ セグメント

    ▪ 指標 ◦ これを決めておくことで、誰でも DMの構築活用ができるようになる データパイプラインの順番は飛ばしていい • まずは速さ重視でDMをDLから作る。 ◦ 共通化できるDWHに切り離していく ◦ 長期を見据え、パフォーマンスチューニングをする ◦ 依存関係の洗い出し方、検証の仕方のパターンナレッジを貯めておく Pairs Engageの立ち上げでやっていること
  13. 32.

    32