亚马逊云科技Amazon MSK为企业构建实时数据架构提供坚实基础

关键字: [亚马逊云科技中国峰会2024, 实时数据分析, 消息队列产品, 托管卡夫卡服务, 数据迁移策略, 可靠性最佳实践]

本文字数: 2300, 阅读完需: 12 分钟

导读

汤世健在亚马逊云科技中国峰会2024上介绍了托管Kafka服务MSK。他解释了实时数据分析的重要性,以及Apache Kafka在实时数据流处理中的关键作用。MSK作为亚马逊云科技托管的Kafka服务,可以避免自建Kafka集群的诸多挑战,如基础设施维护、扩展困难、高可用性等。MSK与其他亚马逊云科技分析服务(如Athena、Kinesis、Redshift等)无缝集成,支持实时数据分析和流式数据仓库等场景。他还介绍了MSK的可靠性最佳实践、监控方案、迁移策略等,帮助用户顺利上云使用MSK服务。

演讲精华

以下是小编为您整理的本次演讲的精华，共2000字，阅读时间大约是10分钟。

在当今时代,数据已经成为组织中最宝贵的资产之一。然而,要真正从海量数据中挖掘出价值,并非易事。根据一份开源报告显示,数据量正在以惊人的速度不断膨胀,这给企业带来了巨大的挑战。幸运的是,通过高质量数据和高级分析驱动业务决策,企业的收入可以实现1.7倍的增长,这从侧面证明了数据挖掘和分析对企业的重要性。

数据通常可以分为两种类型:流式数据和离线数据。离线数据一般在数据仓库场景下进行ETL处理,并进行OLAP的维度分析;而对于流式数据,更多的是进行实时计算或流式数据仓库等操作。流式数据之所以备受关注,是因为它允许我们以更实时的方式访问所需数据,并以更低的成本和更快的速度获取数据价值。

在处理流式数据的过程中,Apache Kafka这一开源消息队列发挥着关键作用。Kafka已经在各种生产系统中广泛使用多年,并在消息队列、服务通信、应用程序用户行为日志等不同场景中得到了广泛应用。

然而,在部署自建Kafka集群时,企业往往会面临一些挑战。首先,需要在自己的IDC中部署Kafka集群,包括Zookeeper、Broker等组件,并启用多个节点来维护底层基础设施,包括操作系统升级补丁等。其次,在本地IDC中很难根据流量或负载进行动态扩展。再者,要实现高可用性,通常需要进行多机房数据同步,这对IDC来说是一个额外的成本。最后,在开发时,需要使用SDK或第三方工具编写Producer/Consumer代码,来对Kafka进行读写操作。特别是当集群规模膨胀到几十甚至几百个节点时,管理和运维的复杂性将成指数级增长。

基于这些挑战,亚马逊云科技推出了托管版本的Kafka服务,名为Managed Streaming for Apache Kafka (MSK)。我们可以用一张图来简单对比托管Kafka和自建Kafka的区别。最左边是本地IDC自建Kafka,需要维护基础设施硬件、操作系统,以及上层应用Zookeeper、Broker的安装,同时难以实现扩展和高可用。如果在Amazon EC2上部署,它只解决了底层基础设施和操作系统这一级别的托管,但对上层应用还需要大量运维管理。相比之下,MSK从底层硬件设施到上层软件设施,以及高可用和扩展等方面,都提供了完善的托管服务。亚马逊云科技推出MSK的目的,就是希望客户能够将精力集中在业务开发上,而不必过多关注底层基础设施和集群管理运维。

避免不了的一个问题是,如何将现有的负载从本地Kafka集群迁移到云上的MSK。对于迁移部分,我们会使用开源著名的Mirror Maker 2.0工具。Mirror Maker底层原理基于Kubernetes环境,它会提供两类Task:Source Task专门读取原始Kafka消息,Sync Task将读取的消息直接写入目标Kafka集群,通过这种模式实现数据同步。亚马逊云科技提供了相应的Workshop,可以帮助客户快速了解Mirror Maker 2.0机制,并上手进行同步操作。

同步分为以下几个步骤:首先,我们有一个本地自建的Kafka集群,有生产者和消费者对它进行读写操作。此时需要设置好Mirror Maker 2.0 Connect环境,无论是在CloudWatch还是EC2上都可以部署该环境。Connect启动后会开始从源Kafka读取所有Topic的消息,并写入目标端。在这个过程中,可以切换消费者,停止原有Consumer,并重启使用新的Broker列表地址。注意,需要确保消息能够继续被消费,这涉及到Offset管理的问题。我们常规的Consumer Group在消费后会将Offset存储在__consumer_offsets Topic中。Mirror Maker支持将原集群Consumer Offset实时同步到目标端,因此在切换时可以使用之前的消费位点继续消费,无需从头开始消费。消费者切换后,停止生产者,等待消费到最新位点,然后重启生产者对新集群生产消息即可。

