ETL Possible entre S3 et Redshift avec Kinesis Firehose?

Question

Mon équipe tente d'utiliser Redshift pour consolider les informations de plusieurs bases de données différentes. Dans notre première tentative d'implémentation de cette solution, nous avons utilisé Kinesis Firehose pour écrire des enregistrements de POST sur nos API vers S3 puis émis une commande COPY pour écrire les données insérées dans les tables correctes dans Redshift. Cependant, cela nous a seulement permis d'insérer de nouvelles données et ne nous a pas permis de transformer des données, de mettre à jour des lignes lorsqu'elles ont été modifiées ou de supprimer des lignes. Quelle est la meilleure façon de maintenir un entrepôt de données mis à jour dans Redshift sans utiliser la transformation par lots? Idéalement, nous aimerions que les mises à jour se produisent "automatiquement" (< 5min) chaque fois que les données sont modifiées dans nos bases de données locales.

Answer 1

1. Firehose ou Redshift ne sont pas déclencheurs, mais vous pouvez utiliser potentiellement l'approche par Lambda et Firehose de pré-traiter les données avant qu'il ne soit inséré comme décrit ici: https://blogs.aws.amazon.com/bigdata/post/Tx2MUQB5PRWU36K/Persist-Streaming-Data-to-Amazon-S3-using-Amazon-Kinesis-Firehose-and-AWS-Lambda

   Dans votre cas, vous pouvez l'étendre pour utiliser Lambda sur S3 car Firehose crée de nouveaux fichiers, qui exécuteront ensuite la mise à jour COPY/SQL. Une autre alternative consiste simplement à écrire votre propre client KCL qui implémenterait ce que Firehose fait, puis à exécuter les mises à jour requises après la COPIE de micro-lots (500-1000 lignes). J'ai fait une telle implémentation (nous avions besoin de mettre à jour les anciens enregistrements basés sur de nouveaux enregistrements) et cela fonctionne bien du point de vue de la cohérence, bien que je déconseille une telle architecture en raison des mauvaises performances de Redshift. aux mises à jour. D'après mon expérience, la règle clé est que les données Redshift sont ajoutées uniquement, et il est souvent plus rapide d'utiliser des filtres pour supprimer les lignes inutiles (avec un élagage régulier facultatif, comme quotidiennement) que de supprimer/mettre à jour ces lignes en temps réel. Encore un autre alernatif, est d'avoir des données de vidage Firehose dans la (les) table (s) intermédiaire (s), puis les tâches planifiées prennent tout ce qui est dans cette table, font le traitement, déplacent les données et tournent les tables.

Comme une architecture de référence générale pour en temps réel insère dans Redshift, jetez un oeil à ceci: https://blogs.aws.amazon.com/bigdata/post/Tx2ANLN1PGELDJU/Best-Practices-for-Micro-Batch-Loading-on-Amazon-Redshift

Cela a été mis en œuvre plusieurs fois, et fonctionne bien.