安定と刺激の間で生きたい。

データ分析の日常を淡々と描いた物です。

本日開催された「Data Platform Meetup#1」に参加しました。

data-platform-meetup.connpass.com

全体を通した所感

  • データ基盤ではなく、データプラットフォーム(Data Platform = DP)という表現かっこいいので、使っていこう。
  • DPアーキテクトの基本構成は、Google BigQueryと、Cloud Composer(Airflow)。
  • DPテーブルの基本構成は、Data Lake(DL), Data WareHouse(DWH), DataMart(DM)の3層構造。
  • DPを使いこなす上では、人の巻き込み方、組織体制が重要。
    • 利用状況モニタリング、依頼チケットのリードタイム計測など、施策PDCAの考え方も使える。

挨拶

  • 平野さん
    • データ分析チームのマネジャー
    • データアナリスト、データ周りすべてを担当

趣旨説明

  • 取り扱いテーマ

    • DWHの設計〜活用(データレイク・データウェアハウス・データマート)
    • データ活用に関わる組織・仕組みの設計(データアナリストとデータエンジニアの役割分担など)
    • BIツールの設計・利用方法
    • 分析に関する品質担保(ダッシュボードの品質・冪等性の担保など)
    • 運用を見据えた管理・統制(権限設定・マスキングなど)
  • 背景

    • Rettyのデータ分析チームは2年目。
      • 現在は、データ活用の拡大のために、DMの開発など。
    • 近年のデータ系勉強会については、組織やアーキテクト、機械学習的な話が多く、DWHなどのData Platformの話題が少ないという課題感があった。
    • そのため、ノウハウが社内に閉じていて、もっと議論をしたいということで、エウレカさんの鉄元さんと話をして、共感を得て、開催に至った。

所感

  • 初めてのData Platform系MeetUpじゃないか?ということで、データアナリストやデータエンジニアにとって非常に貴重会であったと思う。

竹野 峻輔さん:「カルチャーとエンジニアリングを繋ぐデータプラットフォーム」

speakerdeck.com

内容

  • データにまつわる課題

    • データが汚すぎ、パイプライン、ワークフローが長すぎ。
  • kagglerの時間対応割合のアンケート

    • 時間の50%をクレンジングなどデータの準備だけに時間を使っている。
  • Retty

    • 4000万人が利用。
    • 2017年にデータ分析チームが発足。
    • 2017/11時点で月4000 -> 2019/08で月46000にクエリの数が増大。
  • ポイント

    • 大事にしていることは、価値のデリバリ
    • データが生む価値とは?データだけでは価値をうまない。データは(共通認識のための)言語である。そして、RettyではUser Happyを目指す。
    • Platformを作る上で、カルチャーとエンジニアのギャップをうまく繋ぐのが大事。
    • Platfromのスコープは、カルチャーとエンジニアをサイエンス、デザインでつなぐ。
    • 事例
      • 安易な(職務スコープの)サイロ化は良くない。
      • データ基盤エンジニアが全てやると、データアナリストにドメイン知識などの知見が貯まらない。データ基盤は分析者にとってのプロダクトとする。
      • ドメインを持つ人が最前線で開発するのが重要。

質問

  • Q: DWHを分析者のスコープだと思うが、データエンジニアのスコープはどこまでか?

    • A: 自動化ツール、例えばテストを簡単に書けるようにする。そのようなツールを提供して分析者に手離れしてもらう。
  • Q:どういうデータを揃えておくか?

    • A: どういうキーワードで流入してくるか?、サイト内アクセスなど。データ分析者が欲しいというものは、基本全部とる。

所感

  • 「データ基盤エンジニアが全てやると、データアナリストにドメイン知識などの知見が貯まらない。データ基盤は分析者にとってのプロダクトとする。」
    • DPについては、データアナリストをスクラムのPOやPMに据えるのは正しいと思う。

yuzutas0さん:「データレイク構築後の四方山話」

speakerdeck.com

内容

  • ターゲット

    • データは入れたけど、データ基盤をどう進化させていけば良いか困っているデータアナリスト。
  • コメント

    • データを疎通したデータアナリストは、素晴らしい!
    • イシュー駆動して欲しい。
  • 質問に答えていくスタイル

    • 中間テーブルを作るとき
      • キー情報をそぎ落とすと。。。元の意味が知りたい場合に大変。(idが違うのに同じ属性値など)
      • データ利用者と中間テーブル利用率が重要。
      • アナリストが作ったが、使われないテーブルが多い。
        • 利用者のPVとUUで可視化すると良い。パレート図で可視化するSQLを資料に公開!
    • 権限管理
      • Read Onlyの本番用スキーマと自由に加工可能なSandboxスキーマを提供。
      • クラウドサービスに権限管理のTipsがある(GCP)。
      • 権限はTerraformで管理すると良い。サンプルも資料に公開!
    • 処理の遅延
      • 途中で継ぎ足されたテーブルなどで処理が遅くなっていく
    • データ未更新、データが落ちている
      • PythonSQLをラップしてunittestでチェック実行。
      • メタテーブルで更新の正常監視。
    • 不整合データをどこで吸収するか
      • ETLでクレンジングだけでは足りない。勇気を持って、開発担当者などにFBを返そう。
    • 擬似的に履歴データを作りたい
      • 日次バッチでスナップショットを取る、できれば、プロダクト側で履歴を持つのが良い。
      • 法令的に残っていることが必要な場合が多い。
    • 中間テーブルの作成はKPIから効果をブレイクしていく。

