Data Streaming in AWS: Zu viele Optionen

Amazons Aushängeschild für Data Streaming – und der Service, den Sie für die meisten Use Cases als Standardwahl in Betracht ziehen sollten – ist Kinesis. Innerhalb von Kinesis gibt es allerdings mehrere Sub-Services mit teils kryptischen Namen. Die wichtigsten sind:

• Kinesis Data Streams (oft kurz Streams genannt)
• Kinesis Firehose (oder einfach Firehose) und
• Kinesis Data Analytics (oder einfach Analytics)

Schauen wir uns die drei im Detail an.

Streams vs. Firehose: Funktionsüberblick

Sowohl Data Streams als auch Firehose nehmen Daten auf und schreiben sie in ein Ziel. Warum gibt es dann zwei Services, die scheinbar dasselbe leisten?

Der Hauptunterschied: Streams ist dafür gedacht, Daten an Compute-Services mit eigenen Consumern zu schicken – etwa Anwendungen auf EC2, EMR oder Lambda –, die die Daten nahezu in Echtzeit transformieren und verarbeiten, mit Verzögerungen von gerade einmal ~70 ms. Damit eignet sich Streams besonders für Echtzeit-Dashboards, Anomalieerkennung und ähnliche zeitkritische Anwendungen. Streams lässt sich gut mit Apache Spark integrieren und vereinfacht die Echtzeit-Datenverarbeitung über Streaming Data Frames, wenn komplexere Analysen ins Spiel kommen.

Firehose ist dagegen nicht für Near-Real-Time-Delivery gemacht. Stattdessen werden eingehende Nachrichten gebündelt, optional komprimiert und/oder per AWS Lambda transformiert und anschließend in ein Ziel geschrieben – meist einen AWS-Service. Typischerweise sind das S3, Redshift oder Elasticsearch.

Stream-Nachrichten werden in der Regel von eigenen Anwendungen konsumiert, Sie können Streams aber auch so konfigurieren, dass die Daten in einen Firehose-Stream fließen. So bekommen Sie sowohl Echtzeit-Analysen als auch Batching und Langzeitspeicherung der Daten.

Wenn Ihr Use Case keine Near-Real-Time-Verarbeitung verlangt, ist Firehose meist die bessere Wahl – und auch deutlich einfacher in der Handhabung.

Firehose: Meist die bessere Wahl

Warum ist Firehose unter diesen beiden Services in der Regel die bessere Wahl?

Erstens: Kinesis Streams erfordert mehr Entwicklungsaufwand, da man mit der Java-lastigen Kinesis Producer Library (KPL) und Kinesis Consumer Library (KCL) arbeiten muss. Firehose ist hingegen primär darauf ausgelegt, Daten direkt in bestimmte AWS-Services zu schreiben – auf der Sink-Seite ist also kein Coding nötig. Auch das Veröffentlichen von Nachrichten an Firehose ist denkbar einfach:

import boto3firehose_client = boto3.client('firehose')
response = firehose_client.put_record(
    DeliveryStreamName='string',
    Record={'Data': b'bytes'} # base64-encoded
)

Wenn Sie damit leben können, dass Kinesis Streams sowohl auf Producer- als auch auf Consumer-Seite Performance-Einbußen haben kann und Sie auf weitere Vorteile verzichten, können Sie statt aufwendiger KPL-Entwicklung einfach die AWS-SDKs nutzen, um Nachrichten zu veröffentlichen:

import boto3kinesis_client = boto3.client('kinesis')
response = kinesis_client.put_record(
    StreamName='string',
    Data=b'bytes', # base64-encoded
    PartitionKey='string'
)

Zweitens: Streams und Firehose sind beide vollständig verwaltet und skalieren automatisch – allerdings skaliert Streams "weniger" automatisch und ist auch nicht ganz serverlos.

Mit dem Auto-Scaling von Firehose lässt sich der Durchsatz nahtlos und ohne Verzögerung von Entwicklungstests bis hin zu mehreren GB/s hochfahren – vorausgesetzt, Sie stoßen nicht an die AWS-Limits für den Firehose-Durchsatz.

Bei Streams ist das Skalieren komplizierter. Sie verwalten zwar nicht direkt die zugrunde liegende Infrastruktur, müssen aber pro Kinesis Stream eine Anzahl an "Shards" definieren, die den unterstützten Durchsatz festlegt. Ein Shard entspricht maximal 1 MB/s oder 1.000 Datensätzen/s an Schreib-Durchsatz und 2 MB/s an Lese-Durchsatz. Eine bestimmte Anzahl an Shards muss also vorab provisioniert werden, um einen bestimmten Durchsatz zu unterstützen. Sie können die Shard-Anzahl manuell anpassen oder Auto-Scaling einrichten – Letzteres ist allerdings umständlicher als nötig.

