Databricks

Hallo, hier ist Alex von DEV STORIES DOT EU. Databricks, Folge 1 von 15. Jahrelang haben Unternehmen doppelt gezahlt, um exakt dieselben Daten zu speichern, nur um sowohl ihre Machine Learning Engineers als auch ihre Business Analysts happy zu machen. Rohdaten in einem System zu speichern und sie in ein anderes zu kopieren, sorgt für endlose Sync-Probleme. Databricks löst das durch die Einführung eines einheitlichen Ansatzes namens Data Lakehouse. Historisch gesehen haben Unternehmen ihre Datenarchitektur in zwei separate Pfade aufgeteilt. Zuerst haben sie Data Lakes gebaut. Das sind günstige, hochskalierbare Cloud-Storage-Systeme, perfekt, um riesige Mengen an unstrukturierten Daten abzulegen. Data Scientists lieben sie, um Machine-Learning-Modelle zu trainieren. Aber Data Lakes sind furchtbar für schnelle, zuverlässige SQL-Queries. Um das zu lösen, haben Unternehmen Data Warehouses für ihre Business-Intelligence-Teams eingeführt. Das sorgt für einen massiven operativen Overhead. Nehmen wir ein wachsendes Startup als Beispiel. Ihre Data Engineers legen rohe Event Logs in einem Cloud Storage Bucket ab. Dort führen sie ihre Python-Scripts aus. Aber das Finanzteam braucht Dashboards. Also müssen die Engineers komplexe Pipelines bauen, um diese Daten zu extrahieren, zu transformieren und in ein separates Data Warehouse zu laden. Das Unternehmen zahlt doppelt für den Storage. Sie zahlen für das Compute, das nötig ist, um die Daten zu verschieben. Und in dem Moment, in dem die Daten im Warehouse ankommen, sind sie schon wieder veraltet. Databricks eliminiert diese Pipeline komplett mit der Data-Lakehouse-Architektur. Ein Lakehouse kombiniert den günstigen, flexiblen Storage eines Data Lakes mit der Zuverlässigkeit und Performance eines Data Warehouses. Es belässt deine Daten in einem einzigen, offenen Format direkt in deinem Cloud Storage. Du kopierst sie nicht in eine proprietäre Datenbank. Stattdessen legt Databricks einen Transactional Layer direkt über deinen bestehenden Data Lake. Hier ist der springende Punkt: Deine Daten bleiben an einem einzigen Ort, aber verschiedene Experten interagieren damit genau so, wie sie es brauchen. Data Scientists können Python oder Scala schreiben, um Modelle direkt auf den Raw Files zu trainieren. Gleichzeitig können Business Analysts High-Performance SQL-Queries auf exakt denselben Daten ausführen, um ihre Reporting-Tools zu befeuern. Leute denken oft fälschlicherweise, Databricks wäre nur eine weitere SQL-Datenbank oder einfach ein Managed Wrapper um Apache Spark. Es ist weder das eine noch das andere. Es ist eine umfassende Data Intelligence Platform. Indem du den Lake und das Warehouse zusammenführst, vereinst du auch Security und Governance. Im alten Modell musstest du Access Permissions im Cloud Storage für die Engineers und separat im Data Warehouse für die Analysts verwalten. Mit Databricks übernimmt ein Unified Governance Layer die Access Control über jede Tabelle, jedes File und jedes Machine-Learning-Modell. Du definierst eine Data Access Policy ein einziges Mal, und sie gilt überall, unabhängig von der Sprache oder dem Tool, das für die Query verwendet wird. Die wahre Power der Lakehouse-Architektur liegt nicht nur darin, dass du Geld bei redundanten Storage-Pipelines sparst; sie liegt darin, dass deine AI-Modelle und deine Finanz-Dashboards endlich zur exakt selben Zeit auf die exakt selben Zahlen schauen. Wenn du helfen willst, die Show am Laufen zu halten, kannst du auf Patreon nach DevStoriesEU suchen. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Databricks, Folge 2 von 15. Wenn dein Unternehmen mehrere Workspaces zur Datenverarbeitung nutzt, verwaltest du wahrscheinlich auch Permissions an mehreren Stellen. Diese Fragmentierung ist ein massives Compliance-Risiko, denn um Policies über getrennte Umgebungen hinweg synchron zu halten, bist du komplett auf manuelle Updates angewiesen. Unity Catalog beseitigt dieses Risiko, indem es grundlegend verändert, wie Data Governance in Databricks funktioniert. Bevor wir uns ansehen, wie das Ganze funktioniert, müssen wir ein sehr häufiges Missverständnis ausräumen. Unity Catalog ist kein passives Data Dictionary. Es ist nicht einfach nur eine Liste von Tabellen, in der User Beschreibungen nachlesen. Es ist die zentrale Policy Engine, die aktiv Security-Regeln in deiner gesamten Architektur durchsetzt. Unity Catalog löst das ständige Problem, genau zu wissen, wer worauf Zugriff hat. Es bietet ein einheitliches Security-Modell basierend auf Standard-ANSI-SQL. Anstatt Cloud Identity Roles, Workspace-Level Permissions und Cluster-Level Access Controls separat zu konfigurieren, nutzt du vertraute Commands wie grant und revoke direkt auf deinen Daten und AI Assets. Weil Unity Catalog auf dem Account-Level sitzt, anstatt an einen einzelnen Workspace gebunden zu sein, definierst du eine Security-Regel genau einmal. Diese Regel wird dann sofort und universell in jedem Workspace durchgesetzt, der mit diesem Catalog verknüpft ist. Stell dir eine Situation vor, in der ein Auditor einen CTO bittet, genau nachzuweisen, wer letzten Dienstag eine bestimmte Tabelle mit Kreditkartennummern gequeryt hat, und jeden Downstream Report zu identifizieren, der diese Nummern aktuell nutzt. Das zu beantworten bedeutete in der Vergangenheit, unzusammenhängende System Logs über verschiedene Tools hinweg zu parsen, Scheduled Transformation Jobs manuell zu lesen und zu hoffen, dass keine Zwischenschritte übersehen wurden. Unity Catalog übernimmt das nativ durch seine nächsten beiden Säulen: Built-in Auditing und Automated Lineage. Erstens erfasst es out of the box detaillierte Audit Logs auf User-Level. Jedes Mal, wenn ein User oder ein Service Principal auf Daten zugreift, zeichnet der Catalog das Event auf. Hier ist der entscheidende Punkt. Unity Catalog trackt nicht nur, wer eine Tabelle gequeryt hat; es trackt durch Automated Lineage auch, was als Nächstes mit den Daten passiert. Während deine Scheduled Pipelines laufen, liest das System kontinuierlich die Execution Plans und erstellt eine Map davon, wie die Daten fließen. Es trackt, welche Source Tables welche Intermediate Datasets befüllen, bis hinunter zu den finalen Dashboards. Es trackt das sowohl auf Table-Level als auch auf Column-Level. Wenn der Auditor nach den Kreditkartendaten fragt, musst du nicht raten. Du schaust dir den Lineage Graph an und siehst sofort jeden Transformation Step und jeden Access Point. Die letzte große Säule ist Secure Data Sharing. Organisationen müssen oft Datasets mit externen Anbietern oder separaten Business Units teilen. Anstatt Flat Files zu exportieren oder Daten in separate Cloud Storage Buckets zu duplizieren, integriert Unity Catalog ein Protokoll namens Delta Sharing. Das erlaubt es dir, externen Parteien Governed Access auf Live-Daten zu gewähren, ohne sie zu kopieren. Der externe Consumer liest die Daten in place, und sein Zugriff wird von exakt demselben zentralen Brain geloggt und kontrolliert. Der wahre Wert von Unity Catalog ist, dass es die gefährliche Lücke zwischen dem Schreiben einer Security Policy auf dem Papier und dem tatsächlichen Ausführen über isolierte Data Silos hinweg komplett beseitigt. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Databricks, Folge 3 von 15. Am schnellsten verbrennst du dein Cloud-Budget, wenn du einen riesigen Server das ganze Wochenende leer laufen lässt. Du willst Processing Power genau dann, wenn du sie brauchst, und null Kosten, wenn nicht. Genau darum geht es heute in Navigating the Workspace and Compute. Dein Einstiegspunkt in Databricks ist der Workspace. Stell dir den Workspace als die zentrale Umgebung vor, in der dein Team alle seine Databricks-Assets organisiert. Er bietet ein Web-Interface, um deine Notebooks, Data Objects, Machine-Learning-Experimente und die zugrunde liegenden Compute-Ressourcen zu verwalten. Der Workspace bringt all deine Collaboration-Tools in eine übersichtliche Ansicht und stellt sicher, dass verschiedene Teams mit denselben zugrunde liegenden Daten arbeiten können, ohne sich gegenseitig auf die Füße zu treten. Unter der Haube setzt Databricks auf eine Decoupled Architecture. Deine Daten liegen persistent im Cloud Object Storage, während die Compute-Power zur Verarbeitung dieser Daten komplett separat hochgefahren wird. Diese Separation of Concerns bestimmt dein Billing. Weil Compute vom Storage isoliert ist, provisionierst und bezahlst du Server-Instanzen nur dann, wenn du aktiv Code ausführst. Wenn die Arbeit erledigt ist, fährt das Compute herunter, aber deine Daten bleiben sicher gespeichert und zugänglich. Um diese Processing Power zu managen, bietet Databricks verschiedene Arten von Compute-Ressourcen, die auf spezifische Workflows zugeschnitten sind. Die erste ist ein All-Purpose Cluster. Den nutzt du für interaktive Ad-hoc-Arbeiten. Sagen wir, ein Data Analyst braucht an einem Dienstagnachmittag eine leistungsstarke Umgebung, um eine Milliarde Rows abzufragen. Er fährt einen All-Purpose Cluster hoch, hängt sein Notebook an und fängt an zu explorieren. Um Billing-Überraschungen am Wochenende zu vermeiden, setzen diese Cluster auf Auto-Termination. Wenn der Analyst um fünf nach Hause geht und das Notebook offen lässt, überwacht sich der Cluster selbst auf Inaktivität und fährt nach einem festgelegten Time-Limit automatisch herunter. Hier ist der wichtigste Punkt in Sachen Automation. Ein häufiger Fehler von Teams ist es, automatisierte Production Pipelines so zu schedulen, dass sie auf diesen interaktiven All-Purpose Clustern laufen. Vermeide das unbedingt. All-Purpose Cluster haben höhere Nutzungskosten, und wenn du mehrere verschiedene Workflows auf einem Shared Interactive Cluster laufen lässt, kann das zu Library-Konflikten oder Resource Contention führen. Stattdessen sollten Production Pipelines Job Cluster verwenden. Ein Job Cluster ist komplett ephemeral. Wenn eine automatisierte Pipeline getriggert wird, provisioniert der Databricks Job Scheduler einen dedizierten Job Cluster exklusiv für diesen Workload. Er führt den Code aus, und in der absoluten Sekunde, in der der Job fertig ist, terminiert sich der Cluster selbst. Das garantiert eine strikte Resource Isolation für deine Pipeline und stellt sicher, dass du die niedrigstmögliche Compute Rate für automatisierte Tasks zahlst. Zu guter Letzt: Wenn dein Workload rein analytisch ist, kannst du ein SQL Warehouse nutzen. Das ist eine Compute-Ressource, die speziell für das Ausführen von SQL Commands und Dashboard Queries optimiert ist. Wenn du Serverless SQL Warehouses nutzt, managt Databricks das zugrunde liegende Compute automatisch. Es skaliert sofort hoch, wenn ein Ansturm von Queries reinkommt, und skaliert wieder runter, wenn sich die Queue leert. Dadurch musst du die Infrastruktur überhaupt nicht mehr selbst konfigurieren. Den richtigen Compute-Typ an die genaue Art deines Tasks anzupassen, ist der mit Abstand effektivste Weg, um zu garantieren, dass deine Cloud-Infrastruktur während der Peak Hours leistungsstark bleibt und nach Abschluss der Arbeit extrem kosteneffizient ist. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Databricks, Folge 4 von 15. Du baust einen Data Lake, aber schon nach wenigen Monaten weiß niemand mehr, wo die Production Data liegt, wem sie gehört oder ob man eine bestimmte Table eigentlich sicher queryen kann. Der Unterschied zwischen einem sauberen Data Lake und einem unbeherrschbaren Data Swamp ist genau drei Level tief. Heute schauen wir uns an, wie du deine Daten organisierst: das Object Model. Unity Catalog bringt Ordnung in deine Daten durch eine strikte, vorhersehbare Hierarchie. Der absolute Top-Container ist der Metastore, der die Metadaten deiner Organisation enthält. Aber deine tägliche Arbeit basiert auf dem primären dreistufigen Namespace. Jede Query, die du schreibst, zielt auf ein Asset im Format catalog dot schema dot object ab. Das erste Level ist der Catalog. Dieser bildet eine grobe Grenze für Data Assets. Typischerweise nutzt du Catalogs, um Environments logisch zu trennen, zum Beispiel einen Catalog für Production und einen komplett separaten für Development. Das zweite Level ist das Schema, das auch als Database bezeichnet wird. Schemas leben innerhalb von Catalogs und organisieren zusammengehörige Datasets. Du könntest ein Schema für raw ingested Events und ein weiteres für refined Analytics erstellen. Das dritte Level ist das Object selbst. Das ist deine eigentliche Table, eine View oder ein Volume, das non-tabular Files enthält. Durch das Erzwingen dieser dreiteiligen Naming Convention gibt Unity Catalog jedem Datenelement eine klare, eindeutige Adresse. Wenn ein Analyst production dot sales dot customers queryt, sind der Speicherort, die Lifecycle Stage und der Zweck dieser Daten sofort klar. Hier ist die wichtigste Erkenntnis: Sobald du das Table-Level erreichst, musst du verstehen, wie Unity Catalog mit deinem eigentlichen Storage interagiert. Es gibt zwei primäre Arten von Tables: Managed Tables und External Tables. Managed Tables sind der Default. Wenn du eine Managed Table erstellst, besitzt Unity Catalog sowohl die Metadaten als auch die zugrundeliegenden Daten. Er kümmert sich um das File Layout und managt den gesamten Lifecycle der Daten. Die eigentlichen Files werden an einer festgelegten Storage Location gespeichert, die du auf Metastore-, Catalog- oder Schema-Level konfigurierst. External Tables funktionieren anders. Du nutzt eine External Table, wenn deine Files bereits in einem Cloud Storage Bucket liegen und du sie genau dort lassen willst, wo sie sind. Bei einer External Table registriert Unity Catalog die Struktur und regelt den Access, besitzt aber nur die Metadaten. Du behältst die volle Kontrolle über die physischen Files. Diese Unterscheidung wird bei destruktiven Operationen extrem wichtig. Stell dir ein Szenario vor, in dem ein Data Engineer versehentlich einen Drop Table Command ausführt. Wenn er eine Managed Table droppt, entfernt Unity Catalog die Table aus dem Metastore und löscht automatisch die zugrundeliegenden Files aus deinem Cloud Storage. Die Daten sind zerstört. Wenn er eine External Table droppt, entfernt Unity Catalog einfach nur den Metadata Link. Die Table verschwindet aus deinem Workspace Interface, aber die Raw Files in deinem Cloud Storage bleiben völlig intakt und unangetastet. Nutze immer Managed Tables, wenn der Catalog den gesamten Storage Lifecycle optimieren und verwalten soll, und reserviere External Tables für Daten, die du vor versehentlichem Löschen schützen oder direkt mit anderen externen Systemen teilen musst. Danke fürs Dabeisein. Ich hoffe, du hast etwas Neues gelernt.

