ストリーミング取り込み - Amazon Redshift

ストリーミング取り込み

ストリーミング取り込みでは、Amazon Kinesis Data Streams および Amazon Managed Streaming for Apache Kafka から Amazon Redshift Serverless でプロビジョニングされたビューまたは Amazon Redshift マテリアライズドビューにストリームデータを低レイテンシーかつ高速で取り込むことができます。データアクセスにかかる時間を短縮し、ストレージコストを削減することができます。Amazon Redshift でのマテリアライズドビューの作成 で説明しているように、Amazon Redshift クラスターまたは Amazon Redshift Serverless にストリーミング取り込みを設定することで、SQL ステートメントを使用して、マテリアライズドビューを作成できます。その後、マテリアライズドビューの更新を使用して、毎秒数百メガバイトのデータを取り込むことができます。これにより、外部データにすばやくアクセスできるので、更新が高速化されます。

データフロー

Amazon Redshift でプロビジョニングされたクラスターまたは Amazon Redshift Serverless サーバーレスワークグループが、ストリームコンシューマーです。マテリアライズドビューは、ストリームから読み込まれるデータのランディング領域であり、このデータは到着時に処理されます。例えば、JSON 値を消費し、使い慣れた SQL を使用して、マテリアライズドビューのデータ列にマッピングすることができます。マテリアライズドビューを更新すると、Redshift は、ビューの内容が Kinesisストリームの SEQUENCE_NUMBER または Kafka トピックの最後の Offset と同等になるまで、割り当てられた Kinesis データシャードまたは Kafka パーティションのデータを消費します。後続のマテリアライズドビューでは、以前の更新における最後の SEQUENCE_NUMBER からの読み取りデータが、ストリームデータまたはトピックデータと同等になるまで更新されます。

ストリーミング取り込みのユースケース

Amazon Redshift でのストリーミング取り込みのユースケースは、継続的に生成 (ストリーミング) され、その生成から短期間 (低レイテンシー) の内に処理する必要があるデータの処理を含みます。これは、ほぼリアルタイムの分析と呼ばれます。このためのデータソースは、IOT デバイス、システムテレメトリーデータ、またはビジー状態のウェブサイトやアプリケーションからのクリックストリームデータなど、さまざまなものがあります。

ストリーミング取り込みに関する考慮事項

ストリーミング取り込み環境を設定する際の、パフォーマンスと請求に関する重要な考慮事項とベストプラクティスを次に示します。

  • 自動更新の使用と有効化 - マテリアライズドビューに対する自動更新クエリは、他のユーザーワークロードと同様に扱われます。自動更新は、ストリームが到達するとデータをロードします。

    ストリーミング取り込み用に作成されたマテリアライズドビューでは、自動更新を明示的にオンにできます。これを行うには、マテリアライズドビュー定義で AUTO REFRESH を指定します。手動更新がデフォルトです。ストリーミング取り込み用の既存のマテリアライズドビューに自動更新を指定するには、ALTER MATERIALIZED VIEW を実行してオンにします。詳細については、「CREATE MATERIALIZED VIEW」または「ALTER MATERIALIZED VIEW」を参照してください。

  • ストリーミングの取り込みと Amazon Redshift Serverless — プロビジョニングされたクラスターでの Amazon Redshift ストリーミングの取り込みに適用されるのと同じセットアップと設定の手順が、Amazon Redshift Serverless でのストリーミング取り込みにも適用されます。自動更新やその他のワークロードによるストリーミングの取り込みをサポートするために必要なレベルの RPU で Amazon Redshift Serverless のサイズを設定することが重要です。詳細については、「Amazon Redshift Serverless の料金」を参照してください。

  • Amazon MSK クラスターとは異なるアベイラビリティーゾーンにある Amazon Redshift ノード - ストリーミング取り込みを設定すると、Amazon MSK のラック認識が有効になっている場合、Amazon Redshift は同じアベイラビリティーゾーンの Amazon MSK クラスターへの接続を試みます。すべてのノードが Amazon Redshift クラスターとは異なるアベイラビリティーゾーンにある場合、アベイラビリティーゾーン間のデータ転送コストが発生する可能性があります。これを回避するには、Redshift のプロビジョニングされたクラスターまたはワークグループと同じ AZ に少なくとも 1 つの Amazon MSK ブローカークラスターノードを保持します。

  • 更新の開始場所 - マテリアライズドビューを作成すると、最初の更新は TRIM_HORIZON Kinesis ストリームまたは Amazon MSK トピックのオフセット 0 から始まります。

  • データ形式 - サポートされるデータ形式は、VARBYTE からの変換が可能なデータ形式に限られます。詳細については、VARBYTE 型およびVARBYTE 演算子を参照してください。

  • テーブルへのレコードの追加 - 既存のソースマテリアライズドビューからターゲットテーブルに行を追加するには、ALTER TABLE APPEND を実行できます。これは、マテリアライズドビューがストリーミング取り込み用に設定されている場合にのみ機能します。詳細については、「ALTER TABLE APPEND」を参照してください。

  • TRUNCATE または DELETE の実行 - ストリーミング取り込みに使用するマテリアライズドビューからレコードを削除するには、次の 2 つの方法があります。

    • TRUNCATE — このコマンドは、ストリーミング取り込み用に設定されたマテリアライズドビューからすべての行を削除します。テーブルスキャンは行われません。詳細については、「TRUNCATE」を参照してください。

    • DELETE — このコマンドは、ストリーミング取り込み用に設定されたマテリアライズドビューからすべての行を削除します。詳細については、「DELETE」を参照してください。

