file
隨著諸如Apache Flink，Apache Spark，Apache Storm之類的開源框架以及諸如Google Dataflow之類的云框架的增多，創建實時資料處理作業變得非常容易，這些API定義明確，并且諸如Map-Reduce之類的標準概念在所有框架中都遵循幾乎相似的語意，

但是，直到今天，實時資料處理領域的開發人員都在為該領域的某些特性而苦苦掙扎，因此，他們在不知不覺中創建了一條路徑，該路徑導致了應用程式中相當常見的錯誤，

讓我們看一下在設計實時應用程式時可能需要克服的一些陷阱，

活動時間

源生成資料的時間戳稱為“ 事件時間”，而應用程式處理資料的時間戳稱為“ 處理時間”，在實時資料流應用程式中，最常見的陷阱是無法區分這些時間戳，

讓我們詳細說明一下，

由于諸如代理中的GC較高或太多資料導致背壓之類的多個問題，資料佇列易出現延遲，我將事件表示為（E，P），其中E是事件時間戳（HH：MM：SS格式），P是處理時間戳，在理想世界中，E == P，但這在任何地方都不會發生，

假設我們收到以下資料

（'05：00：00'，'05：00：02'），（'05：00：01'，'05：00：03'），（'05：00：01'，'05：00： 03'），（'05:00:01'，'05:00:05'），
（'05:00:02'，'05:00:05'），（'05:00:02'，' 05:00:05'）

現在，我們假設有一個程式可以計算每秒接收到的事件數，根據事件時間，程式回傳

[05:00:00，05:00:01）= 1 
[05:00:01，05:00:02）= 3 
[05:00:02，05:00:03）= 2

但是，基于處理時間，輸出為

[5時○○分00秒，5點00分01秒）= 0 
[5點00分01秒，5點00分02秒）= 0 
[5點00分02秒，5時00分03秒）= 1 
[05:00： 03，05:00:04）= 2 
[05:00:04，05:00:05）= 0 
[05:00:05，05:00:06）= 3

如您所見，這兩個都是完全不同的結果，

資料流中例外的延遲

大多數實時資料應用程式使用來自分布式佇列的資料，例如Apache Kafka，RabbitMQ，Pub / Sub等，佇列中的資料由其他服務生成，例如消費者應用程式的點擊流或資料庫的日志，

問題佇列容易受到延遲的影響，即使在幾十毫秒內，生成的事件也可能到達您的作業中，或者在最壞的情況下可能會花費一個多小時（極高的背壓），由于以下原因，資料可能會延遲：

kafka上的高負載
生產者在其服務器中緩沖資料
由于應用程式中的背壓，消耗速度慢

假設資料將永遠不會延遲是一個巨大陷阱，開發人員應始終具有測量資料延遲的工具，例如，在Kafka，您應該檢查偏移量滯后，

您還應該監視作業中的背壓以及延遲（即事件時間與處理時間之間的差），沒有這些將導致資料意外丟失，例如10分鐘，時間視窗似乎沒有資料，并且視窗顯示10分鐘，之后，其期望值將是預期值的兩倍，

Joins

在批處理資料處理系統中，將兩個資料集合并起來比較簡單，在流處理世界中，情況變得有些麻煩，

//資料集的格式為（時間戳，鍵，值）
//資料組1 （05:00: 
00，A，值A），
（05:00: 01，B，值B），（05:00： 04，C，值C），（05:00:04，D，值D）
//資料流2 
（05:00:00，A，值A'），（05:00:02，B，值B' ），
（05:00:00，C，值C'）

file