在GroupBy |中標記鍵是完整的Dataflow Streaming Pipeline

對於我們的Streaming管道，我們要提交唯一的GCS文件，每個文件包含多個事件信息，每個事件也包含一個密鑰（例如，device_id）。作爲處理的一部分，我們想通過這個device_id來洗牌，以便實現某種形式的worker到device_id親和性（關於爲什麼我們想要做的更多背景是在this another SO question。一旦來自同一文件的所有事件都是完成後，我們希望通過其源GCS文件（我們將使事件本身的屬性，如file_id）減少（GroupBy），並最終將輸出寫入GCS（可能是多個文件）。我們想要做GroupBy的最終原因是因爲我們想要在特定的輸入文件完成處理後通知外部服務。這種方法唯一的問題是，由於數據被device_id，然後在file_id末尾分組，則無法保證來自特定file_id的所有數據都已完成處理。在GroupBy |中標記鍵是完整的Dataflow Streaming Pipeline

有什麼我們可以做的嗎？我知道Dataflow提供了保證，這意味着所有事件最終都會被處理，但是有沒有辦法設置確定性觸發器來說明特定鍵的所有數據都已分組？

編輯我想強調，我們正面臨着這裏的更廣泛的問題。標記爲 文件級別完整性的能力將有助於我們檢查點數據的外部消費者看到的不同階段。例如，

這將使我們能夠觸發每小時或每一天完整性這是至關重要的爲我們生成該窗口的報告。考慮到輸入上明確定義了這些階段/障礙（小時/天）（GCS文件是日期/小時分區），期望輸出的結果是自然而然的。但對於Dataflow的模型，這似乎不可能。
同樣，儘管數據流確保準確地只有一次，但由於出現可怕的錯誤，會出現整個管道需要重新啓動的情況 - 在這種情況下，幾乎不可能從正確的輸入標記重新啓動，因爲存在不能保證已經消耗的東西已經被徹底清除。模式試圖實現這一點，但如前所述，如果整個管道混亂並且本身無法取得進展，則無法知道源的哪一部分應該是起點。

我們正在考慮使用Spark，因爲其基於微批的Streaming模型似乎更適合。如果可能的話，我們仍然希望探索Dataflow，但似乎我們無法在應用程序內部從外部存儲這些檢查點的情況下實現它。如果Dataflow提供這些擔保的另一種方法，那將會很好。擴大這個問題背後的想法是看看我們是否錯過了可以解決我們問題的替代視角。

謝謝

來源

2017-05-04 Gowrishankar Sunder

這實際上是棘手的。 Beam和Dataflow都沒有關於每個密鑰水印的概念，並且實現該粒度級別將是困難的。

一個想法是使用有狀態的DoFn而不是第二個隨機播放。該DoFn需要接收文件中預期的元素數量（從主輸入的側輸入或某個特定值）。然後它可以計算它已處理的元素的數量，並且只輸出一旦它已經看到該元素數量就處理了所有內容。

這將是假設元素的數量預計可以提前確定的時間，等

來源

2017-05-04 19:56:44

它是安全的假設，在輸入GCS文件中的每個事件都將產生恰好一個事件到輸出 - 所以我們一旦數據被讀取，就知道預期的事件數量。 –

假設輸入的GCS文件中的每個事件都會向輸出生成一個事件，這是很安全的 - 所以我們知道一旦數據被讀取後事件的預期數量。我有一些後續問題 [1] IIRC，有狀態的ParDos按每個鍵的每個窗口工作 - 假設沒有窗口，這意味着它是一個單一的全局窗口，它仍然在每個鍵的基礎上工作 - 所以我們會需要洗牌「GroupyBy」_file_id_，對吧？ <繼續閱讀下一條評論> –

<繼續之前的評論> [2]在初始讀取GCS文件後生成的側面輸入將是一個Map - 我知道側面輸入或'PCollectionView'也是不可變的 - 那麼Beam/Dataflow如何管理舊的'file_id'的垃圾回收？就像，如果特定'file_id'的所有數據都到達並且外部服務已被通知，由於'file_id - > event_count'不再需要，這怎麼能被刪除，以便側輸入'PCollectionView'不會繼續增長無限地？ <繼續閱讀下一條評論> –

在GroupBy |中標記鍵是完整的Dataflow Streaming Pipeline

回答

相關問題