Data-Scientist-Tools und Tech-Stack: Der ehrliche Build-Guide 2026

Lassen Sie mich den Stack beschreiben, den die meisten Data-Science-Teams tatsächlich haben, sogar solche mit Unternehmen im achtstelligen ARR-Bereich dahinter.

Ein Jupyter-Notebook auf dem Laptop von jemandem. Eine CSV-Datei in S3 mit einem Namen wie customers_FINAL_v3_use_this.csv. Eine model.pkl, die jemand vor drei Quartalen per Slack an einen Backend-Ingenieur gesendet hat. Ein Looker-Dashboard, dem niemand vertraut, weil die Joins still immer wieder geändert werden. Eine Confluence-Seite mit dem Titel „ML Architecture", die zuletzt am Tag vor dem Abgang des vorherigen Data-Leads bearbeitet wurde.

Wenn das Ihr Stack ist, liegen Sie nicht zurück. Die meisten Teams sind hier. Die ehrliche Frage ist nicht, ob Ihre Einrichtung peinlich ist. Sie ist, ob Sie hier bleiben oder die langweilige Arbeit machen, um herauszukommen.

Dieser Leitfaden ist für den IC-Data-Scientist (nicht den VP, nicht das Platform-Team), der entweder einen Stack von Grund auf neu aufbauen oder das zusammengeflickte Chaos begutachten muss, das er geerbt hat. Wir werden die Core 6 Schichten durchgehen, die Open-Source-Standardlösungen benennen, die kostenpflichtigen Upgrades benennen und klar sagen, wann jedes davon seinen Preis wert ist. Wenn Sie für diese Rolle richtig einstellen möchten, ist die Data Scientist Stellenbeschreibungsvorlage das Begleitstück.

Warum das jetzt wichtig ist

Modelle in Notebooks verdienen kein Geld. Der Abstand zwischen „Ich habe ein Modell mit 0,87 AUC trainiert" und „das Unternehmen nutzt diese Vorhersage täglich, um eine Entscheidung zu treffen" besteht zu etwa 80% aus Tooling und zu 20% aus Wissenschaft. Niemand hört das gern, besonders der Data Scientist mit einem dreijährigen Statistik-Doktorat, aber es ist wahr.

Der Data Scientist, der den gesamten Stack vom Data Warehouse bis zur Überwachung aufbauen kann, ist derjenige, der befördert wird, Headcount bekommt, Budget bekommt und aufhört, wie ein SQL-ausführendes Kostenzentrum behandelt zu werden. Derjenige, der es nicht kann, liefert weiterhin Notebooks und fragt sich, warum sein Name bei der nächsten Entlassungsrunde auftaucht.

Sie müssen MLOps nicht lieben. Sie müssen darin versiert sein.

Die Core 6: Was jeder ML-Stack tatsächlich braucht

Sechs Schichten. Echte Preise. Wann jede davon den Aufwand wert ist.

Gehen wir jeden einzelnen durch, denn die Tabelle ist der Spickzettel, nicht das Argument.

Data Warehouse / Datenschicht

Snowflake, BigQuery oder Databricks SQL. Wählen Sie das, das Ihr Data-Engineering-Team bereits bezahlt. Wenn es kein Data-Engineering-Team gibt und Sie von Grund auf neu wählen, ist BigQuery am günstigsten für den Start (Pay-per-Query bei 6,25 $/TB gescannt, keine Kosten für inaktive Warehouses) und Snowflake ist am einfachsten mit nicht-technischen Analysten zu teilen.

Der Fehler, den ich wöchentlich sehe: Ein DS-Team, das versucht, „Geld zu sparen", indem es Modelle direkt auf rohen Parquet-Dateien in S3 trainiert, ohne Data-Warehouse-Schicht, jeder Job liest 200 GB neu und schreibt Schemata in Pandas um. Das spart kein Geld. Das verbrennt DS-Stunden, die zehnmal mehr kosten als die vermiedenen Warehouse-Credits. Kaufen Sie das Warehouse. Nutzen Sie dbt für Transformationen darin. Trainieren Sie auf kuratierten Tabellen.

Notebook / IDE

