Kafka实战-实时日志统计流程 - 哥不是小萝莉

标签: kafka 实时 日志 | 发表时间:2015-06-16 18:20 | 作者:哥不是小萝莉
出处:

1.概述

  在《 Kafka实战-简单示例》一文中给大家介绍来Kafka的简单示例,演示了如何编写Kafka的代码去生产数据和消费数据,今天给大家介绍如何去整合一个完整的项目,本篇博客我打算为大家介绍Flume+Kafka+Storm的实时日志统计,由于涉及的内容较多,这里先给大家梳理一个项目的运用这些技术的流程。下面是今天的内容目录:

  • 项目流程
  • Flume
  • Kafka
  • Storm

  下面开始今天的内容分享。

2.项目流程

  在整合这套方案的时候,项目组也是经过一番讨论,在讨论中,观点很多,有人认为直接使用Storm进行实时处理,去掉Kafka环节;也有认为直接使用Kafka的API去消费,去掉Storm的消费环节等等,但是最终组内还是一致决定使用这套方案,原因有如下几点:

  • 业务模块化
  • 功能组件化

  我们认为,Kafka在整个环节中充当的职责应该单一,这项目的整个环节她就是一个中间件,下面用一个图来说明这个原因,如下图所示:

  整个项目流程如上图所示,这样划分使得各个业务模块化,功能更加的清晰明了。

  • Data Collection

  负责从各个节点上实时收集用户上报的日志数据,我们选用的是Apache的Flume NG来实现。

  • Data Access

  由于收集的数据的速度和数据处理的速度不一定是一致的,因此,这里添加了一个中间件来做处理,所使用的是Apache的Kafka,关于Kafka集群部署,大家可以参考我写的《 Kafka实战-Kafka Cluster》。另外,有一部分数据是流向HDFS分布式文件系统了的,方便于为离线统计业务提供数据源。

  • Stream Computing

  在收集到数据后,我们需要对这些数据做实时处理,所选用的是Apache的Storm。关于Storm的集群搭建部署博客后面补上,较为简单。

  • Data Output

  在使用Storm对数据做处理后,我们需要将处理后的结果做持久化,由于对相应速度要求较高,这里采用Redis+MySQL来做持久化。整个项目的流程架构图,如下图所示:

3.Flume

  Flume是一个分布式的、高可用的海量日志收集、聚合和传输日志收集系统,支持在日志系统中定制各类数据发送方(如:Kafka,HDFS等),便于收集数据。Flume提供了丰富的日志源收集类型,有:Console、RPC、Text、Tail、Syslog、Exec等数据源的收集,在我们的日志系统中目前我们所使用的是spooldir方式进行日志文件采集,配置内容信息如下所示:

producer.sources.s.type = spooldir
producer.sources.s.spoolDir = /home/hadoop/dir/logdfs

  当然,Flume的数据发送方类型也是多种类型的,有:Console、Text、HDFS、RPC等,这里我们系统所使用的是Kafka中间件来接收,配置内容如下所示:

producer.sinks.r.type = org.apache.flume.plugins.KafkaSink
producer.sinks.r.metadata.broker.list=dn1:9092,dn2:9092,dn3:9092
producer.sinks.r.partition.key=0
producer.sinks.r.partitioner.class=org.apache.flume.plugins.SinglePartition
producer.sinks.r.serializer.class=kafka.serializer.StringEncoder
producer.sinks.r.request.required.acks=0
producer.sinks.r.max.message.size=1000000
producer.sinks.r.producer.type=sync
producer.sinks.r.custom.encoding=UTF-8
producer.sinks.r.custom.topic.name=test

  关于,Flume的详细搭建部署,大家可以参考我写的《 高可用Hadoop平台-Flume NG实战图解篇》。这里就不多做赘述了。

