Data-Analyst-Tools und Tech-Stack: Der ehrliche 6-Schichten-Aufbau (mit echten Preisen)

Ich bin letztes Jahr einem Series-B-Unternehmen beigetreten und habe einen Stack geerbt mit drei BI-Tools, zwei Reverse-ETL-Anbietern, an deren Passwort sich niemand erinnern konnte, einem „Datenkatalog" mit elf Einträgen darin und einer jährlichen Rechnung von 40.000 USD, die exakt einen wöchentlichen Slack-Screenshot produzierte. Allein die Looker-Lizenz betrug 52.000 USD. Looker renderte zwölf Dashboards. Zwei davon wurden in den vorangegangenen 90 Tagen geöffnet. Eines davon war meins, um zu prüfen, ob das Dashboard noch funktionierte.

Das war der Moment, in dem ich verstanden habe, was „moderner Data Stack" wirklich bedeutet: eine Logo-Suppe, die Anbieter an Analysten verkaufen, die noch nicht gezwungen wurden, die einzelnen Posten zu verteidigen. Wenn Sie Ihren Stack nicht auf einer Serviette aufzeichnen und jeden Layer einem CFO erklären können, der noch nie von dbt gehört hat, werden Sie die Budgetschlacht verlieren, und die Budgetschlacht kommt bestimmt.

Hier ist also die ehrliche Version. Sechs Schichten. Echte Preise. Die Anbieter, die ich aus den meisten Stacks streichen würde. Und ein 30-Tage-Audit, den Sie durchführen können, bevor Sie eine weitere Verlängerung unterschreiben.

Warum das jetzt wichtig ist

Jeder CFO, mit dem ich spreche, stellt dieselbe Frage: „Warum sind unsere Analytics-Tooling-Ausgaben um 40 % im Jahresvergleich gestiegen, obwohl der Headcount konstant ist?" Die Antwort lautet meistens, dass jemand Snowflake gekauft hat, obwohl Postgres gereicht hätte, jemand anderes Looker gekauft hat, weil es in einem Interview zur Sprache kam, und eine dritte Person Fivetran hinzugefügt hat, weil der alte Engineer gegangen ist und niemand die Python-Skripte pflegen wollte.

Keine dieser Entscheidungen war für sich genommen falsch. Das Problem ist, dass niemand den gesamten Stack besitzt. Tooling-Ausgaben sind die einfachste Position, die ein CFO infrage stellen kann, und die, die ein Analyst am leichtesten schlecht verteidigt. Wenn Ihre Antwort auf „Warum haben wir das?" lautet „weil das die letzte Person eingerichtet hat", haben Sie bereits verloren.

Verteidigungsfähige Stacks haben eine gemeinsame Eigenschaft: Jedes Tool wird genau einer Schicht zugeordnet, und jede Schicht verdient ihren Platz. Sechs Schichten sind genug.

Die 6 Kernschichten (alles andere ist optional)

1. Data Warehouse

Das ist das Fundament. Falsch gewählt, und die nächsten drei Schichten kosten das Dreifache dessen, was sie sollten.

• Snowflake: nutzungsbasiert, ca. 2 bis 4 USD pro Credit je nach Edition und Region. Hervorragend für unregelmäßige Workloads und teamweiten SQL-Zugriff. Leicht zu überteuern, wenn Sie das automatische Anhalten des Warehouses nicht auf 60 Sekunden setzen und nicht alle für Ad-hoc-Arbeit auf X-Small zwingen. Ich habe erlebt, dass ein einziger fehlerhafter dbt-Lauf an einem Wochenende 800 USD vernichtet hat.
• BigQuery: pay-per-query zu 6,25 USD/TB gescannte Daten (on-demand), oder Slot-Commitment bei vorhersehbarer Last. Gut, wenn Ihr Traffic wirklich unregelmäßig ist und Sie kein Compute verwalten möchten. Das Slot-Modell ist verwirrend für Erstanwender. Lesen Sie die Dokumentation, bevor Sie sich festlegen.
• Redshift: günstig bei Festlegung auf eine reservierte Instanz, schmerzhaft wenn nicht. Reservierte Instanzen beginnen bei ca. 0,25 USD/Knoten/Stunde und steigen. Das Cluster-Modell wirkt veraltet neben Snowflake/BigQuery, aber wenn Ihr Unternehmen bereits auf AWS ist und Ihr DE-Team es in- und auswendig kennt, ist es verteidigungsfähig.
• Postgres: immer noch die richtige Antwort unter 1 TB. Hören Sie auf, sich dafür zu entschuldigen. Eine verwaltete Postgres-Instanz auf RDS oder Supabase kostet 50 bis 500 USD/Monat und verarbeitet alles, was ein Analytics-Team mittlerer Reife tatsächlich abfragt. Ich habe noch nie einen Sub-1-TB-Workload gesehen, der Snowflake gerechtfertigt hätte. Kein einziges Mal.

