Data Engineering Meetup 【ZOZO × GMOペパボ】登壇資料 https://pepabo.connpass.com/event/242688/
GMOペパボのサービスと研究開発を支えるデータ基盤の裏側 https://speakerdeck.com/zaimy/inside-story-of-data-infrastructure-supporting-gmo-pepabos-services-and-r-and-d
データ”抽出”基盤 Yeti をつくっている話堤 利史 / GMO PEPABO inc.2022.04.20 Data Engineering Meetup【ZOZO × GMOペパボ】1
View Slide
2自己紹介技術部 データ基盤チーム シニア2020年 中途入社堤 利史 Tsutsumi Toshifumi2020年12月にGMOペパボへ入社。データエンジニアとしてデータ基盤の開発・運用に従事。Twitter: @tosh2230好きなポケモン: グレッグル
3アジェンダ1. GMOペパボにおけるELT*の現状2. データ抽出基盤 Yeti3. 今後の展望* ELT: Extract, Load, Transform
1. GMOペパボにおけるELTの現状4
- データ駆動のためのエコシステムの提供- サービスの動的な改善と意思決定の自動化をサポート詳細はこちらの資料をご参照ください 👉1. GMOペパボにおけるELTの現状5データ基盤 Bigfoothttps://speakerdeck.com/zaimy/inside-story-of-data-infrastructure-supporting-gmo-pepabos-services-and-r-and-d
61. GMOペパボにおけるELTの現状Data sourcelogsmetricsGitHub issuesdatabasesCollect datatblsdatasetsBigQuerybigfoot/platformCloud Storage- Permissions- Datasets- BucketsData Studiobigfoot/cloud-composerCloud Composerdags/tbls-buildbase tbls.ymlfilespatch files( *.yml, *.json )patched tbls.ymlfilestbls-metatblsdata catalogApplymetadataGenerate& CommitGenerateschema.json& commitbigfoot/data-catalogUpdatemetadata& commitSpread sheetViewSend analysis results
71. GMOペパボにおけるELTの現状Data sourcelogsmetricsGitHub issuesdatabasesCollect datatblsdatasetsBigQuerybigfoot/platformCloud Storage- Permissions- Datasets- BucketsData Studiobigfoot/cloud-composerCloud Composerdags/tbls-buildbase tbls.ymlfilespatch files( *.yml, *.json )patched tbls.ymlfilestbls-metatblsdata catalogApplymetadataGenerate& CommitGenerateschema.json& commitbigfoot/data-catalogUpdatemetadata& commitSpread sheetViewSend analysis results本日はこの範囲のうちリレーショナルデータベース(RDB)のデータ同期についてお話しします
1. GMOペパボにおけるELTの現状8- サービスが複数ある = データベースが複数ある- Amazon RDS に構築されているケースが多い- Bigfoot は GCP を中心に構成されている- AWS -> GCP のパブリッククラウド越境- Bigfootへのデータ同期状況はサービスによって異なる- 同期していない場合- リレーショナルデータベースやキーバリューストアは分析に不向き- 同期していても...- 同期方法がサービスごと異なり、ノウハウが分散している- サービスのデータを同期して分析したい! という点は同じGMOペパボはインターネットサービスを多数運営しています
9logsmetricsGitHub issuesdatabasesCollect datatblsdatasetsBigQuerybigfoot/platformCloud Storage- Permissions- Datasets- BucketsApplymetadataGenerateschema.json& commitSend analysis resultsサービスのRDBとBigfootの間に”なにか”があればよいのでは?1. GMOペパボにおけるELTの現状なにか2021年12月: 検討開始
10logsmetricsGitHub issuesdatabasesCollect datatblsdatasetsBigQuerybigfoot/platformCloud Storage- Permissions- Datasets- BucketsApplymetadataGenerateschema.json& commitSend analysis resultsサービスのRDBからBigfootへの”共通の入り口”をつくる1. GMOペパボにおけるELTの現状2021年12月: 検討開始2022年01月: 実装開始2022年03月: 本番稼働開始2022年04月: いまここ
1. GMOペパボにおけるELTの現状11下記の三点を目的としています💪- データエンジニアリングに関するノウハウの蓄積と共有- データマスキングやポリシータグによるデータ管理手法の共通化- サービスを横断したデータ活用の推進サービスのRDBからBigfootへの”共通の入り口”をつくる
122. データ抽出基盤 Yeti
13Yet another Extract-Transfer Infrastructure2. データ抽出基盤 Yeti
AWS (各サービス)AWS (各サービス)142. データ抽出基盤 YetiBigfootペパボの各サービスVPCExtract DAG Load DAGBigQueryCloud ComposerPrivatesubnetRDS ReplicaRDS PrimaryVPCVPCVPCECRSecretManagerS3VPCEndpointsVPCPeeringQueueBatchJob definitionPrivate subnetFargate (Batch Environment)Batch JobsCloudFormation
152. データ抽出基盤 Yetiデータ抽出の流れStep1: Extract DAG が AWS Batch Job の実行をリクエストStep2: コンテナが RDB からテーブル定義とレコードを抽出Step3: 抽出した結果を S3 バケットに保存Step4: Load DAG がデータを Google BigQuery にロード
AWS (各サービス)AWS (各サービス)162. データ抽出基盤 YetiBigfootペパボの各サービスVPCExtract DAG Load DAGBigQueryCloud ComposerPrivatesubnetRDS ReplicaRDS PrimaryVPCVPCVPCECRSecretManagerS3VPCEndpointsVPCPeeringQueueBatchJob definitionPrivate subnetFargate (Batch Environment)Batch JobsCloudFormationStep1Extract DAG がAWS Batch Job の実行をリクエスト
172. データ抽出基盤 Yeti- オーケストレーターは Google Cloud Composer- フルマネージド Apache Airflow- Bigfoot 全体のデータ操作を担当- DAG (Directed Acyclic Graph; 有向非巡回グラフ)- Airflow におけるワークフローの実行単位- Extract DAG は Batch Job が完了するまで待機- Extract DAG が正常終了したら Load DAG を開始Step1: Extract DAG が AWS Batch Job の実行をリクエスト
AWS (各サービス)AWS (各サービス)182. データ抽出基盤 YetiBigfootペパボの各サービスVPCExtract DAG Load DAGBigQueryCloud ComposerPrivatesubnetRDS ReplicaRDS PrimaryVPCVPCVPCECRSecretManagerS3VPCEndpointsVPCPeeringQueueBatchJob definitionPrivate subnetFargate (Batch Environment)Batch JobsCloudFormationStep2コンテナが RDB からテーブル定義とレコードを抽出
192. データ抽出基盤 Yeti- AWS Batch on AWS Fargate を利用- ひとつのコンテナが1テーブルを担当- 環境変数を経由して対象テーブル名や設定、抽出条件を指定- DB 接続情報は AWS Secrets Manager から取得- JobDefinition, Queue, Environment のパーツに分かれているためパフォーマンスチューニングをしやすい- Amazon RDS インスタンスとの接続はプライベートサブネットで実施- RDS インスタンスと同じAZのサブネットを指定するとVPC 間のデータ転送量が無料になるStep2: コンテナが RDB からテーブル定義とレコードを抽出(1)
- コンテナで実行しているアプリケーションk1LoW/tbls- テーブル定義, メタデータ, ポリシータグを出力- 後続処理として、tbls 出力ファイルを BigQuery のデータ型に変換するスクリプトを実行Embulk- レコードの抽出- RDBMS に合わせてプラグインを変更- e.g. embulk-input-mysql Parquet202. データ抽出基盤 YetiStep2: コンテナが RDB からテーブル定義とレコードを抽出(2)AWS Batch JobRDSS3JSONスキーマレコードParquetParquet
AWS (各サービス)AWS (各サービス)212. データ抽出基盤 YetiBigfootペパボの各サービスVPCExtract DAG Load DAGBigQueryCloud ComposerPrivatesubnetRDS ReplicaRDS PrimaryVPCVPCVPCECRSecretManagerS3VPCEndpointsVPCPeeringQueueBatchJob definitionPrivate subnetFargate (Batch Environment)Batch JobsCloudFormationStep3抽出した結果をS3 バケットに保存
- レコード群を一定のサイズで区切って Apache Parquet 形式に変換- Embulk での抽出結果は embulk-output-command で標準入力に流す- PyArrow で変換して S3 バケットに PUT- Fargate のメモリサイズに収めるための工夫- Apache Parquet- 列指向ファイルフォーマット- ファイルサイズの圧縮を期待できる- 圧縮することによるメリット- データ転送費用の削減(S3 -> BigQuery)- データ出力・転送時間の削減ParquetS3JSONスキーマレコードParquetParquet222. データ抽出基盤 YetiStep3: 抽出した結果を S3 バケットに保存AWS Batch JobRDS
AWS (各サービス)AWS (各サービス)232. データ抽出基盤 YetiBigfootペパボの各サービスVPCExtract DAG Load DAGBigQueryCloud ComposerPrivatesubnetRDS ReplicaRDS PrimaryVPCVPCVPCECRSecretManagerS3VPCEndpointsVPCPeeringQueueBatchJob definitionPrivate subnetFargate (Batch Environment)Batch JobsCloudFormationStep4Load DAG がデータをGoogle BigQuery にロード
242. データ抽出基盤 YetiStep4: Load DAG がデータを Google BigQuery にロード- BigQuery Data Transfer Service(DTS) で一時テーブルとしてロード- 既存テーブルに対して一時テーブルのレコードを追加・更新- Policy Tag を設定- BigQuery 列レベルのセキュリティ- 列ごとにアクセス権限を設定できる- tbls で取得したメタデータの ColumnLabel 設定値で制御- e.g. “Sensitive”ラベルがついている列は管理者のみアクセスできるようにする
25Yetiを構築・運用してみてどうですか?
262. データ抽出基盤 Yeti- 他のサービスに横展開しやすい- AWS CloudFormation でコード管理している- RDBMS の種類にあわせて、コンテナ内の Embulk Input プラグインを変更すればだいたい動く- Extract DAG の設定ファイルにテーブル名を追記すれば同期対象を増やせる- サーバーレス基盤なので運用の負担が少ない- スケーリングを気にしなくてよい- コンテナ内のアプリケーションに集中できる- (コストは注視しています...)Yetiのよいところ
272. データ抽出基盤 Yeti- Extract DAG と Load DAG で、1タスク・1テーブルの構成になっている- Airflow にはサーバーのスペックに応じた Concurrency 推奨値がある- 同期テーブル数が増えると、いずれ Cloud Composer がボトルネックになる- 1タスク・nテーブル といったグルーピングが必要- BigQuery DTS ではないロード方法の検討- 新しいオブジェクトを認識するまで 10 min ほどの時間を要する- DTS のサービスステータスを確認する手段がなさそう...- “S3 -> GCS -> BigQuery” の経路に変更予定Yetiで改善したいところ
281. セクションタイトル3. 今後の展望
3. 今後の展望29- 既存のRDB同期処理をYetiに移行する- バッチレイヤー以外の選択肢を設ける- BIツールに蓄積されたクエリ実行履歴の分析話題に挙がっているトピックをご紹介します
3. 今後の展望- Embulk を使っているサービスが多いので、まずはそこから始める- Yetiの目的のうち、下記の2点を社内に広めていく- データエンジニアリングに関するノウハウの蓄積と共有- データマスキングやポリシータグによるデータ管理手法の共通化- 全社統一 ELT 基盤へ💪30既存のRDB同期処理をYetiに移行する
3. 今後の展望31- RDBとの同期は日次で行っている- スピードレイヤーにあたる何かを提供していきたい- Change Data Capture (CDC) が有力な選択肢バッチレイヤー以外の選択肢を設ける
3. 今後の展望32- ペパボでよく使われている BI ツールは Redash- Redash のメタデータは PostgreSQL に保存されている- Yeti で同期すれば、クエリの実行状況を把握できる- よりよい方法を提案することで、施策検討を効率化するBIツールに蓄積されたクエリ実行履歴の分析
33Thank You!Thank You!