4.Kafka

  Kafka是一种提供高吞吐量的分布式发布订阅消息系统,她的特性如下所示:

  • 通过磁盘数据结构提供消息的持久化,这种结构对于即使数据达到TB+级别的消息,存储也能够保持长时间的稳定。
  • 搞吞吐特性使得Kafka即使使用普通的机器硬件,也可以支持每秒数10W的消息。
  • 能够通过Kafka Cluster和Consumer Cluster来Partition消息。

  Kafka的目的是提供一个发布订阅解决方案,他可以处理Consumer网站中的所有流动数据,在网页浏览,搜索以及用户的一些行为,这些动作是较为关键的因素。这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。对于Hadoop这样的日志数据和离线计算系统,这样的方案是一个解决实时处理较好的一种方案。

  关于Kafka集群的搭建部署和使用,大家可以参考我写的:《 Kafka实战-Kafka Cluster》,这里就不多做赘述了。

5.Storm

  Twitter将Storm开源了,这是一个分布式的、容错的实时计算系统,已被贡献到Apache基金会,下载地址如下所示:

http://storm.apache.org/downloads.html
  Storm的主要特点如下:
  • 简单的编程模型。类似于MapReduce降低了并行批处理复杂性,Storm降低了进行实时处理的复杂性。
  • 可以使用各种编程语言。你可以在Storm之上使用各种编程语言。默认支持Clojure、Java、Ruby和Python。要增加对其他语言的支持,只需实现一个简单的Storm通信协议即可。
  • 容错性。Storm会管理工作进程和节点的故障。
  • 水平扩展。计算是在多个线程、进程和服务器之间并行进行的。
  • 可靠的消息处理。Storm保证每个消息至少能得到一次完整处理。任务失败时,它会负责从消息源重试消息。
  • 快速。系统的设计保证了消息能得到快速的处理,使用ØMQ作为其底层消息队列。
  • 本地模式。Storm有一个本地模式,可以在处理过程中完全模拟Storm集群。这让你可以快速进行开发和单元测试。
  Storm集群由一个主节点和多个工作节点组成。主节点运行了一个名为“Nimbus”的守护进程,用于分配代码、布置任务及故障检测。每个工作节 点都运行了一个名为“Supervisor”的守护进程,用于监听工作,开始并终止工作进程。Nimbus和Supervisor都能快速失败,而且是无 状态的,这样一来它们就变得十分健壮,两者的协调工作是由Apache的ZooKeeper来完成的。
  Storm的术语包括Stream、Spout、Bolt、Task、Worker、Stream Grouping和Topology。Stream是被处理的数据。Spout是数据源。Bolt处理数据。Task是运行于Spout或Bolt中的 线程。Worker是运行这些线程的进程。Stream Grouping规定了Bolt接收什么东西作为输入数据。数据可以随机分配(术语为Shuffle),或者根据字段值分配(术语为Fields),或者广播(术语为All),或者总是发给一个Task(术语为Global),也可以不关心该数据(术语为None),或者由自定义逻辑来决定(术语为 Direct)。Topology是由Stream Grouping连接起来的Spout和Bolt节点网络。在Storm Concepts页面里对这些术语有更详细的描述。
  关于Storm集群的搭建部署,博客在下一篇中更新,到时候会将更新地址附在这里,这里就先不对Storm集群的搭建部署做过多的赘述了。

6.总结

  这里就是为大家介绍的Flume+Kafka+Storm的整体流程,后续会给大家用一个项目案例来实践演示这个流程,包括具体的各个模块的编码实践。今天大家可以先熟悉下实时计算项目的流程开发。

7.结束语

  这篇博客就和大家分享到这里,如果大家在研究学习的过程当中有什么问题,可以加群进行讨论或发送邮件给我,我会尽我所能为您解答,与君共勉!

本文链接: Kafka实战-实时日志统计流程,转载请注明。

相关 [kafka 实时 日志] 推荐:

日志实时收集之FileBeat+Kafka

- - lxw的大数据田地
之前,我们的某一个业务用于实时日志收集处理的架构大概是这样的:. 在日志的产生端(LogServer服务器),都部署了FlumeAgent,实时监控产生的日志,然后发送至Kafka. 经过观察,每一个FlumeAgent都占用了较大的系统资源(至少会占用一颗CPU 50%以上的资源). 而另外一个业务,LogServer压力大,CPU资源尤其紧张,如果要实时收集分析日志,那么就需要一个更轻量级、占用资源更少的日志收集框架,于是我试用了一下Filebeat.

使用Flume+Kafka+SparkStreaming进行实时日志分析

