Warum Sie eine Benutzeroberfläche für Ihre Datenplattform erstellen sollten
26.07.2024
•
Kris Peeters
Moderne Datenplattformen sind komplex. Wenn Sie sich Referenzarchitekturen ansehen, wie die von A16Z unten, enthält sie mehr als 30 Kästen.
Jede Box kann ein oder mehrere Werkzeuge enthalten, je nachdem, wie Sie sie gestalten. Möglicherweise benötigen Sie nicht alle Boxen in Ihrer spezifischen Datenplattform, aber die meisten Datenplattformen, die wir in der realen Welt sehen, enthalten oft mehr als 10 Werkzeuge.

https://a16z.com/emerging-architectures-for-modern-data-infrastructure
Eine Datenplattform für ein kleines Team aufzubauen, ist NICHT der schwierige Teil
Obwohl dies einschüchternd erscheinen mag, ist die Datenwelt ziemlich vertraut mit dem Aufbau solcher Datenplattformen. Wenn Sie zu einem Cloud-Anbieter gehen, erhalten Sie viele dieser Werkzeuge direkt und benötigen eigentlich nichts mehr als ein einfaches Terraform-Skript zur Konfiguration. Oder, wenn Sie es wirklich einfach halten möchten, klicken Sie es in deren Konsole zusammen. Denken Sie daran, einige AWS-Dienste mit Snowflake zu kombinieren, oder Databricks auf Azure einzurichten, oder sogar einen altmodischen Cloudera Hadoop-Cluster vor Ort auszuführen. Heute ist die Einrichtung einer Datenplattform, die einige Anwendungsfälle bearbeiten kann und von einem zentralen Daten-Team erstellt wird, eine Frage von Tagen, Wochen oder höchstens ein paar Monaten.
Tasche von Werkzeugen vs. eine integrierte Erfahrung
Aber am Ende haben Sie nur eine Tasche voller Werkzeuge. Das bringt einige Herausforderungen mit sich:
Sie haben keine kognitive Last abgebaut: Jeder Entwickler muss jedes der Werkzeuge in Ihrer Datenplattform verstehen und muss sie auf eine Weise kombinieren, die für seinen speziellen Anwendungsfall funktioniert.
Keine Schnittstellen: Es ist schwierig, ein Werkzeug zu ändern oder zu aktualisieren. Jeder Anwendungsfall ist eine Sammlung von Skripten, die die zugrunde liegenden Werkzeuge auslösen. Die Änderung oder Aktualisierung von Werkzeugen bedeutet, dass alle Ihre Anwendungsfälle unterbrochen werden.
Es ist schwer, das große Ganze zu sehen: Bricht etwas in einem Dashboard? Das liegt daran, dass in einem zufälligen Notizbuch, das 5 Schritte flussaufwärts liegt, ein Fehler enthalten war. Sie müssen Ihr CICD-System überprüfen, um zu wissen, was das letzte Deployment für dieses Notizbuch war, und dann öffnen Sie Github, um die tatsächliche Änderung zu überprüfen.
Wiederum ist das in Ordnung, wenn Sie ein paar Anwendungsfälle mit einem kleinen zentralen Datenteam aufbauen. Sie können jede Person schulen und jedem Anwendungsfall besondere Aufmerksamkeit und Pflege zukommen lassen.
Aber was ist, wenn Sie die Teams dezentralisieren möchten?
Daten-Mesh, Daten-Framework, Citizen Data Science, Self-Service BI, … Sie können es mit jedem Modewort nennen, das Sie möchten, es gibt einen klaren Trend, allen in der Firma die Fähigkeit zu geben, etwas mit Daten zu tun. Und es gibt einen offensichtlichen Grund dafür: weil Geschäftsbenutzer Daten benötigen und verwenden möchten, um ihr Leben einfacher zu machen.
Erlauben Sie mir, das für die Menschen hinten zu wiederholen: Geschäftsbenutzer müssen und wollen Daten verwenden, um ihr Leben einfacher zu machen.
Glauben Sie mir nicht? Gehen Sie in jede Geschäftseinheit Ihres Unternehmens und beobachten Sie die verrückt komplizierten Dinge, die sie mit Excel und Access tun. Überprüfen Sie die super fortgeschrittenen Datenpipelines, die sie in ihrem Dashboarding-Tool erstellen. Sehen Sie, wie einige ihrer Analysten jeden Monat 7 Tage verbringen, um Zahlen aus verschiedenen Systemen manuell zu konsolidieren und die Ergebnisse in eine PowerPoint zu setzen.
Wir haben ein Projekt bei einem großen Unternehmen durchgeführt, das immer noch ein monolithisches Data Warehouse hatte. Und ein einziges Team war für den Aufbau aller Anwendungsfälle verantwortlich. Das würde zwischen 6 Monaten und 2 Jahren dauern, und sie hatten einen Rückstand von 9 Monaten. Wollte eine Geschäftseinheit etwas? Kommen Sie in 2 Jahren zurück, und vielleicht wird es geliefert. Wir haben eine Self-Service-Datenplattform für sie erstellt, und innerhalb von 3 Monaten haben wir über 100 Anwendungsfälle von mehr als 200 Geschäftsanwendern onboarded, die über MS Access auf die Daten zugreifen würden. „Oh nein, der Horror“? Nein, das ist großartig. Zumindest wissen wir, wer welche Datensätze für welche Zwecke verwendet. Gibt es bessere Werkzeuge als Access? Ja. Wird ihre Geschäftslogik ein komplettes Chaos sein? Ja. Ist das unsere oberste Priorität? Nein. Die Geschäftslogik gehört ihnen.
Mein Punkt ist: Sie möchten diese Benutzer auf Ihrer Plattform, um den zentralen Engpass zu beseitigen, und sobald diese Benutzer auf der Plattform onboarded sind, können Sie ihnen nicht einfach mehr eine Tasche voller Werkzeuge geben.
Obligatorische Auto-Analogie
Kein Ingenieurblo... ist vollständig ohne eine Autoanalogie. In dem Buch Plattformstrategie von Gregor Hohpe argumentiert er, dass die Autoindustrie seit langem von dem Ansatz „Tasche voller Werkzeuge“ abgerückt ist. Wenn ein Hersteller ein neues Modell herausbringen möchte (== einen neuen Anwendungsfall erstellen), geht er nicht zu einem langen Regal von Werkzeugen, wie das obige A16Z-Diagramm. Sie wählen keinen Kolben, ein Lenkrad, einen Kühlkörper, … und beginnen, all das für ihr spezielles Modell zu kombinieren.

