Data Mesh: Wie man mit Daten ohne Monolith arbeitet

Hallo, Habr! Bei Dodo Pizza Engineering sind wir große Fans von Daten (wer ist das nicht heutzutage?). Hier folgt die Geschichte darüber, wie man alle Daten der Dodo Pizza-Welt sammeln und jedem Mitarbeiter einen bequemen Zugang zu diesem Datenpool ermöglichen kann. Die Herausforderung: Die Nerven des Data Engineering-Teams zu schonen.

Wie echte Müllsammler sammeln wir alle möglichen Informationen über den Betrieb unserer Pizzerien:

• wir erinnern uns an alle Kundenbestellungen;
• wir wissen, wie viel Zeit für die Herstellung der ersten Pizza in Syktywkar benötigt wurde;
• wir sehen, wie lange die Pizza gerade jetzt auf dem Wärmegestell in Woronesch abkühlt;
• wir speichern Daten zu den Produktverbräuchen;
• und vieles, vieles mehr.

Für die Datenverarbeitung bei Dodo Pizza sind derzeit mehrere Teams verantwortlich, eines davon ist das Data Engineering-Team. Uns steht derzeit die Aufgabe bevor: allen Mitarbeitern der Firma einen bequemen Zugang zu diesem Datenpool zu ermöglichen.

Als wir darüber nachdachten, wie wir das umsetzen können, fanden wir einen sehr interessanten Ansatz für das Datenmanagement – Data Mesh (über den Link finden Sie einen umfangreichen, großartigen Artikel). Die Ideen darin entsprechen sehr gut unserem Verständnis davon, wie wir unser System gestalten möchten. Im weiteren Verlauf des Artikels präsentieren wir unsere Neubewertung des Ansatzes und wie wir dessen Umsetzung bei Dodo Pizza Engineering sehen.

Was meinen wir mit «Daten»

Beginnen wir damit, festzulegen, was wir unter Daten bei Dodo Pizza Engineering verstehen:

• Ereignisse, die von Diensten gesendet werden (wir verfügen über eine gemeinsame Bus-Architektur, die mit RabbitMQ erstellt wurde);
• Einträge innerhalb der Datenbank (für uns sind das MySQL und CosmosDB);
• Clickstream von der mobilen Anwendung und der Website.

Damit das Geschäft von Dodo Pizza diese Daten nutzen und darauf vertrauen kann, ist es wichtig, dass folgende Bedingungen erfüllt sind:

• Sie müssen vollständig sein. Wir müssen sicherstellen, dass die Daten während ihrer Verarbeitung, Speicherung und Anzeige nicht verändert werden. Wenn das Unternehmen unseren Daten nicht vertrauen kann, sind sie völlig nutzlos.
• Sie müssen einen Zeitstempel haben und dürfen nicht überschrieben werden. Das bedeutet, dass wir jederzeit in der Lage sein möchten, zurückzugehen und die Daten für einen bestimmten Zeitraum anzusehen. Zum Beispiel herauszufinden, wie viele Pizzen wir am 8. Juli 2018 verkauft haben.
• Sie müssen zuverlässig sein. Im Prozess der Datensammlung und -speicherung müssen wir nicht nur die Integrität, sondern auch die Zuverlässigkeit wahren. Wir können keine Datenverluste oder Zeitabschnitte erleiden, denn zusammen mit ihnen verlieren wir das Vertrauen unserer Kunden (sowohl extern als auch intern).
• Sie sollten mit einem stabilen Schema arbeiten – wir stellen Anfragen für diese Daten. Wir möchten nicht, dass mit Änderungen im Anwendungscode oder beim Refactoring die Daten so verändert werden, dass unsere Anfragen nicht mehr funktionieren. Derjenige, der die Anfragen schreibt, erfährt nie von Ihrem Refactoring, bis alles kaputtgeht. Wir möchten nicht, dass uns die Kunden darüber informieren.

Angesichts all dieser Anforderungen sind wir zu dem Schluss gekommen, dass die Daten in Dodo ein Produkt sind. So wie ein öffentliches API des Dienstes. Dementsprechend sollte das Team, das den Dienst besitzt, auch die Daten verwalten. Änderungen am Datenschema müssen immer abwärtskompatibel sein.

Der traditionelle Ansatz – Data Lake

