一、流处理（Stream Processing）
| 工具 | 特点 | 适用场景 | 备注 |
|---|---|---|---|
| Kafka Streams | 轻量内嵌、与 Kafka 紧耦合、Exactly-Once、KTable/状态存储 | 微服务内置实时计算、按主题构建小型管道 | 无集群，无外部依赖，DevOps 成本低 |
| Apache Flink | 批流一体、强状态与事件时间、复杂拓扑 | 大规模流式计算、跨多源、多 Sink、CEP | 对接 Iceberg/Hudi、维表 Join、反压治理成熟 |
| Spark Structured Streaming | 与 Spark 生态融合、易接入湖仓 | 以批为主的团队补齐流处理 | 低延迟能力不及 Flink |
| ksqlDB | SQL 即流处理（基于 Kafka Streams） | 快速拉通“SQL→流应用” | 上手快、便于数据团队 |
| Samza/Storm | 历史项目 | 存量系统维护 | 新项目一般不首选 |
实践提示
- 以业务复杂度与组织能力选型：微服务化优先 Kafka Streams，复杂计算/湖仓融合优先 Flink。
- 统一 “事件时间 + 水位线” 语义，避免“看上去准实时，实则乱序”。
二、数据集成 & CDC（Connectors / Integration）
| 方向 | 主流方案 | 场景 | 说明 |
|---|---|---|---|
| Kafka Connect | 官方框架 + 海量连接器（JDBC、S3/HDFS、Elasticsearch、MongoDB、GCS/ADLS、BigQuery…） | 以配置为主的持续导入/导出 | 生产部署优先 分布式模式，插件路径与版本管理要规范 |
| Debezium（CDC） | MySQL/PostgreSQL/SQL Server/Oracle/DB2… 变更捕获 | 数据库→Kafka 的行级变更流 | 精确抽取 INSERT/UPDATE/DELETE，适合事件溯源与微服务反向同步 |
| NiFi / Airbyte / Logstash | 低代码编排或 ETL 场景 | 异构系统整活、批/流混编 | 与 Connect 并存；注意运维复杂度 |
| MirrorMaker 2 | Kafka↔Kafka 跨集群复制 | 多机房/多区域、容灾 | 规划好 Topic 映射、ACL 与延迟监控 |
落地要点
- 严格按Schema Registry 管控消息格式与演进策略（见第五节）。
- Source/Sink 的重试与幂等：避免“连环重试 → 重复写”。
- 规划DLT（死信主题）与旁路修复流程（离线更正后再回放）。
三、数据湖 / Hadoop / 离线系统集成
| 目标 | 推荐路径 | 说明 |
|---|---|---|
| 落湖归档（近实时） | Kafka Connect HDFS/S3 Sink → Iceberg/Hudi/Delta（经 Flink/Spark 写表） | 统一表格存储与 ACID 管理，支持回放重算 |
| 离线计算 | Flink/Spark 订阅 Kafka → 产出 Hive/湖仓表 | 共享元数据（Glue/Hive Metastore），分区/分桶规划 |
| OLAP 实时分析 | Kafka → ClickHouse/Druid/Pinot → 即席查询 | 指标秒级可见；维表 Join 与去重策略需明确 |
最佳实践
- 统一分区字段与时间语义（事件时间 vs 到达时间）。
- 从 Kafka 回放到湖仓时，处理幂等写入与去重（主键 + 去重窗口）。
四、监控与可观测（Monitoring & Observability）
| 能力 | 工具 | 要点 |
|---|---|---|
| Broker/JVM 指标 | Prometheus + JMX Exporter，Grafana | 关注 Purgatory、ISR、Request/Network、Log Flush 延迟 |
| 消费积压 | Burrow（消费者组 Lag 监控） | 阈值告警 + 自动扩缩容联动 |
| 集群拓扑/分区可视化 | Kafka UI / Kafdrop、Conduktor（商用） | 快速巡检主题、分区与消息 |
| 负载均衡/重分配 | Cruise Control | 线上分区重分配、自动化再均衡 |
| 全链路 | OpenTelemetry / Datadog / New Relic / Elastic | 采样与指标分层，避免告警风暴 |
监控指标清单
- 延迟：生产端、消费端、端到端
- Lag：按消费者组/分区
- 吞吐/错误率：生产失败、重试、DLT 数量
- 存储水位：磁盘、段大小、清理/压缩进度
- 再均衡频率：频繁再均衡通常意味着心跳/会话配置或分配策略问题
五、Schema / 序列化与数据治理
| 组件 | 作用 | 建议 |
|---|---|---|
| Schema Registry（Confluent / Apicurio 等） | 管控 Avro/Protobuf/JSON Schema，版本演进与兼容性校验 | 生产强制开启；设定 Backward / Forward / Full 兼容策略 |
| 序列化格式 | Avro / Protobuf / JSON Schema | 强 schema 优先（Avro/Protobuf）；控制字段演进 |
| 话题命名 & 约定 | 领域.实体.动作 或 领域.数据类型 | 如：activity.page_view.v1、orders.created.v2（携带版本） |
治理要点
- PR / 数据契约流程引入Schema 审核。
- 通过 Subject 与 Compatibility 策略，阻断“破坏性变更”上线。
- 为每个主题补全：保留策略、压缩策略、分区键、数据负责人。
六、部署与运维（Deployment & Ops）
| 场景 | 推荐方案 | 说明 |
|---|---|---|
| Kubernetes | Strimzi Operator（开源）、Confluent for Kubernetes（商用）、Bitnami Helm | Operator 托管升级/扩缩容/滚动重启/证书；持久卷规划 |
| 基础设施即代码 | Terraform + Helm | 多环境一致性，参数化集群规格 |
| 跨区域/容灾 | MirrorMaker 2、多集群架构 | Topic 映射、ACL 与数据延迟观测 |
| 安全 | SASL/SCRAM / OAUTHBEARER、mTLS、ACL/RBAC | 秘密管理（K8s Secrets / Vault），最小权限原则 |
运维清单
replication.factor≥3、min.insync.replicas≥2、生产端acks=all+ 幂等- 合理的 分区数（根据目标吞吐与消费者并发）
- 清理策略：
delete（按时间/大小），或compact/compact,delete（KV/溯源） - 标准化的Topic 申请/变更流程与可观测面板
七、测试与本地开发
| 工具 | 用途 |
|---|---|
| Testcontainers for Kafka | 单测/集成测试中拉起临时 Kafka |
| kcat（kafkacat） | 生产/消费/探测 Topic 的万能 CLI |
| Kafka UI / Kafdrop | 本地可视化调试 |
| Redpanda（兼容协议） | 本地/CI 轻量替代（注意与目标集群差异） |
建议
- 关键流程“生产→消费→DLT”必须可在 CI 里重放验证。
- 构造乱序、重复、延迟到达数据的测试样例，校验窗口与幂等逻辑。
八、参考架构蓝图
A. 行为数据实时数仓
B. 数据库 CDC → 事件驱动微服务
九、选型速查表
| 需求 | 首选 |
|---|---|
| 轻量实时计算、嵌入微服务 | Kafka Streams |
| 跨源融合、复杂拓扑、湖仓对接 | Flink |
| 数据库行级变更进入 Kafka | Debezium（CDC） |
| “配置化”持续导入/导出 | Kafka Connect + 对应连接器 |
| Kubernetes 原生部署 | Strimzi Operator |
| 监控与 Lag 告警 | Prometheus + JMX Exporter + Burrow |
| Schema 治理与演进 | Schema Registry（Avro/Proto） |
十、落地避坑清单
- 别把 Kafka 当“传统队列”：理解保留/回放语义，预留 DLT 与回溯重算通道。
- 分区键拍脑袋 ⇒ 热点或顺序错乱：按 用户/实体 ID 等稳定键设计。
- 无 Schema 治理 ⇒ 难以演进：引入 Registry + 兼容策略。
- Connect 混乱：插件版本与依赖不一致、Offset 与幂等没处理好 ⇒ 重复/漏数。
- 监控缺失：Lag、端到端延迟与再均衡频率必须看板化并告警。
- 跨区域复制低估延迟：MirrorMaker 2 需容量评估与 Topic 级别 SLO。