Für mehr Durchsatz erhöhen Sie also die Shard-Anzahl. Es gibt aber einen großen Haken: Das Hinzufügen oder Entfernen eines Shards dauert im Schnitt etwa 30 Sekunden, und es lässt sich immer nur ein Shard auf einmal hinzufügen oder entfernen.

Wie sich das in der Praxis auswirken kann: Bei einem Stream mit 1.000 Shards (~1 GiB/s Schreib-Durchsatz) und der Erwartung, dass sich der Durchsatz bald verdoppelt, dauert es über 8 Stunden, bis Ihr Stream durch 1.000 zusätzliche Shards vollständig hochskaliert ist.

Wenn Sie damit rechnen, dass es eines Tages zu einem plötzlichen, unerwarteten Anstieg des Datenvolumens kommen könnte, wird Kinesis Data Streams nicht schnell genug skalieren.

Streams ist deshalb nicht für Use Cases mit stark schwankendem Streaming-Durchsatz geeignet – es sei denn, Sie nehmen Über-Provisionierung und höhere Kosten in Kauf oder sind sicher, Lastspitzen vorhersehen und entsprechend planen zu können. Firehose ist schlicht einfacher zu skalieren, einfacher zu entwickeln und – wie wir gleich sehen – einfacher zu kalkulieren. Kinesis Streams sollten Sie nur dann einsetzen, wenn Echtzeit-Analysen wirklich nötig sind.

Streams vs. Firehose: Vergleich der Preisstrukturen

Der serverlose, automatisch skalierende Ansatz von Firehose bringt auch ein übersichtliches Pay-as-you-go-Preismodell mit, das auf Folgendem basiert:

• aufgenommene GB an Daten pro Monat sowie für entsprechende Use Cases:
• GB an durchgeführten Datenformat-Konvertierungen
• GB an Daten, die an eine VPC ausgeliefert werden

Die Preisgestaltung von Data Streams ist deutlich schwerer zu prognostizieren, denn sie basiert auf:

• der Anzahl der provisionierten Shard-Stunden, die durch Auto-Scaling variieren kann. Für eine zuverlässige Verfügbarkeit werden Sie wahrscheinlich überprovisionieren müssen.
• der Anzahl der versendeten 25-KB-PUT-Payloads
• optionalen Änderungen bei der Langzeit-Datenaufbewahrung
• der optionalen Aktivierung von Enhanced Fan-out – einem Feature, das den Durchsatz verbessert, wenn viele Consumer aus demselben Shard lesen

Streams vs. Firehose: Zusammenfassung

Wenn Sie einfache Datentransformationen durchführen und Streaming-Daten im Batch in einen Datenspeicher laden möchten und keine Echtzeit-Anforderung haben, schicken Sie Ihre Daten direkt an Firehose. Firehose ist auch dann die richtige Wahl, wenn Sie den Aufwand für die Anwendungsentwicklung minimieren oder sich nicht um schnelle Infrastruktur-Skalierung kümmern wollen.

Wenn Sie Daten in Echtzeit verarbeiten müssen, schicken Sie sie durch Streams – aber rechnen Sie damit, dass selbst mit aktiviertem Auto-Scaling Lastspitzen nicht immer schnell genug abgefangen werden.

Wenn Sie Daten sowohl in Echtzeit verarbeiten als auch später für Analysen speichern möchten, schicken Sie sie zunächst an Streams und konfigurieren dann in der Kinesis-Webkonsole bequem die Weiterleitung an Firehose – ganz ohne Code (es sei denn, Sie wollen optionale Transformationsschritte über Lambda nutzen).

Es kann helfen, sich Streams funktional ähnlich wie Apache Kafka vorzustellen – aber mit temporärer persistenter Speicherung von Nachrichten, die an viele Consumer weitergeleitet werden können. Consumer können eigene Anwendungen sein (EC2 oder EMR) oder von AWS verwaltet werden (Firehose). Firehose wird häufig als Batch-Loader für bestimmte Services genutzt, meist AWS-zentriert (S3, Redshift, Elasticsearch), mit optionalen, durch Lambda betriebenen serverlosen Datentransformationen.

