アーカイブ動画

データアーキテクトチームの取り組みとは

PayPay株式会社　システム本部
Data Management部　石井 俊一氏

最初に登壇したのは、Data Management（データマネジメント）部の石井俊一氏。石井氏はData Architect（データアーキテクト）チームに所属。新卒で入社したISPでは、Hadoopを使ったビッグデータシステムやIoT向けシステムのSIに従事。次にECサービス企業で、データエンジニアやデータエンジニアリングマネジャーとして業務に従事していた。

その後ベンチャー企業を経て、PayPayに入社。データエンジニアリングを10年経験している。現在はデータプラットフォームアーキテクトとして、データ基盤の設計やデータアーキテクチャの検討に携わっている。

「DataPMチームは、データシステムを実装する上での上流工程を担当しており、プロジェクトマネジメントやデータスチュワード的な役割です。具体的にはビジネスサイドから要件をヒアリングして、ビジネスのデータユースケースを調整します」（石井氏）

石井氏が所属しているData Architect チームは、ビジネスやシステムの仕組みを設計するチーム。主に業務フローや業務プロセスを中心に設計している。

Data Utilizationチームは、ビジネスサイドのさまざまなツールのデータ連携や収集したデータを活用するためのデータマートを開発する。

「Data Utilizationチームは、社内のさまざまな人たちからデータ関連の依頼が来るので、PMチームの担当者と一緒にシステム実装しています」（石井氏）

DaaSチームは、プロダクトDBのトランザクションのパイプラインを開発。PayPayのプロダクトは100以上のマイクロサービスで構成されており、そこからBigQueryに連携するようなシステムを開発しているチームである。

PayPayのデータユースケースは、プロダクトやマーケティング、経営企画などの部署が使っている。社内ではChatGPTをバックエンドにSlackで質問ができるツールや、マシンラーニング、AIのようなユースケースも出てきているという。

データ利用ユーザー数は数千ユーザー、参照するGCPプロジェクト数は数百件、データサイズはデータレイクを含み十数ペタバイトという規模感となっている。データの利用状況は図の通り。

「生データを使いやすい様に変換したデータマートやPayPayのプロダクト自体から収集したプロダクトデータ、ユーザーが作ったデータなどで3分の2を占めている状況です」（石井氏）

昨今、使われている技術スタックは、図の様にモダンデータスタックで構成されている。特徴的なのは、「Looker、Looker Studio、QuickSight、Tableau Cloudと、4種類のBIツールを使っていること」と石井氏は言う。効率的に業務を遂行するためだという。

また、石井氏はデータ基盤のアーキテクチャについても紹介。PayPayではプロダクトシステムをAWS上で展開しており、そこで生成されるデータとビジネスで生成されるデータを、すべてGCP上のBigQueryに集約しBQ上でデータ基盤を作っていると語った。

プロダクトのデータはDaaSチーム、ビジネスデータはData Utilizationチームが担当。これらを集めたデータの活用を促進しているのが、データPMチームである。

データ基盤が抱える課題と解決のための施策

データ基盤の課題は3つある。1つ目は、マルチクラウドなデータ環境における課題だ。AWSとGCPで環境が分かれているので、プロダクトがあるAWS側で生成されたデータをGCP側にあるBQに連携しなければならないのだが、データ量が大きいので差分更新で連携しても、時間がかかってしまう。

更新頻度も上げたいが、「技術的な課題がある」と石井氏は言う。AWS環境からBQを参照しようとすると、ネットワークのボトルネックが発生する。さらにAWSとGCPのマルチクラウド環境を採用しているため、本来1つあればいい分析環境もクラウド環境ごとに分かれているなど、重複しているケースがみられるという。

2つ目の課題は、メタデータやデータリネージの課題である。メタデータ管理については、データが膨大すぎて、そもそもデータがどこにあるか、たとえデータにたどりついてもどのようなデータかわからなかったりする。

