WebstaurantStore automatisiert dbt-Staging für über 700 Quellen mit Snowflake Cortex AI
Ein dreiköpfiges Data-Engineering-Team von WebstaurantStore hat mit Snowflake Cortex LLM-Funktionen und dbt in 90 Tagen eine Staging-Schicht für mehr als 700 Quellen automatisiert, ohne zusätzliches Personal. Nach Angaben des Teams stieg die Ingestion-Geschwindigkeit um etwa das Zehnfache.
- Ein dreiköpfiges Team von WebstaurantStore automatisierte das Staging für mehr als 700 Quellen in 90 Tagen, ohne zusätzliches Personal.
- Das alte SQL-Server-Warehouse nutzte über 1.300 eng gekoppelte Stored Procedures, und das Datenvolumen wuchs um rund 40 Prozent pro Jahr.
- Snowflake Cortex LLM-Funktionen schlagen aus rohen Metadaten lesbare Spaltennamen und fachliche Definitionen vor.
- Die Vorschläge landen in einer Review-Tabelle, in der Ingenieure sie prüfen oder überschreiben, und dbt-Jinja-Makros lesen nur aus dieser freigegebenen Tabelle.
- Das Team beziffert das Ergebnis auf eine rund zehnfache Steigerung der Ingestion-Geschwindigkeit.
Ein Legacy-Warehouse am Limit
Am Anfang des Projekts stand ein veraltetes SQL-Server-Data-Warehouse, das an seine Grenzen gestoßen war. Das berichtet Cathy Huang, Senior Business Intelligence Engineer bei WebstaurantStore, in einem Blogbeitrag von dbt Labs. Das System stützte sich auf mehr als 1.300 eng gekoppelte, praktisch undurchsichtige Stored Procedures.
Mit dem Wachstum des Unternehmens stieg das Datenvolumen um rund 40 Prozent pro Jahr. Der Beitrag nennt mehrere daraus folgende Probleme:
- Überlastete Batch-Jobs drohten ihre nächtlichen Zeitfenster zu überschreiten und in die Geschäftszeiten hineinzulaufen.
- Ingenieure programmierten die Staging-Logik Tabelle für Tabelle von Hand, um Schritt zu halten.
- Die Intransparenz der alten Stored Procedures machte automatisierte Tests nahezu unmöglich.
So funktioniert die automatisierte Pipeline
Die Lösung des Teams automatisiert die Datenaufnahme vom Landing-Bereich bis zur Bronze-Schicht. Zuvor mussten Ingenieure kryptische, abgekürzte Spaltennamen aus Legacy-OLTP-Quellen manuell zuordnen. Im neuen Aufbau speist die Pipeline rohe System-Metadaten in Snowflake Cortex LLM-Funktionen ein, die normalisierte, gut lesbare Spaltennamen und fachliche Definitionen vorschlagen.
Diese Vorschläge gelangen nicht direkt in die Produktion. Zunächst landen sie in einer zwischengeschalteten Review-Tabelle, in der Ingenieure jeden Vorschlag prüfen und bei Bedarf überschreiben. Die dbt-Jinja-Makros, die das SQL der Produktionsmodelle und die YAML-Dokumentation kompilieren, lesen ausschließlich aus dieser von Menschen freigegebenen Tabelle, nie direkt aus der rohen KI-Ausgabe.
Tempo ohne Kontrollverlust
Laut dem Beitrag konnte WebstaurantStore dank dieser Kontrollstation schnell vorankommen und zugleich die Hoheit darüber behalten, was in die Produktion gelangt. Das Team band in 90 Tagen mehr als 700 Quellen an, was nach eigener Rechnung einer rund zehnfachen Steigerung der Ingestion-Geschwindigkeit entspricht. Die Arbeit leisteten dieselben drei Ingenieure, die das Framework aufgebaut hatten.
Huang würdigte zudem Jessica Stayton, Resident Architect bei dbt, die bei einem schwierigen Fall geholfen habe: einer wichtigen Quelle ohne Watermark, anhand derer sich Änderungen nachverfolgen ließen.
Was das für Datenteams bedeutet
Der Fall zeigt ein Muster für Teams mit großen Rückständen an Legacy-Quellen: Ein LLM entwirft die mühsame Arbeit an Benennung und Dokumentation, doch die Ergebnisse laufen über eine von Menschen freigegebene Schicht, bevor Code generiert wird. Huang formulierte das Prinzip im Beitrag so: Automatisierung lohnt sich nur, wenn die Menschen, die sich darauf verlassen, dem Ergebnis weiterhin vertrauen können.
Die Zahlen stammen aus der eigenen Darstellung von WebstaurantStore zum Projekt und sind in der Quelle nicht unabhängig überprüft.
