Daten: Die vier Innovationsphasen von Netflix
Dieser Text ist eine Übersetzung. Das Original von Zhenzhong Xu ist hier(öffnet im neuen Fenster) zu finden.
Mein Name ist Zhenzhong Xu. Angefangen habe ich bei Netflix als Gründungsingenieur im Team für die Echtzeit-Dateninfrastruktur. Später habe ich das Team für die Engines zur Streamverarbeitung geleitet. Das waren die wichtigsten Errungenschaften des Teams:
- Bei den Anwendungsfällen für Streamingdaten sind wir in allen Bereichen bei Netflix von null auf über 2.000 gewachsen.
- Wir haben erfolgreiche Produkte wie Keystone(öffnet im neuen Fenster) , eine verwaltete Flink-Plattform(öffnet im neuen Fenster) , Mantis und eine verwaltete Kafka-Plattform aufgebaut und weiterentwickelt. Diese Produkte bieten Lösungen für viele Aspekte der Datenlandschaft, einschließlich Anwendungsfällen in den Bereichen Datenaufnahme, Datenbewegung, analytische und operative Verarbeitung sowie maschinelles Lernen.
- Wir gehörten branchenweit zu den ersten, die schon 2017 ein skaliertes Open-Source-Deployment für Kafka & Flink umgesetzt haben, um eine Billion Ereignisse pro Tag zu verarbeiten, was dann bis 2021 nochmals um den Faktor 20 skaliert wurde.
Vor einigen Monaten habe ich Netflix verlassen, um eine ähnliche, wenn auch größere Vision im Bereich des maschinellen Lernens in Echtzeit(öffnet im neuen Fenster) zu verfolgen. Hier möchte ich meine Erfahrungen aus dem Aufbau der Echtzeit-Dateninfrastruktur bei Netflix teilen.
Ich hoffe, damit Plattformentwicklern dabei zu helfen, ihre cloudeigenen, im Self-Service nutzbaren Streaming-Datenplattformen zu entwickeln und die Anwendungsfälle über viele Geschäftsfunktionen hinweg zu skalieren. Der Lerneffekt beruht dabei nicht unbedingt auf unserem Erfolg, sondern eher auf unseren Fehlschlägen.
Ich glaube außerdem, dass Kenntnisse zum Aufbau von Datenbanken für Plattformnutzer (beispielsweise Datenwissenschaftler und Ingenieure im Bereich maschinelles Lernen) hilfreich sind, um möglichst viel aus ihren Plattformen herauszuholen.
Wir haben bei Netflix vier Phasen der iterativen Reise zur Echtzeit-Dateninfrastruktur von 2015 bis 2021 durchlaufen.
Phase 1: Rettung der Netflix-Protokolle aus fehlerhaften Batch-Pipelines (2015). Während des globalen Megawachstums von Netflix beruhten die geschäftlichen und operativen Entscheidungen auf schnelleren Protokollierungsdaten. 2015 war die Skalierung von Batch-Pipelines auf der Basis von Chukwa/Hadoop/Hive extrem schwierig. In dieser Phase haben wir von Grund auf eine Plattform aufgebaut, bei der das Streaming oberste Priorität hatte, um die fehlerhaften Pipelines zu ersetzen.
Phase 2: Skalierung für Hunderte von Anwendungsfällen für Datenbewegungen (2016). Nach der ersten Produktveröffentlichung stieg die interne Nachfrage nach Datenbewegungen kontinuierlich. Wir mussten uns auf die häufigsten Anwendungsfälle konzentrieren. In dieser Phase gelang uns eine Skalierung, um Hunderte von Anwendungsfällen zu unterstützen. Hierzu haben wir eine im Self-Service betriebene, vollständig verwaltete Plattform mit einem einfachen, aber leistungsstarken Bausteinprinzip entwickelt.
Phase 3: Unterstützung für benutzerdefinierte Anforderungen und Skalierung von weit über tausend Anwendungsfällen (2017-2019) Als die Streamverarbeitung bei Netflix eine immer größere Dynamik entwickelte, forderten viele Teams eine niedrigere Latenz und eine höhere Verarbeitungsflexibilität in den Bereichen Data Engineering, Beobachtbarkeit und maschinelles Lernen. In dieser Phase haben wir eine neue Entwicklungserfahrung für die Streamverarbeitung aufgebaut, um benutzerdefinierte Anwendungsfälle zu ermöglichen. Außerdem haben wir uns neuen technische und operative Herausforderungen gestellt.
Phase 4: Erweiterte Zuständigkeiten bei der Streamverarbeitung – künftige Herausforderungen und Chancen (2020 bis heute). Mit der rasanten technologischen Entwicklung bei Datenplattformen in der Branche gehen viele neue Herausforderungen einher: Schwierigkeiten bei der Koordinierung, eine steile Lernkurve, Grenzen zwischen Stream und Batch und vieles mehr. In dieser Phase haben wir untersucht, wie die Streamverarbeitung eine prominentere Rolle bei Verbindungstechnologien spielen kann und wie die Abstraktion erhöht werden kann, um eine einfachere Nutzung von Datenplattformen zu erreichen. Vor uns liegen außerdem noch viele Chancen.
Ich stelle für jede Phase die sich ergebenden Geschäftsmotivationen, die einzigartigen Herausforderungen des Teams, die Strategiewetten und die Muster für die Anwendungsfälle vor, die wir auf dem Weg entdeckt haben.
Phase 1: Rettung der Netflix-Protokolle
2015 hatte Netflix bereits 60 Millionen Abonnenten und expandierte aggressiv auf internationaler Ebene. Wir wussten alle, dass der Schlüssel zur Aufrechterhaltung des rasanten Abonnentenwachstums in der schnellen Skalierung der Plattformnutzung lag.
Randnotiz: Wer mit der Thematik nicht so vertraut ist, sollte wissen, dass das Plattformteam für die Nutzung die grundlegenden Infrastrukturkomponenten zentral verwaltet, damit sich das Produktteam auf die Geschäftslogik konzentrieren kann. Unser Team musste herausfinden, wie sich die Protokollierungsverfahren bei Netflix skalieren ließen. Zu dem Zeitpunkt gab es bei Netflix etwa 500 Mikroservices, die jeden Tag mehr als 10 Petabyte Daten in der Umgebung generierten.
Die Erfassung dieser Daten dient bei Netflix in erster Linie zwei Zwecken:
- dem Erfassen geschäftlicher Analyseinformationen (beispielsweise Nutzerbindung, durchschnittliche Sitzungslänge, Trends).
- de, Erfassen operativer Informationen (beispielsweise Messung von Streamingwiedergaben pro Sekunde, um den Zustand der Netflix-Systeme schnell und einfach zu überprüfen), damit Entwickler Alarm schlagen oder Probleme entschärfen können.
Nun kann man sich fragen, warum die Protokolle überhaupt vom Rand des Netzwerks in das Data Warehouse verschoben werden müssen. Aufgrund des enormen Umfangs war es nicht machbar, Analysen der Online-Transaktionsdatenbanken bei Bedarf im richtigen Maßstab umzusetzen.
Der Grund dafür ist, dass OLTP (Online Transactional Processing) und OLAP (Online Analytical Processing) auf verschiedenen Annahmen basieren. OLTP wurde für zeilenorientierte und OLAP für spaltenorientierte Zugriffsmuster entwickelt. Intern werden jeweils unterschiedliche Datenstrukturen für Optimierungen eingesetzt.
Angenommen, wir möchten wissen, wie die durchschnittliche Sitzungslänge bei Hunderten Millionen Netflix-Nutzern aussieht. Wenn wir diese analytische Abfrage in einem zeilenorientierten OLTP-System auf Abruf stellen, erhalten wir komplette Tabellenabfragen mit der Granularität auf Zeilenebene und sperren dadurch eventuell die Datenbank. So sind die Anwendungen nicht mehr erreichbar, was sich negativ auf die Benutzerzufriedenheit auswirkt.
Diese Art der Analyse oder Meldung der Auslastung funktioniert deutlich besser in einem OLAP-System. Deshalb müssen die Protokolle zuverlässig und mit niedriger Latenz verschoben werden.
Bis 2015 hat sich der Umfang der Protokolldaten auf 500 Milliarden Ereignisse pro Tag (1 Petabyte Datenaufnahme) erhöht, während er 2011 noch bei 45 Millionen Ereignissen pro Tag lag. Die bestehende Infrastruktur für die Protokollierung (eine einfache Plattform für Batch-Pipelines, die auf Chukwa, Hadoop und Hive aufbaut) funktionierte bei den wöchentlich steigenden Abonnentenzahlen immer weniger.
Schätzungsweise hatten wir etwa sechs Monate Zeit, eine Lösung zu entwickeln, bei der das Streaming höchste Priorität hatte. Die nachstehenden Diagramme zeigen die Entwicklung von der fehleranfälligen Batch-Architektur hin zur neuen streamingbasierten Architektur.
Wir beschlossen, diese fehleranfällige Infrastruktur durch Keystone zu ersetzen.
Außerdem lässt sich vermutlich die Frage stellen, warum überhaupt eine Architektur in Betracht kommt, bei der Streaming die höchste Priorität hat. Zu dem Zeitpunkt überwog der Mehrwert einer gut aufgestellten Streamingarchitektur die potenziellen Risiken. Netflix ist ein datengesteuertes Unternehmen. Somit zeigt sich die Bedeutung einer Streamingarchitektur sofort in folgenden Punkten:
- Kürzere Feedback-Schleife zwischen Entwickler und Betrieb: Entwickler basieren operative Entscheidungen klar auf Protokollen. Der Zugriff auf neuere, bedarfsgenerierte Protokolle bietet Entwicklern die Möglichkeit, Probleme früher zu erkennen, und sorgt so für höhere Produktivität.
- Bessere Produkterfahrungen: Viele Produktfunktionen, beispielsweise personalisierte Empfehlungen und die Suchfunktion, profitieren von neueren Daten und verbessern so die Benutzererfahrungen. Das führt zu einer höheren Kundenbindung und -treue.
Herausforderungen in Phase 1
Beim Aufbau einer Streamingplattform standen wir vor vielen Herausforderungen.
Herausforderung 1: Hohe Skalierung mit begrenzten Ressourcen. Wir hatten sechs Monate Zeit, um Keystone so aufzubauen, dass 500 Milliarden Ereignisse pro Tag verarbeitet werden konnten – und das ganze mit nur sechs Teammitgliedern.
Herausforderung 2: Unreife Streamingumgebung. Die Entwicklung und der Betrieb einer Infrastruktur mit dem Ansatz "Streaming First" war 2015 noch sehr schwierig, da sowohl Transport- (Apache Kafka) als auch Verarbeitungstechnologien (Apache Samza, Apache Flink) gerade erst aufkamen. Nur wenige Technologieunternehmen verfügten über erwiesenermaßen erfolgreiche Deployments mit Streaming als oberster Priorität in dem von uns benötigten Maßstab.
Deshalb mussten wir alle technologischen Möglichkeiten auswerten und experimentieren. In Anbetracht unserer begrenzten Ressourcen konnten wir nicht einfach alles selbst aufbauen, sondern mussten entscheiden, was wir selbst entwickeln und auf welche aufkommenden Tools wir setzen würden.
Herausforderung 3: Analytische und operative Bedenken unterscheiden sich. Der Schwerpunkt bei der analytischen Streamverarbeitung liegt auf Richtigkeit und Vorhersehbarkeit. Beispielsweise sind für die Verschiebung aller Clickstreams der Benutzer in das Data Warehouse Datenkonsistenz (minimale Duplikate oder Verluste) und Vorhersehbarkeit bei der Latenz (die üblicherweise im Bereich von Minuten liegt) notwendig. (Hierbei ist Keystone wirklich gut.)
Bei der operativen Streamverarbeitung liegt der Schwerpunkt eher auf Wirtschaftlichkeit, Latenz und Verfügbarkeit. Wenn wir zum Beispiel den Zustand der gesamten Gerätelandschaft von Netflix kennen, können wir von Latenzen profitieren, die im Sekundenbereich oder sogar darunter liegen. Außerdem können Stichproben oder Profile der Daten aus der Quelle erstellt werden, um Kosten zu sparen. (Hierbei ist Mantis wirklich gut.)
Herausforderung 4: Cloudeigene Resilienz für eine zustandsbehaftete Datenplattform ist schwierig. Netflix arbeitete bereits seit einigen Jahren in der AWS-Cloud. Wir waren jedoch die Ersten, denen es gelang, eine zustandsbehaftete Datenplattform in die auf Containern basierende Cloudinfrastruktur zu bringen. Im Hintergrund laufen in allen Rechenzentren Hunderttausende physischer Maschinen, die die Cloud antreiben. Bei diesem Umfang sind Hardwareausfälle unvermeidlich.
Wenn diese Ausfälle unerwartet auftreten, kann es für die Systeme sehr schwierig werden, die Erwartungen hinsichtlich Verfügbarkeit und Konsistenz zu erfüllen. Die Herausforderung ist in einer ungebundenen Umgebung für die Streamverarbeitung mit niedriger Latenz, bei der jede Ausfallwiederherstellung dazu führen kann, dass sich Gegendruck aufbaut, sogar noch größer. Eine cloudeigene Resilienz für eine Streaming-First-Architektur würde uns vor enorme technische Herausforderungen stellen.
Zusammenfassung zu Streamverarbeitungsmustern in Phase 1
Ich stelle einige selbst beobachtete Anwendungsfälle mit den jeweiligen Streamverarbeitungsmustern für jede Innovationsphase vor. Das vermittelt ein Gefühl für die Entwicklung im Laufe der Zeit.
| Muster | Produkt | Anwendungsfälle |
|---|---|---|
| Datenrouting | Keystone | Protokollierung, Datenbewegung (MVP) |
| Echtzeitwarnungen / Dashboard | Mantis | SPS-Warnung |
Strategiewetten in Phase 1
Wette 1: Das MVP-Produkt wird anfangs nur für wenige Kunden entwickelt. Beim Untersuchen der anfänglichen Eignung des Produkts für einen Markt wird man leicht abgelenkt. Wir beschlossen, einigen wenigen internen Kunden mit hoher Priorität und großem Umfang zu helfen und uns später um die Skalierung der Kundenbasis zu kümmern.
Durch diese Entscheidung waren wir zum einen in der Lage, uns auf den Kern des Produkts zu konzentrieren. Zum anderen waren wir uns bewusst, worin wir nicht investieren mussten. Beispielsweise nutzten wir eine einfache Tabelle anstelle einer vollwertigen Plattform für die Pflege von Kundennamen, E-Mail-Adressen und Metadaten pro Pipeline, um die Bereitstellung beim Kunden in der MVP-Phase zu vereinfachen.
Wette 2: Gemeinsame Entwicklung mit Technologiepartnern, auch wenn noch kein idealer Reifegrad erreicht ist, anstatt das Rad nochmal neu zu erfinden. Auf diese Weise konnten wir die Umgebungen gemeinsam entwickeln. Wir haben uns früh für Partnerschaften entschieden.
- Streamingpartner: Extern haben wir mit Partnern zusammengearbeitet, die branchenweit bei der Streamverarbeitung führend sind. Dazu gehören Linkedin (Kafka- und Samza-Team), Confluent, Data Artisan (Entwickler hinter Apache Flink, später umbenannt in Veverica). So konnten entsprechend unserer Bedürfnisse zum Betriebsunterstützungssystem (OSS) beitragen und gleichzeitig die gemeinschaftliche Arbeit nutzen.
- Partner bei der Containerisierung: 2015 befand sich die Virtualisierungstechnologie mit Containern noch in einer frühen Phase. Wir brauchten schnell eine Strategie für die Bereitstellung. Intern gingen wir eine Partnerschaft mit der neu geschaffenen Containerinfrastruktur, dem Titus-Team, ein. Titus baute auf Apache Mesos auf und stellte Funktionen für die Verwaltung, Planung und isolierte Bereitstellung von Rechenressourcen über eine abstrahierte API bereit. Titus wurde später so weiterentwickelt, dass es Anfang der 2020er Jahre K8S nutzte. Das zugehörige Team schaffte es, alle Workloads transparent zu migrieren. Dank dieser Partnerschaft mussten wir uns keine Gedanken über die zugrundeliegende Recheninfrastruktur machen, während wir die Datenplattform aufbauten.
Im Verlauf dieser Zusammenarbeit blieben wir in ständigem Kontakt, um Erfahrungen auszutauschen und Feedback zu geben. Alle zwei Wochen fanden Meetings mit engen Partnern statt, um Zielsetzungen abzustimmen und Probleme und Lösungen zu besprechen. Wenn Hindernisse auftraten, kümmerten sich sofort die richtigen Menschen darum.
Wette 3: Bedenken trennen, anstatt sie zu ignorieren. Wir haben die Bedenken in Bezug auf operative und analytische Anwendungsfälle voneinander getrennt. Wir haben Mantis (mit Fokus auf operativem Geschäft) und Keystone (mit Fokus auf Analysen) separat entwickelt, dabei allerdings Raum für eine Schnittstelle zwischen beiden Systemen geschaffen.
Die Bedenken zwischen Herstellern und Verbrauchern haben wir voneinander getrennt. Wir haben Hersteller- und Verbraucher-Clients eingeführt, die mit standardisierten Netzwerkprotokollen und einer einfachen Schemaverwaltung ausgestattet wurden, um den Entwicklungsworkflow zwischen Herstellern und Verbrauchern leichter zu entkoppeln. Das stellte sich später als grundlegender Aspekt bei der Data Governance und der Datenqualitätskontrolle heraus.
Auch die Zuständigkeiten für Komponenten haben wir voneinander getrennt. Anfangs nutzten wir ein an Mikroservices ausgerichtetes Prinzip mit Einzelverantwortung, bei dem die gesamte Infrastruktur aufgeteilt wurde in die Bereiche Messaging (Streamingtransport), Verarbeitung (Streamverarbeitung) und Steuerungsplattform (in dieser Phase war die Plattform nur ein Skript, das später zu einem kompletten System ausgebaut wurde).
Die Trennung der Zuständigkeit für die Komponenten ermöglichte es dem Team, frühzeitig Schnittstellen aufeinander abzustimmen und gleichzeitig die Produktivität des Teams durch den parallelen Schwerpunkt auf verschiedene Bestandteile zu steigern.
Wette 4: Investition in den Aufbau eines Systems, bei dem Ausfälle erwartet und alle Abläufe überwacht werden, anstelle von verzögerten Investitionen. Aufgrund der elastischen, sich konstant ändernden Merkmale der Cloud mit höherer Ausfallwahrscheinlichkeit müssen wir das System so aufbauen, dass alle Arten von Ausfällen überwacht, erkannt und verkraftet werden können.
Die Ausfälle können beispielsweise von Netzwerkaussetzern über den Ausfall von Instanzen, Zonen und Clustern bis hin zu Überlastung und Gegendruck zwischen Services sowie Ausfällen bei örtlichen Katastrophen reichen.
Wir haben in den Ausbau der Systeme in der Annahme investiert, dass konstant Ausfälle auftreten. Wir haben uns ganz früh Devops-Praktiken verschrieben: Szenarien, die für Ausfälle entwickelt wurden, rigorose Automatisierung, kontinuierliches Deployment, Schattentests, automatisierte Überwachung und Warnungen und vieles mehr. Dank dieser Devops-Grundlage gelang uns eine herausragende technische Agilität mit mehreren Bereitstellungen pro Tag.
Veränderungen sind nur möglich, wenn Fehler gemacht werden dürfen
Wir haben viele Fehler gemacht. Am Tag des Produktstarts ist eigentlich alles schief gegangen und wir hatten einen unternehmensweiten Vorfall mit massiven Datenverlusten. Nach der Untersuchung des Vorfalls stellte sich heraus, dass trotz einer korrekten Schätzung des Wachstums beim Datenverkehr der monströse Kafka-Cluster (mit mehr als 200 Brokern), den wir aufgebaut hatten, zu groß war und schließlich an seine Skalierungsgrenze kam.
Als ein Broker ausfiel, konnte der Cluster die Wiederherstellung aufgrund der (damaligen) Beschränkungen in Kafka in Bezug auf die Anzahl an Brokern und Partitionen nicht selbst durchführen. Das gesamte System verschlechterte sich so lange, bis keine Wiederherstellung mehr möglich war.
Ein Ausfall in diesem Maßstab war eine schreckliche Erfahrung. Aber dank unserer psychologisch sicheren Teamumgebung haben wir mit allen Beteiligten transparent kommuniziert und die Erfahrungen schnell in dauerhafte Lösungen umgesetzt. Für diesen besonderen Fall entwickelten wir Möglichkeiten mit einer feingranulareren Cluster-Isolierung (kleinere Kafka-Cluster und isolierter Zookeeper), um den Auswirkungsradius einzudämmen.
Aber es gab noch viele weitere Ausfälle. Als wir durch die Ursachen pflügten, mussten wir feststellen, dass wir auf keinen Fall alle noch so abseitigen Szenarien durchspielen konnten, besonders bei unserem Aufbau auf einer verwalteten Cloud, bei der Änderungen häufig außerhalb unserer Kontrolle passieren, wie die Beendigung von Instanzen oder die Mandanten-Colocation.
Gleichzeitig wird unser Produkt von sehr vielen Menschen genutzt und ist eigentlich zu wichtig, um auszufallen. Es wurde zu unserem Arbeitsprinzip, unsere Abläufe immer auf das Worst-Case-Szenario vorzubereiten.
Nach dem Vorfall führten wir eine wöchentliche Ausfallübung für den Kafka-Cluster ein. Jede Woche musste die zuständige Person einen Ausfall des Kafka-Clusters simulieren. Das Team musste sicherstellen, dass die automatisierte Ausfallsicherung funktionierte und den gesamten Datenverkehr mit minimalen Auswirkungen auf die Nutzer auf einen stabilen Cluster migrieren. Mehr über dieses Vorgehen bietet dieses ausführliche Video(öffnet im neuen Fenster) zu diesem Thema.
Phase 2: Skalierung für Hunderte von Anwendungsfällen
Nach der Bereitstellung des ersten Keystone-MVP und der Migration einiger interner Kunden haben wir nach und nach an Zutrauen gewonnen. Außerdem verbreiteten sich die Neuigkeiten an andere Entwicklerteams. Das Streaming bei Netflix gewann an Dynamik, da es inzwischen ganz leicht ist, Protokolle für die analytische Verarbeitung zu verschieben und operative Informationen nach Bedarf abzurufen.
Jetzt war die Zeit für eine Skalierung auf die allgemeinen Kunden gekommen.
Herausforderungen in Phase 2
Herausforderung 1: Erhöhte operative Last. Anfangs boten wir unseren Neukunden einen umfassenden Einführungsservice. Das ließ sich mit wachsender Nachfrage allerdings nicht lange durchhalten. Wir mussten anfangen, das MVP weiterzuentwickeln, um mehr als nur ein Dutzend Kunden zu unterstützen.
In der Folge mussten wir einige Komponenten umbauen. Beispielsweise war die Zeit gekommen, uns von reinen Tabellen zu einer ordentlichen Steuerungsplattform mit Datenbank im Hintergrund zu entwickeln.
Herausforderung 2: Unterschiedliche Bedürfnisse. Als die Kundenanfragen zunahmen, standen wir vor immer vielfältigeren Bedürfnissen. Diese lassen sich in zwei wichtige Kategorien unterteilen: Eine Gruppe bevorzugte einen voll verwalteten Service mit einfacher Nutzung. Die andere Gruppe bevorzugte Flexibilität und benötigte komplexe Rechenfähigkeiten, um umfangreichere geschäftliche Probleme zu lösen. Für sie war es völlig in Ordnung, Pager zu nutzen und Teile der Infrastruktur selbst zu verwalten. Aber wir können nicht beides gleichzeitig gut machen.
Herausforderung 3: Alles, was wir anfassten, ging kaputt. Ganz im Ernst: Aufgrund der Skalierung haben wir alle unsere abhängigen Services irgendwann kaputt gemacht. Wir haben einmal AWS S3 kaputt gemacht. Wie haben viele Bugs in Kafka und Flink gefunden. Wir haben Titus (die verwaltete Containerinfrastruktur) mehrmals kaputt gemacht und sind auf merkwürdige Probleme mit der CPU-Isolierung und Netzwerken gestoßen. Wir haben Spinnaker (die Plattform für das kontinuierliche Deployment) kaputt gemacht, als wir Hunderte von Kunden-Deployments automatisch gestartet haben.
Zum Glück waren diese Teams hervorragend. Sie haben mit uns gemeinsam diese Probleme nach und nach behoben. Diese Anstrengungen tragen entscheidend zur Reifung der gesamten Streaminglandschaft bei.
Zusammenfassung zu Streamverarbeitungsmustern in Phase 2
| Muster | Produkt | Anwendungsfälle |
|---|---|---|
| Datenrouting | Keystone | Protokollierung, Datenbewegung (+ skaliert) |
| Echtzeit-Datenstichproben / Entdeckung | Mantis | Kostengünstige Echtzeitinformationen |
| Echtzeitwarnungen / Dashboard | Mantis, Kafka | SPS-Warnung, + Infrastrukturzustand-Überwachung (Cassandra & Elasticsearch), + Echtzeit-QoE-Überwachung |
Strategiewetten und Erkenntnisse in Phase 2
Wette 1: Schwerpunkt auf Einfachheit anstelle von komplexer Infrastruktur für die Nutzer. Wir beschlossen, uns zunächst aus zwei Gründen auf einen extrem abstrahierten, komplett verwalteten Service für allgemeine Anwendungsfälle für das Streaming zu konzentrieren.
Dadurch könnten wir die meisten Anwendungsfälle in Bezug auf Datenbewegung und einfaches Streaming-ELT (also Projektion, Filtern und ähnliches) ansprechen. Wenn wir eine so einfache, hochrangige Abstraktion für die Datenweiterleitung bereitstellten, könnten die Techniker in allen Netflix-Bereichen das Datenrouting als Baustein in Verbindung mit anderen Plattformservices nutzen.
Das würde unseren Benutzern den Fokus auf die Geschäftslogik ermöglichen. Fortschrittlichere Anwendungsfälle würden wir später in Angriff nehmen.
Wette 2: Investition in einen komplett verwalteten Self-Service mit mehreren Mandanten anstelle einer fortgesetzten manuellen umfassenden Unterstützung. Wir mussten den Schwerpunkt auf die Automatisierung der Steuerungsplattform und der Workload-Bereitstellung legen. Die Kunden-Workloads müssen völlig isoliert ablaufen. Wir beschlossen, dass der Workload des einen Kunden nicht mit dem eines anderen Kunden in Berührung kommen sollte.
Wette 3: Fortgesetzte Investitionen in Devops anstatt verzögerter Investitionen. Wir wollten Plattformänderungen bei Bedarf mehrmals am Tag bereitstellen. Wir sind der Überzeugung, dass es unerlässlich ist, unsere Kunden in die Lage zu versetzen, jederzeit Änderungen bereitzustellen. Das Deployment sollte automatisch erfolgen und binnen weniger Minuten nach dem Start durch den Kunden sicher in Produktion gehen.
Erkenntnisse aus Phase 2
Erkenntnis 1: Die Entscheidung, woran wir NICHT arbeiten, ist schwer, aber notwendig. Auch wenn es wichtig ist, auf Kundenanfragen zu reagieren, kann dies manchmal auch ablenken. Eine Priorisierung ist der erste Schritt. Kontinuierlich zu entscheiden und zu vermitteln, was wegfällt, ist aber noch wichtiger. Nein sagen ist hart. Doch es gilt: Nein sagen ist nur vorübergehend, Ja sagen ist für immer.
Erkenntnis 2: Die Skalierungsgeschwindigkeit muss beachtet werden. Nach der ersten Bewertung der Eignung des Produkts für einen Markt beginnt eine aufregende Zeit. Eine zu schnelle Skalierung birgt jedoch das Risiko, dass das Team aus verschiedenen Richtungen Ablenkung erfährt.
Im Ergebnis bleiben viele technische Schulden, und das Kundenvertrauen ist gestört. Bei einer zu langsamen Skalierung bleibt das Team unmotiviert zurück, die Kundenanforderungen werden zu lange nicht erfüllt, was ebenfalls das Kundenvertrauen stört. Es geht um eine fragile Balance. Hier sind einige Signale, nach denen Ausschau zu halten ist:
- Softwarequalität: Ändert sich die Rollback-Häufigkeit beim Deployment? Wie häufig wird das Team durch Partnerteams blockiert? Schlagen Tests jetzt häufiger fehl? Wie oft treten Vorfälle aufgrund eines Engpasses im System auf?
- Kundenstimmung: Erfolgt der Anstieg bei den Kundensupportanfragen nicht linear zur Anzahl der Anwendungsfälle? Gibt es Trends bei SLO-Verletzungen? Freuen sich die Kunden über die Ankündigung neuer Features? Welche Alternativen haben Kunden bei einer dringenden Anfrage schon in Betracht gezogen?
- Operativer Overhead: Ändert sich das zeitliche Verhältnis von Entwicklung bis Betrieb beim Team? Ändert sich das Verhältnis zwischen Ursachenanalyse und Vorfällen? Hat das Team einen Burnout von der operativen Belastung? Ändert sich die Innovationsfrequenz des Teams (beispielsweise Blogposts, Konferenzvorträge)?
Erkenntnis 3: Informieren der Benutzer und geduldiges Korrigieren falscher Vorstellungen. Es gab viele falsche Vorstellungen bei der Streamverarbeitung in Bezug auf die Datenqualität, zum Beispiel zu Ereignisausfällen oder Duplikaten, oder in Bezug auf die Verarbeitungssemantik, zum Beispiel zu Garantien für die Richtigkeit in Ausfallszenarien. Viele dieser falschen Vorstellungen stammten noch aus Zeiten, als die Streamverarbeitung unreif war. Die Entwicklung hier war jedoch immens. Hier heißt es, geduldig mit den Benutzern zu bleiben und sie mit Daten und Geschichten zu informieren.
Phase 3: Skalierung von Tausenden von Anwendungsfällen
Ein Jahr nach der ersten Einführung des Keystone-Produkts stieg die Anzahl der Anwendungsfälle im gesamten Unternehmen schnell von weniger als einem Duzend 2015 auf einige Hundert 2017. Wir hatten zu diesem Zeitpunkt eine solide operative Grundlage geschaffen: Kunden wurden selten während der Bereitschaft benachrichtigt, und alle Infrastrukturprobleme wurden vom Plattformteam engmaschig überwacht und behoben.
Wir hatten eine stabile Plattform für die Bereitstellung aufgebaut, über die unsere Kunden Änderungen binnen weniger Minuten produktiv stellen konnten.
Das Keystone-Produkt erfüllte den Zweck, für den es ursprünglich entwickelt wurde, hervorragend: eine Routing-Plattform für Streamingdaten, die benutzerfreundlich und fast unendlich skalierbar ist. Bald wurde jedoch deutlich, dass wir weit unter den vollen Möglichkeiten bei der Streamverarbeitung blieben.
Bei unseren Bemühungen, benutzerdefinierte Anwendungsfälle zu erfüllen, stießen wir immer wieder auf neue Anforderungen nach detaillierterer Steuerung komplexer Verarbeitungsfunktionen wie Streamingverbindungen, Fenstererstellung und anderes.
Inzwischen besitzt Netflix eine einzigartige Kultur der Freiheit und des Verantwortungsbewusstseins, in der jedes Team eigene technische Entscheidungen treffen kann. Diese Kultur bietet jedem Team die Möglichkeit, sogar in maßgeschneiderte Lösungen zu investieren. Als zentrales Plattformteam haben wir enormes Wachstum erfahren. Wenn wir keine Möglichkeit fänden, alles abzudecken, kämen langfristig hohe Kosten auf das Unternehmen zu.
Es war also an der Zeit, dass das Team seine Reichweite vergrößerte. Und wieder standen wir vor neuen Herausforderungen.
Herausforderungen in Phase 3
Herausforderung 1: Benutzerdefinierte Anwendungsfälle erfordern eine andere Erfahrung für Entwickler und operativen Betrieb. Zunächst stelle ich zwei Beispiele für benutzerdefinierte Anwendungsfälle bei der Streamverarbeitung vor.
Erstens: Berechnen der Streaminggrundlagen für Empfehlungen. Damit der Empfehlungsalgorithmus von Netflix eine möglichst gute Erfahrung bietet, muss das Modell mit den neuesten Daten trainiert werden. Eine Variante des Inputs zum Trainieren des Modells ist der Datensatz für Label. Die Label liefern die direkten, zugrundeliegenden Anzeichen dafür, ob die vorherigen personalisierten Prognosen passten oder nicht.
Wenn sich der Benutzer einen empfohlenen Film ansieht, wird ein positives Label vergeben. Wie sich schon vermuten lässt, ist Geschwindigkeit wichtig: Je schneller wir einen solchen Datensatz erstellen, umso schneller erhalten wir die Feedbackschleife für das maschinelle Lernen.
Um die Label zu berechnen, müssen wir den Wirkungsstream und den Stream mit Benutzerklicks zusammenführen. Die Benutzerklicks kommen allerdings häufig erst später an. So lassen sich manche Benutzer einige Minuten Zeit für die Entscheidung oder lassen ihre Geräte stundenlang eingeschaltet, ohne etwas anzusehen. Für den Anwendungsfall muss die Streaming-Pipeline die Label ausgeben, sobald alle relevanten Informationen eingegangen sind. Dabei gilt jedoch auch Toleranz gegenüber später eingehenden Informationen.
Zweitens: Berechnen des Übernahmeanteils bei Empfehlungen. Netflix gibt personalisierte Empfehlungen, um die Benutzererfahrung zu optimieren. Eine Variante ist ein Algorithmus zur Auswahl der am besten personalisierten künstlerischen Darstellung (und der besten Positionierung dafür), um den Übernahmeanteil beim Benutzer zu optimieren.
Intern berechnet eine Pipeline für die Streamverarbeitung diese Metrik für den Übernahmeanteil annähernd in Echtzeit, indem der Datenstream für die Wiedergabe mit dem Wirkungsstream über ein benutzerdefiniertes Fenster zusammengeführt wird. Aufgrund des Umfangs von Hunderten von Millionen Netflix-Nutzern muss der Streaming-Job konstant den internen Status überprüfen, was Checkpoints zwischen ein und zehn Terabyte umfasst.
Diese Anwendungsfälle nutzen fortschrittlichere Streamverarbeitungsfunktionen, beispielsweise komplexe Semantiken für Ereignis-/Verarbeitungszeit und Fenster, zulässige Verspätung, umfangreiches Checkpoint-Management. Zudem ist mehr operativer Support in den Bereichen Beobachtbarkeit, Fehlerbehebung und Wiederherstellung erforderlich.
Dafür müssen Entwickler ihr Vorgehen komplett umstellen und flexiblere Programmierschnittstellen und operative Funktionen wie einen benutzerdefinierten Stack für die Beobachtbarkeit, Funktionen zum Hinterfüllen sowie eine geeignete Infrastruktur für die Verwaltung vieler Terabyte lokaler Zustände nutzen. Das alles gab es bei Keystone nicht. Wir mussten also einen neuen Produkteinstiegspunkt schaffen und gleichzeitig redundante Investitionen möglichst gering halten.
Herausforderung 2: Ausgleich zwischen Flexibilität und Einfachheit. Mit all den neuen benutzerdefinierten Anwendungsfällen mussten wir das richtige Maß für die Kontrollexposition finden. Es gab die Möglichkeit, alles bis zur API auf der untersten Ebene zu exponieren, was aber eine deutlich größere operative Herausforderung bedeutete (da wir nie in der Lage sein würden, vollständig vorwegzunehmen, wie die Nutzer die Engine einsetzen). Oder wir konnten einen Mittelweg einschlagen (also nur eingeschränkte Funktionen exponieren) mit dem Risiko, dass die Kundenzufriedenheit litt.
Herausforderung 3: Höhere operative Komplexität. Durch die Unterstützung benutzerdefinierter Anwendungsfälle mussten wir den Freiheitsgrad der Plattform erhöhen. Folglich musste die operative Beobachtbarkeit in vielen komplexen Szenarien ebenfalls erhöht werden. Da zu der Zeit auch die Integration der Plattform mit vielen anderen Datenprodukten erfolgte, erhöhten sich die Berührungspunkte unseres Systems. Dies erforderte eine operative Koordinierung mit anderen Teams, um unsere gemeinsamen Kunden besser zu unterstützen.
Herausforderung 4: Zentrale Plattform oder lokale Plattform. Unser Team war dafür zuständig, eine zentralisierte Plattform für die Streamverarbeitung bereitzustellen. Aufgrund der vorherigen Strategie mit dem Fokus auf Einfachheit hatten allerdings manche Teams schon viel in ihre lokalen Plattformen zur Streamverarbeitung investiert und dabei teilweise nicht unterstützte Technologien wie Spark Streaming eingesetzt. Wir mussten sie nun davon überzeugen, auf einen schon vorhandenen Weg zurückzukehren, um das Risiko zu verringern, dass die Plattform gar nicht genutzt würde und Ressourcen für redundante Investitionen vergeudet würden. Jetzt ist die Zeit gekommen, um benutzerdefinierte Anwendungsfälle zu nutzen.
Zusammenfassung zu Streamverarbeitungsmustern in Phase 3
| Muster | Produkt | Anwendungsfälle |
|---|---|---|
| Verbindungen zwischen Streams (ETL) | Flink | Berechnung des Übernahmeanteils, Berechnung der Label für Empfehlungsdienst |
| Verbindungen zwischen Stream und Tabelle (ETL) | Flink | Zusätzlicher Input: Streams verbinden mit langsamer Iceberg-Tabelle |
| Streamingsitzung (ETL) | Flink | Personalisierungssitzung, Metrikensitzung |
| Beobachtbarkeit in Echtzeit | Mantis | Verteilte Nachverfolgung, Chaos EXPER-Überwachung, Anwendungsüberwachung |
| Anomalie-/Betreugserkennung in Echtzeit | Mantis, Flink | Kontextwarnung, PII-Erkennung, Verhindern betrügerischer Anmeldungen |
| DevOps-Entscheidung in Echtzeit Tool | Mantis | Automatische Skalierung, Streaming ACA und A/B-Tests, Optimierung der CDN-Platzierung |
| Ereignisquelle Materialansicht | Flink | Content Delivery Network Snapshots |
Strategiewetten und Erkenntnisse aus Phase 3
Wette 1: Aufbau eines neuen Produkteinstiegspunktes mit Refaktorierung bestehender Architektur oder Aufbau eines völlig neuen, isolierten Produkts. In Bezug auf die analytische Verarbeitung beschlossen wir, eine neue Plattform auf der ursprünglichen Architektur aufzubauen, um die komplette Leistung der Streamverarbeitung mit Apache Flink zu nutzen.
Wir würden ein völlig neues internes Kundensegment aufbauen, sahen aber den richtigen Zeitpunkt gekommen, die Architektur zu refaktorieren, um redundante Investitionen (zwischen den Plattformen Keystone und Flink) zu minimieren. Die niedrigere Flink-Plattform unterstützt sowohl Keystone- als auch benutzerdefinierte Anwendungsfälle in dieser neuen Architektur.
Wette 2: Erstes Streaming mit Anwendungsfällen für ETL und Beobachtbarkeit oder gleichzeitige Behandlung aller benutzerdefinierten Anwendungsfälle. Es gab viele Möglichkeiten, doch wir beschlossen, uns auf der analytischen Seite auf das Streaming von ETL-Anwendungsfällen und auf der operativen Seite auf Anwendungsfälle mit Beobachtbarkeit in Echtzeit zu konzentrieren.
Diese Anwendungsfälle stellen uns durch ihre Komplexität und ihren Umfang vor die größten Herausforderungen. Da wir die Leistung der Streamverarbeitung komplett abrufen wollten, hielten wir es für sinnvoll, zuerst die schwierigsten Fälle anzugehen und daraus zu lernen.
Wette 3: Anfängliches Teilen der operativen Verantwortung mit den Kunden und gemeinsame Innovationsschritte, um die langfristige Belastung zu verringern. Wir hatten das große Glück, dass unsere Early Adopters relativ anspruchslos waren. Außerdem boten wir den Kunden, die Schwierigkeiten hatten, umfassende Unterstützung an. Schrittweise erweiterten wir die operativen Investitionen, beispielsweise die automatische Skalierung, verwaltete Deployments, intelligente Warnungen, Hinterfüllmöglichkeiten und vieles mehr.
Erkenntnisse aus Phase 3
Erkenntnis 1: Ein neuer Produkteinstiegspunkt zur Unterstützung neuer benutzerdefinierter Anwendungsfälle ist ein wichtiger Entwicklungsschritt. Er bietet zudem die Möglichkeit einer Neugestaltung oder Refaktorierung der Architektur und der Anpassung an die bestehende Produktlandschaft. Man sollte sich nicht dazu verleiten lassen, ein komplett neues System aufzubauen. Ein zweites System muss vermieden werden.
Erkenntnis 2: Einfachheit ist in 80 Prozent der Anwendungsfälle attraktiv. Flexibilität ist für die größeren Anwendungsfälle hilfreich. Im Rückblick sind das Beobachtungen aus den tatsächlichen Kundensegmenten der vergangenen Jahre. Was ich damit sagen will, ist, dass die Priorisierung zwischen der Unterstützung der Mehrheit oder den Anwendungsfällen mit größerer Auswirkung von der jeweiligen Situation abhängt. Für beide Seiten gibt es gute Argumente, aber die Begründung sollte zum jeweiligen Geschäftsszenario passen.
Einfachheit und Flexibilität sind NICHT die beiden entgegengesetzten Enden des Spektrums, sondern eher eine in sich geschlossene Feedbackschleife für Innovationen. Flexibilität sorgt für neue, gemeinsame Innovationen mit einer kleinen Kundengruppe. Anfangs sind diese Innovationen vielleicht etwas teurer, aber wenn sie sich erstmal bewährt haben, kann dieser Mehrwert auch monetarisiert werden und die vereinfachte Erfahrung als Standard genutzt werden. Da die Innovationen auch zu höheren Kundenzahlen führen, fragt vielleicht erneut eine Gruppe neuer Nutzer nach der Flexibilität.
Erkenntnis 3: Gute Behandlung von Early Adoptern. Sie sind die treuesten Kunden und übernehmen kostenlos das Marketing. Dank der Unterstützung seitens unserer Early Adopter sind unsere Anwendungsfälle in dieser Phase in die Tausende gegangen.
Erkenntnis 4: Wenn etwas kaputt geht: keine Panik. Man sollte den Menschen in seinem Umfeld vertrauen. Ein Bonuspunkt ist eine bereits bestehende Community, die das Produkt unterstützt. Ich erinnere mich an eine Zeit, in der sich die gesamte Plattform nach und nach verschlechterte.
Jeden Tag kamen Unmengen von Seiten dazu, und wir schafften es zwei Wochen lang nicht, die Ursache zu finden. Das war erschreckend, dem Team ging es schlecht und die Kunden hatten zu leiden. Aber dem Team gelang es, über die Teamgrenzen hinweg zusammenzuarbeiten, Menschen mit den richtigen Fachkenntnissen einzubeziehen und anhand von Daten die Symptome logisch zu untersuchen.
Schließlich fanden wir einen Fehler im Linux-Kernel, der zu einem allmählichen Speicherleck beim Streaming-Workload führte. Wir mussten allen beteiligten Mitarbeitern vertrauen, auch wenn wir nicht alle über die entsprechenden Kompetenzen verfügten.
Phase 4: Erweiterte Zuständigkeiten bei der Streamverarbeitung
Während sich die Streamverarbeitung auf alle Unternehmensbereiche von Netflix ausdehnte, erkannten wir neue Muster und konnten frühe Erfolge verzeichnen. Aber für Selbstzufriedenheit ist kein Platz.
Netflix als Unternehmen hat immer neue Gebiete erforscht und enorme Investitionen in Studios zur Produktion von Inhalten und neuerdings auch ins Gaming getätigt. Daraus sind neue Herausforderungen entstanden, und wir haben uns aufgemacht, diese interessanten Probleme zu lösen.
Herausforderungen in Phase 4
Herausforderung 1: Vielfältige Datentechnologien machten die Koordinierung schwierig. Da die Teams eigenständig arbeiten, nutzen viele Teams bei Netflix sehr unterschiedliche Datentechnologien.
Im Transaktionsbereich sind das beispielsweise Cassandra, MySQL, Postgres, CockroachDB und Distributed Cache. Auf der analytischen Seite gibt es unter anderem Hive, Iceberg, Presto, Spark, Pig, Druid und Elasticsearch. Viele Kopien derselben Daten werden häufig in unterschiedlichen Datenspeichern innerhalb der Netflix-Datenlandschaft gespeichert.
Wenn es so viele Auswahlmöglichkeiten gibt, liegt es in der Natur des Menschen, die Technologien in verschiedene Bereiche aufzuteilen. Batch oder Streaming. Transaktionsspeicher oder analytischer Speicher. Online- oder Offlineverarbeitung. Diese Themen werden in der Datenwelt alle generell diskutiert. Die sich überlappenden Grenzen sorgen oftmals für größere Verwirrung bei den Endanwendern.
Heute stellen die Koordinierung und das Arbeiten mit Daten über technologische Grenzen hinweg eine unglaubliche Herausforderung dar. Es ist schwierig, Grenzen zu verschieben.
Herausforderung 2: Steilere Lernkurve. Da immer mehr Datentools zur Verfügung stehen und die Spezialisierung immer ausgeprägter wird, besteht die Herausforderung für die Nutzer darin, zu lernen und zu entscheiden, welche Technologie für einen bestimmten Anwendungsfall geeignet ist.
Herausforderung 3: Beim maschinellen Lernen wird nicht die gesamte Leistungsfähigkeit der Datenplattform ausgenutzt. Alle oben genannten Herausforderungen sorgen beim maschinellen Lernen für zusätzliche Schwierigkeiten. Die Feedbackschleifen der Datenwissenschaftler sind zu lang, die Produktivität von Dateningenieuren leidet, Produktingenieure stehen vor Problemen beim Weitergeben wertvoller Daten. Schließlich entgehen Unternehmen viele Chancen zur Anpassung an den sich schnell ändernden Markt.
Herausforderung 4: Grenzen der Skalierung im Modell mit zentraler Plattform. Da die zentrale Datenplattform Anwendungsfälle mit einer superlinearen Rate skaliert, ist es nicht nachhaltig, einen einzelnen Kontaktpunkt für den Support zu nutzen. Es ist an der Zeit, ein Modell zu evaluieren, bei dem die zentrale Plattform lokale zentrale Plattformen für eine zusätzliche Nutzung unterstützt (das heißt, wir priorisieren die Unterstützung der lokalen Plattformen, die auf unserer Plattform aufbauen).
Chancen und Ausblick
Das Thema Chancen werde ich hier nur kurz streifen. In künftigen Beiträgen gehe ich detaillierter darauf ein.
Mit Streams Welten verbinden. Bei der Streamverarbeitung gilt neben der Stärke bei der Verarbeitung mit niedriger Latenz eine offensichtlich sogar wichtigere Stärke in Bezug auf moderne Datenplattformen, nämlich die Verbindung verschiedener Technologien und die Umsetzung eines flüssigen Datenaustausches.
Technologien wie Change Data Capture (CDC), das Streaming von Materialansichten sowie Datenvernetzungskonzepte gewinnen zunehmend an Popularität. Schließlich wird auch Martin Kleppmanns Vision von 2015, Datenbanken von innen nach außen zu wenden langsam, zur Realität.
Höhere Abstraktion durch die Kombination aus Einfachheit und Flexibilität. In umfassenden internen Kenntnissen zu verschiedenen Datentechnologien liegt ein großer Mehrwert. Aber nicht jeder muss sich darin auskennen. Das gilt insbesondere, wenn Dateninfrastrukturen mit Cloud-First-Ansatz zur Normalität werden.
Wenn die Abstraktion der Dateninfrastruktur zunehmend höher wird, entsteht unmittelbar die Chance, alle fortschrittlichen Funktionen ganz einfach einer größeren Zielgruppe zur Verfügung zu stellen. Technologien wie Streaming-SQL senken die Einstiegshürden, sind allerdings erst der Anfang. Datenplattformen sollten auch an den Grenzflächen (also Streaming oder Batch) die Abstraktion erhöhen, die Endanwender nicht zu Gesicht bekommen.
Maschinelles Lernen benötigt mehr Aufmerksamkeit von modernen Datenplattformen. Maschinelles Lernen hat die größten Auswirkungen im Unternehmen. Die Mitarbeiter in diesem Bereich gehören allerdings unter allen Entwicklern zu denen, die am wenigsten Unterstützung erhalten. Alle Plattformen für maschinelles Lernen beruhen auf Datenspeichern und Datenverarbeitung.
Es gibt also viele Möglichkeiten für das Datenplattformteam, eine helfende Hand in Richtung maschinelles Lernen auszustrecken: Datenqualität, Zuverlässigkeit und Skalierbarkeit, Feedbackschleife zwischen Entwicklung und Produktion, Beobachtbarkeit in Echtzeit, Effizienz insgesamt und vieles mehr.
Zusammenfassung zu Streamverarbeitungsmustern in Phase 4
| Muster | Produkt | Anwendungsfälle |
|---|---|---|
| Streaming-Hinterfüllung / Neuformulierung | Flink | Abmilderung von Pipeline-Fehlern, Kaltstart vermeiden |
| Datenqualitätskontrolle | Keystone, Flink | Management für Schemaentwicklung, SLA für Datenqualität, Kostensenkung über Avro-Komprimierung |
| Quelle / Senke - agnostische Datensynchronisierung | Keystone, Flink | Delta, Datenvernetzung, Operative Berichte, Benachrichtigung, Pipeline für Suchindex |
| Annähernde Echtzeit-Inferenz | Flink | Empfehlung für Kundenservice, absichtsbasierte Sitzungsanpassungen |
| Streaming-SQL | Flink | Dynamische Funktionsentwicklung |
| Intelligenter Betrieb | 4 | Automatische Diagnose und Behebung |
Ich bin schon sehr gespannt auf die Zukunft der Dateninfrastruktur, insbesondere bei der Unterstützung für bessere Erfahrungen mit maschinellem Lernen. Ich glaube, dass hier die nächste Grenze ist, die wir überwinden müssen. Über Rückmeldungen zu diesem Beitrag freue ich mich sehr. Networking ist wichtig.
Danksagung: Viele Menschen haben mir bei der Überarbeitung dieses Beitrags geholfen. Ohne ihr Feedback wäre mir so manches Detail gar nicht aufgefallen. Mein besonderer Dank gilt Chip Huyen, Steven Wu, Prashanth Ramdas, Guanhua Jiang, Scott Shi, Goku Mohandas, David Sun, Astasia Myers und Matt Willian. Zhenzhong Xu(öffnet im neuen Fenster) leitete bei Netflix unter anderem das Team für die Engines zur Streamverarbeitung. Jetzt ist er selbständig und entwickelt mit seinem Unternehmen eine Streaming-First-Machine-Learning-Plattform.
Anhang: Streamverarbeitungsmuster bei Netflix
| Muster | Phase | Anwendungsfälle |
|---|---|---|
| Datenrouting | 1 | Protokollierung, Datenbewegung |
| Echtzeitwarnungen / Dashboard | 1, 2 | SPS-Warnung, Infrastrukturzustand, Überwachung (Cassandra & Elasticsearch), Echtzeit-QoE-Überwachung |
| Echtzeit-Datenstichproben / Entdeckung | 2 | Kostengünstige Echtzeitinformationen |
| Verbindungen zwischen Streams (ETL) | 3 | Berechnung des Übernahmeanteils, Berechnung der Label für Empfehlungsdienst |
| Verbindungen zwischen Stream und Tabelle (ETL) | 3 | Zusätzlicher Input: Streams verbinden mit langsamer Iceberg-Tabelle |
| Streamingsitzung | 3 | Personalisierungssitzung, Metrikensitzung |
| Beobachtbarkeit in Echtzeit | 3 | Verteilte Nachverfolgung, Chaos EXPER-Überwachung, Anwendungsüberwachung |
| Anomalie-/Betrugserkennung in Echtzeit | 3 | Kontextwarnung, PII-Erkennung, Verhindern betrügerischer Anmeldungen |
| DevOps-Entscheidung in Echtzeit Tool | 3 | Automatische Skalierung, Streaming ACA und A/B-Tests, Optimierung der CDN-Platzierung |
| Ereignisquelle Materialansicht Streaming-Hinterfüllung / Neuformulierung | 3 | Content Delivery Network Snapshots, Abmilderung von Pipeline-Fehlern, Kaltstart vermeiden |
| Datenqualitätskontrolle | 4 | Management für Schemaentwicklung, SLA für Datenqualität, Kostensenkung über Avro-Komprimierung |
| Quelle/Senken - agnostische Datensynchronisierung | 4 | Delta, Datenvernetzung, Operative Berichte, Benachrichtigung, Pipeline für Suchindex |
| Annähernde Echtzeit-Inferenz | 4 | Empfehlung für Kundenservice, absichtsbasierte Sitzungsanpassungen |
| Streaming-SQL | 4 | Dynamische Funktionsentwicklung |
| Intelligenter Betrieb | 4 | Automatische Diagnose und Behebung |