広告配信におけるビッグデータ活用とそれを取り巻くシステム - Tech x Marketing - @issy/Zucks

Transcript

1. 広告配信における ビッグデータ活用と それを取り巻くシステム Tech x Marketing Conference 2021
2. 2 誰？ 石塚 大貴 いしづか だいき CARTA HOLDINGS / Zucks 将棋 精油 珈琲 ピアノ (いっしー) 趣味 フルサイクルエンジニア(3年目) データエンジニア(1年目) Profile
3. 3 CARTA HOLDINGS とは？
4. 4 CARTA HOLDINGS とは？ 2022 年 1 月
5. 5 CARTA HOLDINGS とは？ アドプラットフォーム事業 ‧ メディア事業 を中心に 10以上の事業 25以上のサービス を展開
6. 6 CARTA HOLDINGS とは？ アドプラットフォーム事業 ‧ メディア事業 を中心に 10以上の事業 25以上のサービス を展開
7. 7 Zucksの事業紹介 アドネットワーク DSP 成果報酬型広告 広告配信プラットフォーム
8. 話すこと 話さないこと 8 今日のお話 Zucks の業務における分析データ活用 データメネジメント概論
9. 9 Zucks におけるデータ扱いの歴史 Zuck設立 2011 解析チーム発足 2016 BigQuery導入開始 2014 ビジネス成長 データ活用用途の多様化 bqloader開発 2015 ※1 bqloaderの刷新 Looker の導入 2020 ～ 2021 ... 分析用re:dashを導入 2016 ※1 bqloader とは s3 に置いたファイルをBigQuery にロードして使えるようにする社内サービス
10. 10 データ活用用途の多様化 配信ログ Impression Click CV etc... Ads 配信条件 マスターデータ どのようなデータがあるか？
11. 11 データ活用用途の多様化 どれくらいのデータがある？ 約 580億 レコード 約 4.6 TB (圧縮済) 1日あたり 増加
12. 12 データ活用用途の多様化 どれくらいのデータを扱ってるの？ クエリ数 500TB 以上 6.5K 以上 1日あたり クエリ処理サイズ
13. 13 データ活用用途の多様化 2018 67種類 2019 144種類 2020 175種類 2021 186種類 2017 44種類 ?? BigQuery に取り込みログの種類数の変化 ログの取り込み種類も大幅に増加
14. 14 データサイエンス エンジニア データ分析 ロジック開発 アプリケーション エンジニア ビジネスユーザー データ活用用途の多様化 誰がどういう用途でデータを使う？ 初期の 用途
15. 15 データサイエンス エンジニア データ分析 ロジック開発 アプリケーション エンジニア アラート監視 リリース後の 挙動チェック 原因調査 ビジネスユーザー レポート データ活用用途の多様化 誰がどういう用途でデータを使う？ 用途の 多様化
16. 16 データ活用用途の多様化 誰がどういう用途でデータを使う？ データサイエンス 74% re:dash 14% Looker 7% 他5% 他5% クエリサイズ クエリ数 データサイエンス 42% re:dash 10% フラウド検知 バッチ 44% 機械学習 BIツール が大半を締めている
17. データ量の増加 A B C D A B C データ種類の増加 D E F 17 データエンジニアリングの重要性が増加 複雑化 負荷増 2020年末くらいからデータエンジニアをやることに
18. 18 業務におけるデータエンジニアリング 2つの軸で話します ETL編 E T L BigQuery 活用編 BigQuery Data Science BI Tools
19. 19 ETL編 E T L BigQuery 活用編 BigQuery Data Science BI Tools
20. 配信サーバー バッチ 20 ETL編: 現bqloader s3 SQS log sns EC2 Extract Transform ECS Load Google Storage BigQuery bqloader worker load batch システム構成
21. 配信サーバー バッチ 21 システム構成 s3 SQS log sns EC2 Extract Transform ECS Recover recover batch ECS dedupe dedupe batch ECS Load Google Storage BigQuery bqloader worker load batch 差分 再取り込み 重複排除クエリ ETL編: 現bqloader
22. 22 を使っている Workflow Engineとして ←ビジネスロジック ←依存関係 ←outputファイル AWS S3やGoogleStorageなどをoutputにできる ETL編: 現bqloader
23. 23 を使っている Workflow Engineとして bqloader load 起 点 機械学習 バッチ データ処理バッチ bqloader recover 機械学習 バッチ 機械学習 バッチ ETL編: 現bqloader
24. 24 を使っている Workflow Engineとして bqloader load 起 点 機械学習 バッチ データ処理バッチ bqloader recover 機械学習 バッチ 機械学習 バッチ ETL編: 現bqloader
25. 25 を使っている Workflow Engineとして bqloader load 起 点 機械学習 バッチ データ処理バッチ bqloader recover 機械学習 バッチ 機械学習 バッチ ETL編: 現bqloader
26. 26 障害が発生 14:00 15:00 14:30 15:30 14:15 15:15 14:45 15:45 OK OK ETL編: 現bqloader
27. qube load TARGET_DATETIME=2021-12-10T1415 qube load TARGET_DATETIME=2021-12-10T1430 qube load TARGET_DATETIME=2021-12-10T1445 qube load TARGET_DATETIME=2021-12-10T1500 qube load TARGET_DATETIME=2021-12-10T1515 qube load TARGET_DATETIME=2021-12-10T1530 27 障害が発生 復旧コマンド 14:00 15:00 14:30 15:30 14:15 15:15 14:45 15:45 OK OK ETL編: 現bqloader
28. qube load TARGET_DATETIME=2021-12-10T1415 qube load TARGET_DATETIME=2021-12-10T1430 qube load TARGET_DATETIME=2021-12-10T1445 qube load TARGET_DATETIME=2021-12-10T1500 qube load TARGET_DATETIME=2021-12-10T1515 qube load TARGET_DATETIME=2021-12-10T1530 28 障害が発生 復旧コマンド 14:00 15:00 14:30 15:30 14:15 15:15 14:45 15:45 OK OK 復旧するのを簡単にしたい ETL編: 現bqloader
29. 29 ETL編: 新bqloader 新システム構成図 配信サーバー バッチ s3 SQS log SNS
30. 30 ETL編: 新bqloader 新システム構成図 配信サーバー バッチ s3 SQS log SNS lambda Pub/Sub dataflow BigQuery New!
31. 31 ETL編: 新bqloader 配信サーバー バッチ s3 SQS log SNS lambda Pub/Sub dataflow BigQuery recover Airflow dedupe Airflow 差分チ ェ ッ ク 再投入 重複排除 差分チェック 差分チェック 新システム構成図
32. 32 ETL編: 新bqloader dataflowを採用した3つの理由 フルマネージド Apache Beam の恩恵 採用実績
33. 33 ETL編: 新bqloader apache beam プログラミング https://www.oreilly.com/radar/the-world-beyond-batch-streaming-101/
34. 34 ETL編: 新bqloader apache beam プログラミング https://www.oreilly.com/radar/the-world-beyond-batch-streaming-101/
35. 35 ETL編: 新bqloader apache beam プログラミング https://www.oreilly.com/radar/the-world-beyond-batch-streaming-101/
36. 36 ETL編: 新bqloader dataflow の苦悩: おもしろバグ watermark lagが 5,000w 余談: 計算してみると、UNIX TIMESTAMP 0 (1970年) からの時間
37. 37 ETL編: 新bqloader dataflow の苦悩: おもしろバグ class SomeDoFn extends DoFn<String, String> { private Counter counter = Metrics.counter(SomeDoFn.class, "my-counter"); @ProcessElement public void processElement(ProcessContext c) { counter.inc(); } } droppedDueToLatenessでcustom metrics を受けつけなくなる こんな感じで簡単にカスタムメトリクスが送れるのだが……
38. 38 ETL編: 新bqloader dataflow の苦悩: オートスケールが攻め過ぎ 24台 24台 3台 3台
39. 39 ETL編: 新bqloader dataflow の苦悩: オートスケールが攻め過ぎ Scaling up: If a streaming pipeline remains backlogged with workers utilizing, on average, more than 20% of their CPUs, for a couple minutes, Dataflow scales up. Dataflow targets clearing the backlog in approximately 150 seconds after scaling up, given the current throughput per worker. Scaling down: If a streaming pipeline backlog is lower than 10 seconds and workers are utilizing on average less than 75% of the CPUs for a period of a couple minutes, Dataflow scales down. After scaling down, workers utilize on average, 75% of their CPUs. In streaming jobs that do not use Streaming Engine, sometimes the 75% CPU utilization cannot be achieved due to disk distribution (each worker must have the same number of persistent disks), and a lower CPU utilization is used. For example, a job set to use a maximum of 100 workers (with 1 disk per worker) can be scaled down to 50 workers (with 2 disks per worker). For this job, a 75% CPU utilization is not achievable because the next scale down from 100 workers is 50 workers, which is less than the required 75 workers. Consequently, Dataflow does not scale down this job, resulting in a lower than 75% CPU utilization. No scaling: If there is no backlog but CPU usage is 75% or greater, the pipeline does not scale down. If there is backlog but CPU usage is less than 20% the pipeline does not scale up. https://cloud.google.com/dataflow/docs/guides/deploying-a-pipeline 自分でスケーリング条件を管理したい: 切実
40. 40 ETL編: 新bqloader そしてついにスケールインしなくなりました backlog が10秒を切らないという理由
41. 41 ETL編: 新bqloader dataflowつらい (BigQueryIO.write を使わない場合には、あまり気にならない) 戦いは、まだまだ続く……
42. 42 ETL編: 新bqloader うまくいかなかった理由の考察 レコードの1カラムがでかすぎた Apache Beam の BigQueryIO.write の内部実装がイケてない dataflow のスケーリングの仕様が厳しすぎる ビジネスの特性の違い 普通にやってもうまくいかない 現状) これらを元に再設計してます
43. 43 table_20211201 table_20211202 table_20211203 ... table_a table_b table_c ... table table ETL編: 新bqloader 新設計で良かった点もあります 日付別シャーディングテーブルをパーティションテーブルにする 同じ schemaのテーブルをまとめて差分をclustering field に切りだす select field from table_A union all select field from table_B union all select field from table_c select field from table SQLを書く時間の大幅短縮 クエリで 1,000 table_referencesの上限を超えなくなる
44. 44 ETL編 E T L BigQuery 活用編 BigQuery Data Science BI Tools
45. 45 Data Science
46. 46 Data Science 使っている分析ツールの紹介 EXPLORATORY Data Studio BigQuery
47. 47 gcs ECS 学習・予測 データ加工 Data Science BigQuery s3 ECR task definition サーバー docker image push クエリ・データ保存 ログETL 保存 取得 アルゴリズム実行 parameter feature lambda CloudWatch Event (Schedule) 依存チェック 中間ファイル保存
48. 48 BI Tools
49. BigQuery Athena DynamoDB データソース 49 BI Tools アラート ダッシュボード スケジュール実行 グラフ表示
50. 50 BI Tools Queries 1,895 (archive, draft のクエリを除く)
51. 51 BI Tools Queries 1,895 同じような用途のクエリがたくさんある 見たい軸が少し違うだけでも fork してクエリを作りがち クエリのメンテナンスコストが増える 実際「こういうクエリを書いて欲しい」という依頼が多い
52. 52 BI Tools を使ってみることに
53. 53 BI Tools の特徴 LookMLでデータの意味を定義 Git でのコード管理 マネージドサービス
54. 54 BI Tools view: orders { dimension: id { primary_key: yes type: number sql: ${TABLE}.id ;; } dimension: order_amount { type: number value_format: “0.00” sql: ${TABLE}.amount ;; } measure: count { type: count } サンプルコード(一部抜粋) dimension view measure フィールド定義 型は何か？ count percentile median XX_distinct sum average min max 表示フォーマットはどうするか？ 実際にデータソースに投げるSQLは? etc... etc... 集計項目を定義 (aggregate) テーブル定義
55. 55 BI Tools view: orders { dimension: id { primary_key: yes type: number sql: ${TABLE}.id ;; } dimension: order_amount { type: number value_format: “0.00” sql: ${TABLE}.amount ;; } measure: count { type: count } サンプルコード(一部抜粋)
56. 56 BI Tools おすすめの始め方 一気に全てのテーブルを LookMLに書き起こそうとしない 大変だし、1巡目は書き方に困って、後々リファクタリングしたくなります 使われるところから書き起こそう(使われ始めると自然と要望が来るようになります) テーブル構造を使いやすい形に LookMLは万能ではありません。テーブル構造が汚ないとモデリングが大変です。 例: 日付別シャーディングテーブルはどうやってモデリングするの？(スキャンサイズ落としたいんだが) 今までのものと併用して使う LookMLを定義していない場合には使えない (厳密にいうと使いづらい) SQLを扱える人にとっては、特殊な aggregation などは自分で書いた方が速い 新ETLがうまくいってから、もっと使いやすい形にしたい
57. 57 興味をもたれた方へ Engineers in VOYAGE という本があります 第2章では、Zucksのエンジニア文化 第6章では、詳しく話せなかったデータサイエンスまわりの話 目次 第1章 fluct：広告配信の舞台裏の技術者たち 第2章 Zucks：フルサイクル開発者の文化 第3章 VOYAGE MARKETING：20年級大規模レガシーシステムとの戦い 第4章 VOYAGE Lighthouse Studio：数十万記事のメディアをゼロから立ち上げる 第5章 サポーターズ：事業の成長を止めない手段としてのシステム刷新 第6章 データサイエンス：エンジニアによるビジネスのための機械学習 なんかもあります 手にとって読んでみてください いっしょに働く仲間を募集中！ やりがいのある挑戦があなたをまっています！