摘要：导读近年来，Iceberg 已成为数据湖格式的事实标准。在国外，随着 Databricks 的收购行为以及 Confluent 推出 Table Flow 和 AWS 推出 S3 Tables，这一趋势愈发明显。AWS 在发布 S3 Tables 时披露的数据
导读近年来，Iceberg 已成为数据湖格式的事实标准。在国外，随着 Databricks 的收购行为以及 Confluent 推出 Table Flow 和 AWS 推出 S3 Tables，这一趋势愈发明显。AWS 在发布 S3 Tables 时披露的数据显示，目前在 AWS 上已有 EB 级的 Parquet 数据文件。众所周知，Iceberg 背后的主要格式是 Parquet，每天都会产生数百 PB 的新增 Parquet 数据存储。这正是 AutoMQ 推出 Table Topic 的重要原因。
在现代大数据技术中，所有数据最终都需要存储在以 S3 为代表的存储系统中。Kafka 作为流数据存储的事实标准，在这一过程中扮演着关键角色。然而，要实现流数据的完整摄取和分析，还需要一个能够连接流数据和静态数据湖的桥梁。AutoMQ 的 Table Topic 正是这样一个桥梁，它能够将 Kafka 中的流数据高效地写入 Iceberg 表，从而实现流数据和静态数据的无缝对接。
本文将详细介绍 AutoMQ 及其 Table Topic 功能，并阐述如何通过 Table Topic 实现流数据摄取与分析的完整拼图，特别是在与 Iceberg 集成方面的应用。同时，本文还将通过 AWS 上的成功案例，展示 AutoMQ Table Topic 在实际应用中的优势。
文章主要包括以下几大部分：
1. AutoMQ 与流处理的演变
2. AutoMQ 的架构及其优势
3. Table Topic 与 S3 Tables 和 Iceberg 的集成
4. 在 AWS 上入门 Table Topic
5. 总结回顾与未来规划
6. AutoMQ Table Topic：技术问答
分享嘉宾｜周新宇 AutoMQ 联合创始人 & CTO
编辑整理｜杨峰
内容校对｜李瑶
出品社区｜DataFun
在过去的 2024 年，我们在国内已经开展了大量关于 AutoMQ 的运营工作。简单来说，AutoMQ 是 Apache Kafka 的云原生替代方案。我们通过对 Kafka 开源版本的存储层进行完全替代，实现了这一目标。具体来说，我们通过将持久性解耦到 S3 和 EBS，完全替换了原有的存储方式。
目前，AutoMQ 作为一个开源项目，已经取得了显著的进展。我们拥有超过 4,000 个全球关注者（Stargazer），其中 70% 来自海外。此外，我们有 40 多位核心贡献者，大部分来自 AutoMQ 社区，同时也包括国内外知名互联网公司，如新加坡的互联网巨头 Globe，以及国内的知乎、小红书和京东等。这些公司都积极参与了社区的贡献。因此，如果大家对 AutoMQ 感兴趣，欢迎加入我们的社区。任何形式的贡献都是欢迎的。
随着数字化时代的到来，流数据（streaming data）已成为企业数据处理的重要组成部分。从 Apache Kafka 的诞生到如今的云原生流处理技术，这一领域经历了翻天覆地的变化。
自 2011 年起，Apache Kafka 凭借其高性能、高吞吐量的架构优势，迅速成为实时数据存储的事实标准。Kafka 的无共享架构、仅追加日志、零拷贝和批处理等特点，奠定了流处理技术的基础。随后，在 Kafka 的基础上，Confluent 和 Redpanda 等商业化公司相继诞生，推动了流处理技术的进一步发展。
Confluent 通过引入 KRaft（Kafka Raft）和分层存储架构，解决了基于 ZooKeeper 的分布式架构的痛点，并缓解了 Kafka 在云上部署时的高成本问题。而 Redpanda 则使用 C++ 重写 Kafka，并采用 Raft 协议替换 ISR（In-Sync Replicas）协议，提高了性能和可靠性。
然而，真正的变革发生在 2023 年。随着云原生技术的崛起，WarpStream 和 AutoMQ 等云原生流处理解决方案应运而生。这两家公司都采用了云原生架构，实现了流处理技术的进一步优化。
AutoMQ 作为云原生流处理技术的代表，采用了完全存算分离的架构。通过将存储层替换为云存储（如 S3），AutoMQ 实现了真正的共享存储架构。这一创新不仅充分利用了云存储的成本优势，还保持了与 Kafka 的 100% 兼容性，使得用户可以无缝迁移至 AutoMQ。
与 WarpStream 相比，AutoMQ 在保持高性能和低延迟方面表现出色。WarpStream 虽然也将 Kafka 架构构建在 S3 之上，但由于 S3 的延迟问题，其端到端（E2E）延迟可能超过一秒钟。此外，WarpStream 由于完全重写了 Kafka，因此在兼容性方面仍面临挑战，尚未完全兼容 Kafka 的所有 API 和功能特性。
而 AutoMQ 则通过其独特的架构设计，既保持了与 Kafka 的完全兼容性，又充分利用了云存储的优势。其存算分离的架构使得数据存储和计算可以独立扩展，提高了系统的灵活性和可扩展性。同时，AutoMQ 还支持多种云服务和框架的集成，如 AWS、Azure 和 Kubernetes 等，使得用户能够更加方便地将其部署到云环境中。
完全存算分离：通过将存储层与计算层分离，实现了数据存储和计算的独立扩展。共享存储架构：利用云存储作为共享存储介质，提高了数据的可靠性和存储效率。100% 兼容性：与 Kafka 完全兼容，用户可以无缝迁移至 AutoMQ。高性能和低延迟：通过优化架构设计和算法实现，提供了高性能和低延迟的数据处理能力。多云服务支持：支持多种云服务和框架的集成，方便用户部署和管理。在数据流处理的广阔领域中，AutoMQ 凭借其创新技术脱颖而出，为用户提供了一个高效、低成本且易于扩展的流数据处理平台。这一创新的核心在于 AutoMQ 引入的 S3Stream 共享流存储库，以及其对 Kafka 架构的重构。
AutoMQ 的技术创新主要集中在存储层面。为了打造一个理想的流数据存储解决方案，AutoMQ 开发了 S3Stream。这一存储库结合了 Elastic Block Store（EBS）和 Amazon Simple Storage Service（S3）的优势，为用户提供了一个低延迟、高吞吐、低成本且容量无限的共享流存储环境。S3Stream 之所以被称为“流存储库”，是因为它不是一个存储服务（Service），而是一个可以直接嵌入到 Kafka Broker 中的库（Library）。这种设计避免了存算分离带来的高昂运维成本和资源开销。传统的存算分离架构需要维护一套独立的计算集群和存储集群，而 S3Stream 作为库的存在，使得这一需求得以简化。
在流存储领域，对存储介质的要求极高，单一的云存储服务往往无法满足所有需求。例如，S3 虽然成本低廉且容量巨大，但延迟较高，不适合需要低延迟的场景。而 EBS 虽然提供了低延迟和高 IOPS（输入/输出操作每秒），但成本相对较高。为了解决这个问题，AutoMQ 巧妙地采用了 EBS 和 S3 的组合。EBS 被用作写前日志（WAL），提供低延迟和高持久性，确保数据在写入主存储前的安全性和可靠性。每个 Broker 使用的 EBS 大小仅为 10GB，成本极低，例如在 AWS 上，10GB 的 GP3 磁盘每月费用不到 1 美元。而 S3 则作为主存储，提供低成本和高容量，满足大规模数据存储的需求。
Kafka 架构的重构，引入 S3Stream 后，AutoMQ 对 Kafka 架构进行了全面重构。这一重构带来了以下显著变化：移除 ISR 复制协议：由于 S3Stream 本身提供了高持久性和数据冗余，Kafka 不再需要 ISR（In-Sync Replicas）复制协议。这一变化不仅降低了存储成本，还减少了计算和网络开销。替换存储层：Kafka 的存储层被完全替换为 S3Stream，使得 Broker 变得无状态。这意味着 Broker 不再依赖本地磁盘，可以像部署微服务一样轻松部署和扩展。这一变化极大地简化了 Kafka 集群的管理和运维。弹性架构：通过自动控制器（Auto Controller），AutoMQ 实现了弹性架构。自动伸缩（Auto Scaling）功能根据集群的负载情况动态调整资源，实现动态扩容和缩容。而自动负载均衡（Auto Balancing）功能则通过动态迁移分区，消除热点问题，确保集群的负载均衡。分区迁移速度可达秒级，进一步提升了系统的响应速度和稳定性。AutoMQ 采用云原生架构，旨在提供高效、可扩展和可靠的消息流处理服务。其核心组件包括自动控制器、无状态代理和共享云存储等。
自动控制器：负责根据工作负载自动扩展或缩减资源，以及通过动态重新分配任务来最小化热点问题。无状态代理：通过 S3Stream 解耦持久性，使代理变为无状态。这进一步简化了代理的管理和运维，并允许使用成本更低的现货实例（Spot Instances）来进一步降低成本。共享云存储：由 EBS 和 S3 提供高持久性存储。数据存储在共享云存储中，无需进行复制，降低了存储成本。AutoMQ 通过引入 S3Stream 和重构 Kafka 架构，成功打造了一个高效、低成本且易于扩展的流数据处理平台。
S3Stream 作为 AutoMQ 的核心组件，通过灵活的存储介质选择和高效的数据处理流程，为流数据处理提供了强大的支持。这种设计不仅满足了低延迟和高吞吐的需求，还确保了系统的低成本和高可用性。
S3Stream 是整个 AutoMQ 架构的核心组件。它由共享的 WAL（Write-Ahead Logging，预写日志）和 S3 存储组成，提供了高效的数据持久化和存储管理。
数据处理流程数据写入：数据从生产者发出后，会持久化写入到 WAL 中。WAL 是一种自带持久性保障的存储介质，通常使用 EBS（Elastic Block Store，弹性块存储）。数据通过直接 I/O（Dio）的方式写入到 WAL 中，确保低延迟和高吞吐量。数据上传：数据写入 WAL 后，会通知客户端。随后，数据会被一步上传到对象存储（如 S3）。数据读取：热读（Hot Read）：消费者如果是热读，会直接从缓存（Cash）中读取数据。冷读（Cold Read）：消费者如果是冷读，会从 S3 中读取数据。为了加速冷读效率，系统会采用一些读取优化机制。存储介质的选择S3 存储：S3 是由各大云厂商提供的对象存储服务，国内外的云厂商基本都兼容 S3 协议。S3 提供了高可用性和低成本的存储解决方案。WAL 存储：WAL 的实现方式较为灵活，可以选择 EBS 作为 WAL，也可以选择具备 Region 级容灾能力的 Regional EBS 作为 WAL，甚至可以选择本地的分布式文件系统（如 HDFS）作为 WAL 的实现。如果业务对延迟不敏感，也可以选择 S3 作为 WAL。架构优势AutoMQ，作为一款创新的流数据处理平台，通过其独特的架构设计，在成本效率、运维效率和兼容性方面展现出了显著优势。这些优势使得 AutoMQ 成为云环境中部署和使用的理想选择，为流数据处理带来了全新的解决方案。
成本效率：实现高达 10 倍的成本效益AutoMQ 在成本效率方面表现出色，通过优化存储和计算资源的使用，实现了高达 10 倍的成本效益。
在存储成本上，AutoMQ 采用了单副本 S3 存储方案。这种存储方式具有 11 个 9 的持久性（99.999999999%），无需数据复制，从而大大降低了存储成本。与传统的三副本 EBS 存储相比，AutoMQ 的存储成本显著降低。例如，在 Apache Kafka 中，存储成本可能高达 2095.71 美元/月，而在 AutoMQ 中，这一成本降至 257.38 美元/月，仅为前者的约 12%。
在计算成本上，AutoMQ 的弹性架构能够根据业务需求动态调整资源，避免了过度配置和资源浪费。这种动态调整能力使得 AutoMQ 的计算成本也显著低于 Apache Kafka。例如，Apache Kafka 的计算成本可能达到 3054.26 美元/月，而 AutoMQ 的计算成本仅为 201.46 美元/月，约为前者的 6.6%。
运维效率：显著提高运维操作的灵活性和速度AutoMQ 的无状态架构极大提高了运维效率，特别是在分区迁移和扩容操作方面。
在分区迁移上，Apache Kafka 需要将整个分区数据从一个 Broker 迁移到另一个 Broker，耗时较长。例如，对于 100GB/s 的数据摄入率，存储 30 天的数据，分区迁移可能需要 3 小时。而在 AutoMQ 中，由于数据存储在 S3 上，分区迁移只需修改元数据，耗时仅需 1.5 秒，大大提高了分区迁移的效率。在扩容操作上，Apache Kafka 需要将大量分区迁移到新节点，耗时同样较长。扩容操作可能涉及数百个甚至上千个分区的迁移，耗时可能达到数天。而在 AutoMQ 中，扩容操作可以分批进行分区迁移，只需修改少量元数据即可完成，耗时仅需 1 分钟左右。这种高效的扩容操作使得 AutoMQ 能够轻松应对业务增长带来的挑战。
兼容性：与 Apache Kafka 保持 100% 的兼容性AutoMQ 与 Apache Kafka 社区保持紧密的联系和合作，确保了与 Apache Kafka 的 100% 兼容性。AutoMQ 通过了社区所有的E2E测试用例，并支持社区所有的 KIP 功能，包括最新的功能如 Idempotent Producer、Compact Topic 和事务消息等。此外，AutoMQ 还支持从 0.9 版本到最新版本的 Apache Kafka 客户端，确保了与不同版本的 Apache Kafka 的兼容性。这种广泛的兼容性使得 AutoMQ 能够无缝接入现有的 Apache Kafka 生态系统，为用户提供了更多的选择和灵活性。
03
Table Topic 与 S3 Tables 和 Iceberg 的集成
AutoMQ Table Topic 通过从共享存储到共享数据的转变，实现了数据的高效存储和共享。这一架构不仅简化了数据处理流程，还提高了数据的可用性和分析效率，为数据密集型应用提供了强大的支持。
在当今数据密集型应用中，数据最终都会存储在对象存储上。这一趋势已经非常明显，无论是数据库还是监控领域，许多组件都将数据存储在对象存储上。然而，尽管数据存储在对象存储上，但由于各个系统采用不同的数据格式，数据共享仍然面临挑战。传统的解决方案需要通过 ETL（Extract, Transform, Load）管道将数据从一个系统转换到另一个系统，这不仅复杂而且效率低下。
AutoMQ Table Topic 的初衷是实现从共享存储到共享数据的转变。具体来说，所有数据源都以标准格式将数据写入对象存储，任何系统都可以通过 Zero ETL 的方式访问这些数据。这一目标的实现得益于 Iceberg 等开放的数据湖表格式，它们为数据共享提供了标准化的格式。
Table Topic 希望实现：
实时数据处理：实时数据通过 Kafka 协议写入日志存储，Kafka API 作为市场标准，被广泛用于实时数据处理。Flink 和其他 Kafka 消费者可以通过 Kafka API 消费这些数据，挖掘实时数据的价值。数据持久化：当数据失去实时价值后，通过简单的方式将数据转换为表格格式并存储在对象存储中。这一过程无需复杂的 ETL 管道，实现了数据的高效持久化。数据分析：存储在对象存储中的数据可以通过 Hive、Spark、ClickHouse 和 Presto 等数据分析工具进行查询和分析，实现了 Zero ETL 的数据访问。Table Topic 是 AutoMQ 中的一种新型主题，它同时支持日志（Log）和表格（Table）两种形态。这种设计使得 Table Topic 能够在流数据处理和数据分析之间架起桥梁，实现流数据的实时分析和处理。
Table Topic 的架构主要由以下三个核心组件组成：
Schema/Catalog Management（模式/目录管理）内置 Kafka 模式注册表：Table Topic 提供了一个内置的 Kafka 模式注册表。当创建 AutoMQ 集群后，用户会获得一个模式注册表的入口点。将该入口点配置到 Kafka 客户端中，流数据可以以模式化的方式写入 AutoMQ。自动模式演变：Table Topic 支持自动模式演变。当数据源的模式发生变化时，这些变化会自动同步到 Iceberg 表的模式中。支持 AWS Glue 和 Table Bucket 作为目录：Table Topic 支持使用 AWS Glue 和 Table Bucket 作为 Iceberg 的目录服务，方便数据的存储和管理。Table Coordinator（表协调器）每个主题都有一个表协调器：每个 Table Topic 都有一个表协调器。表协调器可以理解为一个控制器，它与每个 Table Topic 的分区 0 一起运行。协调器迁移：如果分区 0 从 Broker A 迁移到 Broker B，表协调器也会在新的 Broker 上重新启动。集中协调：表协调器负责集中协调 Iceberg 快照的提交，减少提交频率，避免性能冲突。表协调器会定期广播提交请求，确保所有分区的数据一致提交。Table Workers（表工作节点）嵌入在 AutoMQ 代理中：Table Workers 嵌入在 AutoMQ 的代理节点中。每个 Broker 上的每个 Table Topic 都有一个 Table Worker。数据写入：Table Worker 负责将所有分区的数据高效地转换为 Iceberg 表格式，并写入对象存储。资源优化：Table Workers 之间会共享一些资源，如连接池和内存，以降低 Iceberg 写入的整体资源消耗。通信机制：Table Coordinator 和 Table Workers 之间通过内置的控制主题进行通信。例如，当某个分区需要触发提交时，会在控制主题中写入提交请求事件，Table Workers 会订阅这些事件并进行相应的提交操作。数据摄入：数据从各种数据源（如数据库、日志等）流入 AutoMQ Table Topic。模式管理：数据通过内置的 Kafka 模式注册表进行模式化处理，确保数据的一致性和兼容性。数据写入：Table Workers 将数据从所有分区高效地转换为 Iceberg 表格式，并写入对象存储。提交协调：Table Coordinator 通过控制主题协调所有分区的提交操作，确保数据的一致性和完整性。数据查询：存储在 Iceberg表中的数据可以通过各种计算引擎（如 Spark、Presto、Hive 等）进行查询和分析。基于上述架构，AutoMQ 就可以同时支持流存储和表存储，将数据从数据源摄入到 AutoMQ 当中，再以 Iceberg 形式存储，继而就可以供 Spark、Flink、Presto 等计算引擎进行大规模的离线分析。
AutoMQ Table Topic 通过其简单易用的部署、内置模式注册表、Zero ETL、弹性扩展和与 AWS S3 表的无缝集成等优势，为用户提供了高效、便捷和稳定的数据处理解决方案。这些优势使得 Table Topic 成为桥接流数据和分析数据的理想选择，帮助用户更好地利用数据，提升业务价值
简单易用的部署AutoMQ Table Topic 的部署非常简单，只需一键即可完成设置。在创建 AutoMQ 集群时，用户只需点击一下即可启用该功能，无需额外配置。这与传统的数据处理流程相比，大大简化了部署过程。以前，为了将 Kafka 中的数据消费并写入 S3，需要配置 Flink Connect 或 Kafka Connect 集群，整个链路的配置复杂度和资源消耗都较高。而 Table Topic 的一键部署功能，完全消除了这些额外的配置需求。
内置模式注册表AutoMQ Table Topic 提供了内置的 Kafka 模式注册表。这一功能确保了数据的一致性和兼容性，使得用户无需担心数据格式的变化。内置模式注册表的自动创建和管理，使得用户可以专注于数据处理本身，而无需花费额外的时间和精力在模式管理上。
Zero ETLAutoMQ Table Topic 采用 Zero ETL（Extract, Transform, Load）的设计理念，消除了传统的 ETL 管道。这意味着用户无需进行数据转换，从而节省了大量的计算和网络资源。Zero ETL 的设计不仅降低了成本，还减少了操作的复杂性，使得数据处理更加高效和便捷。
弹性扩展AutoMQ Table Topic 具备弹性扩展的能力，能够根据数据摄入速率无缝扩展。通过 Auto Scaling 和 Auto Balancing 控制器，Table Topic 可以动态调整资源分配，确保系统的高效运行。具体来说，Table Topic 可以根据流量和存储需求，自动进行分区的迁移和资源的调整。例如，当某个分区的流量过大时，系统会自动进行扩容，并将分区迁移到新的节点，同时 Table Worker 也会随之迁移。这种弹性扩展的能力，使得用户无需担心资源不足的问题，系统会自动进行调整，确保数据处理的高效性和稳定性。
与 AWS S3 表的无缝集成AutoMQ Table Topic 与 AWS S3 表实现了无缝集成。利用 S3 表的高性能、集成目录和表维护功能，Table Topic 能够高效地存储和管理数据。此外，Table Topic 还与 AWS 的分析产品（如 Athena、EMR、Redshift、QuickSight 等）无缝集成，使得用户可以方便地进行大规模数据分析。未来，Table Topic 还将与腾讯云等其他云厂商的大数据生态系统进行深度整合，进一步提升其功能和性能。
AutoMQ 在各大云市场上提供的产品形态为 BYOC（Bring Your Own Cloud），这意味着 AutoMQ 可以完全部署在客户的账户和 VPC（Virtual Private Cloud）中。用户只需在云厂商的云市场上订阅该产品，即可完成软件的安装。安装完成后，用户将获得一个控制面板，用于管理和监控 AutoMQ 的运行状态。
在控制面板中创建集群时，可以为其配置一个目录（Catalog），例如 AWS Glue 或 Table Bucket。配置好目录后，在 AWS S3 控制台上创建一个 Table Bucket，并将该 Table Bucket 的 ARN（Amazon Resource Name）填写到指定位置。这样，我们就创建了一个支持 Table Topic 的集群。
在创建 Topic 时，可以通过点击“启用 Table Topic”按钮来启用该功能。具体步骤如下：
①配置 Table Topic 参数：
Catalog Type：选择 Table Bucket。Table Bucket ARN：填写 AWS S3 表的 ARN，例如 arn:aws:s3:::your-bucket-name。IAM Policy：配置 IAM 策略，确保 AutoMQ 实例具有访问 S3 表的权限。②创建 Topic：
Topic Name：输入主题名称，例如 test-topic。Partitions：设置分区数量，例如 16。Cleanup Policy：选择清理策略，例如 delete 或 compact。③启用 Table Topic：
在 Advanced Settings 中，确保 automq.table.topic.enable 设置为 true。Schema Type：选择 schema 作为 Schema 类型。通过以上步骤，即可创建一个启用 Table Topic 的 AutoMQ 实例，并开始使用该功能进行数据处理和分析。
3.使用 Schema 将 Clickstream 数据发送到 Table Topic在控制面板中完成上述配置后，我们可以准备一些数据。这里我们准备了一些 clickstream 数据
发送数据通过 Kafka 的 Avro producer，我们可以将这些数据发送到 Table Topic 中。
通过上述步骤，我们可以将 clickstream 数据成功发送到 Table Topic 中，并利用其 schema 进行数据处理和分析。
4.通过 AWS Athena 查询 Table Topic 中的数据通过 AWS Athena，我们可以轻松地对存储在 Table Topic 中的数据进行查询和分析。通过编写 SQL 查询语句，可以直接从 AWS Athena 中查询和分析存储在 S3 表中的数据。这种集成方式使得数据查询和分析变得更加便捷和高效，充分利用了 AWS Athena 的强大查询能力和 AutoMQ Table Topic 的数据存储优势。
从 Apache Kafka 的传统架构开始，逐步演进到 AutoMQ 的共享存储架构，最终发展到共享数据架构。这一过程不仅展示了技术的演进，还突显了架构升级带来的成本优势和数据共享的可能性。
Apache Kafka 最初是为本地的 On-Premise 环境设计的，采用了一种典型的分片（Shared-Nothing）架构。这种架构通过将数据分散到多个节点上，解决了 IDC 环境中的可扩展性问题。然而，随着云计算的发展，这种架构在成本和可扩展性方面逐渐显现出局限性。
为了解决传统 Kafka 架构的局限性，AutoMQ 采用了云原生技术，将 Kafka 升级到了共享存储（Shared-Storage）架构。这种架构利用了云存储的成本优势和云计算的规模化红利，通过技术手段释放了这些优势。具体来说，AutoMQ 通过以下方式实现了这一目标：
云存储的利用：将数据存储在云存储中，充分利用了云存储的低成本和高可用性。计算资源的弹性扩展：支持自动扩展和负载均衡，能够根据工作负载动态调整计算资源，从而降低成本。无状态代理：将持久性解耦到云存储，使代理节点变得无状态，可以使用成本更低的现货实例（Spot Instances），进一步降低成本。通过这些改进，AutoMQ 相比传统的 Kafka 架构在成本上具有显著优势，能够为用户提供超过 50% 的成本节省。
随着数据湖和大数据分析的发展，共享数据（Shared-Data）架构逐渐成为趋势。特别是随着 Iceberg 等数据湖格式的标准化，数据共享变得更加容易。AutoMQ 通过引入 Iceberg，实现了从共享存储到共享数据的升级。这一升级带来了以下优势：
无缝集成：AutoMQ 与 Iceberg 无缝集成，支持直接查询和分析存储在 S3 表中的数据。高效查询：通过 Iceberg 的优化查询机制，AutoMQ 能够提供低延迟、高吞吐量的数据查询能力。数据湖的扩展：AutoMQ 支持将数据湖扩展到流数据，实现了流数据与分析数据的无缝连接。AutoMQ Table Topic 正在快速迭代和发展，未来将支持更多的目录类型、增强 CDC 功能，并提供更强大的表维护功能。这些改进将使 AutoMQ Table Topic 成为流数据处理和分析领域的领先工具，帮助用户更高效地管理和分析实时数据。
通过上述功能的实现，AutoMQ Table Topic 将能够更好地支持各种数据处理场景，提供更高效、更灵活的数据管理和查询能力。我们期待这些功能能够为用户带来更优质的体验，助力企业更高效地利用数据资源。
Q1：在将数据从 Kafka 转换到 Iceberg 时，如何处理分区策略？
A1：在 AutoMQ Table Topic 中，Kafka 的分区和 Iceberg 的分区没有必然联系。默认情况下，Table Topic 会创建一个无分区的表，并以无分区的方式写入数据。用户可以根据需要在 Iceberg catalog 中修改表的分区策略，例如按天或按小时分区。Table Topic 会检测到分区策略的变更，并在后续的数据写入中按照新的分区规则进行写入。
Q2：AutoMQ Table Topic 是否会与 Amoro 等工具产生冲突？
A2：不会。Table Topic 的重点是流式数据无缝入湖，是能跟 Amoro 等工具配合使用的，比如通过 Amoro 来管理 AutoMQ 产生的 Topic。Amoro 自身提供了很多 Table 的 Maintenance 功能，AutoMQ 完全可以兼容。但考虑到很多客户没有这些技术设施，所以 Table Topic 也会提供内置的 Maintenance 功能，这部分功能跟 Amoro 会有一些冲突，但因为 Iceberg 本身保证了事务性，不会产生正确性问题。
Q3：在国内云上使用 AutoMQ 时，是否会受到对象存储的限制？
A3：确实，国内云厂商的对象存储在吞吐量上可能会有一些限制。例如，阿里云的读取吞吐量可以达到 100Gib/s，写入吞吐量默认是 20Gib/s，而腾讯云的限制会稍低一些。然而，根据我们的服务经验，客户可以通过与云厂商沟通，调整这些限制。例如，得物和吉利等客户已经成功地将阿里云的吞吐量调整到了 10GiB/s+级别。
Q4：AutoMQ 的架构优势是什么？
A4：AutoMQ 的架构优势主要体现在其存储分离的架构上。在云原生时代，存储分离的意义在于利用云服务的持久性和运维保障，而不是在云存储之上再搭建一套分布式存储软件。云存储已经实现了类似分布式文件系统（DFS）的功能，例如 EBS 背后的DFS。因此，AutoMQ 的架构设计更加简洁和高效，避免了传统架构中的冗余和高成本。
Q5：AutoMQ Table Topic 的未来规划是什么？
A5：AutoMQ Table Topic 计划在未来支持更多的目录类型，例如 Hive Metastore Server 和 Iceberg REST Catalog。此外，还将支持行变更和更新模式，包括更新/删除行和 Upsert 模式，以更好地处理 CDC（Change Data Capture）场景。同时，Table Topic 将提供更强大的表维护功能，如压缩数据文件、过期快照、删除旧元数据文件和删除孤立文件。
Q6：AutoMQ Table Topic 的新版本何时发布？
A6：Table Topic 当前版本已经在 AWS 上可用，新版本将覆盖更多的云服务厂商，预计将在 2 月底发布。如果您对新版本感兴趣，可以留下联系方式，我们会在新版本发布后与您联系。
Q7：AutoMQ Table Topic 可以应用于哪些场景？
A7：AutoMQ Table Topic 可以应用于多种场景，包括但不限于：
数据湖集成：通过与 AWS S3 Table 和 Iceberg 的无缝集成，实现数据湖的高效管理和查询。实时分析：支持实时数据摄取和分析，帮助企业在数据生成的同时进行决策。CDC 场景：通过支持行变更和更新模式，轻松处理 CDC 场景，实现数据的实时同步和更新。Q8：AutoMQ Table Topic 的技术优势是什么？
A8：AutoMQ Table Topic 的技术优势包括：
单次点击启用：只需一次点击即可启用 Table Topic，轻松将数据流传输到 Iceberg 表中，实现连续的实时分析。内置 Schema Registry：内置的 Kafka Schema Registry 开箱即用，支持自动模式演变。零 ETL：消除了传统的 ETL 流程，显著降低了成本和运营复杂性。自动扩展：支持自动扩展和负载均衡，能够无缝处理从数百 MiB/s 到数 GiB/s 的数据摄入速率。与 AWS S3 Table 的无缝集成：利用 S3 Table 的目录服务和维护功能，如压缩、快照管理和未引用文件删除，促进大规模数据分析。来源：DataFunTalk
