1. Kafka

1.1 定位

分布式流数据平台，核心解决三大问题：
高吞吐的实时数据管道：支持每秒百万级消息处理。
持久化的消息队列：消息持久化到磁盘，支持多订阅者。
流式数据处理：与 Flink/Spark Streaming 集成，实现实时计算。

1.2 基础概念

组件	作用
Producer	消息生产者，将数据发布到指定 Topic（如日志采集器、应用事件埋点）
Broker	Kafka 服务节点，负责消息存储和转发。集群中多个 Broker 组成高可用架构
Topic	逻辑上的消息分类（如 order_events）。每个 Topic 分为多个 Partition 提高并行度
Partition	消息的物理分片，有序不可变序列，每条消息通过 Offset 唯一标识
Consumer	消息消费者，按需订阅 Topic（如实时计算任务、数据同步服务）
Consumer Group	多个 Consumer 组成的组，共同消费一个 Topic，实现负载均衡（组内竞争 Partition）
Zookeeper/KRaft	集群元数据管理与选举（Kafka 2.8+ 逐步移除 Zookeeper，改用 KRaft 协议）

Broker（经纪人/服务节点）
可以理解为 “数据中转站” 或 “Kafka服务器”。
作用：Kafka集群中的一个工作节点，负责接收、存储和转发消息。多个Broker组成一个Kafka集群（类似快递公司的多个分拣中心）。
例子：假设Kafka是一个邮政系统，Broker就是各个城市的邮局。生产者把信件（消息）送到邮局，邮局负责暂存信件，并分发给对应的收件人（消费者）。

Topic（主题）
可以理解为 “消息分类” 或 “数据流名称”。
作用：逻辑上对消息进行分类，类似数据库中的“表”或文件系统中的“文件夹”。生产者向指定Topic发送消息，消费者订阅Topic获取消息。
例子：继续用邮政系统类比，Topic就是不同类型的邮件，比如：
订单通知 Topic：专门处理电商订单消息（如“您的订单已发货”）。
日志监控 Topic：专门传输服务器日志（如“用户A登录了系统”）。

Partition（分区）
可以理解为 “数据分片” 或 “并行处理的通道”。
作用：每个Topic可以分成多个Partition，实现数据的分布式存储和并行处理。消息在Partition内是有序的，但不同Partition之间无序。
例子：
假设订单通知 Topic有3个Partition，就像邮局的3个分拣窗口：
Partition 0：处理订单号以0结尾的订单（如订单100、订单200）。
Partition 1：处理订单号以1结尾的订单（如订单101、订单201）。
Partition 2：处理订单号以2结尾的订单（如订单102、订单202）。

生产者（Producer）的数据是先发送到 Topic，但 Topic 的物理载体是 Broker。

Offset是 Kafka 中每条消息在 Partition 内的唯一位置标识（类似于数组下标）。例如，Partition 中的消息按顺序存储为Offset 0, 1, 2, ...。
作用：Consumer 通过记录已处理的 Offset，来标识消费进度。例如，若 Consumer 处理完 Offset 100 的消息，下一次会从 Offset 101 开始消费。
提交 Offset：Consumer 在处理完消息后，需显式或隐式地告知 Kafka：“我已处理到 Offset X”。Kafka 会将此信息记录在内部 Topic __consumer_offsets 中。

1.3 数据流向

1.4 性能调优

Producer：
批量发送（linger.ms 和 batch.size）。
压缩消息（compression.type=snappy）。

Consumer：
增加分区数提升并行度。
避免单 Consumer 处理过多 Partition（均衡负载）。

Broker：
调整 num.io.threads 和 num.network.threads 匹配硬件资源。

常见问题
消息积压：增加 Consumer 数量或优化处理逻辑。
数据倾斜：合理设计 Partition Key（避免热点 Key）。
重复消费：确保 Consumer 提交 Offset 的幂等性。

1.5 引申问题

Kafka 和 HDFS 都能存储数据，但本质不同：
Kafka 是流式数据的中转站，强调高吞吐、低延迟的实时传输，数据默认会滚动删除，适合作为消息队列或流处理管道；
HDFS 是批量数据的永久存储，针对大文件优化，支持复杂分析，适合离线计算。
例如，我们会用 Kafka 实时接收用户行为日志，再由 Flink 消费计算实时指标，同时定期将 Kafka 数据归档到 HDFS 供离线补算和审计。

2. Flink

2.1 定位

Apache Flink 是一个分布式流批一体计算引擎，设计目标是处理无界（流）和有界（批）数据，提供低延迟、高吞吐、精确一次（Exactly-Once）的计算能力。其核心特点是以流处理为原生模型，批处理被视为流处理的特殊情况。

2.2 组件

组件	角色
JobManager	集群的“大脑”，负责任务调度、Checkpoint协调、故障恢复。一个集群可有多个备用（HA）
TaskManager	执行具体任务的节点，包含多个Task Slot（资源单元），负责数据计算与网络传输
Resource Manager	管理资源（如与YARN/K8s集成），分配TaskManager资源

2.3 计算流程

Flink 的执行模型可类比为 流式优化的 DAG（有向无环图），但更强调事件驱动的连续处理。以下是其核心阶段：

阶段拆解

阶段	说明
Source	从外部系统（如 Kafka、文件）读取数据，生成 DataStream 或 DataSet
Transformation	应用 map、filter、keyBy 等操作，构建处理逻辑链
Shuffle	根据 keyBy 或自定义分区器（Partitioner）重新分配数据（类似 MapReduce 的 Shuffle）
Window/Aggregate	对 KeyedStream 应用窗口或聚合操作（如 reduce、sum、window）
Sink	将结果写入外部存储（如数据库、Kafka）

2.4 为什么Flink适合实时处理？

2.4.1 处理模型差异

• Flink：原生流处理（True Streaming）

  • 将数据视为无界流，每条记录到达时立即处理，实现毫秒级延迟。
  • 流水线式执行引擎，无需等待微批次，最大化实时性。

• Spark Streaming：微批处理（Micro-Batching）

  • 将流数据切分为小批次（如1秒），以RDD批处理方式处理。
  • 虽然通过缩小批次可降低延迟（如Structured Streaming的连续处理模式），但存在亚秒级延迟，需权衡吞吐与延迟。

• MapReduce：离线批处理

  • 仅支持静态数据集的全量处理，无法处理无界数据流，完全不适合实时场景。

2.4.2 核心优势详解

• 低延迟与高吞吐

  • Flink通过流水线式数据传输（非阻塞模型）和内存计算优化，同时实现高吞吐与低延迟。
  • Spark的微批次模型需等待批次积累，存在固有延迟。

• 事件时间（Event Time）与乱序处理

  • Flink支持事件时间语义，通过Watermark机制处理乱序事件，确保计算准确性。
  • Spark Streaming默认基于处理时间（Processing Time），对乱序处理能力较弱。

• 状态管理与容错

  • Flink的状态后端（内存/RocksDB）支持高效状态存取，结合Checkpoint机制实现故障恢复与Exactly-Once语义。
  • Spark Streaming依赖WAL（Write-Ahead Log）或RDD血缘（Lineage）恢复，状态管理灵活性较低。

• 灵活的窗口机制

  • Flink支持基于事件时间的窗口（滚动、滑动、会话窗口），允许自定义触发策略。
  • Spark的窗口操作受限于微批处理模型，灵活性较差。

• 流批一体架构

  • Flink以流处理为核心，批处理视为有限流（Bounded Stream）的特例，统一编程模型。
  • Spark需切换API（Spark Streaming vs. Spark SQL），MapReduce完全分离流批场景。