关键字: [ 亚马逊云科技中国峰会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 中以表的形式探  afka 消费过来的数据。根据测试, 在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 的首选。此外，活动还详细介绍了亚马逊云科技秉承客户至尚的原则，通过与本地合作伙伴一起支持行业客户数字化转型和创新，提供安全、稳定、可信赖的服务，以及持续深耕本地、链接全球，助力客户在中国和全球化发展的道路上取得成功。