【PIXIV MEETUP 2023】ピクシブのデータインフラと組織構造

PIXIV MEETUP 2023の発表資料です。

https://conference.pixiv.co.jp/2023/meetup#main-session

Transcript

1. pixiv Inc. ピクシブのデータ インフラと組織構造 @kashira
2. Profile kashira CTO室 プラットフォーム開発部 エンジニア データインフラの整備や、 データマネジメントを担当
3. このプレゼンで話すこと • ピクシブのデータインフラ • データ利活用の組織構造 • データインフラの将来の展望
4. データインフラ
5. プロダクト数が多い！ 2023年8月31日時点 https://www.pixiv.co.jp/service/ 約330名(正社員数)で16プロダクトを運営している 全員が開発する訳ではないが、単純計算で1プロダクトあたり約20人で運営
6. 全社共通のデータインフラ ドメイン コーポレート インフラ マーケティング データを1つのデータインフラに集約
7. BigQueryの利用状況 • データ量： 約7.8PiB • データアップロード量/日： 約6.9TiB/日 • テーブル数： 約180,000テーブル • ジョブ数/日： 約52,000件/日 ※2023年9月時点のデータ
8. Lookerの利用状況 • 月間利用者数(MAU): 248人 • アクティブ率(MAU/正社員数)： 74% • モデル数： 1522個 • ダッシュボード数： 1368個 • スケジュール数： 220個 ※2023年8月時点のデータ
9. 全社のデータインフラ
10. データインフラの全体像
11. 全社のデータ利活用を支えるデータインフラ DBデータ export 分析 load extract Transform ※機械学習などの特殊な要件は別で基盤で処理 ※全社的によく利用されるものをピックアップ
12. データ基盤チームの仕事
13. BigQueryの管理 • ストレージの管理・モニタリング • スロット(≒ 仮想CPU) 周りの管理・モニタリング • 機密情報周りの管理・モニタリング • 権限のポリシー設計 • コスト管理
14. Looker • コスト管理 • CI/CDの管理 • インスタンスとBigQueryの接続周りの管理
15. Airflow + Embulk(bq-batch) • Airflow管理 • テンプレートの作成 • 使い方のドキュメントを作成 • CI/CDの管理 • ライブラリの更新
16. データ基盤チームは データを管理していない
17. データ整備に 必要なインフラを管理
18. じゃあ、誰がデータを 管理しているの？
19. データ利活用の組織構造
20. データ基盤 ドメイン コーポレート インフラ マーケティング よくある組織構造 横断組織: データ分析チーム・データエンジニアリングチーム
21. データ基盤 ドメイン コーポレート インフラ マーケティング 中央のデータ組織がデータ利活用の主役 横断組織: データ分析・データエンジニアリングチーム 主役
22. データ組織が主役の場合 ドメインチーム(分析の依頼人) 分析チーム データ整備チーム 分析依頼 データ連携依頼 データ加工 データ分析 データ仕様 の問い合わせ
23. データ組織中心の体制は ピクシブには合わない
24. なぜか？
25. (再掲) 社員に対してプロダクト数が多い！ 2023年8月31日時点 https://www.pixiv.co.jp/service/ 約330名(正社員数)で16プロダクトを運営している = 1プロダクトあたり約20人で運営
26. プロダクトの数が多い • データ分析はドメイン知識が最重要 • 正社員が約330名に対して、プロダクトの数が16個 ◦ 必要とするドメイン知識も様々 ◦ イラスト、小説、EC、3D、BtoBなどなど • 中央の分析者のみで分析するのは難しい
27. もし、 ピクシブのデータ利活用の主役が 中央のデータ組織だったら
28. IFの世界 • 利用者は簡単に分析結果が得られる • → でもデータ分析には時間がかかる • -> 分析依頼が多くなると返答が遅くなる • → 利用者体験が悪化、解決にはデータ人材が必要 • -> でも人はそんなに取れない... • → 困った 😭
29. コミュニケーションがボトルネック ドメインチーム(分析の依頼人) 分析チーム データ整備チーム 分析依頼 データ連携依頼 データ加工 データ分析 データ仕様 の問い合わせ
30. じゃあ、どうしたのか？
31. ドメインチームを主役に
32. データ基盤 ドメイン コーポレート インフラ マーケティング ドメインチームがデータ利活用の主役 横断組織 主役
33. ピクシブではドメインチームが主役 ドメインチーム データ分析 データ加工 データ連携 データ生成 全部やります！！
34. ドメインチームが主役だと • 伝言ゲームが少なく、分析のための準備時間が短い ！！ • ボトルネックが無くスケールしやすい • データの民主化を目指す
35. ただし、課題も沢山ある...
36. 乗り越えるべき課題も沢山ある • データ利活用をするための認知負荷が高い • データ利活用の環境構築まで手が回らない • 作業者がデータの専門家ではない場合も多い • データガバナンスの統制が難しい
37. ドメインチームに丸投げ すればいいわけではない
38. ドメインチームをサポート する体制が重要になる
39. ドメインチームをサポートする体制が重要 ドメインチーム1 ドメインチーム2 ドメインチーム3 全社プラットフォーム ノウハウの共有・共通ルールの作成のための定例 データ利活用の推進・コンサル
40. ドメインチームの サポート体制
41. データ利活用の組織の登場人物 • データエンジニアリング互助会 • データ駆動推進室 • データ基盤チーム 3つのチーム・組織がドメインチームをサポート！
42. ピクシブのデータ組織構造
43. データエンジニアリング互助会の役割 • 社内でデータ利活用に携わる仲間と知見を交換・集約できる場 • データに興味がある人達で運営 ◦ 体制図上のチームではない • ベストプラクティスを共有し、分析環境を健全に保つ • 互いに助け合う文化の醸成・維持も担う https://inside.pixiv.blog/2022/07/28/130000
44. データエンジニアリング互助会の内容 • 9部署15人が良く参加するメンバー • 議題 ◦ 更新されたドキュメントの確認 ◦ 他部署や全社的なルールに関する討論 ◦ 現在進行中の案件の共有
45. • データ利活用をするための認知負荷が高い • データ利活用の環境構築まで手が回らない • 作業者がデータの専門家ではない場合も多い • データガバナンスの統制が難しい 乗り越えるべき課題 対策
46. データ駆動推進室の役割 • データドリブンな意思決定による業務の効率化を推進 • ドメインチームが自走してデータ利活用するためのサポート • データインフラを整備しても使われない • ドキュメント整備や社内教育活動が必要
47. • データ利活用をするための認知負荷が高い • データ利活用の環境構築まで手が回らない • 作業者がデータの専門家ではない場合も多い • データガバナンスの統制が難しい 乗り越えるべき課題 対策 対策
48. データ基盤チームの役割 • データ利活用を自己完結できるデータインフラを提供 • データ利活用のハードルをインフラ面から下げる • データマネジメント関連の作業も担当
49. 全社のデータ利活用を支えるデータインフラ DBデータ export 分析 load extract Transform ※機械学習などの特殊な要件は別で基盤で処理 ※全社的によく利用されるものをピックアップ
50. • データ利活用をするための認知負荷が高い • データ利活用の環境構築まで手が回らない • 作業者がデータの専門家ではない場合も多い • データガバナンスの統制が難しい 乗り越えるべき課題 対策 対策
51. 結果どうだったか？
52. ⭕ 上手くいった所 • データの繋ぎこみ、分析がチーム内で素早く完結する • スケールしやすい • エンジニアの分析への関心度が高い • コスト最適化しやすい • インフラのナレッジが溜まりやすい
53. △ まだ対策が必要な所 • データ品質管理が難しい • ナレッジの共有が難しい • ビジネス職にはハードルが高い • データ基盤チームがボトルネックになりやすい
54. データ品質管理が難しい • データ品質を保つのはそもそも大変 • + データ利活用する人がデータの専門家でないことが多い • 啓蒙もベストプラクティスも工数も足りない
55. データ品質管理への対策 • データオーナーを立てる • 全社的なデータ品質チェックの追加 • データリネージの導入 • (やりたい) データカタログのテンプレート整備 • (やりたい) dbtでのテストの強制
56. ナレッジ共有が難しい • データ利活用する人が各部に分散している • 大抵一人で作業を進めるケースが多い • データエンジニアリング互助会の取り組みでは不十分 • 特に基礎的な部分が足りていないケースが多い
57. ナレッジ共有への対策 • データ基盤チーム・データ駆動推進室が旗振り役となる • 読書会を様々な部署を巻き込んで実行する • 今は以下の２つの読書会を開催している ◦ Fundamentals of Data Engineering ◦ LEAN ANALYTICS
58. ビジネス職にはハードルが高い • エンジニアであればドキュメントを見るだけ、データ利 活用が出来るインフラを整備している • ビジネス職オンリーのチームは難しい • ビジネス職には必要なスキルの難易度が高い ◦ SQL、Git、Python
59. ハードルを下げるための対策 • (やりたい) トレーニングの強化 • (やりたい) データ連携を簡略化するツールの提供
60. データ基盤チームがボトルネック • データツールは進化が早い • ツール導入の遅れはデータ利活用の遅れに • でも全社共通インフラでは導入のコストが大きい
61. ボトルネックへの対策 • データ基盤チームの責務を無闇に増やさない • 共通ルール・共通処理を無闇に増やさない • 移行作業ではドメインチームにも手伝ってもらう
62. データ基盤チームとしての 将来の展望
63. データ基盤チームの将来の展望 • データ整備のサイクルタイムを短く • 全社のデータ品質・メタデータの強化 • データインフラをProduct化
64. データ整備のサイクルタイムを短く • データ整備にかける時間を短縮！ • dbtとFivetranを絶賛導入検討中 • 合わせてデータ品質の向上に着手 Modern Data Stackの導入
65. データ品質・メタデータの強化 • dbt移行に合わせてテスト・メタデータを強化 • データカタログのテンプレートポリシーの策定 • 全社的なデータ品質チェックの更なる追加
66. データインフラをProduct化 • 定常的にフィードバックを受け取れる仕組みの整備 • 社内に向けたマーケティング • KPIの策定 • コスト最適化 • 価値の可視化
67. まとめ
68. 全社共通のデータインフラ ドメイン コーポレート インフラ マーケティング データを1つのデータインフラに集約
69. データ基盤 ドメイン コーポレート インフラ マーケティング ドメインチームがデータ利活用の主役 横断組織 主役
70. ピクシブではドメインチームが主役 ドメインチーム データ分析 データ加工 データ連携 データ生成 全部やります！！
71. ドメインチームをサポートする体制が重要 ドメインチーム1 ドメインチーム2 ドメインチーム3 データ基盤チーム データエンジニアリング互助会 データ駆動推進室
72. ご清聴ありがとうございました