Der Entscheidungsbaum: unter 500 GB, Postgres. 500 GB bis 5 TB mit unregelmäßiger Last, BigQuery oder Snowflake. Über 5 TB oder viele parallele Nutzer, Snowflake. Über 50 TB und Sie haben ein DE-Team, Redshift bei Commitment.

2. ELT / Ingestion

Daten in das Data Warehouse bringen. Hier explodieren viele „moderner Stack"-Budgets still und leise.

• Fivetran: 1.000 bis 10.000 USD/Monat je nach Monthly Active Rows. Hervorragend, wenn es funktioniert. Teuer, wenn ein Connector abbricht und Sie zwei Tage auf den Support warten. Ihr Preismodell (MAR) ist undurchsichtig genug, dass ich eine Rechnung von 1.200 USD/Monat auf 7.800 USD in einem Quartal steigen gesehen habe, weil jemand eine geschwätzige Salesforce-Synchronisierung aktiviert hat.
• Airbyte: Open-Source, kostenlos bei Self-Hosting. Cloud-Version beginnt bei ca. 360 USD/Monat für geringe Volumina. Self-Hosting auf einem kleinen EC2- oder GKE-Cluster kostet ca. 200 USD/Monat für Infrastruktur. Der Kompromiss: Sie werden Dinge um 23 Uhr reparieren. Ich habe das getan. Es ist akzeptabel, wenn Sie einen halbwegs guten DE oder einen starken Analytics Engineer haben. Nennen Sie es nicht „kostenlos", wenn Ihr Team es nicht betreiben kann.
• Stitch: mittleres Segment, rückläufig. Akzeptabel, wenn Sie es bereits haben. Ich würde kein neues Unternehmen damit starten.

Mein Standard: Fivetran für die 5 bis 10 wichtigsten Connectors, die wirklich wichtig sind (Salesforce, HubSpot, Stripe, NetSuite, Postgres-Replikate). Airbyte für die lange Liste seltsamer APIs, um die sich sonst niemand kümmert. Betreiben Sie nicht zwei davon gleichzeitig für dieselbe Quelle. Entscheiden Sie sich.

3. Transformation

Diese Schicht ist entschieden. Es ist dbt. Hören Sie auf zu suchen.

• dbt Core: kostenlos, Open-Source. Läuft überall, wo Sie Python ausführen können. Die meisten Analyst-Teams sollten hier beginnen.
• dbt Cloud: 50 USD/Entwickler/Monat für das Team-Tier, 300 USD/Entwickler/Monat für Enterprise. Sie zahlen für die IDE, den Scheduler, das Docs-Hosting und die CI-Integration. Lohnenswert für Teams von 3 oder mehr Analysten ohne Data Engineer. Überspringen Sie es, wenn Sie einen DE haben, der bereit ist, Airflow oder Dagster einzurichten. dbt Core auf Airflow zu betreiben ist in Ordnung, und Airflow selbst ist kostenlos.

Die einzige legitime Alternative ist SQLMesh, und nur wenn Sie in einem Maßstab arbeiten, bei dem dbt's Full-Refresh-Muster wehtut. Für die meisten Unternehmen unter 100 Modellen sind das nicht Sie.

4. BI / Dashboards

Die am stärksten übereingekaufte Schicht. Die meisten Teams haben zwei BI-Tools, weil jemand von einem Tableau-Unternehmen kam und jemand anderes von einem Looker-Unternehmen, und niemand sie zur Entscheidung gezwungen hat.

