大数据分析-第三章第二节kafka.docVIP

Kafka 3.2.1kafka概述 Kafka是一个分布式，基于发布-订阅模式的消息系统，最初由LinkedIn公司开发设计，使用Scala编写。最突出的特性有：高吞吐量、可水平拓展、异步通信及可靠性。最初用于LinkedIn公司作为活动流和运营数据处理管道的基础，现在已被多家公司作为数据管道或消息系统使用。越来越多开源分布式处理系统都支持与kafka集成。主流应用架构中，由kafka作为前端消息系统，Spark Streaming作为后端流引擎从而组成流引擎处理架构。 活动流数据是所有站点在对其网站使用情况做报表时要用到的数据中最常规的部分。活动数据包括页面访问量（page view）、被查看内容方面的信息以及搜索情况等内容。这种数据通常的处理方式是先把各种活动以日志的形式写入某种文件，然后周期性地对这些文件进行统计分析。运营数据指的是服务器的性能数据（CPU、IO使用率、请求时间、服务日志等等数据)。运营数据的统计方法种类繁多。 近年来，活动和运营数据处理已经成为了网站软件产品特性中一个至关重要的组成部分，这就需要一套稍微更加复杂的基础设施对其提供支持。 3.2.2kafka工作原理 在上节通过对kafka简单的了解后，本节我们主要介绍kafka的工作原理。 Kafka提供了一个普通消息系统的功能，但同时又具有自己独特的设计。 学习kafka，首先我们要知道以下基本知识： kafka将消息以topic为单位进行归纳 将向kafka topic发布消息的程序称为producers 将预定topic并消费信息的程序称为consumers Kafka以集群的方式运行，可以有一个或多个服务器组成，每个服务器称为一个broker 因此基本工作流程就是：Producers通过网络将信息发送至kafka集群，再由集群将信息发送给Consumers，如下图所示： 我们首先看一个例子，如下图所示是kafka所在LinkedIn中部署后形成的各系统的拓扑结构。 要注意的是，一个单个的Kafka集群系统用于处理来自各种不同来源的所有活动数据。它同时为在线和离线的数据使用者提供了一个单个的数据管道，在线活动和异步处理之间形成了一个缓冲区层。我们还使用kafka，把所有数据复制（replicate）到另外一个不同的数据中心去做离线处理。 我们并不想让一个单个的Kafka集群系统跨越多个数据中心，而是想让Kafka支持多数据中心的数据流拓扑结构。这是通过在集群之间进行镜像或“同步”实现的。这个功能非常简单，镜像集群只是作为源集群的数据使用者的角色运行。这意味着，一个单个的集群就能够将来自多个数据中心的数据集中到一个位置。下面所示是可用于支持批量装载（batch loads）的多数据中心拓扑结构的一个例子： 每一个分区都由一系列有序、不可变的消息组成，这些消息被连续的追加到分区中。分区中的每个消息都有一个连续的序列号，我们称之为offset，用来在分区内唯一地标识这条消息。 在一个可配置的时间段内，Kafka集群保留所有发布的消息，不管这些消息有没有被消费。比如，如果消息的保存策略被设置为2天，那么在一个消息被发布的两天时间内，它都是可以被消费的。之后它将被丢弃以释放空间。Kafka的性能是和数据量无关的常量级的，所以保留太多的数据并不是问题。 实际上每个consumer唯一需要维护的数据是消息在日志中的位置，也就是offset.这个offset有consumer来维护：一般情况下随着consumer不断的读取消息，这offset的值不断增加，但其实consumer可以以任意的顺序读取消息，比如它可以将offset设置成为一个旧的值来重读之前的消息。 以上特点的结合，使Kafka 中的consumers非常的轻量级：它们可以在不对集群和其他consumer造成影响的情况下读取消息。你可以使用命令行来tail消息而不会对其他正在消费消息的consumer造成影响。 将日志分区可以达到以下目的：首先这使得每个日志的数量不会太大，可以在单个服务上保存。另外每个分区可以单独发布和消费，为并发操作topic提供了一种可能。 Distribution 每个分区在Kafka集群的若干服务中都有副本，这样这些持有副本的服务可以共同处理数据和请求，副本数量是可以配置的。副本使Kafka具备了容错能力。 每个分区都由一个服务器作为“leader”，零或若干服务器作为“followers”,leader负责处理消息的读和写，followers则去复制leader.如果leader down了，followers中的一台则会自动成为leader。集群中的每个服务都会同时扮演两个角色：作为它所持有的一部分分区的leader，同时作为其他分区的followers，这样集群