「PayPayのデータ分析基盤を支える技術」参加レポート

久しぶりにオンライン勉強会にリアルタイム参加しました。

夕方から夜は家族との食事などに時間を使っているので勉強会に参加する機会が減ってしまいました。アーカイブ動画が公開されたら後日見る程度になっていました。今回の勉強会は業務で取り組んでいるデータ分析基盤にテーマにしていて、内容にとても興味があったので参加しました。

PayPayデータ基盤チーム立ち上げ・チームの役割や運営について

2018年10月にPayPayローンチ、2020年10月にデータマネジメントチームが立ち上がる

課題

DWH周り
- PayPayアプリのデータをBigQueryに数時間おきに同期
- SQLを書ける人がスケジュールドクエリを組み合わせてデータマートを作って、作った人がいつの間にかやめて保守を引き取ることに
GCP周り、権限まわり
- 一つのプロジェクトで全ユーザーが利用している

設立初期にやったこと

全社ヒアリング
- どう使っているをヒアリングしまくった。15チームぐらい
DM部の認知度向上
- PayPayの社内報に出る。効果があったと思う
- BigQueryのクエリがコケたユーザーに直接DMしてフォローついでに認知してもらう。効果大
- Slackでの周知は効果が低い
採用
- カスタム開発の知識があってデータ周りをやりたい人を採用

チーム運営（チーム外とのコミュニケーション）

MTGは空き時間に自由に招待可能な社風
Slackチャンネル
- #paypay-bigquery：BigQuery使っている人を招待。数百人
- #bq-light-question：クエリの書き方などを質問できるチャンネル。数十人
Google Form
- 業務部門からの分析依頼フォーム。全体に公開していない

チームマネジメント

明確や期限をもったタスクがそれほど多くない
同時並行で関連のない大量のプロジェクトが進む。すべて管理するのが難しい
差し込みが非常に多い
課題を洗い出し、ロードマップを策定、月一で見直して認識合わせ

感想

質疑応答でもありましたが、PayPayローンチ時点ですでにデータ活用する企業文化はできていて、BigQueryでのデータ分析・利用は活発にされていたようです。しかし、活用していくうちにデータガバナンス周りで課題が出てきたことからデータマネジメントチームが発足され、足回りを整えたりより活発に利用されるようにSlackなどでコミュニケーションを取っていたとのことです。SQLに不慣れな方向けにクエリの書き方を質問できるチャンネルがあるのが良いと思いました。

PayPayのデータ活用を支えるパイプライン環境や全社共通テーブルの整備について

データソース⇒全社マート（リプレイス中）⇒部署作成マート

1年で取り組んだ課題 - BQ利用の改善

フォルダ・プロジェクトの構成を設計。確実に処理したいクエリは別プロジェクトに移行
BigQuery Reservationsを購入。Slots消費のWindowを可視化。コストの大きいクエリを特定。作成者に同意をとってクエリを改善
- パーティションキーの質
- データスキュー（偏り）の解決
- クエリ実行頻度の調整、ビューのテーブル化
- マテリアライズドビューの停止 or 専用プロジェクトでの作成
数ヶ月経つと元に戻ってしまうため、共通の全社マートを利用すべきなので作成して利用を促していく

1年で取り組んだ課題 - 全社マートの再設計

何十人も使っているけど管理者がいないテーブル
既存のテーブル構造を維持しつつ、自分たちが運用しやすい形に前段に中間tableを作成
スケジュールクエリではなく、Airflow上にパイプラインを作成して依存を管理
階層構造
- 1層目：データソースとの1:1
- 2層目：スタースキーマ風。ドメイン知識にそって整理
- 3層目：全社マート。集計
現状
- 1層目はリリース済。一部で利用開始
- 2層目、3層目は10月中にリリース予定
- 要望などを受け付けるフォームの整備
データカタログの整備
- 元々はData Catalogや自作リネージツールを利用
- より便利に実現するツールを検討⇒ dbt を検証
  - テンプレート化されたSQLやあらかじめ設定したconfigをもとに依存関係通りにクエリが実行される
  - データカタログの自動生成も可能（HTML、JS）
  - 社内向けにアクセス制限して公開できるか検証中
チーム体制の改善
- DWHチーム一つで動いていたが専門性が高まってきたので、チームを分割
- データアーキテクト
  - データを詳しく知っている人。SQLをガリガリ書ける人
  - BIチームやデータアナリストとの連携を深める
- データパイプライン
  - パイプライン環境の整備。エンジニアリング寄り
  - GCPチームやDM部との連携を深める

感想

データウェアハウス周りについて、どのように整備していったのかを説明されていました。個人的に最も聞きたかったセッションですが、時間の都合上で深掘りされないままになってしまい、もっと具体的に聞きたかったです。

PayPayのLooker立ち上げとユーザ展開の課題と解決策について

PayPayでのBI利用状況

設立当初はGoogle Workspaceが使えたためデータポータルが使われていた
3年で数百～数千のダッシュボードが作成された
データポータルの課題
- 誰がどんなダッシュボード・データソースを作っているか把握できず、ガバナンスが取れない
- BigQueryの権限がないと社内データが利用できない。DB不慣れのアナリストにとって不便
- パフォーマンスが不安定
- データポータルはGoogle Workspaceのサポート対象ではない
  - ダッシュボード作成者が退職されてダッシュボードが消えてしまったときに問い合わせしても対応してもらえなかった