• Looker: Enterprise-Preise, öffentliche Schätzungen liegen bei 50.000 USD und mehr pro Jahr und steigen schnell. Die semantische Schicht (LookML) ist der Schutzwall. Es ist das einzige BI-Tool, bei dem Data Governance in großem Maßstab wirklich funktioniert. Kaufen Sie es erst, wenn Sie eine echte semantische Schicht aufzubauen haben und eine Person, die sie pflegt. Looker ohne LookML-Eigentümer zu kaufen ist wie einen Ferrari zu kaufen, um ihn in der Garage zu fahren.
• Tableau: 75 USD/Nutzer/Monat für Creator, 42 USD für Explorer, 15 USD für Viewer. Immer noch die schönsten Dashboards auf dem Markt. Schmerzhaft für Data Governance und Versionskontrolle. Gut, wenn Ihre Zielgruppe Führungskräfte sind, denen Optik wichtig ist.
• Hex: 40 bis 80 USD/Nutzer/Monat je nach Tier. Notebooks und Dashboards in einer App. Die richtige Wahl, wenn Ihre Analysten die Hälfte ihrer Zeit mit SQL-Exploration und die andere Hälfte mit stakeholder-gerichteten Berichten verbringen. Ersetzt die „Jupyter für mich, Tableau für sie"-Aufteilung.
• Metabase: Open-Source, kostenlos bei Self-Hosting. Cloud Pro beginnt bei 85 USD/Monat für 5 Nutzer. Die richtige Antwort für Series A und früher. Ehrlich gesagt auch für viele Series B. Ich habe gesehen, wie Metabase eine 40.000-USD-Looker-Lizenz bei Unternehmen übertroffen hat, die noch keine Bedürfnisse auf Ebene der semantischen Schicht hatten.

Meine Regel: ein BI-Tool. Unter 10 Mio. USD ARR, Metabase. Mit LookML-Eigentümer und Führungskräften, die Data Governance fordern, Looker. Wenn Ihre Analysten notebook-first sind, Hex. Tableau, wenn die Führungsebene es ausdrücklich wünscht. Alles andere ist eine Verlängerung, die Sie bereuen werden.

5. Notebook / Exploration

Wo Analysten das unordentliche Denken tatsächlich erledigen, bevor es zu einem Dashboard wird.

• Jupyter: kostenlos, lokal, funktioniert für immer. Der Standard. Kombiniert mit VS Code sind Sie gut aufgestellt.
• Hex: bereits in Ihren Büchern, wenn Sie es für BI gekauft haben. Erschlägt zwei Schichten mit einem Tool. Das ist ein Teil des Grundes, warum Hex's Preise für manche Teams aufgehen.
• Deepnote: Gratis-Tier ist großzügig. Bezahlte Pläne beginnen bei 39 USD/Nutzer/Monat. Starkes kollaboratives Bearbeiten. Lohnenswert, wenn Ihr Team wirklich gemeinsam Notebooks bearbeitet; weniger überzeugend, wenn alle alleine arbeiten.

Wenn Sie Hex für BI gekauft haben, fügen Sie Deepnote nicht hinzu. Wenn nicht, ist Jupyter in Ordnung.

6. Ticket / Aufnahme

Die Schicht, an die die meisten Analysten nicht als Schicht denken. Sie ist es aber.

• Jira, Notion oder Linear: wählen Sie eines. Was das Engineering-Team nutzt, ist meistens gut genug. Der Punkt ist nicht das Tool. Der Punkt ist, die Slack-Direktnachricht als Aufnahmekanal abzuschaffen.

Slack-Direktnachrichten als Analytics-Aufnahme produzieren keine Warteschlange, keine Priorität, kein Prüfprotokoll und unendlich viele „kurze Fragen", die sechs Stunden dauern. Ein echtes Aufnahme-Tool gibt Ihnen eine Warteschlange, ein SLA und einen Datensatz. Behandeln Sie es als Tool.

CRM / Sales-Daten: die Schicht, die die meisten Analysten unterbudgetieren