需要注意的是,由于Mirror Maker基于Connect环境,它不能保证Exactly Once语义,只提供至少一次消息传递语义。也就是说,在同步过程中出现故障重启时,消息有可能重复。对于重复消息的处理,一般需要在消费阶段进行幂等处理。如果下游是NoSQL或ElasticSearch这种有幂等引擎的系统,重复写入没有问题。如果是MySQL这种系统,就需要处理数据重复的问题。

相比于开源Kafka,MSK的一大优势在于与亚马逊云科技上其他分析服务的无缝集成。首先是Athena,这是亚马逊基于开源Trino部署的托管OLAP引擎,它基于内存计算,速度快,通常用于进行临时性的Ad-Hoc查询。Athena目前支持以Connect方式直接消费MSK的数据,直接读入内存进行探索分析。

第二是亚马逊的托管Flink和托管Spark服务。我们可以使用开源的Flink Kafka Connector或Spark Kafka Connector直接消费MSK数据,因为MSK对于开源Kafka来说,API是完全兼容和一致的,所以可以完全使用开源的Producer或Consumer代码。

第三是Firehose,它是一个数据传递服务。通过Firehose,我们可以将Kafka数据按日期分区落盘到S3,或者写入OpenSearch/ElasticSearch等,并提供了可视化界面进行配置,无需编写任何Producer/Consumer代码。

第四是Redshift,亚马逊的数据仓库产品,一般用于多维分析和宽表Join等操作。Redshift与Kafka集成的一个重点功能是Streaming Ingestion,也称为流式数据仓库。其概念是将实时消息队列数据以秒级的方式同步到数据仓库,并以表格形式快速分析这些实时数据内容。通过Streaming Ingestion,我们可以在秒级将Kafka Topic数据直接同步到Redshift,并在Redshift中以表的形式探索Kafka消费过来的数据。根据测试,在60MB/s的数据量下,Redshift可以轻松应对这种场景。

此外,亚马逊的托管Spark平台Glue DataBrew也可以使用开源Connector连接MSK。

在监控方面,MSK除了提供标准的CloudWatch监控指标外,还提供了Prometheus接口,方便已有Prometheus监控系统的客户将MSK的监控数据集成到统一的Prometheus监控系统中。对于日志,MSK提供了File Host功能,可以将Broker日志和Zookeeper日志导出到CloudWatch Logs、S3或OpenSearch,方便进行故障排查。

为了确保MSK的可靠性,亚马逊云科技提出了一些最佳实践建议。首先是建议多AZ部署,最佳实践是3个AZ的集群,以提高可用性。其次,Broker的副本因子至少为3,min.insync.replicas设置为replication.factor-1,这样可以防止在下线节点时导致数据丢失。在Producer端,建议将acks设置为all,开启无限制重试以及设置最长等待时间,并开启幂等Producer以防止重试导致的消息重复。在Consumer端,建议使用主动commit offset机制,在确定消息消费完成后再提交offset到Kafka,以确保消息不会丢失。

由于在运维过程中,MSK会进行证书更新、安全补丁等操作,它的基本逻辑是通过滚动升级的方式,每次下线一台Broker进行升级,然后重启,所以遵循可靠性最佳实践配置非常重要,否则可能会导致Producer停止写入或数据丢失的情况发生。

对于MSK的规模计算,亚马逊云科技提供了一个专门的计算器,客户可以根据自己的流量、日志保存期、副本因子等配置,快速计算出所需的MSK集群规模及相应的成本估算。

在现场环节,一位观众提出了一个问题:在3个AZ的部署中,如果出现故障,MSK是如何进行Failover和恢复的?汤世健解释说,如果一个节点由于硬件故障而宕机,亚马逊云科技层面会先拉起一个新的Broker节点顶替故障节点。在Kafka层面,Failover更多是针对Topic或Partition级别的。如果下线的是In-Sync Replica,不会影响读写;如果是Partition Leader宕机,Kafka会自动从现有同步副本中选举出一个新的Leader,继续服务读写请求,这是一个自动化的过程。