Jupyter ist kostenlos, lokal, für Einzelarbeit ausreichend. Für Teams mit drei oder mehr Personen verdienen sich die kollaborativen Notebooks (Hex bei 40-80 $/User/Mo., Deepnote etwas günstiger) ihren Preis, weil sie SQL, Python und ein veröffentlichbares Artefakt auf einer Leinwand vereinen. Stakeholder können ein Hex-Dokument lesen; sie können Ihr analysis_v7_final.ipynb nicht lesen.

Databricks Notebooks sind mit Databricks-Compute gebündelt. Wenn Sie bereits für den Compute zahlen, sind die Notebooks in Ordnung. Wenn nicht, zahlen Sie Databricks-Plattformpreise für das, was im Wesentlichen ein gehostetes Jupyter ist, und diese Rechnung geht nicht auf.

Unterbewertete Option: VS Code mit der Jupyter-Erweiterung. Kostenlos, schnell, hat echtes Git, Debugger und Erweiterungen. Die meisten Senior Data Scientists, die ich respektiere, nutzen es für ernsthafte Arbeit und reservieren gehostete Notebooks für Erkundung und Stakeholder-Sharing.

Experiment-Tracking

Das ist die Schicht, wo die meisten Teams drei Tools haben, weil niemand eine Entscheidung getroffen hat. Wählen Sie eines.

MLflow ist Open-Source und selbst auf einer kleinen VM für etwa 50 $/Mo. hostbar. Die Tracking-UI ist in Ordnung. Das Modellregister ist funktional. Sie werden vielleicht einen Engineering-Tag für die Einrichtung aufwenden und ein paar Stunden pro Quartal für die Wartung.

Weights & Biases hat die schönste UI in dieser Kategorie, ist am einfachsten mit Stakeholdern zu teilen und es lohnt sich zu bezahlen (zwischen 20 und 100 $ pro User pro Monat je nach Tier), wenn Sie mehr als zwanzig Experimente pro Woche durchführen oder Ihr Team die Vergleichs-Tooling wirklich nutzt. Wenn zwei von Ihnen drei Experimente im Quartal durchführen, ist MLflow ausreichend und W&B ist überdimensioniert.

Neptune.ai ist die günstigere W&B-Alternative mit den meisten derselben Funktionen. Einen Blick wert, wenn W&B's Preisgestaltung Sie abschreckt.

Was auch immer Sie wählen, beenden Sie die anderen. Der schlechteste Experiment-Tracking-Stack ist der, bei dem Alice W&B nutzt, Bob MLflow nutzt und der neue Mitarbeiter TensorBoard öffnet, weil das bei seinem letzten Job der Standard war.

Feature Store

Feast ist Open-Source und kostenlos in Dollar. Es ist nicht kostenlos in Stunden. Sie müssen Redis (oder einen anderen Online-Store) hosten, die Registry einrichten, die Materialisierungsjobs schreiben und alles am Laufen halten. Für ein Zweier-Team mit drei Modellen in der Produktion ist Feast theoretische Infrastruktur, und ein gut organisiertes dbt-Projekt erledigt dieselbe Aufgabe mit einem Zehntel des Wartungsaufwands.

Tecton ist die kostenpflichtige Enterprise-Option. Der Einstiegspreis liegt im sechsstelligen Bereich. Sie ist nur gerechtfertigt, wenn Sie 50+ Modelle in der Produktion mit echter Feature-Wiederverwendung über Teams haben. Ein Zweier-Team, das Tecton kauft, ist das lauteste mögliche Signal für schlechte Kapitalallokation in diesem Bereich.

Databricks Feature Store ist gebündelt, wenn Sie bereits auf Databricks sind. Nutzen Sie ihn, wenn Sie das tun. Wechseln Sie keine Plattformen, um ihn zu bekommen.

Ehrliche Einschätzung: Die meisten Teams mit weniger als zehn Modellen in der Produktion brauchen noch keinen Feature Store. Sie brauchen saubere Feature-Pipelines in dbt und eine Namenskonvention. Überspringen Sie die Feature-Store-Schicht, bis der Schmerz der Feature-Duplizierung über fünf Trainingsjobs hinweg lauter wird als der Schmerz, Feast aufzusetzen.

Modell-Serving

Die Serving-Schicht ist der Bereich, in dem die meisten Stacks über-engineert werden. Vier echte Optionen:

