データ分析基盤をSnowflakeとdbtを中心に据えたアーキテクチャにリニューアル

参考になった

レビュー投稿日の情報になります

セーフィー株式会社 / 大室昌也

プロジェクトマネージャ / 従業員規模: 301名〜500名 / エンジニア組織: 101名〜300名

最終更新日2025/03/04投稿日2025/03/05

ツールの利用規模

ツールの利用開始時期

事業形態

101名〜300名

2023年1月

B to B

B to C

ツールの利用規模

101名〜300名

ツールの利用開始時期

2023年1月

事業形態

B to B

B to C

アーキテクチャ

アーキテクチャの意図・工夫

AWSのリソース全般とSnowflakeのテーブル以外のリソースはTerraformで管理し、Snowflake のテーブル関連リソースはdbtで管理。コードの自動フォーマットと本番デプロイする仕組みをGitHub Actionsで構築。
- IaCとCI/CDにより、属人化予防とリリースサイクル高速化を実現。
Snowflakeは用途別（データ連携 / データ整形 / データ分析）で3アカウント作成し、Data Sharingでデータ共有する仕組みを構築。
- アカウントを分離することにより、権限管理の簡素化を実現。
dbtは開発環境にOSSのdbt Coreを採用し、本番環境にSaaSのdbt Cloudを採用。
- dbt Coreとdbt Cloudを使い分けることにより、dbt Cloudのランニングコストを抑制。

導入の背景・解決したかった問題

導入背景

社内のデータ分析・利活用を目的として、2021年頃からデータ分析基盤の構築が始まった。
私が入社した2022年頃のデータ分析基盤は、DWHにRedshift（DS2ノードタイプ）を使用し、素のPython / SQL / Shell Script等を組み合わせてデータパイプラインが構築されていた。しかし、下記のような課題を抱えており、データ量の増加やデータ分析ニーズの増加に答えるのが難しい状況となっていた。
- データモデルの複雑化・属人化
  - Redshift上のデータモデルは複雑化し、柔軟性に欠けていた。
  - データモデリング手法は特に採用されておらず、属人化が加速し、認知負荷が高い状態になっていた。
- スケーラビリティが低い
  - Redshift（DS2ノードタイプ）はワークロード毎にスペックの違うコンピュートリソースを割り当てたり、並列実行数に応じて動的にスケールイン / スケールアウトすることができなかったため、日次バッチの処理時間が線形的に増加する状況となっていた。
  - また、データの保存量に上限があり、定期的に過去データを削除するといった運用が必要となっていた。
- 障害発生時の調査や対応に時間が掛かる
  - RedshiftはTime Travel（SQLで特定時間の状態に遡れる機能）が存在せず、後述のようにデータリネージの把握が困難なこともあり、障害発生時の調査やリカバリ対応に時間が掛かっていた。
- データリネージの把握が困難
  - 各テーブルの依存関係が定義されておらず、データリネージの把握が困難なため、開発効率の低下を招いていた。
上記の課題を解決するべく、2023年に「データ分析基盤リニューアルPJ」がスタート。DWHはRedshiftからSnowflakeに移行し、データパイプラインはdbtとSnowflakeの機能（Snowpipe / Data Sharing）を中心に再構築。データモデルはDataVault 2.0やDimensional Modelingといったデータモデリング手法を採用し、抜本的な改善を進めた。

比較検討したサービス

Snowflakeと比較検討したクラウドDWH
- Redshift Serverless
  - お見送り理由：PJ開始当初は情報が殆どない点（Redshift Serverlessは2022年7月にGA）や、Snowflake / BigQueryよりWeb UIのユーザビリティが高くない点
- BigQuery
  - お見送り理由：S3の転送料が発生する点や、Snowflake / Redshiftよりクエリのコストコントロールが難しい点
dbtと比較検討したデータ変換ツール
- Dataform
  - お見送り理由：dbtより導入事例が少ない点や、エコシステムが充実していない点

選定理由

Snowflakeを選定した理由
- クラウドネイティブな設計による高いスケーラビリティを備えている点
- Time Travelによるバックアップ/リカバリが容易な点
- ウェアハウス（コンピュートリソース）の設定により、柔軟にクエリのコストコントロールが可能な点
- 豊富なデータ連携機能（Snowpipe / Data Sharing / External Table等）を備えている点
- AWSの同一リージョン通信であればS3転送料が発生しない点
- Marketplaceから多種多様なオープンデータを容易に取得できる点
- ユーザビリティの高いWeb UI（Snowsight）を備えている点
dbtを選定した理由
- テーブル間の依存関係（DAG: 有向非巡回グラフ）を自動解釈できる点
- データリネージやドキュメントを自動生成できる点
- DataVault 2.0対応パッケージ（AutomateDV）が存在する点
- Snowflakeとの組み合わせ事例が豊富な点

導入の成果

日次バッチの処理時間が約7時間から約2.5時間に短縮
データリネージやTime Travelにより、迅速なリカバリ対応が可能に
データリネージやドキュメント自動生成、マクロや各種パッケージの活用により、開発効率が向上
Marketplaceのオープンデータ活用により、汎用的なマスタデータ（カレンダーマスタ等）の実装が容易に

導入に向けた社内への説明

上長・チームへの説明

正式導入前にPoCを実施し、既存システムからの移行可能性と優位性を確認。
当時のデータ分析基盤が抱えていた課題と解決策およびPoCの結果を企画書にまとめ、直属の上司とCTOに説明。以前から課題感を共有していたこともあり、特に異論は無く正式導入が決定。

活用方法

よく使う機能

Snowflake
- Snowsight
- Snowpipe
- Data Sharing
- Time Travel
- Marketplace
dbt
- ジョブスケジューリング
- マクロ
- ephemeralモデル
- テスト機能全般
- データリネージの可視化

ツールの良い点

アップデートが多い点
- Snowflake / dbt共に機能改善や機能強化のアップデートが頻繁に行われており、日々便利になっているのを実感できる。
コミュニティが活発な点
- Snowflake / dbt共にコミュニティが活発なため、情報収集がし易いのは勿論、組み合わせ可能なOSSのツールやパッケージも多数開発されている。

ツールの課題点

Snowflakeのウェアハウスの課金が1分単位な点
- 1秒単位であればランニングコストを大幅に抑制できるため。
Snowsight（Snowflake Web UI）のダッシュボード機能が弱い点
- チャートの種類が少なかったり、色のカスタマイズができなかったりと、ビジュアル表現の制約が大きいため。