Hallo, hier ist Alex von DEV STORIES DOT EU. Databricks, Folge 5 von 15. In einer relationalen Datenbank kannst du problemlos einschränken, wer eine Spalte sieht. Aber wie setzt du Access Control bei einem Cloud Storage Bucket mit Tausenden von Raw PDFs durch? Die Antwort lautet: Unstrukturierte Daten mit Volumes bändigen. Bevor wir uns ansehen, wie sie funktionieren, lass uns ein häufiges Missverständnis klären. Volumes sind ausschließlich für pfadbasierten Dateizugriff gedacht. Sie sind nicht für tabellarische Daten. Wenn du Zeilen und Spalten mit SQL abfragst, benutzt du eine Tabelle. Wenn du Bilder, Textdokumente oder Audiodateien liest, benutzt du ein Volume. Ein Volume ist ein Objekt im Unity Catalog. Es repräsentiert einen logischen Speicherplatz in deiner Cloud-Umgebung. Indem du ein Volume erstellst, bringst du unstrukturierte Daten unter genau denselben Sicherheitsschirm wie deine strukturierten Tabellen. Anstatt Identity Policies in AWS oder Role Assignments in Azure zu verwalten, nur um eine Datei zu lesen, steuerst du den Zugriff über Standardberechtigungen direkt in Databricks. Stell dir ein Krankenhaus vor, das ein Machine Learning Model trainiert, um Anomalien in Röntgenbildern zu erkennen. Sie können nicht Tausende von hochauflösenden Bildern in eine Datenbanktabelle packen. Sie müssen sie als Raw Files in einem Cloud Object Storage speichern. Weil das hochsensible Patientendateien sind, ist strikte Governance extrem wichtig. Indem sie die Röntgenbilder in ein Databricks-Volume legen, kann das Engineering-Team genau steuern, welche Data Scientists dieses spezifische Directory lesen dürfen. Es gibt zwei Arten von Volumes: Managed und External. Ein Managed Volume wird komplett von Databricks verwaltet. Wenn du eins erstellst, gibst du keinen Storage Path an. Databricks reserviert einfach Platz in der Default Storage Location, die deinem aktuellen Schema zugewiesen ist. Du lädst Dateien direkt dort hoch. Wenn du ein Managed Volume droppst, löscht Databricks auch die zugrundeliegenden Dateien. Das macht sie ideal für temporäre Workspace-Dateien oder Daten, die komplett innerhalb deiner Databricks-Pipelines generiert werden. Ein External Volume zeigt auf ein existierendes Cloud Storage Directory, das dir bereits gehört. Zuerst registrierst du einen Cloud Storage Path als External Location im Unity Catalog. Dann erstellst du ein Volume darauf. Das gibt dir strikte Governance über Daten, die von anderen Systemen produziert werden. Wenn eine separate Application Log Files in einen Azure Data Lake Bucket schreibt, können Databricks-User diese Dateien über ein External Volume sicher lesen. Wenn du ein External Volume droppst, werden die Metadaten entfernt, aber die zugrundeliegenden Dateien in deinem Cloud Bucket bleiben komplett unangetastet. Dieser pfadbasierte Ansatz ist genau das, was moderne AI braucht. Open-Source Machine Learning Libraries erwarten normalerweise, Daten von einem lokalen File System zu lesen. Sie wissen nicht, wie sie sich bei proprietären Cloud Storage Interfaces authentifizieren sollen. Volumes lösen das, indem sie einen Directory Path bereitstellen, der wie ein normaler lokaler Ordner aussieht und sich auch so verhält. Dein Model Training Script öffnet einfach einen File Path. Unity Catalog fängt diesen Request ab und verifiziert nahtlos die User Permissions. Hier ist die wichtigste Erkenntnis: Volumes eliminieren die Diskrepanz dazwischen, wie du deine strukturierten Datenbanken verwaltest und wie du deine Raw Files absicherst. So kannst du Machine Learning Workloads auf unstrukturierten Daten ausführen, ohne die Enterprise Security zu umgehen. Das war's für diese Folge. Danke fürs Zuhören, und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Databricks, Folge 6 von 15. Wenn deine Data Engineers immer noch Cloud Access Keys direkt in ihre Skripte pasten, ist dein Unternehmen nur einen Fehler von einem massiven Data Breach entfernt. Die Lösung, um deinen Workspace und deinen Cloud Storage sicher zu verbinden, ohne Secrets preiszugeben, ist Bulletproof Cloud Security: External Locations. Wenn sich ein User bei Databricks anmeldet, verwendet er ein Identity Token. Dieses Token beweist dem Workspace, wer er ist. Aber diese Identity bedeutet deinem zugrundeliegenden Cloud Provider – egal ob AWS, Azure oder Google Cloud – absolut gar nichts. Um ein File aus einem Cloud Bucket zu lesen, muss sich der Workspace selbst bei der Cloud-Infrastruktur authentifizieren. In der Vergangenheit haben Developer diesen Disconnect umgangen, indem sie Cloud IAM Keys direkt in ihre Notebooks oder Environment Variables gehardcodet haben. Das erzeugt eine gravierende Security Vulnerability, da jeder mit Read Access auf den Code die Keys stehlen kann. Unity Catalog löst das durch eine strikte zweiteilige Abstraktion. Der erste Teil ist das Storage Credential. Ein Storage Credential repräsentiert einen Authentifizierungs- und Autorisierungsmechanismus, der direkt an deinen Cloud Provider gekoppelt ist. Es mappt auf eine IAM Role in AWS, eine Managed Identity in Azure oder einen Service Account in Google Cloud. Anstatt einem Developer rohe Cloud Keys zu geben, erteilt dein Cloud Admin Access Privileges für dieses Storage Credential. Unity Catalog hat die Berechtigung, diese Role zu assumen, und hält das eigentliche Credential komplett von den Workspace Usern fern. Nun ist ein Storage Credential allein aber zu weit gefasst. Diese IAM Role hat vielleicht die Permission, auf Dutzende verschiedene Buckets in deiner Cloud-Umgebung zuzugreifen. Hier kommt der zweite Teil ins Spiel. Eine External Location verknüpft ein Storage Credential mit einem spezifischen Cloud Storage Path, wie zum Beispiel einer S3 Bucket URI oder einem Azure Data Lake Storage Container Path. Sie definiert exakt, wo dieses Credential operieren darf. Du kannst dir das wie eine geografische Grenze für deine Cloud Credentials vorstellen. Nehmen wir ein konkretes Szenario. Ein Developer muss System Logs analysieren, die in einem hochsicheren S3 Bucket gespeichert sind. In einem Legacy Setup würde ein Admin AWS Access Keys generieren und sie dem Developer schicken, in der Hoffnung, dass dieser die Keys nicht versehentlich in ein öffentliches Code Repository committet. Mit Unity Catalog ändert sich der Workflow komplett. Der Admin erstellt ein Storage Credential, das mit einer IAM Role konfiguriert ist, die den Target Bucket lesen kann. Als Nächstes erstellt der Admin eine External Location, die strikt auf den S3 Path mit den System Logs zeigt, und hängt das Storage Credential daran an. Zu guter Letzt erteilt der Admin dem Developer über Standard-SQL die Permission, Files exklusiv an dieser External Location zu lesen. Wenn der Developer eine Query gegen die Logs ausführt, schaltet sich Unity Catalog ein und übernimmt transparent die Cloud-Authentifizierung für ihn. Der Developer sieht niemals einen AWS Key. Er managt keine Secrets und konfiguriert keine Cloud Profiles. Er führt einfach nur Queries auf den erlaubten Path aus. Später kannst du External Tables oder External Volumes direkt auf dieser Location aufbauen, um die Daten weiter zu organisieren. Wenn der Developer in ein anderes Team wechselt, revoked der Admin einfach seinen Grant für die External Location in Databricks. Die zugrundeliegende Cloud IAM Configuration bleibt dabei komplett unangetastet. Hier ist die entscheidende Erkenntnis. External Locations entkoppeln die Security deiner Cloud-Infrastruktur von deiner täglichen Data Access Governance. Indem du IAM Roles aus dem User Code heraushältst und sie an explizite Paths bindest, garantierst du, dass jeder Data Request auditierbar, sicher und komplett auf die Daten beschränkt ist, die du auch wirklich teilen willst. Danke, dass du dir ein paar Minuten Zeit für mich genommen hast. Bis zum nächsten Mal, mach's gut.

