Amazon AthenaからSnowflakeへの移行

ツール導入前の課題

• Athenaの環境を2020年に構築し、利用拡大に伴い厳しさが出てきた
  • 社内でもある程度活用されているが、応用的な分析には耐えられない
• パフォーマンスが固定なので、複雑な分析は作成時、閲覧時ともに待ち時間が長くなる
  • 複雑なクエリは10分待ちとかも…
• 加工した結果の保存先として別途RDSを使っているので、分析がしにくく管理に支障がある
  • AthenaではUPDATE文が実行できないため、delete & insertもしくは別DBに作る必要がある
  • 今後も加工したデータを保存するシーンが増えていくのが予想されるため運用負荷が高い
• メインのIoTデータはdelete & insertしたりと複雑な処理になっている
  • （時系列データかつ電波状況により遅延データがある中で、集計の都合上、生データに加えて前後の距離や時間の差分が必要なので、加工が必要）
  • 項目追加対応が結構大変
  • その他テーブルの変更対応も属人化しやすい状態

どのような状態を目指していたか

Athenaの構成を完全再現し、運用工数が下がり、将来性が上がるデータ基盤になること。

• Amazon Athena
• Redshift Serverless
• (BigQuery)

• 費用面：できれば既存と同じくらいに収まって欲しい
• Athena → (ETL) → RDSのETLをシンプルにしたい
• スペックを柔軟に変えられること
• 運用において属人性を減らしたい

• 勢いがあるので、一応比較したけどSnowflakeありきでやった部分は大きい
• Redshift Serverlessを一応触ったが、使いにくい & 課金が1分単位で微妙
• BigQueryに関してはデータはAWSにあるので、この2024年のタイミングで選定する理由が無い

改善したかった課題はどれくらい解決されたか

• 運用工数削減
  • 分析パイプラインがシンプルになった
    • RDSをデータマートとリバースETL用に2台あったのが1台に
    • Embulkの変換処理がSnowflake内になってシンプルに
    • 追加の分析テーブル作るのも楽
  • テーブルやカラムの追加もGlueよりは楽なような気がする
    • terraform化が後回しになっているのでこれから改善な部分もある
• 分析面
  • 適宜ウェアハウスを変えることで時短
  • データが1箇所にまとまったことでjoin等々しやすい
    • 今まで3箇所に別れていたのでRedashのquery_rezultsを駆使していた
• 分析の幅が広がる
  • マーケットプレイスから色んなデータが無料/有料 で使える
  • GISを始め豊富な関数+Athenaに比べ知見が多い
  • SnowflakeのコミュニティSnowVillageが活発
  • LLM/MLが使える（Snowflake Cortex）
  • SnowparkやStreamlit on Snowflakeが使える

AthenaからSnowflakeの移行において、大まかなアーキテクチャを公開している技術ブログはありましたが、サブシステムの利用の有無など細かい部分が異なり、実際の設定を行う部分は探り探り行う必要がありました。

具体的な内容は多いのでこちらをご参照ください。AthenaからSnowflakeへ移行するときの躓きポイント集

Cortexなどを活用し既存のデータを更に活用し事業に貢献できるデータ基盤にしていきたいです。