Das Unternehmen ist in mehrere Betriebe aufgeteilt. Jeder Betrieb betreibt eigene Kampagnen auf unterschiedlichen Kan\u00e4len. Fast alle Kan\u00e4le (wie z. B. TikTok) werden von mehr als einem Betrieb mit jeweils eigenen Accounts bespielt.
Der Fokus lag im oben verlinkten Beitrag vor allem auf der Transformation innerhalb des f\u00f6derierten Data Warehouse. In diesem Beitrag geht es darum, wie die Rohdaten \u00fcberhaupt in das System gelangen. Wir haben zwei Arten von Daten:<\/p>\n\n\n\n
- \n
- Manuell gepflegte Daten<\/li>\n\n\n\n
- Daten aus anderen Systemen<\/li>\n<\/ul>\n\n\n\n
Manuell gepflegte Daten<\/h3>\n\n\n\n
Manuelle Datenpflege an sich ist zwar organisatorisch anspruchsvoll, technisch jedoch recht geradlinig.
Wir haben eine App geschrieben, die XLSX- und CSV-Dateien annimmt und auch die manuelle Dateneingabe erm\u00f6glicht. Die so bereitgestellten Daten werden zusammen mit Metadaten an eine Tabelle im Data Warehouse angeh\u00e4ngt.
Eine sp\u00e4tere Transformation filtert die nicht mehr relevanten Zeilen aus.
Der Sinn dieser Append-only-Strategie besteht darin, dass \u00e4ltere Versionen der Daten nicht verloren gehen. Es kann nachverfolgt werden, wann etwas hochgeladen wurde und von wem. Diese Struktur erm\u00f6glicht Auditing und einfache Rollbacks.<\/p>\n\n\n\nDaten aus anderen Systemen<\/h3>\n\n\n\n
Komplexer ist die Anbindung externer Datenquellen wie Social-Media-Plattformen und Web-Analytics. Hier hat jeder Anbieter eigene Schnittstellen und Prinzipien.
Eine Eigenentwicklung w\u00e4re hier zu teuer. Deshalb haben wir nach einem Anbieter gesucht, der sowohl die meisten der Datenquellen anbinden kann als auch die regulatorischen Anforderungen unserer Kundin erf\u00fcllt. Unsere Wahl fiel auf Adverity.
Adverity bietet eine Web-UI, in der wir Data Streams anlegen k\u00f6nnen. F\u00fcr jeden Social-Media-Channel, Web-Analytics-Dienst etc. brauchen wir einen oder mehrere Streams. Adverity fragt dann die Daten beim Anbieter entsprechend der Konfiguration ab und l\u00e4dt sie in das Data Warehouse.
Wir haben derzeit etwas \u00fcber 200 Streams. Die Konfigurationen all dieser Streams h\u00e4ndisch zu verwalten ist zwar m\u00f6glich, aber fehleranf\u00e4llig und nervt\u00f6tend. Wie bereits im oben verlinkten Beitrag beschrieben, nutzen meist mehrere Betriebe des Unternehmens die gleichen Plattformen \u2013 nur mit unterschiedlichen Accounts. Da bietet es sich an, die f\u00fcr eine Plattform ben\u00f6tigten Streams nur einmal zu definieren und mit kleinen \u00c4nderungen f\u00fcr alle Betriebe des Unternehmens auszurollen.
Die Weboberfl\u00e4che von Adverity bietet diese M\u00f6glichkeiten nicht, jedoch stellt Adverity eine API bereit, durch die wir viele Aspekte der Data Streams anpassen k\u00f6nnen.<\/p>\n\n\n\nStream-Management per API<\/h3>\n\n\n\n
Unser Ansatz besteht aus zwei Teilen:<\/p>\n\n\n\n
- \n
- Eine detaillierte Beschreibung aller Streams durch Konfigurationsdateien<\/li>\n\n\n\n
- Ein Programm, das durch API-Aufrufe s\u00e4mtliche Streams auf den Soll-Zustand bringt<\/li>\n<\/ul>\n\n\n\n
Wenn also zum Beispiel ein neues Feld f\u00fcr alle \u201cSearch Term Performance\u201d-Streams ben\u00f6tigt wird, kann dieses im entsprechenden Template eingetragen werden. Das Programm passt danach alle Streams entsprechend an.<\/p>\n\n\n\nStrukturierte Konfiguration<\/h3>\n\n\n\n
Die Konfiguration erstreckt sich \u00fcber eine Vielzahl von Dateien. Durch die Aufteilung auf mehrere Dateien bleiben die einzelnen Dateien (relativ) \u00fcbersichtlich und haben jeweils einen klar umrissenen Anwendungsbereich. W\u00e4re alle Konfiguration in einer einzelnen Datei, so h\u00e4tte diese \u00fcber 7.500 Zeilen.<\/p>\n\n\n\n
- \n
- Jede Konfigurationsdatei hat eine bestimmte Rolle:<\/li>\n\n\n\n
- Stream-Template: Beschreibt einen konkreten Stream<\/li>\n\n\n\n
- Stream-Set: Beschreibt eine Sammlung von Streams, z. B. alle Streams f\u00fcr eine Plattform<\/li>\n\n\n\n
- Workspace: Beschreibt die Streams f\u00fcr einen Betrieb durch die Einbindung von Stream-Sets und\/oder einzelnen Stream-Templates<\/li>\n\n\n\n
- Hauptkonfiguration: Enth\u00e4lt eine Liste der Workspaces und globale Einstellungen wie z. B. die API-URL<\/li>\n<\/ul>\n\n\n\n
![\"\"](\"https:\/\/www.theinformationlab.de\/wp-content\/uploads\/2026\/06\/aok_usecase2_grafik.png\")
<\/figure>\n<\/div>\n\n\n
Durch den Einsatz von Variablen in der Konfiguration k\u00f6nnen Streams angepasst werden. Werte werden von oben (Hauptkonfiguration) nach unten (einzelner Stream) durchgereicht und k\u00f6nnen auf jeder Ebene angepasst, erweitert oder \u00fcberschrieben werden.
Zum Beispiel werden alle Instagram-Medien-Streams die gleichen Felder abfragen. Der Name des Streams und der Account, den er nutzt, sollen aber pro Betrieb konfiguriert werden.<\/p>\n\n\n\nIm Workspace des Betriebs definieren wir daf\u00fcr zwei Variablen:<\/strong><\/p>\n\n\n\n
# Die folgenden 2 Zeilen \u201eaktivieren\u201c Instagram f\u00fcr den Betrieb:\n[[stream_sets]]\ninclude = \u201esets\/instagram_organic.toml\u201c\n\n \n\n# Variablen f\u00fcr die Produktiv-Umgebung:\n[variables.prod]\nname_infix = \u201eZentrale\u201c # Wird sp\u00e4ter Teil des Stream-Namens\ninstagram_auth = 154 # ID der zu nutzenden Instragram-Authorisation<\/code><\/pre>\n\n\n\nIn der Konfiguration f\u00fcr das Instagram-Stream-Set k\u00f6nnen wir diese Variablen dann entsprechend nutzen:<\/strong><\/p>\n\n\n\n
[[streams]]\nname = { subst = \u201eIG_${name_infix}_Media_Lifetime_Daily\u201c }\n# ergibt: name = \u201eIG_Zentrale_Media_Lifetime_Daily\u201c\n\n \n\nauth = { ref = \u201einstagram_auth\u201c }\n# ergibt: auth = 154\n\n \n\ntemplate = \u201etemplates\/instagram\/ig_media_lifetime.toml\u201c<\/code><\/pre>\n\n\n\nDiese Aufteilung bietet eine hohe Wiederverwendbarkeit von Komponenten und bleibt gleichzeitig sehr flexibel.<\/strong><\/p>\n\n\n\n
One Tool to rule them all<\/h3>\n\n\n\n
Die zentrale Funktion des Tools, das wir zur Verwaltung der Adverity-Workspaces entwickelt haben, ist der Abgleich von Ist- mit Soll-Zust\u00e4nden \u2013 und auf Wunsch auch die Herbeif\u00fchrung des Soll-Zustands.
Dazu fragt das Tool die aktuelle Konfigurationen aller Adverity-Streams ab und speichert sie in einem internen Datenmodell. Dieses Datenmodell wird dann mit der Konfiguration abgeglichen, um eine Liste notwendiger \u00c4nderungen zu erstellen. Kleinere Abweichungen werden bewusst akzeptiert, solange sie keine Auswirkungen auf das finale Datenprodukt haben. Diese \u00c4nderungen zeigt das Tool dann an und kann sie auf Wunsch auch direkt durchf\u00fchren.
Zus\u00e4tzlich kommen noch hilfreiche Features dazu, wie die Steuerung von \u201cFetches\u201d, die Generierung von Templates aus existierenden Streams, das Rendern von Text-Templates mit Informationen aus der Konfiguration und von Adverity, sowie diverse weitere kleine Helferlein.
Als Programmiersprache f\u00fcr das Programm haben wir Rust gew\u00e4hlt. Diese Wahl mag auf den ersten Blick ungew\u00f6hnlich erscheinen \u2013 ist Python doch im Datenbereich viel weiter verbreitet.
Rust ist bekannt f\u00fcr seine Performance und Speichersicherheit \u2013 beides Eigenschaften, die zwar in jedem Projekt vorteilhaft sind, bei einem internen Tool dieser Art aber nicht den Ausschlag geben.
Dennoch hat sich Rust im Nachhinein als die richtige Wahl herausgestellt. In der Anfangsphase, in der wir die Grundlagen geschaffen haben, haben wir zwar mehr Arbeit investiert, als es mit Python der Fall gewesen w\u00e4re. Danach jedoch hat die Entwicklung danach eine gute Geschwindigkeit aufgenommen. Neue Features konnten wir im Verlauf des Projekts schnell (meist innerhalb weniger Stunden) und ohne Angst vor ungewollten Seiteneffekten entwickeln.
Vor allem die starke Typisierung und erzwungene Fehlerbehandlung sind dabei sehr hilfreich. Was anfangs vielleicht wie Over-Engineering aussah hat sich sp\u00e4ter mehrfach ausgezahlt: Durch die rapide Weiterentwicklung und den stabilen sowie fehlerfreien Betrieb.
Mit dieser Entscheidung stehen wir nicht allein auf weiter Flur. Auch unser Partner dbt labs, der uns k\u00fcrzlich als \u201cEmerging Partner of the Year\u201d ausgezeichnet hat, geht diesen Weg. Sie entwickeln das Kernst\u00fcck ihres Produkts \u2013 dbt core \u2013 unter dem Namen dbt Fusion engine in Rust neu. Seit Kurzem ist dbt Fusion engine in Public Preview.<\/p>\n\n\n\nFazit<\/h3>\n\n\n\n
Mit dem hier beschriebenen Ansatz haben wir einen entscheidenden Schritt gemacht: Sowohl manuell gepflegte Daten als auch automatisiert geladene Datenstr\u00f6me lassen sich nun vollst\u00e4ndig nachvollziehbar, konsistent und skalierbar in das f\u00f6derierte Data Warehouse integrieren.
\u00c4nderungen an hunderten Streams, die sonst Stunden oder Tage gedauert h\u00e4tten, sind in Minuten umgesetzt. Neue Plattformen oder Betriebe lassen sich mit minimalem Aufwand einbinden, und bestehende Strukturen bleiben jederzeit nachvollziehbar und auditierbar.
Damit haben wir nicht nur die technische Grundlage geschaffen, sondern auch die operative Skalierbarkeit erreicht, die ein f\u00f6deriertes Data-Warehouse-System dieser Gr\u00f6\u00dfenordnung ben\u00f6tigt. Kurz gesagt: Wir haben ein komplexes, fehleranf\u00e4lliges Setup in ein wartbares, robustes und elegantes System verwandelt \u2013 und zeigen damit, wie durchdachte Automatisierung und sauberes Engineering einen echten Mehrwert schaffen.<\/p>\n\n\n\nDieser Use Case verdeutlicht, warum die Wahl der richtigen Plattform entscheidend ist. Um solche komplexen Multi-Mandanten-Szenarien performant und sicher abzubilden, vertrauen wir auf die Snowflake Data Cloud.<\/p>\n\n\n\n
<\/p>\n\n\n\n