Keyby-Datenverteilung in Apache Flink, logischem oder physischem Operator?
Gemäß der Apache Flink-Dokumentation partitioniert die KeyBy-Umwandlung einen Stream logisch in disjunkte Partitionen. Alle Datensätze mit demselben Schlüssel werden derselben Partition zugewiesen.
Ist KeyBy 100% logische Transformation? Enthält es keine physische Datenpartitionierung für die Verteilung auf die Clusterknoten? Wenn ja, wie kann dann sichergestellt werden, dass alle Datensätze mit demselben Schlüssel derselben Partition zugewiesen werden?
Angenommen, wir erhalten einen verteilten Datenstrom vom Apache Kafka-Cluster mit n Knoten. Der Apache Flink-Cluster, in dem unser Streaming-Job ausgeführt wird, besteht aus m Knoten. Wie wird die logische Datenpartitionierung garantiert, wenn die keyBy-Umwandlung auf den eingehenden Datenstrom angewendet wird? Oder handelt es sich um eine physische Datenpartitionierung über die Clusterknoten?
Es scheint, dass ich zwischen logischer und physischer Datenpartitionierung verwechselt bin.
Antworten
Der Schlüsselraum aller möglichen Schlüssel ist in einige Schlüsselgruppen unterteilt . Die Anzahl der Schlüsselgruppen (entspricht der maximalen Parallelität ) ist ein Konfigurationsparameter, den Sie beim Einrichten eines Flink-Clusters festlegen können. Der Standardwert ist 128.
Jeder Schlüssel gehört genau einer Schlüsselgruppe an. Wenn ein Cluster gestartet wird, werden jedem Task-Manager bestimmte Schlüsselgruppen zugewiesen. Wenn der Cluster von einem Prüfpunkt oder Sicherungspunkt aus gestartet wird, werden diese Snapshots nach Schlüsselgruppen indiziert, und jeder Task-Manager lädt den Status für die Schlüssel im Schlüssel Gruppen, denen es zugewiesen wurde.
Während ein Job ausgeführt wird, kennt jeder Task-Manager die Tastenauswahlfunktionen, die zum Berechnen der Schlüssel verwendet werden, und wie Schlüssel Schlüsselgruppen zugeordnet werden. Die TMs kennen auch die Aufteilung von Schlüsselgruppen auf Task-Manager. Dies macht es einfach, jede Nachricht an den Task-Manager weiterzuleiten, der für den Schlüssel dieser Nachricht verantwortlich ist.