ウォーターマークが不正な動作をしている可能性があります（クライアントクロックのスキュー）

Question

ビデオストリーミングクライアントからのイベントフローが約1k-3k/sで、ほとんどがハートビートです。 10分のギャップ期間とデフォルトのトリガー（すなわち、初期トリガーはなく、遅れは許容されない）を有するセッションウィンドウを使用する。

私たちが観察するのは、（1）セッションの不安定で爆発的な放出、（2）不安定で「跳ねる」透かし、時には2週間ほどの歴史の中にある時です。

これは、ローカルクロックスキューを持つクライアントのサブセットに関連付けられ、イベント時間に影響すると考えられます。

これは、「悪い」クライアントからのイベントを遅くマークする代わりに、これらの新しい（古い）タイムスタンプに従って調整し、最近終了したセッションの排出を効果的に停止することを意味します。また、あらかじめ定義された時間に悪いイベントが観察されなかった場合にのみ、ウォーターマークがリアルタイムに進み、最近のセッションが放出されます。

これは合理的な仮説ですか？ これは上記の条件で期待される動作ですか？ 私たちの前提が正しいとすれば、推奨される解決策は何でしょうか？

Answer 1

あなたの仮説は合理的です。 Pub/Sub透かしトラッキングでは過去のデータは無視されますが、一般的に発生した場合は、記述したとおりに動作します。考えられる解決策の1つは、ローカルスキューされたクロックに基づくタイムスタンプではなく、クラウドPub/Subでレコードが受信されたときのタイムスタンプを使用することです。これを行うには、読み取りトランスフォームで.timestampLabel（）を省略するだけです。