BigQuery+RedShiftの経験から見るSnowflakeの真価

このスライドは以下のイベントの登壇資料です。

SNOWFLAKE TECHNICAL ROUNDTABLE
What’s NEW in Global Technologies
〜グローバルにおけるデータ変革のトレンドをご紹介〜

1. BigQuery+RedShiftの経験から見る Snowflakeの真価 SNOWFLAKE TECHNICAL ROUNDTABLE What’s NEW in Global Technologies 〜グローバルにおけるデータ変革のトレンドをご紹介〜 村上 柊 @shu22203 CARTA HOLDINGS, fluct
2. 自己紹介 • しゅう ◦ 村上 柊 ◦ @shu22203 ◦ 新卒入社5年目 • 好きなもの ◦ Celeste ◦ ずっと真夜中でいいのに ◦ スノボー • 嫌いなもの ◦ データがズレること ◦ CASE式で頑張ってるSQL
3. 話すこと • とにかくロードが楽 • クラスタ管理が要らない嬉しさ • 運用してみて実感した良さ
4. 話さないこと • dbt, Fivetran など個別のツール周りの話 • データモデリングの話
5. fluct • メインはSSP事業 ◦ メディア向け広告配信プラットフォー ム • JSタグを貼るといい感じに広告が 出るシステム • 2010年スタートの国内最大級 SSP
6. 前提 • 広告プラットフォームなのでログの量がかなり多い ◦ 数億インプレッション / day 以上のオーダー ◦ オークション数となると 数十億 records / day ◦ TB 以上はあたりまえ • 動いているシステムの大半は AWS
7. 今まで BigQuery • 生のログ • 調査用途・速報データ用 • 雑に加工したデータを置いておける便利な場所 ◦ Looker Studio 便利だよね RedShift • ウェアハウス・マート層 • レポーティング・分析用途
8. 話すこと • とにかくロードが楽 • クラスタ管理が要らない嬉しさ • 運用してみて実感した良さ
9. とにかくまずロード • ELT rather than ETL ◦ https://www.getdbt.com/blog/etl-vs-elt ◦ とにかくまず1箇所にデータを集めて からデータ加工がしたい ▪ ETL だと加工ロジックの変更で不要な再ロードが発生する • 一度ロードしてしまえば、加工は dbt に任せられる ◦ https://www.getdbt.com
10. ※ 説明のために一部省略しています たいへん！！
11. AWS -> BigQuery へロードする面倒さ • S3 -> GCS へインターネットを経由したファイル転送 ◦ ネットワークコストがかかる ◦ ストレージコストも倍 • GCS のファイルを BigQuery へ MECE にロードする仕組み ◦ ロック、リトライ機構の整備 • クラウドサービスを跨いだ権限管理 ◦ GCP の IAM, みなさんうまく扱えていますか ...？ • (我々の場合) BigQuery -> RedShift へレポートデータとして集計する仕組み → 管理するものが増えて辛いんじゃ〜
12. ※ 説明のために一部省略しています たいへん！！
13. Snowflake 導入の結果...
15. Snowflake だと？ • Snowflake 自体が AWS (GCP / Azure) で動く • Snowpipe ◦ https://docs.snowflake.com/ja/user-guide/data-load-snowpipe-intro • S3 へファイルが置かれると、自動的に Snowflake にロード ◦ 計測サービスは、S3 へ正しいログを置くことだけ考えればよい • ロード時にメタデータも付与 ◦ ファイル名 ◦ パーティション ◦ ロード時刻 ◦ etc • どのファイルが入ったのかも明確
16. AWS内だけで完結する ようになった！ Snowflake managed な部分
17. ロードしたら後は加工するだけ dbt での例 半構造化データのクエリ https://docs.snowflake.com/ja/user-guide/querying-semistructured
18. 話すこと • とにかくロードが楽 • クラスタ管理が要らない嬉しさ • 運用してみて実感した良さ
19. Redshift • 結局クラスターにデータが依存する ◦ コンピューティングとストレージが真に分離されていない • 誰かが重いクエリを投げると他のサービスへの影響が出る • Redshift Serverless ◦ Datashare 周りの体験があまり良くない ◦ 作り直すと共有が消えたり • system update で予期せぬ問題が発生したりする... ◦ タイムゾーンがバグでズレたこともありました ◦ https://zenn.dev/mur0jas0n/articles/b00ec06b7f45b0 • UI が Snowflake に比べてつらい(後述)
20. Snowflake だと？ • Warehouse の概念 ◦ https://docs.snowflake.com/ja/user-guide/warehouses-overview • 役割(ロール)ごとにコンピューティングリソースを確保 ◦ loader ◦ dbt (transform) ◦ reporting ◦ developer, etc… • 使うときだけ立ち上がって勝手に落ちる ◦ サイズ x 利用時間 単位の課金でシンプル • 使う側の関心で欲しいサイズ(パワー)を決めるだけ
21. Warehouse 運用 今まではデータ加工の処理が重い時間帯や誰かが重いクエリを投げているときに、管 理画面などから利用しているレポートAPIが遅くなってしまう、といったことが起きていま した。 しかし現在では、データ加工用、社内レポーティング用、レポートAPI用などそれぞれに 独立したコンピューティングリソースが割り当てられるようになったため、APIの安定性向 上、速度改善にも繋がりました。
22. 話すこと • とにかくロードが楽 • クラスタ管理が要らない嬉しさ • 運用してみて実感した良さ
23. 運用してみて実感した良さ • ドキュメントがしっかりしている ◦ 当たり前のようで実はめちゃくちゃすごい • サポートとの相性がよい • Snowsight (ウェブインターフェース) がすごい • 細かいところでストレスを感じることがほぼ無い ◦ 当たり前品質が非常に高い
24. ドキュメント みなさんこんな経験ないですか？ • ドキュメントが読めない、機械翻訳が壊れてて意味不明 • ドキュメントの通りにやっても動かない ◦ 結局手探りで調整したり、サポートケース上げたり ... 安心してください。Snowflake なら素直に読めるし素直に動きます ほとんど全てのドキュメントに読める日本語が付いてます
25. サポートとの相性 • 我々のコミュニケーションスタイル ◦ Slackでラフにたくさん議論する。 ◦ 他のメンバーもたくさん割り込んでくる。 ◦ そのため1つの返事に数日またされるとかはとてもつらい。 → Snowflake サポートはすぐ返事が返ってくる。また後から割り込みもしてくれる。
26. サポートとの相性 • 溢れるビジネスパートナー感 ◦ 個々の課題に合った解決策を提案・一緒に考えてくれる。 ▪ よくあるパターンとして、テンプレ的なメッセージと公式ドキュメントだけ送られて終わってしま うケース ◦ ふんわり投下したぼやきなども拾ってくれる。 ◦ そして今実現できない場合はすぐに機能要望上げてくれる。 → Snowflake のことをめっちゃ詳しい人と一緒に働いている感覚になれる。
27. Snowsight (Load History) • ファイルからのロードで何行目でどのように死んだのかが一目瞭然
28. Snowsight (Usage) • どの計算リソースでどの程度お金が掛かっているのか一目瞭然 ◦ コスト感は大事
29. Snowsight (Query History) • 実行計画がめちゃくちゃわかりやすい • どこがボトルネックになっているか一目瞭然
30. 総じてストレスが少ない 今までの項目、一つ一つは大きな問題ではなくても、ちりつもで人間のリソースが奪わ れていったり、ストレスが蓄積することでやる気がだん無くなったり、プラットフォームに対 する信頼感が損なわれることに繋がります。 Snowflake では少なくとも今まで運用する中でプラットフォーム側起因で疲弊した記憶 がほとんど無く、解決するべき課題にフォーカスすることができています。 ただ terraform provider 周りはいい感じになって欲しい！
31. まとめ
32. 本質的ではない面倒事に巻き込まれずに 本来やるべき仕事に集中できる Snowflake は最高
33. https://cartaholdings.co.jp/engineering
34. ありがとうございました