Flume+Kafka+Spark Streaming实现大数据实时流式数据采集

近年来，随着企业信息化建设的飞速发展，大数据应用的问题越来越备受关注。很多企业投入大量的人力、物力和财力建设企业大数据平台，平台建设工作涵盖数据采集、数据处理、数据存储、数据服务、数据展示以及数据质量管理各个环节。而数据采集作为企业大数据平台建设的首要环节，是企业大数据平台建设的根本所在，如果数据采集环节技术体系架构可靠性不高、稳定性不强且不易扩展，企业大数据平台建设就失去了意义。尤其是面对数据量大、来源分散、格式多样化的实时数据采集，如何搭建稳定、可靠且易扩展的技术体系架构，以实现快速、高效收集数据源产生的实时数据，满足在业务应用上能够及时响应、在数据分析和处理上能够及时完成，是企业大数据平台建设重中之重。

那么，企业大数据平台的实时数据采集架构实现过程中，应该选型哪一种技术更合适呢？仁者见仁、智者见智，并不是一种解决方案适合所有的应用场景。本文仅针对户用光伏发电领域生产运行数据实时采集进行设计和考虑，提出一种基于Flume、Kafka和Storm实现企业大数据平台的实时数据采集解决方案。

我们先了解一下户用光伏发电实时数据主要来源及基本构成。户用光伏发电实时数据来源于光伏发电设备，光伏发电设备是指安装在家庭、园区或商业大楼屋顶的关口表、逆变器、光伏组串等，通过传感器采集光伏设备运行实时数据，数据包括发电量、功率、电压、电流等。在业务需求上分析，运维人员需要实时监控设备运行状态，一旦出现问题，立即安排人员检修和维护；运维管理人员通过分析历史数据反映出来的特征，安排定期检修和维护工作；另外，发电量和用电量等数据要及时反馈给用户，以便其了解收益情况。

在户用光伏发电数据采集体系架构的技术选型上优先选用开源技术，便于后续扩展和维护。实时采集选用Flume技术、消息队列选Kafka技术，在线实时处理选用Storm技术、关系型数据库选用MySQL、实时内存数据库选用Redis、历史大数据存储选用MongoDB。数据采集系统体系结构如下图所示：

技术体系架构

Flume是一个分布式、高可靠和高可用的数据采集采集系统。针对不同数据源、不同结构的海量数据进行高效收集、聚合和传输，具备良好的扩展性、伸缩性和容错性。Flume是由一系列的称为Agent的组件构成，每一个Agent内部包含三个组件，分别是Source、Channel、Sink。Flume的每个组件是可插拔、可定制的，其本质上是一个中间件，有效屏蔽了数据源与目标源之间的异构性，便于系统的扩展和升级。Source可定制开发从外部系统或Agent接收数据，并写入一个或多个Channel；Channel是一个缓冲区，缓冲Source写入的数据，知道Sink发送出去；Sink负责从Channel中读取数据，并发送给消息队列或存储系统，甚至于是另一个Agent。

在本文设计的体系架构中，针对不同通讯协议或者不同数据量级的户用光伏发电设备运行数据（电量、功率、电压、电流等），定制开发一个Agent，在Agent内部采用Memory Channel缓存，以提升性能，采用Kafka Sink将Channel中的数据写入Kafka。

在实际应用中，不同数据源（数据生产者）产生的实时数据，例如关口表电量、逆变器功率等，需要经过不同的系统进行逻辑和业务处理，例如电量、功率要同时被写入历史数据库和Storm集群（数据消费者）进行离线大数据分析和在线实时分析。因此，本文设计的体系架构中，采用Kafka作为消息缓冲区，Kafka提供了高容错性和可扩展性，允许可靠地缓存更多的实时数据，以便于多个消费者重复读取。

Storm是为在线实时处理提供便利，实时采集的电量、功率、电压、电流等数据，在Storm中实现模型化处理、简单的统计分析、数据存储等功能。Storm会根据实际业务应用的要求，将数据存储在实时内存数据库Redis、关系型数据库MySQL、历史大数据库MongoDB等系统。

Kafka和Storm由Zookeeper集群化管理，这样即使Kafka宕机重启后也能找到上次的消费记录，接着从上次宕机点继续从Kafka的Broker中进行消费。但是由于存在先消费后记录日志或者先记录后消费的非原子操作，如果出现刚好消费完一条消息并还没将信息记录到Zookeeper的时候就宕机的类似问题，或多或少都会存在少量数据丢失或重复消费的问题， 其中一个解决方案就是Kafka的Broker和Zookeeper都部署在同一台机子上。接下来就是使用用户定义好的Storm Topology去进行数据的分析并输出到Redis缓存数据库中(也可以进行持久化)。

之所以在Flume和Storm中间加入一层Kafka消息系统，就是因为在高并发的条件下， 数据会井喷式增长，如果Storm的消费速度(Storm的实时计算能力那是最快之一，但是也有例外， 而且据说现在Twitter的开源实时计算框架Heron比Storm还要快)慢于数据的产生速度，加上Flume自身的局限性，必然会导致大量数据滞后并丢失，所以加了Kafka消息系统作为数据缓冲区，而且Kafka是基于log File的消息系统，也就是说消息能够持久化在硬盘中，再加上其充分利用Linux的I/O特性，提供了可观的吞吐量。架构中使用Redis作为数据库也是因为在实时的环境下，Redis具有很高的读写速度。

结束语：基于Flume、Kafka和Storm实现企业大数据平台的实时数据采集解决方案，全部选择开源技术搭建，具备高可靠性、易扩展性和稳定性。