Vorstellung von Netflix’ TimeSeries Data Abstraction Layer

• Mit der Expansion von Netflix in verschiedene Bereiche wie VoD und Gaming wird die Fähigkeit immer wichtiger, große Mengen zeitbezogener Daten im Petabyte-Bereich mit Latenzen im Millisekundenbereich zu speichern und zu verarbeiten.
• Auf Basis einer Key-Value-Abstraktion und der Data-Gateway-Plattform hat Netflix eine TimeSeries-Abstraktion entwickelt, die eine Lösung bietet, um zeitliche Ereignisdaten über verschiedene Anwendungsfälle hinweg effizient zu speichern und abzufragen.

Herausforderungen

• Bei Netflix werden fortlaufend zeitbezogene Daten aus Benutzerinteraktionen, Asset-Expositionen und Aktivitäten in komplexen Microservice-Netzwerken erzeugt und genutzt.
• Diese Daten effektiv zu verwalten, ist entscheidend, um Nutzererfahrung und Systemzuverlässigkeit sicherzustellen.
• Zentrale Herausforderungen:
  • Hoher Durchsatz: Es müssen bis zu 10 Millionen Schreibvorgänge pro Sekunde bei hoher Verfügbarkeit verarbeitet werden.
  • Effiziente Abfragen auf großen Datensätzen: Es müssen Daten im Petabyte-Bereich gespeichert werden, während Ergebnisse für Primary-Key-Reads in niedrigen Millisekunden zurückgegeben und Suchen sowie Aggregationen über mehrere sekundäre Attribute unterstützt werden.
  • Globale Lese- und Schreibvorgänge: Lese- und Schreiboperationen müssen von überall auf der Welt unterstützt werden, mit einem konfigurierbaren Konsistenzmodell.
  • Anpassbare Konfiguration: Es muss möglich sein, Datensätze in Single-Tenant- oder Multi-Tenant-Datastores aufzuteilen.
  • Umgang mit Traffic-Spitzen: Lastspitzen etwa bei neuen Content-Releases oder regionalen Recovery-Ereignissen müssen bewältigt werden.
  • Kosteneffizienz: Infrastrukturkosten müssen minimiert und gleichzeitig die langfristige Aufbewahrung optimiert werden.

TimeSeries-Abstraktion

• Datenpartitionierung: Durch eine eigene zeitliche Partitionierungsstrategie und einen Event-Bucket-Ansatz werden Burst-Workloads effizient verarbeitet und Abfragen vereinfacht.
• Flexibler Speicher: Das System ist für die Integration mit unterschiedlichen Storage-Backends wie Apache Cassandra und Elasticsearch ausgelegt.
• Konfigurierbarkeit: Für jeden Datensatz stehen verschiedene anpassbare Optionen zur Verfügung, um unterschiedliche Anwendungsfälle flexibel zu unterstützen.
• Skalierbarkeit: Horizontale und vertikale Skalierung werden unterstützt, damit wachsender Durchsatz und steigende Datenvolumina mit der Nutzerbasis und den Services von Netflix mitwachsen können.
• Shard-Infrastruktur: Mithilfe der Data Gateway Platform lassen sich Single-Tenant- und/oder Multi-Tenant-Infrastrukturen mit der nötigen Zugriffs- und Traffic-Isolierung bereitstellen.

Datenmodell

• Es folgt einem eigenen Event-Datenmodell, das Ereignisdaten kapselt und effizient abfragbar macht.
• Event Item: Ein Event Item ist ein Schlüssel-Wert-Paar, das Nutzer zum Speichern von Daten zu einem bestimmten Ereignis verwenden. Beispiel: {"device_type": "ios"}
• Event: Ein Event ist eine strukturierte Sammlung aus einem oder mehreren Event Items. Es tritt zu einem bestimmten Zeitpunkt auf und wird durch einen clientseitig erzeugten Zeitstempel und eine Event-ID (z. B. UUID) identifiziert. Die Kombination aus event_time und event_id bildet einen Teil des eindeutigen Idempotenzschlüssels eines Events, sodass Nutzer Anfragen sicher wiederholen können.
• Time-Series-ID: Eine time_series_id ist eine Sammlung von einem oder mehreren Events, die während der Aufbewahrungsdauer eines Datensatzes auftreten. So speichert etwa eine device_id alle Events, die während der Aufbewahrungsdauer auf einem bestimmten Gerät auftreten. Alle Events sind unveränderlich, und der TimeSeries-Service hängt Events nur an eine gegebene Time-Series-ID an.
• Namespace: Ein Namespace ist eine Sammlung aus Time-Series-IDs und Event-Daten und repräsentiert den gesamten TimeSeries-Datensatz. Nutzer können für jeden Use Case einen oder mehrere Namespaces anlegen. Die Abstraktion wendet verschiedene konfigurierbare Optionen auf Namespace-Ebene an.