数千ユーザーの利用に耐えうるメタデータ整備にも課題があり、「ユーザービリティを高める仕組みが必要」と石井氏は言う。一方のデータリネージについては、データパイプラインが複雑でどこで生成されたかわからない、データの不具合の原因調査に時間がかかるなどの課題がある。3つ目の課題はガバナンス維持の運用負荷が高いことだ。

「数千ユーザー、数百GCPプロジェクトと規模が拡大し、インフラ運用の作業量が指数関数的に増加、データは年間数十％のスピードで増え続けています」（石井氏）

これらの課題に対する解決手段については、現在、検討中のステータスであるという。例えばDWHサービスの見直しを検討している。具体的にはデータ環境の抜本的な見直しをDWHサービスから検討していたり、既存構成（BigQueryやBigQuery Omni）をうまく使ってGCP上で構築することを検討したり、AWS上での構成については、SnowflakeやRedshiftを使ってAWS上で構築するなど、さまざまな構成について議論している。

また、分析環境についても、Vertex AIやSageMakerなどのNotebook環境の見直しも検討しており、他の選択肢としてDatabricks上に分析基盤を作るのはどうかというアイデアが議論されているという。

「3つ目の課題であるメタデータマネジメントやデータリネージについては、具体的な議論はまだこれからですが、DataCatalogやDatahubを導入するといいのではなど、見直しを検討しています」（石井氏）

全社共通データマートが抱える課題

PayPay株式会社　システム本部
Data Management部　小芝 涼太氏

続いて登壇したのは、小芝涼太氏だ。小芝氏のキャリアは動画配信サービス会社のWebエンジニアから始まる。2社目でデータエンジニアの仕事に従事し、データエンジニア歴は4年となる。

PayPayでもデータエンジニアとして、会社間のデータ連携やBIツールを利用したダッシュボード構築支援に従事。直近では全社で利用されるデータマートの構築・運用に携わっている。

まず語られたのは、全社共通マートの現状についてである。「Data Management部が統合して、全社共通マートを構築している」と小芝氏。全社共通マートのデータソースはプロダクトチームから提供され、現在10以上の業務部署の社員約200人がBIツールを使ってデータを参照しており、部署ごとに整備しているデータ群も存在しているという。

全社共通マートは3層構造となっており、Airflow上にパイプラインを作成して依存を管理している。1層目は型やカラム名の変換、JSONのフラット化などの前処理を行っている。2層目はユーザーに関連するテーブルや加盟店のテーブルなどの整備を行う。

3層目はマスタごとの集計項目やユーザー、加盟店軸の決済を行う汎用的な集計テーブルとなっている。1層目と2層目はデータソースの更新に合わせ1日4～5回、3層目は1日1回データを更新している。

「運用して1年が経過しましたが、社内からの問い合わせが徐々に増加しています。その中身のほとんどが品質やデータ定義に関するものです」（小芝氏）

データの品質が低下する原因は、データソースの仕様変更に対して追従の漏れがあること。および、その対応に関する各業務部門への連絡漏れである。

社内からの問い合わせを減らすための取り組み

問い合わせを減らすためには、データ品質の低下を検知することに加え、仕様変更の検知や周知するプロセスを改善することが必要になる。

データ品質低下を検知するために行っていることとして、次の4点が挙げられた。1点目はさまざまな検知の仕組みが整っているdbtを利用しデータ品質の検知を実施すること。2点目は品質チェックのみを先行して導入。3点目は有効性に関わる項目を最優先すること。4点目は完全性・整合性を一部導入したことである。

「あらかじめステータスを登録して異なるステータスが入ってきたことを検知するなど、今まで約70％は値が入っていたのに、急に20％ぐらいしか値が入ってこなかったことなどを検知する項目を最優先で入れました」（小芝氏）

導入してまだ数カ月だが、仕様変更を検知するなど便利に使えている数件がある一方で、ノイズになっているものもある。

例えば、月末はバラツキが大きいため、少しゆるめに設定したり、テーブル間の整合性についてもマスターデータの更新頻度や更新タイミングに合わせて、特定の日の検知を除外。泥臭い工夫を実施してノイズを減らし、意味のある通知を受け取れるようにしているという。

