第四章流数据管理系统.PDFVIP

第四章 流数据管理系统 4.1 概述 早在本世纪初，学术界针对数据流的处理已经开展了相关的研究工作，推出了早期的数 据流管理系统Aurora ，Borealis 和 STREAM 等。如今，为满足处理流式大数据的实时性、 负载均衡和容错处理等需求，学术界和工业界相继推出了Storm，S4，Puma 和Samza 等流 数据管理系统。 针对流数据的实时处理流程往往包含三个阶段：数据实时采集阶段、数据实时计算阶段 和数据持久化存储阶段。其中，数据采集阶段包含多种数据收集方式，包括使用消息队列 （RabbitMQ 等），或直接通过网络 Socket 传输数据，或利用前端业务系统专有的数据采集 API 等等。 本节首先针对数据采集较为通用的方案—消息队列进行系统介绍，然后将重点对Storm， S4，Puma 和Samza 系统进行对比分析和详细说明。 4.2 消息队列 通信领域中的电话记录数据流、Web 上的用户点击数据流、网络监测中的数据包流、 各类传感器网络中的监测数据流、金融领域的证券数据流、卫星传回的图像数据流以及零售 业务中的交易数据流等形成了一种与传统数据库中静态数据不同的数据形态。 在传统静态数据集的处理过程中，往往借助一些数据导入工具把待处理的数据集批量导 入到数据处理系统中，或以数据库文件的形式，或导入到分布式文件系统中（如：HDFS） 等。在流数据的产生和采集过程中，数据源的实时性和持续性给数据采集工作带来了很大的 挑战。首先在功能上，要保证可以完整地收集到所有数据，为实时应用提供实时数据；其次 在响应时间上，需要保证实时性、低延迟；另外，还要求系统配置简单、部署容易，稳定可 靠等。目前较为流行的产品包括：Facebook 的Scribe[1]、LinkedIn 的Kafka[2]、Cloudera 的 Flume[3]，Hadoop 的Chukwa[4]等，均可以满足每秒数百MB 的日志数据采集和传输需求。 Apache Flume 是Cloudera 于2009 年7 月发布的一个分布式的、可靠的、高可用的海量 日志聚合系统，支持在系统中定制各类数据发送方，用于收集数据，把数据集中到一个中心 化的存储中。Scribe 是Facebook 开源的日志收集系统，在Facebook 内部已经得到大量的应 用。它能够从各种日志源上收集日志，存储到一个中央存储系统 （可以是NFS，分布式文 件系统等）上，以便于进行集中统计分析处理。它为日志的“分布式收集，统一处理”提供 了一个可扩展的，高容错的方案。Sqoop[5]是Apache 下用于RDBMS 和HDFS 互相导数据的 工具。Chukwa 是Apache 的开源项目，由于其属于Hadoop 系列产品，因而使用了很多Hadoop 的组件（用HDFS 存储，用MapReduce 处理数据），它提供了很多模块以支持Hadoop 集群 日志分析。本节将详细介绍RabbitMQ、Kafka 和SpringXD 。 4.2.1 RabbitMQ RabbitMQ[6]是流行的开源消息队列系统，用 erlang 语言开发，是AMQP （高级消息队 列协议）的标准实现。最初起源于金融系统，用于在分布式系统中存储转发消息，在易用性、 扩展性、高可用性等方面表现不俗。消息中间件主要用于组件之间的解耦，消息的发送者无 需知道消息使用者的存在，反之亦然。 RabbitMQ 1.0.0-alpha 版本于2007 年由Rabbit 科技有限公司发布并提供商业支持。起初， Rabbit 科技是 LSHIFT 和 CohesiveFT 在 2007 年成立的合资企业，该公司于 2010 年 4 月被 VMware 公司旗下的SpringSource 部门收购，并在2013 年5 月被并入Pivotal。 30 图4.1 RabbitMQ 系统架构图 RabbitMQ 的系统架构如图4.1 所示，主要包括四个核心组件：  生产者（Producer ）：负责产生、发送消息的角色。  消费者（Consumer ）：负责接收、处理消息的角色。  队列（Queue ） 队列是RabbitMQ 内部对象，用于存储消息。队列的属