web-dev-qa-db-ja.com

Amazon Redshift：一括挿入とS3からのコピー

分析アプリケーションに使用するredshiftクラスターがあります。 clicksテーブルに追加したい着信データがあります。 1秒ごとに保存する新しい「クリック」を10個まで持っているとします。可能であれば、データをできるだけ早く赤方偏移で利用できるようにしたいと思います。

私が理解していることから、円柱状のストレージのため、挿入のパフォーマンスが悪いため、バッチで挿入する必要があります。私のワークフローはクリックをredisに保存することで、1分ごとにredisからredshiftに約600回のクリックをバッチとして挿入します。

クリックのバッチを赤方偏移に挿入する方法は2つあります。

私はいくつかのテストを行いました（これは既に200万行のclicksテーブルで行われました）：

             | multi-row insert stragegy |       S3 Copy strategy    |
             |---------------------------+---------------------------+
             |       insert query        | upload to s3 | COPY query |
-------------+---------------------------+--------------+------------+
1 record     |           0.25s           |     0.20s    |   0.50s    |
1k records   |           0.30s           |     0.20s    |   0.50s    |
10k records  |           1.90s           |     1.29s    |   0.70s    |
100k records |           9.10s           |     7.70s    |   1.50s    |

ご覧のとおり、パフォーマンスの観点では、最初にs3のデータをコピーしても何も得られないようです。 upload + copy時間はinsert時間と等しくなります。

質問：

各アプローチの長所と短所は何ですか？ベストプラクティスは何ですか？私は何かを見逃しましたか？

そして副質問：赤方偏移がマニフェストを介してs3からCOPYデータに自動的に可能ですか新しい.csvファイルがs3に追加されるとすぐにデータをコピーしますか？ Doc here および here 。または、COPYコマンドをトリガーするためにバックグラウンドワーカーを自分で作成する必要がありますか？

私のクイック分析：

整合性に関するドキュメント では、複数行の挿入を介したデータのロードに関する記述はありません。推奨される方法は、一意のオブジェクトキーを使用してs3からCOPYingするように見えます（s3の各.csvには独自の一意の名前があります）...

  • S3 Copy strategy：
    • 長所：ドキュメントの良い習慣のように見えます。
    • 短所：さらなる作業（バケットとマニフェスト、およびCOPYコマンドをトリガーするcronを管理する必要があります...）
  • Multi-row insert strategy
    • 長所：作業が少なくなります。アプリケーションコードからinsertクエリを呼び出すことができます
    • 短所：データをインポートする標準的な方法のように見えません。何か不足していますか？
amazon-s3amazon-redshift
37
Benjamin Crouzier

Redshiftは分析DBであり、数百万および数十億のレコードを照会できるように最適化されています。また、COPYコマンドを使用してこれらのレコードを非常に迅速にRedshiftに取り込むことができるように最適化されています。

COPYコマンドの設計は、クラスターの複数のノードに複数のファイルを並行してロードすることです。たとえば、5つの小さなノード（dw2.xl）クラスターがある場合、データが複数のファイル（たとえば20）であれば、データを10倍速くコピーできます。各ファイルには多少のオーバーヘッドがあるため、ファイル数と各ファイルのレコード数の間にはバランスがあります。

これにより、たとえば30秒ごとではなく5分または15分ごとなどのCOPYの頻度と、イベントファイルのサイズと数のバランスを取ることができます。

考慮すべきもう1つのポイントは、SSDのもの（dw2.xlおよびdw2.8xl）と磁気のもの（dx1.xlおよびdw1.8xl）の2種類のRedshiftノードです。 SSDの方が取り込みの点でも高速です。非常に新しいデータを探しているので、SSDで実行することをお勧めします。SSDは通常、500GB未満の圧縮データで低コストです。時間がたつにつれて500GBを超える圧縮データがある場合は、2つの異なるクラスターを実行することを検討できます。1つは先週または月のデータを持つSSDの「ホット」データ用、もう1つはすべての磁気ディスク上の「コールド」データ用です履歴データ。

最後に、データをS3にアップロードする必要はありません。これは、取り込みのタイミングの大部分です。 SSH COPYオプションを使用して、サーバーからデータを直接コピーできます。詳細については、こちらをご覧ください： http://docs.aws.Amazon.com/redshift/latest/dg/loading-data-from-remote-hosts.html

Redisキューを複数のサーバーに分割できる場合、または少なくともログファイルが異なる複数のキューに分割できる場合は、1秒あたりの取り込み速度が非常に優れている可能性があります。

ほぼリアルタイムの分析を可能にするために検討する必要があるもう1つのパターンは、ストリーミングサービスであるAmazon Kinesisの使用です。数秒の遅延でデータの分析を実行し、同時に、より最適化された方法でRedshiftにコピーするデータを準備できます。

40
Guy

S3コピーは、データのロードが大きい場合に高速に動作します。数千万のレコードをredshiftにロードする必要があると言った場合、s3 upload + copyはクエリを挿入するよりも速く動作します。

S3コピーは並列モードで機能します。

テーブルを作成して挿入すると、バッチサイズに制限があります。単一のSQLの最大サイズは16 MBです。そのため、SQLバッチのサイズに注意する必要があります（各挿入クエリのサイズに依存します）

S3コピーは、テーブルのエンコード（圧縮）を自動的に適用します。テーブルを作成し、コピーを使用してサンプルのロードを実行すると、圧縮が自動的に適用されることがわかります。

ただし、開始にinsertコマンドを使用している場合、圧縮が適用されないことに気付くでしょう。これにより、場合によっては、赤方偏移のテーブルのスペースが増え、クエリプロセスのタイミングが遅くなります。

挿入コマンドを使用する場合は、スペースを節約して応答時間を短縮するために、各列にエンコードが適用されたテーブルを作成します。

3
Sandesh Deshmane

Redshiftへの一括アップロードを実行しながら、マイクロバッチ処理を実装する価値があります。この記事には、COPYコマンドのパフォーマンスを向上させるために従うべき他のテクニックも含まれているため、読む価値があります。

http://blogs.aws.Amazon.com/bigdata/post/Tx2ANLN1PGELDJU/Best-Practices-for-Micro-Batch-Loading-on-Amazon-Redshift

2
Mohammed Idrees

私のテスト結果は少し異なります。 OS WindowsデスクトップからCSVファイルをRedshiftにロードしていました。

  • 行の挿入が最も遅かった。
  • 複数行の挿入は、行の挿入よりも5倍高速でした。
  • S3 + COPYは、複数行挿入よりも3倍高速でした。

バルクS3 + COPY挿入の高速化に貢献した理由。

  • CSV行から挿入ステートメントを解析する必要がないという事実。
  • S3へのマルチパートアップロードの前にストリームが圧縮されました。
  • COPYコマンドは非常に高速でした。

すべての調査結果を1つにまとめましたPython script CSV_Loader_For_Redshift

1
Alex B