Hier ist die wenig diskutierte Realität: Die Hälfte der Datenqualitätsprobleme, mit denen Analysten kämpfen, sind CRM-Hygiene-Probleme, die nachgelagert weitergegeben werden. Wenn Ops nach „sauberen B2B-Daten" fragt, lautet die Standardantwort, Salesforce-Exporte durch vier dbt-Transformationen zu leiten, um Kontakte zu deduplizieren, Firmennamen zu normalisieren, Telefonnummern-Formate zu korrigieren und die fehlenden Branchencodes zu ergänzen.

Das ist kein Data Engineering. Das ist das Kompensieren für ein CRM, das beim Schreiben keine Hygiene erzwungen hat.

Rework beginnt bei 12 USD/Nutzer/Monat für CRM und Sales Ops und exportiert saubere B2B-Kontakt- und Pipeline-Daten direkt in Ihr Data Warehouse. Der Bereinigungsdurchlauf, den Sie sonst in dbt durchführen würden, löst sich größtenteils auf, weil die Daten bereits bei der Aufnahme strukturiert sind (Pflichtfelder, validierte Formate, Deduplizierung beim Schreiben). Ich habe Teams von Salesforce-plus-vier-Bereinigungsmodellen weg und hin gesehen, und die dbt-Build-Zeit sank dabei von 22 Minuten auf 6 Minuten.

Das ist keine „Rework gewinnt überall"-Aussage. Wenn Sie Salesforce bei einem 500-Mitarbeitenden-Unternehmen mit 12 Administratoren betreiben, wechseln Sie nicht morgen. Aber wenn Sie in dem Stadium sind, in dem „wir sollten irgendwann Salesforce kaufen" der Plan ist, rechnen Sie zuerst mit Rework durch. Die Einsparungen zeigen sich in der Anzahl der dbt-Modelle, nicht nur im Lizenzpreis.

Der 30-Tage-Stack-Audit (durchführen, bevor Sie irgendetwas kaufen)

Jeder Analyst sollte das einmal im Jahr durchführen. Es rechnet sich in Woche eins.

Tage 1 bis 3: Inventur. Listen Sie jedes Tool, jeden Platz, jede monatliche Rechnung auf. Ziehen Sie das Kreditorenbuchhaltungsprotokoll. Finden Sie den Kreditkartenabschluss. Die meisten Teams finden in Woche eins 10.000 bis 30.000 USD/Jahr an ungenutzten Lizenzen. Das Snowflake-Reader-Konto, das niemand nutzt. Der Tableau-Platz für den Analysten, der im November gegangen ist. Das Census-Abonnement aus der Zeit, als Sie ein Quartal lang Reverse-ETL ausprobiert haben.

Tage 4 bis 10: Kartierung. Ordnen Sie jedes Tool einer der obigen Schichten zu. Alles, das sich nicht zuordnen lässt, bekommt ein „Warum existiert das?"-Gespräch mit dem Vertragsverantwortlichen. Wenn dieser es nicht in zwei Sätzen beantworten kann, ist es ein Streichkandidat.

Tage 11 bis 20: Duplikate finden. Zwei BI-Tools. Zwei ELT-Tools. Drei Dinge, die sich „Datenkataloge" nennen. Wählen Sie eines pro Schicht. Das Duplikat ist der Streichkandidat.

Tage 21 bis 30: Streichliste schreiben. Konkrete Euro-Beträge. Konkrete Gründe. Dem Head of Data mit Belegen präsentieren. Den alternativen Migrationsplan mitbringen, auch wenn es nur „zu Metabase wechseln, hier ist der Zeitplan" ist. Heads of Data hassen vage Streichlisten. Sie lieben konkrete mit Ersatzplänen.

Stack-auf-einer-Serviette-Diagramm (das Ergebnis für Ihren CFO):

Quellsysteme → ELT (Fivetran) → Data Warehouse (Postgres oder Snowflake) → dbt → BI (ein Tool) → Stakeholder
                                          ↑
                                   CRM (Rework)
                                   liefert saubere
                                   Daten hierher
Aufnahme (Jira) verwaltet die Warteschlange.

Wenn Ihre Serviette mehr Boxen als das benötigt, sind Sie überbaut.

Die Streichliste (Anbieter, die ich aus den meisten Stacks entfernen würde)

