實時流技術來源及比較

流資料的處理存在很多技術：

1、簡單的事件處理器

2、複雜的事件處理器

3、流處理器

分布式流處理需求日益增加，包括支付交易、社交網絡、物聯網（IOT）、系統監控等。業界對流處理已經有幾種适用的架構來解決，下面我們來比較各流處理架構的相同點以及差別。

分布式流處理是對無邊界資料集進行連續不斷的處理、聚合和分析。它跟MapReduce一樣是一種通用計算，但我們期望延遲在毫秒或者秒級别。這類系統一般采用有向無環圖（DAG）。

當選擇不同的流處理系統時，有以下幾點需要注意的：

運作時和程式設計模型：平台架構提供的程式設計模型決定了許多特色功能，程式設計模型要足夠處理各種應用場景。這是一個相當重要的點，後續會繼續。

函數式原語：流處理平台應該能提供豐富的功能函數，比如，map或者filter這類易擴充、處理單條資訊的函數；處理多條資訊的函數aggregation；跨資料流、不易擴充的操作join。

狀态管理：大部分應用都需要保持狀态處理的邏輯。流處理平台應該提供存儲、通路和更新狀态資訊。

消息傳輸保障：消息傳輸保障一般有三種：at most once，at least once和exactly once。At most once的消息傳輸機制是每條消息傳輸零次或者一次，即消息可能會丢失；A t least once意味着每條消息會進行多次傳輸嘗試，至少一次成功，即消息傳輸可能重複但不會丢失；Exactly once的消息傳輸機制是每條消息有且隻有一次，即消息傳輸既不會丢失也不會重複。

容錯：流處理架構中的失敗會發生在各個層次，比如，網絡部分，磁盤崩潰或者節點當機等。流處理架構應該具備從所有這種失敗中恢複，并從上一個成功的狀态（無髒資料）重新消費。

性能：延遲時間（Latency），吞吐量（Throughput）和擴充性（Scalability）是流處理應用中極其重要的名額。

平台的成熟度和接受度：成熟的流處理架構可以提供潛在的支援，可用的庫，甚至開發問答幫助。選擇正确的平台會在這方面提供很大的幫助。

對海量事件的收集和處理要滿足：低開銷、低延遲。流處理器對此提供了比較好的支援。考慮每秒資料量的大小，再确定如何選用何種技術。（例如流量每秒幾百條消息，每秒數十萬條消息，處理的技術可以完全不同）

Flume 和 NiFi 确切地屬于資料收集（DC）和單事件處理器（SEP），而其它的是多事件流處理器（ESP）引擎或複雜的事件處理器（CEP）。

Spark 本身和 Ignite 确切來說不僅僅是流處理器，他們還提供流媒體功能。Apex 也是同樣的情況，這是一個統一批次和流資料的平台，它應該是介于一個資料收集引擎、一個基本 ETL 工具與一個事件流處理器之間。

Kafka 流是一個 Kafka 的 Java 庫，主要用于消息的處理。Kafka流是最初由 LinkedIn 開發的消息傳遞系統。Kafka 目前在 LinkedIn、Netflix 和 Spotify 中被廣泛應用。Kafka流的特點是低延遲、高容量、分布式的隊列系統。

在 CEP 市場上當然還有許多其他選擇，例如：Software AG 的 Apama，微軟的 StreamInsight，Oracle 事件處理，SAP ESP，Tibco 的 BusinessEvents＆Streambase。它們列出時并沒有按具體的順序！另外還有Esper，其中有一個可擷取的開源版本，是 GNU GPL 許可的。

In-flight 修改表示沒有任何停機或應用程式重新送出的情況。有時也被稱為零停機擴容，和即席或動态應用程式修改。對于 in-flight 修改，Spooker是一個值得多看一眼的項目。