Um die Herausforderungen einer zuverlässigen Speicherung und Verarbeitung großer Datenmengen zu bewältigen, gibt es einen traditionellen Ansatz, der in vielen Unternehmen, die mit solchen Informationspools arbeiten, anerkannt ist – Data Lake. Bei diesem Ansatz sammeln Dateningenieure Informationen aus allen Komponenten des Systems und lagern sie in einem großen Speicher (dies kann zum Beispiel Hadoop, Azure Kusto, Apache Cassandra oder sogar eine MySQL-Replikation sein, sofern die Daten hineinpassen).

Anschließend schreiben diese Ingenieure Abfragen an diesen Speicher. Die Umsetzung dieses Ansatzes bei Dodo Pizza Engineering bedeutet, dass das Data Engineering-Team die Datenstruktur im analytischen Speicher verwalten wird.

In diesem Szenario wird das Team jedoch zu sehr traurigen Kätzchen, und das aus folgendem Grund:

• Es muss die Änderungen in ALLE Diensten innerhalb des Unternehmens überwachen. Und es gibt viele Dienste und zahlreiche Änderungen (im Durchschnitt fusionieren wir etwa 100 Pull-Requests pro Woche, wobei viele Dienste überhaupt keine Pull-Requests erstellen).
• Wenn das Datenmodell geändert wird, müssen der Produktverantwortliche und das Team, das das Datenmodell ändert, warten, bis das Data Engineering den notwendigen Code fertiggestellt hat, um die Änderungen zu unterstützen. Solche Situationen, in denen ein Team auf ein anderes warten muss, sind sehr selten und wir möchten nicht, dass dies ein "normaler" Teil des Entwicklungsprozesses wird.
• Sie sollte in ALLEN Aspekten des Unternehmens eingebunden sein. Ein Netzwerk von Pizzerien mag wie ein einfaches Geschäft erscheinen, aber das täuscht. Es ist sehr schwierig, im selben Team ausreichend Kompetenzen zu bündeln, um ein angemessenes Datenmodell für das gesamte Unternehmen zu entwickeln.
• Es ist der einzige Fehlerpunkt. Jedes Mal, wenn Daten, die von einem Service zurückgegeben werden, geändert oder eine Abfrage geschrieben werden muss, fallen all diese Aufgaben an das Data Engineering-Team. Dadurch hat das Team einen überlasteten Backlog.

Dies führt dazu, dass das Team an der Schnittstelle einer Vielzahl von Bedürfnissen steht und diese wahrscheinlich nicht befriedigen kann. Gleichzeitig befindet es sich in ständigem Zeitdruck und Stress. Das wollen wir unbedingt vermeiden. Daher müssen wir darüber nachdenken, wie wir diese Probleme lösen und gleichzeitig die Möglichkeit zur Datenanalyse erhalten können.

Vom Data Lake zum Data Mesh

Zum Glück war diese Frage nicht nur uns wichtig. Tatsächlich wurde ein ähnliches Problem bereits in der Branche gelöst (Hallelujah!). Nur in einem anderen Bereich: beim Deployment von Anwendungen. Ja, ich spreche vom DevOps-Ansatz, bei dem das Team festlegt, wie das Produkt, das es erstellt, bereitgestellt werden soll.

Einen ähnlichen Ansatz zur Lösung von Data Lake-Problemen schlug Zhamak Dehghani, Beraterin bei ThoughtWorks, vor. Beobachtungen darüber, wie ähnliche Herausforderungen Netflix und Spotify angehen, führten sie zu einem bemerkenswerten Artikel. Wie man über einen monolithischen Data Lake zu einem verteilten Data Mesh übergeht(der Link dazu war am Anfang des Artikels). Die wichtigsten Ideen, die wir daraus für uns mitgenommen haben:

• Große Data Lakes in Daten-Domänen aufzuteilen, die den Domain-Driven-Design-Domänen sehr ähneln. Jede Domäne ist ein kleiner begrenzter Kontext.
• Feature-Teams, die für DDD-Domänen zuständig sind, kümmern sich auch um die entsprechenden Datenschichten. Sie speichern das Schema, nehmen Änderungen vor und laden Daten hoch. Dabei wissen sie genau, wie man die Dateneingabe ändert, ohne dass etwas kaputt geht, wenn sich die Anwendung ändert. Das Wissen bleibt erhalten. Um auf die Daten zuzugreifen, müssen sie nicht woanders hingehen. Das Team selbst durchläuft den gesamten Entwicklungszyklus von der Änderung operativer Daten bis zur Bereitstellung von Analysedaten für Dritte. Ein Team besitzt alles, was mit dem Domain zu tun hat (sowohl aus geschäftlicher als auch aus datentechnischer Sicht).
• Data Engineer – eine Rolle innerhalb des Feature-Teams. Es muss nicht unbedingt eine einzelne Person sein, aber es ist wichtig, dass das Team über diese Kompetenz verfügt.

