程序员消息队列MQ（Kafka&RabbitMQ）

Streaming流式数据处理将统治世界，是真的！

2018-06-15  本文已影响13人  pstrike

在数据处理领域，Streaming流式数据处理被越来越多的提及到，很多报道都提到Streaming将取代传统数据仓库(Data Warehouse)、数据湖(Data Lake)成为下一代数据处理的主要方式。针对流式数据处理方式出现的背景、特点、应用，本文基于Gwen Shapira在Goto论坛以及Neha Narkhede在InfoQ论坛的演讲内容进行了整理，希望能帮助让读者快速的了解流式数据处理。

传统的数据处理

在传统的数据处理方式中，主要通过数据库以及数据仓库这两种方式对数据进行储存的。数据库主要储存业务、操作数据，这些数据周期性（每天）的会被ETL(Extract, Tranform, Load)工具导入数据仓库。由于数据库和数据仓库的数据结构可能并不一致，在数据导入数据仓库之前，可能需要进行额外的数据集成工作。在完成了ETL后，储存在数据仓库内的结构化数据将支持BI等数据分析服务进行业务分析、报表等。

上述数据处理的方式以数据仓库、ETL为主。虽然数据仓库以及ETL已经出现多年，但是从实际的应用情况来看，数据仓库的数据覆盖率的普遍比较低。这个问题的主要原因：

由于ETL的实时性差，为了实现数据处理的实时性，后来出现了EAI (Enterprise Application Integration)方式。EAI方式主要基于ESB (Enterprise Service Bus)或者MQ来实现不同应用间的数据交换。EAI方式可以有效的处理小规模数据，但是无法对于大规模的数据（例如：日志、传感设备数据）进行有效的处理，例如：ESB容易因为单点故障而导致数据处理系统整体失效。

新的挑战

随着IT技术的发展、业务模式的不断演进，传统的数据处理模式也面临着新的挑战：

如果把上述挑战简化为对实时性以及伸缩性的需求，我们可以把传统的ETL以及EAI方式放在以下象限中。很显然，为了满足新的数据处理需求，我们需要一种数据处理方式即可以满足实时处理的需求，又可以进行有效的伸缩。

流式数据处理

在上述背景中，流式数据处理的方式被提出。其定位就是提供一种数据处理方式兼具数据处理实时性以及伸缩性。

流式数据处理对数据进行抽取、转换、储存等处理，向数据消费者提供唯一准确的数据；通过实时的、可伸缩的消息总线像神经中枢一样协调各系统进行交互。

流式数据处理有以下几个特点：

通过事件驱动，可以有效的解耦消息发布者(Publisher)以及消息消费者(Consumer)之间的强关联关系。如下图所示，Web App和Hapdoop间并不直接进行交互，而是通过Streaming Pltform进行解耦。

解耦的优势在上图中不容易被发现，但是在有多个消息发布者以及多个消息消费者的情况，通过流式数据作为处理中枢，可以避免重复建立系统间点到点的连接，简化错综复杂的依赖关系。例如：当有新的系统需要向hadoop导入数据，该系统只须发布事件，hadoop、其它数据消费者通过订阅即可获得数据，而不需与各系统间建立连接。

我们通过一个例子来进行解释。假设我们在运营一个电商系统，我们需要将商品的数据加载进数据仓库以生成相应的业务报表，但是在数据加载至数据仓库之前，我们需要将商品数据中的一些敏感信息清除掉。通过传统的ETL方式，通过“E”从数据源读取数据，通过“T”对数据进行清洗、消除敏感数据，通过“L”加载至数据仓库。

假设我们希望通过Cassandra为商品搭建推荐系统，那么我们需要重复上述的ETL过程为Cassandra加载数据。也就是说，同样的数据被重复执行了2次“E”以及2次“T”，由此产生了不必要的、大量的计算资源浪费。

流式数据处理可以有效的解决这个问题。流式数据处理只需要执行1次“E“，并将数据存放在数据队列中，数据的消费者只需要询问队列获得数据即可，而不需要反复地执行“E”。另一方面，在将数据存放在队列时，流式数据处理可以对数据进行消除敏感数据的操作，即“T“，数据消费者不需要再重复执行。

通过上例子，流式数据处理可以在数据消费者获取数据前，完成数据的ET处理。另外，基于不同的业务需求，数据消费者在“L”的过程中，可以对数据进行加工，从而使得数据可以适配不同的业务需求。

总结

流式数据处理解决了传统数据处理过程无法实现实时数据处理以及对大规模、异构数据支持不足的问题，通过事件驱动的方式，搭建消息中枢，连接各系统实现系统间数据的交互。

参考文献

pstrike 2018.06.15 于广州天河

【尊重版权：转载之前请先联系我】

上一篇下一篇

猜你喜欢

热点阅读