Amazon Redshift は、パッチ 198 以降、新しい Python UDF の作成をサポートしなくなります。既存の Python UDF は、2026 年 6 月 30 日まで引き続き機能します。詳細については、[ブログ記事](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)を参照してください。
# マテリアライズドビューへのストリーミング取り込み
このトピックでは、マテリアライズドビューを使用してストリーミングデータにすばやくアクセスする方法について説明します。
ストリーミング取り込みでは、[Amazon Kinesis Data Streams](https://aws.amazon.com//kinesis/data-streams/) や [Amazon Managed Streaming for Apache Kafka](https://aws.amazon.com//msk/) から、Amazon Redshift でプロビジョニングされたビューや Amazon Redshift Serverless データベースへの、低レイテンシーかつ高速のデータインジェストを行います。データは、目的に合わせて設定された Redshift マテリアライズドビューに到達します。このため、外部データへのアクセスが高速化されます。ストリーミング取り込みは、データアクセス時間を短縮し、ストレージコストを削減します。ストリーミング取り込みは、SQL コマンドの小さなコレクションを使用して、Amazon Redshift クラスターまたは Amazon Redshift Serverless ワークグループ用に設定できます。設定後は、マテリアライズドビューの更新ごとに、毎秒数百メガバイトのデータを取り込むことができます。
## ストリーミングサービスから Redshift へのデータフロー
これにより、ストリーミング取り込みの仕組みやプロセスで使用されるデータベースオブジェクトを理解しやすくなります。データは、データストリームプロバイダーから Amazon Redshift でプロビジョニングされたクラスターまたは Amazon Redshift Serverless ワークグループに直接流れます。Amazon S3 バケットなどの一時的な到着エリアはありません。プロビジョニングされたクラスターやワークグループは、ストリームコンシューマーです。Redshift データベースの場合、ストリームから読み取られたデータはマテリアライズドビューに到着します。データは到着時に処理されます。例えば、SQL を使用して JSON 値を消費し、マテリアライズドビューのデータ列にマッピングできます。マテリアライズドビューを更新すると、Redshift は、ストリームに伴ってビューが最新の状態になるまで、割り当てられた Kinesis データシャードまたは Kafka パーティションのデータを消費します。
Amazon Redshift ストリーミング取り込みのユースケースでは、データの継続的な生成と、生成時点からの短期間 (低レイテンシー) での処理が伴います。**これは、一般的に、ほぼリアルタイムの分析と呼ばれます。**ソースには、IT デバイス、システムテレメトリデバイス、ビジー状態のウェブサイトやアプリケーションからのクリックストリームデータなどが含まれます。
## パフォーマンス改善に向けたデータ解析のベストプラクティス
ストリーミング取り込みを設定する場合、受信データを解析する方法について、いくつかのオプションがあります。プラクティスには、データの到着時にビジネスロジックやフォーマットを実行することが含まれます。エラーやデータ損失を避けるため、以下のベストプラクティスをお勧めします。ベストプラクティスは、内部テストに基づくものであり、設定や解析の問題のトラブルシューティングを行う際に役立ちます。
+ **ストリーミングされたデータから値を抽出する** — マテリアライズドビュー定義で [JSON\$1EXTRACT\$1PATH\$1TEXT](https://docs.aws.amazon.com/redshift/latest/dg/JSON_EXTRACT_PATH_TEXT.html) 関数を使用してストリーミング JSON を解析または細分化すると、パフォーマンスとレイテンシーに大きな影響を及ぼす可能性があります。**具体的には、JSON\$1EXTRACT\$1PATH\$1TEXT を使用して抽出した列ごとに、着信 JSON が再解析されます。これに続けて、データ型の変換、フィルタリング、ビジネスロジックの計算が行われます。例えば、JSON データから 10 列を抽出すると、各 JSON レコードは 10 回解析されます (これには追加のロジックが含まれます)。その結果、取り込みのレイテンシーが長くなります。代わりに、[JSON\$1PARSE 関数](https://docs.aws.amazon.com/redshift/latest/dg/JSON_PARSE.html)を使用して JSON レコードを Redshift の SUPER データ型に変換することをお勧めします。ストリーミングされたデータがマテリアライズドビューに到着したら、PartiQL を使用して JSON データの SUPER 表現から個々の文字列を抽出します。詳細については、「[半構造化データのクエリ](https://docs.aws.amazon.com/redshift/latest/dg/query-super.html)」を参照してください。
さらに、JSON\$1EXTRACT\$1PATH\$1TEXT のデータサイズは最大 64 KB であることに注意してください。JSON レコードのサイズが 64 KB を超えると、JSON\$1EXTRACT\$1PATH\$1TEXT での処理エラーになります。
+ **Amazon Kinesis Data Streams ストリームまたは Amazon MSK トピックを複数のマテリアライズドビューにマッピングする** — 単一のストリームやトピックからデータを取り込むために、複数のマテリアライズドビューを作成することはお勧めしません。その理由として、各マテリアライズドビューは Kafka トピックの Kinesis Data Streams ストリームやパーティション内のシャードごとにコンシューマーを作成するためです。これにより、スロットリングや、ストリームまたはトピックのスループット超過が生じる場合があります。また、同じデータを複数回取り込むことになるため、コストが高くなる可能性もあります。ストリーミング取り込みを設定する場合、ストリームやトピックごとに 1 つのマテリアライズドビューを作成することをお勧めします。
ユースケースで 1 つの KDS ストリームや MSK トピックから複数のマテリアライズドビューにデータを取り込む必要がある場合は、事前に [AWS Big Data Blog](https://aws.amazon.com/blogs/big-data/) の「[Amazon MSK で Amazon Redshift ストリーミング取り込みを使用して、ほぼリアルタイムの分析を実装するためのベストプラクティス](https://aws.amazon.com/blogs/big-data/best-practices-to-implement-near-real-time-analytics-using-amazon-redshift-streaming-ingestion-with-amazon-msk/)」を参照してください。
## ストリーミング取り込みの動作とデータタイプ
次の表では、データタイプ別の技術的な動作の詳細とサイズ制限について説明します。ストリーミング取り込み用にマテリアライズドビューを設定する前に、以下を理解しておくことをお勧めします。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/materialized-view-streaming-ingestion.html)