<kafka><应用场景><Kafka VS Flume>

前言

• 最近在搭一个离线Hadoop + 实时SparkStreaming的日志处理系统，然后发现基本上网上的这种系统都集成了kafka。
• 自己对kafka有一点点的认识，之前看过官网文档，用过一次，就了解到它是个消息队列。好像说是比起其他的消息队列，对多subscriber更友好。
• 所以google了一些kafka的应用场景，来加深一下理解。

Use Cases

• Kafka documentation - use cases

Messaging

• Kafka works well as a replacement for a more traditional message broker.
• 一般来说，message broker有多重使用原因：
  • To decouple processing from data producers;
  • To buffer unprocessed messages.
  • 关于Message Broker，往下拉，看下一章节~
• Kafka与大多数messaging系统相比，有更高的吞吐量(throughput)，内置分区(built-in partitioning)，复本(replication)，容错性(fault-tolerance)。

Website Activity Tracking

• Kafka的原始的用例是作为实时publish-subscribe feeds用以重建一个用户活动追踪管道。
• 这意味着网页活动(包括页面浏览、搜索或其他用户行为)，每个活动类型都会作为一个topic被发送到一个central topics。
• These feeds are available for subscription for a range of use cases including real-time processing, real-time monitoring, and loading into Hadoop or offline data warehousing systems for offline processing and reporting.
• Activity tracking通常有high volume，因为许多活动消息都是对每个用户生成的。

Metrics

• Kafka经常用来操作数据管道的监控。这包括从分布式应用中聚集数据来产生操作数据的centralized feeds.

Log Aggregation

• 日志聚合通常是从servers中收集物理log文件，并将它们放到一个central place(一个文件服务器或HDFS等)去处理。
• Kafka去掉了文件细节，并将log或event数据的摘要作为一个消息流。这考虑到了低延迟的处理，对多数据源的更简单的支持，以及分布式数据消耗。
• 相比于log-centric系统，比如Scribe或Flume，kafka提供了相同的优越性能，基于副本的更强的持久性保证，以及更低的端到端延迟。

Streaming Processing

• TBD...

Message Broker

• A message broker is an intermediary program module that translates a message from the formal messaging protocol of the sender to the formal messaging protocol of the receiver. [消息代理是一个中间编程模块，它可以将sender的正式消息协议翻译成receiver的正式消息协议]。
• 消息代理调解众多应用之间的通信，最小化应用之间交换消息时对彼此的awareness，高效地实现解耦decoupling。
• broker的目的是从applications中取得incoming message，并基于它们做一些action。以下是broker可以采取的actions：
  • 将消息路由到多个目的地；
  • 将消息转化为an alternative representation;
  • 执行消息聚合，将消息分解成多个消息并发送到相应目的地，然后recomposing the response成一个消息，并返回给user；
  • 与外部存放处(external repository)交互来增加一条消息并存储；
  • 唤起web services来取得数据；
  • 对events和errors作出response；
  • 使用publish-subscribe模式来提供内容和基于topic的消息路由。

Kafka VS Flume

• 看了很多博客，大概都是在强调：
  1. 有多个consumers用Kafka；
  2. 如果是要导数据到Hadoop生态系统，用Flume。
• 其中这篇blog写的不错。Flume or kafka
• 现在的趋势是，将Kafka与Flume结合。

Kafka Over Flume

• 相比于Flume，Kafka胜在它极好的可扩展性和消息持久性：
• Kafka is very scalable.
  • kafka的一个最大的优点就是它很容易添加大量的consumer，却不影响性能。这是因为Kafka不追踪topic中的消息是否已经被consumed，它只是简单地在一个configurable周期内保存topic中的所有消息。它是consumer自身通过offset来追踪。
  • 相比之下，Flume添加consumers意味着改变Flume管道的拓扑设计，复制channel以传送数据到一个新的sink。同时，由于需要改变flume的拓扑结构，那么就需要一些down time。
  • kafka的可扩展性也体现在它能处理大量events上，kafka可以处理100k+ 每秒的生产到来速度。由于kafka consumers是pull-based，所以不同consumers可以以不同速度消费消息。同时kafka也支持不同消费模型，你可以实时处理消息，也可以以批处理模式处理消息。
  • 相比之下，Flume sink是push-based模型，当event生产者突然产生a flood of messages, 即使有flume channel可以作为source和sink之间的buffer，sink端仍然会被写操作淹没。
• 消息的持久性也是一个重要考量。
  • Flume既提供短暂的基于内存的channel，也提供耐用的基于文件的channel。在agent fail掉之后，即使你使用file-based channel， 任何存储在channel中还未写到sink的event都会不可用，直到agent被恢复。
  • 相比之下，Kafka提供了同步和不同步的副本策略，基于你的持久性要求。

Flume over Kafka

• Flume与Hadoop生态系统紧密结合。比如，flume HDFS sink与HDFS安全性融合非常好。所以Flume经常被用作ingest数据到Hadoop的消息管道。
• Flume最主要的优点就是它支持多种内置sources和sinks，方便你开箱即用。相比之下，如果你使用Kafka，你需要定制生产者和消费者。(但是随着kafka越发流行，有很多框架为kafka添加了集成)。
• Kafka本身没有提供消息处理，所以它可能需要集成一些其他的事件处理框架，比如Apache Storm来完成这项工作。
• 相比之下，Flume提供了多种数据流模型和拦截器链，这使得事件过滤和转换很方便。比如说，你可以在管道中过滤掉你不需要的消息，而不需要在网络中传输了。但是这也不适合做很复杂的时间处理。