Modélisation dimensionnelle et ETL dans Redshift

J'ai fait des recherches sur la base de données Redshift d'Amazon en tant que futur remplacement possible de notre entrepôt de données. Mon expérience a toujours consisté à utiliser la modélisation dimensionnelle et les méthodes de Ralph Kimball, il était donc un peu étrange de voir que Redshift ne prend pas en charge des fonctionnalités telles que le type de données série pour les colonnes à incrémentation automatique.

Il existe cependant ce récent billet de blog du blog AWS Big Data sur la façon d'optimiser Redshift pour un schéma en étoile: https://blogs.aws.amazon.com/bigdata/post/Tx1WZP38ERPGK5K/Optimizing-for-Star-Schemas -et-entrelacé-tri-sur-Amazon-Redshift

Ma question est de savoir quelle est la meilleure pratique pour charger un schéma en étoile dans Redshift? Je ne trouve pas cette réponse dans la documentation de Redshift.

Je penche vers l'importation de mes fichiers depuis S3 dans des tables intermédiaires, puis j'utilise SQL pour effectuer des transformations telles que des recherches et générer des clés de substitution avant de les insérer dans les tables de destination.

Est-ce ce que font les autres actuellement? Existe-t-il un outil ETL qui en vaut la peine pour vous faciliter la tâche?

Vous êtes définitivement sur la bonne voie avec Kimball plutôt que Inmon pour Redshift.

Il existe un certain nombre de modèles pour cela, je les ai tous utilisés dans différents cas d'utilisation

1. Modèle "ELT" - Chargez complètement les tables source pour effectuer un redshift, n'effectuez aucune transformation significative avant le chargement des données. Pour cela, vous pouvez soit charger dans s3, puis utiliser la commande de copie redshift ou je recommanderais d'utiliser "AWS data migration services", qui peut synchroniser une source (egmysql ou postgres) avec une cible (eg redshift) Ensuite, sur une base régulière, exécutez sql traite dans redshift pour remplir les gradations puis les faits. Vous pouvez utiliser des outils tiers basés sur le cloud pour "simplifier" ce processus si vous le souhaitez - comme Matillion (je ne recommande pas d'utiliser un outil tiers)
2. "Modèle ETL" - Transformez les données en vol, en utilisant une étincelle apache. et chargez les gradations et les faits dans redshift spark-> s3-> redshift. J'ai utilisé EMR pour cela, ce qui est bien. c'est également l'approche adoptée si vous utilisez AWS Glue
3. Ne vous transformez pas! - similaire à 1) mais utilisez simplement les tables qui ont été chargées.

Notez que Redshift fonctionne parfois mieux si vous avez un tableau large avec des valeurs répétées plutôt qu'un fait et des dimensions. La raison en est que l'approche en colonnes permet à Redshift de compresser les différentes valeurs à un niveau assez efficace. Je n'ai pas de formule pour savoir quand utiliser de nombreuses dimensions par rapport à une table large et plate, la seule façon est de l'essayer et de voir!

Quelques liens

AWS DMS pour taret Redshift

Colle AWS

Pour ETL, il y a AWS Glue. Il s'agit d'un service ETL géré et sans serveur qui se charge entre autres sur Redshift.

https://aws.amazon.com/glue/

Je fais actuellement face à une tâche similaire. Il s'agit de construire un processus ETL et de concevoir un modèle dimensionnel. J'ai fait beaucoup de recherches sur la meilleure façon de le gérer et j'ai trouvé une source utile de techniques incroyables que nous devrions certainement appliquer lorsque nous travaillons avec MPP.

Pour répondre à la question

Ma question est de savoir quelle est la meilleure pratique pour charger un schéma en étoile dans Redshift?

assurez-vous de jeter un œil à cette ressource . Je parie que vous le trouverez incroyablement utile. Il s'agit d'un document de ~ 35 pages avec des techniques puissantes pour tirer parti de l'utilisation des magasins à colonnes MPP. Il prend en charge les commentaires que vous voyez comme

