Amazon redshift: insertion en vrac vs copie à partir de s3
j'ai un cluster redshift que j'utilise pour certaines applications d'analyse. J'ai des données entrantes que je voudrais ajouter un clicks tableau. Disons que j'ai ~10 nouveaux "clics" que je veux stocker chaque seconde. Si possible, j'aimerais que mes données soient disponibles dès que possible dans le redshift.
D'après ce que j'ai compris, à cause du stockage en colonnes, la performance d'insertion est mauvaise, donc vous devez insérer par lots. Mon workflow est de stocker les clics dans redis, et chaque minute, J'insère les ~600 clics de redis à redshift comme un lot.
j'ai les moyens de l'insertion d'un lot de clics en redshift:
Multi-row insert strategy: j'utilise uninsertrequête pour insérer plusieurs lignes. Multi-ligne d'insérer de la documentation iciS3 Copy strategy: je copie les lignes s3clicks_1408736038.csv. Puis-je exécuter unCOPYpour le charger dans leclickstableau. copier la documentation ici
j'en ai fait tests (cela a été fait sur un clicks table 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 voir, en termes de performance, il semble que je ne gagne rien en copiant d'abord les données dans s3. upload+ copy le temps est égal au insert fuseau.
Questions:
Quels sont les avantages et les inconvénients de chaque approche ? Quelle est la meilleure pratique ? Ai-je raté quelque chose ?
et question subsidiaire: est-il possible pour redshift COPY les données automatiquement à partir de s3 via un manifeste ? Je veux dire copier les données dès qu'elles sont nouvelles .csv les fichiers sont ajoutés dans s3 ? Doc ici et ici. Ou dois-je créer moi-même un travailleur d'arrière-plan pour déclencher les commandes de copie ?
Mon analyse rapide:
dans la documentation sur la cohérence, il n'est pas question de charger les données via des inserts à plusieurs rangées. Il ressemble à l' le moyen privilégié est COPYing à partir de s3 avec unique clés de l'objet (chaque .csv sur s3 a son propre nom)...
S3 Copy strategy:- pour: cela ressemble à la bonne pratique des docs.
- CONS: plus de travail (je dois gérer des seaux et des manifestes et un cron qui déclenche le
COPYcommandes...)
Multi-row insert strategy- pour: moins de travail. Je peux appeler un
insertrequête de mon application code - contre: cela ne ressemble pas à un moyen standard d'importer des données. Ai-je raté quelque chose?
- pour: moins de travail. Je peux appeler un
4 réponses
Redshift est un DB analytique, et il est optimisé pour vous permettre d'interroger des millions et des milliards d'enregistrements. Il est également optimisé pour vous permettre d'ingérer ces enregistrements très rapidement dans Redshift en utilisant la commande COPY.
la conception de la commande COPY est de travailler avec le chargement parallèle de plusieurs fichiers dans les noeuds multiples du cluster. Par exemple, si vous avez un 5 Petit noeud (dw2.xl) cluster, vous pouvez copier des données 10 fois plus rapide si vous avez vos données est un nombre multiple de fichiers (20, par exemple). Il y a un équilibre entre le nombre de dossiers et le nombre de dossiers dans chaque dossier, car chaque dossier comporte de petits frais généraux.
cela devrait vous conduire à l'équilibre entre la fréquence de la copie, par exemple toutes les 5 ou 15 minutes et pas toutes les 30 secondes, et la taille et le nombre des fichiers d'événements.
un autre point à considérer est les 2 types de noeuds Redshift que vous avez, les noeuds SSD (dw2.xl et dw2.8xl) et les magnétiques (dx1.xl et dw1.8xl). Les SSD sont plus rapides en termes d'ingestion. Puisque vous êtes à la recherche de données très fraîches, vous préférez probablement exécuter avec les SSD, qui sont généralement moins coûteux 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 l'exécution de 2 clusters différents, un pour les données "chaudes" sur SSD avec les données de la semaine ou du mois dernier, et un pour les données "froides" sur les disques magnétiques avec toutes vos données historiques.
Enfin, vous n'avez pas vraiment besoin de télécharger les données dans S3, qui est la majeure partie de votre ingestion de timing. Vous pouvez copier les données directement depuis vos serveurs en utilisant L'option Copier SSH. Voir plus d'informations à ce sujet ici: http://docs.aws.amazon.com/redshift/latest/dg/loading-data-from-remote-hosts.html
si vous êtes capable de diviser vos Files D'attente Redis en plusieurs serveurs ou au moins plusieurs files d'attente avec des fichiers de log différents, vous pouvez probablement obtenir de très bons enregistrements par seconde vitesse d'ingestion.
un autre modèle que vous pourriez vouloir considérer pour permettre des analyses en temps quasi réel est L'utilisation D'Amazon Kinesis, le service de diffusion en continu. Il permet d'exécuter des analyses sur des données dans le délai de secondes, et dans le même temps préparer les données à copier dans Redshift d'une manière plus optimisée.
la copie S3 fonctionne plus rapidement en cas de charges de données plus importantes. lorsque vous avez par exemple des milliers-des millions d'enregistrements doivent être chargés sur redshift, alors S3 upload + copy fonctionnera plus rapidement que les requêtes insert.
S3 copie fonctionne en mode parallèle.
quand vous créez la table et insérez alors il y a limite pour la taille du lot. La taille maximale pour un seul SQL est de 16 Mo. Vous devez donc prendre soin de la taille du lot SQL (dépend de la taille de chaque requête insert)
la copie S3 applique automatiquement le codage ( compression) pour votre table. Lorsque votre table de création et faire la charge d'échantillon en utilisant la copie, alors vous pouvez voir la compression appliquée automatiquement.
mais si vous utilisez la commande insert pour commencer, vous ne remarquerez aucune compression appliquée qui résultera plus d'espace pour la table dans redshift et le temps de processus de requête lent dans certains cas.
si vous souhaitez utiliser des commandes insert, alors créer une table avec chaque colonne a appliqué des encodages pour économiser de l'espace et temps de réponse plus rapide.
il pourrait être utile de mettre en œuvre micro batching tout en effectuant des chargements en vrac vers Redshift. Cet article peut être intéressant à lire car il contient également d'autres techniques à suivre pour une meilleure performance de la commande de copie.
Mes résultats de test diffèrent un peu. Je chargeais le fichier CSV à Redshift à partir du bureau de Windows OS.
- Ligne insert a été le plus lent.
- l'insertion à plusieurs rangées était 5 fois plus rapide que l'insertion à une rangée.
- S3+COPY était 3 fois plus rapide que multi-ligne insert.
ce qui a contribué à un encart de copie en vrac S3+plus rapide.
- le fait que vous n'avez pas à analyser insérer la déclaration de la ligne CSV.
- le flux a été comprimé avant de télécharger en multipartie sur S3.
- LA COMMANDE DE COPIE était extrêmement rapide.
j'ai compilé tous mes résultats dans un script Python CSV_Loader_For_Redshift