實時計算知多少?
實時計算是什么?
請看下面的圖:
我們以熱賣產(chǎn)品的統(tǒng)計為例,看下傳統(tǒng)的計算手段:
1將用戶行為、log等信息清洗后保存在數(shù)據(jù)庫中.
2將訂單信息保存在數(shù)據(jù)庫中.
3利用觸發(fā)器或者協(xié)程等方式建立本地索引,或者遠程的獨立索引.
4join訂單信息、訂單明細、用戶信息、商品信息等等表,聚合統(tǒng)計20分鐘內(nèi)熱賣產(chǎn)品,并返回top-10.
5web或app展示.
這是一個假想的場景,但假設你具有處理類似場景的經(jīng)驗,應該會體會到這樣一些問題和難處:
1、水平擴展問題(scale-out)
顯然,如果是一個具有一定規(guī)模的電子商務網(wǎng)站,數(shù)據(jù)量都是很大的。而交易信息因為涉及事務,所以很難直接舍棄關系型數(shù)據(jù)庫的事務能力,遷移到具有更好的scale-out能力的NoSQL數(shù)據(jù)庫中。
那么,一般都會做sharding。歷史數(shù)據(jù)還好說,我們可以按日期來歸檔,并可以通過批處理式的離線計算,將結果緩存起來。
但是,這里的要求是20分鐘內(nèi),這很難。
2、性能問題
這個問題,和scale-out是一致的,假設我們做了sharding,因為表分散在各個節(jié)點中,所以我們需要多次入庫,并在業(yè)務層做聚合計算。
問題是,20分鐘的時間要求,我們需要入庫多少次呢?
10分鐘呢?
5分鐘呢?
實時呢?
而且,業(yè)務層也同樣面臨著單點計算能力的局限,需要水平擴展,那么還需要考慮一致性的問題。
所以,到這里一切都顯得很復雜。
3、業(yè)務擴展問題
假設我們不僅僅要處理熱賣商品的統(tǒng)計,還要統(tǒng)計廣告點擊、或者迅速根據(jù)用戶的訪問行為判斷用戶特征以調(diào)整其所見的信息,更加符合用戶的潛在需求等,那么業(yè)務層將會更加復雜。
也許你有更好的辦法,但實際上,我們需要的是一種新的認知:
這個世界發(fā)生的事,是實時的。
所以我們需要一種實時計算的模型,而不是批處理模型。
我們需要的這種模型,必須能夠處理很大的數(shù)據(jù),所以要有很好的scale-out能力,最好是,我們都不需要考慮太多一致性、復制的問題。
那么,這種計算模型就是實時計算模型,也可以認為是流式計算模型。
現(xiàn)在假設我們有了這樣的模型,我們就可以愉快地設計新的業(yè)務場景:
轉發(fā)最多的微博是什么?
最熱賣的商品有哪些?
大家都在搜索的熱點是什么?
我們哪個廣告,在哪個位置,被點擊最多?
或者說,我們可以問:
這個世界,在發(fā)生什么?
最熱的微博話題是什么?
我們以一個簡單的滑動窗口計數(shù)的問題,來揭開所謂實時計算的神秘面紗。
假設,我們的業(yè)務要求是:
統(tǒng)計20分鐘內(nèi)最熱的10個微博話題。
解決這個問題,我們需要考慮:
1、數(shù)據(jù)源
這里,假設我們的數(shù)據(jù),來自微博長連接推送的話題。
2、問題建模
我們認為的話題是#號擴起來的話題,最熱的話題是此話題出現(xiàn)的次數(shù)比其它話題都要多。
比如:@foreach_break : 你好,#世界#,我愛你,#微博#。
“世界”和“微博”就是話題。
3、計算引擎
我們采用storm。
4、定義時間
如何定義時間?
時間的定義是一件很難的事情,取決于所需的精度是多少。
根據(jù)實際,我們一般采用tick來表示時刻這一概念。
在storm的基礎設施中,executor啟動階段,采用了定時器來觸發(fā)“過了一段時間”這個事件。
如下所示:
(defn setup-ticks! [worker executor-data] (let [storm-conf (:storm-conf executor-data) tick-time-secs (storm-conf TOPOLOGY-TICK-TUPLE-FREQ-SECS) receive-queue (:receive-queue executor-data) context (:worker-context executor-data)] (when tick-time-secs (if (or (system-id? (:component-id executor-data)) (and (= false (storm-conf TOPOLOGY-ENABLE-MESSAGE-TIMEOUTS)) (= :spout (:type executor-data)))) (log-message "Timeouts disabled for executor " (:component-id executor-data) ":" (:executor-id executor-data)) (schedule-recurring (:user-timer worker) tick-time-secs tick-time-secs (fn [] (disruptor/publish receive-queue [[nil (TupleImpl. context [tick-time-secs] Constants/SYSTEM_TASK_ID Constants/SYSTEM_TICK_STREAM_ID)]] )))))))
每隔一段時間,就會觸發(fā)這樣一個事件,當流的下游的bolt收到一個這樣的事件時,就可以選擇是增量計數(shù)還是將結果聚合并發(fā)送到流中。
bolt如何判斷收到的tuple表示的是“tick”呢?
負責管理bolt的executor線程,從其訂閱的消息隊列消費消息時,會調(diào)用到bolt的execute方法,那么,可以在execute中這樣判斷:
public static boolean isTick(Tuple tuple) { return tuple != null && Constants.SYSTEM_COMPONENT_ID .equals(tuple.getSourceComponent()) && Constants.SYSTEM_TICK_STREAM_ID.equals(tuple.getSourceStreamId()); }
結合上面的setup-tick!的clojure代碼,我們可以知道SYSTEM_TICK_STREAM_ID在定時事件的回調(diào)中就以構造函數(shù)的參數(shù)傳遞給了tuple,那么SYSTEM_COMPONENT_ID是如何來的呢?
可以看到,下面的代碼中,SYSTEM_TASK_ID同樣傳給了tuple:
;; 請注意SYSTEM_TASK_ID和SYSTEM_TICK_STREAM_ID
(TupleImpl. context [tick-time-secs] Constants/SYSTEM_TASK_ID Constants/SYSTEM_TICK_STREAM_ID)
然后利用下面的代碼,就可以得到SYSTEM_COMPONENT_ID:
public String getComponentId(int taskId) { if(taskId==Constants.SYSTEM_TASK_ID) { return Constants.SYSTEM_COMPONENT_ID; } else { return _taskToComponent.get(taskId); } }
滑動窗口
有了上面的基礎設施,我們還需要一些手段來完成“工程化”,將設想變?yōu)楝F(xiàn)實。
這里,我們看看Michael G. Noll的滑動窗口設計。
Topology
String spoutId = "wordGenerator"; String counterId = "counter"; String intermediateRankerId = "intermediateRanker"; String totalRankerId = "finalRanker"; // 這里,假設TestWordSpout就是我們發(fā)送話題tuple的源 builder.setSpout(spoutId, new TestWordSpout(), 5); // RollingCountBolt的時間窗口為9秒鐘,每3秒發(fā)送一次統(tǒng)計結果到下游 builder.setBolt(counterId, new RollingCountBolt(9, 3), 4).fieldsGrouping(spoutId, new Fields("word")); // IntermediateRankingsBolt,將完成部分聚合,統(tǒng)計出top-n的話題 builder.setBolt(intermediateRankerId, new IntermediateRankingsBolt(TOP_N), 4).fieldsGrouping(counterId, new Fields( "obj")); // TotalRankingsBolt, 將完成完整聚合,統(tǒng)計出top-n的話題 builder.setBolt(totalRankerId, new TotalRankingsBolt(TOP_N)).globalGrouping(intermediateRankerId);
上面的topology設計如下:
將聚合計算與時間結合起來
前文,我們敘述了tick事件,回調(diào)中會觸發(fā)bolt的execute方法,那可以這么做:
RollingCountBolt:
@Override public void execute(Tuple tuple) { if (TupleUtils.isTick(tuple)) { LOG.debug("Received tick tuple, triggering emit of current window counts"); // tick來了,將時間窗口內(nèi)的統(tǒng)計結果發(fā)送,并讓窗口滾動 emitCurrentWindowCounts(); } else { // 常規(guī)tuple,對話題計數(shù)即可 countObjAndAck(tuple); } } // obj即為話題,增加一個計數(shù) count++ // 注意,這里的速度基本取決于流的速度,可能每秒百萬,也可能每秒幾十. // 內(nèi)存不足? bolt可以scale-out. private void countObjAndAck(Tuple tuple) { Object obj = tuple.getValue(0); counter.incrementCount(obj); collector.ack(tuple); } // 將統(tǒng)計結果發(fā)送到下游 private void emitCurrentWindowCounts() { Map<Object, Long> counts = counter.getCountsThenAdvanceWindow(); int actualWindowLengthInSeconds = lastModifiedTracker.secondsSinceOldestModification(); lastModifiedTracker.markAsModified(); if (actualWindowLengthInSeconds != windowLengthInSeconds) { LOG.warn(String.format(WINDOW_LENGTH_WARNING_TEMPLATE, actualWindowLengthInSeconds, windowLengthInSeconds)); } emit(counts, actualWindowLengthInSeconds); }
上面的代碼可能有點抽象,看下這個圖就明白了,tick一到,窗口就滾動:
IntermediateRankingsBolt & TotalRankingsBolt:
public final void execute(Tuple tuple, BasicOutputCollector collector) { if (TupleUtils.isTick(tuple)) { getLogger().debug("Received tick tuple, triggering emit of current rankings"); // 將聚合并排序的結果發(fā)送到下游 emitRankings(collector); } else { // 聚合并排序 updateRankingsWithTuple(tuple); } }
其中,IntermediateRankingsBolt和TotalRankingsBolt的聚合排序方法略有不同:
IntermediateRankingsBolt的聚合排序方法:
// IntermediateRankingsBolt的聚合排序方法: @Override void updateRankingsWithTuple(Tuple tuple) { // 這一步,將話題、話題出現(xiàn)的次數(shù)提取出來 Rankable rankable = RankableObjectWithFields.from(tuple); // 這一步,將話題出現(xiàn)的次數(shù)進行聚合,然后重排序所有話題 super.getRankings().updateWith(rankable); }
TotalRankingsBolt的聚合排序方法:
// TotalRankingsBolt的聚合排序方法 @Override void updateRankingsWithTuple(Tuple tuple) { // 提出來自IntermediateRankingsBolt的中間結果 Rankings rankingsToBeMerged = (Rankings) tuple.getValue(0); // 聚合并排序 super.getRankings().updateWith(rankingsToBeMerged); // 去0,節(jié)約內(nèi)存 super.getRankings().pruneZeroCounts(); }
而重排序方法比較簡單粗暴,因為只求前N個,N不會很大:
private void rerank() { Collections.sort(rankedItems); Collections.reverse(rankedItems); }
結語
下圖可能就是我們想要的結果,我們完成了t0 - t1時刻之間的熱點話題統(tǒng)計,其中的foreach_break僅僅是為了防盜版 : ].
以上就是本文的全部內(nèi)容,希望大家喜歡。
相關文章
Java訪問Hadoop分布式文件系統(tǒng)HDFS的配置說明
Hadoop的能提供高吞吐量的數(shù)據(jù)訪問,是集群式服務器的上的數(shù)據(jù)操作利器,這里就來為大家分享Java訪問Hadoop分布式文件系統(tǒng)HDFS的配置說明:2016-06-06Java中String字符串常量池和intern方法源碼分析
在之前的文章中,小編給大家介紹了String字符串的不可變性及其實現(xiàn)原理,其中給大家提到了字符串常量池的概念,那么什么是常量池,String字符串與常量池有什么關系,本文給大家嘮嘮字符串常量池及String#intern()方法的作用,需要的朋友可以參考下2023-05-05SpringBoot如何優(yōu)雅實現(xiàn)接口參數(shù)驗證
為了保證參數(shù)的正確性,我們需要使用參數(shù)驗證機制,來檢測并處理傳入的參數(shù)格式是否符合規(guī)范,所以本文就來和大家聊聊如何優(yōu)雅實現(xiàn)接口參數(shù)驗證吧2023-08-08