Kafka Engineer 是一个面向 Apache Kafka、事件流与实时数据管道的专家型技能，聚焦可扩展的事件驱动架构与实时数据管道，用于构建具备 exactly-once 处理能力的容错流式平台，并覆盖 Kafka Connect 与 Schema Registry 管理。
用途 该技能用于在以下场景提供 Kafka 与事件流方面的专业支持：设计事件驱动微服务架构；搭建 Kafka Connect 管道（CDC、S3 Sink）；编写流处理应用（Kafka Streams / ksqlDB）；排查消费者延迟、再平衡风暴或 broker 性能问题；使用 Schema Registry 设计 Avro/Protobuf 模式；配置 ACL 与 mTLS 安全。
主要能力 技能提供架构选型决策框架，按用途区分方案：数据集成（ETL）场景中，数据库到数据库/数据湖使用 Kafka Connect（零代码），复杂转换使用 Kafka Streams；实时分析场景中，类 SQL 查询使用 ksqlDB（快速聚合），复杂有状态逻辑使用 Kafka Streams / Flink；微服务通信场景中，事件通知使用标准 Producer/Consumer，事件溯源使用状态存储（RocksDB）。 配置调优方面，技能给出“三大项”要点：吞吐量关注 batch.size、linger.ms、compression.type=lz4；延迟关注 linger.ms=0、acks=1；持久性关注 acks=all、min.insync.replicas=2、replication.factor=3。同时列出需要升级给 sre-engineer 的红旗信号：启用“unclean leader election”（数据丢失风险）、新集群依赖 Zookeeper（应使用 KRaft 模式）、broker 磁盘使用率超过 80%、消费者延迟持续增长（容量不匹配）。
使用方式 技能包含核心工作流示例。Kafka Connect（CDC）工作流的目标是将 PostgreSQL 的变更流式传输到 S3，步骤包括：编写 Source 配置（postgres-source.json），使用 io.debezium.connector.postgresql.PostgresConnector，设置 database.hostname、database.dbname、database.user、plugin.name=pgoutput；编写 Sink 配置（s3-sink.json），使用 io.confluent.connect.s3.S3SinkConnector，设置 s3.bucket.name、format.class 为 ParquetFormat、flush.size=1000；通过 curl -X POST -d @postgres-source.json http://connect:8083/connectors 部署。Schema Registry 集成工作流的目标是强制模式兼容性，步骤包括：定义模式（user.avsc，record 类型，字段 id 为 int、name 为 string）；Producer（Java）使用 KafkaAvroSerializer，Registry URL 为 http://schema-registry:8081。
反模式与注意事项 技能列出若干反模式：大消息（如在 Kafka 消息中发送 10MB 图片负载）会阻塞 broker 线程，因为 Kafka 针对小于 1MB 的小消息优化，正确做法是将图片存入 S3 并在 Kafka 消息中发送引用 URL；分区过多（如在小集群上创建 10,000 个分区）会导致 leader 选举缓慢（Zookeeper 开销）和高文件句柄占用，正确做法是限制每 broker 分区数（约 4000），使用更少主题或更大集群；阻塞消费者（如每条消息执行 30 秒的重 HTTP 调用）会因超时导致消费者离开组而引发再平衡风暴，正确做法是异步处理（将工作移至线程池），或在缓冲区满时使用 consumer.pause() 暂停/恢复。
质量检查清单 配置方面：生产环境复制因子为 3；min.ISR 为 2（防止数据丢失）；正确配置保留策略（按时间或大小）。可观测性方面：监控消费者延迟（Burrow/Prometheus）；对 under-replicated 分区（>0）告警；导出 JMX 指标。
示例 示例一：实时欺诈检测管道。金融公司使用 Kafka 流式处理进行实时欺诈检测。架构实现包括：事件摄取使用 Kafka Connect 从 PostgreSQL 交易数据库进行 CDC；流处理使用 Kafka Streams 应用进行实时模式检测；告警系统通过 Producer 向告警主题发送消息触发通知；存储使用 S3 sink 用于历史分析与合规。管道配置：3 个主题（transactions、alerts、enriched），12 个分区（3 broker × 4），复制因子 3，压缩 LZ4。关键逻辑：检测速度模式（1 分钟内 5 笔以上交易）、识别地理异常（不可能旅行）、标记高风险商户类别。结果：99.7% 的欺诈在 100ms 内被检测到；误报率从 5% 降至 0.3%；合规审计零发现通过。 示例二：电商订单处理系统。构建基于 Kafka 的高可靠弹性订单处理系统。系统设计：订单事件主题用于订单生命周期事件；库存服务消费订单并更新库存；支付服务处理支付并发布结果；通知服务通过邮件/短信发送确认。弹性模式：失败处理的死信队列；幂等生产者实现 exactly-once 语义；消费者组手动管理偏移量；带指数退避的重试。配置：Producer 使用 acks: all、retries: 3、enable.idempotence: true；Consumer 使用 auto.offset.reset: earliest、enable.auto.commit: false、max.poll.records: 500。结果：99.99% 消息投递可靠性；6 个月内零重复订单；峰值处理 10,000 订单/秒。 示例三：IoT 遥测平台。处理数百万 IoT 设备遥测消息。平台架构：设备网关为 MQTT 到 Kafka 代理；数据丰富通过流处理添加设备元数据；时序存储使用按 device_id/date 分区的 S3 sink；实时告警基于阈值检测异常。可扩展性配置：50 个分区用于并行处理；启用压缩以优化成本；保留策略为热存 7 天、S3 冷存 1 年；使用 Schema Registry 管理数据契约。性能指标：吞吐量 500,000 消息/秒；延迟（P99）50ms；消费者延迟小于 1 秒；压缩使存储效率提升 60%。
最佳实践 主题设计：使用清晰的层级主题命名（domain.entity.event）；分区策略按未来增长规划（预期吞吐量的 3 倍）；保留策略匹配业务需求；清理策略按时间使用 delete、按状态使用 compact；通过 Schema Registry 强制模式。 生产者优化：通过增大 batch.size 和 linger.ms 提升吞吐；使用 LZ4 平衡速度与大小；可靠性使用 acks=all，延迟使用 acks=1；实现带退避的重试；在关键路径启用幂等以实现 exactly-once 语义。 消费者最佳实践：关键处理使用手动提交偏移量；增大 max.poll.records 提升批处理效率；实现优雅关闭以处理再平衡；使用死信队列处理毒消息；监控消费者延迟与处理时间。 安全配置：所有客户端-broker 通信使用 TLS 加密；生产环境使用 SASL/SCRAM 或 mTLS 认证；ACL 遵循最小权限原则；实施客户端配额防止滥用；记录所有访问与配置变更的审计日志。 性能调优：按工作负载类型（吞吐 vs 延迟）优化 broker 配置；JVM 调优（堆大小与垃圾回收器选择）；操作系统调优（文件描述符限制、网络设置）；监控吞吐、延迟与错误指标；定期审查与评估容量规划。 安全：客户端-broker 与 broker 间启用 TLS 加密；启用 SASL/SCRAM 或 mTLS 认证；ACL 遵循最小权限原则（主题读写）。
限制 资料未提供该技能的安装命令、收费方式、价格、支持平台或具体运行环境要求，这些信息暂未提供。