Wie kann ich die Prüfpunktaufzeichnung verstehen, wenn Kafka Direct InputDstream und Stateful Stream Transformation verwendet wird?

Question

Auf Garn-Cluster verwende ich kafka directream als Eingabe (ex.batch Zeit ist 15s), und möchte die Eingabe msg in separaten userIds aggregieren. Also verwende ich Stateful Streaming API wie updateStateByKey oder mapWithState. Aber aus der API-Quelle, sehe ich, dass die Standard-Checkpoint-Dauer mapWithState ist BatchDarstellung * 10 (in meinem Fall 150 s), und in Kafka DirectStream der Partition Offset ist jeder Batch (15 s). Tatsächlich kann jeder dstream eine unterschiedliche Checkpoint-Dauer setzen. Also, meine Frage ist:

Wenn Streaming-App abgestürzt ist, starte ich es neu, der Kafka-Offset und State Stream Rdd sind asynchron in Checkpoint, in diesem Fall, wie kann ich keine Daten verlieren verlieren? Oder ich verstehe den Checkpoint-Mechanismus falsch?

Answer 1

Wie kann ich keine Daten verlieren?

Stateful Ströme wie mapWithState oder updateStateByKeyerfordern Ihnen ein Checkpoint-Verzeichnis zur Verfügung zu stellen, denn das Teil ist, wie sie arbeiten, speichern sie den Zustand jeden Zwischen in der Lage sein, den Zustand bei einem Absturz zu erholen.

Darüber hinaus ist jede DStream in der Kette frei, Checkpointing als auch zu fragen, Frage ist "müssen Sie wirklich Checkpoint andere Streams"?

Wenn eine Anwendung abstürzt, nimmt Spark alle Status-RDDs, die im Checkpoint gespeichert sind, und bringt sie zurück in den Speicher, so dass Ihre Daten dort so gut sind wie beim letzten Funken Checkpoint. Eine Sache, die Sie in Erinnerung behalten sollten, ist, wenn Sie Ihren Anwendungscode ändern, können Sie den Status von Checkpoint nicht wiederherstellen, müssen Sie es löschen. Das heißt, wenn Sie zum Beispiel ein Versions-Upgrade durchführen müssen, sind alle Daten, die zuvor in diesem Zustand gespeichert wurden, verschwunden, es sei denn, Sie speichern sie manuell in einer Weise, die die Versionierung ermöglicht.