SageMaker ist AWS-nativ, komplex und läuft etwa 0,05 bis 2 $ pro Stunde pro Endpoint je nach Instanz. Es ist die richtige Antwort, wenn Sie AWS bereits intensiv nutzen und einen Platform-Engineer haben, der Endpoints verwaltet. Es ist die falsche Antwort, wenn Sie ein Zweier-DS-Team sind und nur ein Modell hinter einem HTTP-Endpoint haben möchten.

Vertex AI ist das GCP-Äquivalent. Ähnliche Preise, ähnliche Komplexität, ähnliche Vorbehalte.

Modal ist serverless GPU. Sie zahlen pro Sekunde Compute. Es eignet sich hervorragend für spiky Inference (Empfehlungen auf einer wenig frequentierten Website, Batch-Scoring-Jobs, alles, wofür Sie sonst für einen inaktiven Endpoint zahlen würden). Die Entwicklererfahrung ist die beste in dieser Kategorie. Es ist meine Standardempfehlung für unabhängige und kleine Team-Setups.

BentoML ist ein Open-Source-Framework. Sie schreiben Ihre Inference-Logik, BentoML verpackt sie, und Sie deployen das Paket auf Kubernetes (oder Modal, oder Lambda, oder wo auch immer). Kombinieren Sie es mit Modal und Sie haben einen serverlosen GPU-Stack zu Startup-Preisen.

Die Modal-plus-BentoML-Kombination ist das, was ich heute aufbauen würde, wenn ich ein DS-Team von Grund auf ohne Platform-Team starten würde. SageMaker ist das, wozu man sich verpflichtet, wenn man ein Platform-Team und einen Beschaffungsvertrag hat, der bereits AWS-Credits enthält.

Überwachung & Drift-Erkennung

Wenn Sie Modelle in der Produktion haben und keine Überwachung, haben Sie keine Modelle in der Produktion. Sie haben Zeitbomben, bewertet nach AUC.

Evidently ist Open-Source, als Python-Bibliothek oder eigenständiger Service ausführbar. Es ist der richtige Ausgangspunkt. Sie können es in ein Notebook einbinden und grundlegende Drift-Berichte in einem Nachmittag laufen lassen.

WhyLabs hat einen kostenlosen Tier, der skaliert. Solide Wahl, wenn Sie ein gehostetes Dashboard ohne das Budget für Arize möchten.

Arize ist die seriöse kostenpflichtige Option, 1.000-10.000 $/Mo. für Produktionsvolumen. Es lohnt sich zu bezahlen, sobald Sie mehr als fünf Modelle in der Produktion haben oder regulatorische Anforderungen bestehen (Finanzdienstleistungen, Gesundheitswesen, alles mit Wirtschaftsprüfern).

Beginnen Sie mit Evidently kostenlos. Upgraden Sie, wenn die Anzahl der Modelle in der Produktion oder der Compliance-Druck es rechtfertigt. Kaufen Sie Arize nicht, bevor Sie ein Modell haben, das Überwachung benötigt.

Die zentrale Datenquellen-Frage (wo die meisten DS-Stacks verfaulen)

Schlechte Labels rein, schlechte Modelle raus. Das wissen Sie bereits. Was Sie möglicherweise noch nicht verinnerlicht haben, ist, woher die meisten schlechten Labels kommen: das operative System of Record. Das CRM. Das Ticketing-Tool. Das Product-Analytics-Setup, das drei verschiedene PMs auf drei verschiedene Arten über zwei Neuorganisationen hinweg konfiguriert haben.

Wenn Ihr „Kunde hat abgewandert"-Label aus einem CRM kommt, wo Vertriebsmitarbeiter A einen Deal als „Closed Lost - No Decision" markiert, Mitarbeiter B dieselbe Situation als „Lost - Competitor" markiert und Mitarbeiter C den Deal einfach löscht, rettet Sie kein MLflow-Tracking. Ihr Abwanderungsmodell lernt die inkonsistente Datenhygiene Ihrer Mitarbeiter, nicht das Kundenverhalten.

Ein sauberes operatives System of Record ist wichtiger als ein ausgefeilter Feature Store. Es ist nicht glamourös. Es bringt Ihnen keinen Konferenzvortrag. Aber der Data Scientist, der eine Woche damit verbringt, Pipeline-Stage-Definitionen zu korrigieren und Pflichtfeld-Validierungen im CRM durchzusetzen, liefert für die nächsten zwei Jahre bessere Modelle als derjenige, der dreimal den Feature Store wechselt.