Hallo, hier ist Alex von DEV STORIES DOT EU. Databricks, Folge 7 von 15. Data Engineers verbringen unglaublich viel Zeit damit, anfällige API-Ingestion-Scripts am Laufen zu halten. Wenn ein Endpoint seine Pagination-Logik ändert oder ein Rate Limit sinkt, schlägt deine Pipeline fehl, und du verbringst den Nachmittag mit dem Debugging von JSON, anstatt Datenmodelle zu bauen. Die Lösung für genau dieses Problem ist Lakeflow Connect. Bevor wir uns anschauen, wie das funktioniert, lass uns eine häufige Namensverwirrung klären. Databricks hat Lakeflow Jobs und Lakeflow Connect. Lakeflow Jobs übernimmt die Orchestration, das heißt, es führt Tasks in einer bestimmten Reihenfolge aus. Bei Lakeflow Connect geht es ausschließlich um Ingestion. Es ist der Mechanismus, um Raw Data aus externen Systemen in deine Databricks-Umgebung zu bekommen. Im Kern bietet Lakeflow Connect Managed Connectors. Das sind native, speziell entwickelte Integrationen für Enterprise-Anwendungen und Datenbanken. Wenn du Daten aus externen Systemen ziehen musst, schreibst du normalerweise Custom Python Code. Dieser Code muss die Authentifizierung managen, Retries handhaben, wenn der Server die Connection droppt, tracken, welche Records schon ingested wurden, und komplexe Pagination parsen. Managed Connectors eliminieren diese komplette Schicht an Custom Infrastructure. Databricks übernimmt das zugrundeliegende Compute, die API-Interaktionen und das State Tracking, das für inkrementelle Reads nötig ist. Weil Lakeflow Connect auf Serverless Compute läuft, musst du keine Cluster konfigurieren oder managen, nur um Daten reinzuziehen. Der Service skaliert automatisch, basierend auf dem Volumen der eingehenden Daten. Er integriert sich auch direkt mit dem Unity Catalog, was bedeutet, dass die Daten, die du ingestest, sofort governed und für Queries verfügbar sind. Stell dir eine typische Anforderung vor. Dein Marketing-Team braucht aktuelle Salesforce-Daten in eurem Lakehouse. Wenn du das from scratch baust, verbringst du vielleicht eine Woche damit, ein Custom Script zu schreiben, das die Salesforce-API abfragt. Du musst Logik schreiben, um unter den strengen API-Limits zu bleiben, Token Refreshes zu managen und Updates in deine bestehenden Delta-Tabellen zu mergen, ohne Records zu duplizieren. Mit einem Managed Connector in Lakeflow Connect umgehst du den Custom Code komplett. Du gibst die Connection Credentials an, wählst die spezifischen Salesforce-Objekte aus, die du tracken willst, und legst einen Destination Catalog und ein Schema fest. Das Setup dauert ein paar Minuten. Databricks übernimmt die Execution. Es zieht den initialen historischen Snapshot deiner Daten und geht dann dazu über, kontinuierlich inkrementelle Änderungen zu erfassen, sobald sie passieren. Hier ist der entscheidende Punkt. Indem du den Ingestion-Workload auf einen Managed Connector verlagerst, musst du keine Polling-Scripts mehr maintainen. Wenn sich eine externe API-Spezifikation ändert, updatet Databricks den Connector im Hintergrund. Deine Pipeline läuft einfach weiter. So kannst du dich auf die eigentliche Business-Logik konzentrieren, wie das Transformieren von Raw Data in Aggregate Tables oder das Trainieren von Machine-Learning-Modellen, anstatt ein kaputtes Extraction-Script zu babysitten. Der wahre Wert von Lakeflow Connect ist nicht nur das schnelle Setup, sondern das dauerhafte Entfernen von Custom Ingestion Code aus deinem Maintenance Backlog. Wenn du helfen willst, die Show am Laufen zu halten, kannst du auf Patreon nach DevStoriesEU suchen und uns dort unterstützen. Danke, dass du ein paar Minuten mit mir verbracht hast. Bis zum nächsten Mal, mach's gut.