- - CSDN博客推荐文章
每个公司想要进行数据分析或数据挖掘,收集日志、ETL都是第一步的,今天就讲一下如何实时地(准实时,每分钟分析一次)收集日志,处理日志,把处理后的记录存入Hive中,并附上完整实战代码. 思考一下,正常情况下我们会如何收集并分析日志呢. 首先,业务日志会通过Nginx(或者其他方式,我们是使用Nginx写入日志)每分钟写入到磁盘中,现在我们想要使用Spark分析日志,就需要先将磁盘中的文件上传到HDFS上,然后Spark处理,最后存入Hive表中,如图所示:.

Kafka实战-实时日志统计流程 - 哥不是小萝莉

- - 博客园_首页
  在《 Kafka实战-简单示例》一文中给大家介绍来Kafka的简单示例,演示了如何编写Kafka的代码去生产数据和消费数据,今天给大家介绍如何去整合一个完整的项目,本篇博客我打算为大家介绍Flume+Kafka+Storm的实时日志统计,由于涉及的内容较多,这里先给大家梳理一个项目的运用这些技术的流程.

使用Flume+Kafka+SparkStreaming进行实时日志分析 - Trigl的博客 - CSDN博客

- -

开源日志系统简介——Scribe,flume,kafka,Chukwa

- - 互联网 - ITeye博客
许多公司的平台每天会产生大量的日志(一般为流式数据,如,搜索引擎的pv,查询等),处理这些日志需要特定的日志系统,一般而言,这些系统需要具有以下特征:. (1) 构建应用系统和分析系统的桥梁,并将它们之间的关联解耦;. (2) 支持近实时的在线分析系统和类似于Hadoop之类的离线分析系统;. 即:当数据量增加时,可以通过增加节点进行水平扩展.

Flume + kafka + HDFS构建日志采集系统

- - 企业架构 - ITeye博客
    Flume是一个非常优秀日志采集组件,类似于logstash,我们通常将Flume作为agent部署在application server上,用于收集本地的日志文件,并将日志转存到HDFS、kafka等数据平台中;关于Flume的原理和特性,我们稍后详解,本文只简述如何构建使用Flume + kafka + HDFS构建一套日志采集系统.

日志收集:ETL,ELK以及Kafka/Redis - S.Mona

- -
其实一直都想写ELK的,毕竟在公司做了一年的日志ETL的工作,而且经历了上个世纪遗留的日志收集方案到现在流行的日志收集方案的变更,但是一直都没有找到合适的时间和机会写这一篇文章,趁着寒冬需求量下降没有那么忙碌就做了. ELK是Elastic公司的产品,elastic公司最远近闻名的就是他的ElasticSearch,这也是ELK中的’E’,其他’L’和’K’,分别是指Logstash以及Kibana.

Kafka日志及Topic数据清理 - moonandstar08 - 博客园

- -
  由于项目原因,最近经常碰到Kafka消息队列拥堵的情况. 碰到这种情况为了不影响在线系统的正常使用,需要大家手动的清理Kafka Log. 但是清理Kafka Log又不能单纯的去删除中间环节产生的日志,中间关联的很多东西需要手动同时去清理,否则可能会导致删除后客户端无法消费的情况.   在介绍手动删除操作之前,先简单的介绍一下Kafka消费Offset原理.

SpringBoot+Kafka+ELK 完成海量日志收集(超详细)

- - 掘金 架构
来源:jiandansuifeng.blog.csdn.net/article/details/107361190. 在这先列出各服务器节点,方便同学们在下文中对照节点查看相应内容. SpringBoot项目准备. 引入log4j2替换SpringBoot默认log,demo项目结构如下:. 测试Controller,用以打印日志进行调试.

实时流计算、Spark Streaming、Kafka、Redis、Exactly-once、实时去重

- - lxw的大数据田地
本文想记录和表达的东西挺多的,一时想不到什么好的标题,所以就用上面的关键字作为标题了. 在实时流式计算中,最重要的是在任何情况下,消息不重复、不丢失,即Exactly-once. 本文以Kafka–>Spark Streaming–>Redis为例,一方面说明一下如何做到Exactly-once,另一方面说明一下我是如何计算实时去重指标的.