Rework CRM zu 12 $/User/Monat bietet Ihnen strukturierte Pipeline-Stages, benutzerdefinierte Felder mit Validierung, ein Event-Log, das Sie in Ihr Warehouse streamen können, und eine zentrale Datenquelle für den Kundenlebenszyklus, von dem Ihre Abwanderungs- und Conversion-Modelle abhängen. Unabhängig davon, welches CRM Sie verwenden, gilt das Prinzip: Die vorgelagerte Datenqualität entscheidet über die nachgelagerte Modellqualität. Korrigieren Sie sie, bevor Sie einen weiteren Hyperparameter optimieren.

Build vs. Buy: Der tatsächliche Entscheidungsbaum

Hier ist die Matrix. Finden Sie Ihre Zeile, bauen Sie entsprechend. Überspringen Sie keine Ebenen.

Überspringen Sie keine Ebenen. Die beiden häufigsten Stack-Fehler, die ich sehe, in der Reihenfolge:

1. Das Zweier-Team, das Tecton gekauft hat, weil jemand einen Konferenzvortrag gesehen hat.
2. Das Achter-Team, das noch alles auf dem Laptop eines Gründers betreibt, weil „wir noch kein MLOps brauchen."

Beides ist schlecht. Das Erste ist Überinvestition ohne Ertrag. Das Zweite ist Unterinvestition, die jede Woche Produktivität und Glaubwürdigkeit kostet.

Das 30-Tage-Stack-Audit

Konkret, Woche für Woche. Führen Sie das durch, egal ob Sie ein Chaos geerbt oder es selbst gebaut haben.

Tage 1-3: Inventarisieren, was tatsächlich eingesetzt wird

Nicht was im Architektur-Slide steht. Was tatsächlich läuft. Öffnen Sie jeden Cron, jeden Airflow DAG, jeden SageMaker-Endpoint, jedes planmäßig ausgeführte Notebook. Erstellen Sie eine Tabelle. Spalten: Tool, Eigentümer, monatliche Kosten, prozentualer Anteil des Teams, das es nutzt, Datum der letzten Nutzung, Kill-Keep-Upgrade.

Sie werden mindestens drei Dinge finden, von deren Existenz Sie nicht wussten.

Tage 4-7: Jedes Modell in der Produktion finden

Für jedes Modell: Wer ist der Eigentümer, auf welchen Daten trainiert es, wann wurde es zuletzt neu trainiert, wie lautet die aktuelle Leistungsmetrik, und ob jemand es bemerken würde, wenn es aufhört zu laufen.

Wenn niemand es bemerken würde, dekommissionieren Sie es. Wenn niemand es besitzt, ist das jetzt Ihr Problem, es zuzuweisen.

Tage 8-14: Überwachung für das am schlechtesten überwachte Modell hinzufügen

Wählen Sie das Modell mit der höchsten geschäftlichen Auswirkung und der schlechtesten Überwachung. Fügen Sie Evidently diese Woche hinzu. Es muss nicht perfekt sein. Ein wöchentlicher Drift-Bericht, der an einen Channel gesendet wird, ist für den Anfang ausreichend.

Tage 15-21: Experiment-Tracking konsolidieren

Wählen Sie ein Tool. Migrieren Sie die aktiven Experimente. Sagen Sie dem Team, die anderen aufzuhören zu verwenden. Archivieren Sie den Rest. Das wird politisch schwieriger sein als es klingt, weil die Person, die das Tool aufgesetzt hat, das Sie abschaffen, es persönlich nehmen wird. Tun Sie es trotzdem.

Tage 22-30: Den Stack in einem README dokumentieren

Ein einzelnes README im Team-Repository. Architekturdiagramm (Boxen und Pfeile, kein Visio-Meisterstück). Zweck, Eigentümer und Login jedes Tools. Das On-Call-Verfahren für jedes Modell in der Produktion. Der nächste DS-Mitarbeiter sollte das in einer Stunde lesen und wissen können, was er erbt.

