2016-06-08 29 views
0

我正在計算來自單個數據集的大量top-n報告。我的小規模測試工作正常。但是當我增加top-n報告的數量時,這項工作被拒絕爲太大。如何讓我的數據流作業更小?

作業JSON(通過--dataflowJobFile)是19 MB。

此實驗用於200個top-n報告,甚至不包括所有報告類型。在生產規模上,我們將處理來自多個數據集的10,000多個前n個報表。

運行併發工作是不切實際的,因爲工作單位需要在尷尬的方式被分割,而兼職的限制僅是25

我可以共享作業ID和工作與GCDF隊私下文件。

+0

top-n報告如何關聯?是什麼使他們獲得了200份不同的top-N報告,而不僅僅是200個鍵的最高N-per-key? –

+0

GCDF的工作請求限制大小爲20MB - 所以這可能是您的工作被拒絕的原因。從小規模測試到全面測試時,代碼中的哪些變化?另外,你可以分享工作ID嗎? – pjesa

+0

工作ID:2016-06-07_18_47_26-16910805709550021335 我無法開始全尺寸工作。這個只有三分之一的大小。 –

回答

1

你想要做的是把尺寸問題轉移到你的數據中,而不是你的管道的大小。如果你喜歡,可以從「控制平面」到「數據平面」。

對於要在其上運行報告的數據的每個子集,請爲該子集分配一個鍵。假設每個報告都是按鍵,則您需要構建包含原始鍵和報告鍵的複合鍵。然後,您可以將單個PCollection上的所有頂部報告(作爲特定n)一起計算爲Top.largestPerKey(n)

假設你有不同的閾值,如前10,最高100等多個頂級ñ報告,以及ñ和數據的子集之間的關係太複雜,只是運行最大的和修剪得到別人。然後,您可以爲每個運行一個單獨的轉換(仍然不應該太多),也可以組合一個composed combine,將它們全部計算在一起。