專案需要從實時單向資料流中讀取和篩選資料，即當遇到標誌資料時，執行某些操作。所有資料只能讀一次，不能回溯。我們的場景是監聽串列埠，然後根據監聽結果，讀取後續資料。
上午寫了個演算法程式：從實時資料流中搜尋資料，監控實時資料流中的資料，發現資料時立即做出應對。然後，寫完了之後，總覺得效能有缺陷。仔細考慮了一下，發現問題在於其資料搜尋演算法不太好：
1）從實時資料流中讀入資料；
2）把資料加入快取；
3）對比快取和目標資料；
在那個演算法中，需要維護乙份（同目標資料一樣大的）快取，然後比較的時候，回溯快取。
我就是在糾結與這個快取的問題，然後想了乙個新的演算法：
1）從實時資料流中讀入資料；
2）比較資料和目標資料：
首字元匹配的，把結果加入佇列中；
二字元後匹配的，繼續；
二字元後不匹配的，從佇列中刪除；
經測試，效能提高超過一半。
上**，先是適合實時資料流的版本：
public static bool search(system.io.stream stream, byte findbytes, int timeout)
;timer.start();
while (!expired)
catch
// 遞增匹配佇列
for (var i = 0; i < matchcount; i++)
// 如果匹配第乙個字元，那麼加入匹配佇列中
if (b == findbytes[0])
// 否則依次判斷每乙個佇列中的匹配結果是否依舊匹配
else
i++;
}else
matchcount--;}}
}}
timer.stop();
timer.close();
return false;
}
public static bool search(system.io.stream stream, byte findbytes)
catch
// 遞增匹配佇列
for (var i = 0; i < matchcount; i++)
// 如果匹配第乙個字元，那麼加入匹配佇列中
if (b == findbytes[0])
// 否則依次判斷每乙個佇列中的匹配結果是否依舊匹配
else
else
matchcount--;}}
}}
return false;
}
檔案大小
純掃瞄檔案耗時
演算法1耗時
演算法2耗時
100k
3ms22ms
10ms
1000m
881ms
4956ms
1265ms
說明：演算法1，指的是從實時資料流中搜尋資料文章所描述的演算法；
演算法2，指的是本文描述的演算法；
純掃瞄檔案耗時，指的是開啟檔案，並逐一讀入全部檔案位元組消耗的時間；
演算法1耗時和演算法2耗時，指的是使用演算法程式搜尋成功靠後的某乙個字串的時間；
100k的測試檔案是ascii的，1g的測試檔案是unicode的。
根據上表的測試結果，我對這個演算法的效能還算滿意，只是需要更多測試，以保證其實用性和穩健性，
以上是本文全部內容。
kafka實時資料流寫入HDFS
一 摘要 impala作為實時資料分析引擎，其源資料時效性要求不同，主要分為離線資料分析和實時資料分析。離線資料分析應用場景下，可以利用hive離線載入資料。實時資料分析則依靠kafka 高吞吐量的訊息發布訂閱系統 二 kafka介紹 kafka是一種高吞吐量的分布式發布訂閱訊息系統，它可以處理消費...
1 騰訊 實時資料流推薦實踐
tecentrec real time stream recommendation in practice 解決問題 主要解決問題 資料量大 實時 準確性 實時計算平台選取 1 支援實時資料統計計算 2 集群擴充套件性好 3 失敗恢復快 4 活躍度較高的開源工具 5 簡單程式設計模式，支援多種國語言...
實時資料流計算引擎Flink和Spark剖析
在過去幾年，業界的主流流計算引擎大多採用spark streaming，隨著近兩年flink的快速發展，flink的使用也越來越廣泛。與此同時，spark針對spark streaming的不足，也繼而推出了新的流計算元件。本文旨在深入分析不同的流計算引擎的內在機制和功能特點，為流處理場景的選型提供...