Hallo, hier ist Alex von DEV STORIES DOT EU. Databricks, Folge 8 von 15. Du hast eine komplexe ETL-Pipeline, bei der eine Tabelle stündlich und eine andere kontinuierlich aktualisiert wird, und die Orchestrierung der Dependencies erfordert hunderte Zeilen State-Management-Code. Was wäre, wenn du einfach die gewünschten finalen Tabellen deklarieren könntest und die Engine die Infrastruktur baut, um sie aktuell zu halten? Das ist die Prämisse von Automated ETL mit Declarative Pipelines. In einer traditionellen imperativen Pipeline sagst du dem System genau, wie es seinen Job machen soll. Du schreibst den Code, um Checkpoints zu managen, Retries zu handlen, Dependencies zu mappen und Cluster zu provisionieren. Declarative Pipelines drehen dieses Modell um. Du legst einfach fest, wie die finale Tabelle aussehen soll, meistens mit einer Standard-SQL-Query oder einer Python-Funktion. Die zugrundeliegende Engine baut den Execution Graph, managt die Infrastruktur und kümmert sich automatisch um die State Transitions. Damit das funktioniert, setzt Databricks auf zwei spezifische Tabellentypen. Ein häufiger Fehler ist, sie als austauschbar zu betrachten. Das sind sie aber nicht. Du musst deine Append-Only-Event-Daten klar von deinen komplexen Aggregationen trennen. Der erste Typ ist die Streaming Table. Streaming Tables sind strikt für inkrementelles Append-Only-Processing konzipiert. Sie lesen kontinuierlich oder in Batches aus einer Data Source, verarbeiten nur die neuen Records und hängen sie an das Target an. Stell dir vor, du verarbeitest einen riesigen Stream von Website-Klicks, die aus Kafka kommen. Du schreibst eine Query, um eine Streaming Table aus diesem Kafka-Topic zu befüllen. Du schreibst keinen Code, um Offsets zu tracken oder dir zu merken, welche Messages schon gelesen wurden. Die Pipeline verwaltet den State intern und stellt sicher, dass jeder Klick genau einmal verarbeitet wird, selbst wenn das System neu startet. Nun zum zweiten Teil des Ganzen. Sobald du deine Raw Events sicher gespeichert hast, musst du sie normalerweise transformieren. Hier kommen Materialized Views ins Spiel. Während Streaming Tables den initialen Ingest von neuen Daten übernehmen, sind Materialized Views für komplexe Aggregationen, Joins und Records gebaut, die sich im Laufe der Zeit updaten oder gelöscht werden. Um auf unsere Website-Klicks zurückzukommen: Du brauchst ein tägliches Executive Dashboard, das die gesamten Klicks gruppiert nach Region anzeigt. Du definierst eine Materialized View, die Daten aus deiner Streaming Table abfragt und die Aggregation ausführt. Wenn die Pipeline läuft, evaluiert die Engine die Materialized View. Sie ermittelt den effizientesten Weg, die View zu aktualisieren. Wenn sie die Änderungen inkrementell berechnen kann, tut sie das. Wenn ein Full Recompute nötig ist, übernimmt sie das automatisch. Du schreibst niemals selbst die Logik, die vorgibt, wann ein Refresh stattfindet oder wie die neuen Aggregationen gemerged werden. Hier ist die entscheidende Erkenntnis: Weil du sowohl die Streaming Tables als auch die Materialized Views deklarativ definierst, versteht die Databricks-Engine die komplette Lineage deiner Daten. Sie weiß, dass die Materialized View von der Streaming Table abhängt. Sie verknüpft sie zu einem einheitlichen Pipeline Graph. Wenn ein Compute Node mitten in der Verarbeitung ausfällt, verlässt sich die Pipeline auf diesen Graphen, um zu pausieren, einen Retry zu machen und fortzufahren, ohne Records zu duplizieren oder das finale Dashboard zu korrumpieren. Deine Codebase ist nicht länger mit operativem Scaffolding überladen. Sie enthält nur noch die reine Business Logic, die definiert, wie die Daten von der Source zur Destination fließen. Das war’s für diese Folge. Danke fürs Zuhören, und keep building!

