Concatenate s3-Dateien, wenn AWS Firehose mit

Question

Ich habe ein AWS Kinesis Firehose-Stream-Daten in s3 mit folgenden Konfiguration setzen:

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

Alles funktioniert gut. Das einzige Problem ist, dass Firehose eine s3-Datei für jeden Datenblock erstellt. (In meinem Fall eine Datei jede Minute, wie im Screenshot). Im Laufe der Zeit gibt es eine Menge Dateien: 1440 Dateien pro Tag, 525k Dateien pro Jahr.

Das ist schwer zu verwalten (zum Beispiel, wenn ich den Eimer in einen anderen kopieren möchte ich brauchen würde, jede einzelne Datei eins nach dem anderen, und dies würde einige Zeit dauern, kopieren).

Zwei Fragen:

• Gibt es eine Möglichkeit Kinesis zu einer Gruppe sagen/verketten alt zusammen Dateien. (Dateien, die älter als 24 Stunden sind, werden z. B. einen Tag lang in Gruppen zusammengefasst).
• Wie wirkt sich die COPY-Rotverschiebungsleistung aus, wenn COPY aus einer Vielzahl von s3-Dateien im Vergleich zu nur einigen wenigen gefunden wird? Ich habe das nicht genau gemessen, aber meiner Erfahrung nach ist die Performance mit vielen kleinen Dateien viel schlechter. Soweit ich mich erinnern kann, ist bei großen Dateien ein COPY von etwa 2 Millionen Zeilen ungefähr ~ 1 Minute. 2M Zeilen mit vielen kleinen Dateien (~ 11k Dateien), dauert es bis zu 30 Minuten.

Meine beiden wichtigsten Anliegen sind:

• Bessere Leistung Rotverschiebung COPY (von s3)
• Einfachere Gesamt s3 Dateiverwaltung (Backup, Manipulation jeglicher Art)

Answer 1

Der einfachste Das Problem besteht darin, die Puffergröße und das Zeitlimit zu erhöhen - Sie können bis zu 15 Minuten pro Tag auf bis zu 96 Dateien pro Tag reduzieren (es sei denn, Sie haben die maximale Dateigröße erreicht).

Darüber hinaus gibt es in Kinesis keine Dateien, die die Dateien für Sie darstellen. Sie können jedoch ein S3-Lebenszyklusereignis einrichten, das bei jeder Erstellung einer neuen Kinesis-Datei ausgelöst wird EC2 oder gehen Sie serverbasiert mit Lambda) und führen Sie die Verkettung selbst durch.

Ich kann die Rotverschiebungs-Ladeperformance nicht kommentieren, aber ich vermute, dass es keine große Sache ist. Wenn es einer war oder werden wird, vermute ich, dass AWS etwas an der Performance vornehmen wird, da dies das von ihnen eingerichtete Nutzungsmuster ist.

Answer 2

Kinesis Firehose wurde entwickelt, um die Verarbeitung von Ereignissen in Echtzeit zu ermöglichen. Es ist für solche Anwendungsfälle optimiert und Sie haben daher solche Einstellungen wie kleinere und häufigere Dateien. Auf diese Weise erhalten Sie die Daten schneller für Abfragen in Redshift oder häufigere Aufrufe von Lambda-Funktionen für die kleineren Dateien.

Es ist sehr üblich für Kunden des Dienstes, auch die Daten für längere historische Abfragen vorzubereiten. Auch wenn es möglich ist, diese langfristigen Abfragen auf Redshift auszuführen, könnte es sinnvoll sein, EMR für diese Abfragen zu verwenden. Sie können dann Ihren Redshift-Cluster auf die populäreren jüngsten Ereignisse einstellen (z. B. einen "heißen" Cluster für 3 Monate auf SSD und einen "kalten" Cluster für 1 Jahr auf HDD).

Es macht Sinn, dass Sie das kleinere nehmen (unkomprimiert?) Dateien in der Firehose-Ausgabe S3-Bucket, und übertragen Sie sie in ein EMR (Hadoop/Spark/Presto) optimiertes Format. Sie können Dienste wie S3DistCp oder eine ähnliche Funktion verwenden, die die kleinere Datei übernimmt, sie verkettet und ihr Format in ein Parquet-Format umwandelt.

In Bezug auf die Optimierung für die Redshift COPY gibt es ein Gleichgewicht zwischen der Zeit, die Sie die Ereignisse zusammengeführt und der Zeit, die es dauert, sie zu kopieren. Es ist wahr, dass es beim Kopieren nach Redshift besser ist, größere Dateien zu haben, da für jede Datei ein kleiner Aufwand entsteht. Wenn Sie die Daten jedoch nur alle 15 Minuten kopieren, haben Sie möglicherweise "ruhige" Zeiten, in denen Sie das Netzwerk nicht nutzen, oder die Fähigkeit der Cluster, Ereignisse zwischen diesen COPY-Befehlen zu erfassen. Sie sollten die Balance finden, die für das Geschäft gut ist (wie frisch brauchen Sie Ihre Ereignisse) und die technischen Aspekte (wie viele Ereignisse können Sie in einer Stunde/Tag zu Ihrer Redshift aufnehmen).

Answer 3

Ich konfrontiert ein ähnliches Problem, wo die Anzahl der Dateien zu viele waren, um damit umzugehen. Hier ist eine Lösung, die nützlich sein kann:

i) Erhöhen Sie die Größe Puffer auf max. (128 MB)

ii) Erhöhen Sie den Zeitpuffer auf max. (900 Sekunden)

iii) Anstatt einen Datensatz zu einem Zeitpunkt zu veröffentlichen, mehrere Datensätze in einen zusammenfassen (durch Trennung durch eine Linie), um einen Kinesis-Firehose-Datensatz zu erstellen (maximale Größe eines KF-Datensatzes: 1000 KB).

iv) Vereinbaren Sie auch mehrere Kinesis-Firehose-Datensätze, um eine Charge zu bilden und dann eine Charge zu setzen. (http://docs.aws.amazon.com/firehose/latest/APIReference/API_PutRecordBatch.html)

Dadurch wird ein s3-Objekt veröffentlicht: Anzahl der Stapel, die der Kinesis-Firehose-Stream enthalten kann.

Hoffe, das hilft.