「事件流处理架构」事件流处理的八个趋势

本文涉及的产品
实时计算 Flink 版,5000CU*H 3个月
简介: 「事件流处理架构」事件流处理的八个趋势

经过二十多年的研究和开发,事件流处理(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产品作为开源提供。

流数据集成(SDI),一种为SDI提供特殊功能的ESP(也称为“实时ETL”)。它们用于实时、低延迟、大容量接收流式事件数据,或用于将大量数据从一个数据库或文件移动到另一个数据库或文件。专注于SDI的产品为各种dbms、文件系统和消息传递系统(如Kafka、kinisis、Pulsar或其他)提供适配器。请注意,其他ESP产品(主要关注实时流分析)也经常用于将事件数据放入数据库或文件中(即,它们可以用于SDI,即使它们可能不具备SDI专家的所有数据集成功能)。相反,一些主要关注SDI的产品也能够实时流分析来驱动仪表板、发送警报或触发自动响应。其中一些产品与普通ESP平台并没有太大区别。以SDI为重点的产品示例包括:

  • (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平台.

这些平台没有在上面的开源或SDI部分中列出:

  • 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
相关文章
|
4月前
|
存储 监控 安全
【B/S架构】医院不良事件报告系统源码
【B/S架构】医院不良事件报告系统源码
55 0
|
7月前
|
存储 监控 安全
医院安全(不良)事件管理系统源代码(B/S架构):事件全程监管 质量持续改进
系统概述 医院安全(不良)事件管理,让上报人更加准确、快捷地将不良事件内容报告给相关管理人员;使管理者系统地收集资料,并通过深入分析与学习,寻找管理中的薄弱环节,完善系统结构和运作。该系统是有效预防不良事件再次发生的一种管理工具。 二、技术架构: PHP+ vue2+element+ laravel8+ mysql5.7+ vscode 三、不良事件类型 护理相关事件:(跌倒事件,坠床事件,压疮事件,管路滑脱事件,给药差错事件,烧伤/烫伤事件,输液反应事件,病人自杀事件,病人走失事件,消毒供应事件,其他事件) 医疗相关事件:(手术事件,麻醉事件,诊疗相关事件,医德医风相关,病案管理事件
69 0
医院安全(不良)事件管理系统源代码(B/S架构):事件全程监管 质量持续改进
|
12月前
|
设计模式 缓存 前端开发
Android 架构之 MVI 究极体 | 状态和事件分道扬镳,粘性不再是问题
Android 架构之 MVI 究极体 | 状态和事件分道扬镳,粘性不再是问题
479 0
|
12月前
|
消息中间件 存储 缓存
「事件驱动架构」技术架构师必看事件溯源,CQRS,流处理和Kafka之间的复杂关系
「事件驱动架构」技术架构师必看事件溯源,CQRS,流处理和Kafka之间的复杂关系
|
12月前
|
消息中间件 存储 缓存
「事件驱动架构」事件溯源,CQRS,流处理和Kafka之间的复杂关系
「事件驱动架构」事件溯源,CQRS,流处理和Kafka之间的复杂关系
|
12月前
|
uml
「业务架构」TOGAF建模:业务事件图
「业务架构」TOGAF建模:业务事件图
|
12月前
|
传感器 算法 数据挖掘
「事件架构」ESP和CEP有什么区别?
「事件架构」ESP和CEP有什么区别?
|
12月前
|
消息中间件 存储 缓存
「事件驱动架构」事件溯源,CQRS,流处理和Kafka之间的多角关系
「事件驱动架构」事件溯源,CQRS,流处理和Kafka之间的多角关系
「事件驱动架构」事件溯源,CQRS,流处理和Kafka之间的多角关系
|
12月前
|
存储 机器学习/深度学习 消息中间件
[事件驱动架构 ]事件驱动2.0 事件,存储和处理统一到一个平台
[事件驱动架构 ]事件驱动2.0 事件,存储和处理统一到一个平台
|
消息中间件 SQL 存储
RocketMQ 5.0 大手笔,拥抱云原生,支持流处理,高可用架构升级!
RocketMQ 5.0 大手笔,拥抱云原生,支持流处理,高可用架构升级!
291 0
RocketMQ 5.0 大手笔,拥抱云原生,支持流处理,高可用架构升级!