flume-ng+Kafka+Storm+HDFS 实时系统搭建

  categories:mq, 资料  tags:  author:

一直以来都想接触Storm实时计算这块的东西,最近在群里看到上海一哥们罗宝写的Flume+Kafka+Storm的实时日志流系统的搭建文档,自己也跟着整了一遍,之前罗宝的文章中有一些要注意点没提到的,以后一些写错的点,在这边我会做修正;内容应该说绝大部分引用罗宝的文章的,这里要谢谢罗宝兄弟,还有写这篇文章@晨色星空J2EE也给了我很大帮助,这里也谢谢@晨色星空J2EE

之前在弄这个的时候,跟群里的一些人讨论过,有的人说,直接用storm不就可以做实时处理了,用不着那么麻烦;其实不然,做软件开发的都知道模块化思想,这样设计的原因有两方面:

一方面是可以模块化,功能划分更加清晰,从“数据采集–数据接入–流失计算–数据输出/存储”

1).数据采集

负责从各节点上实时采集数据,选用cloudera的flume来实现

2).数据接入

由于采集数据的速度和数据处理的速度不一定同步,因此添加一个消息中间件来作为缓冲,选用apache的kafka

3).流式计算

对采集到的数据进行实时分析,选用apache的storm

4).数据输出

对分析后的结果持久化,暂定用mysql

另一方面是模块化之后,加入当Storm挂掉了之后,数据采集和数据接入还是继续在跑着,数据不会丢失,storm起来之后可以继续进行流式计算;

那么接下来我们来看下整体的架构图

详细介绍各个组件及安装配置:

操作系统:ubuntu

Flume

Flume是Cloudera提供的一个分布式、可靠、和高可用的海量日志采集、聚合和传输的日志收集系统,支持在日志系统中定制各类数据发送方,用于收集数据;同时,Flume提供对数据进行简单处理,并写到各种数据接受方(可定制)的能力。

下图为flume典型的体系结构:

Flume数据源以及输出方式:

Flume提供了从console(控制台)、RPC(Thrift-RPC)、text(文件)、tail(UNIX tail)、syslog(syslog日志系统,支持TCP和UDP等2种模式),exec(命令执行)等数据源上收集数据的能力,在我们的系统中目前使用exec方式进行日志采集。

Flume的数据接受方,可以是console(控制台)、text(文件)、dfs(HDFS文件)、RPC(Thrift-RPC)和syslogTCP(TCP syslog日志系统)等。在我们系统中由kafka来接收。

Flume下载及文档:

http://flume.apache.org/

Flume安装:

  1. $tar zxvf apache-flume-1.4.0-bin.tar.gz/usr/local

Flume启动命令:

  1. $bin/flume-ng agent –conf conf –conf-file conf/flume-conf.properties –name producer -Dflume.root.logger=INFO,console

Kafka… 阅读全文

Kafka简介

  categories:mq, 资料  tags:, ,   author:

1. 引言

互联网够公司的日志无处不在,web日志,js日志,搜索日志,监控日志等等。对于这些日志的离线分析 (Hadoop),wget&rsync虽然人力维护成本较高,但可以满足功能行需求。但对于这些日志的实时分析需求(例如实时推荐,监控系 统),则往往必须要引入一些“高大上”的系统。

传统的企业消息系统(例如WebSphere)并不是非常适合大规模的日志处理系统,理由如下:
1) 过于关注可靠性,这些可靠性增加了系统实现&API的复杂度,而在日志处理过程中,丢失几条日志常常“无伤大雅”
2) 包括API,scale及消息缓冲的设计理念都不适合Hign Throughput的日志处理系统

针对这些问题,近些年各个公司都做了一些自己的日志收集系统,例如:Facebook的Scribe、Yahoo的data highway,Cloudera的Flume,Apache的Chukwa,百度的BigPipe,阿里的RocketMQ。