Oberes Bild vom Autor. Unteres Bild aus Plattformstrategie von Gregor Hohpe
Stattdessen bauen sie einmal eine Plattform und ermöglichen es, mehrere Modelle darauf aufzubauen. Dies bringt mehrere Vorteile gegenüber dem Ansatz „Tasche voller Werkzeuge“:
Reduzierte kognitive Last: Alle technischen Aspekte des Fahrens eines Autos werden abstrahiert. Das Plattformteam kann sich auf Leistung, Haltbarkeit und Kosteneffektivität der Plattform konzentrieren. Das Modellteam kann sich auf die Kundenerfahrung konzentrieren.
Saubere Schnittstelle für die Modellentwickler: Sie müssen nur sicherstellen, dass der Fahrer das Lenkrad und die Pedale benutzen kann. Sie müssen nicht wissen, wie die Bremsen und die Federung mit den Rädern verbunden sind. Das kann sich im Laufe der Zeit ändern, ohne die Schnittstelle für die Modellentwickler zu beeinflussen.
Einfach, das große Ganze zu sehen: Im Rahmen der Schnittstelle zeigen die Plattformentwickler den Status im Dashboard an: „Ölwechsel nötig“, „Flüssigkeit fast leer“, … Für fortgeschrittenere Statusmeldungen können Experten eine Verbindung zum CAN-Bus des Autos herstellen.
Jetzt zurück zu Datenplattformen
Datenplattformenteams sollten denselben Ansatz für Datenplattformen bieten. Sie sollten anstatt nur eine Tasche voller Werkzeuge ihren Anwendungsfall-Teams anzubieten, über die Fähigkeiten nachdenken, die sie ihren Anwendungsfall-Teams anbieten möchten, und welche Schnittstellen sie benötigen, um das zu erreichen.

