Upgrade to Pro — share decks privately, control downloads, hide ads and more …

サイバーエージェントの実践×実験Snowflake 導入の経緯から最新機能のトライアルまで /...

Kurochan
October 05, 2021

サイバーエージェントの実践×実験Snowflake 導入の経緯から最新機能のトライアルまで / How Snowflake Is Used In CyberAgent - Go To the Future

BUILD.localイベントはコミュニティメンバーによってリードされており、「BUILD」の名の通り、データアプリケーション、データサイエンス、データエンジニアリング、そしてデータシェアリングの領域でイノベーションを作り上げている人たちのためのイベントです。
https://usergroups.snowflake.com/events/details/snowflake-japan-presents-buildlocal-japan-snowparkdexi-ufei-gou-zao-deta-playing-with-unstructured-data-using-snowpark/

Kurochan

October 05, 2021
Tweet

More Decks by Kurochan

Other Decks in Technology

Transcript

  1. サイバーエージェントの実践×実験Snowflake 導⼊の経緯から最新機能のトライアルまで How Snowflake Is Used In CyberAgent - Go

    To the Future 株式会社サイバーエージェント AI事業本部 黒崎 優太 (@kuro_m ) @Snowflake Build.local Japan
  2. 開発しているシステム概況 • ⼊札リクエスト量: 数⼗万リクエスト / 秒 数千億リクエスト/⽉ • ⼊札トラフィック: 約8Gbps

    • レスポンスタイム: 100ms以内 • ログの量: 数TB / Day(圧縮状態) • ALL AWS ೔ຊͷೖࡳϦΫΤετඵ ೔ຊΞϝϦΧͷϨεϙϯελΠϜ NTFD
  3. Dynalystでの悩み • ログの転送量がとにかく多い(数TB/day) • 事業の特性上仕⽅がない • データウェアハウスのコスト • ⾦銭的コストが課題だった •

    データウェアハウスのパフォーマンスが引き出せない • ログの転送量が多いことに起因して、読み込み性能が引き出せていなかった • データウェアハウスの運⽤負荷 • テーブルのローテーションやDWHの空き容量の整理といったメンテナンス作業
  4. 費⽤の試算 • 何はともあれ、費⽤が現実的でなければ選択肢に⼊らない • Snowflakeはどれくらいのリソースをどのくらいの時間使うのかがキモ • 厳密な費⽤を⾒積もるのは無理だった • コンピュートリソースをどれくらい利⽤するかが読めなかった •

    ⼩規模な環境を⽤意して実際に動かすことで費⽤感を把握した • ある程度使⽤量を予測して事前にコミットしなくて良いのは安⼼ • 以前の環境よりは⾼くならなさそう、という感覚はつかめた
  5. ログのローテーションのしやすさ • TBくらいのテーブルに対して2TB分くらいの削除をした • DELETE FROM table WHARE logged_at >=

    ... • 数秒でクエリが終了した • メタデータ更新のみか、バックグラウンドで削除が⾏われるようで、 ⼤量のデータの削除が楽 • ⼀定期間経過するとexpireするような機能もあるとさらに嬉しいところ。。
  6. Snowpipe • S 等へのファイルのPUTイベントをフックしてSnowflakeにファイルをリアル タイムに取り込んでくれる仕組み • Virtual Warehouseのリソースは使⽤しないのでパフォーマンス影響がない • 別途Snowpipe代が掛かる

    • 費⽤の計算⽅法がないため、実験してみないと費⽤はわからない • 体感的にはそんなに⾼くない • TB/⽇くらいの勢いでデータを投⼊してもS へのPUTからクエリできるように なるまで数分だった
  7. 💥突然のDROP TABLE💥 • 正直勘弁してほしい • こんなときどうしますか…? • データの再import • S

    にすべてのログが保管されているので最悪やれなくはない • 数年分のデータを⼊れ直すのは時間的にきつい & やりたくない…
  8. 💥突然のDROP TABLE💥 • Snowflakeは標準で1⽇〜テーブルの履歴が時系列で維持されている • 削除も例外ではなく、削除という⾏為も戻すことが可能 • さらに履歴を維持する期間を超えたデータも7⽇間は「Fail Safe」という特別 な領域に保管され、ユーザは操作することができない

    • サポートにお願いするとそこから復元できたりするはず…? • サポートが介在しない限りユーザは触れないので混乱して危険な操作をすることがなさそう • バックアップの上に最終⼿段が⽤意されてるのはありがたい
  9. ALTER TABLE 〜 SWAP WITH • 初めて知ったときは感動しました • alter table系のクエリはトランザクションが効かない

    • テーブル洗い替え系の操作をしている瞬間にクエリが来るとタイミングが悪い とテーブルが存在しない • alter table 〜 swap with 〜をつかうとテーブルの⼊れ替えがatomicに • トランザクションができなくともテーブルのスワップが安全に!
  10. ログの集計(現状) • ログの量が数TB/day(圧縮状態) • 広告の集計処理は複雑になりがち • 集計ロジックを⾃前実装したい • テストコードが書きたい •

    分散処理がしたい • Apache Spark on Amazon EMR • クラスタコンピューティングフレームワーク • 分散共有メモリモデル • ScalaやPythonで処理が記述できる &.3$MVTUFS .BTUFS 4MBWF 4MBWF 4MBWF 4MBWF
  11. Apache SparkのSnowflake Driver • Apache Spark: クラスタコンピューティングフレームワーク • 集計はApache Sparkを使って256コア,

    512GB程度のクラスタで実⾏ • データソースとしてSnowflakeを使うことで集計対象のデータ抽出や簡単な 前処理をSnowflakeに寄せることができる https://docs.snowflake.com/ja/user-guide/spark-connector-overview.html