Zephyrnet-Logo

Generative Datenintelligenz

Big Data

Amazon Managed Service für Apache Flink unterstützt jetzt Apache Flink Version 1.18 | Amazon Web Services

Neuauflage von Plato
Neuauflage von Plato

Datum:

Views: 65

Apache Flink ist eine verteilte Open-Source-Verarbeitungs-Engine, die leistungsstarke Programmierschnittstellen für Stream- und Batch-Verarbeitung mit erstklassiger Unterstützung für Stateful-Verarbeitung und Ereigniszeitsemantik bietet. Apache Flink unterstützt mehrere Programmiersprachen, Java, Python, Scala, SQL und mehrere APIs mit unterschiedlichem Abstraktionsniveau, die austauschbar in derselben Anwendung verwendet werden können.

Amazon Managed Service für Apache Flink, das eine vollständig verwaltete, serverlose Erfahrung beim Ausführen von Apache Flink-Anwendungen bietet, wird jetzt unterstützt Apache Flink 1.18.1, die zum Zeitpunkt des Schreibens neueste Version von Apache Flink.

In diesem Beitrag besprechen wir einige der interessanten neuen Funktionen und Fähigkeiten von Apache Flink, die mit den neuesten Hauptversionen 1.16, 1.17 und 1.18 eingeführt wurden und jetzt im Managed Service für Apache Flink unterstützt werden.

Neue Anschlüsse

Bevor wir uns mit den neuen Funktionen von Apache Flink befassen, die mit Version 1.18.1 verfügbar sind, wollen wir uns mit den neuen Funktionen befassen, die sich aus der Verfügbarkeit vieler neuer Open-Source-Konnektoren ergeben.

Öffnet die Suche

Ein dedizierter Öffnet die Suche Der Connector kann jetzt in Ihre Projekte integriert werden und ermöglicht es einer Apache Flink-Anwendung, Daten direkt in OpenSearch zu schreiben, ohne auf den Elasticsearch-Kompatibilitätsmodus angewiesen zu sein. Dieser Stecker ist kompatibel mit Amazon OpenSearch-Dienst bereitgestellt und OpenSearch-Dienst ohne Server.

Dieser neue Connector unterstützt SQL- und Tabellen-APIs, arbeitet sowohl mit Java als auch mit Python und dem DataStream-API, nur für Java. Im Auslieferungszustand bietet es mindestens einmalige Garantien und synchronisiert die Schreibvorgänge mit dem Flink-Checkpointing. Mithilfe deterministischer IDs und der Upsert-Methode können Sie eine Exact-Once-Semantik erreichen.

Standardmäßig verwendet der Connector OpenSearch-Clientbibliotheken der Version 1.x. Sie können auf Version 2.x umsteigen Hinzufügen der richtigen Abhängigkeiten.

Amazon DynamoDB

Entwickler von Apache Flink können jetzt einen dedizierten Connector zum Schreiben von Daten verwenden Amazon DynamoDB. Dieser Connector basiert auf dem Apache Flink AsyncSink, entwickelt von AWS und jetzt integraler Bestandteil des Apache Flink-Projekts, um die Implementierung effizienter Sink-Konnektoren mithilfe nicht blockierender Schreibanforderungen und adaptiver Stapelverarbeitung zu vereinfachen.

Auch dieser Connector unterstützt beides SQL und Tabelle APIs, Java und Python und Datenstrom API, nur für Java. Standardmäßig schreibt die Senke stapelweise, um den Durchsatz zu optimieren. Ein bemerkenswertes Merkmal der SQL-Version ist die Unterstützung der PARTITIONED BY-Klausel. Durch die Angabe eines oder mehrerer Schlüssel können Sie eine gewisse clientseitige Deduplizierung erreichen, indem Sie bei jedem Batch-Schreibvorgang nur den neuesten Datensatz pro Schlüssel senden. Ein Äquivalent kann mit der DataStream-API erreicht werden, indem eine Liste von Partitionsschlüsseln zum Überschreiben innerhalb jedes Stapels angegeben wird.