API

• WriteEventRecordsSync: Dieser Endpunkt schreibt einen Batch von Events und sendet dem Client eine Bestätigung der Dauerhaftigkeit zurück. Er wird verwendet, wenn Nutzer Garantien für die Persistenz benötigen.
• WriteEventRecords: Dies ist die Fire-and-Forget-Version des obigen Endpunkts. Sie stellt einen Event-Batch ohne Persistenzbestätigung in die Warteschlange. Das eignet sich für Fälle wie Logging oder Tracing, in denen Durchsatz wichtiger ist und ein geringer Datenverlust tolerierbar ist.
• ReadEventRecords: Wenn eine Kombination aus Namespace, timeSeriesId, timeInterval und optionalen eventFilters gegeben ist, gibt dieser Endpunkt alle passenden Events in absteigender Reihenfolge nach event_time mit niedriger Latenz im Millisekundenbereich zurück.
• SearchEventRecords: Bei gegebenen Suchkriterien und Zeitintervall liefert dieser Endpunkt alle passenden Events zurück. Diese Use Cases eignen sich für letztlich konsistente Lesevorgänge.
• AggregateEventRecords: Wenn Suchkriterien und ein Aggregationsmodus (z. B. DistinctAggregation) gegeben sind, führt dieser Endpunkt die angegebene Aggregation innerhalb des Zeitintervalls aus. Ähnlich wie beim Search-Endpunkt können Nutzer hier eventuelle Konsistenz und potenziell höhere Latenzzeiten im Sekundenbereich in Kauf nehmen.

Speicher-Schicht

• Die Speicher-Schicht von TimeSeries besteht aus einem primären Datastore und einem optionalen Index-Datastore.
• Apache Cassandra wird als Datastore bevorzugt, wenn in Szenarien mit hohem Durchsatz Dauerhaftigkeit sichergestellt werden muss.
• Elasticsearch wird als Datastore für die Indexierung bevorzugt.

Primärer Datastore

• Apache Cassandra wird genutzt, um TimeSeries-Anwendungsfälle zu verarbeiten.
• Das Datenmanagement erfolgt über Temporal Partitioning, bei dem Daten anhand von Zeitintervallen in Chunks aufgeteilt werden.
  • Zeitscheibe: Abbildung auf eine Cassandra-Tabelle, die der Aufbewahrungsdauer entspricht
  • Zeit-Bucket: Weitere Partitionierung innerhalb einer Zeitscheibe zur Optimierung von Abfragen über bestimmte Zeitbereiche
  • Event-Bucket: Weitere Partitionierung von Zeit-Buckets zur Verarbeitung großer Schreibmengen einer Time Series in kurzer Zeit
• Datentabellen speichern die eigentlichen Event-Daten, Metadatentabellen enthalten Informationen zur Konfiguration der Zeitscheiben pro Namespace.

Index-Datastore

• Zur Unterstützung sekundärer Zugriffsmuster über Nicht-Primary-Key-Attribute werden Daten in Elasticsearch indexiert.
• Nutzer können die Liste der Attribute, nach denen gesucht und aggregiert werden soll, pro Namespace konfigurieren.

Control Plane

• Die Data Plane übernimmt Lese- und Schreiboperationen, die Control Plane konfiguriert alle Aspekte des Namespace-Verhaltens.
• Die Data Plane kommuniziert mit dem TimeSeries-Control-Stack, der wiederum mit der Data-Gateway-Control-Plane interagiert.
• Über die Namespace-Konfiguration lassen sich verschiedene Aspekte flexibel anpassen, etwa zeitliche Partitionierung, Buffering, Konsistenz oder Aufbewahrung.

