Amazon redshift: insertion en bloc vs COPY à partir de s3

Question

J'ai un cluster redshift que j'utilise pour certaines applications d'analyse. J'ai des données entrantes que je voudrais ajouter à une table clicks. Disons que j'ai ~ 10 nouveaux «clics» que je veux stocker chaque seconde. Si possible, j'aimerais que mes données soient disponibles le plus rapidement possible en redshift.

D'après ce que j'ai compris, en raison du stockage en colonnes, les performances d'insertion sont mauvaises. Vous devez donc les insérer par lots. Mon flux de travail consiste à stocker les clics dans redis et chaque minute, j'insère les ~ 600 clics de redis à redshift en tant que lot.

J'ai des façons d'insérer un lot de clics dans redshift:

• Multi-row insert strategy: J'utilise une requête insert régulière pour insérer plusieurs lignes. Documentation d'insertion sur plusieurs lignes ici
• S3 Copy strategy: Je copie les lignes de s3 en tant que clicks_1408736038.csv. Ensuite, je lance une COPY pour charger ceci dans la table clicks. COPIER la documentation ici

J'ai fait quelques tests (cela a été fait sur une table clicks avec déjà 2 millions de lignes):

             | 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    |

Comme vous pouvez le constater, en termes de performances, il semble que je ne gagne rien en copiant d’abord les données dans s3. Le temps upload + copy est égal au temps insert.

Des questions:

Quels sont les avantages et les inconvénients de chaque approche? Quelle est la meilleure pratique? Est-ce que j'ai manqué quelque chose ?

Et question secondaire: est-il possible pour redshift de COPY les données automatiquement à partir de s3 via un manifeste? Je veux dire COPIER les données dès que de nouveaux fichiers .csv sont ajoutés à s3? Doc ici et ici . Ou dois-je créer moi-même un travailleur d'arrière-plan pour déclencher les commandes COPY?

Mon analyse rapide:

Dans la documentation sur la cohérence , il n'est pas question de charger les données via des insertions sur plusieurs lignes. Il semble que la méthode préférée est COPYing from s3 avec des clés d'objet uniques (chaque .csv sur s3 a son propre nom unique) ...

• S3 Copy strategy:
  • Avantages: ressemble à la bonne pratique de la documentation.
  • CONS: Plus de travail (je dois gérer des seaux et des manifestes et un cron qui déclenche les commandes COPY ...)
• Multi-row insert strategy
  • Avantages: moins de travail. Je peux appeler une requête insert à partir de mon code d'application
  • CONS: ne ressemble pas à un moyen standard d'importer des données. Est-ce que je manque quelque chose?

Answer 1

Redshift est une base de données analytique optimisée pour vous permettre d'interroger des millions et des milliards d'enregistrements. Il est également optimisé pour vous permettre d’intégrer très rapidement ces enregistrements dans Redshift à l’aide de la commande COPY. 

La conception de la commande COPY doit fonctionner avec le chargement en parallèle de plusieurs fichiers dans les multiples nœuds du cluster. Par exemple, si vous avez un cluster de 5 petits nœuds (dw2.xl), vous pouvez copier des données 10 fois plus rapidement si vos données contiennent plusieurs fichiers (20, par exemple). Il y a un équilibre entre le nombre de fichiers et le nombre d'enregistrements dans chaque fichier, chaque fichier ayant une légère surcharge. 

Cela devrait vous amener à trouver un équilibre entre la fréquence de COPY, par exemple toutes les 5 ou 15 minutes et non toutes les 30 secondes, et la taille et le nombre des fichiers d'événements. 

Un autre point à considérer concerne les 2 types de nœuds Redshift que vous avez, les nœuds SSD (dw2.xl et dw2.8xl) et les nœuds magnétiques (dx1.xl et dw1.8xl). Les SSD sont également plus rapides en termes d'ingestion. Puisque vous recherchez des données très récentes, vous préférez probablement utiliser les données SSD, qui coûtent généralement moins cher pour moins de 500 Go de données compressées. Si, au fil du temps, vous avez plus de 500 Go de données compressées, vous pouvez envisager d'exécuter 2 clusters différents, un pour les données "chaudes" sur SSD avec les données de la semaine ou du mois écoulé, et un pour les données "à froid" sur des disques magnétiques avec vos données historiques. 

Enfin, vous n'avez pas vraiment besoin de télécharger les données dans S3, ce qui constitue la majeure partie de votre calendrier d'ingestion. Vous pouvez copier les données directement à partir de vos serveurs à l'aide de l'option SSH COPY. Voir plus d'informations à ce sujet ici: http://docs.aws.Amazon.com/redshift/latest/dg/loading-data-from-remote-hosts.html

Si vous êtes en mesure de fractionner vos files d'attente Redis sur plusieurs serveurs ou au moins plusieurs files d'attente avec différents fichiers journaux, vous pouvez probablement obtenir de très bons enregistrements par vitesse d'ingestion par seconde. 

L’utilisation d’Amazon Kinesis, le service de diffusion en continu, est un autre modèle que vous pouvez envisager d’autoriser l’analyse en temps quasi réel. Il permet d'exécuter des analyses sur des données en quelques secondes et, simultanément, de préparer les données à copier dans Redshift de manière plus optimisée. 

Answer 2

Il peut être intéressant de mettre en œuvre le microdosage lors de transferts groupés vers Redshift. Cet article mérite peut-être d'être lu car il contient également d'autres techniques à suivre pour une meilleure performance de la commande COPY.

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

Answer 3

La copie S3 fonctionne plus rapidement en cas de charges de données plus importantes. lorsque vous avez indiqué que des millions d’enregistrements doivent être chargés dans redshift, le téléchargement et la copie s3 fonctionneront plus rapidement que les requêtes d’insertion.

La copie S3 fonctionne en mode parallèle.

Lorsque vous créez une table et que vous insérez, la taille du lot est limitée. La taille maximale d'un SQL unique est de 16 Mo. Donc, vous devez prendre soin de la taille de SQL Batch (dépend de la taille de chaque requête d'insertion)

La copie S3 applique automatiquement le codage (compression) à votre table. Lorsque vous créez une table et que vous chargez des échantillons en utilisant copy, vous pouvez voir la compression automatiquement appliquée.

Cependant, si vous utilisez la commande insert pour commencer, vous ne remarquerez aucune compression qui entraînera plus d'espace pour la table dans redshift et un ralentissement du processus de requête dans certains cas.

Si vous souhaitez utiliser des commandes d'insertion, créez une table avec chaque colonne avec des codages appliqués pour économiser de l'espace et un temps de réponse plus rapide.

Answer 4

Mes résultats de test diffèrent un peu. Je chargeais un fichier CSV sur Redshift à partir du bureau Windows.

• L'insertion de ligne était la plus lente. 
• L'insertion sur plusieurs lignes était 5 fois plus rapide que l'insertion de ligne.
• S3 + COPY était 3 fois plus rapide que l'insertion sur plusieurs lignes.

Ce qui a contribué à une insertion plus rapide de la copie S3 + COPY.

• Le fait que vous ne devez pas analyser une instruction insert de la ligne CSV.
• Le flux a été compressé avant le téléchargement multipart vers S3.
• La commande COPY était extrêmement rapide.

J'ai compilé toutes mes découvertes dans un script Python CSV_Loader_For_Redshift