Dieser Anschluss dient nur als Senke. Sie können es nicht zum Lesen aus DynamoDB verwenden. Um Daten in DynamoDB nachzuschlagen, müssen Sie noch eine Suche mithilfe von implementieren Flink Async I/O API oder die Implementierung einer benutzerdefinierten benutzerdefinierten Funktion (UDF) für SQL.

MongoDB

Ein weiterer interessanter Anschluss ist für MongoDB. In diesem Fall stehen sowohl Quelle als auch Senke zur Verfügung SQL und Tabelle APIs und Datenstrom API. Der neue Connector ist nun offiziell Teil des Apache Flink-Projekts und wird von der Community unterstützt. Dieser neue Connector ersetzt den alten, direkt von MongoDB bereitgestellten, der nur ältere Flink Sink- und Source-APIs unterstützt.

Wie bei anderen Datenspeicher-Konnektoren kann die Quelle entweder als begrenzte Quelle, im Batch-Modus oder für Suchvorgänge verwendet werden. Die Senke funktioniert sowohl im Batch-Modus als auch im Streaming und unterstützt sowohl den Upsert- als auch den Append-Modus.

Unter den vielen bemerkenswerten Funktionen dieses Connectors ist die Möglichkeit erwähnenswert, das Caching zu aktivieren, wenn die Quelle für Suchvorgänge verwendet wird. Im Auslieferungszustand unterstützt die Spüle mindestens einmal Garantien. Wenn ein Primärschlüssel definiert ist, kann die Senke eine genau einmalige Semantik über idempotente Upserts unterstützen. Der Sink-Connector unterstützt auch eine genau einmalige Semantik mit idempotenten Upserts, wenn der Primärschlüssel definiert ist.

Neue Connector-Versionierung

Keine neue Funktion, aber ein wichtiger Faktor, der beim Aktualisieren einer älteren Apache Flink-Anwendung berücksichtigt werden muss, ist die neue Connector-Versionierung. Ab Apache Flink Version 1.17 wurden die meisten Konnektoren aus der Hauptdistribution von Apache Flink externalisiert und folgen einer unabhängigen Versionierung.

Um die richtige Abhängigkeit einzuschließen, müssen Sie die Artefaktversion in folgender Form angeben: <connector-version>-<flink-version>

Zum Beispiel der neueste Kafka-Connector, der auch mit funktioniert Amazon Managed Streaming für Apache Kafka (Amazon MSK), zum Zeitpunkt des Schreibens ist Version 3.1.0. Wenn Sie Apache Flink 1.18 verwenden, ist die zu verwendende Abhängigkeit die folgende:

<dependency> 
    <groupId>org.apache.flink</groupId>
    <artifactId>flink-connector-kafka</artifactId> 
    <version>3.1.0-1.18</version>
</dependency>

Aussichten für Amazon Kinesis, die neue Connector-Version ist 4.2.0. Die Abhängigkeit für Apache Flink 1.18 wird wie folgt sein:

<dependency>
    <groupId>org.apache.flink</groupId>
    <artifactId>flink-connector-kinesis</artifactId> 
    <version>4.2.0-1.18</version>
</dependency>

In den folgenden Abschnitten besprechen wir weitere leistungsstarke neue Funktionen, die jetzt in Apache Flink 1.18 verfügbar sind und in Amazon Managed Service für Apache Flink unterstützt werden.

SQL

