Kafka实战－实时日志统计流程

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.结束语

　　这篇博客就和你们分享到这里，若是你们在研究学习的过程中有什么问题，能够加群进行讨论或发送邮件给我，我会尽我所能为您解答，与君共勉！