关键字: [亚马逊云科技， Amazon MSK Express Broker， 亚马逊云科技， Msk Express Broker， 存储成本降低， 数据迁移方案， 客户案例分享]

导读

在这个演讲中，潘超分享了如何从标准的Broker或自建的Broker迁移到Amazon MSK Express Broker，以及相关客户案例。他解释了使用Express Broker可以降低存储成本、提高性能和扩展速度，并简化运维。具体来说，他提到Express Broker只需存储一份数据副本、提供两到三倍的性能提升和20倍的扩展速度，且无需关注存储运维和固定维护窗口。通过客户案例，他展示了Express Broker可以节省50%和34%的总体成本。他还建议在生产者写入Kafka时开启压缩，以进一步降低流量和存储成本。

演讲精华

以下是小编为您整理的本次演讲的精华。

亚马逊云科技的数据分析解决方案架构师潘超首先自我介绍，然后开始分享如何从标准的Broker或自建的Broker迁移到Express Broker，以及客户案例和Express Broker需要掌握的要点。

潘超解释道，如果当前使用的是标准的Broker，想要迁移到Express Broker，应该采取以下步骤。首先，在开源社区中，如果想要实现两个Kafka集群之间的数据同步，通常需要使用Mirror Maker One或Mirror Maker Two，而现在大多数情况下使用的是Mirror Maker Two，简称MM Two。然而，在亚马逊云科技中，我们提供了托管的Kafka Replicator，也称为MSK Replicator。它位于源MSK集群和目标MSK集群之间，能够实现同Region和跨Region两个MSK集群之间的数据同步、消费者Offsets同步以及ACL同步。而且，MSK Replicator是一个Serverless服务，不需要您自行安装和部署，类似于MSK服务本身。它会根据您的资源使用情况自动扩展。因此，如果您想从标准Broker迁移到Express Broker，实际上非常简单，只需在页面上配置MSK Replicator，就可以将数据同步到目标集群。

完成数据同步后，接下来就需要切换生产者和消费者。您可以先切换生产者，也可以先切换消费者，这两种切换方式原则上都可以，但需要根据实际场景来决定。如果您的消费者数量较多，可能在一天或一段时间内无法完成切换，那么通常情况下，我们会先切换生产者。无论您是先切换生产者还是先切换消费者，都需要注意两个问题。首先，无论切换哪一个，数据都有可能重复，因此您的下游一定需要支持幂等操作，或者在切换过程中手动进行数据去重，否则就是您的下游本身已经是幂等操作，数据重复对下游不会产生影响。另外，在某些日志分析场景中，允许数据重复也是可以的，您可以不用进行数据去重。但是，我们需要知道，MSK的Replicator上，包括MM Two，我们的语义都是At Least Once，所以原则上来讲，会有数据重复的情况，这一点需要大家注意。

同时，在切换消费者或生产者的时候，无论您是先切换生产者还是先切换消费者，都必须等到Replicator将数据完全复制到目标集群，才可以进行切换，否则将无法保证数据的原始写入顺序。比如说，如果在切换生产者时，没有等到Replicator将数据完全复制到目标集群，就会出现目标集群有两个写入源，一个是原始的生产者，另一个是Replicator集群，这两个写入源无法保证原始数据的写入顺序。因此，在切换过程中，生产者必须暂停一段时间，等到数据在两个集群之间完全同步后，再重新启动生产者，这可能是大家需要注意的一个点。

所以，在切换过程中，可能需要注意的就是这两点:第一，数据重复的问题，需要进行处理;第二，必须等到Replicator将数据完全消费，Message Lag基本为0时，再进行切换。

第二种迁移方式是双写方式，适用于生产者数量较少的场景。比如说，当前不想使用Replicator或MM Two，因为无论使用哪一个组件，都需要等到数据同步完成后再进行切换。但如果生产者数量很少，例如源头数据写入MSK的数据可能是一个源头数据库的CDC数据，或者是一些第三方组件，或者是自己编写的程序，生产者数量非常少，那么这种情况下可以通过双写的方式进行迁移。将生产者端改造成直接写入两份数据，一份写入源集群，一份写入目标集群，改造成本很低，尤其是在实验、点击流量、日志分析等场景下，生产者本身就很少，采用双写方式会非常简单和方便，中间不需要依赖任何其他组件。

但是，双写方式带来的问题是，必须接受数据重复的情况。在数据重复的过程中，下游的消费者一定要支持从Kafka的某个Offset或某个时间点开始消费，并且一定会消费出重复的那一段数据。消费完成后，无论是Sink到下游，还是下游本身，都需要支持幂等操作，或者有程序将重复的数据处理掉，这是必须要做的。

如果您是自建的Kafka集群，想要迁移到Express Broker，那么对于自建的Kafka而言，我们之前提到的Kafka Replicator实际上无法帮助我们将自建的Kafka数据直接通过同步的方式同步到目标集群上。这种情况下，我们只能使用开源的MM Two，也就是Mirror Maker Two这个组件来帮助我们进行数据同步。

MM Two的部署有两种方式。第一种方式是在EC2实例上部署一个三节点的MM Two集群，就可以将数据同步到MSK集群。一般来说，这种方式相对比较简单。第二种方式是通过MSK的Connector，您可以认为它是一个托管的、类似于开源Kafka Connect的Serverless服务，MM Two的架构本身就是基于Kafka Connect的架构。所以，您可以通过配置的形式，在MSK Connect上配置MM Two，让它帮助您完成数据的同步。这两种方式您都可以选择。