In Apache Flink SQL können Benutzer Folgendes bereitstellen Hinweise um Abfragen zu verbinden, die verwendet werden können, um dem Optimierer eine Wirkung im Abfrageplan vorzuschlagen. Insbesondere bei Streaming-Anwendungen Lookup-Joins werden verwendet, um eine Tabelle, die Streaming-Daten darstellt, mit Daten anzureichern, die von einem externen System, typischerweise einer Datenbank, abgefragt werden. Seit Version 1.16 wurden mehrere Verbesserungen für Lookup-Joins eingeführt, mit denen Sie das Verhalten des Joins anpassen und die Leistung verbessern können:

  • Lookup-Cache ist eine leistungsstarke Funktion, die es Ihnen ermöglicht, die am häufigsten verwendeten Datensätze im Speicher zwischenzuspeichern und so den Druck auf die Datenbank zu verringern. Bisher war der Suchcache für einige Connectors spezifisch. Seit Apache Flink 1.16 ist diese Option für alle Konnektoren verfügbar, die intern die Suche unterstützen (FLIP-221). Zum jetzigen Zeitpunkt, JDBC, Bienenstock und HBase Connectors unterstützen den Lookup-Cache. Der Lookup-Cache verfügt über drei verfügbare Modi: FULL, für einen kleinen Datensatz, der vollständig im Speicher gehalten werden kann, PARTIAL, bei einem großen Datensatz nur die neuesten Datensätze zwischenspeichern, oder NONE, um den Cache vollständig zu deaktivieren. Für PARTIAL Im Cache können Sie auch die Anzahl der zu puffernden Zeilen und die Lebensdauer konfigurieren.
  • Asynchrone Suche ist eine weitere Funktion, die die Leistung erheblich verbessern kann. Die asynchrone Suche bietet in Apache Flink SQL eine ähnliche Funktionalität wie Asynchrone E/A verfügbar in der DataStream-API. Dadurch kann Apache Flink neue Anfragen an die Datenbank senden, ohne den Verarbeitungsthread zu blockieren, bis Antworten auf frühere Suchvorgänge eingegangen sind. Ähnlich wie bei Async I/O können Sie die asynchrone Suche konfigurieren, um die Reihenfolge zu erzwingen oder ungeordnete Ergebnisse zuzulassen, oder die Pufferkapazität und das Timeout anpassen.
  • Sie können auch a konfigurieren Suchwiederholungsstrategie in Kombination mit PARTIAL or NONE Lookup-Cache, um das Verhalten im Falle einer fehlgeschlagenen Suche in der externen Datenbank zu konfigurieren.

Alle diese Verhaltensweisen können mithilfe von a gesteuert werden LOOKUP Hinweis, wie im folgenden Beispiel, in dem wir einen Lookup-Join mit asynchroner Suche zeigen:

SELECT 
    /*+ LOOKUP('table'='Customers', 'async'='true', 'output-mode'='allow_unordered') */ 
    O.order_id, O.total, C.address
FROM Orders AS O 
JOIN Customers FOR SYSTEM_TIME AS OF O.proc_time AS C 
  ON O.customer_id = O.customer_id

PyFlink

In diesem Abschnitt besprechen wir neue Verbesserungen und Unterstützung in PyFlink.

Python 3.10-Unterstützung

Die neuesten Versionen von Apache Flink führten mehrere Verbesserungen für PyFlink-Benutzer ein. In erster Linie wird Python 3.10 jetzt unterstützt und die Unterstützung für Python 3.6 wurde vollständig entfernt (FLINK-29421). Managed Service für Apache Flink verwendet derzeit die Python 3.10-Laufzeit, um PyFlink-Anwendungen auszuführen.

Wir nähern uns der Feature-Parität

Aus Sicht der Programmier-API nähert sich PyFlink mit jeder Version Java an. Die DataStream-API unterstützt jetzt Funktionen wie Nebenausgaben und Broadcast-Status, und Lücken in der Fenster-API wurden geschlossen. PyFlink unterstützt jetzt auch neue Konnektoren wie Amazon Kinesis-Datenströme direkt von der DataStream-API.

Verbesserungen im Thread-Modus

