Chargement des données (par incrément) dans Amazon Redshift, S3 vs DynamoDB vs Insert
j'ai une application web qui doit envoyer des rapports sur son utilisation, je veux utiliser Amazon RedShift comme un entrepôt de données à cet effet, Comment collecter les données ?
chaque fois que l'utilisateur interagit avec mon application, je veux le signaler.. alors Quand dois-je écrire les fichiers à S3 ? et de combien ? Ce que je veux dire, c'est: - Si ne pas envoyer l'information immédiatement, alors je pourrais la perdre à la suite d'une connexion perdue, ou à partir d'un bug dans mon système alors qu'il a été collecté et se préparer à être envoyé à S3... - Si j'écris des fichiers à S3 sur chaque interaction utilisateur, je finirai avec des centaines de fichiers (sur chaque fichier a des données minimales), qui doivent être gérés, triés, supprimés après avoir été copiés sur RedShift.. cette dose ne semble être une bonne solution .
Ce qui me manque? Si J'utilise plutôt DynamoDB, devrais-je utiliser simple insert dans Redshift à la place !?
Si j'ai besoin d'écrire les données sur DynamoDB, devrais-je supprimer la table hold après avoir été copiée .. quels sont les meilleures pratiques en la matière ?
dans tous les cas, quelles sont les meilleures pratiques pour éviter la duplication des données dans RedShift ?
Apprécions l'aide!
5 réponses
il est préféré à agrégation journal d'événements avant de les ingérer dans Amazon Redshift.
Les avantages:
Vous allez utiliser le parallèle la nature de Redshift mieux; COPY sur un ensemble de fichiers plus grands dans S3 (ou à partir D'une grande table DynamoDB) sera beaucoup plus rapide QU'un INSERT individuel ou une copie d'un petit fichier.
Vous pouvez pré-tri vos données (surtout si le tri est basé sur le temps de l'événement) avant de le charger dans Redshift. Cela permet également d'améliorer vos performances de charge et de réduire 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 à S3 - le moyen le plus commun est d'agréger vos logs sur le client / serveur et toutes les X MB ou y minutes upload à S3. Il y a beaucoup de log appenders qui prennent en charge cette fonctionnalité, et vous n'avez pas besoin de faire des modifications dans le code (par exemple, FluentD ou Log4J). Cela peut être fait uniquement 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 de le télécharger.
DynamoDB - comme @Swami l'a décrit, DynamoDB est un très bon moyen d'accumuler les événement.
Amazon Kinesis - le service récemment publié est également un bon moyen de diffuser vos événements à partir des différents clients et serveurs vers un emplacement central d'une manière rapide et fiable. Les événements sont dans l'ordre d'insertion, ce qui rend facile de le charger plus tard pré-trié à Redshift. Les événements sont stockés dans Kinesis pendant 24 heures, et vous pouvez programmer la lecture de kinesis et de chargement à Redshift toutes les heures, par exemple, pour de meilleures performances.
veuillez noter que tous ces services ( S3, SQS, DynamoDB et Kinesis) vous permettent de poussez les événements directement des utilisateurs/périphériques finaux, sans passer par un serveur web intermédiaire. Cela peut améliorer considérablement la haute disponibilité de votre service (comment gérer la charge accrue ou la défaillance du serveur) et le coût du système (vous ne payez que pour ce que vous utilisez et vous n'avez pas besoin d'avoir des serveurs sous-utilisés juste pour les journaux).
http://aws.amazon.com/articles/4611615499399490un Autre ensemble important d'outils permettant une interaction directe avec ces services sont différents SDKs. Par exemple pour Java, .NET, JavaScript, iOS et Android.
Quant à la dé-duplication exigence; dans la plupart des options ci-dessus, vous pouvez faire cela 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 duplications dans vos événements, mais analyser un grand tampon d'événements avant de mettre dans la mémoire.
Cependant, vous pouvez faire cette vérification dans Redshift. Une bonne pratique est d' COPY les données dans des tables de stadification et puis SÉLECTIONNER une bien organisé et le tableau trié.
une autre meilleure pratique que vous pouvez mettre en œuvre est d'avoir une partition de table quotidienne (ou hebdomadaire). Même si vous souhaitez avoir une grande table d'événements longs, mais la majorité de vos requêtes tournent sur un seul jour (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 = ... pour chacune de ces tables. Lorsque vous voulez interroger les données à partir de plusieurs jours, vous pouvez utiliser UNION_ALL.
une option à considérer est de créer des tables de séries chronologiques dans DynamoDB où vous créez une table chaque jour ou semaine dans DynamoDB pour écrire chaque interaction utilisateur. À la fin de la période (jour, heure ou semaine), vous pouvez copier les logs sur Redshift.
pour plus de détails, sur le tableau des séries chronologiques de DynamoDB voir ce schéma: 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 Redshift DynamoDB copie: http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/RedshiftforDynamoDB.html
espérons que ceci aider.
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 (enregistrer) vers redshift, la manipulation des réts et des erreurs,la gestion du débit, etc...
C'est probablement la façon la plus facile et la plus fiable de le faire.
Juste à être un peu égoïste ici et décrivant exactement ce que chasse-neige, une plateforme d'analyse d'événements le fait. Ils utilisent cette façon unique 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, c'est héberger un pixel dans l'un des S3 buckets et mettre ce bucket derrière une distribution CloudFront comme origine. Activez les logs dans un seau S3 pour le même CloudFront.
vous pouvez envoyer des logs comme url paramètres à 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 en utilisant la copie.
ceci résout le but de l'agrégation des logs. Cette installation se chargera de tout pour vous.
Vous pouvez aussi regarder Piwik qui est un service d'analyse open source et voir si vous pouvez le modifier en fonction de vos besoins.
vous pouvez écrire des données dans le fichier CSV sur le disque local et ensuite lancer le script Python/boto/psycopg2 pour charger des données dans Amazon Redshift.
Dans mon CSV_Loader_For_Redshift j'ai:
compresser et charger les données à S3 en utilisant boto module Python et de 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 )Utiliser psycopg2 commande de copie 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)