Looker導入の過程

データの民主化とガバナンスの強化を期待
- サービスアカウントでBigQueryに接続するコネクタを構成してエンジニアとアナリスト両方に使いやすい環境構築
- LookMLでデータガバナンスの確保とサイロ化の解決
  - バラバラになっているデータの定義を一箇所で集約
- 監査ログと配信制御でセキュリティ強化
- エンタープライズサポート
導入時の課題
- データポータルの利用が根付いていてBigQueryの中でパイプラインが構築されているケースがあった
- 今までポチポチできていたのをLookMLによるスクリプトに変わるので抵抗感ある人がいた
- データポータルでできた可視化がLookerで実現できないケースがあった
- UI/UXへの抵抗感
  - Tableauライクっぽくないので抵抗感がある人がいた
  - 手持ちのCSVをすぐ入れたいのにできない
データポータルとLookerの使い分けを明確にした
- ライトユーザー、アドホックな分析 ⇒ データポータル
- ダッシュボード ⇒ Looker
導入の過程で取り組んだこと
- データスチュワードを各部署で育成。自ら必要なダッシュボードを作成することができるようにした
- 全社で利用するデータを各部署に提供 ⇒ LookerのHub&Spoke構造
- Lookerに慣れていないユーザーに対してSlackでサポート
導入したことのメリット
- LookMLによるデータ定義の一元化
- データの利活用でLookerだけで完結できる
- 派生テーブルによる不要な中間テーブルを減らせた
- 監査ログによるセキュリティ強化、データ利用率の分析でデータの活用を推進
- メールやSlackなどAPIによる配信を制御してセキュリティ強化

今後の取組み

社内共通のExplorer構築：Lookerをどこから見ればいいの？という疑問への対策
社内トレーニング開発
データポータルのLooker移行支援
誰もメンテされなくなったデータポータルダッシュボードを引き取ってLookerに移行

感想

社内でLooker検討が始まろうとしていて今後の参考になりました。データポータルと比較してLookerだとビジュアライズで表現が難しいものがあるのは意外でした。

Q&A

Q：Lookerは費用が高いと思うが、どのように社内承認を取ったのか
- PayPayは立ち上がって4年でグロース重視というフェーズだった
- エンタープライズ向けBIとしてTableauなどと比較してあまり変わらなかった
Q：BIツールはどのように使い分けているか
- データポータル：個人用、アドホック、可視化にこだわる
- Looker：可視化にこだわらない、安定配信したい場合
- データポータルが圧倒的に多いので今後は経営陣へのレポーティングでLookerに移行していきたい
Q：BQの使い方を社内でヒアリングしたときに使われたスプレッドシートでは、具体的にどのような項目があるか
- クエリ開発にあてている人数と工数
- SLO
- 部署内でのチーム編成
- BigQuery利用上の課題
- 中級者向けのカリキュラムがあると嬉しいとの声
- BigQuery関連の社内ドキュメント（Wiki）はあるか？
Q：データマートは社内だれでも作れるものか？
- 全社向けマートは誰でも作れる
- Data Fusionで作れる
Q：「スタースキーマ」でなく「スタースキーマ風」にした背景は？
- きちんとしたスタースキーマにできなかったため
- スタースキーマにしようという意識より自然にそうなった
Q：Google Data Catalogや自作リネージツールでは不十分だと思った理由や背景は？
- 登録が大変。BigQueryのDescriptionから編集する必要がある
- Webコンソール上で誰でも編集できるよりかは、ソースコード上で誰かに承認をとって登録できる形にした
- 検索はData Catalogで引き続きできる
- 自作リネージツールは全社マート移行するときに依存関係を調べるときに使っていた。ローカルで実行していて社内公開しているわけではなかった
Q：利用者がデータカタログに記入・修正したいケースがあるかと思うが、dbtを利用する上でどのようなフローで対応されているか？
- 利用者への周知はしておらず、フローはできていない
- 利用者が勝手に修正されると困るのでGoogle Formなどで受け付ける形にする予定
Q：Lookerのトレーニング行う上でユーザーの最も重要視しているポイントは？
- ハンズオン形式にしている
Q：最初の発表にあったGoogle Formでの分析依頼について、スライドに「分析まで行かないものがほとんど」と書いてあったと思います。これについてもう少し詳しく教えていただけないでしょうか？（なぜ？が気になっています）
- 普通の問い合わせレベルが多かった
Q：BigQueryの連携は1日1回の日次JOBではなく、当日の中で数回更新されているというお話ですが、シンプルにAirflow / ComposerでJOBを実行しているということでしょうか？当日中の処理を行う上で懸念などはありますでしょうか？
- 前日分のデータを届けるようにSLOを決めている

さいごに

PayPayのデータ分析基盤やデータマネジメントの取り組みについて概要を知ることができて収穫があって参加して良かったです。改善要望があるとしたら1セッションあたり15分と短いので、2時間の枠にしてもう少し深掘りした内容を話してもらえるともっと満足度が高かったです。採用目的であるので、もっと詳しく聞きたい人はカジュアル面談へということなんだと思いますが。

本日も乙

ただの自己満足な備忘録。