智海观潮的博客

Apache Kafka由Scala和Java编写，基于生产者和消费者模型作为开源的分布式发布订阅消息系统。它提供了类似于JMS的特性，但设计上又有很大区别，它不是JMS规范的实现，如Kafka允许多个消费者主动拉取数据，而在JMS中只有点对点模式消费者才会主动拉取数据。Kafka对消息保存时根据topic进行归类，发送消息者称为producer，消息接收者称为consumer。Kafka集群由多个Kafka实例组成，每个实例称为broker。

消息传递、存储和流处理的组合是Kafka作为流式处理平台的关键特性。像HDFS这样的分布式文件系统允许存储静态文件来进行批处理。这样系统可以有效地存储和处理历史数据。而传统的企业消息系统允许在你订阅之后处理将来的数据，并在这些数据到达时处理它。Kafka结合了这两种能力，这种组合对于Kafka作为流处理应用和流数据管道平台是至关重要的。通过消息存储和低延迟订阅，流应用程序可以以同样的方式处理历史和将来的数据。

大家都知道Kafka是将数据存储于磁盘的，而磁盘读写性能往往很差，但Kafka官方测试其数据读写速率能达到600M/s，那么为什么Kafka性能会这么高呢？首先producer往broker发送消息时，采用batch的方式即批量而非一条一条的发送，这种方式可以有效降低网络IO的请求次数，提升性能。此外这些批次消息会"暂存"在缓冲池中，避免频繁的GC问题。批量发送的消息可以进行压缩并且传输的时候可以进行高效的序列化，从而减少数据大小。

通常情况下，企业中会采取轮询或者随机的方式，通过Kafka的producer向Kafka集群生产数据，来尽可能保证Kafk分区之间的数据是均匀分布的。在分区数据均匀分布的前提下，如果我们针对要处理的topic数据量等因素，设计出合理的Kafka分区数量。对于一些实时任务，比如Spark Streaming/Structured-Streaming、Flink和Kafka集成的应用，消费端不存在长时间"挂掉"的情况即数据一直在持续被消费，那么一般不会产生Kafka数据积压的情况。但是这些都是有前提的，当一

众所周知，Apache Kafka是基于生产者和消费者模型作为开源的分布式发布订阅消息系统（当然，目前Kafka定位于an open-source distributed event streaming platform），由Scala和Java编写。Kafka提供了类似于JMS的特性，但设计上又有很大区别，它不是JMS规范的实现，如Kafka允许多个消费者主动拉取数据，而在JMS中只有点对点模式消费者才会主动拉取数据。Kafka producer在向Kafka集群发送消息时，需要指定topic，Kaf

1. 现象在利用Spark和Kafka处理数据时，有时会同时在maven pom中引入Spark和Kafka的相关依赖。但是当利用Spark SQL处理数据生成的DataSet/DataFrame进行collect或者show等操作时，抛出以下异常信息：in stage 3.0 (TID 403, localhost, executor driver): java.lang.NoSuchMethodError: net.jpountz.lz4.LZ4BlockInputStream.<init&g