Datennetz: So arbeiten Sie mit Daten ohne Monolithen

Hallo habr Wir bei Dodo Pizza Engineering lieben die Daten wirklich (und wem gefallen sie jetzt nicht?). Jetzt wird es eine Geschichte darüber geben, wie alle Daten der Dodo Pizza-Welt gesammelt werden und wie jeder Mitarbeiter des Unternehmens bequem auf dieses Datenfeld zugreifen kann. Herausforderung unter dem Stern: Retten Sie die Nerven des Data Engineering-Teams.

Wie echte Plyushkins speichern wir alle Arten von Informationen über die Arbeit unserer Pizzerien:

• Erinnern Sie sich an alle Benutzeraufträge;
• Wir wissen, wie lange es gedauert hat, die erste Pizza in Syktyvkar zuzubereiten.
• Wir sehen, wie viel Zeit die Pizza im Moment in Voronezh auf dem Heizregal abkühlt;
• Daten über Produktabschreibungen speichern;
• und vieles mehr.

Derzeit sind mehrere Teams für die Arbeit mit Daten bei Dodo Pizza verantwortlich, eines davon ist das Data Engineering-Team. Jetzt haben sie (das heißt wir) die Aufgabe, jedem Mitarbeiter des Unternehmens einen bequemen Zugang zu diesem Datenfeld zu ermöglichen.

Als wir darüber nachdachten und das Problem diskutierten, fanden wir einen sehr interessanten Ansatz für das Datenmanagement - Data Mesh (hier finden Sie einen riesigen schicken Artikel). Ihre Ideen entsprachen sehr gut unserer Vorstellung, wie wir unser System aufbauen wollen. Der Rest des Artikels wird unser Überdenken des Ansatzes und der Umsetzung in Dodo Pizza Engineering sein.

Was meinen wir mit "Daten"

Lassen Sie uns zunächst entscheiden, was wir mit den Daten in Dodo Pizza Engineering meinen:

• Ereignisse, die Dienste senden (wir haben einen gemeinsamen Bus, der mit RabbitMQ erstellt wurde);
• Datensätze in der Datenbank (für uns sind dies MySQL und CosmosDB);
• Clickstream von einer mobilen Anwendung und Website.

Damit das Dodo Pizza-Unternehmen diese Daten verwenden und sich darauf verlassen kann, ist es wichtig, dass die folgenden Bedingungen erfüllt sind:

• Sie müssen ganzheitlich sein. Wir müssen sicher sein, dass wir die Daten während ihrer Verarbeitung, Speicherung und Anzeige nicht verändern. Wenn ein Unternehmen unseren Daten nicht vertrauen kann, ist dies nicht von Nutzen.
• Sie müssen mit einem Zeitstempel versehen und dürfen nicht überschrieben werden. Dies bedeutet, dass wir jederzeit in der Lage sein möchten, die Daten dieses Zeitraums rückgängig zu machen und anzusehen. Finden Sie beispielsweise heraus, wie viele Pizzen am 8. Juli 2018 verkauft wurden.
• Sie müssen zuverlässig sein. Beim Sammeln und Speichern von Daten dürfen wir nicht nur die Integrität, sondern auch die Zuverlässigkeit verlieren. Wir können keine Daten, Zeitscheiben verlieren, weil wir mit ihnen das Vertrauen unserer Kunden (sowohl extern als auch intern) verlieren.
• Sie sollten ein stabiles Schema haben - wir schreiben Anfragen für diese Daten. Wir möchten wirklich nicht, dass sie sich mit dem Ändern des Anwendungscodes, mit dem Refactoring, so sehr ändern, dass unsere Anfragen nicht mehr funktionieren. Derjenige, der die Anfragen schreibt, wird nie erfahren, dass Sie das Refactoring durchgeführt haben, bis alles kaputt geht. Das möchte ich von Kunden nicht wissen.

Angesichts all dieser Anforderungen kamen wir zu dem Schluss, dass die Daten in Dodo ein Produkt sind. Entspricht der API für öffentliche Dienste. Dementsprechend sollte dasselbe Team, dem der Dienst gehört, die Daten besitzen. Außerdem müssen Änderungen am Datenschema immer abwärtskompatibel sein.

Traditioneller Ansatz - Data Lake