ストリーミング取り込みに関するベストプラクティスとレコメンデーション

ストリーミング取り込みの設定方法に関するオプションが表示される場合があります。以下のベストプラクティスをお勧めします。これらは当社独自のテストに基づいており、データ損失につながる問題の回避に役立ちます。

  • ストリーミングされたデータから値を抽出する — マテリアライズドビュー定義の JSON_EXTRACT_PATH_TEXT 関数を使用して着信ストリーミング JSON を細断すると、パフォーマンスとレイテンシーに大きな影響を及ぼす可能性があります。具体的には、JSON_EXTRACT_PATH_TEXT を使用して抽出した列ごとに、着信 JSON が再解析されます。その後に、データ型の変換、フィルタリング、ビジネスロジックが続きます。例えば、JSON データから 10 列を抽出すると、各 JSON レコードは 10 回解析され、これには型変換と追加のロジックが含まれます。その結果、取り込みのレイテンシーが長くなります。代わりに、JSON_PARSE 関数を使用して JSON レコードを Redshift の SUPER データ型に変換することをお勧めします。ストリーミングされたデータがマテリアライズドビューに表示されたら、PartiQL を使用して SUPER の JSON データ表現から個々の文字列を抽出します。詳細については、「半構造化データのクエリ」を参照してください。

    JSON_EXTRACT_PATH_TEXT のデータサイズの上限は 64 KB であることにも注意してください。JSON レコードのサイズが 64 KB を超えると、JSON_EXTRACT_PATH_TEXT での処理エラーになります。

  • Amazon Kinesis Data Streams ストリームまたは Amazon MSK トピックを Amazon Redshift ストリーミング取り込みのマテリアライズドビューにマッピングする — 単一の Amazon Kinesis Data Streams ストリームや Amazon MSK トピックからデータを取り込むために、複数のストリーミング取り込みのマテリアライズドビューを作成することはお勧めしません。その理由として、各マテリアライズドビューは Kafka トピックの Kinesis Data Streams ストリームやパーティション内のシャードごとにコンシューマーを作成するためです。これにより、スロットリングや、ストリームまたはトピックのスループット超過が生じる場合があります。また、同じデータを複数回取り込むことになるため、コストが高くなる可能性もあります。ストリームやトピックごとに 1 つのストリーミングマテリアライズドビューを作成することをお勧めします。

    ユースケースで 1 つの KDS ストリームや MSK トピックから複数のマテリアライズドビューにデータを読み込む必要がある場合は、事前に AWS ビッグデータブログを参照してください。特に「Best practices to implement near-real-time analytics using Amazon Redshift Streaming Ingestion with Amazon MSK」が役立ちます。

Amazon S3 のデータのステージングとストリーミング取り込みの使用の比較

Amazon Redshift または Amazon Redshift Serverless にデータをストリーミングする複数のオプションがあります。よく知られているオプションには、このトピックで説明しているストリーミング取り込みと、Firehose を使用した Amazon S3 への配信ストリームのセットアップの 2 つがあります。以下のリストで、それぞれの方法を説明します。

  1. Kinesis Data Streams または Amazon Managed Streaming for Apache Kafka から Amazon Redshift または Amazon Redshift Serverless へのストリーミング取り込みでは、データを受信するためにマテリアライズドビューを設定する必要があります。

  2. Kinesis Data Streams を使用して Amazon Redshift にデータを配信し、Firehose を介してストリーミングするには、ソースストリームを Amazon Data Firehose に接続し、Firehose が Amazon S3 にデータをステージングするのを待つ必要があります。このプロセスでは、さまざまな長さのバッファ間隔でさまざまなサイズのバッチを使用します。Amazon S3 へのストリーミング後に、Firehose はデータをロードするための COPY コマンドを開始します。