一般来说，如果您不想对MM Two进行运维，也不想管控MM Two底层的运行资源，那么您可以选择通过MSK Connect来部署。如果您的运维工程师经验丰富，可以直接在EC2实例上下载一个Kafka Connect，直接完成数据同步。

数据同步的功能与Replicator提供的功能一样，包括支持消费者Offsets的同步、ACL的全量同步，以及元数据的同步。Topic的命名也可以指定为与原名一致。切换生产者或消费者的方式也与之前介绍的相同。

只不过，对于自建的Kafka而言，我们没有一个托管的工具可以直接点一点就将数据同步过去，需要先部署MM Two。

接下来，潘超分享了两个客户案例。第一个客户的场景是，玩家的点击数据先进入MSK，然后通过MSK Connector将数据同步到S3，再使用EMR处理S3中的数据进行数据分析，最终进入数据湖。该客户面临的问题是，它使用的是标准的Kafka Broker，存储成本非常高，只能存储两天的数据，想要存储更长时间的数据面临成本压力。

所以，该客户选择迁移到Express Broker后，由于只需支付单副本的存储费用，存储成本得到了节省。Express Broker相比标准Broker，如果每天存储的数据达到2TB以上，可以节省约30%的成本，具体节省情况需要根据不同客户的数据量来计算。

这个客户在迁移时，虽然使用的是标准Broker，但并没有使用Replicator进行切换，而是采用了双写的方式，因为它的下游直接支持数据去重。切换到Express Broker后，包括存储、Broker和网络三部分的总成本节省了50%。

潘超在这里给出了一个技巧，就是如果生产者写入Kafka时开启压缩，并且对延迟不是特别敏感，那么压缩能够进一步降低流量成本和存储成本。一般情况下，如果Broker开启了压缩，生产者默认不配置就会与Broker保持一致。如果生产者配置了与Broker不一致的压缩方式，这是不推荐的。但有很多客户没有开启压缩，开启压缩后，流量成本和存储成本都会有较大节省。

第二个客户案例是将自建的多AZ部署的Kafka集群迁移到MSK Express Broker，整体成本节省了34%。该客户的场景是，源头数据来自KingBaseDB数据库的CDC数据，写入自建的Kafka集群，然后由Flink消费CDC数据，最终Sink到Doris中进行分析。

该客户自建的Kafka集群是多AZ部署的，但在2022年曾出现过一个峰值流量，由于对EBS存储的监控不足，导致Kafka集群失去响应，可用性受到挑战。同时，随着业务量的增长，数据存储也遇到了瓶颈，无法存储更多数据，面临着成本压力。因此，该客户决定迁移到Express Broker。

迁移过程中，由于是自建的Kafka集群，无法使用Replicator，因此采用了MM Two进行数据同步迁移。需要注意的是，如果自建的Kafka集群是单AZ部署，那么迁移到Express Broker可能无法节省成本，因为需要支付跨AZ的流量费用，尽管MSK Broker之间的流量是免费的，但生产者到Broker的流量需要支付跨AZ费用。由于这个客户是多AZ部署，因此迁移到Express Broker可以节省更多成本。

最后，潘超总结了Express Broker需要掌握的几个要点。首先，Express Broker相比标准Broker有2-3倍的性能提升，扩展速度提高20倍，这是它的优势所在。其次，Express Broker的存储成本优势在于，您不用再关注存储扩容的问题，只需支付单副本的存储费用，存储数据量多少就付多少费用，不用永远担心存储空间不足。如果您的数据量很少，Express Broker就无法帮助您节省存储成本。第三，Express Broker的运维非常简单，基本上不需要关注存储方面的运维。第四，Express Broker没有固定的维护窗口期，它是一个分布式系统，每个月会自动进行升级和维护，不会给您指定固定的维护窗口。

总的来说，如果您的存储数据量较大，那么迁移到Express Broker可以极大地节省存储成本。但如果数据量较少，Express Broker的优势就不太明显了。视频到此结束。

下面是一些演讲现场的精彩瞬间：

总结

亚马逊云科技MSK Express Broker助力降低存储成本的关键点:

从标准Broker迁移到Express Broker，可通过MSK Replicator或Mirror Maker Two实现数据同步，需注意数据重复和切换时机。对于自建Kafka集群，只能使用Mirror Maker Two进行迁移。客户案例显示，Express Broker能够显著降低存储成本，尤其适用于大数据量场景。此外，Express Broker还提供了更高性能、自动扩展能力、简化运维和无固定维护窗口等优势。

总的来说，Express Broker凭借其独特的存储优化设计，为客户带来了显著的成本节省，同时也提升了性能和可用性，是大数据处理的理想选择。亚马逊云科技持续创新，为客户提供更高效、更经济的解决方案。

我们正处在Agentic AI爆发前夜。2025亚马逊云科技中国峰会提出，企业要从“成本优化”转向“创新驱动”，通过完善的数据战略和AI云服务，把握全球化机遇。亚马逊将投入1000亿美元在AI算力、云基础设施等领域，通过领先的技术实力和帮助“中国企业出海“和”服务中国客户创新“的丰富经验，助力企业在AI时代突破。