最近在從事實時方面的工作，主要涉及到資料處理、加工及視覺化，在採坑的過程中總結出一套比較簡單的實時計算方案，供大家參考。主要涉及到幾個元件，kafka，flink，redis，druid和es。相信大家對以上幾個元件都比較熟悉了，這裡就不細說了。我們從一個簡單的需求，來說明各個元件是怎麼協作的。

     假如現在我們有一個電商平臺，每天訪問的流量巨大，主要訪問流量都集中在衣服類、家電類頁面，那麼我們想實時看到這兩類頁面的訪問量走勢（十分鐘出一個統計量），當做平臺的重要指標，視覺化的資料如下。

資料採集    

為了計算訪問量，前提就是要進行資料採集，假設平臺在每一次使用者訪問的時候，我們可以獲取到資訊包括：手機號，訪問頁面型別，訪問時間。資料採集的方式有很多，一般我採用埋點的方式，將【手機號，訪問頁面型別，訪問時間】，形成一條埋點計入日誌，然後採用flume或其他元件，將埋點日誌收集進入kafka（根據訪問量，設定partition數量）

資料處理

資料處理是最關鍵的階段，這裡選用flink處理kafka的流，該過程包括過濾、格式轉換、分組等等、去重、附加欄位、聚合等。針對我們的需求，我們可以分為幾個階段：

1.資料過濾

資料過濾，就是為了過濾掉非法資料，針對我們的需求，比如過濾掉手機號為空的記錄

2.資料分組

資料分組是一個比較重要的階段，這涉及到我們資料統計的方式，在分組的時候我們一般按照資料最低維度來分組，增加資料靈活性，如果我們這裡先按照頁面型別分組，分組的結果就是我相同頁面型別的資料會在同一個分組。

3.資料window

window選擇

資料window是實時處理中比較重要的特點，因為我們需要看到資料的統計結果，所以必須先給資料流劃分批次，然後對批中的資料做聚合，flink的window比較豐富，包括time window，thumb window等等。在我們的需求中要看到10分鐘內的訪問量，所以這裡選用time window，為了應對靈活多變的需求，我們需要選擇合適的視窗時長，比如現在的需求要看到10分鐘內的訪問量，如果想要看到每分鐘的訪問量該怎麼辦呢，所以一般我們視窗時長會選擇最小的粒度，這裡我們選擇1分鐘的視窗時長。

time 型別

選用time window時需要注意，我們的時間標準，有兩個概念需要注意，一個是event time指時間發生時間，另一個是process time指訊息處理時間，這兩個時間是有差別的，比如使用者在7：01：23的時候訪問了平臺，但是埋點經過flume，kafka再到flink延遲至7：01：45的時候才到，那麼event time是7：01：23，process time是7：01：45，我們如果想準確統計訪問量，就需要選用event time，值得注意的是，如果以event time為時間標準的話，需要kafka中的訊息，帶有時間戳。

4.資料聚合

當分組和window都設定好以後，就可以對資料做聚合了，比如分組之後的資料，我們直接可以做reduce，或count，sum，max，min。這裡我們做reduce,對記錄做count。需要注意的是，如果需求變了，需要對手機號做去重，那麼在去重的時候還要加入去重的邏輯，去重如果量小的話可以再flink中做，如果量大的話，可以依賴redis等中間kv儲存，做去重。

資料落地

資料聚合完之後，就需要將資料落地，這是可以選擇直接落入儲存，或傳送到下游topic用來進行更加複雜的計算，我一般為了靈活擴充套件會將資料sink到下游topic，然後由kafka直接接入druid或es。在落入druid的時候需要注意，因為druid特有的預聚合方式，你要指定維度，指標，聚合時間戳欄位以及時間段長度，所以聚合結果中需要帶上，event time的時間戳，同時決定預聚合時長。回到需要：10分鐘統計一次，因此預聚合時長可以在1~10分鐘內任意選擇。需要說明的是，資料不需要做特殊加工（比如不需要去重、不需要關聯、資料量沒那麼大）的時候可以跳過flink階段，直接落入druid中，因為druid本身就帶有多種預聚合功能。

資料校驗

本需求可能比較簡單，但是在實際需求可能複雜的多，為了確保資料的正確性，需要把明細資料備份下來，方便資料校驗，一般備份的資料不需要實時性的時候，可以將資料落入hive中，而需要實時校對的時候，可以將資料落入es中。

      在實際場景中，資料多種多樣，該方案僅使用於特定場景，如有不足之處歡迎大家，評論指正！！！