Um die Probleme der zuverlässigen Speicherung und Verarbeitung von Big Data zu lösen, verfolgen viele Unternehmen, die mit einem solchen Informationspool arbeiten, einen traditionellen Ansatz: Data Lake. Im Rahmen dieses Ansatzes sammeln Dateningenieure Informationen von allen Komponenten des Systems und speichern sie in einem großen Speicher (dies können beispielsweise Hadoop, Azure Kusto, Apache Cassandra oder sogar ein MySQL-Replikat sein, wenn die Daten eingehen).

Ferner schreiben dieselben Ingenieure Anforderungen an einen solchen Speicher. Die Implementierung dieses Ansatzes bei Dodo Pizza Engineering setzt voraus, dass das Data Engineering-Team das Datenschema im analytischen Repository besitzt.

Mit diesem Szenario wird das Team zu sehr traurigen Katzen und deshalb:

• Sie muss Änderungen in ALLEN Diensten innerhalb des Unternehmens überwachen. Und es gibt viele von ihnen und es gibt viele Änderungen (im Durchschnitt führen wir ~ 100 Pull-Anforderungen pro Woche zusammen, während viele Services überhaupt keine Pull-Anforderungen ausführen).
• Wenn Sie das Datenschema ändern, müssen der Produktmanager und das Team, das das Datenschema ändert, warten, bis Data Engineering den für die Unterstützung der Änderungen erforderlichen Code vervollständigt hat. Darüber hinaus sind wir seit langem in Erscheinung getreten und die Situation, in der eine Mannschaft auf eine andere wartet, ist sehr selten. Und wir möchten nicht, dass dies ein „normaler“ Teil des Entwicklungsprozesses wird.
• Sie muss in das gesamte Geschäft des Unternehmens eintauchen. Eine Kette von Pizzerien sieht aus wie ein einfaches Geschäft, aber es scheint nur. Es ist sehr schwierig, in einem Team genügend Kompetenzen zu sammeln, um ein adäquates Datenmodell für das gesamte Unternehmen zu erstellen.
• Es ist ein einzelner Punkt des Scheiterns. Jedes Mal, wenn Sie die vom Service zurückgegebenen Daten ändern oder eine Abfrage schreiben müssen, fallen alle diese Aufgaben an das Data Engineering-Team. Infolgedessen hat das Team einen überlasteten Rückstand.

Es stellt sich heraus, dass sich das Team an der Schnittstelle einer Vielzahl von Bedürfnissen befindet und wahrscheinlich nicht in der Lage ist, diese zu befriedigen. Gleichzeitig wird es in konstanter Zeit unter Druck und Stress stehen. Das wollen wir wirklich nicht. Daher müssen Sie überlegen, wie Sie diese Probleme lösen und gleichzeitig die Möglichkeit erhalten, die Daten zu analysieren.

Fließen von Data Lake zu Data Mesh

Zum Glück haben wir uns diese Frage nicht nur gestellt. Tatsächlich wurde ein ähnliches Problem in der Branche bereits gelöst (Halleluja!). Nur in einem anderen Bereich: Anwendungsbereitstellung. Ja, ich spreche über den DevOps-Ansatz, bei dem das Team festlegt, wie das von ihnen erstellte Produkt bereitgestellt werden soll.

Ein ähnlicher Ansatz zur Lösung von Data Lake-Problemen wurde von Zhamak Dehghani, ThoughtWorks-Berater, vorgeschlagen. Sie beobachtete, wie Netflix und Spotify solche Probleme lösten, und schrieb einen erstaunlichen Artikel über das Verschieben von Daten aus einem monolithischen Datensee in ein verteiltes Datennetz (der Link dazu befand sich am Anfang des Artikels). Die Hauptideen, die wir daraus für uns genommen haben:

• Teilen Sie den großen Data Lake in Datendomänen auf, die domänengesteuerten Designdomänen sehr ähnlich sind. Jede Domain ist ein kleiner begrenzter Kontext.
• Das Feature-Team, das für die DDD-Domänen verantwortlich ist, ist auch für die entsprechenden Datendomänen verantwortlich. Sie speichern die Schaltung, nehmen Änderungen daran vor und laden Daten hinein. Gleichzeitig wissen sie selbst alles: wie man das Laden von Daten ändert und nichts kaputt macht, wenn sich die Anwendung ändert. Wissen geht nirgendwo hin. Sie müssen nirgendwo hingehen, um die Daten zu öffnen. Das Team selbst führt einen vollständigen Entwicklungszyklus durch, von der Änderung der Betriebsdaten bis zur Bereitstellung von Analysedaten für Dritte. Ein Team besitzt alles, was mit der Domäne zusammenhängt (sowohl die Geschäftsdomäne als auch die Datendomäne).
• Dateningenieur - Eine Rolle im Feature-Team. Dies muss keine Einzelperson sein, aber es ist unbedingt erforderlich, dass das Team über diese Kompetenz verfügt.