Notez que Redshift fonctionne parfois mieux si vous avez un tableau large avec des valeurs répétées plutôt qu'un fait et des dimensions. La raison en est que l'approche en colonnes permet à Redshift de compresser les différentes valeurs à un niveau assez efficace. Je n'ai pas de formule pour savoir quand utiliser de nombreuses dimensions par rapport à une table large et plate, la seule façon est de l'essayer et de voir!

commentaire de Jon Scott

J'espère que vous le trouverez aussi utile que moi

Je pense que le chargement depuis S3 est un modèle courant.

Nous devions appliquer des contraintes d'unicité, nous avons donc choisi d'écrire dans Postgres, puis de répliquer les nouvelles données pour redshift toutes les 10 minutes.

Nous utilisons https://github.com/uswitch/blueshift pour charger dans Redshift.

Étant donné que Redshift est une base de données en colonnes, les performances de stockage et de requête seront différentes de celles des modèles SGBDR. L'optimisation d'une base de données en colonnes est également différente. Parce qu'il y a généralement moins d'E / S disque et moins de données chargées à partir du disque, les requêtes sont plus rapides.

En termes de l'article de blog AWS auquel vous faites référence, je suppose que vous avez examiné ces recommandations et examiné les options qui fonctionnent le mieux pour vos données pour la distribution, les clés, les curseurs, la gestion de la charge de travail, etc. et que vous avez au moins une bonne idée de l'approche vous utiliseriez. Je trouve plus facile de travailler avec une représentation visuelle, vous pourriez envisager un diagramme de base de données rapide et sale montrant comment vos tables existantes migreraient vers Redshift. Couvrir les principaux pour avoir une idée de la quantité de données qui vont où. Et j'utiliserais certainement les pilotes ODBC / JDBC d'Amazon, le chargement de grandes quantités de données peut être gênant dans tous les cas, et encore moins passer à un autre type de base de données.

En ce qui concerne ETL / ELT, il y a AWS Glue comme d'autres affiches l'ont mentionné. Et oui, il existe un certain nombre d'outils, dont certains sont gratuits. Amazon a un guide des meilleures pratiques DB , qui pourrait également vous aider. Une astuce que j'ai vue dans d'autres forums est de charger vos données aussi brutes que possible et de faire les transformations dans Redshift. Cela vous mènerait à un processus ELT. Avec autant d'options, peut-être que regarder une comparaison des 2 méthodes serait utile. Voici un article de blog de Panopoly expliquant les différences, il pourrait vous aider à décider d'un chemin.

Amazon a récemment publié quelques bonnes pratiques pour ETL dans Redshift

https://aws.amazon.com/blogs/big-data/top-8-best-practices-for-high-performance-etl-processing-using-amazon-redshift/

Dans une présentation sur ce sujet, Tony Gibbs, AWS Solution Architect recommande le modèle suivant pour les charges de style UPSERT:

1. Charger les données CSV (depuis S3) dans la table intermédiaire
2. Supprimer les lignes correspondantes de la table prd

3. Insérer des données de l'étape

   BEGIN;
   CREATE TEMP TABLE staging(LIKE …); — copies dist keys
   copy staging from ’s3://… COMPUTE OFF;
   DELETE deep_dive d
   USING staging s WHERE d.aid = s.aid;
   INSERT INTO deep_dive SELECT * FROM staging
   DROP table staging;
   COMMIT;

Si possible, préférez DROP TABLE ou TRUNCATE à DELETE pour éviter les lignes fantômes

Voir une vidéo de son discours et les diapositives .

Dans notre équipe, nous chargeons généralement les données dans Redshift directement depuis S3 à l'aide de l'instruction SQL COPY .

Et gérez tous nos ETL à l'aide de l'excellent outil Apache Airflow .

Nous utilisons également des services d'intégration comme Stich qui écrivent directement dans Redshift, puis utilisons CREATE TABLE LIKE et SELECT INTO pour déplacer les données dans un autre schéma.