經過二十多年的研究和開發,事件流處理(ESP)軟體平台已不再局限于在小生境應用或實驗中使用。它們已經成為許多業務環境中實時分析的基本工具。
其動機來自需要分析的流資料量激增,特别是:
- 物聯網傳感器資料;
- 來自使用者互動的點選流;
- 社交媒體事件,如tweets、Instagram posts、Facebook posts和Linked in updates;
- 市場資料;
- 氣象資料;以及
- 業務應用程式中事務的事件流。
早在20世紀90年代,學術界就開始建構開發人員可以用來建構和部署流分析應用程式(當時稱為複雜事件處理(CEP))的通用ESP平台,但在2010年之前,隻有少數商業産品可用。它們主要用于金融交易所的高速交易系統和政府機構的情報應用。
在過去的九年中,商業和開源ESP平台的數量已經從少數增長到40多個。本文總結了該軟體的八個主要趨勢。
無處不在
——幾乎所有主要軟體供應商都提供一個或多個ESP産品(見下面的清單)。供應商意識到流式資料隻會越來越豐富,越來越多的業務應用程式需要能夠實時或接近實時地處理這些資料。
物聯網
——幾年前,我們預測物聯網将成為ESP的殺手級應用(實際上是殺手級應用,因為物聯網是數百種不同的應用,而不是一種)。事實證明就是這樣。大多數物聯網應用程式處理傳感器資料,傳感器資料作為實時事件流生成。我們看到的所有物聯網平台套件都包括一個ESP平台作為産品的一部分。大多數物聯網平台供應商明智地選擇利用其通用ESP産品,而不是僅僅為了嵌入物聯網平台而編寫新的ESP平台。
邊緣處理
——許多物聯網應用程式的預設架構是在邊緣或邊緣附近運作流分析,以接近事件源。物聯網事件的來源包括傳感器、儀表、數字控制系統(DCSs)、監控和資料通路(SCADA)系統以及連接配接到DCSs或SCADA系統的曆史資料庫。在某些情況下,ESP在網關、路由器、卡車、汽車或火車上運作,甚至在終端裝置中運作。在邊緣或靠近邊緣的地方運作ESP有很多好的理由:對不斷變化的條件做出快速響應的較低延遲;較少的網絡開銷;以及更高的可用性(由于網絡關閉或雲伺服器關閉,您負擔不起讓工廠、車輛或其他機器無法運作)。這就産生了層次結構,其中初始流處理是在邊緣上完成的,然後處理和抽象事件的子集被轉發到雲或資料中心,在雲或資料中心中完成另一層流處理。
雲ESP
——幾乎所有ESP産品都可以在公共或雲基礎設施即服務(IaaS)上運作。越來越多的供應商,包括Amazon Web Services、Google、IBM、Microsoft、Salesforce、SQLstream等,為那些不想管理自己的雲ESP服務的公司提供ESP即平台即服務(PaaS)。此外,幾乎所有具有嵌入式ESP平台的物聯網套件都是有效的ESP PaaS提供商。
并行處理
——過去六年上市的許多ESP平台可以稱為分布式流計算平台(DSCP),因為它們将工作負載分散在多個伺服器上。如果特定的應用程式允許資料并行操作,則傳入的資料将被分片并分發給多個工作者,進而實作更高的吞吐量(每秒更多事件)。其他類型的ESP平台也可以設定為跨多個節點分發工作,但它們需要更多的程式設計來實作這一點。
進階分析
——許多供應商正在将機器學習(ML)或業務規則引擎內建到其ESP平台的過程中。ML庫(如評分服務)可以嵌入到事件處理流中。早期的ESP平台通常僅限于使用者定義的功能(例如,用Java或供應商專有的事件處理語言編寫),而不支援現成的分析。
開源
——開源運動在過去五年中對流處理産生了重大影響,正如它影響了其他軟體技術一樣。開源有兩種截然不同的風格:
免費的、開源的流處理架構
主要來自GitHub/Apache,使開發人員能夠在不支付許可費的情況下建構和運作應用程式。它們缺乏商業支援,開發設施和管理工具有限,與外部源和彙的連接配接很少。但是,對于入門、學習事件處理以及建構小型或臨時應用程式來說,它們是很好的。在少數情況下,高度熟練的開發團隊已經在這些産品上建構了大型的、關鍵任務的應用程式。免費開源産品及其主要貢獻者的示例包括:
- Apache Flink (Alibaba Ververica)
- Apache Gearpump (Intel)
- Apache Heron (Twitter)
- Apache Kafka SQL (LinkedIn, Confluent)
- Apache Samza (LinkedIn)
- Apache Spark Streaming (Databricks)
- Apache Storm (Twitter)
- Drools Fusion (RedHat)
- Esper, Nesper (EsperTech)
混合“開放核心”産品
使用上述開源産品,并添加專有增值功能。這些都有商業支援,是以它們吸引那些規避風險、願意支付許可證、維護費或訂閱費的大企業。它們通常還具有更好的開發和管理工具,以及到更多外部系統的連接配接器。很多都有實時的儀表盤;有些有安全擴充或更改資料捕獲(CDC)擴充卡。這些産品的成本與完全專有的ESP産品一樣高,而且它們将應用程式鎖定在與完全專有的産品幾乎相同的位置。然而,購買者喜歡(部分)開源的光環,而且這些産品中的許多都具有一套很好的現代特性。供應商喜歡open core,因為他們不必自己開發整個産品,是以他們可以将資源集中在産品差異化的擴充上。示例包括:
- Alibaba Ververica Platform (formerly data Artisans, on Flink)
- Amazon Kinesis Data Analytics for Java (on Flink)
- Cloudera Hortonworks DataFlow (on Kafka, Nifi, Storm)
- Confluent Platform (on Kafka)
- Databricks Spark Streaming (on Spark)
- EsperTech Esper Enterprise Edition
- Google Cloud DataFlow (with Apache Beam)
- Impetus StreamAnalytix (on Flink, Spark, Storm)
- Informatica Big Data Streaming (on Spark)
- Oracle Stream Analytics (on Spark)
- Pivotal Spring Cloud Data Flow
- Radicalbit Natural Analytics (on Flink, Kafka, Spark)
- Red Hat Decision Manager (on Drools Fusion)
-
Streamlio Intelligent Platform for Fast Data (on Bookkeepper, Heron, Pulsar)
…and apologies to those I may have overlooked
其他供應商,
包括Software AG(Apama)和WSO2(Stream Processor),也将其ESP産品作為開源提供。
- (Google) Alooma Platform
- Astronomer Cloud, Enterprise, Open/Apache Airflow
- (Qlik) Attunity Replicate, Compose
- Equalum LTD Data Beaming
- HVR Software Real-time Replicator
- IBM DataStage, Big Integrate, Infosphere Information Server
- Informatica Big Data Streaming
- InfoWorks Autonomous Data Engine
- Nexla Data Operations
- Streamsets Data Collector
- Syncsort DMX
- Talend Data Streams
一些其他重要的ESP平台.
- Amazon Kinesis Data Analytics
- Axiros Axtract
- EVAM (Event and Action Manager)
- Fujitsu Software Interstage Big Data Complex Event Processing Server
- (Thales) Guavus SQLStream Blaze
- Hitachi uCosminexus Stream Data Platform
- IBM Streams and Decision Server Insights (ODM)
- LG CNS EventPro
- MapR Converged Data Platform with Streams
- Microsoft Azure Stream Analytics, Stream Insight
- SAP Event Stream Processor
- SAS Event Stream Processing Engine
- Software AG Apama Streaming Analytics
- Striim Platform
- TIBCO BusinessEvents, Streaming
- Vitria VIA Analytics Platform
- WSO2 Stream Processor