Namespace-Konfiguration

• Ein Konfigurations-Snippet, das die Flexibilität des Services zeigt, macht deutlich, dass sich pro Namespace viele Dinge anpassen lassen.

Infrastruktur-Provisionierung

• Unter Berücksichtigung verschiedener Parameter werden über automatisierte Provisionierungs-Workflows optimale Einstellungen ermittelt.
• Das System provisioniert zunächst die Anfangsinfrastruktur und skaliert danach entsprechend der Nutzer-Workloads.

Skalierbarkeit

• Da Nutzungsprognosen bei der initialen Provisionierung nur begrenzt möglich sind, sind nachträgliche Anpassungen nötig.
• Horizontale Skalierung: TimeSeries-Serverinstanzen werden je nach Traffic-Bedarf automatisch hoch- und herunterskaliert.
• Vertikale Skalierung: TimeSeries-Serverinstanzen oder Storage-Instanzen können vertikal skaliert werden, um mehr CPU, RAM und/oder angeschlossene Speicherkapazität zu erhalten.
• Festplatten-Skalierung: Daten können auf angebundenem EBS gespeichert werden; sobald der Speicher einen bestimmten Schwellenwert erreicht, werden die EBS-Volumes erweitert.
• Durch Neu-Partitionierung von Daten lassen sich über- oder unterpartitionierte Datensätze anpassen.

Designprinzipien

• Event-Idempotenz: In alle mutierenden Endpunkte ist Idempotenz eingebaut, damit Nutzer Anfragen sicher wiederholen können.
• SLO-basiertes Hedging: Für verschiedene Endpunkte werden Service-Level-Objective-(SLO)-Ziele festgelegt, um die Performance sicherzustellen.
• Teilrückgaben: Wenn Clients latenzsensitiv sind, können sie partielle Ergebnismengen akzeptieren.
• Adaptive Paginierung: Wenn die Service-Schicht erkennt, dass ein Time-Series-Datensatz dicht befüllt ist, passt sie den Fan-out-Faktor dynamisch an.
• Begrenztes Schreibfenster: Daten werden so schnell wie möglich unveränderlich gemacht, damit Optimierungen angewendet werden können.
• Write Buffering: Um Burst-Workloads zu verarbeiten, werden Events für kurze Zeit zusammengeführt, damit die Last gleichmäßiger verteilt wird.
• Dynamische Komprimierung: Sobald Daten unveränderlich sind, werden Komprimierungsstrategien verwendet, um die Leseleistung zu optimieren.

Reale Performance

• Der Service kann Daten mit niedriger Latenz im Millisekundenbereich schreiben und dabei stabile Punktlese-Latenzen aufrechterhalten.

Einsatz von Time Series bei Netflix

Die TimeSeries-Abstraktion spielt eine wichtige Rolle in zentralen Services von Netflix. Einige besonders wirkungsvolle Use Cases sind:

• Tracing und Insights: Log-Tracing über alle Apps und Microservices bei Netflix hinweg, um die Kommunikation zwischen Services zu verstehen, Probleme zu debuggen und Support-Anfragen zu beantworten
• Tracking von Benutzerinteraktionen: Millionen von Benutzerinteraktionen wie Videowiedergabe, Suche und Content-Engagement werden verfolgt, um die Empfehlungsalgorithmen von Netflix in Echtzeit zu verbessern und Erkenntnisse zur Optimierung des gesamten Nutzererlebnisses zu liefern
• Feature-Rollouts und Performance-Analyse: Die Einführung und Performance neuer Produktfunktionen werden verfolgt, damit Netflix-Ingenieure messen können, wie Nutzer mit Features interagieren, was datenbasierte Entscheidungen für künftige Verbesserungen unterstützt
• Tracking und Optimierung von Asset-Impressions: Asset-Expositionen werden erfasst, damit Inhalte und Assets effizient ausgeliefert werden, während gleichzeitig Echtzeit-Feedback für Optimierungen bereitsteht
• Abrechnung und Abo-Management: Historische Daten zu Abrechnung und Abo-Verwaltung werden gespeichert, um die Genauigkeit von Transaktionsverläufen sicherzustellen und Kundenservice-Anfragen zu unterstützen

Zukünftige Verbesserungen

