J'espère que quelqu'un pourra m'aider à résoudre ce problème. Je travaille actuellement sur un projet de pipeline de données, mon dilemme actuel est de savoir s'il faut utiliser le parquet avec Athena ou le stocker dans Redshift
2 Scénarios: Premièrement,
EVENTS --> STORE IT IN S3 --> USE SPARK(EMR) TO STORE DATA INTO REDSHIFT
Deuxièmement,
EVENTS --> STORE IT IN S3 AS JSON.GZ --> USE SPARK(EMR) TO CONVERT TO PARQUET --> STORE PARQUET BACK INTO S3 --> ATHENA FOR QUERY --> VIZ
Problèmes avec ce scénario:
Je ne parviens pas à trouver d'informations utiles sur la meilleure méthode. Dois-je même utiliser Redshift ou le parquet est-il assez bon?
De plus, ce serait formidable si quelqu'un pouvait me dire s'il existe d'autres méthodes pour connecter Spark avec Redshift car il n'y a que 2 solutions que j'ai vues en ligne - JDBC et Spark-Reshift (Databricks)
PS le modèle de tarification ne me préoccupe pas non plus, je traite des millions de données d'événements.
3 Réponses :
Voici quelques idées / recommandations
Mon architecture proposée:
ÉVÉNEMENTS -> CONSERVEZ-LE EN S3 -> RUCHE à convertir en parquet -> À utiliser directement dans Athena
et / ou
ÉVÉNEMENTS -> STORE IT IN S3 -> HIVE pour convertir en parquet -> Utiliser directement dans Redshift en utilisant Redshift Spectrum
Vous POUVEZ PAS avoir besoin de convertir en parquet, si vous utilisez la bonne structure de partitionnement (dossiers s3) et gzip les données alors Athena / spectre alors les performances peuvent être assez bonnes sans la complexité de la conversion en parquet. Cela dépend de votre cas d'utilisation (volumes de données et types de requêtes que vous devez exécuter).
Lequel utiliser dépend de vos données et de vos modèles d'accès. Athena utilise directement la structure de clé S3 pour limiter la quantité de données à analyser. Supposons que vous ayez le type d'événement et l'heure dans les événements. Les clés S3 peuvent être par ex. aaaa / MM / jj / type / * ou type / aaaa / MM / jj / * . L'ancienne structure de clé vous permet de limiter la quantité de données à analyser par date ou date et type, mais pas uniquement par type. Si vous souhaitez effectuer une recherche uniquement par type x mais que vous ne connaissez pas la date, il faudrait une analyse complète du compartiment. Ce dernier schéma clé serait l'inverse. Si vous avez principalement besoin d'accéder aux données d'une seule manière (par exemple, par le temps), Athena pourrait être un bon choix.
D'un autre côté, Redshift est un entrepôt de données basé sur PostgreSQL qui est beaucoup plus compliqué et flexible qu'Athena. Le partitionnement des données joue un grand rôle en termes de performances, mais le schéma peut être conçu de nombreuses manières pour s'adapter à votre cas d'utilisation. D'après mon expérience, la meilleure façon de charger des données sur Redshift est d'abord de les stocker dans S3, puis d'utiliser COPY https://docs.aws.amazon.com/redshift/latest/dg/r_COPY.html . C'est plusieurs magnitudes plus rapide que JDBC que je n'ai trouvé bon que pour tester avec de petites quantités de données. C'est également ainsi que Kinesis Firehose charge les données dans Redshift. Si vous ne souhaitez pas implémenter vous-même la copie S3, Firehose vous propose une alternative.
Il manque quelques détails dans la question. Comment géreriez-vous l'upsert incrémentiel dans le pipeline de données?
Si vous avez implémenté une dimension à changement lent (SCD type 1 ou 2), la même chose ne peut pas être gérée à l'aide de fichiers parquet. Mais cela peut être facilement gérable dans Redshift.