• Reverse-ETL bei 3 Zielen. Hightouch und Census sind echte Produkte, aber wenn Sie Daten nur zu Salesforce und HubSpot übertragen und das war's, brauchen Sie kein Tool für 24.000 USD/Jahr. Schreiben Sie ein Python-Skript. Planen Sie es in dbt Cloud oder Airflow. Weiter.
• Datenkataloge unter 50 Tabellen. Atlan, Alation, Collibra sind in großem Maßstab großartig. Unter 50 Tabellen schlägt eine Notion-Seite sie und kostet nichts. Kataloge verdienen ihren Platz erst, wenn niemand ohne einen die richtige Tabelle findet.
• „KI-gestützte" Produkte, die ChatGPT um einen SQL-Editor wickeln. Ich habe fünf davon evaluiert. Alle generieren plausibles SQL, das auf subtile Weise falsch ist. Ihre Analysten werden mehr Zeit damit verbringen, es zu korrigieren, als SQL selbst zu schreiben. Warten Sie 18 Monate.
• Observability-Tools bei 12 dbt-Modellen. Monte Carlo, Bigeye, Elementary machen in großem Maßstab Sinn. Bei 12 Modellen ist Ihre „Observability-Schicht" eine dbt-Test-Suite und ein Slack-Alert. Das ist kostenlos.

Häufige Fehler

Looker kaufen, bevor Sie eine semantische Schicht haben. Das sehe ich jedes Quartal. Ein Team kauft Looker für die Governance-Geschichte, stellt dann fest, dass niemand im Team LookML kennt, und zahlt dann einem Berater 200 USD/Stunde, um die semantische Schicht aufzubauen. Zwei Jahre später nutzen sie es immer noch nicht so, wie Looker es beabsichtigt.

Snowflake für einen 200-GB-Workload wählen. Postgres verarbeitet 200 GB auf einer 200 USD/Monat RDS-Instanz. Snowflake verarbeitet es für mindestens 2.000 USD/Monat, sobald Sie Compute, Storage und die Warehouses berücksichtigen, die die Leute vergessen haben anzuhalten. Wenn Ihre Daten in den RAM eines 500-USD-Servers passen, brauchen Sie noch kein Cloud-Data-Warehouse.

dbt Cloud als obligatorisch behandeln. Es ist es nicht. dbt Core plus Airflow plus ein kostenloser GitLab-CI-Runner gibt Ihnen 90 % von dbt Cloud zu 0 % der Kosten. Die 10 %, die Sie verlieren, sind die IDE und die Dokumentationsseite. Beides ist nett. Beides ist nicht obligatorisch.

Jedem Team erlauben, sein eigenes BI-Tool zu kaufen. Marketing kauft Tableau. Sales kauft Looker. Product kauft Hex. Jetzt haben Sie drei semantische Schichten, drei Sätze von Dashboards, die sich widersprechen, und drei Verlängerungen, um die Sie kämpfen müssen. Ein BI-Tool. Hart verhandeln. Die Teams anpassen lassen.

Erfolgsmessung

Sie sind mit dem Audit fertig, wenn:

• Sie jeden Posten im Analytics-Budget, jeden monatlichen Preis und jede bediente Schicht benennen können.
• Die Tooling-Ausgaben pro Analyst verglichen sind. (Mein Ziel: 8.000 bis 15.000 USD pro Analyst und Jahr für alles unterhalb des Data Warehouse plus Warehouse-Compute. Wenn Sie über 25.000 USD pro Analyst liegen, stimmt etwas nicht.)
• Nichts in Ihrem Stack existiert, „weil das die letzte Person eingerichtet hat".

Das ist der Maßstab. Sechs Schichten, echte Preise, verteidigungsfähig gegenüber einem CFO, der noch nie von dbt gehört hat. Wenn Sie diesen Absatz aus dem Stegreif schreiben können, behalten Sie das Budget. Wenn nicht, werden Sie es nicht behalten.

Weiterführende Artikel

• Data Analyst Stellenbeschreibungsvorlage
• Data-Analyst-Karrierepfad
• Data-Analyst-KPIs und Kennzahlen
• Ein Data-Team von Grund auf aufbauen
• Rework CRM pricing