Snowflakeの導入効果をレビューでご紹介(越境-株式会社Algoage)

導入以前はAmazon Athena+AWS Glue+S3により構成されるHive基盤を利用していたが、以下のような課題があった

• Amazon Athenaに関して
  • パーティション数の制限により、将来的に利用できなくなることが確定していた
  • クエリエディタとして使いづらかった
• AWS Glueに関して
  • Glue Jobのコードを1人しか書けず、属人化が発生していた
  • 低い開発者体験からくる開発効率の低さが深刻だった
• 全体的に、エラーが頻繁に起きて運用や開発がしづらい構成だった
  • Hive関連のエラーが多発する状況

詳しくは以下のブログを参照してください。 https://tech.algoage.dmm.com/entry/2023/08/21/221045

これらの課題を解決するため、データ分析基盤をフルリプレイスする決定をした。その過程で、データウェアハウスとして何を使うか決定する必要があった。

• Google BigQuery
• Amazon Redshift

• バックエンドで使用していたAWSとの相性が良かった
• 運用が楽であり、開発者体験を高めることができた
• ユーザーサポートの品質が高いとの評判があった

vs Redshifit

以下の観点で、比較にならないほどSnowflakeが優れていた

• チューニングのしやすさ
• 運用のしやすさ
• 開発のしやすさ
• コスト

なお、ごく一部のユースケースでは、コンピューティングリソースとストレージが分離していないRedshiftに軍配が上がる。しかし、弊社の場合はそのユースケースに該当しないと判断した。

vs BigQuery

バックエンド環境がAWSであったため、AWS上でも動作するSnowflakeに軍配が上がった。また、マイクロパーティショニング機能によりテーブル設計時のコストが下がるのも魅力だった。

導入自体はスムーズであり、政治的な意味で苦労することはなかった。理由は以下の2つ。

• 事前にチームへの頭出しや、関係者への根回しを行っていたから
• 30日間・400ドル分のトライアル用クレジットがコストの見積もりを可能にしたため、金銭的なリスクを下げることができたから

Snowflake自体は扱いやすいサービスであり、学習コンテンツも充実していたため習得は容易だった。

• まず自分が学習して習得する
• そののちに勉強会を実施したり、移行作業の一部を分担してもらったりして、チーム内へのスキル普及に務めた

1. SQLインターフェースの外部解放
   • 現在は環境が整っていないため、データ分析チームとごく一部の他チームのみがSnowflakeを利用している状況である
   • ガバナンス環境の整備を通じて、SQLを発行するインターフェースを徐々に開放していきたい。
2. データパイプラインの「ラストワンマイル」の強化
   • データウェアハウスからデータをユーザーに届ける最後の部分は、現在主にダッシュボードとアナリストによる手動抽出で実施している状況
   • この状態のままだと規模が大きくなった際に人手が足らず、データのデリバリー速度に悪影響が出る
   • Streamlitを用いたアプリケーションの構築などを通じて、データパイプラインの「ラストワンマイル」を整備していく計画を実行していく

• 何のために使うのか目的を見失うことなく、筋の通った意思決定をしてほしい
  • データウェアハウスを選定するうえでは、データパイプライン全体を見据えた包括的な意思決定が必要となります。データウェアハウス単体ではなく、例えばTransformationの部分で何を使うのか、データソースは何なのかなど、様々な条件を考慮したうえでの決定が必要です。
  • Snowflakeは素晴らしいツールです。が、たまたま自分たちがその条件に当てはまったのが実際のところだと考えています。
  • 視野を広く持ち、データパイプラインで何を成し遂げたいのか、確実に満たす必要があるMustの条件は何か、できれば満たしたいWantの条件は何か、設計思想としてどうあるべきかを明確に言語化し、ドキュメントに記録しながら判断していくなど、技術選定の勘所を持てるといいと思います。
  • ツール・ドリブンな意思決定はせず、目的を必ず忘れないようにするのをお勧めします。