Da sich die Use Cases weiterentwickeln und die Notwendigkeit steigt, die Abstraktion kosteneffizienter zu machen, plant Netflix in den kommenden Monaten viele Verbesserungen am Service. Einige davon sind:

• Tiered Storage für Kosteneffizienz: Unterstützung dafür, ältere und seltener genutzte Daten in günstigeren Object Storage mit längerer Time-to-First-Byte zu verschieben, was Netflix Millionen Dollar sparen könnte
• Dynamisches Event-Bucketing: Statt bei der Provisionierung eines Namespace eine relativ statische Konfiguration zu haben, sollen Schlüssel beim Streaming von Events in Echtzeit in Partitionen optimaler Größe aufgeteilt werden. Ein großer Vorteil dieser Strategie ist, dass sie die Gesamtkosten der Read Amplification senkt, indem time_series_id, die keine Partitionierung benötigen, nicht partitioniert werden. Außerdem bringt Cassandra 4.x deutliche Verbesserungen beim Lesen von Teilmengen aus sehr breiten Partitionen, wodurch die Notwendigkeit sinken könnte, den gesamten Datensatz im Voraus aggressiv zu partitionieren.
• Caching: Die Unveränderlichkeit der Daten soll genutzt werden, um einzelne Zeitbereiche intelligent zu cachen.
• Counts und weitere Aggregationen: Manche Nutzer interessieren sich nur für die Anzahl von Events in einem bestimmten Zeitintervall, statt alle Event-Daten abzurufen.

Fazit

• Die TimeSeries Abstraction ist ein wichtiger Baustein der Online-Dateninfrastruktur von Netflix und unterstützt Entscheidungen in Echtzeit ebenso wie langfristige Entscheidungen.
• Mit der Expansion von Netflix in neue Bereiche bleibt die TimeSeries Abstraction ein Kernelement der Plattform und wird dazu beitragen, die Möglichkeiten von Streaming und darüber hinaus zu erweitern.

Meinung von GN⁺

• Beeindruckend ist das Know-how von Netflix, mit der TimeSeries-Abstraktion gleichzeitig Skalierbarkeit, Flexibilität und Kosteneffizienz zu erreichen und so gewaltige Mengen an Zeitreihendaten zuverlässig zu verarbeiten. Besonders auffällig sind Techniken wie zeitbasierte Partitionierung, Write Buffering und dynamische Komprimierung, die auf Datencharakteristika und Zugriffsmuster optimiert sind.
• Es wirkt effektiv, dass Netflix nicht einfach nur eine Time-Series-DB nutzt, sondern über eine Abstraktionsschicht verschiedene Speicher wie Cassandra und Elasticsearch flexibel einsetzen und über ein Kontrollsystem die Infrastruktur passend zu den Workload-Eigenschaften provisionieren und betreiben kann. Durch die Abstraktion wird Komplexität verborgen, sodass sich Nutzer auf die Daten konzentrieren können.
• Aktuell verarbeitet das System Daten im Petabyte-Maßstab und bis zu 15 Millionen Events pro Sekunde, was es zu einem starken Vorbild für Unternehmen macht, die Hochleistungs-Pipelines für Zeitreihendaten aufbauen wollen. Das zeigt besonders, dass bei großen Services nicht nur Datenvolumen und Geschwindigkeit, sondern auch Kosten ganzheitlich berücksichtigt werden müssen.
• Da die Lösung in zentralen Bereichen des Netflix-Geschäfts wie Tracing, Analyse des Nutzerverhaltens und Abrechnungsmanagement breit eingesetzt wird, wird deutlich, dass Zeitreihendaten ein Motor für datenbasierte Entscheidungen und Service-Innovationen sind. Es geht nicht nur um Logging, sondern auch um die Grundlage für ML-/AI-basierte Services wie Echtzeit-Empfehlungen.
• Die geplanten Verbesserungen wie tiered Storage, dynamische Partitionierung und Aggregationsoperationen zeigen den Willen zur kontinuierlichen Weiterentwicklung. Um auf schnell wechselnde geschäftliche Anforderungen zu reagieren, dürfte eine solche fortlaufende Innovation notwendig sein. Es bleibt zu hoffen, dass das dabei angesammelte Know-how über Open Source oder andere Wege geteilt wird.