這篇文章主要介紹流式數(shù)據(jù)處理的計算模型， 對于目前你搜索查找的問題還是具有很好的參考價值，希望編程之家小編整理的這個內(nèi)容對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教。
編程之家（)小編說：接觸這塊將近3個月左右，期間給自己的定位也是業(yè)務(wù)層開發(fā)。對平臺級的產(chǎn)品沒有太深入的理解和研究map是什么接入點map是什么接入點，所以也不能大談特談什么storm架構(gòu)之類的了。 說說業(yè)務(wù)中碰到流式計算問題吧： 1.還是要介紹下簡要的架構(gòu)(原諒我不會畫圖) 流式數(shù)據(jù)接入層------------------->流式數(shù)據(jù)處理層------------------->結(jié)果數(shù)據(jù)歸檔層
接觸這塊將近3個月左右，期間給自己的定位也是業(yè)務(wù)層開發(fā)。對平臺級的產(chǎn)品沒有太深入的理解和研究，所以也不能大談特談什么storm架構(gòu)之類的了。
說說業(yè)務(wù)中碰到流式計算問題吧：
1.還是要介紹下簡要的架構(gòu)(原諒我不會畫圖)
流式數(shù)據(jù)接入層------------------->流式數(shù)據(jù)處理層------------------->結(jié)果數(shù)據(jù)歸檔層
||
V
中間數(shù)據(jù)存儲層
所有的數(shù)據(jù)通過接入層源源不斷地進入到這個系統(tǒng)， 在數(shù)據(jù)處理層得到相應(yīng)的計算存儲， 最后將結(jié)果寫入到歸檔層，供下一個系統(tǒng)查詢或作他用。
系統(tǒng)相比于數(shù)據(jù)倉庫，數(shù)據(jù)庫等系統(tǒng)的不同：
1.數(shù)據(jù)是一個個到來，下一個時段的數(shù)據(jù)是未知的
2.數(shù)據(jù)到來的速度也是無法控制的
3.數(shù)據(jù)是有實效性的，必須及時處理
4.數(shù)據(jù)從采集系統(tǒng)到達(dá)接入層的順序是不能保證的
5.任務(wù)永無止境
如果將其和的map-任務(wù)對比，區(qū)別在于：
map和一直在運行，map源源不斷的發(fā)送數(shù)據(jù)，也不停地處理數(shù)據(jù)，沒有任務(wù)執(zhí)行完的概念。
2.系統(tǒng)需要實現(xiàn)的業(yè)務(wù)邏輯
對于常見的數(shù)據(jù)業(yè)務(wù)，有如下幾點，對數(shù)據(jù)庫比較熟悉，就拿sql的幾個操作對比了：
---------------------------固定數(shù)據(jù)查詢（異常或者臟數(shù)據(jù)處理），
max/min/avg-------------------最大最小值
count/sum----------------------求和或次數(shù)統(tǒng)計（比如pv等）
count()------------------去重計數(shù)（典型的如UV）
order by------------------------排序（取近訪問的用戶）
group by + 聚類函數(shù) + order by-----聚類后排序（如訪問次數(shù)最多的topN商品）
3.具體的實現(xiàn)方式：
3.1 指定查詢
這是流式系統(tǒng)里最簡單的處理方式，一般而言進入系統(tǒng)的一個元素是一個個字符串對，（arg1,arg2,arg3,……）
那么指定查詢，就是比較下arg的值，符合要求即做下一步的處理，等到需要時統(tǒng)計結(jié)果。
數(shù)據(jù)讀取次數(shù)：讀0寫1
3.2 最大最小值,平均值----------中間變量
在中間存儲器上保存一個中間變量，每次僅需取出來，進行計算后更新即可。
數(shù)據(jù)讀取次數(shù)：讀1寫1
3.3 TopN排序----------------最大最小堆
同3.2，稍有不同的是，需要保存一個數(shù)據(jù)結(jié)構(gòu)堆。每次更新也需要有相應(yīng)的插入刪除實現(xiàn)。
3.4 窗口內(nèi)計數(shù)--------------------DGIM算法
這里先要談一下時間窗口：其實可以理解成一個隊列，包含兩個操作，add和。
同時還要考慮的是，時間并不是進入系統(tǒng)的時間，有可能是自帶的日志時間，這個是會亂序到來。
這里談計數(shù)，就還包含了一個操作，和get。
3.4 去重計數(shù)----------hash表，搜索樹，F(xiàn)M算法，組合估計
四種方式的邏輯是一致的：一要保存歷史數(shù)據(jù)，二是要壓縮歷史數(shù)據(jù)，三是要方便查詢（判斷是不是存在了，且任意時刻都能匯總結(jié)果）。
而空間，時間，準(zhǔn)確性三個指標(biāo)又是不能全部顧忌的（是不是有點像cap定理了？），你不能要求占用空間有小，判斷時間短，同時又準(zhǔn)確。
一般而言我們是選擇犧牲準(zhǔn)確性（但也要保證一定級別的準(zhǔn)確，差一個量級的話，那就荒唐了），畢竟任何系統(tǒng)都沒有要求UV這種數(shù)據(jù)準(zhǔn)確到個位數(shù)。
這里建議看下FM算法的實現(xiàn)。
3.5 特殊指標(biāo)過濾--------bloom
bloom 真是個古老而又流行的東西。目前接觸過的系統(tǒng)，如果用到過濾，大部分都第一時間考慮bloom 過濾。
他其實是一個泛化的hash（多個hash函數(shù)），節(jié)省空間，時間，同時準(zhǔn)確性保證了一般（會漏，但是不會誤判）。
3.6 熱度統(tǒng)計------------指定時間窗口統(tǒng)計
首先確認(rèn)你的統(tǒng)計粒度。是流水記錄級別的，還是分鐘級別，還是小時級別。
對應(yīng)到時間窗口，那就是你時間指針滑動的最基本單位。
例如 你計算 最近一天的熱銷排行榜，那么你窗口的長度是24小時，同時你的粒度是5分鐘級別的。
那么：
你一共需要保存288條時間粒度的數(shù)據(jù)，每一條表示5分鐘內(nèi)商品的相關(guān)信息，我們記為函數(shù)t()
= f() = K1 * t(1)+ …… + K2*t(288)
3.7 排行榜-----------------隨時間衰減。
這里一般性的問題在3.6里會處理，但有一個卻無法解決。
如果你是一家論壇性質(zhì)的網(wǎng)站，有十大熱門貼，我們記為t1,t2,t3,……,t10。如果有訪問，或者新的記錄過來的話，我們更新即可。
但是還有一種情況是，在半夜長達(dá)幾個小時的情況下，是有可能沒有任何訪問的。那么順序還是原來的那個順序嗎？
不一定，以為每個時間片段的權(quán)重不一樣。可能順序會是： t3,t1,t10……
這時候我們的方法是：自己構(gòu)造一些定時調(diào)度的數(shù)據(jù)，例如5分鐘一次空數(shù)據(jù)，觸發(fā)計算過程，重新更新3.6節(jié)里的值。
4.高級分析函數(shù)的處理
再高級一點，設(shè)計到不同維度的數(shù)據(jù)計算，有這么一些：
where--------------------------指定統(tǒng)計范圍
group by + -------------細(xì)分不同維度的統(tǒng)計
join +union--------------------多個數(shù)據(jù)合并
至于,cube等高級分析函數(shù)就不說，實質(zhì)上由于你可以拿到最明細(xì)的數(shù)據(jù)，什么計算方式都能處理過來的。
5. 性能問題-----------抽樣與近似
萬一數(shù)據(jù)量大到你的系統(tǒng)實在是處理不過來了怎么辦？如果不需要準(zhǔn)確值，那就抽樣吧！
抽樣是解決數(shù)據(jù)量大的最好辦法，可以極大程度減少計算量，其實很多情況下我們并非需要那么準(zhǔn)確的計算值。
比如推薦需要的是一個商品排序，用戶排序（當(dāng)然網(wǎng)站統(tǒng)計的需求基本就不能抽樣了，老老實實想別的辦法吧）。
這里需要注意的是，要非常了解數(shù)據(jù)的分布，比如你求平均值，抽樣卻漏掉了極少數(shù)的極值，那樣誤差就大了。