Chargement de données dans Redshift avec DBT

• Yelp a récemment réexaminé sa manière de charger les données dans Redshift de façon plus efficace, face à l’augmentation de la demande des utilisateurs pour les données
• Cet article explique comment DBT s’utilise de manière fluide avec Redshift Spectrum pour lire les données du Data Lake vers Redshift, réduire fortement le temps d’exécution, résoudre des problèmes de qualité des données et améliorer la productivité des développeurs

Point de départ

• La méthode de chargement des données batch dans Redshift était efficace depuis des années, mais l’équipe cherchait en permanence des pistes d’amélioration
• Elle utilisait principalement des jobs Spark pour lire les données depuis S3 et les publier dans un pipeline de données interne basé sur Kafka, afin d’alimenter à la fois le Data Lake et Redshift
• Mais plusieurs problèmes ont commencé à apparaître :
  • Performance : les gros jeux de données (plus d’un million de lignes par jour) ont commencé à subir de la latence. Cela venait principalement des scans de table nécessaires pour éviter les doublons de clés primaires lors des upserts
  • Changements de schéma : la plupart des tables reposaient sur des schémas Avro. Les changements de schéma étaient parfois complexes, car ils nécessitaient un processus en plusieurs étapes pour générer et enregistrer un nouveau schéma Avro
  • Backfill : la prise en charge des corrections de données par backfill était insuffisante, car il n’existait pas de moyen simple de modifier des lignes in-place. Il fallait souvent supprimer manuellement les données avant de réécrire les données corrigées pour une partition complète
  • Qualité des données : écrire en parallèle dans le Data Lake et dans Redshift entraînait un risque d’écarts de données, par exemple à cause de différences de types entre les deux stockages

Améliorer le chargement dans Redshift avec DBT

• En réfléchissant à une manière plus efficace de déplacer les données, l’équipe a choisi d’exploiter AWS Redshift Spectrum, un outil conçu spécialement pour permettre à Redshift d’interroger les données du Data Lake
• Comme les tables du Data Lake disposaient généralement du schéma le plus à jour, il a été décidé d’utiliser le Data Lake comme source pour les batchs Redshift plutôt que S3. Cela aide non seulement à réduire les écarts de données, mais correspond aussi à la bonne pratique consistant à traiter le Data Lake comme source unique de vérité
• Pour l’implémentation, Spectrum exige un schéma défini, déjà présent dans Glue pour les tables du Data Lake. Le seul paramétrage supplémentaire nécessaire consistait à ajouter les tables du Data Lake comme tables externes afin qu’elles soient accessibles depuis Redshift via de simples requêtes SQL
• DBT avait déjà commencé à être adopté pour d’autres jeux de données, et il s’est aussi révélé être un excellent candidat pour capturer les requêtes Redshift Spectrum dans le pipeline. DBT excelle dans la transformation de données et aide à imposer l’écriture de SQL modulaire et versionné
• Au lieu que des jobs Spark lisent depuis S3 vers Redshift, l’équipe utilise DBT pour copier directement les données du Data Lake vers Redshift. En plus d’apporter ses avantages habituels comme la reproductibilité, la flexibilité et le lignage des données, DBT a également aidé à résoudre plusieurs des problèmes mentionnés plus haut

Changements de schéma simplifiés

• Pour simplifier les changements de schéma, l’équipe a exploité l’argument de configuration on_schema_change de DBT. En le définissant sur append_new_columns, elle s’assure que les colonnes ne sont pas supprimées lorsqu’elles sont absentes des données entrantes
• Elle utilise aussi les contrats DBT comme deuxième couche de protection afin de vérifier que les données écrites correspondent à la configuration du modèle

Des backfills moins manuels

• Les backfills sont également devenus bien plus simples avec DBT. L’argument de configuration pre_hook permet de spécifier une requête à exécuter juste avant le modèle
• Cela permet de supprimer de manière plus automatique les données des partitions qui vont être réécrites
• Il est désormais possible de garantir l’idempotence et d’effectuer des backfills sans craindre que d’anciennes données ne soient pas supprimées

Déduplication des données

• Pour gérer les lignes dupliquées, l’équipe a ajouté une couche de déduplication en SQL et l’a validée avec des tests DBT
• DBT intègre un test de colonne unique, mais celui-ci nécessite un scan complet de la table, ce qui n’est pas viable pour les grosses tables
• À la place, l’équipe utilise la fonction expect_column_values_to_be_unique du package dbt_expectations. Cela permet de définir une condition sur les lignes afin de ne scanner que les lignes récemment écrites

Améliorations de performance

• Le résultat le plus visible a été l’amélioration des performances, en particulier sur les jeux de données Redshift les plus problématiques :
  • Les écritures prenaient environ 2 heures, mais s’exécutent désormais généralement en seulement 10 minutes
  • Auparavant, il pouvait y avoir jusqu’à 6 heures de retard par mois, mais il n’y a maintenant plus de retard. Cela réduit fortement la charge liée à la gestion des incidents d’astreinte
  • Les mises à niveau de schéma suivaient auparavant un processus plus long en plusieurs étapes. Elles ont maintenant été ramenées à un processus en 3 étapes qui ne prend que quelques heures

Une meilleure cohérence des données

• En supprimant la bifurcation dans le flux de données, l’équipe a davantage confiance dans le fait que les données ne divergeront pas entre les différents stockages
• Comme toutes les données qui entrent dans Redshift doivent d’abord passer par le Data Lake, il est plus facile de garantir que le Data Lake reste la source unique de vérité

Conclusion

• À la suite du succès de cette migration, ces changements ont été appliqués à environ 12 autres jeux de données, avec des bénéfices similaires observés dans l’ensemble
• En s’appuyant sur des outils comme AWS Redshift Spectrum et DBT, l’équipe a fait évoluer son infrastructure pour répondre à l’évolution des besoins en données et fournir davantage de valeur aux utilisateurs et aux parties prenantes