核心概览
我们很高兴宣布开源项目 AutoMQ v1.6.0 版本正式发布。该版本为开发者带来三大核心优化：
- 成本效益提升最高达 17 倍：通过对写入路径的深度优化，在高吞吐负载场景下，AutoMQ 的总拥有成本（TCO）较自管理 Apache Kafka 降低最高 17 倍。
- Table Topic 功能增强：原生支持 CDC 流，并提供更灵活的 Schema 管理能力，简化数据湖写入流程，无需额外部署 ETL 任务或强制依赖 Schema Registry。
- 完全兼容 Strimzi Operator：可与 Strimzi Operator 无缝集成，让你能通过熟悉的工具在 Kubernetes 上管理 AutoMQ，实现快速扩缩容且无需进行数据重平衡。
如需查看 v1.6.0 版本的完整更新内容，请参阅完整发布说明（https://github.com/AutoMQ/automq/releases?utm_source=wechat_v160）。
01
AutoMQ：基于 S3 重构的 Diskless Kafka
在深入介绍 1.6.0 版本细节前，我们先为刚接触该项目的用户简要回顾 AutoMQ 的核心架构及旨在解决的问题。所有大规模管理过 Kafka 的工程师都清楚其运维痛点：流量峰值需要更多资源支撑，但扩容操作会触发数小时的分区重平衡 —— 这一过程风险高、资源消耗大，且会将计算与存储绑定在固定流程中。这一问题源于 Kafka 原生为本地部署设计的 “无共享”（shared-nothing）架构，是其在云环境中运行时的固有局限。
AutoMQ 通过对 Kafka 进行云原生重构，从根本上解决了这一痛点。我们的设计始于一个简单的问题：如果 Broker 不依赖磁盘会怎样？通过解耦计算与存储，并构建直接将数据流式传输到 S3 或兼容对象存储的全新存储层，AutoMQ 直面并解决了 Kafka 在云环境中的核心挑战：
真正的弹性扩展：Broker 变得轻量且无状态。夜间扩容不再是令人头疼的数据迁移任务，只需启动新 Pod，几秒钟即可完成。
成本大幅降低：无需昂贵且过度配置的块存储（如 EBS），通过 S3 的按量付费模式及区域终端节点，显著降低跨可用区（AZ）数据复制成本。
云原生数据持久性：单个可用区故障不再造成严重影响。将数据持久化任务转移到云存储后，数据的 “可信源” 始终安全，且无需承担管理多副本 ISR 机制的运维开销。
这种 “Diskless” 架构是 AutoMQ 在云环境中具备更高弹性、成本效益和可靠性的基础，也是本次 v1.6.0 版本实现强大成本优化与功能增强的技术基石。
02
超越 Kafka：AutoMQ 实现 17 倍成本降低
在云环境中大规模运行 Kafka 的成本往往高得惊人，这是许多团队的共同痛点。想象一下，如果既能保留你熟悉的 Kafka API，又能大幅降低总拥有成本（TCO），会怎么样？我们针对 v1.6.0 版本的最新基准测试，就展示了 AutoMQ 如何实现这一目标。
核心结论：在 1 GB/s 吞吐、跨 3 个可用区的负载场景下，AutoMQ 1.6.0 版本月均成本约为 12,900 美元；而配置相当的自管理 Apache Kafka 集群，月均成本约为 226,196 美元。成本降低幅度达 17.5 倍，主要得益于跨 AZ 数据传输成本的大幅削减。
下面我们将拆解成本降低的具体原因。
2.1 基准测试配置
透明度是基准测试的核心原则。我们使用开源基准测试工具模拟常见的高吞吐流处理负载，目标是对比 “完全高可用、跨多可用区部署的 AutoMQ” 与 “传统自管理 Apache Kafka” 在 AWS 环境中的成本差异。
2.2 17 倍成本降低的原因解析
成本节省并非偶然，而是通过从根本上改变 Kafka 存储层与云基础设施的交互方式实现的。用 “直接写入 S3 的存储引擎” 替代本地磁盘后，计算与存储得以解耦，进而释放巨大的效率提升空间。
成本节省主要来自以下三个方面：
- 跨 AZ 网络（节省 1080 倍）：这是最关键的突破点。传统 Kafka 集群通过将每条消息从 Leader Broker 复制到其他 AZ 的 Follower Broker 来实现数据备份，在 1 GB/s 吞吐、3 副本配置的场景下，会产生海量且昂贵的跨 AZ 流量（月均约 13.8 万美元）。而 AutoMQ 直接将数据写入 S3，仅需跨 AZ 传输少量元数据和热数据，仅此一项优化就将月均跨 AZ 网络成本从 138,240 美元降至 128 美元。
- 计算资源（节省 6.3 倍）：Apache Kafka 依赖本地存储，导致计算与存储强耦合。云服务商对本地磁盘容量有限制（例如 AWS 限制单实例本地磁盘最大容量为 16TB），而 Kafka 需存储大量数据及冗余的分区副本，因此必须使用更多计算实例，造成计算资源浪费。AutoMQ 解耦计算与存储，支持二者独立扩缩容，彻底解决了这一问题。
- 存储资源（节省 7 倍）：Apache Kafka 需要使用昂贵的预配置块存储（如 EBS），且需按峰值容量进行配置；而 AutoMQ 借助 S3 按量付费模式的弹性与成本优势，仅需为实际存储的数据付费，避免了过度配置造成的浪费。
2.3 性能表现
性能是吞吐、延迟与成本三者的平衡。在本次 1 GB/s 吞吐的基准测试中，AutoMQ 1.6.0 版本的生产端 P99 延迟约为 823ms。
当然，我们也意识到不同负载的需求存在差异。对于有严格低延迟要求的应用，AutoMQ 企业版提供灵活选项：可将区域级 EBS 或 FSx 作为 WAL（预写日志）存储后端。这种配置能实现 “两全其美” 的效果：生产端 P99 延迟低于 10ms，同时仍可借助 S3 实现低成本的长期数据存储。
更多关于我们如何平衡成本与延迟的探讨，请参见官网博客《深度剖析基于 S3 构建 Kafka 的挑战》（原文链接：https://www.automq.com/blog/deep-dive-into-the-challenges-of-building-kafka-on-top-of-s3#latency?utm_source=wanshao_oponsource_blog）。
03
从 Kafka Topic 到 Iceberg 表：实现零 ETL 数据传输
实时分析需求正推动数据架构不断演进。传统的 “批量 ETL 管道”（将数据从 Kafka 传输到数据湖）正逐渐被更直接的 “流写入模式” 取代。这种转变虽能降低延迟与运维开销，但构建和维护这类自定义管道仍面临巨大挑战。
对开发者而言，核心需求往往很明确：将 Kafka 中的事件流导入 Apache Iceberg 等数据湖，以便开展实时分析。但实际操作过程却复杂得多：你需要先部署独立的 ETL 系统（如 Flink、Spark 或 Kafka Connect），相当于为了将数据从第一个分布式系统导出，不得不管理第二个分布式系统 —— 这不仅会增加运维负担、引入新的故障点，还会额外产生成本。
更棘手的是管道的长期维护：微服务团队在 Protobuf Schema 中新增一个字段，你的 Flink 任务就可能崩溃，此时需要协调服务、ETL 任务与 Iceberg 表 Schema 的多步骤部署，同时还要担心数据丢失；又如使用 Debezium 同步数据库变更时，Kafka Topic 中会充斥复杂的 CDC 事件信封，你需要编写并维护有状态逻辑，才能正确解析 “变更前 / 后” 的数据、将操作码（op code）转换为 Iceberg 表的 INSERT/UPDATE/DELETE 操作。每新增一个数据源或数据格式，都要重复这套流程，最终构建出脆弱且冗余的管道。
这种额外的负担被称为 “ETL 税”，也是我们开发 AutoMQ Table Topic 的初衷。它并非又一个工具，而是对 “流数据到数据湖” 流程的根本性重构。Table Topic 是一种特殊的 Topic 类型，可作为 Kafka Broker 原生的零 ETL 桥梁，将数据无缝流式传输到 Apache Iceberg。其目标是通过简化操作、自动化 Schema 演进、提供端到端可靠性（无需依赖外部系统），彻底消除 “ETL 税”。
在 AutoMQ 1.6.0 版本中，我们重新设计了 Table Topic 的底层引擎，专门解决上述实际场景中的复杂问题。旧版设计虽能运行，但随着用户规模扩大，我们也遇到了大家面临的共性问题：某团队将 Protobuf Schema 直接管理在应用的 Git 仓库中，不愿承担 Schema Registry 的运维成本，而旧版实现无法支持这种场景；另一团队使用 Debezium 时发现，Table Topic 虽能将原始变更日志事件写入 Iceberg，但无法理解其语义 —— 例如 UPDATE 操作仅被视为一条普通数据行，而非真正的更新操作。
1.6.0 版本通过架构升级解决了这些问题：
- 引入通用的数据接入层：打破传统限制，将原始 Kafka 消息字节智能转换为结构化、标准化的内部格式。通过采用与数据湖生态深度兼容、且支持 Schema 无缝演进的格式，彻底摆脱对固定 Schema Registry 的依赖。无论你是直接导入 Protobuf 的 .proto 文件，还是处理无 Schema 的 JSON 数据，都能得到支持。
- 基于标准化数据的内容感知处理：在标准化数据基础上，实现智能的内容感知处理，解锁高级数据湖能力。以 Debezium 场景为例：系统现在能原生理解并处理 Debezium CDC 流，只需极少配置，就能自动解析 CDC 事件信封、精准提取实际业务数据（从 “变更前” 或 “变更后” 字段中）、正确识别操作类型（创建 / 更新 / 删除）。这使得 Table Topic 能直接对 Iceberg 表执行真正的 Upsert（更新插入）和 Delete 操作，最终让 CDC 流成为数据湖中的 “一等公民”。此外，我们还优化了从 Avro 到 Iceberg 的最终数据绑定步骤，显著提升了整体写入性能。
这种新架构将 Table Topic 从简单的数据传输工具，升级为智能的内容感知写入引擎。如今，你无需编写任何 ETL 代码，就能构建端到端的 CDC 管道，或流式传输由应用管理的 Protobuf 事件。对于构建实时数据湖的开发者而言，这终于实现了 “专注于数据本身，而非数据传输工具” 的目标。
这些增强的功能让 Table Topic 成为构建实时数据湖的更优解，可支撑多种场景，从实时交易明细表到近实时分析仪表盘均适用。
04
100% 兼容 Kafka：与 Strimzi 无缝集成
试想这样的场景：凌晨 3 点，流量峰值迫使你在 Kubernetes 上扩容 Kafka Broker。这本该是自动化的常规操作，但你却面临艰难抉择 —— 扩容会触发数小时的数据重平衡，引发大量网络流量与 I/O 负载，进而威胁集群稳定性。这并非 Kubernetes 的问题，而是传统 Kafka 并非真正 “Kubernetes 原生” 的体现：Kubernetes 擅长管理临时、无状态的工作负载，以实现快速扩缩容与自愈；而 Kafka 计算与存储强耦合的架构，与这些特性根本相悖。这种矛盾导致你始终无法充分发挥 Kubernetes 带来的弹性优势。
社区针对这一运维挑战的主流解决方案是 Strimzi—— 这款权威的 Operator 工具能自动化 Kafka 管理流程，大幅简化部署操作，但它无法解决 Kafka 底层的架构局限：无法消除 “数据引力”（数据对存储的依赖）导致的扩容风险，因此无法提供真正的 Kubernetes 原生 Kafka 体验。
AutoMQ 通过 “计算 - 存储解耦” 的创新架构解决了这一核心问题，但开发者自然会提出关键疑问：“既然你们重构了 Kafka 核心，那我们依赖的工具（尤其是 Strimzi）是否还能兼容？”
答案是“可以”。由于我们将 “100% 兼容 Kafka 协议” 作为核心设计原则，你无需放弃信赖的工具：只需在 Strimzi 自定义资源（Custom Resource）中修改容器镜像引用，就能无缝管理 AutoMQ 集群。我们很高兴地宣布，从 v1.6.0 版本开始，AutoMQ 已完全兼容 Strimzi Operator，且我们已通过全面测试验证了其核心功能。
这种无缝集成并非偶然，而是我们设计理念的直接体现：我们认可 Kafka 社区的价值，也相信其生态的强大。通过完全兼容 Kafka 协议，我们确保 AutoMQ 能随生态演进而同步发展。对 Strimzi 的兼容能力，正是这一承诺的有力证明。
如今，当凌晨 3 点的流量峰值来临时，你终于可以通过信赖的 Operator 管理 Kafka 集群，实现 “分钟级扩缩容”（而非小时级），真正释放 Kubernetes 对数据流的管理能力。若你想了解实现这一兼容性的技术细节，可阅读我们的博客文章：《AutoMQ 如何实现 100% Kafka 协议兼容》（原文链接：https://www.automq.com/blog/how-automq-makes-apache-kafka-100-protocol-compatible?utm_source=wechat_v160）。
小贴士：AutoMQ 1.6.0 在保持与 Kafka 完全兼容的同时，新增发布了基于 Apache Kafka 开源镜像的版本。该镜像完全兼容 Apache Kafka 官方 Docker 镜像的启动逻辑，支持开箱即用。详情请参阅此处（https://www.automq.com/docs/automq/deployment/deployment-recommendations?utm_source=wechat_v160）。
05
立即体验开源 AutoMQ
AutoMQ 1.6.0 版本带来了开发者在云环境中最关注的三大能力：成本大幅降低、数据湖写入简化、Kubernetes 上的无摩擦运维。基准测试显示其 TCO 较 Kafka 降低 17 倍，重构后的 Table Topic 实现 “零 ETL 写入 Iceberg”，且通过 100% Kafka 兼容能力集成 Strimzi—— 这意味着你无需放弃现有工具与 API，就能充分享受云环境承诺的弹性优势。