Pull模式下流計算頻率與週期相關性的分析

本文討論的話題有一些特定的背景，這裏的“流計算”具體指的是以Spark Streaming爲代表的Micro Batch一類的流式計算框架，因此會涉及到Batch Duration、Window以及Slide等概念。在架構層面上，數據流的走向是：數據採集組件以Pull的模式採集數據後推送給消息隊列，流式處理組件以Pull的模式從消息隊列中獲取數據，處理之後寫入NoSQL數據庫，最後，前端的數據展示組件同樣以Pull模式從NoSQL數據庫查詢數據並展示(儘管Pull模式的時效性要差一些，但是受源頭數據源約束，很多數據源只能以Pull的模式進行數據採集，因此本文討論的話題依然有很大的適用性)。因此，在數據採集組件上會有一個數據採集頻率Collecting
Frequency, 在前端查詢的組件上會有一個刷新頻率和以及每次查詢最近多長時間的參數設置，我們把UI上的這兩個參數叫作Time Shift和Refresh
Frequency。 以下是對些相關參數的一些分析：

1. Batch Duration是全局唯一的: 這並不是必須的，只是在Spark Streaming的背景下，Batch Duration是綁定在一個StreamingContext上的，雖然一個應用可以啓動多個StreamingContext，但我們依然認爲單一的StreamingContext在資源管理與調配上有很大的優勢，所以我們應該儘量地保持一個單一的StreamingContext，這也決定了整個應用層面上只有一個Batch Duration。因此Batch Duration的取值應該綜合各個流的業務需求取一個平衡的值，大多數情況下這個Batch Duration的值是各個流相互妥協平衡之後取得的最小值。

2. Batch Duration == Minimum Delay: 這很容易理解，在Micro Bacth的流式系統裏，Batch Duration就是理論上的整個系統的最小延遲，但考慮到數據寫入和前端的查詢頻率，實際的延遲時間還要更大一些。

3. Batch Duration == Refresh Frequency: 把UI上的Refresh Frequency設置爲與Batch Duration一樣大小是比較常規的做法。但是Refresh Frequency確實可以設置的更小，這樣可以讓前端及時地得到剛剛寫入數據庫的數據。

4. Collecting Frequency == Window Size == Time Shift: 這三個參數都不是全局的，而是針對每個流獨立配置的，但它們的取值最終是由Collecting Frequency來確定的， 任何小於Collecting Frequency的Window Size和Time Shift設置沒有意義，任何大於Collecting Frequency的Window Size和Time Shift設置在分析結果的“解析度”上會有所降低，但如果是特殊原因，例如數據採集端鼓勵以“小步快跑”的方式採集數據，而業務端不需要很細時間粒度的分析，就可以這樣設置。本文原文出處: 本文原文鏈接: http://blog.csdn.net/bluishglc/article/details/78456213 轉載請註明出處。