<应用场景>

时间:2021-07-24 01:31:25

前言

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

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提供了多种数据流模型和拦截器链,这使得事件过滤和转换很方便。比如说,你可以在管道中过滤掉你不需要的消息,而不需要在网络中传输了。但是这也不适合做很复杂的时间处理。