Hi, hier ist Alex von DEV STORIES DOT EU. Databricks, Folge 9 von 15. Wenn deine nächtliche Datenverarbeitung auf einer Chain unabhängiger Cron Schedules basiert, hoffst du im Grunde nur darauf, dass der vorherige Schritt rechtzeitig fertig geworden ist. Du bist im Blindflug unterwegs. Um Silent Failures zu verhindern und die Execution Order zu garantieren, brauchst du Master Orchestration mit Lakeflow Jobs. Zuerst eine kurze Unterscheidung. Lakeflow Pipelines kümmern sich um Data Dependencies unten auf der Table-Ebene. Lakeflow Jobs, auf die wir uns jetzt konzentrieren, orchestrieren Tasks auf der Makroebene. Stell dir vor, dass Pipelines Daten innerhalb des Data Warehouses verschieben, während Jobs Notebooks, Python-Scripts und Machine Learning Models zu einem größeren Workflow verknüpfen. Ein Job in Databricks ist der übergeordnete Container für deine Orchestrierung. Innerhalb dieses Containers definierst du mehrere Tasks. Ein Task ist eine einzelne, isolierte Unit of Work. Das kann das Ausführen eines Databricks-Notebooks sein, das Submitten einer Spark-Application, das Ausführen eines dbt-Projects oder das Abfeuern einer SQL-Query. Indem du diese Tasks miteinander verknüpfst, baust du einen Execution Graph, bei dem ein Task erst dann beginnt, wenn seine spezifischen Voraussetzungen erfolgreich abgeschlossen sind. Lass uns ein praktisches Szenario durchgehen, um zu sehen, wie der Control Flow für Zuverlässigkeit sorgt. Du hast einen täglichen Prozess, der Raw Data ingested, die Qualität checkt, sie transformiert und das Team alarmiert, wenn etwas schiefgeht. Du beginnst damit, einen Ingestion Task zu definieren. Als Nächstes verknüpfst du einen Data Quality Task, der strikt nach Abschluss der Ingestion läuft. Hier ist die entscheidende Erkenntnis. Anstatt Custom Error Handling in deinem Python-Code zu schreiben, um zu entscheiden, was als Nächstes passiert, nutzt du den nativen Job Control Flow. Du fügst direkt nach dem Quality Check einen If-Else Condition Task hinzu. Die Condition wertet eine Variable aus, die von deinem Data Check Task zurückgegeben wird. Wenn die Daten sauber sind, folgt der Job dem If-Branch und triggert deinen Downstream Transformation Task. Wenn die Daten fehlerhaft sind, nimmt der Job den Else-Branch und triggert einen Webhook Task, der einen Slack Channel anpingt. Du managst den State auch über Run-If Task Conditions. Du kannst einen Alerting Task so konfigurieren, dass er nur ausgeführt wird, wenn der vorherige Task komplett fehlgeschlagen ist, während der Rest der Pipeline sicher anhält. Das verhindert die klassische Silent Failure Cascade, bei der ein kaputter Ingestion-Schritt still und heimlich ein Machine Learning Model triggert, das dann auf komplett leeren Tables trainiert. Um diesen Workflow zu initiieren, wendest du einen Trigger an. Jobs können On-Demand, in einem traditionellen Scheduled Interval oder kontinuierlich laufen. Sie können auch basierend auf einem Event ausgeführt werden, zum Beispiel wenn ein neues File in einem externen Cloud Storage Bucket ankommt. Sobald sie getriggert wurden, bietet Databricks built-in Observability. Du musst nicht raten, wo ein Fehler aufgetreten ist. Die Plattform zeichnet eine komplette Run History mit einer Matrix View auf, die dir genau zeigt, welcher Task erfolgreich war, welcher Task hängen geblieben ist und wie lange jeder Schritt gedauert hat. Du kannst Notifications auf Job-Level oder Task-Level konfigurieren, um automatisierte E-Mails oder Webhooks zu senden, sobald sich ein Execution State ändert. Der wahre Wert dieses Orchestration Models liegt darin, das Failure Handling aus deinen einzelnen Scripts in die Plattform-Infrastruktur zu verlagern. So wird sichergestellt, dass dein System genau weiß, wie es die Execution routen muss, wenn unweigerlich mal etwas kaputtgeht. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Databricks, Folge 10 von 15. Daten aus deinem Data Lake zu verschieben, nur damit dein Business-Intelligence-Team Queries darauf ausführen kann, ist langsam, teuer und völlig unnötig. Am Ende pflegst du fragile Pipelines, nur um Daten von einem System in ein anderes zu kopieren, was zu Verzögerungen und doppelten Storage-Kosten führt. Genau dieses Problem löst Databricks SQL. Es gibt den weit verbreiteten Irrglauben, dass Databricks ausschließlich für Data Engineers und Data Scientists gedacht ist, die Python oder Scala schreiben. Databricks SQL räumt damit auf. Es ist ein dedizierter Workspace, der komplett für SQL-Anwender entwickelt wurde. Stell dir ein Business-Intelligence-Team vor, das von einem Legacy-Data-Warehouse migriert. Früher mussten sie warten, bis die Engineers über Nacht Extraction Jobs ausgeführt haben, um die Daten aus dem Data Lake in das Warehouse zu laden. Erst dann konnten sie anfangen, Reports zu bauen. Databricks SQL eliminiert diesen gesamten Extraction Layer. Es ermöglicht Analysten, Standard-ANSI-SQL-Queries direkt gegen den Data Lake auszuführen. Du bekommst die enorme Skalierbarkeit von Open Lake Storage, interagierst damit aber über das vertraute, schnelle Interface eines traditionellen relationalen Data Warehouse. Die Engine, die diese Queries antreibt, ist das Serverless SQL Warehouse. Ein SQL Warehouse ist einfach eine Compute-Ressource, die speziell für SQL-Workloads konfiguriert ist. In älteren Architekturen musstest du Cluster manuell provisionieren, Scaling-Regeln konfigurieren und mehrere Minuten warten, bis die Virtual Machines hochgefahren sind, bevor du eine Query ausführen konntest. Hier ist die entscheidende Erkenntnis: Weil diese SQL Warehouses serverless sind, startet der Compute Layer fast sofort. Er skaliert automatisch, wenn deine Analysten hohe, gleichzeitige Workloads triggern, und er terminiert sich selbst, wenn die Queries fertig sind. Das Infrastructure Management ist komplett wegabstrahiert, sodass sich die Analysten voll und ganz auf ihre Daten konzentrieren können. Um diese Queries zu schreiben und auszuführen, bietet die Plattform einen integrierten SQL-Editor. Das ist das primäre Interface, um die Daten zu erkunden. Im Editor können User Standard-SQL schreiben, durch Data Catalogs browsen, Table Schemas untersuchen und sich Execution Histories ansehen. Wenn eine Query Daten zurückgibt, muss der Analyst sie nicht erst exportieren, um sie zu verstehen. Er kann Visualisierungen direkt im Editor bauen und diese in Custom Dashboards anordnen, die sich automatisch updaten. Die Plattform enthält außerdem ein Alerting-Feature. Analysten können eine Query schreiben, die eine bestimmte Metrik prüft, und das System so konfigurieren, dass es eine E-Mail oder eine Web Notification sendet, wenn diese Metrik einen definierten Threshold überschreitet. Viele Unternehmen haben bereits etablierte Visualisierungstools. Databricks SQL integriert sich direkt mit Standard-Third-Party-Tools wie Power BI und Tableau. Diese externen Applikationen verbinden sich mit dem Serverless SQL Warehouse und behandeln den Data Lake genau so, als wäre er eine High-Performance-Datenbank. Bei diesem Shift geht es im Grunde um die Nähe zu deinen Daten. Indem du Warehouse-Grade Compute und Standard-SQL direkt zum Lake bringst, hörst du auf, Daten zu kopieren, und fängst an, deine Single Source of Truth in dem Moment zu analysieren, in dem sie landet. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Databricks, Folge 11 von 15. Wenn drei verschiedene Abteilungen drei unterschiedliche Dashboards bauen, um den Umsatz zu tracken, und sie drei unterschiedliche Zahlen mit ins Executive Meeting bringen, hast du kein Data-Pipeline-Problem. Du hast ein Semantic-Layer-Problem. Die Lösung ist, einen Semantic Layer als Single Source of Truth zu etablieren, und in Databricks SQL machst du das mit Metric Views. Rohdaten sind selten so strukturiert, wie Business User denken. Datenbanktabellen enthalten kryptische Column-Namen, komplexe Joins und rohe Transaction Logs. Ein Semantic Layer schließt diese Lücke, indem er die zugrunde liegenden Daten in vertraute Business-Konzepte übersetzt. Schauen wir uns ein klassisches Szenario an, in dem das schiefgeht. Dein Marketing-Team und dein Finance-Team reporten beide über Monthly Active Users. Das Marketing schreibt eine Query in seinem Dashboard, die jeden zählt, der die App geöffnet hat. Finance schreibt eine andere Query in einem separaten Tool, die nur User zählt, die eine Transaktion abgeschlossen haben. Beide Teams nennen ihre Metric Monthly Active Users. Wenn die Zahlen kollidieren, bricht das Vertrauen der Organisation in die Daten zusammen. Monthly Active Users als Metric View im Unity Catalog zu definieren, löst dieses Problem für immer. Um zu verstehen, warum, müssen wir klären, was dieses Feature eigentlich ist. Eine Metric View ist nicht dasselbe wie eine Standard SQL View. Eine Standard SQL View speichert einfach eine Query, die rohe Rows und Columns zurückgibt, und überlässt es komplett dem End-User zu entscheiden, wie er diese Daten später summiert, mittelt oder gruppiert. Eine Metric View ist viel strenger. Sie erzwingt spezifische Aggregationsberechnungen und Dimensionalität direkt auf Catalog-Ebene. Wenn du eine Metric View erstellst, legst du die exakte Business-Logik fest. Du definierst das Measure, wie zum Beispiel einen Distinct Count von User-IDs basierend auf bestimmten Transaktionskriterien. Du definierst auch die erlaubten Dimensions. Das bedeutet, du legst explizit fest, dass diese Metric nur nach bestimmten Attributen gesliced werden kann, wie dem Transaction Date, der User-Region oder dem Device-Typ. Hier ist die entscheidende Erkenntnis. Sobald diese Metric View im Unity Catalog veröffentlicht ist, wird sie zur einzigen maßgeblichen Definition der Monthly Active Users für das gesamte Unternehmen. Wenn Analysten sich mit Databricks SQL verbinden, schreiben sie keine Custom-Logik, um die Daten zu aggregieren. Sie joinen keine Tabellen oder schreiben Where-Clauses, um aktive States zu filtern. Sie fragen einfach die Metric View ab. Das entkoppelt die Metric-Definition komplett vom Presentation Layer. Es spielt keine Rolle, ob das Marketing Tableau nutzt, Finance Power BI verwendet und das Product-Team native Databricks-Dashboards einsetzt. Das Business-Intelligence-Tool fragt einfach nach der Metric, und Databricks führt die vordefinierte Calculation serverseitig aus. Weil die Logik zentral im Unity Catalog lebt, ist es für verschiedene Abteilungen unmöglich, versehentlich ihre eigene Mathematik zu erfinden. Sie rufen alle exakt dieselbe Zahl ab, was perfekte Konsistenz in der gesamten Organisation sicherstellt. Die wahre Power eines Semantic Layers ist nicht technische Effizienz; sie besteht darin, Business-Logik aus unzusammenhängenden Downstream-Tools herauszunehmen und sie direkt in das Fundament der Data-Platform selbst einzubauen. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Databricks, Folge 12 von 15. Was wäre, wenn dein Sales Director deinem Data Warehouse einfach eine Nachricht schreiben könnte, um sofortige Business Insights zu bekommen, ohne jemals ein Ticket beim Data-Team einreichen zu müssen? Ad-hoc-Datenanfragen unterbrechen ständig die Engineering-Workflows, und Business-User hassen es, tagelang auf eine einfache Query warten zu müssen. Die Lösung für diesen Engpass ist ein Databricks-Feature namens Genie Spaces, das Teil ihres umfassenderen AI/BI-Angebots ist. AI/BI ist ein Business-Intelligence-Produkt, das auf einem Compound AI System basiert. Es ist darauf ausgelegt, die spezifische Semantik deiner Daten zu verstehen. Genie Spaces dienen als Conversational Interface für dieses System. Ein Genie Space sieht aus und fühlt sich an wie eine ganz normale Chat-App, ist aber direkt mit deinem Data Warehouse verbunden. Business-User tippen ihre Fragen in natürlicher Sprache ein, und Genie antwortet mit echten Daten, Visualisierungen und Antworten. Wenn Leute davon hören, dass eine AI Daten abfragt, machen sie sich sofort Sorgen wegen Halluzinationen. Sie gehen davon aus, dass das Model Column-Namen errät, Metrics erfindet oder voller Überzeugung falsche Antworten liefert. Genie verhindert das, indem es sich komplett auf die governed Metadaten stützt, die in deinem Unity Catalog gespeichert sind. Es sendet keinen blinden Prompt an ein generisches Language Model. Die AI ist in deinem tatsächlichen Schema, deinen Data Types, deinen Foreign Key Relationships und den vordefinierten Metrics, die dein Team festgelegt hat, verankert. Damit das funktioniert, erstellt und konfiguriert ein Analyst zuerst den Genie Space. Er wählt die relevanten Datasets aus dem Unity Catalog aus und übergibt eine Reihe von Instructions. Er kann Sample Queries hinzufügen, spezifische Business-Terminologie definieren und mehrdeutige Begriffe klären. Zum Beispiel kann er dem System mitteilen, dass, wenn ein User Active Customer sagt, damit speziell ein Kunde gemeint ist, der innerhalb der letzten neunzig Tage etwas gekauft hat. Dieses initiale Setup beschränkt die AI auf eine klar definierte Domain. Wenn eine Frage gestellt wird, orchestriert das System mehrere Schritte. Es liest den Natural Language Prompt und checkt den bereitgestellten Context. Es matcht den Intent des Users mit den exakten Tabellen und Columns im Catalog. Anschließend generiert es eine präzise SQL-Query, führt diese Query auf der Databricks SQL Compute Engine aus und formatiert die Ergebnisse. Stell dir einen nicht-technischen Sales Manager vor, der einen vorbereiteten Genie Space nutzt. Er tippt ein: Zeig mir die Umsätze in Europa nach Produkt für das letzte Quartal. Das System parst den Request basierend auf seinem Training. Es erkennt Europa als Region-Dimension, findet die Produkt-Tabellen und übersetzt letztes Quartal in einen präzisen Date-Filter. Innerhalb von Sekunden generiert die AI das SQL, führt es aus und gibt ein interaktives Chart mit der Aufschlüsselung zurück. Wenn der Manager dann antwortet: Jetzt Deutschland ausschließen, passt Genie die zugrundeliegende Query an und updatet das Chart sofort, wobei der Conversational Context erhalten bleibt. Dieser Workflow verändert grundlegend, wie Ad-hoc-Requests behandelt werden. Data Engineers und Analysten verbringen einen massiven Teil ihrer Woche damit, One-off-SQL-Queries für Stakeholder zu schreiben. Diese Exploration in Genie Spaces zu verlagern, gibt Business-Stakeholdern sofortige Antworten und macht gleichzeitig Engineering-Zeit für komplexe Aufgaben frei. Darüber hinaus bleibt der gesamte Prozess vollständig governed. Genie respektiert strikt alle Row- und Column-Level Access Controls, die im Unity Catalog definiert sind. Wenn der User, der die Frage stellt, keine Permission hat, sensible Finanzdaten zu sehen, wird die AI sie einfach nicht queryn. Hier ist die entscheidende Erkenntnis. Die Effektivität der Conversational Data Exploration wird von der Qualität deines zugrundeliegenden Data Models und deiner Metadaten bestimmt, nicht nur von der Intelligenz des Language Models. Das war’s für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Databricks, Folge 13 von 15. Ein Machine Learning Model zu trainieren, ist der spaßige Teil, aber es als hochverfügbare, sichere REST-API zu deployen, ist der Punkt, an dem die meisten Data Science Projekte scheitern. Der Schritt von einem Notebook-Experiment zu einem production-ready Endpoint erfordert die Konfiguration von Scaling, Load Balancing und strenger Governance. Um das zu lösen, nutzt du Mosaic AI Model Serving. Dieses Feature bietet ein einheitliches Interface, um AI-Models zu deployen, zu verwalten und zu queryn. Ein weit verbreiteter Irrtum ist, dass Databricks Model Serving nur für Models gedacht ist, die du selbst in Databricks trainierst. Das ist falsch. Es fungiert eigentlich als zentrales AI Gateway. Es verarbeitet drei verschiedene Arten von Models: Custom Models, Foundation Models und External Models. Erstens: Custom Models. Das sind die Models, die du baust, mit MLflow loggst und im Unity Catalog registrierst. Model Serving provisioniert einen Serverless Container, lädt deine Model-Dependencies und exposed das Model als REST-API. Du musst die Infrastruktur nicht verwalten. Es skaliert hoch bei Traffic-Spikes und skaliert auf null runter, wenn es idle ist. Zweitens: Databricks-hosted Foundation Models. Das sind große Open-Source-Models, die Databricks auf optimiertem Compute hostet. Du bekommst sofortigen Zugriff auf State-of-the-Art-Architekturen, ohne dir Gedanken über GPU-Provisioning machen zu müssen. Drittens: External Models. Hier konfigurierst du Endpoints, die auf Third-Party-Services zeigen. Warum solltest du externen Traffic über Databricks routen, anstatt externe Provider direkt aufzurufen? Denk an Governance und Cost Control. Angenommen, deine Firma möchte GPT-4 für eine interne Application nutzen. Wenn jeder Developer einen API-Key in seinem Script hardcodet, verlierst du die Visibility. Du kannst Kosten nicht strikt monitoren, Rate Limits nicht managen oder Filter anwenden, um zu verhindern, dass Mitarbeiter sensible Kundendaten an einen externen Provider senden. Indem du alle Requests über Mosaic AI Model Serving routest, zwingst du diesen Traffic durch ein einziges, sicheres Gateway. Du managst ein einziges Set an Credentials. Du wendest Access Controls über den Unity Catalog an und legst genau fest, wer oder was das Model queryn darf. Du bekommst außerdem zentralisiertes Tracking von Usage, Errors und Latency. Der Logic Flow ist straightforward. Du definierst einen Serving Endpoint in Databricks. Für ein Custom Model lässt du den Endpoint auf ein registriertes MLflow-Model zeigen und definierst die Compute Size und Scaling Limits. Databricks übernimmt die Containerization automatisch. Für ein External Model gibst du den Namen des External Providers und einen sicher gespeicherten API-Key an. Sobald der Endpoint aktiv ist, senden deine Downstream Applications einen Standard-JSON-Payload per HTTP Request an die Endpoint-URL. Die Response kommt in einem konsistenten Format zurück, unabhängig davon, ob das Model auf Databricks Serverless Compute läuft oder in einem externen Data Center liegt. Hier ist die Key Insight: Mosaic AI Model Serving entfernt die Friction beim Deployment und erzwingt gleichzeitig Security. Es standardisiert deinen Application Layer, sodass dein Client Code immer nur mit einem einzigen Databricks Endpoint spricht, komplett abstrahiert davon, wo oder wie das zugrunde liegende Model gehostet wird. Übrigens, wenn du die Show unterstützen möchtest, kannst du auf Patreon nach DevStoriesEU suchen. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Databricks, Folge 14 von 15. Du hast zehntausend rohe Customer Support Logs in einer Datenbanktabelle liegen, und das Business braucht sie bis zum Ende des Tages zusammengefasst und nach Sentiment kategorisiert. Normalerweise erfordert das Extrahieren solcher Insights eine komplexe Python-Pipeline, sorgfältiges Management von API Keys und eine Custom Batching Logic, um den Text in ein Large Language Model einzuspeisen. Was wäre, wenn du diesen gesamten Workload mit einem einfachen Datenbankbefehl ausführen könntest? Genau dieses Problem lösen AI Functions, die LLMs direkt in deine SQL Queries einbetten. AI Functions schließen die Lücke zwischen modernster Generative AI und alltäglicher Data Analytics. Sie nehmen eine Fähigkeit, die normalerweise spezialisiertes Machine Learning Engineering erfordert, und geben sie jedem, der SQL schreiben kann. Anstatt eine separate Infrastruktur aufzubauen, um Daten zu extrahieren, sie an ein Modell zu senden und die Predictions zurückzuschreiben, bringen AI Functions das Modell direkt dorthin, wo die Daten bereits liegen. Das wichtigste Tool dafür ist ein eingebauter Befehl namens AI query. Du verwendest ihn genau wie eine Standard-Textverarbeitungsfunktion innerhalb eines Select Statements. Du gibst den Namen des Model Endpoints an, den du nutzen möchtest, und dann übergibst du den Prompt. Zurück zu diesen zehntausend Support Logs: Dein Workflow wird dadurch trivial. Du schreibst eine Query, die deine Customer ID und den Log-Text auswählt. Dann fügst du mithilfe der AI query Funktion eine neue Spalte hinzu. Dein Prompt weist das Modell an, den Text zu lesen, die Hauptbeschwerde zu extrahieren und zu bestimmen, ob das Sentiment positiv, neutral oder negativ ist. Du übergibst die Spalte mit deinem rohen Log-Text an diesen Prompt. Wenn du die Query ausführst, verteilt die Database Engine diesen Request automatisch. Sie verarbeitet jede einzelne Zeile durch das angegebene Large Language Model. Das Modell wertet den Text aus und gibt die Zusammenfassung und das Sentiment zurück. Da das alles in SQL passiert, kommt der Output als strukturierte Standard-Spalten zurück. Du kannst die Ergebnisse sofort filtern, um nur negatives Sentiment anzuzeigen, diese Ergebnisse mit einer Customer Billing Table joinen und die Daten aggregieren, um herauszufinden, welches Produkt die meiste Frustration verursacht. Hier ist der entscheidende Insight. Du nimmst vielleicht an, dass der Zugriff von Data Analysts auf Large Language Models bedeutet, sensible API Keys im gesamten Unternehmen zu verteilen. Das ist aber nicht der Fall. AI Functions sind eng in Databricks Model Serving integriert. Die eigentlichen Connections zu externen Modellen oder selbstgehosteten Open-Source-Modellen werden von Administratoren auf Plattformebene konfiguriert. Der Data Analyst sieht niemals einen API Key, ein Token oder ein Secret. Er referenziert in seiner Query lediglich den vorkonfigurierten Endpoint-Namen. Die gesamte Operation bleibt absolut sicher. Jede Query wird geloggt, und alle Access Controls für die Daten und Modelle werden durch das Governance Framework der Plattform strikt durchgesetzt. Indem du die Infrastructure Friction und das Credential Management beseitigst, veränderst du die Art der Data Exploration. Du verwandelst komplexe unstrukturierte Textanalyse in eine einfache Filteroperation und wertest so die analytische Power deines gesamten Teams sofort auf. Danke fürs Zuhören. Macht's gut, zusammen.