Kafka是LinkedIn开发并开源出来的一个高吞吐的分布式消息系统。其具有以下特点:
1) 支持高Throughput的应用
2)  scale out:无需停机即可扩展机器
3) 持久化:通过将数据持久化到硬盘以及replication防止数据丢失
4) 支持online和offline的场景。

2. 介绍

kafka使用scala开发,支持多语言客户端(c++、java、python、go等)其架构如下[2]:

Producer:消息发布者
Broker:消息中间件处理结点,一个kafka节点就是一个broker
Consumer:消息订阅者

kafka的消息分几个层次:
1) Topic:一类消息,例如page view日志,click日志等都可以以topic的形式存在,kafka集群能够同时负责多个topic的分发
2) Partition: Topic物理上的分组,一个topic可以分为多个partition,每个partition是一个有序的队列。partition中的每条消息都会被分配一个有序的id(offset)。
3) Message:消息,最小订阅单元

具体流程:
1. … 阅读全文

kafka入门

  categories:mq  tags:, ,   author:
一、kafka入门
    1、简介
    Kafka is a distributed,partitioned,replicated commit logservice。它提供了类似于JMS的特性,但是在设计实现上完全不同,此外它并不是JMS规范的实现。kafka对消息保存时根据Topic进行归类,发送消息者成为Producer,消息接受者成为Consumer,此外kafka集群有多个kafka实例组成,每个实例(server)成为broker。无论是kafka集群,还是producer和consumer都依赖于zookeeper来保证系统可用性集群保存一些meta信息。
<ignore_js_op>
   2、Topics/logs
    一个Topic可以认为是一类消息,每个topic将被分成多个partition(区),每个partition在存储层面是append log文件。任何发布到此partition的消息都会被直接追加到log文件的尾部,每条消息在文件中的位置称为offset(偏移量),offset 为一个long型数字,它是唯一标记一条消息。它唯一的标记一条消息。kafka并没有提供其他额外的索引机制来存储offset,因为在kafka中几 乎不允许对消息进行“随机读写”。

 

<ignore_js_op>

 

    kafka和JMS(Java Message Service)实现(activeMQ)不同的是:即使消息被消费,消息仍然不会被立即删除.日志文件将会根据broker中的配置要求,保留一定的时 间之后删除;比如log文件保留2天,那么两天后,文件会被清除,无论其中的消息是否被消费.kafka通过这种简单的手段,来释放磁盘空间,以及减少消 息消费之后对文件内容改动的磁盘IO开支.
    对于consumer而言,它需要保存消费消息的offset,对于offset的保存和使用,有consumer来控制;当consumer正常消费消 息时,offset将会”线性”的向前驱动,即消息将依次顺序被消费.事实上consumer可以使用任意顺序消费消息,它只需要将offset重置为任 意值..(offset将会保存在zookeeper中,参见下文)
    kafka集群几乎不需要维护任何consumer和producer状态信息,这些信息有zookeeper保存;因此producer和consumer的客户端实现非常轻量级,它们可以随意离开,而不会对集群造成额外的影响.
    partitions的设计目的有多个.最根本原因是kafka基于文件存储.通过分区,可以将日志内容分散到多个server上, 来避免文件尺寸达到单机磁盘的上限,每个partiton都会被当前server(kafka实例)保存;可以将一个topic切分多任意多个 partitions,来消息保存/消费的效率.此外越多的partitions意味着可以容纳更多的consumer,有效提升并发消费的能力.(具体 原理参见下文).
    3、Distribution
    一个Topic的多个partitions,被分布在kafka集群中的多个server上;每个server(kafka实例)负责 partitions中消息的读写操作;此外kafka还可以配置partitions需要备份的个数(replicas),每个partition将会 被备份到多台机器上,以提高可用性.
    基于replicated方案,那么就意味着需要对多个备份进行调度;每个partition都有一个
阅读全文



快乐成长 每天进步一点点      京ICP备18032580号-1