Nach 30 Tagen können Sie in einem Atemzug antworten: jedes Modell in der Produktion, wer es besitzt, wann es zuletzt neu trainiert wurde, wie der aktuelle Drift aussieht, und welches eine Tool Sie morgen abschalten würden. Wenn Sie das nicht können, ist das Audit nicht abgeschlossen.

Häufige Fallstricke

Die größten Hits, in etwa der Reihenfolge, in der ich sie sehe:

• Tools kaufen, bevor Modelle in der Produktion sind. „Wir brauchen einen Feature Store." Wirklich? Haben Sie Features? Haben Sie ein Modell, das sie nutzt? Kaufen Sie keine Infrastruktur für eine Zukunft, die Sie noch nicht gebaut haben.
• MLflow selbst hosten, ohne Wartungszeit zu budgetieren. Es ist kostenlos in Dollar. Es ist nicht kostenlos in Stunden. Jemand muss die VM gepatcht, die Datenbank gesichert und die Authentifizierung am Laufen halten. Wenn dieser Jemand Sie sind und Sie auch Modelle liefern müssen, kann die Mathematik für die verwaltete Option sprechen.
• Jeden Data Scientist sein eigenes Tool wählen lassen. „Wir verwenden, was sie bei ihrem letzten Job hatten" ist der Weg, wie man mit drei Experiment-Trackern, zwei Feature Stores und einem 40-seitigen Onboarding-Dokument endet.
• Eine „Plattform" aufbauen, bevor Sie drei Modelle haben, die sie rechtfertigen. Die Platform-Team-of-One-Falle. Verallgemeinern Sie nicht, bevor Sie spezifische Dinge haben, von denen aus zu verallgemeinern.
• Das CRM und die operative Datenschicht ignorieren, weil es „kein ML" ist. Es ist die Schicht, die entscheidet, ob Ihre Labels real sind. Es ist die Grundlage von ML, kein Nachbar von ML.

Nützliche Templates

Vier Artefakte für Ihr Team-Repository:

1. Stack-Audit-Tabelle. Tool, monatliche Kosten, Eigentümer, prozentualer Anteil des Teams, das es nutzt, Datum der letzten Nutzung, Kill-Keep-Upgrade-Entscheidung.
2. „Was ist tatsächlich in der Produktion"-Inventar. Modell, Eigentümer, Trainingsdatenquelle, letztes Neutraining, Überwachungsstatus, geschäftliche Auswirkung, On-Call-Verfahren.
3. Build-vs-Buy-Entscheidungsmatrix. Die Tabelle aus diesem Artikel, angepasst für den spezifischen Stack Ihres Teams.
4. Minimal-viables Stack-Repository-Struktur. Ein funktionierendes Beispiel von MLflow plus BentoML plus Evidently zusammengeschaltet, damit der nächste DS-Mitarbeiter es klonen und in seiner ersten Woche ein Modell liefern kann.

Das Fazit

Der schwierigste Teil eines ML-Stacks ist nicht das ML. Es ist die langweilige vorgelagerte Schicht (saubere Labels, saubere Events, eine zentrale Datenquelle) und die langweilige nachgelagerte Schicht (Überwachung, die Sie sich tatsächlich ansehen). Die Mitte (welches Modell, welcher Feature Store, welches Serving-Framework) bekommt die meiste Aufmerksamkeit und ist am wenigsten wichtig.

Tools sind wichtig. Stack-Disziplin ist wichtiger. Der Data Scientist, der das 30-Tage-Audit durchführt, zwei redundante Tools abschaltet und das README schreibt, ist wertvoller als derjenige, der fünf Gradient-Boosting-Bibliotheken benchmarkt.

Wenn Sie für diese Rolle einstellen, legt die Data Scientist Stellenbeschreibungsvorlage die Verantwortlichkeiten und die Messlatte fest. Wenn Sie bereits in der Rolle sind und Ihr Stack wie der einleitende Absatz dieses Leitfadens aussieht, starten Sie das Audit am Montag.

Mehr erfahren

• Ein Tag im Leben eines Data Scientists
• Ihre ersten 30/60/90 Tage als neuer Data Scientist
• Modelle ohne Probleme in die Produktion überführen
• DS-Metriken: Ausgelieferte Modelle, geschäftliche Auswirkung, Modellverfall
• Data Scientist Stellenbeschreibungsvorlage