質問

  • Q: 履歴を持つデータの設計のベタープラクティス
  • Q: DWH/DMなどの過去訴求が、大変かつユーザー影響があるけど、どうやるのが良いか?
    • A: A/B面作戦で、まずは_tempを作り、データ移行した後に切り替えるのが良い。

所感

  • 明日から使える、DPトリビアだらけ。ひたすら感謝。
  • DPの利用状況モニタリング、クエリのテスト方法やメタテーブルによる欠損の監視など、もう一度読み込みたい。
    • 参考文献も豊富なので、隙がない。

鉄本 環さん:「DataPlatform構築プロジェクト推進の事例と学び」

speakerdeck.com

内容

  • エウレカアーキテクチャ

    • BigQueryとComposer。
    • Data Lakeの役割はDWHの可能性を拡げること。
    • DataWareHouseが要。前処理工程を減らす。時差計算、非正規化など。
      • 日付分割パーティション
      • TimeStampの罠、二重に時差を考慮してしまう。 DATETIME型に直しておくと良い。
    • DMは、誰でも触れる環境。
      • 誰でもわかる命名が大事。
  • エウレカの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構築でスクラムを取り組んでいるのはユニークではないだろうか。(たぶんその方が進めやすい気もする。)

石田 祥英さん:「大規模サービス開発における分析用データの必要要件」

  • ガチ広告系データエンジニアからビジネス系データアナリストになっためずらしい経歴の方。

speakerdeck.com

内容

  • 大規模サービスデータの三重苦

    • 広い(多い)、データ量が数十TBなのでBQでも処理が重い、メルカリのJPだけでも1000人体制なので意思疎通が大変。
  • データアナリティクスが活躍する3つの領域

    • お客様の行動・事業進捗の把握、UX計画・効果予測、効果振り返り。
  • メルカリの分析環境

    • 物理
      • 基本生データ全部がBQにある(恵まれている環境だ。。。)
    • 組織
      • 職能(Data Analyst)とプロジェクト(売上、出品者、横断的なUX改善)の掛け算。
    • 思想
      • どの施策を選択するか?、どのお客さんをターゲットにすべきか?などの目的先行でのデータを使った意思決定で進める。
  • 横断モニタリングPRJ

    • 全体をモニタリングする責任者がいなかった。ので、作った。
    • イベントレベルまで詳細なモニタリングダッシュボードを作成。
    • 効果としては、追えていなかった数字が見え、新たな問題を築けた。
  • 誰でも中間テーブル

    • SQLを書けば、アナリストが誰でも中間テーブルをできるようになった。
    • オンボーディング資料を作って、ハンズオンを実施。
    • SQLとDAGスクリプトを書いてPushすれば反映される仕組み。CircleCI経由で。
  • ログ漏れ

    • テスト設計、ログレビューを必須とする。
    • BIチーム内で仮説や検証をダブルチェック。
    • 効果検証フォーマットでチェック。(走る施策多くてレビューが大変そう。。。)
      • ABテストでわからないことを明示しておくのが良い。
  • 今後やりたいこと

    • 元テーブルと、中間テーブルの数値チェック。
    • 体系的なデータマートの整える。など

質問

  • Q: モニタリングは指標が少ない、絞る方が良いのではないか?

    • A: 異常検知や全体的なモニタリングは、カバレッジが重要と思ったので、多い方が良いと思う。
  • Q: 定義したKPIをどう運用していくか?データマート作成が大変そう。

    • A: 常に更新していく方針。更新が多いので、データマートは作成していない。変更があればクエリだけ更新している。Lookerで対応している。

所感

  • 横断モニタリングに関して、全部を見てバランスよく判断するのは、難しいと思う。この取り組みついては、今後も注視したいと感じた。
  • 施策の効果測定のガバナンスを利かす上でも、テスト設計やログ設計や仮説、検証を、レビューする体制を整えたのは、素晴らしい。
    • しかし、同時にBIチームがボトルネックになって、スケールしなくなる気もするけど、どううまく対応しているのだろうか、気になる。