Streams und Firehose decken die Aufnahme, Transformation und Weiterleitung von Streaming-Daten an Echtzeit-Analyseanwendungen (Streams) und Langzeit-Speicher (Firehose) gut ab. Welche Rolle übernimmt dann Analytics?

Data Analytics, Amazons vollständig verwaltetes und serverloses Apache-Flink-Angebot:

• integriert sich mit Data Streams oder Firehose
• führt SQL-Abfragen auf diesen Streaming-Daten aus und
• streamt die Ergebnisse an einen AWS-Service – etwa einen weiteren Data Stream, einen Firehose-Stream oder Lambda
• Data Analytics kann zudem statische CSV- oder JSON-Dateien in S3 als SQL-Tabellen behandeln und so JOINs von Referenzdaten mit Streaming-Daten ermöglichen.

Data Analytics dient in erster Linie dazu, kontinuierlich Aggregationen von Streaming-Daten – angereichert mit statischen Referenzdaten – über Zeitfenster zu berechnen, meist für Echtzeit-Alerting, ohne Code oder bereitgestellte Infrastruktur und einfach per SQL. Sie könnten stattdessen auch Flink-Code schreiben und deployen, aber zur einfacheren Wartung würde ich bei SQL bleiben, da Scala & Java in der Data-Science-Welt seltener genutzt werden.

Die AWS-Doku zeigt ein Beispiel für Sliding-Window-Analytik mit Aktienticker-Daten. Ich empfehle stattdessen dieses spannendere Praxisbeispiel: Verkehrsgeschwindigkeiten aus ganz Belgien werden in einen Firehose-Stream eingespeist, Data Analytics vergleicht aktuelle mit vergangenen Verkehrsgeschwindigkeiten unter Zuhilfenahme von Referenzdaten in S3, Staus werden per SQL erkannt und Echtzeit-Alerts über Lambda ausgelöst.

Sowohl Kinesis Data Streams als auch MSK – das von AWS verwaltete Angebot für Apache Kafka – sind effektive Pub-Sub-Systeme, die das Publizieren und Konsumieren von Nachrichten mit hohem Durchsatz, niedriger Latenz, hoher Verfügbarkeit und Fehlertoleranz ermöglichen. In Sachen Skalierbarkeit und Zuverlässigkeit als Plattform für Datenaufnahme und -auslieferung gibt es zwischen den beiden auf den ersten Blick keine großen Unterschiede.

Im Detail finden sich aber entscheidende Unterschiede – und die fallen meist zugunsten von Kinesis aus:

• Sie können nur die Anzahl der Message Broker erhöhen. Ein MSK-Deployment lässt sich also nicht herunterskalieren.
• MSK ist zwar vollständig verwaltet, aber kein serverloses Kafka. Eine gewisse Cluster-Konfiguration ist daher unverzichtbar. Sie müssen Zonen und Subnetze definieren, in denen Ihre Broker gestartet werden, die Anzahl der Broker pro Zone, den Instance-Typ Ihrer Broker und so weiter.
• Da MSK nicht serverlos ist, zahlen Sie auch für den EBS-Speicher, der die Instances stützt. Auch dieser lässt sich nicht herunterskalieren.
• Den Instance-Typ können Sie nach dem initialen Cluster-Setup nicht mehr ändern. Die einzige Option zum Hochskalieren ist, die Anzahl der Instances zu erhöhen.
• Kinesis ist der hauseigene, vollständig verwaltete und serverlose Streaming-Service von AWS und integriert sich daher naturgemäß besser mit AWS-Services. Manche Kinesis-Consumer lassen sich ganz ohne Code anbinden, während bei MSK alle Consumer-Anwendungen individuell entwickelt werden müssen – etwa auf EC2, EKS, EMR oder mit Flink-Code, der auf Kinesis Data Analytics deployt wird.
• In Kafka kann pro Partition immer nur ein Consumer aus einer bestimmten Consumer-Group lesen. Kinesis unterstützt dagegen mehrere Consumer pro Shard.

Initiale und laufende Cluster-Konfiguration kombiniert mit der Unmöglichkeit, Deployments herunterzuskalieren, bedeuten kurz- wie langfristig mehr DevOps-Overhead bei MSK im Vergleich zu Kinesis.

Auch beim Pricing unterscheiden sich die beiden – und auch hier hat Kinesis meist die Nase vorn.