Diese Schnittstelle kann von Unternehmen zu Unternehmen unterschiedlich sein. Und es hängt auch davon ab, auf welcher Entwicklungsstufe Sie sich mit der Plattform befinden. Aber allgemein gesprochen gibt es 4 Archetypen von Anwendungsfällen, die Sie auf einer Datenplattform erstellen können:
Datenlagerung: Datenquellen integrieren, historische Änderungen verfolgen, Berichte bauen
Datenwissenschaft & GenAI: Daten verwenden, um Vorhersagen zu treffen, Empfehlungen zu geben oder Ratschläge zu erteilen
Geschäftskritische Anwendungsfälle: Mit hohen SLA laufen, integriert in Geschäftsprozesse
Citizen Data Analytics: Oft als „Last-Mile-Analytics“ bezeichnet: den Geschäftsanwendern ermöglichen, einige einfache Transformationen durchzuführen und Dashboards zu erstellen
Jeder dieser Anwendungsfall-Prototypen durchläuft die gleichen 4 Phasen: Entdecken, Experimentieren, Implementieren, Überwachen. Und vielleicht sogar „sonnenuntergang“. Unternehmen haben unterschiedliche Namen für diese Phasen und manchmal machen sie sie detaillierter. Die Entdeckungsphase kann darin bestehen, einen Business Case zu erstellen, sich mit der Unternehmensstrategie abzustimmen, die benötigten Datenquellen zu identifizieren, Budgetgenehmigungen zu erhalten, …
Die Anwendungsfall-Teams verstehen diese Konzepte. Sie verstehen nicht unbedingt die Begriffe „Airflow DAG“ oder „Iceberg Table“ oder „pip install“. Es ist Ihre Aufgabe, diesen Anwendungsfall-Teams ausgebaute Wege anzubieten. Damit sie auswählen können „Ich möchte einen neuen Anwendungsfall für Data Science durchführen“, und wie von Zauberhand hinter den Kulissen wird ein Git-Repo erstellt, eine ML-OPS-Datenpipeline aufgebaut, ein Modellrepo hinzugefügt, ein Notizbuch erstellt, …
Beispielschnittstelle aus unserem Data Product Portal
Letzten Monat haben wir unser neues, voll funktionsfähiges Open-Source-Projekt: Das Datenproduktportal eingeführt. Für Teams, die mit einem Datenproduktansatz arbeiten möchten, ist dies eine großartige Möglichkeit, eine technologieunabhängige Schnittstelle für ihre Anwendungsfall-Teams bereitzustellen: Anwendungsfall-Teams können neue Datenprodukte definieren, Benutzer zu Datenprodukten hinzufügen, Datensätze mit Datenprodukten verlinken, … Und im Hintergrund wird dies in Ihre spezifische Infrastruktur übersetzt, egal ob das Snowflake oder Databricks oder AWS ist.
Hier sind einige Screenshots unserer API-Dokumentation, damit Sie ein Gefühl dafür bekommen, was die Schnittstelle ist, die wir anbieten:

https://portal.public.demo1.conveyordata.com/api/docs#/
Ohne auf die Einzelheiten zu jedem Endpunkt einzugehen, ermöglicht Ihnen diese Schnittstelle, Datenprodukte auf eine technologieunabhängige Weise zu erstellen und zu konfigurieren. Wie das in eine tatsächliche Werkzeugkette übersetzt wird, ist ein anderer Blog.
Und natürlich spricht nicht jeder Benutzer „API“. Daher gibt es auch eine Web-UI.

https://portal.public.demo1.conveyordata.com/data-products/ffcf5286-8f14-4411-8dfe-75dc7ed9ec36
Fazit
Die Botschaft dieses Blogs ist, dass Sie als Plattformingenieur mehr tun sollten, als Ihren Benutzern eine Tasche voller Werkzeuge anzubieten. Sie sollten eine Datenplattform-Schnittstelle entwerfen, die technologieunabhängig ist und die spezifischen Bedürfnisse Ihres Unternehmens erfüllt.
Wenn Sie das Denken in Datenprodukten übernehmen, schauen Sie sich das Datenproduktportal an, das als Open-Source-Projekt auf Github verfügbar ist. Wenn Sie Fragen haben oder Ihre Gedanken teilen möchten? Treten Sie unserer Community auf Slack bei und verbinden Sie sich direkt mit uns.
Latest
When writing SQL isn't enough: debugging PostgreSQL in production
SQL alone won’t fix broken data. Debugging pipelines requires context, lineage, and collaborationnot just queries.
Portable by design: Rethinking data platforms in the age of digital sovereignty
Build a portable, EU-compliant data platform and avoid vendor lock-in—discover our cloud-neutral stack in this deep-dive blog.
Cloud-Unabhängigkeit: Test eines europäischen Cloud-Anbieters gegen die Giganten
Kann ein europäischer Cloud-Anbieter wie Ionos AWS oder Azure ersetzen? Wir testen es – und finden überraschende Vorteile in Bezug auf Kosten, Kontrolle und Unabhängigkeit.