Daten mit DBT in Redshift laden

• Yelp hat angesichts der zuletzt stark gestiegenen Nachfrage der Nutzer nach Daten erneut geprüft, wie sich Daten effizienter in Redshift laden lassen
• Dieser Artikel zeigt, wie sich DBT nahtlos mit Redshift Spectrum einsetzen lässt, um Daten aus dem Data Lake in Redshift einzulesen, Laufzeiten deutlich zu verkürzen, Probleme mit der Datenqualität zu beheben und die Produktivität der Entwickler zu steigern

Ausgangspunkt

• Die Methode zum Laden von Batch-Daten in Redshift war über Jahre hinweg effektiv, wurde aber kontinuierlich weiter verbessert
• Hauptsächlich wurden Spark-Jobs genutzt, um Daten aus S3 zu lesen und in eine unternehmenseigene, Kafka-basierte Datenpipeline zu veröffentlichen, die Daten sowohl in den Data Lake als auch in Redshift bringt
• Dabei traten jedoch einige Probleme auf:
  • Performance: Große Datensätze (mehr als 1 Million Zeilen pro Tag) begannen Verzögerungen zu verursachen. Der Hauptgrund waren Tabellenscans bei Upserts, um sicherzustellen, dass keine Primärschlüssel doppelt vorhanden sind
  • Schemaänderungen: Die meisten Tabellen basierten auf Avro-Schemas. Änderungen am Schema waren teils aufwendig, da dafür ein mehrstufiger Prozess zum Erstellen und Registrieren neuer Avro-Schemas nötig war
  • Backfills: Die Unterstützung für Backfills bei Datenkorrekturen war unzureichend, weil es keinen einfachen Weg gab, Zeilen direkt zu ändern. Häufig mussten Daten manuell gelöscht werden, bevor korrigierte Daten für eine gesamte Partition geschrieben werden konnten
  • Datenqualität: Das parallele Schreiben in den Data Lake und nach Redshift brachte das Risiko von Datenabweichungen zwischen beiden Speichern mit sich, etwa durch Unterschiede bei Datentypen

Redshift-Ladevorgänge mit DBT verbessern

• Bei der Suche nach einer effizienteren Methode zur Datenbewegung fiel die Wahl auf AWS Redshift Spectrum, ein speziell dafür entwickeltes Tool, mit dem sich Data-Lake-Daten direkt aus Redshift heraus abfragen lassen
• Da die Tabellen im Data Lake in der Regel das aktuellste Schema hatten, wurde entschieden, den Data Lake statt S3 als Datenquelle für Redshift-Batches zu verwenden. Das hilft nicht nur, Datenabweichungen zu reduzieren, sondern entspricht auch der Best Practice, den Data Lake als Single Source of Truth zu behandeln
• Für die Implementierung benötigt Spectrum ein definiertes Schema, das für die Data-Lake-Tabellen bereits in Glue vorhanden war. Die einzige zusätzliche Einrichtung bestand darin, die Data-Lake-Tabellen als externe Tabellen hinzuzufügen, damit sie in Redshift über einfache SQL-Abfragen zugänglich sind
• DBT wurde bereits für andere Datensätze eingeführt und erwies sich auch als idealer Kandidat, um Redshift-Spectrum-Abfragen in der Pipeline abzubilden. DBT ist stark bei Datentransformationen und hilft dabei, modulare und versionskontrollierte SQL-Entwicklung durchzusetzen
• Anstatt dass Spark-Jobs Daten aus S3 in Redshift lesen, werden die Daten nun mit DBT direkt aus dem Data Lake nach Redshift kopiert. DBT bietet nicht nur typische Vorteile wie Reproduzierbarkeit, Flexibilität und Data Lineage, sondern hilft auch dabei, mehrere der oben genannten Probleme zu lösen

Vereinfachte Schemaänderungen

• Um Schemaänderungen zu vereinfachen, wurde das Konfigurationsargument on_schema_change von DBT genutzt. Mit der Einstellung append_new_columns wird sichergestellt, dass Spalten nicht entfernt werden, wenn sie in eingehenden Daten fehlen
• Zusätzlich werden DBT Contracts als zweite Schutzschicht eingesetzt, um sicherzustellen, dass die geschriebenen Daten mit der Modellkonfiguration übereinstimmen

Weniger manuelle Backfills

• Auch Backfills wurden mit DBT deutlich einfacher. Über das Konfigurationsargument pre_hook lassen sich Abfragen definieren, die direkt vor dem Modell ausgeführt werden
• So können Daten für die zu schreibenden Partitionen automatisierter gelöscht werden
• Dadurch lässt sich nun Idempotenz sicherstellen, sodass Backfills durchgeführt werden können, ohne sich Sorgen machen zu müssen, dass alte Daten nicht entfernt wurden

Deduplizierung von Daten

• Um doppelte Zeilen zu beheben, wurde in SQL eine Deduplizierungsschicht ergänzt und diese mit DBT-Tests validiert
• DBT bietet zwar einen eingebauten unique-Spaltentest, dieser erfordert jedoch einen vollständigen Tabellenscan und ist daher für große Tabellen nicht praktikabel
• Stattdessen wird die Funktion expect_column_values_to_be_unique aus dem Paket dbt_expectations verwendet. Damit lässt sich eine Zeilenbedingung angeben, sodass nur kürzlich geschriebene Zeilen gescannt werden

Verbesserte Performance

• Das auffälligste Ergebnis war die bessere Performance, insbesondere bei dem problematischsten Redshift-Datensatz:
  • Schreibvorgänge dauerten früher etwa 2 Stunden, laufen jetzt aber in der Regel in nur 10 Minuten
  • Früher kam es teils zu Verzögerungen von bis zu 6 Stunden pro Monat, jetzt gibt es überhaupt keine Verzögerungen mehr. Das entlastet die Reaktion auf On-Call-Incidents erheblich
  • Schema-Upgrades waren zuvor ein längerer, mehrstufiger Prozess. Jetzt wurden sie auf einen dreistufigen Ablauf reduziert, der nur noch wenige Stunden dauert

Bessere Datenkonsistenz

• Durch das Entfernen der Verzweigung im Datenfluss ist das Vertrauen gestiegen, dass Daten nicht mehr zwischen verschiedenen Datenspeichern auseinanderlaufen
• Da alle Daten für Redshift zunächst den Data Lake durchlaufen müssen, lässt sich besser sicherstellen, dass der Data Lake die Single Source of Truth bleibt

Fazit

• Nach dem Erfolg der Migration wurden diese Änderungen auf etwa 12 weitere Datensätze angewendet, wobei insgesamt ähnliche Vorteile beobachtet wurden
• Durch den Einsatz von Tools wie AWS Redshift Spectrum und DBT wurde die Infrastruktur an sich wandelnde Datenanforderungen angepasst, um Nutzern und Stakeholdern mehr Mehrwert zu bieten