kafkaから別のシステムで下流に伝播したい変更イベントを取得しようとしています。しかし、変更命令は重要です。それで、真ん中でスパーク変換をすることでこれを行うための適切な方法はなんですか？私が見る唯一のことは、並列性を失い、1つのパーティションにDstreamを作成することです。たぶん、並行して操作を行い、すべてを1つのパーティションに戻し、それを外部システムに送信するか、またはカフカに戻し、カフカシンクを使用する方法があります。Sparking Streamingでの注文保証
あなたの経験とアプローチを分かち合うことができれば、それは素晴らしいことでしょう。ありがとう。
ほとんどのレイヤーで何らかの形でキャッシュ/バッファリングを行う分散環境では、同じマシンから生成されたメッセージが異なる順序でバックエンドに到達する可能性があります。また、注文の定義は主観的です。注文の全体的な定義を実装することは、データ全体に対して制限的（正しいとは限りません）です。
したがって、カフカは、データを入れた順に並べることを意図していますが、パーティションはキャッチとして来ます！パーティションは、トピックごとの並列度を定義します。
通常、カフカが保持されている抽象度は、順序についてはあまり気にしないでください。パーティショニングが便利になる最大スループットに最適化する必要があります。ストリーミングをサポートするだけの副作用を注文することを検討してください！
今、ロジックが確実に、データがカフカに順番に入れられるようになり、それがアプリケーション（スパークジョブ）でより意味をなさないようになります。
はい、私はそれを得るが、問題は私の火花の仕事からKAFKAで順番に入れられるようにする方法です。唯一の解決策は、実際には1つのパーティションにデータを修復し、それをkafkaで出力することです。つまり、データの変換を並行して行うことができますが、すべてのパーティションを1つのパーティションに戻してからD kafkaをプッシュするには、再パーティションを実行する必要があります。問題は、すべてのRDDがDStreamに表示される順序で処理されることですか？ – MaatDeamon
カフカはパーティション内での注文を保証します。つまり、変更イベントに固有のIDがある場合、そのデータは常に同じパーティションに格納されます。したがって、注文保証があります。異なる変更イベント、つまり異なるIDにまたがってグローバルオーダーについて心配している場合にのみ、パーティション= 1ルートに移動する必要があります。 –