历史

消息引擎系统

  1. Kafka在刚诞生时是以消息引擎系统的面目出现在大众视野中
  2. Kafka在0.10.0.0之前的定位：分布式、分区化且带备份功能的提交日志（Commit Log）服务
  3. Kafka在设计之初的功能特性
    • 提供一套API实现生产者和消费者
    • 降低网络传输和磁盘存储开销
    • 实现高伸缩架构

分布式流处理平台

  1. Kafka于2011年正式进入Apache基金会孵化并于次年10月成为Apache顶级项目
  2. Kafka社区于0.10.0.0版本正式推出流处理组件Kafka Streams，定位变成了分布式流处理平台
  3. 同等级的实时流处理平台：Apache Kafka、Apache Storm、Apache Spark、Apache Flink
  4. 目前国内对Kafka是流处理平台的认知还不普及，其核心的流处理组件Kafka Streams更是少有大厂在使用

优势

端到端的正确性

  1. Kafka更容易实现端到端的正确性（Correctness）
  2. 流处理要替代批处理需要具备两个核心优势
    • 实现正确性（正确性是流处理能够匹敌批处理的基石）
    • 提供能够推导时间的工具
  3. 正确性一直都是批处理的强项，而实现正确性的基石是要求框架能提供_精确一次处理语义_
    • 即处理一条消息有且只有一次机会能够影响系统状态
  4. 目前主流的大数据流处理框架都宣称实现了精确一次处理语义，但这是有限定条件的
    • 即它们只能实现框架内的精确一次处理语义，无法实现端到端的
    • 当这些框架与外部消息引擎系统结合使用时，它们无法影响到外部系统的处理语义
    • 例如搭建一套环境使得Spark或Flink从Kafka读取消息之后进行有状态的数据计算，最后写回Kafka
    • 这种情况只能保证在Spark或Flink内部，这条消息对于状态的影响只有一次
    • 但计算结果有可能多次写入到Kafka，因为它们不能控制Kafka的语义处理
  5. 对于Kafka，因为所有的数据流转和计算都在Kafka内部完成，所以Kafka可以实现_端到端的精确一次处理语义_

自身定位

  1. Kafka官网：Kafka Streams是一个用于搭建实时流处理的客户端库而不是一个完整的功能系统
    • 不提供类似集群调度、弹性部署等开箱即用的运维特性
  2. 大公司的流处理平台一定是大规模部署的，因此具备集群调度功能以及灵活的部署方案是不可或缺的要素
  3. 但世界上还存在很多中小企业，它们的流处理数据量并不巨大，逻辑也不复杂，部署几台机器即可应付
    • 针对这样的需求，没必要搭建重量级的完整性平台，这也正是Kafka Streams的用武之地

参考资料

Kafka核心技术与实战