ストリーミング取り込みでは、2 番目のプロセスで必要ないくつかの手順を省略できます。

  • ストリーミング取り込みでは、Kinesis Data Streams から Redshift データベースのマテリアライズドビューにデータを直接送信できるため、Amazon Data Firehose 配信ストリームにデータを送信する必要はありません。

  • ストリーミング取り込みデータは Redshift マテリアライズドビューに直接送信されるため、ストリーミングデータを Amazon S3 に入れる必要はありません。

  • マテリアライズドビュー内のデータはストリームから直接更新されるため、COPY コマンドを記述して実行する必要はありません。Amazon S3 から Redshift へのデータのロードはプロセスの一部ではありません。

ストリーミング取り込みは Amazon Kinesis Data Streams からのストリームと Amazon MSK からのトピックに限定されることに注意してください。Kinesis Data Streams から Amazon Redshift 以外のターゲットにストリーミングする場合、Firehose 配信ストリームが必要になることがあります。詳細については、「Amazon Data Firehose 配信ストリームへのデータの送信」を参照してください。

制限事項

機能または動作 説明
Kafka トピックの長さ制限

Kafka トピックの名前は 128 文字 (引用符は含まない) を超えることはできません。詳細については、「名前と識別子」を参照してください。

マテリアライズドビューでの増分の更新と JOIN

マテリアライズドビューは、増分的な保守が可能である必要があります。Kinesis や Amazon MSK では、24 時間または 7 日前のストリームやトピックの履歴は保持されないため、完全な再計算は不可能です。Kinesis または Amazon MSK では、より長いデータ保持期間を設定することができます。ただし、これによりメンテナンスとコストが増える可能性があります。また、現在、Kinesis Streams や Amazon MSK トピックで作成されたマテリアライズドビューでは、JOIN の使用はサポートされていません。ストリームやトピックでマテリアライズドビューを作成した後、別のマテリアライズドビューを作成して、ストリーミングのマテリアライズドビューと他のマテリアライズドビュー、テーブル、またはビューとの結合のために使用できます。

詳細については、「REFRESH MATERIALIZED VIEW」を参照してください。

レコード解析

Amazon Redshift のストリーミング取り込みでは、Kinesis プロデューサーライブラリ (KPL の重要なコンセプト) によって集計されたレコードの解析をサポートしていません。集計されたレコードは取り込まれますが、バイナリプロトコルのバッファデータとして格納されます。(詳細については「Protocol buffers」(プロトコルバッファ) を参照してください。) Kinesis へのデータのプッシュ方法によっては、この機能の無効化が必要となる場合があります。

解凍

VARBYTE では現在、解凍処理がサポートされていません。このため、圧縮データを含むレコードを Redshift でクエリすることはできません。データは、Kinesis ストリームまたは Amazon MSK トピックにプッシュする前に解凍してください。

レコードの最大サイズ

Amazon Redshift が Kinesis または Amazon MSK から取り込むことができるレコードフィールドの最大サイズは、1 MB をわずかに下回ります。動作の詳細は以下のとおりです。

  • VARBYTE の最大長 - VARBYTE タイプは、最大長 1,024,000 バイトのデータをサポートします。Kinesis はペイロードを 1MB に制限しているので、Base64 エンコーディングの後、すべての Kinesis データは Amazon Redshift によって取り込むことができます。

  • メッセージ制限 - Amazon MSK のデフォルト設定では、メッセージは 1 MB に制限されています。また、メッセージにヘッダーが含まれる場合、データ量は 1,048,470 バイトに制限されます。デフォルトの設定では、取り込みに問題はありません。ただし、Kafka、つまり Amazon MSK では最大メッセージサイズをより大きな値に変更できます。この場合、Kafka レコードのキーと値フィールドまたはヘッダーがサイズ制限を超える可能性があります。これらのレコードはエラーの原因となる可能性があり、取り込まれることはありません。

エラーレコード

データのサイズが最大サイズを超えているためにレコードを Redshift に取り込めない場合、そのレコードはスキップされます。この場合でも、マテリアライズドビューの更新は成功し、各エラーレコードのセグメントが SYS_STREAM_SCAN_ERRORS システムテーブルに書き込まれます。計算のエラーやタイプ変換によるエラーなど、ビジネスロジックに起因するエラーはスキップされません。マテリアライズドビュー定義にロジックを追加する前に、ロジックを注意深くテストして、これらを回避してください。

Amazon MSK マルチ VPC プライベート接続

Amazon MSK マルチ VPC プライベート接続は、現在 Redshift ストリーミングの取り込みではサポートされていません。代わりに、VPC ピアリングを使用して VPC に接続するか、AWS Transit Gateway を使用しセントラルハブを介して VPC およびオンプレミスネットワークに接続することができます。これらのいずれかにより、Redshift は Amazon MSK クラスターまたは別の VPC にある Amazon MSK サーバーレスと通信できるようになります。