Wie bereits erwähnt, basiert das Pricing von Kinesis Data Streams weitgehend auf On-Demand-Nutzung. Es richtet sich vor allem nach der Anzahl der versendeten 25-KB-PUT-Payloads und der Anzahl der provisionierten Shard-Stunden, die für Ihren gewünschten PUT- und GET-Durchsatz nötig sind. Shard-Anzahlen lassen sich auch per Auto-Scaling konfigurieren, was On-Demand-Pricing simuliert – auch wenn die Implementierung etwas holprig ist.

MSK dagegen wird danach bepreist, wie viele Instances welcher Größe Sie ausgewählt haben und welche EBS-Volumes diese stützen. Weder Instance-Anzahl noch EBS-Volume-Größe lassen sich verkleinern; wer überprovisioniert, bleibt auf den Kosten sitzen, sofern er den Cluster nicht beendet. Speicher kann auf Auto-Scaling gesetzt werden, Instance-Größen und -Anzahlen jedoch nicht. Sie müssen daher kontinuierlich Instance-CloudWatch-Metriken im Auge behalten, beobachten, wie viele Partitionen pro Broker genutzt werden, und weitere Performance-Indikatoren überwachen, um den Service manuell zu skalieren. Hinzu kommt: Es wird dringend empfohlen, dass die CPU-Auslastung im Cluster unter 60 % bleibt – Sie zahlen also zwangsläufig zu viel für Compute-Kapazität.

Es gibt einen großen Vorteil von MSK: Kinesis bietet At-least-once-Delivery, während Kafka Exactly-once-Delivery garantiert. Allerdings ist die Deduplizierung von Nachrichten in der Regel deutlich einfacher zu handhaben als die Herausforderungen rund um eine kosteneffiziente Infrastruktur-Skalierung.

Selbst wenn Sie es schaffen, einen MSK-Cluster bei sehr hohem Durchsatz erfolgreich und kostenoptimiert zu betreiben und das Deployment günstiger zu kalkulieren als Kinesis – ich würde wetten, dass Sie mit Kinesis trotzdem mehr sparen. Grund sind die deutlich geringeren DevOps-Stunden (und damit hohen Gehaltskosten) für den Betrieb eines geschäftskritischen Pub-Sub-Service, wenn ein vollständig verwaltetes Pendant praktisch ohne Aufwand denselben Job erledigt.

Persönlich empfehle ich AWS MSK nur Unternehmen, die eine bestehende Kafka-basierte Anwendung haben, die aufgrund von Zeit-, Refactoring-Kosten- oder Personalengpässen ohne architektonische Änderungen per Lift-and-Shift migriert werden muss.

Wer mehr erfahren möchte, dem empfehle ich diesen ehrlichen AWS-MSK-Review. Auch die Kommentare zum Artikel sind aufschlussreich und drehen sich um MSK-vs.-Kinesis-Preisbeispiele.

AWS EMR ist Amazons vollständig verwaltetes und automatisch skalierendes (aber nicht serverloses) Angebot für die clusterbasierte Ausführung von Skripten, die für Open-Source-Big-Data-Tools geschrieben wurden. Zu diesen Tools zählt unter anderem Apache Spark.

Spark ermöglicht DataFrame-basierte Analysen, die sich sowohl auf statischen als auch auf Streaming-Datensätzen ausführen lassen. Sie können DataFrames mit den üblichen programmatischen Funktionsaufrufen analysieren oder ANSI-SQL-konformes Spark SQL einsetzen. Die Arbeit mit Spark SQL auf Streaming-Daten ähnelt dem Einsatz von SQL mit Apache Flink / Kinesis Data Analytics. Spark kann Apache Kafka und Apache Flume sowie AWS S3 und AWS Kinesis Data Streams als überwachte Streaming-Quelle nutzen.

Wegen der hervorragenden eingebauten Integrationen von Spark mit Streams und S3 sowie der niedrigen Lernkurve mit PySpark empfehle ich Spark Streaming mit DataFrames auf EMR, wenn Sie:

• Echtzeit-Analysen auf Kinesis Data Streams oder S3 durchführen müssen und
• der Umfang oder die Komplexität der Analysen einige der zahlreichen Einschränkungen von Kinesis Data Analytics sprengt.

Besonders wichtig: Bei Data Analytics gilt es, Folgendes zu beachten:

• Keine Datenzeile darf größer als 512 KB sein. Sparks Limit liegt deutlich höher: 2 GB.
• Ihr Referenzdatensatz darf 1 GB nicht überschreiten. Spark hat hier kein Limit.
• Jede Anwendung darf genau eine Streaming-Quelle und maximal eine Referenzdatenquelle haben. Mit Spark können Sie mehrere Streaming-Quellen und mehrere statische Referenzdatenquellen miteinander joinen.
• Window-Abfragen sollten 60 Minuten nicht überschreiten, da Daten in flüchtigem Speicher liegen, aus dem der Stream bei unerwarteten Anwendungsunterbrechungen neu aufgebaut werden kann. Spark hat hier kein Zeitfenster-Limit.

Glue Streaming ist ein vollständig verwaltetes, automatisch skalierendes und serverloses Spark-Streaming-DataFrames-Angebot. Es eignet sich, wenn Sie Spark-Erfahrung haben und individuelle Transformationen sowie Analysen auf Daten durchführen wollen, die aus Kinesis streamen – und zwar lieber mit diesem Service als mit einem selbstverwalteten EMR-Cluster oder Lambda-Funktionen. Glue Streaming kann in die üblichen Ziele wie S3, Redshift und DynamoDB schreiben.

Glue kann anhand einer Liste von Transformationen, die Sie in der Webkonsole anfordern, bis zu einem gewissen Grad automatisch Spark-Code für Sie generieren. Tiefgehende Spark-Erfahrung ist daher nicht zwingend nötig, auch wenn Grundkenntnisse hilfreich sind.

Persönlich finde ich diesen Service etwas eigenwillig. Serverloses Spark klingt zwar praktisch, bringt aber einige Einschränkungen mit:

• Bei Schema-Erkennung sind keine Joins von Streaming-Daten möglich.
• Sie können die Anzahl der Kinesis-Streams-Shards nicht ändern, während ein Glue-Streaming-ETL-Job läuft. Sie müssen den Job stoppen, die Shard-Anzahl der Data Streams ändern, warten, bis der Vorgang abgeschlossen ist, und den Job dann neu starten.

Allein wegen der Upstream-Skalierbarkeit würde ich persönlich einen selbstverwalteten Spark-Cluster mit aktiviertem Auto-Scaling Glue Streaming ETL vorziehen. In Ihren Tests stellen Sie aber vielleicht fest, dass die Auto-Scaling- und serverlose Natur von Glue Streaming ETL die Nachteile überwiegt.

Was die IoT-Analytics-Komponenten genau leisten, ist nicht so transparent, wie es sein sollte – deshalb habe ich einen ganzen Artikel darüber geschrieben! Production-Scale IoT Best Practices: Implementation with AWS (Part 2). Hier behandeln wir die Grundlagen und überlassen viele Details dem Artikel.

IoT-Geräte, die in AWS streamen, treffen zuerst auf den IoT Core. Von dort lassen sich die Nachrichten an andere Services für individuelle Analysen weiterleiten. Mit IoT Rules können Sie IoT-Core-Daten zum Beispiel einfach weiterleiten an:

• DynamoDB
• Firehose, das die Daten dann in DynamoDB, S3, Redshift oder Elasticsearch ablegt
• Data Streams, das Daten an EC2, EMR, Lambda oder Firehose senden kann

Wie Sie sehen, gibt es eine Vielzahl möglicher IoT-Datenflüsse, die Sie aufsetzen können.

Wenn Sie aber alle Ihre IoT-Daten – vom Streaming in Ihre Plattform bis hin zu Speicherung und Analyse – komplett innerhalb einer einheitlichen, IoT-zentrierten Plattform verarbeiten möchten, die vollständig serverlos, automatisch skalierend und vollständig verwaltet ist und mehrere analyserelevante Integrationen mit anderen AWS-Services wie SageMaker und QuickSight bietet, dann ist IoT Analytics die richtige Wahl. Mit dem IoT Core verarbeiten Sie IoT-Daten innerhalb eines einzigen Service, statt mehrere Services zusammenzustückeln.

Beim Durchklicken des IoT-Analytics-Wizards wird Folgendes eingerichtet:

• Ein IoT Channel, in dem die IoT-Daten ankommen
• Eine IoT Pipeline, die Channel-Daten übernimmt und es Ihnen erlaubt, Nachrichten optional anhand ihrer Attribute anzureichern, zu transformieren und zu filtern
• Ein IoT Data Store, in dem Streaming-Daten gespeichert werden – entweder unbegrenzt oder für einen festgelegten Zeitraum. Im Hintergrund landen diese Daten in einem von AWS verwalteten S3-Bucket.
• Ein IoT Data Set lässt sich aus einem Data Store erstellen. Es ist eine Teilmenge eines IoT Data Store, wird mit IoT SQL erstellt, hat einen eigenen Aufbewahrungszeitraum und kann sich auf Abruf oder nach Zeitplan neu erzeugen. Wie Data Stores werden auch Data Sets als CSV-Dateien in einem verwalteten Bucket abgelegt. Mit Data Sets können Sie also einen statischen Datensatz auf Basis eines individuellen Filters erstellen (etwa alle Temperaturdaten aus einem engen, aber interessanten Zeitraum), diesen einmalig auf Abruf generieren und den gefilterten Datensatz unbegrenzt für nachgelagerte Analysen aufbewahren – während die ursprünglichen Rohdaten im Data Store gemäß einer Aufbewahrungsfrist ablaufen, die Ihre Organisation als optimalen Kompromiss zwischen Rohdaten-Aufbewahrung und Wirtschaftlichkeit festlegt.
• Einige AWS-Services, die mit IoT Analytics integriert sind – etwa QuickSight – greifen ausschließlich auf Data Sets zu, während andere Services wie SageMaker sowohl auf Data Stores als auch auf Data Sets zugreifen können. Generell sollten alle Services auf Data Sets zugreifen können. Wegen der eingeschränkteren Anbindung an Data Stores und der Kostenfolgen einer dauerhaften Speicherung von Rohdaten in IoT Analytics sollten Sie sich in produktiven Use Cases angewöhnen, gezielt diskrete, gefilterte Data Sets für Analysen oder das Training von ML-Modellen anzulegen, während die Rohdaten im Data Store nach und nach ablaufen – es sei denn, Ihre Organisation akzeptiert die Kosten einer vollständigen Historienspeicherung der IoT-Daten.

Beim Versuch, die verschiedenen AWS-Streaming-Optionen kompakt zu erklären, habe ich womöglich zu viel geschrieben! Hier deshalb eine kurze Zusammenfassung, wann welcher Service die richtige Wahl ist:

• Kinesis Data Streams: Wenn Sie Echtzeit-Analysen auf EC2, EMR oder Lambda durchführen müssen und mit etwas zusätzlicher Entwicklungs-Komplexität sowie der Tatsache leben können, dass sich der Durchsatz nicht schnell skalieren lässt.
• Kinesis Firehose: Wenn Sie Streaming-Daten batchen, optional transformieren und/oder komprimieren und in Langzeitspeicher auf S3, Redshift oder Elasticsearch ablegen möchten. Wenn Sie eine einfach nutzbare, serverlose und sofort automatisch skalierende Plattform für die Aufnahme von Streaming-Daten wollen und damit leben können, dass Daten gebatcht geschrieben statt in Echtzeit an Consumer gesendet werden.
• Kinesis Data Analytics: Wenn Sie einfache Window-Analysen auf Data-Streams- oder Firehose-Daten durchführen wollen, typischerweise für Echtzeit-Alerting, mit SQL auf einer einfachen, serverlosen, automatisch skalierenden Plattform.
• Managed Streaming for Apache Kafka (MSK): Wenn Sie eine bestehende Kafka-basierte Anwendung haben und diese per Lift-and-Shift in AWS bringen möchten. Zeit- oder Ressourcenbeschränkungen verhindern eine Neugestaltung der Anwendung für Kinesis.
• Spark Streaming mit EMR: Wenn Sie fortgeschrittene Window-Analysen auf Kinesis Data Streams über JOIN-Operationen durchführen müssen, die mehrere Streaming-Quellen und/oder statische Referenzdatensätze einbeziehen.
• Glue Streaming ETL: Ähnlich wie Spark Streaming mit EMR, nur dass Sie Spark-workloads in einer serverlosen, automatisch skalierenden Umgebung ausführen können. Erlaubt kein Upstream-Shard-Scaling von Data Streams, ohne verbundene Glue-Streaming-Jobs zu stoppen und neu zu starten.
• IoT Analytics innerhalb des IoT Core: Eine All-in-One-Plattform für Aufnahme, Speicherung und Analyse von IoT-Streaming-Daten – vollständig verwaltet, serverlos und automatisch skalierend. Mit dem IoT Core müssen Sie nicht mehrere AWS-Services zusammenstückeln, um dieselbe Funktionalität zu erreichen.

Vielen Dank fürs Lesen! Bleiben Sie mit uns in Kontakt – im DoiT Engineering Blog , auf dem DoiT LinkedIn-Kanal und auf dem DoiT Twitter-Kanal . Karrieremöglichkeiten finden Sie unter https://careers.doit-intl.com .