PyFlink ist sehr effizient. Der Overhead beim Ausführen von Flink-API-Operatoren in PyFlink ist im Vergleich zu Java oder Scala minimal, da die Laufzeit die Operatorimplementierung tatsächlich direkt in der JVM ausführt, unabhängig von der Sprache Ihrer Anwendung. Wenn Sie jedoch eine benutzerdefinierte Funktion haben, sieht die Sache etwas anders aus. Eine Zeile Python-Code so einfach wie lambda x: x + 1oder so komplex wie eine Pandas-Funktion, muss in einer Python-Laufzeit ausgeführt werden.

Standardmäßig führt Apache Flink auf jedem Task-Manager eine Python-Laufzeit außerhalb der JVM aus. Jeder Datensatz wird serialisiert, per Interprozesskommunikation an die Python-Laufzeit übergeben, deserialisiert und in der Python-Laufzeit verarbeitet. Das Ergebnis wird dann serialisiert und an die JVM zurückgegeben, wo es deserialisiert wird. Das ist der PyFlink PROCESS-Modus. Es ist sehr stabil, verursacht jedoch einen Overhead und kann in manchen Fällen zu einem Leistungsengpass führen.

Seit Version 1.15 unterstützt auch Apache Flink THREAD-Modus für PyFlink. In diesem Modus werden benutzerdefinierte Python-Funktionen innerhalb der JVM selbst ausgeführt, wodurch der Serialisierungs-/Deserialisierungs- und Interprozess-Kommunikationsaufwand entfällt. Der Thread-Modus hat einige Einschränkungen; Beispielsweise kann der THREAD-Modus nicht für Pandas oder UDAFs (benutzerdefinierte Aggregatfunktionen, bestehend aus vielen Eingabedatensätzen und einem Ausgabedatensatz) verwendet werden, kann aber die Leistung einer PyFlink-Anwendung erheblich verbessern.

Mit Version 1.16 wurde die Unterstützung des THREAD-Modus erheblich erweitert und umfasst auch die Python DataStream API.

Der THREAD-Modus wird vom Managed Service für Apache Flink unterstützt und kann dies auch sein direkt über Ihre PyFlink-Anwendung aktiviert.

Apple Silicon-Unterstützung

Wenn Sie Apple Silicon-basierte Maschinen zur Entwicklung von PyFlink-Anwendungen verwenden und für PyFlink 1.15 entwickeln, sind Sie wahrscheinlich auf einige der bekannten Python-Abhängigkeitsprobleme bei Apple Silicon gestoßen. Diese Probleme wurden endlich gelöst (FLINK-25188). Diese Einschränkungen wirkten sich nicht auf PyFlink-Anwendungen aus, die auf Managed Service für Apache Flink ausgeführt werden. Wenn Sie vor Version 1.16 eine PyFlink-Anwendung auf einem Computer mit M1-, M2- oder M3-Chipsatz entwickeln wollten, mussten Sie welche verwenden Problemumgehungen, da es unmöglich war, PyFlink 1.15 oder früher direkt auf dem Computer zu installieren.

Nicht ausgerichtete Checkpoint-Verbesserungen

Apache Flink 1.15 unterstützt bereits inkrementelle Checkpoints und Buffer Debloating. Diese Funktionen können insbesondere in Kombination verwendet werden, um die Checkpoint-Leistung zu verbessern und die Checkpoint-Dauer vorhersehbarer zu machen, insbesondere bei Vorhandensein von Gegendruck. Weitere Informationen zu diesen Funktionen finden Sie unter Optimieren Sie das Checkpointing in Ihrem Amazon Managed Service für Apache Flink-Anwendungen mit Pufferdebloating und nicht ausgerichteten Checkpoints.

Mit den Versionen 1.16 und 1.17 wurden mehrere Änderungen eingeführt, um die Stabilität und Leistung zu verbessern.

Umgang mit Datenverzerrungen

