页面树结构

2017-11-09 ApacheCN 开源组织,第二期邀请成员活动,一起走的更远 : http://www.apachecn.org/member/209.html


MachineLearning 优酷地址 : http://i.youku.com/apachecn

转至元数据结尾
转至元数据起始

当以正确方式的打开并且用正确的姿势使用的情况下,Kafka其独特的属性,使它成为一个极具吸引力的数据集成选择。

Apache Kafka 最近造成了很大反响。作为Kafka的创建者LinkedLn,是最广为人知的用户。还有很多公司也在用Kafka。

那么对于Kafka大家都想知道些什么:它是做什么的?为什么每个人都想使用它吗?它比现有的解决方案好在哪里?是否有足够的理由替换现有的系统和架构?

在这篇文章中,我们试图回答这些问题。我们首先简要介绍Kafka,然后通过一些应用场景Kafka的一些独特功能。我们还将讨论一些额外用例来对Kafka和现有方案进行对比。

什么是Kafka

Kafka是一个操作起来非常简单的系统, 但当你深入的时候会发现难以置信的技术细节。Kafka文档很好的解释了许多设计和实现系统中的微妙之处,我们不会在本文中把他们都说一遍。总之,Kafka是一个快速、可伸缩、耐用的分布式发布和订阅消息系统。

同很多消息系统一样,Kafka把信息存储在topic中。生产者(Producer)将数据写入topic然后消费者(Consumer)从topic中读取。因为Kafka是分布式系统,topic可以跨节点分区和复制。

消息均为字节数组,开发者可以把他们存储成任意对象及格式,比如String,Json几Avro这些常用格式。也可以给每个消息添加key,这样producer可以确保同样key的所有信息可以存储到同一个分区上。从一个topic消费的时候,可以将多个consumer建立成一个消费组。消费组中的每个consumer将读取他们订阅的topic分区的一个子集。也就是说每个消息会被传送给祖中的一个consumer,包含同样key的所有消息会被传送到同一个consumer中。

Kafka独特的地方就是把每个topic 分区当成log(一个排序了的消息集)。分区中的每个消息被分配一个独一无二的位置。Kafka不会追踪哪些被consumer读取的消息,只保留未读消息;相反Kafka保留所有消息集的时间,和Consumer负责追踪他们在每个日志的位置。因此Kafka可以用极小的开销支持大量的consumer并保留大量数据。

接下来让我们看看Kafka独特的属性是如何应用于特定用例的。

Kafka at Work

假设我们在开发一个大型多人在线游戏。在这些游戏中,玩家在一个虚拟世界中相互合作和竞争。通常玩家会互相交易,交换游戏物品和钱,所以游戏开发者有个很重要的任务就是确保玩家不会被欺骗。如果一个玩家交易记录明显大于一般玩家或者玩家登陆的IP与近20次游戏的IP不同,就会被标记。除了实时标记,我们也想把数据存放到Hadoop,这样我们的数据科学家可以训练并测试新算法。

对于实时事件标记而言,如果我们可以把数据缓存到游戏服务器内存,并快速决策(至少大部分是这样)是最好的。我们系统有多个游戏服务器和数据集,并将他们过去20次登陆和20次交易信息记录在内存中。

我们的游戏服务器执行两个角色:第一个接受并传送用户动作,第二个处理交易信息,并实时标记特定日志。要使第二个操作高效,就得把所有用户交易历史事件存放在一个服务器的内存中。这意味着如果某个服务器没有用户的历史交易信息,我们就要在服务器之间传送消息。为了保持角色的松耦合(loosely coupled),我们使用Kafka在服务期间传递信息,如下:

Kafka的几个特性使之非常适合我们的需求:可伸缩性、数据分区,低延迟,并且能够处理大量不同的consumer。我们已经配置了Kafka的一个topic,用来传递登陆和交易信息。我们之所以需要一个topic是确保我们获取登陆信息后在拿到交易信息(我们可以确认玩家平时登录IP)。Kafka只维护单个topic的消息顺序,但是不维护多个。

当用户登陆或交易,服务器(accepting server)会立刻发送一个信息给Kafka。我们把user id当成key,事件为值。这样可以确保同一个用户的所有交易和登陆信息都会存放在同一个Kafka分区。每个事件处理服务器都运行一个Kafka Consumer,他们都属于同一个组。这样每个服务器读取几个Kafka分区,然后所有关于同一个用户的数据都会前往同一个日志处理服务器(可能来自不同的accepting server)。当日志处理服务器从Kafka读取用户交易记录,它会添加时间到用户历史事件,并且缓存到内存中。然后它可以通过本地缓存读取用户历史事件,并标记可以事件,没有额外的网络或磁盘开销。

kafka-usecase

有一点要注意,每个事件处理服务器我们都创建了一个分区或者多线程处理的时候每个内核创建一个。(记住,Kafka群集大多在所有topic不超过10,000个分区环境中做的测试,所以我们没有为每个用户创建分区)

