Chargement de données (incrémentiel) dans Amazon Redshift, S3 vs DynamoDB vs Insert
J'ai une application Web qui doit envoyer des rapports sur son utilisation, je souhaite utiliser Amazon RedShift comme entrepôt de données à cette fin, comment dois-je collecter les données?
Chaque fois que l'utilisateur interagit avec mon application, je tiens à le signaler .. alors quand dois-je écrire les fichiers sur S3? et combien ? Ce que je veux dire, c'est: - Si vous n'envoyez pas les informations immédiatement, alors je pourrais les perdre à la suite d'une perte de connexion, ou d'un bug dans mon système pendant sa collecte et préparez-vous à être envoyé à S3 ... - Si j'écris des fichiers dans S3 à chaque interaction avec l'utilisateur, je me retrouverai avec des centaines de fichiers (sur chaque fichier a un minimum de données), qui doivent être gérés, triés, supprimés après avoir été copiés sur RedShift .. cette dose ne semble pas une bonne solution.
Qu'est-ce que je rate? Dois-je utiliser DynamoDB à la place, devrais-je utiliser une simple insertion dans Redshift à la place!?
Si j'ai besoin d'écrire les données dans DynamoDB, dois-je supprimer la table d'attente après avoir été copiée .. quelles sont les meilleures pratiques?
Dans tous les cas, quelles sont les meilleures pratiques pour éviter la duplication des données dans RedShift?
Appréciez l'aide!
Il est préférable de agréger les journaux d'événements avant de les ingérer dans Amazon Redshift.
Les avantages sont les suivants:
Vous utiliserez mieux la nature parallèle de Redshift; COPIER sur un ensemble de fichiers plus gros dans S3 (ou à partir d'une grande table DynamoDB) sera beaucoup plus rapide que INSERT ou COPY individuel d'un petit fichier.
Vous pouvez pré-trier vos données (surtout si le tri est basé sur l'heure de l'événement) avant de les charger dans Redshift. Cela améliore également les performances de votre charge et réduit le besoin de VIDE de vos tables.
Vous pouvez accumuler vos événements à plusieurs endroits avant de les agréger et de les charger dans Redshift:
Fichier local vers S3 - la façon la plus courante est d'agréger vos journaux sur le client/serveur et toutes les x Mo ou y minutes de les télécharger sur S3. Il existe de nombreux ajouts de journaux qui prennent en charge cette fonctionnalité, et vous n'avez pas besoin de modifier le code (par exemple, FluentD ou Log4J ). Cela ne peut être fait qu'avec la configuration du conteneur. L'inconvénient est que vous risquez de perdre certains journaux et ces fichiers journaux locaux peuvent être supprimés avant le téléchargement.
DynamoDB - comme @Swami l'a décrit, DynamoDB est un très bon moyen d'accumuler les événements.
Amazon Kinesis - le service récemment publié est également un bon moyen de diffuser vos événements depuis les différents clients et serveurs vers un central emplacement d'une manière rapide et fiable. Les événements sont classés par ordre d'insertion, ce qui facilite leur chargement ultérieur pré-trié vers Redshift. Les événements sont stockés dans Kinesis pendant 24 heures, et vous pouvez planifier la lecture depuis Kinesis et le chargement vers Redshift toutes les heures, par exemple, pour de meilleures performances.
Veuillez noter que tous ces services ( S3, SQS, DynamoDB et Kinesis) vous permettent de pousser les événements directement depuis les utilisateurs/appareils finaux, sans avoir à passer par un serveur Web intermédiaire. Cela peut considérablement améliorer la haute disponibilité de votre service (comment gérer une charge accrue ou une panne de serveur) et le coût du système (vous ne payez que ce que vous utilisez et vous n'avez pas besoin d'avoir des serveurs sous-utilisés uniquement pour les journaux).
Voir par exemple comment obtenir des jetons de sécurité temporaires pour les appareils mobiles ici: http://aws.Amazon.com/articles/461161549939949
Un autre ensemble important d'outils permettant une interaction directe avec ces services sont les divers SDK s. Par exemple pour Java , . NET , JavaScript , iOS et Android .
Concernant l'exigence de déduplication ; dans la plupart des options ci-dessus, vous pouvez le faire dans la phase d'agrégation, par exemple, lorsque vous lisez à partir d'un flux Kinesis, vous pouvez vérifier que vous n'avez pas de doublons dans vos événements, mais en analysant un grand tampon d'événements avant de mettre dans le magasin de données.
Cependant, vous pouvez également effectuer cette vérification dans Redshift. Une bonne pratique consiste à COPY les données dans des tables intermédiaires puis SELECT INTO une table bien organisée et triée.
Une autre meilleure pratique que vous pouvez implémenter est d'avoir une partition de table quotidienne (ou hebdomadaire). Même si vous souhaitez avoir une grande table d'événements longue, mais la majorité de vos requêtes s'exécutent sur une seule journée (le dernier jour, par exemple), vous pouvez créer un ensemble de tables avec une structure similaire (events_01012014, events_01022014, events_01032014 ...). Ensuite vous pouvez SELECT INTO ... WHERE date = ... à chacun de ces tableaux. Lorsque vous souhaitez interroger les données de plusieurs jours, vous pouvez utiliser NION_ALL .
Une option à considérer consiste à créer des tables de séries chronologiques dans DynamoDB où vous créez une table chaque jour ou chaque semaine dans DynamoDB pour écrire chaque interaction utilisateur. À la fin de la période (jour, heure ou semaine), vous pouvez copier les journaux sur Redshift.
Pour plus de détails, sur le tableau des séries chronologiques DynamoDB, voir ce modèle: http://docs.aws.Amazon.com/amazondynamodb/latest/developerguide/GuidelinesForTables.html#GuidelinesForTables.TimeSeriesDataAccessPatterns
et ce blog:
http://aws.typepad.com/aws/2012/09/optimizing-provisioned-throughput-in-Amazon-dynamodb.html
Pour la copie Redshift DynamoDB: http://docs.aws.Amazon.com/amazondynamodb/latest/developerguide/RedshiftforDynamoDB.html
J'espère que cela t'aides.
Vous pouvez écrire des données dans un fichier CSV sur le disque local, puis exécuter le script Python/boto/psycopg2 pour charger les données dans Amazon Redshift.
Dans mon CSV_Loader_For_Redshift je fais juste cela:
Compressez et chargez les données dans S3 en utilisant boto Python et téléchargement en plusieurs parties).
conn = boto.connect_s3(AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY) bucket = conn.get_bucket(bucket_name) k = Key(bucket) k.key = s3_key_name k.set_contents_from_file(file_handle, cb=progress, num_cb=20, reduced_redundancy=use_rr )Utilisez psycopg2 commande COPY pour ajouter des données à la table Redshift.
sql=""" copy %s from '%s' CREDENTIALS 'aws_access_key_id=%s;aws_secret_access_key=%s' DELIMITER '%s' FORMAT CSV %s %s %s %s;""" % (opt.to_table, fn, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY,opt.delim,quote,gzip, timeformat, ignoreheader)
Bien qu'il y ait déjà une réponse acceptée ici, AWS a lancé un nouveau service appelé Kinesis Firehose qui gère l'agrégation selon des intervalles définis par l'utilisateur, un téléchargement temporaire vers s3 et le téléchargement (SAVE) vers redshift, retries et gestion des erreurs, gestion du débit, etc ...
C'est probablement le moyen le plus simple et le plus fiable de le faire.
Être juste un peu égoïste ici et décrire exactement ce que fait Snowplow , une plate-forme d'analyse d'événements. Ils utilisent cette façon unique et impressionnante de collecter les journaux d'événements du client et de les agréger sur S3.
Ils utilisent Cloudfront pour cela. Ce que vous pouvez faire est d'héberger un pixel dans l'un des compartiments S3 et de placer ce compartiment derrière une distribution CloudFront en tant qu'origine. Activez les journaux dans un compartiment S3 pour le même CloudFront.
Vous pouvez envoyer des journaux en tant que paramètres d'URL chaque fois que vous appelez ce pixel sur votre client (similaire à Google Analytics). Ces journaux peuvent ensuite être enrichis et ajoutés à la base de données Redshift à l'aide de Copy.
Cela résout le but de l'agrégation des journaux. Cette configuration gérera tout cela pour vous.
Vous pouvez également consulter Piwik qui est un service d'analyse open source et voir si vous pouvez le modifier en fonction de vos besoins.