マイクロアドでの Hive → Iceberg 移行事例紹介

2026/2/13 OTFSG Tokyo Meetup #5
マイクロアドでのHive → Iceberg 移行事例紹介

Transcript

1. マイクロアドでの Hive → Iceberg 移行事例紹介 株式会社マイクロアド 高橋 唐樹 OTFSG Tokyo Meetup #5 1
2. 自己紹介 / 高橋 唐樹 OTFSG Tokyo Meetup #5 2 ⚫ 株式会社マイクロアド システム開発部 データマネージメントユニット ◼ 弊社出身のやっさんのご縁で登壇 ⚫ 仕事 ◼ 大規模データ処理開発 ◼ データマネジメント ⚫ 好きな言語: Python ⚫ 経歴 ◼ 2022/3: 東京農工大学大学院 修士課程修了 ◼ 2022/4: 株式会社マイクロアドに新卒入社
3. OTFSG Tokyo Meetup #5 3 目次 1. 会社紹介 ◼ 会社と事業内容 2. マイクロアドのデータ基盤 ◼ 移行前後の基盤構成 3. 移行の事例紹介 ◼ Iceberg活用事例 ◼ Icebergでの悩み ◼ やりたいけどできてないこと
4. OTFSG Tokyo Meetup #5 4 目次 1. 会社紹介 ◼ 会社と事業内容 2. マイクロアドのデータ基盤 ◼ 移行前後の基盤構成 3. 移行の事例紹介 ◼ Iceberg活用事例 ◼ Icebergでの悩み ◼ やりたいけどできてないこと
5. マイクロアドについて / VISION OTFSG Tokyo Meetup #5 5 Redesigning the Future Life ビッグ データ AI テクノロジー データとテクノロジーの力で “未来を予測する”
6. マイクロアドについて / 事業内容 OTFSG Tokyo Meetup #5 6 ⚫ 自社製品を提供するデータプロダクト事業 ◼ データプラットフォーム UNIVERSE ◼ 広告主向けプラットフォーム UNIVERSE Ads ◼ 媒体社向けプラットフォーム MicroAd COMPASS ◼ 業種特化マーケティングプロダクト ◼ その他 広告サービス ⚫ 他社製品を扱うコンサルティング事業 ◼ 海外コンサルティングサービス ◼ メディア向けコンサルティングサービス
7. マイクロアドについて / 事業内容 OTFSG Tokyo Meetup #5 7 ⚫ 自社製品を提供するデータプロダクト事業 ◼ データプラットフォーム UNIVERSE ◼ 広告主向けプラットフォーム UNIVERSE Ads ◼ 媒体社向けプラットフォーム MicroAd COMPASS ◼ 業種特化マーケティングプロダクト ◼ その他 広告サービス ⚫ 他社製品を扱うコンサルティング事業 ◼ 海外コンサルテイングサービス ◼ メデイア向けコンサルティングサービス インターネット広告
8. OTFSG Tokyo Meetup #5 8 目次 1. 会社紹介 ◼ 会社と事業内容 2. マイクロアドのデータ基盤 ◼ 移行前後の基盤構成 3. 移行の事例紹介 ◼ Iceberg活用事例 ◼ Icebergでの悩み ◼ やりたいけどできてないこと
9. データ基盤 / 前提 OTFSG Tokyo Meetup #5 9 ⚫ データの大部分をオンプレのサーバーで保持 ⚫ ざっくりの移行理由は利用していたHadoopディストリビューションが継続利用できないため ⚫ データ規模 ◼ 実効容量: 約 2 PB ◼ 流量: 約 13 TB/日 ⚫ データ量が多いテーブルの例 ◼ RTBのログ: 約 65億 件/日 ◆ RTB: 広告オークション ◼ ターゲティング用のユーザー情報: 約 220億 件 ◆ ターゲティング: 狙った属性のユーザーに広告を出す ⚫ ETL処理: 約 250〜 ◼ ETL: データの抽出・変換・蓄積
10. OTFSG Tokyo Meetup #5 10 データ基盤 / 移行前の構成 “ ” OTFSG Osaka #1 / やっさん “マイクロアドのData LakehouseとIcebergテーブルの最適化について”
11. OTFSG Tokyo Meetup #5 11 データ基盤 / 移行前の構成 “ ” OTFSG Osaka #1 / やっさん “マイクロアドのData LakehouseとIcebergテーブルの最適化について”
12. OTFSG Tokyo Meetup #5 12 データ基盤 / 移行後の構成 “ ” OTFSG Osaka #1 / やっさん “マイクロアドのData LakehouseとIcebergテーブルの最適化について”
13. OTFSG Tokyo Meetup #5 13 ⚫ ハードウェア側のI/O性能に不安 ◼ 日次集計タイミングなどのピーク時の負荷を減らしたい ⚫ その他の課題やより詳しい基盤自体の話は過去の発表をご覧ください！ データ基盤 / 課題
14. OTFSG Tokyo Meetup #5 14 目次 1. 会社紹介 ◼ 会社と事業内容 2. マイクロアドのデータ基盤 ◼ 移行前後の基盤構成 3. 移行の事例紹介 ◼ Iceberg活用事例 ◼ Icebergでの悩み ◼ やりたいけどできてないこと
15. OTFSG Tokyo Meetup #5 15 ⚫ 誰: ユーザー識別子 ⚫ 何について: セグメントの種類と属性値 ◼ 種類: 性別、年齢、居住地、興味のありそうなキーワード など ◼ 属性値: 男性、20代、関東在住、技術系のキーワード など ⚫ 度合い: スコア ◼ 確定情報か推定情報か ◼ 興味の度合いはどの程度か ⚫ 情報提供元 ◼ 外部から提供されたデータ ◼ マイクロアドで収集したデータ ⚫ データの有効期限 ◼ いつからいつまで使えるデータなのか 活用事例① ターゲティング用ユーザー情報の更新 / データの内容 ? 20代 関東在住 OTFに興味 Connpassに登録 ※データは適切に匿名化/ハッシュ化されており、個人を特定するものではありません
16. OTFSG Tokyo Meetup #5 16 ⚫ ユーザーの行動・興味のあるキーワードなど日々情報は更新される ⚫ 過去のある時点での情報も必要 ◼ 広告配信後にどのようなユーザーに対して効果が良かったかを分析 ◆ そのユーザーに広告が表示された時点でのユーザー情報 ◼ データ提供者へ支払う利用料金の集計 ◆ 月末時点で保有している提供されたデータ量 ⚫ 特定の日付時点での状態を全て保持しておくにはデータ量が多い ◼ ターゲティング用のユーザー情報: 約 220億 件 ◼ 更新されていない場合でも複製は保持することになる 活用事例① ターゲティング用ユーザー情報の更新 / 更新内容 M/D時点でのユーザー情報 2/11時点でのユーザー情報 2/12時点でのユーザー情報 …
17. OTFSG Tokyo Meetup #5 17 ⚫ Time Travel: 過去の特定の時点でのテーブルの状態を参照できる機能 ⚫ タグ: 過去の特定の時点に対して名前をつけておく機能 ⚫ ユーザー情報の更新完了時点でタグをつける ◼ 例: YYYY-MM-DD ⚫ 特定の日付時点でのユーザー情報が参照できる かつ 変更がないファイルについては複製が作られない状態を実現 ⚫ テーブル全体での容量 ◼ Hive: 60 TB ◼ Iceberg: 20 TB ◼ スナップショット間でのファイルの使いまわしにより大幅削減 ◆ 更新されないユーザー情報も多くある 活用事例① ターゲティング用ユーザー情報の更新 / Time Travel + タグ
18. OTFSG Tokyo Meetup #5 18 ⚫ RTB: 広告オークション ◼ Webサイト訪問時に広告枠毎に表示する広告を決めるためのオークションが行われる ⚫ インプレッション ◼ 広告が画面に表示されること ◼ RTBから短時間の間に発生 ⚫ クリック ◼ 広告がクリックされ、広告主サイトに移動すること ◼ RTBから短時間の間に発生 ⚫ CV: コンバージョン ◼ 商品購入、アプリのダウンロードなどの広告配信の最終目標 ◼ RTBから長時間経ってから発生することがある ◆ 例) 30日経過してからの購入を広告の効果として計上する 活用事例② RTB時刻ベースでの広告効果集計 / 用語の説明 RTB インプレッシ ョン クリック CV
19. OTFSG Tokyo Meetup #5 19 ⚫ インプレッション・クリック・CVにRTB情報を紐づけ、RTB日時のhour単位で集計 ◼ 例) 広告主Aの広告Xについて、2026-01-01 0時台のRTBでどの程度の成果が上がったか ⚫ インプレッション・クリックはRTBから30分以内に発生したものが対象 ◼ RTB: 00:00:00 〜 01:00:00 ◼ インプ・クリック: 00:00:00 〜 01:30:00 ◆ 0時台の集計は0・1時台のログが揃えば可能 ⚫ CVはRTBから60日以内に発生したものが対象 ◼ 今日発生したCVは今日のRTBに紐づくこともあるし、60日前に紐づくこともある ⚫ 60日分が毎日更新される可能性がある ◼ CV（商品購入など）はあまり発生しないので更新対象の行はごく一部 活用事例② RTB時刻ベースでの広告効果集計 / 集計内容
20. OTFSG Tokyo Meetup #5 20 ⚫ MoR: Merge on Readとは？ ◼ データファイルの変更差分だけを書き込み、読み込み時に合体させる仕組み ◆ 書き込みのパフォーマンス向上・書き込み量の削減 ◆ 読み込み側の負荷は大きくなる ◼ 差分ファイルが増えすぎると参照パフォーマンスが悪化するので定期的なメンテナンスが必要 ◼ ⇔ CoW: Copy on Write ⚫ CV数をMoRで更新することで書き込み量を大幅削減 ◼ 最悪の場合の書き込み量: 450〜600 GB ◆ データ量: 300〜400 MB/時 × 60 日 ◆ CoW かつ 60日分全てのデータファイルに更新が入った場合 ◼ 実際の書き込み量: 約 130 MB ◆ 60日分の集計でも書き込み量を抑えられている 活用事例② RTB時刻ベースでの広告効果集計 / MoR
21. OTFSG Tokyo Meetup #5 21 ⚫ MoRの振り返り ◼ 差分ファイルが増えすぎると参照パフォーマンスが悪化するので定期的なメンテナンスが必要 ⚫ コンパクション ◼ rewrite_data_filesプロシージャの実行によってデータファイルの状態を適切に保つ ◼ データファイルの分割・結合、削除ファイルとの統合など ⚫ コンパクションの実施基準 ◼ #データファイル : #削除ファイルの比率がしきい値を超えたら？ ◼ 1ファイルあたりの平均容量がしきい値を下回ったら？ ◼ テーブルの状態に関係なく定期的に実施？ ◼ しきい値はどの程度が妥当？ Icebergでの悩み / コンパクション戦略、どうしてますか？
22. Icebergでの悩み / いろいろ OTFSG Tokyo Meetup #5 22 ⚫ Hidden Partitioningをもっと使いたかった ◼ 多くのテーブルでログの時刻基準の dt=‘YYYYMMDD’, hour=‘HH’ パーティション ◆ 移行のタイミングで hour(time) のような形式に切り替えたかった ◼ 利用者が今の形式に慣れてしまっており、変更が大変との意見が多かった ⚫ Trinoでタイムゾーン付きのTimestampがUTCで表示されてしまう ◼ Sparkでタイムゾーン付きで書き込んでいる ◼ Trinoからの参照時に頭の中で+9時間しなければならない ⚫ CSVやJSONなどの半構造化データをテーブルにできなくなった ◼ Parquetに変換するなどの1ステップが必要に
23. やりたいけどできてないこと / 監視・可視化 OTFSG Tokyo Meetup #5 23 ⚫ 現状を見やすい状態にしたい ◼ コンパクション戦略を考える参考に ◼ テーブルのパーティション分割を考える参考に ⚫ メタデータテーブルでテーブルの状態が取れる ◼ アクティブなファイル数、全ファイル数 ◼ アクティブな容量、テーブルの全容量 ◼ パーティションごとのレコード数、容量 ⚫ MetricsReporterでRead/Write時の情報が取れる ◼ 実行計画作成にかかった時間 ◼ 書き込みにかかった時間
24. まとめ OTFSG Tokyo Meetup #5 24 ⚫ 広告配信のデータ基盤をHiveからIcebergに移行 ⚫ Time Travel, タグ, MoRなど便利な機能が多い ⚫ メンテナンスが重要になったがまだ知見が溜まっていない ⚫ 監視・可視化をこれから頑張りたい
25. 株式会社 マイクロアド 〒150-0031 東京都渋谷区桜丘町20-1 渋谷インフォスタワー 13F www.microad.co.jp OTFSG Tokyo Meetup #5 25