另一位观众问及,除了亚马逊云科技之外,其他云厂商如谷歌或阿里是否提供类似的托管Kafka服务?汤世健表示,他们一般不会直接比较自家产品与竞品的优劣,而是更多关注客户的具体场景,并提供合适的解决方案来满足客户需求。

又有一位观众询问MSK与Redshift的Streaming Ingestion(流式数据仓库)集成情况。汤世健解释说,Streaming Ingestion允许在Redshift中创建一个物化视图,指向Kafka的Topic,当刷新该视图时,就可以将Kafka的实时消息以秒级同步到Redshift,并以表格形式进行分析和探索。这极大加快了对实时数据(如用户行为日志)的分析能力。

最后,一位观众提出了关于MSK权限控制的问题。汤世健说明,MSK支持两种权限模式:一是与开源Kafka一致的ACL模式;二是基于IAM Role/User的权限模式,可以在Kafka中为特定Role/User限制对某个Topic的读写权限,还支持TLS加密等安全功能。

总的来说,本次演讲全面介绍了亚马逊云科技的托管Kafka服务MSK,阐述了其优势、最佳实践、与其他亚马逊云科技服务的集成、监控和成本估算等方面的内容,并通过现场问答环节进一步解答了观众的相关疑问,为企业实时数据处理提供了完整的解决方案。MSK作为亚马逊云科技生态中的重要一员,能够高效、可靠地传输和处理关键数据,满足企业对实时数据分析的需求。

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

汤世健先生在亚马逊云科技中国峰会2024上介绍了亚马逊云科技的托管Kafka产品MSK。

亚马逊云科技中国峰会2024:介绍了Redshift与Kafka集成的Streaming Ingestion功能,实现将实时消息队列数据秒级同步到数仓,以表格形式快速分析实时数据。

亚马逊云科技中国峰会2024:强调MSK可靠性最佳实践,避免在滚动升级期间出现生产者停止写入或数据丢失的情况。

亚马逊云科技中国峰会2024上,演讲者详细阐述了如何配置Kafka以确保数据的高可用性和可靠性,包括多AZ部署、副本因子设置、同步副本数量等,旨在防止数据丢失。

亚马逊云科技中国峰会2024:深入探讨MSK与亚马逊云科技数仓产品Redshift的无缝集成,实现流式数据高效入仓

亚马逊云科技中国峰会2024:借助Redshift的流式摄入功能,可实现秒级分析用户行为日志,洞悉用户行为洞察。

亚马逊云科技中国峰会2024上,演讲者介绍了Amazon MSK提供的两种权限管理模式:基于开源的ACL和将IAM权限管理融入MSK,并支持常规加密如TLS等。

总结

亚马逊云科技的托管Kafka服务MSK为企业提供了一种高效、可靠的实时数据传输解决方案。MSK消除了自建Kafka集群的运维复杂性,提供了动态扩展、高可用性和与其他亚马逊云科技分析服务的无缝集成。通过Mirror Maker 2.0,企业可以轻松将现有Kafka集群迁移到MSK,实现数据流的平稳过渡。为确保可靠性,MSK建议采用多可用区部署、适当的副本因子和同步副本设置,以及生产者端的重试和幂等性配置。凭借亚马逊云科技的托管服务,企业可将精力集中于业务创新,充分释放实时数据分析的价值潜力。

MSK与亚马逊云科技分析服务如Athena、Kinesis、Firehose和Redshift等紧密集成,为企业提供了端到端的实时数据处理和分析能力。例如,通过Redshift的Streaming Ingestion功能,企业可以秒级将Kafka数据同步到数仓,实现对实时用户行为等数据的快速探索和分析。MSK的安全性也得到了保证,支持开源Kafka的ACL模式,同时可与Amazon Web Services IAM权限模型无缝集成。总之,MSK为企业构建现代化的实时数据架构提供了坚实的基础,助力企业从海量数据中挖掘洞见,推动业务创新。

2024年5月29日，亚马逊云科技中国峰会在上海召开。峰会期间，亚马逊全球副总裁、亚马逊云科技大中华区总裁储瑞松全面阐述了亚马逊云科技如何利用在算力、模型、以及应用层面丰富的产品和服务，成为企业构建和应用生成式 AI 的首选。此外，活动还详细介绍了亚马逊云科技秉承客户至尚的原则，通过与本地合作伙伴一起支持行业客户数字化转型和创新，提供安全、稳定、可信赖的服务，以及持续深耕本地、链接全球，助力客户在中国和全球化发展的道路上取得成功。