「現在もパイプラインは絶賛移行中で、パイプラインもdbtで実施するメリットは、Airflowの大半の処理が不要になることや、ディスクリプションのBQへの自動登録ができるようになること。dbt style guideを参考にコーディングスタイルの統一ができることです」（小芝氏）

また問い合わせを減らすためには、データ品質の低下を検知し、仕様変更を検知するプロセス改善や仕様変更を周知するプロセス改善に取り組んでいる。

仕様変更を検知するプロセス改善については、「新サービスの承認プロセスに参加することにした」と小芝氏は言う。というのもプロダクトや業務部門では影響の範囲判断が不可能にも関わらず、企画段階でData Management部が会話に入っていなかったからだ。

だが、承認プロセスの段階に参加しても、仕様変更がありそうという程度の判断はできるが、詳細な仕様はこの段階では決まっていないため、別角度のアプローチが必要だと感じているという。

仕様変更を周知するプロセス改善については、全社マートに関する開発情報をすべてオープンにすることで対応。仕様変更や影響範囲などを記したリリースノートの公開、開発中やリリース予定の公開を行っている。「効果は見えにくいが、今後の信頼性に繋がるはず」と、小芝氏は期待を寄せる。

今後の展望としては、まずは品質検知の定義・結果の可視化に取り組むこと。次にメタデータ管理やデータカタログなど、dbtのエコシステムをフル活用し、品質検知以外の改善を実施することが挙げられた。

最後にデータソースをプロダクト本部と共に整備したり、データマートを各業務部門と共に育てるなど、プロダクト本部や各業務部門との連携を強化することに取り組んでいく予定だと、小芝氏は力強く語った。

多くの質問が寄せられたQ&Aタイム

セッションが終わり、約20分間のQ&Aセッションが設けられた。抜粋して紹介する。

Q．データスクラムについては、どんな内容を他チームへ共有されているか

A．具体的には業務部門やデータガバナンスを管理する部門に対しては、データアクセスに関する注意事項やトレーニングに関するアナウンス、プロジェクトの移行の話などについて共有しています。また、プロダクトオペレーションチームには、dbtでどんなことができるのかを共有しています。

Q．BIツールが4つあるとのことだが、利用者はどのように使い分けているのか。ガイドラインなどを用意しているのか

A．外部配信用のBIとして専用に立てていて、Looker StudioはPayPayではずっと活用しておりユーザーも使い慣れています。基本的にアドホックな分析に使っており、Lookerはかっちりしたものをつくりたいときに使っています。

ただし、Lookerは可視化のところで自由が利かないこともあります。使い分けるため、各ツールの機能や使い勝手を記した星取表みたいなものを提供しています。

Q．メタデータはどのように管理しているか。特定のエンジニアのみが変更できるようにしているのか。ビジネスサイドのメンバーもメタデータを変更できるようにしているか

A．具体的にメタデータを効率的に管理するツールはPayPayでは導入されていません。Confluenceにユーザーがよく使うデータを入れ、ユーザーサイドで管理しています。中にはスプレッドシートなどで管理している部署もあります。ビジネスサイドのユーザーがメタデータを管理している場合は変更できるため、ツールの力を借りて統合できればいいと思います。

Q．マルチクラウドなデータを移行する際に、troccoなどのETLツールを活用するケースはあるのか

A．あります。例えばSalesforceからデータを引き抜く場合は、Fivetranを使っています。

Q．Looker（LookML）での指標定義・統一も全社データマート整備に近い話かと思うが、Lookerを使った取り組みもされているのか

A．Lookerではやらずに、データマートのところで指標を統一する方針を採用しています。

PayPay株式会社
https://about.paypay.ne.jp/

PayPay株式会社の採用情報
https://about.paypay.ne.jp/career/

PayPay株式会社のオウンドメディア「PayPay Inside-Out」
https://insideout.paypay.ne.jp/