In der Zwischenzeit hat das Data Engineering-Team ...

Wenn Sie sich vorstellen, dass dies alles auf Knopfdruck realisiert wird, müssen Sie noch zwei Fragen beantworten:

Was wird das Data Engineering-Team jetzt tun? Dodo Pizza Engineering hat bereits ein / SRE-Plattformteam. Seine Aufgabe ist es, Entwicklern Tools für die einfache Bereitstellung von Diensten zur Verfügung zu stellen. Das Data Engineering-Team übernimmt dieselbe Rolle nur für Daten.

Die Umwandlung von Betriebsdaten in Analysedaten ist ein komplexer Prozess. Noch schwieriger ist es, Analysen für das gesamte Unternehmen verfügbar zu machen. Dies ist die Lösung für diese Probleme, mit denen sich das Data Engineering-Team befassen wird.

Wir werden Feature Team eine Reihe praktischer Tools und Vorgehensweisen zur Verfügung stellen, mit denen sie Daten aus ihrem Service für den Rest des Unternehmens veröffentlichen können. Wir werden auch für die allgemeine Infrastruktur der Datenpipeline verantwortlich sein (Warteschlangen, zuverlässiger Speicher, Cluster für die Durchführung von Transformationen von Daten).

Wie werden die Fähigkeiten von Data Engineer im Feature-Team angezeigt? Das Feature Team wird immer härter. Natürlich könnten wir versuchen, in jedem unserer Teams einen Dateningenieur einzustellen. Aber es ist sehr schwer. Es ist schwierig, eine Person mit einem guten Hintergrund in der Datenverarbeitung zu finden und ihn davon zu überzeugen, in einem Einkaufsteam zu arbeiten.

Der große Vorteil von Dodo ist, dass wir das interne Lernen lieben. Unser Plan lautet nun: Das Data Engineering-Team beginnt mit der Veröffentlichung der Daten einiger Dienste, heult und sticht, frisst aber weiterhin den Kaktus. Sobald wir verstehen, dass wir einen vorgefertigten Veröffentlichungsprozess haben, beginnen wir, im Feature-Team darüber zu sprechen.

Wir haben verschiedene Möglichkeiten, dies zu tun:

1. DevForum , in dem wir Ihnen erklären , wie der von uns erstellte Prozess aussieht, welche Tools vorhanden sind und wie Sie sie am effektivsten einsetzen können.
2. Wenn wir bei DevForum sprechen, können wir Feedback von Produktentwicklern einholen. Danach können wir den Produktteams beitreten und sie bei der Lösung von Problemen mit der Veröffentlichung von Daten unterstützen sowie Schulungen für Teams organisieren.

Datenverbrauch

Jetzt habe ich viel über das Veröffentlichen von Daten gesprochen. Es gibt aber auch Konsum. Was ist mit diesem Problem?

Wir haben ein wunderbares BI-Team, das sehr komplexe Berichte für eine Verwaltungsgesellschaft verfasst. In Dodo IS gibt es viele Berichte für unsere Partner, die ihnen beim Verwalten von Pizzerien helfen. In unserem neuen Modell verstehen wir sie als Datenkonsumenten mit eigenen Datendomänen. Und es sind die Verbraucher, die für ihre eigenen Domains verantwortlich sind. Manchmal kann eine Consumer-Domain mit einer einzigen Anforderung an das analytische Repository beschrieben werden - und das ist gut so. Wir verstehen jedoch, dass dies nicht immer funktionieren wird. Aus diesem Grund möchten wir, dass die Plattform, die wir für Produktteams erstellen, auch von Datenkonsumenten genutzt wird (bei Berichten in Dodo IS handelt es sich nur um Teams).

So sehen wir das Arbeiten mit Daten in Dodo Pizza Engineering. Wir freuen uns, Ihre Gedanken dazu in den Kommentaren zu lesen.