ෆಈ࢈৘ใαΠτʹ͓͚Δ σʔλऩूͰؤுͬͨ͜ͱ💪 Jagu'e'r データ利活⽤分科会 Data Journey: データ収集 2024.02.15

⽬次 1. ⾃⼰紹介/弊社紹介 2. 本⽇話すこと/話さないこと 3. 分析基盤のシステム構成 4. 収集データ⼀覧 5. 収集元別 頑張ったこと 6. まとめ

⾃⼰紹介 杉⼭ 隆（Takashi Sugiyama） 3 • 所属 • 株式会社Red Frasco • 職種 • データエンジニア/MLエンジニア • 技術 • Google Cloud, Python, Golang • よく使うGCPサービス • Cloud Composer, Dataflow, Dataproc, BigQuery, ... • 趣味 • バスケットボール🏀, ガンダム🆓, ...

株式会社Red Frasco • https://www.red-frasco.com/ • 不動産業界に特化したプロダクト開発・集客⽀援を実施 • 今回はとある 賃貸不動産情報サイトのデータ分析基盤 のお話 4

本⽇話すこと/話さないこと • 話すこと • 弊社データ分析基盤内のデータ収集（データパイプライン）の仕組み • 収集⽅法、頑張ったこと・・・等 • 話さないこと • データ分析基盤のその他の仕組み • データ加⼯、データ可視化、データ活⽤・・・等 5

お願い 6 いいね︕と思ったら褒めてください︕ 👏👏👏

分析基盤のシステム構成（1/2） 全体構成 7

分析基盤のシステム構成（2/2） 本⽇話す内容はここ︕ 8

収集元別 収集データ⼀覧 9 No. 収集元 収集先 収集⽅法 データ例 1 Google アナリティクス BigQuery BigQuery Export 機能 アクセスログ 2 Cloud Storage BigQuery Cloud Composer システムデータ 3 Google スプレッドシート BigQuery 外部テーブル, Cloud Composer 集客実績 4 Web API BigQuery Cloud Composer 成約データ 5 FTP サーバ BigQuery Cloud Composer 会計データ 6 アドレポ © YRGLM Inc. BigQuery BigQuery 出⼒機能 広告データ 7 リアルタイムデータ（※） BigQuery Cloud Run, Pub/Sub アクセスログ ※⼀部 前回登壇資料 と内容が重複します。ご容赦ください。

収集元別 頑張ったこと – Cloud Composer 全般（1/3） • なぜ Cloud Composer を使っているのか • Python でワークフローを実装するため、収集元がどのようなもので あってもだいたい対応できる • 複雑な条件分岐に対応 • Sensor オペレータにより、収集元の処理が遅れても処理の続⾏が可能 • 例: Cloud Storage にファイルが置かれるまで⼀定時間待つ • GUIが分かりやすい 10

収集元別 頑張ったこと – Cloud Composer 全般（2/3） • 再取り込みを考慮 • 再取り込みをしてもデータが重複しないよう、WRITE_TRUNCATE や DELETE/INSERT を⾏っている 11 ※対象のテーブルが存在、かつレコードがあったら削除

収集元別 頑張ったこと – Cloud Composer 全般（3/3） • 再取り込みを考慮 • 環境変数で⽇付を指定することで、特定⽇のデータを取得可能に している 12 ※環境変数「BASE_DATE」が存在すればそちらを、存在しなければ当⽇の⽇付を 取り込み対象にする

収集元別 頑張ったこと – Google アナリティクス • BigQuery Export のログ監視を⾏う • BigQuery Export は⾃動でエクスポートしてくれる便利な機能ではあ るが、念のため Cloud Logging でログ監視を⾏う • フィルタ条件（GA4 の場合） 13 ※ 4⾏⽬の条件は、毎回データセットを作成しようとしてエラーになっているログを 除外するため（GA4 は最近作成しなくなった︖）

収集元別 頑張ったこと – Google スプレッドシート • スナップショット • データは更新されることがあるため、「外部テーブル」 +「Cloud Composer からのクエリ実⾏結果を保存」で スナップショットを保存 14

収集元別 頑張ったこと – Web API / FTP サーバ • egress IP を固定 • Web API 側でグローバル IP 制限が設定されている場合を考慮し、 Cloud NAT を使⽤して egress（下り）の IP アドレスを固定 15

収集元別 頑張ったこと – Web API • GA4 のデータも API で取得 • Analytics Data API を使⽤ • 即時性や、BigQuery Export されたデータの⼀部がWeb管理画⾯と 異なっていたため 16

収集元別 頑張ったこと – FTP サーバ • Python でオペレータを実装 • SFTP だと Airflow のオペレータがある・・・ 17

収集元別 頑張ったこと – アドレポ • 便利︕ • https://ad-repo.com/ • ステマではありません 18

なぜリアルタイムデータが必要なのか（1/2） • 賃貸不動産情報サイトにおけるユーザーの⾏動パターン • ほとんどのユーザは初回訪問でコンバージョン（Web での問い合わせ 等）する • そのためセッション内での訴求が重要となり、⾏動ログ等のユーザ データをリアルタイムで取得、さらにセッション内の⾏動を計測でき るようにすることが望まれる 19

なぜリアルタイムデータが必要なのか（2/2） • Google アナリティクスでは要件を満たせなかった • BigQuery Export 機能 • エクスポートされるタイミングが遅い（要件定義時は翌⽇午後） • 最近早くなってきた（翌⽇早朝）が、それでも要件を満たしていない • ストリーミングエクスポート機能 • 翌⽇以降にエクスポートされたレコードと⽐較すると、2〜3割程度のレコード⽋ 損がある︖（※今回の対象サイトだけかもしれません。ご参考まで。） • 将来的には GA からリアルタイムデータへの移⾏を検討 • UA → GA4 の移⾏に伴う作業が⼤変だった・・・ 20

収集元別 頑張ったこと – リアルタイムデータ（1/3） • ログを取得する仕組みは API で提供 • アプリケーション側に極⼒⼿が⼊らないように • 開発チームとの分離 • バックエンドは Cloud Run で構築 • 運⽤が楽︕ 21

収集元別 頑張ったこと – リアルタイムデータ（2/3） • ログの保存先は2つ • Cloud Run → Bigtable • ログをすぐに利⽤したい場合の保存先 • 過去2⽇分を保存 • Cloud Run → Pub/Sub → Dataflow → BigQuery • 通常利⽤の保存先 • 過去分全てを保存 22

収集元別 頑張ったこと – リアルタイムデータ（3/3） • 当初は Bigtable ではなく Firestore を利⽤していたが 書き込みエラーが多く出たため変更 • エラー原因は結局分からず・・・ • 「500/50/5」ルールはきちんと守っていた・・・はず・・・ 23

まとめ • データ収集で頑張ったことを説明させていただきました • 主に Cloud Composer について • その他の機能も機会があれば話させてください︕ • Embedding を使⽤した Item-to-Item レコメンド • Redash on GKE・・・等 24

Thanks for listening!