Apache Flink verwendet Wasserzeichen zur Unterstützung der Ereigniszeitsemantik. Wasserzeichen sind spezielle Datensätze, die normalerweise vom Quelloperator in den Fluss eingefügt werden und den Fortschritt der Ereigniszeit für Operatoren wie Ereigniszeitfensteraggregationen markieren. Eine gängige Technik besteht darin, Wasserzeichen vom Zeitpunkt des zuletzt beobachteten Ereignisses zu verzögern, um zu ermöglichen, dass Ereignisse zumindest bis zu einem gewissen Grad außer Betrieb sind.

Allerdings ist die Verwendung von Wasserzeichen mit einer Herausforderung verbunden. Wenn die Anwendung über mehrere Quellen verfügt und beispielsweise Ereignisse von mehreren Partitionen eines Kafka-Themas empfängt, werden Wasserzeichen für jede Partition unabhängig generiert. Intern wartet jeder Operator immer auf das gleiche Wasserzeichen auf allen Eingabepartitionen und richtet es praktisch auf der langsamsten Partition aus. Der Nachteil besteht darin, dass Wasserzeichen nicht verarbeitet werden, wenn eine der Partitionen keine Daten empfängt, was die End-to-End-Latenz erhöht. Aus diesem Grund ist ein optionales Leerlauf-Timeout wurde in vielen Streaming-Quellen eingeführt. Nach Ablauf der konfigurierten Zeitüberschreitung ignoriert die Wasserzeichengenerierung alle Partitionen, die keine Datensätze empfangen, und die Wasserzeichen können fortgesetzt werden.

Sie können auch vor einer ähnlichen, aber entgegengesetzten Herausforderung stehen, wenn eine Quelle Ereignisse viel schneller empfängt als die anderen. Wasserzeichen werden auf die langsamste Partition ausgerichtet, was bedeutet, dass jede Fensteraggregation auf das Wasserzeichen wartet. Datensätze von der schnellen Quelle müssen warten und gepuffert werden. Dies kann dazu führen, dass ein übermäßiges Datenvolumen gepuffert wird und der Betreiberstatus unkontrolliert anwächst.

Um das Problem schnellerer Quellen zu lösen, können Sie ab Apache Flink 1.17 die Wasserzeichenausrichtung von Quellaufteilungen aktivieren (FLINK-28853). Dieser standardmäßig deaktivierte Mechanismus stellt sicher, dass die Wasserzeichen keiner Partition im Vergleich zu anderen Partitionen zu schnell aktualisiert werden. Sie können mehrere Quellen, z. B. mehrere Eingabethemen, miteinander verbinden, dieselbe Ausrichtungsgruppen-ID zuweisen und die Dauer der maximalen Abweichung vom aktuellen Wasserzeichen konfigurieren. Wenn eine bestimmte Partition Ereignisse zu schnell empfängt, unterbricht der Quellenoperator die Nutzung dieser Partition, bis die Abweichung unter den konfigurierten Schwellenwert sinkt.

Sie können es für jede Quelle separat aktivieren. Sie müssen lediglich eine Alignment-Gruppen-ID angeben, die alle Quellen mit derselben ID zusammenfasst, sowie die Dauer der maximalen Abweichung vom aktuellen minimalen Wasserzeichen. Dadurch wird die Verarbeitung der Quell-Unteraufgabe, die zu schnell voranschreitet, angehalten, bis die Abweichung unter dem angegebenen Schwellenwert liegt.

Der folgende Codeausschnitt zeigt, wie Sie die Wasserzeichenausrichtung von Quellaufteilungen in einer Kafka-Quelle einrichten können, die begrenzte Wasserzeichen außerhalb der Reihenfolge ausgibt:

KafkaSource<Event> kafkaSource = ...
DataStream<Event> stream = env.fromSource(
    kafkaSource,
    WatermarkStrategy.<Event>forBoundedOutOfOrderness( Duration.ofSeconds(20))
        .withWatermarkAlignment("alignment-group-1", Duration.ofSeconds(20), Duration.ofSeconds(1)),
    "Kafka source"));

