2016-09-22 94 views
0

我有一個用python apache-beam編寫的管道。它將800,000個帶時間戳的數據分成2秒鐘的窗口,每1秒重疊一次。我的元素可能有不同的鍵。爲什麼groupBy瓶頸我的管道?

當它做了GROUPBY,則需要3個小時才能完成。我使用10名員工部署在雲數據流中。當我增加工人數量時,處理速度沒有顯着提高。爲什麼這種變革瓶頸我的管道?

+1

我不熟悉,在這個問題上的特定標籤,但爲了開展「GROUPBY」操作(在非索引字段),那麼無論做分組必須將整個數據集於一體排序地點。沒有這個操作,你可能有容易並行的數據。這是一個字嗎? –

+1

是否有顯示問題的特定工作ID?正如Kenny Ostrom所說,gorupby不僅需要在一個地方對數據進行排序,還需要在工作人員之間傳遞數據,以便處理單個密鑰的工作人員具有所有相關的值。元素有多大(這應該顯示在每個步驟的Dataflow UI中)? –

+1

除非元素很大,否則在每個800,000個元素上執行groupby應該非常快。最有可能的事情是瓶頸 - 你在做每件元素或每把鑰匙都非常昂貴的東西嗎?有多少個不同的鑰匙? (一個按鍵是按順序處理的,所以如果只有很少的按鍵,那麼無論您指定了多少工人,都會限制可達到的最大並行度)的確如此,很難說出沒有工作編號的情況下會發生什麼。 – jkff

回答

0

總結從JKFF和別人的答案:

管道似乎是由一個非常大的鍵瓶頸。您可以使用常規的Java日誌和工作人員的日誌看(如測量processElement(您DOFN的處理時間)與記錄它,如果它是大於閾值),但不幸的是,我們還沒有進行調試「熱鍵」提供了更高級的工具的問題。

您也可以打開autoscaling,使該服務可以,至少,關閉未使用的工人,這樣你就不會產生對他們收費。