Redshiftは「捨てずに溜め込む」DB 📊
RedshiftはデータウェアハウスとしてのDB。
複数システムからデータを集めて蓄積し、
分析に使う。
大容量データを経営判断に活かすことを BI（Business Intelligence） と呼ぶらしい。
特徴的なのは、
基本的に削除・更新をせず、追加がメインという運用スタイル。
過去データも消さずに溜め込み続けるから、
当然、必要な容量も膨大になる。
クラスター構成は「現場監督と作業員」
Redshiftのクラスターはこんな構成。
-
Leaderノード
タスクをComputeノードに振り分ける司令塔 -
Computeノード
実際の処理を担当
さらに内部のノードスライス単位まで処理が細分化される
現場監督（Leader）が仕事を割り振って、
作業員（Compute）がさらに細かく分担してこなすイメージ。
カラムナ（列志向）データベースという発想
一般的なRDBは「行」単位でデータを管理するが、
Redshiftは 「列」単位 で管理する。
分析処理は「特定の列だけを大量に読む」ケースが多いので、
列単位で持っておいた方が効率がいい、という設計思想らしい。
S3とのやり取りが前提
データのロード・エクスポートはS3と連携して行う。
対応形式は、
- CSV / JSON などの構造化データ
- それらの圧縮ファイル
「分析するデータはまずS3に置く」という流れが、
AWSのデータ分析系サービス全体の共通言語になっている気がする。
バックアップ（＝スナップショット）の柔軟さ
- バックアップスケジュールは8時間/12時間などから設定可能
- 削除までの保持期間も設定可能
- 別リージョンへの保存も可能（クロスリージョンスナップショット）
「同じリージョンに置きっぱなし」にならないよう、
災害対策までちゃんと考えられている。
Redshift Serverlessは「運用の手離れ」担当
クラスターのノード管理やスケーリングをAWSが肩代わりしてくれる。
- インフラ運用コストを最小化
- 使用量に応じた従量課金
「今後どれくらい使うか読めない」という状況でも、
コストを無理なく最適化できるのがポイント。
Redshift Spectrumは「取り込まずに覗き見る」仕組み
S3からのロードには時間がかかる、という課題を解決するのがSpectrum。
S3上のデータを取り込まずに、テーブルのように参照できる。
データを移動させなくても、その場で分析対象にできるのか…
「一旦Redshiftに入れてから分析」ではなく、
「S3に置いたまま分析窓口だけ用意する」という発想の転換。
Redshift MLはSQLだけで機械学習
機械学習モデルの作成・訓練・デプロイ・分析を行うサービス。
本来なら、
- SageMakerなどのMLサービス
- Pythonなどのプログラミング言語
の知識が必要になる場面だが、
SQLに慣れていれば学習プロセスを構築できるのが最大の特徴。
分析担当者がわざわざMLエンジニアに頼らなくても、
自分の得意な言語のまま機械学習に踏み込めるのは効率がいい。
まとめメモ ✍️
- Redshiftは追加前提のデータウェアハウス、BI用途の主役
- Leader/Computeノードで処理を分担する構成
- カラムナ型で分析に強い設計
- S3とのロード・エクスポートが基本動線
- バックアップは柔軟な間隔＆クロスリージョン対応
- Serverlessで運用コストを削減
- Spectrumは「取り込まず参照」で高速化
- MLはSQLだけで機械学習に手が届く
「とにかくデータを溜めて、あとから読み解く」という発想が、
RDS的なDBとはっきり違う世界線だと感じた回だった。