12

次の構成で s3 にデータを配置するAWS Kinesis Firehose ストリームがあります。

S3 buffer size (MB)*       2
S3 buffer interval (sec)*  60

すべて正常に動作します。唯一の問題は、Firehose がデータのチャンクごとに 1 つの s3 ファイルを作成することです。(私の場合、スクリーンショットのように、毎分 1 つのファイルです)。時間の経過とともに、これは大量のファイルになります。1 日あたり 1440 ファイル、1 年あたり 525,000 ファイルです。

ここに画像の説明を入力

これは管理が困難です (たとえば、バケットを別のバケットにコピーする場合、すべてのファイルを 1 つずつコピーする必要があり、これには時間がかかります)。

2 つの質問:

  • Kinesis に古いファイルをグループ化/連結するように指示する方法はありますか? (たとえば、24 時間以上経過したファイルは、1 日 1 回のチャンクにグループ化されます)。
  • COPY redshiftCOPYのパフォーマンスは、多数の s3 ファイルから ing する場合と少数の s3 ファイルから行う場合にどのように影響しますか? これを正確に測定したことはありませんが、私の経験では、小さなファイルがたくさんある場合のパフォーマンスはかなり悪くなります。私が思い出す限り、大きなファイルを使用する場合、約 2M 行の COPY は約 1 分です。200 万行に多数の小さなファイル (～11k ファイル) が含まれる場合、最大 30 分かかります。

私の主な懸念事項は次の 2 つです。

  • redshift COPY パフォーマンスの向上 (s3 から)
  • 全体的な s3 ファイル管理の容易化 (バックアップ、あらゆる種類の操作)
4

3 に答える 3

7

最も簡単な解決策は、firehose のバッファ サイズと時間制限を増やすことです。最大 15 分で、1 日あたり 1440 ファイルを 1 日 96 ファイルに削減できます (もちろん、ファイル サイズの制限に達しない限り)。 ）。

それ以上に、Kinesis にはファイルを連結するものは何もありませんが、新しい Kinesis ファイルが作成されるたびに起動する S3 ライフサイクル イベントをセットアップし、独自のコードをいくつか追加することができます (EC2 で実行するか、サーバーレスにすることができます)。 Lambda で) 連結を自分で行います。

redshift の読み込みパフォーマンスについてコメントすることはできませんが、大したことではないと思います。もしそうであったか、そうなったとしても、AWS はパフォーマンスについて何かを行うのではないかと思います。これは彼らが設定した使用パターンだからです。

于 2016-04-28T20:48:10.880 に答える
1

ファイルの数が多すぎて処理できないという同様の問題に直面しました。役立つソリューションは次のとおりです。

i) サイズバッファを最大に増やします。(128MB)

ii) 時間バッファを最大に増やします。(900秒)

iii) 一度に 1 つのレコードを公開する代わりに、複数のレコードを 1 つにまとめて (行で区切って)、1 つの kinesis firehose レコードを作成します (KF レコードの最大サイズは 1000 KB です)。

iv) また、複数のキネシス ファイアホース レコードをクラブにまとめてバッチを形成し、次にバッチ プットを実行します。( http://docs.aws.amazon.com/firehose/latest/APIReference/API_PutRecordBatch.html )

これにより、公開される 1 つの s3 オブジェクトが : kinesis firehose ストリームが保持できるバッチの数になります。

お役に立てれば。

于 2016-05-19T08:35:40.480 に答える