Diese Funktion ist nur mit verfügbar FLIP-217 kompatible Quellen, die die Wasserzeichenausrichtung von Quellaufteilungen unterstützen. Zum jetzigen Zeitpunkt unterstützt von den wichtigsten Streaming-Quellen-Konnektoren nur Kafka Source diese Funktion.

Direkte Unterstützung für das Protobuf-Format

Die SQL- und Tabellen-APIs unterstützen jetzt direkt Protobuf-Format. Um dieses Format zu verwenden, müssen Sie die Protobuf-Java-Klassen aus generieren .proto Erstellen Sie Schemadefinitionsdateien und fügen Sie sie als Abhängigkeiten in Ihre Anwendung ein.

Das Protobuf-Format funktioniert nur mit den SQL- und Tabellen-APIs und nur zum Lesen oder Schreiben von Protobuf-serialisierten Daten aus einer Quelle oder in eine Senke. Derzeit unterstützt Flink Protobuf nicht direkt, um den Status direkt zu serialisieren, und es unterstützt keine Schemaentwicklung, wie dies der Fall ist Avro, Zum Beispiel. Sie müssen sich noch registrieren benutzerdefinierter Serialisierer mit etwas Overhead für Ihre Bewerbung.

Halten Sie Apache Flink als Open Source

Apache Flink verlässt sich intern auf Akka, um Daten zwischen Unteraufgaben zu senden. Im Jahr 2022 Lightbend, das Unternehmen hinter Akka, kündigte eine Lizenzänderung an für zukünftige Akka-Versionen, von Apache 2.0 auf eine restriktivere Lizenz, und dass Akka 2.6, die von Apache Flink verwendete Version, kein weiteres Sicherheitsupdate oder Fix erhalten würde.

Obwohl Akka in der Vergangenheit sehr stabil war und keine häufigen Updates erforderte, stellte diese Lizenzänderung ein Risiko für das Apache Flink-Projekt dar. Die Entscheidung der Apache-Flink-Community bestand darin, Akka durch einen Fork der Version 2.6 mit dem Namen zu ersetzen Apache Pekko (FLINK-32468). Dieser Fork behält die Apache 2.0-Lizenz und erhält alle erforderlichen Updates von der Community. In der Zwischenzeit wird die Apache-Flink-Community darüber nachdenken, ob die Abhängigkeit von Akka oder Pekko vollständig entfernt werden soll.

Zustandskomprimierung

Apache Flink bietet optionale Komprimierung (Standard: aus) für alle Checkpoints und Savepoints. Apache Flink hat einen Fehler identifiziert in Flink 1.18.1, wo der Operatorstatus nicht ordnungsgemäß wiederhergestellt werden konnte, wenn die Snapshot-Komprimierung aktiviert ist. Dies könnte entweder zu Datenverlust oder zur Unmöglichkeit der Wiederherstellung vom Prüfpunkt führen. Um dieses Problem zu beheben, hat Managed Service für Apache Flink das zurückportiert fixieren die in zukünftigen Versionen von Apache Flink enthalten sein wird.

Direkte Versions-Upgrades mit Managed Service für Apache Flink

Wenn Sie derzeit eine Anwendung im Managed Service für Apache Flink mit Apache Flink 1.15 oder älter ausführen, können Sie sie jetzt direkt auf 1.18 aktualisieren, ohne den Status zu verlieren AWS-Befehlszeilenschnittstelle (AWS-CLI), AWS CloudFormation or AWS Cloud-Entwicklungskit (AWS CDK) oder ein beliebiges Tool, das die AWS-API verwendet.

Das Anwendung aktualisieren Die API-Aktion unterstützt jetzt die Aktualisierung der Apache Flink-Laufzeitversion einer vorhandenen Managed Service for Apache Flink-Anwendung. Sie können UpdateApplication direkt in einer laufenden Anwendung verwenden.