将一个事件从一个游戏服务器传到Kafka,又从另外一个游戏服务器读取,然后在处理它。这种方案看起来有点绕路。不过这样设计对这两个role进行了去耦并且我们允许我们对每个role进行管理。此外这种方法不会增加过的增加处理时间,因为Kafka就是为高吞吐量和低延迟设计的。即使很小的三节点群集也可以处理近一百万日志每秒,平均延迟3毫秒。

当一个事件被标记为可疑时,它会发送至新的Kafka topic。然后报警服务器和仪表盘可以读取它。与此同时一个单独的进行读取时间和警报topic并写入到Hadoop进行进一步分析。

因为Kafka不跟踪确认消息,它可以处理数千万的consumer,性能影响却很小。Kafka亦可批量处理consumer ,每小时处理所有的新消息,不影响系统吞吐量和延迟。

附加用例

我们展示了简单的例子,Kafka也可以像传统消息处理系统一样把事件摄取到Hadoop

这里有一些常见用途:

  • 网站跟踪(Website activity tracking): Web应用程序发送事件,如页面浏览以及搜索至kafka。他们可以用于实时处理,仪表展示或者在Hadoop中进行离线分析。
  • 运营指标(Operational metrics): 对运营指标进行报警。 比如对某个topic的数量进行统计,进行比较,如果发现数据丢失就报警。
  • 日志收集 (Log aggregation): Kafka可以跨系统收集多个服务的日志,并且处理成标准格式consumer,包括Hadoop和Apache Solr。
  • 流处理 (Stream processing): 一些框架,比如Spark Streaming 从topic读取数据,处理后放入新的topic ,然后供用户或者应用程序使用。Kafka的可靠性十分适合流处理。

其他系统也可以做以上的一些事情,但是没有一个全部可以做的。ActiveMQ和RabbitMQ是非常受欢迎消息代理系统( message broker system),Apache Flume 传统的摄取(ingest)事件,日志和度量再放到Hadoop中。

Kafka及其他可选方案

对于消息代理没有什么可说的了,但对于Hadoop的数据摄取问题我们有所了解。

首先,Kafka使得摄取数据至Hadoop更加容易。涉及到多个数据源及目的地的时候,为每个源和目标写个分离数据管道会迅速发展至一个不可维护的混乱场面。Kafka帮助linkedIn标准化数据管道和允许出入系统各一次,大大减少了管道操作的复杂性和成本。

Jay Kreps,LinkedIn的Kafka架构师,在他的Blog中描述这个问题

My own involvement in this started around 2008 after we had shipped our key-value store. My next project was to try to get a working Hadoop setup going, and move some of our recommendation processes there. Having little experience in this area, we naturally budgeted a few weeks for getting data in and out, and the rest of our time for implementing fancy prediction algorithms. So began a long slog.

与Flume作对比

Flume和Kafka有一部分功能是重叠的。这里列出不同之处来评估这两个系统。

  • Kafka是一个通用系统。你可以有许多producer和consumer来共享多个topic.相比之下Flume旨在发送数据到HDFS和HBase。它对HDFS进行了一些优化,并且集成了Hadoop的安全控制。因此,数据会被多个应用程序消费就用Kafka,如果data只放Hadoop中就用Flume。
  • 如果你对Flume有所了解,那么就知道Flume内置了很多源(sources)和槽(sinks)。Kafka是一个小得多的producer和consumer系统,Kafka社区支持也一般。希望以后可以改善,是用Kafka你需要自己编码来建立你的producer和consumer。 而Flume因为内置了源和槽,可以根据你的需求设置,而不需要额外开发。
  • Flume可以使用interceptor处理数据,对数据屏蔽或者过滤非常有用。而Kafka需要额外的流处理系统。
  • Kafka和Flume都是可靠的系统,通过适当配置能保证零数据丢失。然而Flume不复制事件。因此,即使使用可靠文件通道,如果一个Flume的代理蹦了,你无法访问事件通道,直到你恢复磁盘。使用Kafka你只要保证摄取管道的高可用性即可。
  • Flume和Kafka可以一起工作。如果把流数据从Kafka存到Hadoop,可以使用Flume的Kafka源读取数据:,你不需要实现自己的consumer,你会得益于Flume与HDFS和HBase的整合,你可以用Clouder Manager监视consumer甚至可以添加一个interceptor添加进行流处理。

结语

正如你所见,Kafka有着独特的设计使得它非常有用的解决广泛的架构挑战。重要是确保你使用正确的方法保证高吞吐量、低延迟、高可用性和数据不丢失。

Gwen Shapira是Cloudera的软件工程师、Kafka贡献者。 Jeff Holoman是Cloudera的系统工程师。

  • 无标签

2 评论

  1. 陈留锁 发表:

    最近看到一篇不错的基于kafka 0.10的博文,对kafka的相关细节细节做了一些说明,可作为此翻译的补充阅读:kafka原理以及设计实现思想

  2. 方磊 发表:

    写的不错