Und währenddessen arbeitet das Data Engineering-Team...

Wenn man sich vorstellt, dass all dies mit einem Fingerschnippen umgesetzt wird, bleiben zwei Fragen zu beantworten:

Womit wird sich das Data Engineering-Team jetzt beschäftigen? Im Dodo Pizza Engineering gibt es bereits ein Plattform-/SRE-Team. Ihre Aufgabe besteht darin, den Entwicklern Werkzeuge zur einfachen Bereitstellung von Dienstleistungen zu bieten. Das Data Engineering-Team wird eine ähnliche Rolle nur für Daten übernehmen.

Die Umwandlung von Betriebsdaten in analytische Daten ist ein komplexer Prozess. Analytische Daten für das gesamte Unternehmen verfügbar zu machen, ist noch schwieriger. Genau mit diesen Herausforderungen wird sich das Data Engineering-Team befassen.

Wir werden dem Feature-Team ein benutzerfreundliches Set an Werkzeugen und Praktiken bereitstellen, damit sie Daten aus ihrem Service für das gesamte Unternehmen veröffentlichen können. Außerdem sind wir verantwortlich für die allgemeinen Infrastrukturkomponenten der Datenpipeline (Warteschlangen, zuverlässiger Speicher, Cluster für Datenverarbeitungen).

Wie werden die Fähigkeiten eines Data Engineers innerhalb des Feature-Teams aufgebaut? Das ist beim Feature-Team schwieriger. Natürlich könnten wir versuchen, in jedes unserer Teams einen Data Engineer einzustellen. Aber das ist sehr kompliziert. Jemanden mit einem soliden Hintergrund in der Datenverarbeitung zu finden und ihn davon zu überzeugen, innerhalb des Produktteams zu arbeiten, ist eine Herausforderung.

Ein großes Plus von Dodo ist, dass wir internes Training schätzen. Unser Plan sieht derzeit so aus: Das Data Engineering Team beginnt, Daten einiger Dienste zu veröffentlichen, auch wenn es Herausforderungen gibt, aber es beißt sich durch. Sobald wir einen reifen Prozess für die Veröffentlichung haben, beginnen wir, darüber im Feature Team zu berichten.

Wir haben mehrere Möglichkeiten, dies zu tun:

1. DevForum, in dem wir erläutern, wie der Prozess aussieht, den wir entwickelt haben, welche Werkzeuge es gibt und wie man sie am effektivsten verwendet.
2. Ein Auftritt auf dem DevForum wird uns helfen, Feedback von Produktentwicklern zu sammeln. Danach können wir uns den Produktteams anschließen und ihnen bei der Lösung von Aufgaben zur Datenveröffentlichung helfen, sowie Schulungen für die Teams organisieren.

Datenverbrauch

Ich habe jetzt viel über die Datenveröffentlichung gesprochen. Aber es gibt auch den Verbrauch. Was ist dazu zu sagen?

Wir haben ein großartiges BI-Team, das sehr komplexe Berichte für das Managementunternehmen erstellt. Innerhalb von Dodo IS gibt es viele Berichte für unsere Partner, die ihnen helfen, die Pizzerien zu verwalten. In unserem neuen Modell betrachten wir sie als Datenverbraucher mit eigenen Datenbereichen. Und diese Verbraucher sind für ihre eigenen Bereiche verantwortlich. Manchmal lässt sich der Bereich eines Verbrauchers mit einer einzigen Anfrage an das analytische Lager beschreiben – das ist in Ordnung. Aber wir wissen, dass das nicht immer funktionieren wird. Daher möchten wir sicherstellen, dass die Plattform, die wir für die Produktteams schaffen, auch von den Datenverbrauchern genutzt werden kann (denn im Fall der Berichte innerhalb von Dodo IS handelt es sich um dieselben Teams).

So sehen wir die Arbeit mit Daten bei Dodo Pizza Engineering. Wir freuen uns auf Ihre Gedanken dazu in den Kommentaren.

Quelle: habr.com