Bevor Sie mit der direkten Aktualisierung fortfahren, müssen Sie die in Ihrer Anwendung enthaltenen Abhängigkeiten überprüfen und aktualisieren und sicherstellen, dass sie mit der neuen Apache Flink-Version kompatibel sind. Insbesondere müssen Sie alle Apache Flink-Bibliotheken, Konnektoren und möglicherweise die Scala-Version aktualisieren.

Wir empfehlen außerdem, die aktualisierte Anwendung zu testen, bevor Sie mit dem Update fortfahren. Wir empfehlen, lokal und in einer Nicht-Produktionsumgebung mit der Zielversion von Apache Flink zu testen, um sicherzustellen, dass keine Regressionen eingeführt wurden.

Und schließlich, wenn Ihre Anwendung zustandsbehaftet ist, empfehlen wir die Durchführung eines Schnappschuss des laufenden Anwendungsstatus. Dadurch können Sie zur vorherigen Anwendungsversion zurückkehren.

Wenn Sie bereit sind, können Sie jetzt das verwenden Anwendung aktualisieren API-Aktion oder Update-Anwendung AWS CLI-Befehl zum Aktualisieren der Laufzeitversion der Anwendung und zum Verweisen auf das neue Anwendungsartefakt, JAR oder ZIP-Datei mit den aktualisierten Abhängigkeiten.

Ausführlichere Informationen zum Prozess und zur API finden Sie unter Direktes Versions-Upgrade für Apache Flink. Die Dokumentation enthält eine Schritt-für-Schritt-Anleitung und ein Video, das Sie durch den Upgrade-Prozess führt.

Schlussfolgerungen

In diesem Beitrag haben wir einige der neuen Funktionen von Apache Flink untersucht, die im Amazon Managed Service für Apache Flink unterstützt werden. Diese Liste ist nicht vollständig. Apache Flink führte auch einige vielversprechende Funktionen ein, wie TTL auf Operatorebene für die SQL- und Tabellen-API [FLIP-292] und Zeitreisen [FLIP-308], diese werden jedoch noch nicht von der API unterstützt und sind für Benutzer noch nicht wirklich zugänglich. Aus diesem Grund haben wir uns entschieden, sie in diesem Beitrag nicht zu behandeln.

Mit der Unterstützung von Apache Flink 1.18 unterstützt Managed Service für Apache Flink jetzt die neueste veröffentlichte Apache Flink-Version. Wir haben einige der interessanten neuen Funktionen und neuen Konnektoren gesehen, die mit Apache Flink 1.18 verfügbar sind, und wie Managed Service für Apache Flink Ihnen dabei hilft, eine vorhandene Anwendung vor Ort zu aktualisieren.

Weitere Details zu aktuellen Versionen finden Sie im Apache Flink-Blog und in den Versionshinweisen:

Wenn Sie neu bei Apache Flink sind, empfehlen wir unsere Leitfaden zur Auswahl der richtigen API und Sprache und im Anschluss an die Erste Schritte um mit der Nutzung von Managed Service für Apache Flink zu beginnen.

Über die Autoren

Lorenzo NicoraLorenzo Nicora arbeitet als Senior Streaming Solution Architect bei AWS und unterstützt Kunden in der gesamten EMEA-Region. Er entwickelt seit über 25 Jahren cloudnative, datenintensive Systeme und ist in der Finanzbranche sowohl für Beratungsunternehmen als auch für FinTech-Produktunternehmen tätig. Er hat Open-Source-Technologien umfassend genutzt und zu mehreren Projekten beigetragen, darunter Apache Flink.

Francisco MorilloFrancisco Morillo ist Streaming Solutions Architect bei AWS. Francisco arbeitet mit AWS-Kunden zusammen und hilft ihnen beim Entwurf von Echtzeit-Analysearchitekturen mithilfe von AWS-Diensten und unterstützt Amazon MSK und Amazon Managed Service für Apache Flink.

spot_img

Neueste Intelligenz

spot_img

Copyright @ 2024 Plato Technologies Inc.