利用Redshift实现的流处理管道的新可能性

前言

我认为有很多方法可以配置用于将流式数据传送到Redshift的管道。
在本文中,我们将介绍一些新的可能性和方法,并对它们进行实际运行和评估。

由于作者的原因,非常抱歉,截至12月3日中午,验证工作仍在进行中。
文章将在验证工作全部完成后进行更新,请稍等片刻。

从过去一直存在的方法

1. 数据流 -> Kinesis数据Firehose(KDF) -> S3 -> (拷贝命令) -> 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 -> (自动拷贝) -> Redshift
2022/11/29 预览已发布。更新内容
定期执行的COPY任务会自动加载与上次执行的差异,无需管理COPY命令。

Pros

ロードジョブを手組で作る必要が無い
差分ファイルを随時取り込んでくれる

Cons

Previewのため、通常のCOPYと比較して多くの制限がある

データ鮮度

不明 (実際に検証してみる。)

3. 数据流 -> (Redshift实时流) -> Redshift
这个功能以前作为预览版发布,但直到2022年11月29日才正式推出。 新功能
可以直接从流数据源导入数据,并将其作为Materialized View(MV)保存。还支持Apache Kafka的流式处理(MSK)。此外,无需额外费用即可执行流数据的下游处理和转换,这也是一个令人高兴的特点。

Pros

ストリームから直接データを取り込むので他の手法に比べて圧倒的にリアルタイム性能が良い
追加費用なしなので、従来からある KDF を使った方式よりコスパが良い

Cons

MVの更新が必要(自動更新 がどこまで使えるか検証)
MV と他のテーブルの直接JOINができない(はず)ので、実体化が必要
実体化まで含めてのデータ鮮度となるとどこまでデータ鮮度が保てるか不明 (こちらも検証する)

データ鮮度

データ鮮度は秒単位 (のはず)

使用Redshift Spectrum的配置

未完成

使用Amazon S3进行自动复制的配置。

工作中

3. 使用Amazon Kinesis Data Streams(KDS)进行实时流式摄取的配置。

未完成

总结

进行中

广告
将在 10 秒后关闭
bannerAds