Hallo, hier ist Alex von DEV STORIES DOT EU. Databricks, Folge 15 von 15. Dein Standard-Chatbot ist höflich, informativ und völlig passiv. Er kann dir anhand eines Handbuchs erklären, wie du eine kaputte Pipeline reparierst, aber er kann die Pipeline nicht wirklich für dich reparieren. Der Schritt von einer AI, die nur redet, zu einer AI, die aktiv Tasks ausführt, erfordert einen grundlegenden Architekturwandel. Dieser Shift ist das AI Agent Framework. Lass uns gleich mit einem häufigen Missverständnis aufräumen. Leute verwechseln oft einfache Retrieval-Augmented Generation Applications mit echten Agents. Eine RAG-Application ist im Grunde eine Suchmaschine mit einem Language Model obendrauf. Sie ruft Dokumente ab und fasst sie zusammen. Sie liest nur. Ein echter AI Agent hat Tools. Er kann schreiben. Er kann SQL Queries ausführen, Jobs triggern und externe APIs aufrufen. Er verändert den State deiner Systeme. Das Databricks Agent Framework bietet die Infrastruktur, um diese autonomen Agents sicher innerhalb des Lakehouse zu bauen, zu evaluieren und zu deployen. Der Kernmechanismus hier ist Tool Calling kombiniert mit Multi-Step Reasoning. Anstatt einfach nur eine Antwort in einem Durchgang zu generieren, fungiert das Language Model als Reasoning Engine. Du gibst ihm ein Ziel und ein Set an Tools, was im Grunde Funktionen sind, die du definiert hast. Der Agent entscheidet, welches Tool er verwendet, wartet auf das Ergebnis und entscheidet dann, was er als Nächstes tut. Stell dir einen Agent vor, der Data Pipelines überwacht. Wenn ein Fehler auftritt, sitzt der Agent nicht einfach nur da und wartet auf einen User Prompt. Das Framework erlaubt es ihm, einen Workflow zu triggern. Zuerst braucht der Agent Kontext. Er nutzt ein Custom Tool, das du bereitgestellt hast, um eine SQL Query gegen deine System Logs in Databricks auszuführen. Das Framework führt diese Query aus und gibt das Ergebnis an den Agent zurück. Hier ist die entscheidende Erkenntnis. Der Agent wertet diese Logs aus, identifiziert die Root Cause des Fehlers und geht dann zum nächsten Schritt über. Er merkt, dass das Engineering-Team Bescheid wissen muss. Also wählt er ein anderes Tool aus, eine API-Integration mit deiner Chat Application. Er ruft dieses Tool auf, um eine Message zu draften und zu senden, die den genauen Error und den vorgeschlagenen Fix detailliert beschreibt. Das ist Multi-Step Reasoning in Aktion. Der Agent hat eine Sequenz geplant, Code ausgeführt, den Outcome beobachtet und das Ergebnis kommuniziert, alles autonom. Einem Language Model die Fähigkeit zu geben, Queries auszuführen und APIs zu triggern, ist ein massives Security-Risiko, wenn man es schlecht handhabt. Deshalb koppelt der Databricks-Ansatz das Agent Framework eng an den Unity Catalog. Wenn du einen Agent über Databricks Model Serving deployst, gibst du ihm keinen pauschalen Zugriff auf deine Infrastruktur. Du registrierst deine Tools als spezifische Funktionen innerhalb des Unity Catalog. Der Unity Catalog erzwingt eine strikte Governance darüber, was diese Funktionen tun dürfen. Wenn du einem Agent ein Tool gibst, um Log Tables abzufragen, stellt der Unity Catalog sicher, dass er nur diese spezifischen Tabellen lesen kann. Wenn das Language Model halluziniert und versucht, mit dem SQL Tool eine Production Database zu droppen, stoppt das Framework das, weil der zugrundeliegenden Funktion die nötigen Permissions fehlen. Der Agent ist strikt an die Governance-Regeln deines Lakehouse gebunden. Diese Capability verwandelt das Lakehouse von einem passiven Storage Layer in ein aktives, automatisiertes Environment. Zum Abschluss dieser Serie ermutige ich dich, dir die offizielle Dokumentation anzusehen und selbst mal zu versuchen, einen einfachen Tool-Calling Agent zu bauen. Wenn du Themen für unsere nächste Serie vorschlagen willst, schau auf devstories dot eu vorbei. Der Übergang von Chatbots zu Agents ist der entscheidende Shift darin, wie wir heute AI Applications bauen. Das war's für diese Folge. Danke fürs Zuhören und keep building!