まえがき
Redshiftへのストリームパイプラインの構成として様々な手法が存在すると思います。
本記事では新たな可能性としていくつかの手法が登場していきているので、それらを実際に動かして評価していきたいと思います。
執筆者の都合で大変申し訳ございませんが、12/3 正午 時点でまだ検証作業を続けている途中です。
記事は検証作業が全て完了次第、アップデートします。今しばらくお待ち下さい。
従来からある手法
1. データストリーム -> Kinesis Data Firehose (KDF) -> S3 -> ( COPYコマンド ) -> Redshift
S3上のデータ（のパス）を手組みのジョブ経由で Redshift に連携する、最もプリミティブな方式。
前回実行分との差分も管理が必要。
-
Pros
- 特になし ( 強いて言うなら自由度が高いぐらいか )
-
Cons
- ロードジョブの開発が必要 (イベントベースでSQSに取り込んでCOPYを実行する など)
- 前回実行分との差分も管理が必要
-
データ鮮度 (目安)
- 10分以内
2. データストリーム -> KDF -> Redshift
KDF から直接Redshiftに連携する方式。内部的にはCOPYが実行されている。参考
-
Pros
- Redshiftへのロード処理の実装が不要
-
Cons
- KDF のコスト
-
データ鮮度 (目安)
- 10分以内
新たな可能性
1. Redshift Spectrum を使う構成 ( データストリーム -> KDF -> S3 <- Redshift Spectrum
技術スタック自体は従来からあるものですが、ストリームパイプラインでの適用は検討されることが少ないのではないでしょうか。しかし、パフォーマンスが問題にならないケースにおいては Redshift Serverless と組み合わせることでコスパの良いニアリアル分析パイプラインが作れるのでは？という仮説から、本記事内での検証対象としております。
-
Pros
- Redshiftへのロードが不要
- コスパの良いニアリアル分析パイプライン
-
Cons
- クエリ応答速度が遅くなる
- ファイルサイズやパーティションのチューニングが必要
-
データ鮮度 (目安)
- 10分以内
2. データストリーム -> KDF -> S3 -> ( Auto COPY ) -> Redshift
2022/11/29 プレビューが公開れた。What’s New
定期実行するCOPYジョブが前回実行との差分を自動ロードしてくれるのでCOPYコマンドの管理が不要。
-
Pros
- ロードジョブを手組で作る必要が無い
- 差分ファイルを随時取り込んでくれる
-
Cons
- Previewのため、通常のCOPYと比較して多くの制限がある
-
データ鮮度
- 不明 (実際に検証してみる。)
3. データストリーム -> ( Redshift Streaming ) -> Redshift
これまで Preview として公開されていたが、2022/11/29 にようやくGAとなった。 What’s New
ストリームデータソースから直接取込み、Materialized View (MV) としてデータを保持する。Streaming for Apache Kafka (MSK) もサポートされている。また、追加コストなしでストリーミングデータのダウンストリーム処理および変換を実行することができる点も嬉しいポイント。
-
Pros
- ストリームから直接データを取り込むので他の手法に比べて圧倒的にリアルタイム性能が良い
- 追加費用なしなので、従来からある KDF を使った方式よりコスパが良い
-
Cons
- MVの更新が必要（自動更新 がどこまで使えるか検証）
- MV と他のテーブルの直接JOINができない(はず)ので、実体化が必要
- 実体化まで含めてのデータ鮮度となるとどこまでデータ鮮度が保てるか不明 (こちらも検証する)
-
データ鮮度
- データ鮮度は秒単位 (のはず)
1. Redshift Spectrum を使う構成
WIP
2. Auto-copy from Amazon S3 を使う構成
WIP
3. Real-time streaming ingestion for Amazon Kinesis Data Streams (KDS) を使う構成
WIP
まとめ
WIP