- Kafka war als verteiltes Log für die Rechenzentrumsära erfolgreich, doch in der Public Cloud werden Netzwerkkosten zwischen AZs und der Betriebsaufwand für lokale Festplatten erheblich
- WarpStream ist eine mit dem Apache-Kafka-Protokoll kompatible diskless Streaming-Plattform, die auf Objektspeichern wie S3 ohne lokale Festplatten und ohne Broker-Rebalancing läuft
- Ein Kafka-Cluster über 3 Availability Zones verursacht selbst im besten Fall pro 1 GiB Streaming etwa 0,053 US-Dollar an zonenübergreifenden Übertragungskosten; das ist mehr als die monatliche Speicherung von 1 GiB in S3 für 0,021 US-Dollar
- WarpStream trennt mit einem zustandslosen Go-Binary namens Agent und einem separaten Metadatenspeicher Storage und Compute sowie Daten und Metadaten; die Daten verbleiben im Objektspeicher des Cloud-Kontos des Nutzers
- Die Kosten können bei den meisten Kafka-Workloads um 5- bis 10-mal sinken, allerdings nimmt die aktuelle Implementierung eine Latenz von etwa 400 ms P99 für Produce-Requests und etwa 1 Sekunde P99 Ende-zu-Ende vom Producer zum Consumer in Kauf
Die Grundstruktur von Kafka, die in der Cloud teuer geworden ist
- Apache Kafka wurde 2011 als Open Source veröffentlicht und hat sich danach als grundlegende Infrastruktur für Streaming-Architekturen etabliert
- Das Problem ist weniger Kafka selbst, sondern dass ein Design, das auf das LinkedIn-Rechenzentrum von 2011 zugeschnitten war, nicht gut zu modernen Cloud-Workloads passt
- Besonders deutlich werden Kosten und Betriebsaufwand
- Cloud-Ökonomie: Kafkas Replikationsverfahren kann erhebliche Bandbreitenkosten zwischen AZs verursachen
- Betriebsaufwand: Der Betrieb eines eigenen Kafka-Clusters erfordert ein dediziertes Team und maßgeschneiderte Tools
- Ähnliche Systeme, die Daten auf lokalen Festplatten speichern, können dieselben Kosten- und Betriebsprobleme haben
Kafka-nomics: Übertragungskosten zwischen AZs
- In einem typischen Kafka-Cluster über 3 Availability Zones werden erzeugte Daten wegen der Position des Partitions-Leaders mit einer Wahrscheinlichkeit von 2/3 zonenübergreifend geschrieben; anschließend repliziert der Leader die Daten an Follower in den beiden anderen Zonen
- Wenn 1 GiB zwischen Zonen übertragen wird, werden die Kosten mit 0,022 US-Dollar berechnet
- Egress aus der Ausgangszone: 0,01 US-Dollar
- Ingress in die Zielzone: 0,01 US-Dollar
- Selbst im besten Fall liegen die Kosten für das Streaming von 1 GiB bei etwa
0.02 * 2/3 + 0.02 * 2 = $0.053
- Die monatliche Speicherung von 1 GiB in S3 kostet 0,021 US-Dollar; für die Kosten, Daten mit Kafka vom Producer bis zum Consumer zu kopieren, könnte man dieselben Daten mehr als zwei Monate lang in S3 speichern
- Bei Kafka-Clustern mit hohem Durchsatz dominieren nicht die Hardwarekosten, sondern Bandbreitengebühren zwischen AZs; sie können 70 bis 90 % der Workload-Kosten ausmachen
- Auch bei niedrigem Durchsatz wächst bei langen Aufbewahrungszeiten der Speicherbedarf, und eine dreifache Replikation auf lokalen SSDs kann selbst bei angenommener 100%iger Festplattenauslastung pro GiB etwa 10- bis 20-mal teurer sein als Objektspeicher wie S3
Cluster-Betrieb, der bei Entwicklern hängen bleibt
- Entwickler führen Kafka ein, um Geschäftsprobleme zu lösen, müssen aber zunächst Kafka und ZooKeeper oder KRaft, Leader Elections, Partitionen, Consumer Groups, Rebalancing, Broker-Tuning und Client-Tuning lernen
- Kafkas Data Plane, die Broker, sowie die konsensbasierte Control Plane aus Controllern, ZooKeeper und Ähnlichem werden alle direkt auf lokalen SSDs betrieben
- Bei selbst gehosteten Kafka-Clustern erfordern schon Basisaufgaben wie Knotentausch oder Cluster-Erweiterung ein spezialisiertes Team und Custom-Tools, wenn sie sicher durchgeführt werden sollen
- Das in Apache Kafka integrierte Tool zur Partitions-Neuzuweisung kann beim Stilllegen eines Brokers keinen automatischen Reassignment-Plan erstellen; Administratoren müssen den Plan zum Verschieben von Partitions-Replikaten selbst schreiben
- Auch gehostete Dienste wie AWS MSK beseitigen den Betriebsaufwand nicht vollständig
- Die Dokumentation zum Cluster-Rebalancing von MSK verweist auf die Apache-Kafka-Dokumentation
- Das Verfahren umfasst das manuelle Bearbeiten von JSON, um festzulegen, welche Partition auf welchen Broker verschoben wird
- Cruise Control kann die Last verringern, bringt aber zusätzliche Konzepte, Deployment und Monitoring eines separaten Dienstes sowie operative Fallstricke mit sich
- Cruise Control selbst ist ebenfalls eine JVM-Anwendung, die von Apache Kafka und ZooKeeper abhängt
Der Ansatz, Streaming auf Objektspeicher zu setzen
- Husky von Datadog war eine spaltenorientierte Datenbank für Observability-Daten, die direkt auf S3 lief, und funktionierte größtenteils als zustandsloser, automatisch skalierender Data Lake
- Nach dem Aufbau von Husky wirkten Kafka-Cluster im Vergleich wie eine veraltete Architektur
- Die Kafka-Bandbreite von Datadog lag im zweistelligen GiB/s-Bereich, der Broker-Speicher wurde in PiB an NVMe gemessen
- Große Speicher-Workloads können in Cloud-Umgebungen nur schwer mit der Wirtschaftlichkeit, Zuverlässigkeit, Skalierbarkeit und Elastizität von Objektspeicher konkurrieren
- Auch Big-Data-Technologien wie Snowflake und Databricks entwerfen ihre Systeme rund um universellen Objektspeicher
- Wenn man ein Kafka-ähnliches System direkt auf S3 baut, lassen sich zwei Belastungen gleichzeitig reduzieren
- Geringere Kosten
- Weniger traditionelle Kafka-Betriebsprobleme
- Die zentrale Schwierigkeit besteht darin, auf einem Storage-Medium mit hoher Latenz wie S3 eine Low-Latency-Streaming-Infrastruktur zu bauen, die ohne lokale Festplatten die Semantik des Kafka-Protokolls beibehält
WarpStream-Architektur
- WarpStream ist eine mit dem Apache-Kafka-Protokoll kompatible Streaming-Plattform, die direkt auf universellen Objektspeichern wie AWS S3, GCP GCS und Azure Blob Storage läuft
- Es gibt keine Bandbreitenkosten zwischen AZs, keine lokalen Festplatten zu verwalten, und der Betrieb kann innerhalb der VPC des Nutzers erfolgen
- Statt Kafka-Brokern verwendet es Agents
- Ein Agent ist ein zustandsloses Go-Binary
- Er verwendet keine JVM
- Er spricht das Kafka-Protokoll
- Jeder Agent kann die Rolle eines Topic-Leaders, eines Committers für Consumer-Group-Offsets oder eines Cluster-Koordinators übernehmen
- WarpStream ersetzt Kafkas zustandsbehaftete Struktur durch zwei Trennungen
- Storage und Compute werden getrennt, und Daten werden nach S3 ausgelagert
- Daten und Metadaten werden getrennt, und Metadaten werden in einen maßgeschneiderten Metadatenspeicher ausgelagert
- Wenn der gesamte Storage an Objektspeicher übergeben wird, ist beim Hoch- oder Herunterskalieren der Anzahl der Agents entsprechend der Laständerung kein Daten-Rebalancing nötig
- Bei Ausfällen können Requests sofort über einen anderen Agent erneut versucht werden, was die Wiederherstellung beschleunigt
- Auch das Hotspot-Problem, bei dem einige Kafka-Broker wegen ungleich verteilter Daten pro Partition stärker belastet werden, wird größtenteils reduziert
- Die Metadaten eines WarpStream Virtual Cluster werden in einer maßgeschneiderten Metadaten-Datenbank gespeichert
- Datenreplikation, Dauerhaftigkeit und Verfügbarkeit übernimmt der Objektspeicher-Bucket, und die Daten des Nutzers bleiben im Cloud-Konto
- Das Einzige, was das Cloud-Konto verlässt, sind Workload-Metadaten, die für Konsens nötig sind, etwa die Batch-Reihenfolge innerhalb einer Partition
- Die detaillierte Struktur ist in der WarpStream-Architekturdokumentation beschrieben
Kostenbeispiel und Latenz-Trade-off
- Ein kontinuierlicher Streaming-Workload in der Testumgebung produziert fortlaufend 140 MiB/s Daten, die von 3 dedizierten Consumern konsumiert werden, wodurch insgesamt 560 MiB/s kontinuierliche Datenübertragung entstehen
- Die zonenübergreifenden Netzwerkkosten des gesamten Cloud-Kontos wurden im Tagesdurchschnitt mit weniger als 15 US-Dollar gemessen
- Wird derselbe Workload auf einem Kafka-Cluster ausgeführt, ergeben sich allein für zonenübergreifende Netzwerkkosten 641 US-Dollar pro Tag
- Die Berechnung lautet
0.14GiB * $0.053/GiB * 60 * 60 * 24
- Die Kosten für S3-API-Operationen desselben Workloads liegen unter 40 US-Dollar pro Tag
- Für die Agent-Hardware sind nur VMs im Umfang von 27 vCPUs nötig
- Die Total Cost of Ownership der meisten Kafka-Workloads kann mit WarpStream um 5- bis 10-mal niedriger ausfallen
- Der größte Nachteil ist die Latenz
- Produce-Requests liegen aktuell bei etwa 400 ms P99
- Das liegt daran, dass erst bestätigt wird, wenn die Daten dauerhaft in S3 gespeichert und in der Cloud-Control-Plane committed wurden
- Die Ende-zu-Ende-Latenz vom Producer zum Consumer liegt bei etwa 1 Sekunde P99
- Wenn ein Workload etwa 1 Sekunde P99-Latenz vom Producer zum Consumer toleriert, lassen sich die Streaming-Kosten pro GiB um das 5- bis 10-fache senken und der Betriebsaufwand nahezu eliminieren
- Die Schnittstelle ist kein proprietäres Protokoll, sondern Kafka, und sie kann in Umgebungen laufen, die AWS S3, GCP GCS und Azure Blob Storage verwenden
Developer Experience und Nutzung
- WarpStream adressiert unter Kafkas Hauptproblemen zuerst die Cloud-Ökonomie und den Betriebsaufwand
- Kafka hat auch Probleme bei der Developer Experience, und Partitionen gelten als zu niedrig angesetzte Abstraktion, um komplexe Stream-Processing-Anwendungen zu schreiben
- Künftig soll behandelt werden, wie sich Stream-Processing-Anwendungen näher an die traditionelle Art der Anwendungsentwicklung heranführen lassen
- Die Demo kann in weniger als 30 Sekunden ausgeführt werden
$ curl https://console.warpstream.com/install.sh | bash
$ warpstream demo
- WarpStream ist eine Produktvorstellung eines Unternehmens, das eine objektspeicherbasierte Alternative auf Apache Kafka verkauft; die Zahlen und Vergleiche im Text sollten in diesem Kontext gelesen werden
1 Kommentare
Meinungen auf Hacker News
Die Aussage „Fast jedes Tech-Unternehmen nutzt Kafka“ scheint mir falsch zu sein.
Zwar haben wir dafür nicht gegenseitig Belege vorgelegt, aber von den sechs Unternehmen, für die ich zuletzt gearbeitet habe, nutzte Kafka keines; bei einem früheren Arbeitgeber hatte ich die Einführung vorangetrieben, später wurde es aber wieder verworfen.
LinkedIn hat Kafka entwickelt, um Probleme in extrem großem Maßstab zu lösen, die 99 % nicht haben. Und auch wenn Techniker den Ruf haben, Technologien einzusetzen, die sie nicht brauchen, glaube ich, dass die meisten es erfolgreich vermeiden, Kafka zu verwenden.
Wenn das alles ist, was man braucht, lässt es sich leicht wie ein einfacher Message Broker ohne Aufbewahrungsfrist verwenden; wenn man ungewöhnliche Dinge braucht, die Persistenz ausnutzen, kann man in diese Richtung gehen.
Wenn man negative Gefühle gegenüber einem Open-Source-Tool hat, das schon in seiner Grundform robust und weit verbreitet ist, liegt das meistens wohl an bestimmten Spezialfunktionen oder Use Cases.
Eher wirkt so eine Formulierung für diesen Anbieter nicht gut. Man kann Kafka über technische Vor- und Nachteile kritisieren oder mit ihm konkurrieren, aber seine Marktposition zu verzerren, ist nicht besonders überzeugend.
Ich bezweifle nicht, dass es gute Use Cases gibt, aber bisher habe ich nur Enthusiasten gesehen, die es in jede Situation hineinzwingen wollten. Das hat einen schlechten Nachgeschmack hinterlassen, und deshalb gehöre ich zur „ablehnenden“ Seite.
Dem Teil mit „Accidental SRE“ stimme ich zu, aber Kafka ist eine solide Technologie, und deshalb gibt es auch jede Menge Tools wie Redpanda, also „Kafka, aber besser als Kafka“.
Am Ende scheint das am Punkt vorbeizugehen. Selbst wenn es nicht weit verbreitet wäre, ist das unabhängig davon, ob es eine polarisierende Technologie ist. Für die Leute, die die erwähnten Skalierungsprobleme des 1 % lösen, kann es weiterhin etwas sein, das man mag oder hasst.
Das ist so ähnlich, als würde man sagen, „Lamborghinis polarisieren“ sei falsch, weil die meisten Menschen keinen Lamborghini besitzen. Der Autor hat den Geltungsbereich außerdem ausdrücklich auf „im Datenbereich“ beschränkt.
Ich habe ein paar Fragen.
Daher sind die S3-PUT-Kosten nicht proportional zur Anzahl der Topic-Partitionen, sondern zur Zahl der laufenden Agents und zum Flush-Intervall. Produce-Requests werden erst bestätigt, wenn die Daten dauerhaft in S3 und in der Cloud-Control-Plane gespeichert sind.
Ich finde nicht, dass man zwischen Zuverlässigkeit und Kosten wählen müssen sollte. WarpStream bietet Zuverlässigkeit und Verfügbarkeit auf dem Niveau eines Betriebs über drei Availability Zones hinweg zu den Kosten einer einzelnen Availability Zone.
Die Reihenfolge wird von einer Custom-Metadaten-Datenbank gehandhabt, die in der Cloud-Control-Plane läuft.
An dem Ansatz, in jeder Availability Zone einen Kafka-Cluster zu betreiben und nur bis zum späteren Zusammenführen zu replizieren, ist an sich nichts falsch. Wenn aber verteilte Systeme und Availability Zones im Spiel sind, entscheiden sich Engineers – und auch die Business-Anforderungen – meist für eine Multi-Availability-Zone-Konfiguration. Bei Regionen ist es genauso.
Deshalb sind die meisten Kafka-Cluster Multi-AZ, obwohl das in vielen Fällen eigentlich nicht nötig wäre, und die entsprechende Rechnung wird dann Kafka angelastet.
Das Kafka-Protokoll bewahrt die Reihenfolge der Operationen innerhalb einer Kafka-Partition tatsächlich nicht. Es bewahrt die Reihenfolge der Operationen innerhalb eines Producer-Partition-Paars, und selbst das nur bei bestimmter Konfiguration.
Die Standardimplementierung bewahrt die Reihenfolge, in der der Broker die Nachrichten vom Producer erhält; aus Sicht eines externen Systems bedeutet das eher, dass bei korrekter Konfiguration die Nachrichten für einen bestimmten Key und einen bestimmten Producer in Empfangsreihenfolge erhalten bleiben.
Übernimmt der Cloud Metadata Store im Grunde die Rolle, Offsets zuzuteilen?
Ich bin Ryan Worl, Mitgründer und CTO von WarpStream. Wir freuen uns sehr, eine Developer Preview eines Kafka-Protokoll-kompatiblen Streaming-Systems anzukündigen, das direkt auf S3 aufsetzt.
Es gibt keine zustandsbehafteten Disks/Nodes, die betrieben werden müssen, kein Daten-Rebalancing, kein ZooKeeper und keine Bandbreitenkosten zwischen Availability Zones, wodurch es 5- bis 10-mal günstiger ist.
Wenn es Fragen zu WarpStream gibt, beantworte ich sie gern zusammen mit meinem Mitgründer richieartoul.
Einer der Gründe, warum ich es nicht gebaut habe, war das Paradox: Wenn Skalierung keine Rolle spielt, wollen Nutzer dann wirklich eine Mini-Version von Kafka, statt einfach direkt SQLite zu verwenden?
Aber es kann gut sein, dass Leute die Semantik des Kafka-Protokolls mögen oder bereits Kafka einsetzen und dann feststellen, dass sie doch nicht in der Größenordnung unterwegs sind, für die sie die Komplexität in Kauf nehmen müssten. Viel Erfolg.
Wenn ihr Cloudflare R2 unterstützt, wäre das auch gut für Multi-Cloud.
Bietet ihr auch Ordnungs-Garantien, wie Kafka sie auf Partitionsebene bereitstellt?
Wenn „5- bis 10-mal günstiger“ vor allem durch eingesparte Kosten zwischen Availability Zones entsteht: Bietet AWS MSK das nicht auch?
Eines ist sicher: Kafka „nach Lehrbuch“ auf einzelnen VMs bei einem Cloud-Anbieter zu betreiben, ist absurd teuer.
Ich erinnere mich an sehr einfache Gespräche mit mehreren Kunden über Kafka und Hadoop: Wenn Disks bereits als vollständig redundantes System bereitgestellt werden, warum repliziert man Daten dann noch einmal auf VM-/Disk-Ebene?
In diesem Fall ging es um Azure Storage, das lokal redundanten, zonenredundanten und georedundanten Storage bietet; ein erheblicher Teil davon konnte für Managed Disks genutzt werden.
Deshalb nutzen gut designte cloudverwaltete Hadoop-/Kafka-Services Storage-Adapter, um die eingebaute Redundanz des Anbieters auszunutzen. Aus demselben Grund gibt es bei einigen Cloud-Anbietern Kafka-kompatible Event-Broker.
Der Rest von WarpStream wirkt eher wie das Sahnehäubchen, aber mich interessiert, wie die interne Architektur aussieht und wie ihr Kosten zwischen Availability Zones vermeidet.
Nebenbei: Ich arbeite bei Microsoft, habe aber vor meinem Einstieg vor fast zehn Jahren Hadoop-/Spark-/Kafka-Cluster aufgebaut.
Einige Raft-Implementierungen erlauben Nodes mit Stimmrecht, die aber kein Quorum-Leader werden können. Eine Niederlassung, deren gesamter Traffic beispielsweise durch einen asymmetrischen VPN-Tunnel läuft, sollte nicht zum Leader gewählt werden, weiß aber, welche Kandidaten sie sehen kann.
Dadurch lagen die Grundkosten für den Clusterbetrieb eher bei 2,2-facher Hardware statt beim Dreifachen, was bei kleinen Lösungen oder Entwickler-Sandboxes einen großen Unterschied machte. Wenn drei Shards für die Last knapp zu wenig sind, fünf aber zu viel, oder auch beim Unterschied zwischen sechs und sieben, ist das relevant.
Das Problem ist, dass geografische Replikation die zwei Probleme nicht löst, die den Kern des Beitrags ausmachen: Aus Sicht der Cloud-Ökonomie erzeugt Kafkas Replikationsstrategie per Design massive Bandbreitenkosten zwischen Availability Zones, und aus Betriebssicht erfordert der Betrieb eines eigenen Kafka-Clusters praktisch ein dediziertes Team und ausgefeilte Custom-Tools.
Trotzdem muss man diese Fähigkeit in der Cloud zurückbekommen. Besonders dann, wenn das Pendel wieder in Richtung Self-Hosting ausschlägt, wie es auch früher immer wieder passiert ist.
EBS-ähnliche Lösungen bringen entsprechende Kosten mit sich. Besonders wenn man viele IOPS braucht, wird es sehr teuer. Man spart zwar möglicherweise Traffic-Kosten zwischen Availability Zones, zahlt dafür aber absurd viel für Storage.
Wenn man die Replikation selbst übernimmt, kann man deutlich günstigeren Attached Storage verwenden.
An richieartoul: Der Blogpost ist etwas stark gewürzt.
Kafka erfordert nicht grundsätzlich ein dediziertes Expertenteam und Millionen von Dollar, bevor man sehr große Cluster betreibt.
Ich stimme aber völlig zu, dass ein Cluster über drei Availability Zones hinweg durch Transferkosten zwischen den Zonen Geld verschlingt. Genau so verkauft AWS auch MSK. Der Transfer zwischen Availability Zones sei „kostenlos“, heißt es, ist aber tatsächlich bereits im Preis enthalten.
Sieht interessant aus, aber nach der Lektüre von „Accidental SRE“ habe ich zwei Fragen.
Bare Metal gibt es schon lange, aber die eigene Verwaltung von Bare Metal scheint nicht wirklich viel einfacher geworden zu sein. Wenn sie wirklich einfach wäre, würden Endnutzer solche Dinge häufiger selbst betreiben.
Wie wird dieser Service also betrieben? Bei einem Cloud-Anbieter oder auf Bare Metal?
Ihr beide habt viel Erfahrung mit FoundationDB, das üblicherweise selbst betrieben wird. Habt ihr deshalb auch für den Metadaten-Store wieder FoundationDB gewählt? Falls ja oder falls nein, würde mich die Begründung interessieren.
Dadurch bleiben alle Kundendaten im Cloud-Account und im S3-Bucket des Kunden, sodass wir sie weder sehen noch anfassen können. Kunden müssen den WarpStream Agent zwar selbst ausführen, aber es ist nur ein zustandsloser Container, der leicht zu betreiben ist.
Wir haben FoundationDB als Metadaten-Store geprüft, uns am Ende aber dagegen entschieden. Um den Free Tier kosteneffizient zu machen, mussten wir den Metadaten-Store für diesen speziellen Use Case so effizient wie möglich gestalten, und dafür brauchten wir etwas stärker Maßgeschneidertes.
Trotzdem ist FoundationDB eine großartige Technologie. Unter den vielen verteilten Datenbanken, die ich genutzt habe, ist sie die beste.
Die Aussage „Wie viele Partitionen soll man verwenden? Unklar, aber wenn man sich einmal festgelegt hat, kann man es nie wieder ändern, also muss man richtig wählen“ ist schlicht falsch. Die Anzahl der Partitionen lässt sich ändern.
Und auch die wiederholt vorgebrachte Behauptung „Für den Betrieb von Kafka braucht man ein ganzes Engineering-Team“ kann ich nicht so recht nachvollziehen. Nach meiner Erfahrung stimmt das nicht. Die Betriebskosten sind zwar hoch, aber in unserem Team braucht es dafür nicht viel Engineering-Zeit.
Sehr interessant. Ich habe etwas Ähnliches entworfen und wollte es in Zig implementieren: https://github.com/fremantle-industries/transit
Ein großer Teil der Stärke von Kafka kommt aus der API, und ich bin zu einem ähnlichen Schluss gekommen: Die Komplexität des Cluster-Managements wird letztlich durch verschiedene Implementierungen abstrahiert werden.
Wenn man Kafka-Persistenz auf dem S3-Key-Space implementieren kann, könnte man wie WarpStream damit beginnen, direkt nach S3 zu persistieren, und später schnellere Hot-Disk- und Memory-Tiering-Mechanismen daraufsetzen, um die End-to-End-Latenz zu senken.
Mir gefällt die Richtung. Wenn ihr tiefer darüber sprechen wollt, könnt ihr mich gern auf Twitter kontaktieren: https://twitter.com/rupurt
In einem früheren Job habe ich vermutlich etwas gebaut, das diesem Produkt sehr ähnlich war. Wir hatten Machine-Learning-Traffic im zweistelligen TB-Bereich pro Tag und brauchten keine Echtzeitlatenz; nachdem wir alles nach S3 verlagert hatten, sanken die Kosten um etwa 90 %.
Es war auf der JVM gebaut, und zur Pflege der Metadaten nutzten wir weiterhin einen Kafka-Cluster mit 6 Brokern. Als ursprünglich alles in Kafka lag, waren es vermutlich 300 Broker.
Das Compute-/Storage-Modell von Kafka skaliert für extreme Use Cases, bei denen man Latenz in Kauf nehmen kann, nicht gut; das Modell von Apache Pulsar passte dafür eher. Allerdings war Pulsar damals nicht stabil genug für den Produktionseinsatz.
Einer der Schlüssel zur Kosteneffizienz war, dass die Datenmenge groß genug war, sodass man nicht lange warten musste, bis wirtschaftliche Dateigrößen erreicht waren. Ich kann mir schwer vorstellen, dass eine Pipeline mit weniger als 10 MB/s auf diese Weise effizient funktioniert.
War das Pinterests memq, oder war es etwas anderes?
Der Titel des Artikels hätte „Kafka is dead. Long live WarpStream.“ lauten sollen. Der „long live“-Teil bezieht sich auf den Nachfolger.
https://en.wikipedia.org/wiki/The_king_is_dead,_long_live_th...!