人们需要了解如何在混合云上利用云原生和无服务器Apache Kafka来处理与数据湖互补的动态数据。而Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。
如今，Apache Kafka成为处理动态数据的一个事实标准。Kafka具有开放、灵活和可扩展的特性，但也使许多团队面临运营的挑战。在理想情况下，企业的IT团队可以使用无服务器Kafka SaaS产品来专注于业务逻辑。然而，混合场景需要在一个云原生平台运行，该平台提供自动化和弹性工具来减轻运营负担。本文探讨了如何在混合云架构中利用云原生和无服务器Kafka产品，并从数据湖的静态数据的角度出发，探索它与Kafka的动态数据的关系。
1.静态数据仍然是一种正确的方法吗?
静态数据是指将数据存储在数据库、数据仓库或数据湖中。这意味着在许多用例中数据处理得太晚了——即使实时流组件(如Kafka)摄取了数据。数据处理仍然是Web服务调用、SQL查询或map-reduce批处理过程，而不是解决遇到的问题。
静止数据并不是一件坏事。报告(商业智能)、分析(批处理)和模型训练(机器学习)等几个用例需要这种方法。
(1)Cloudera数据湖的错误做法
多年前，Cloudera公司和Hortonworks公司以及IBM等合作伙伴为大多数企业引入了数据湖技术。这些企业都有采用大数据的愿景(但他们不知道如何从中获得商业价值)。而数据湖由20多个不同的开源框架组成。
新框架在出现时会添加，以便数据湖是最新的。那么面临的主要问题是什么?没有商业价值。此外可能没有与良好商业模式的供应商合作，而只有销售部门提供支持是行不通的，尤其是当两个非常相似的供应商相互竞争时，其最终结果是Cloudera公司与Hortonworks公司合并。
Cloudera公司仍然为这么多不同的框架提供支持，其中包括许多数据湖技术，还有诸如Storm、Kafka、Spark Streaming和Flink等事件流平台。人们很惊讶这家规模相对较小的公司如何做到这一点。很多人只对每个框架有一些了解，而且可能只对过时的Hadoop生态系统非常了解，因此这种商业模式行不通。而直到今年，Cloudera公司仍然没有真正的SaaS产品。这也不足为奇，因为要构建一个具有20多个框架构建真正的SaaS产品并不容易。
事实表明，对于规模相对较小的企业来说，最好只做一件事，而不是试图做所有的事情。
(2)AWS公司的Lake House策略
云计算供应商需要一起构建数据湖，其中包括全球主要的云提供商(AWS、GCP、Azure、阿里巴巴)、MongoDB、Databricks和Snowflake。他们都有自己的特定用例和权衡，但有一个共同点是，他们的数据湖都有云优先策略和无服务器SaaS产品。
以下了解AWS公司具有良好商业模式的现代云原生战略将在今年有什么发展。
AWS公司作为全球公共云基础设施的市场领导者，定期开发并推出新的基础设施类别。例如，EC2实例开启了云时代，并提供了敏捷和弹性的计算能力;S3成为对象存储的事实上的行业标准。如今，AWS公司拥有数百种创新的SaaS服务。
(3)AWS的数据湖策略基于新的流行术语Lake House
众所周知，虽然关键信息是一种解决方案，但并不能解决所有问题。更重要的是，这些问题都可以通过云原生、无服务器AWS解决方案解决。
这就是公共云中的云原生数据湖产品的外观。显然，像GCP和Azure等其他云计算报务商的无服务器产品也朝着相同的方向发展。
然而，由于网络延迟、安全性和成本等原因，公共云并不是解决所有问题的理想选择。
(4)混合云和多云成为常态
近年来，许多新的创新解决方案针对另一个市场：边缘计算和内部基础设施。一些示例包括AWS本地区域、AWS Outposts、AWS Wavelength。AWS公司通常会设置新基础设施以及提供软件类别的创新方法，大多数云计算提供商都有非常相似的产品。AWS公司在许多情况下推出它，而其他公司通常或多或少地进行复制。
话虽如此，每个云计算提供商都有各自的优势。谷歌云平台(GCP)以其在Kubernetes、Tensor Flow等开源服务方面的行业领先地位而闻名。IBM和Oracle更擅长为自己的产品提供服务和基础设施。
用户对于采用多个云提供商的服务有着更多的需求。大多数企业都有使用AWS公司和其他供应商(如Azure、GCP、IBM、Oracle或阿里巴巴)的多云战略。使用不同云计算供应商提供的云服务的理由很充分，其中包括成本、数据位置、跨供应商的灾难恢复、供应商独立性、历史原因和专用的特定于云的服务。
幸运的是，无服务器Kafka SaaS Confluent Cloud可用于所有主要云。因此，类似的示例可用于将完全托管的Kafka生态系统与Azure和GCP云平台一起使用。
2.从“静态数据”到“动态数据”
在进行相关介绍之后，现在又回到了无服务器Kafka。只有知道这些背景，人们才有可能了解动态数据的兴起以及对云原生和无服务器服务的需求。
先从关键信息开始：
- 在跨行业的大多数用例中，实时数据胜过慢速传输的数据。
- 对于事件流，需要采用与现代数据湖相同的云原生方法。
- 事件流和数据湖技术是互补的，而不是竞争性的。
由Apache Kafka提供支持的事件驱动架构和动态数据的兴起，使企业能够构建实时基础设施和应用程序。
(1)Apache Kafka：动态数据的事实标准
简而言之，大多数附加值来自处理相关的动态数据，而不是存储静态数据并稍后处理(有可能为时已晚)。Forrester公司的分析师Mike Gualtieri采用下图很好地说明了这一点：
Kafka API是用于动态数据的事实上的标准API，就像用于对象存储的Amazon S3：
虽然Snowflake公司和MongoDB公司等供应商希望进入动态数据业务，但这可能并没有什么意义。正如以上针对Cloudera公司所讨论的那样，最好只专注于一件事并将其做好。这就是为什么Confluent公司不仅与云计算提供商，而且还与Snowflake和MongoDB更加紧密合作的原因。
Apache Kafka是经过实战测试且可扩展的开源框架，用于处理动态数据。然而，它更像是一台汽车引擎。
3.完整的无服务器Kafka平台
当人们谈论云计算、无服务器、AWS公司等时，可能会问自己：“如果可以简单地使用Amazon MSK，为什么还要考虑采用AWS上的Kafka?”而回答这个问题的答案是：Amazon MSK是PaaS，而不是完全托管和无服务器的Kafka SaaS产品。
那么你更喜欢购买以下的哪一个产品?
①一台经过充分测试的汽车引擎(没有车轮、刹车、灯等)
②一辆完整的汽车(包括成熟和自动化的安保、安全和维护)
③一辆自动驾驶汽车(包括无需转向、加油、换刹车、产品召回等的安全自动驾驶)
而在Kafka的世界里，人们可以从Confluent公司获得一辆自动驾驶汽车。这并不是销售或营销的一种宣传，而是事实。所有其他云计算产品都为用户提供自我管理的产品，企业需要自己选择代理、修复错误、进行性能调整等。AWS MSK也是如此。因此建议评估不同的产品，以了解“完全托管”或“无服务器”是营销术语还是事实。
无论是要构建数据湖/Lake House架构、与其他第三方应用程序集成，还是构建新的自定义业务应用程序：无服务器是云计算的发展方向，
(1)无服务器、完全托管的Kafka
如果企业采用公共云，完全托管的无服务器产品是最佳选择，无需担心运营工作。与其相反，应该使用即用即付模型以及基于消费的定价和关键任务服务等级协议(SLA)关注和支持解决业务问题。
真正完全托管的无服务器产品不会让企业访问服务器基础设施。那么是否可以访问AWS S3对象存储或Snowflake服务器配置?并不是这样，因为那样将会担心这样的操作可能影响甚至破坏集群。
(2)自我管理的云原生Kafka
并非每个Kafka集群都在公共云中运行。因此，一些Kafka集群需要由企业的运维团队自己进行管理。很多企业都在为管理Kafka而陷于困境，特别是如果用例不仅仅是将数据摄取到数据湖中，而是关键的事务或分析工作负载。
云原生Kafka通过自动化支持运营团队，减少了企业的风险和工作量。例如，自平衡集群接管分区的重新平衡。自动滚动升级允许企业升级到每个新版本，而不是运行昂贵且有风险的迁移项目。计算和存储的分离(使用分层存储)支持大型但经济高效的Kafka集群，其中包含TB级甚至PB级的数据。
顺便说一句：云原生Kafka集群不必在Kubernetes上运行。Ansible或普通容器/裸机部署是在企业的数据中心或边缘部署Kafka的其他常见选项。但是Kubernetes提供了关于具有弹性规模的自动化的最佳云原生体验。因此，供应商在过去几年开发了各种Kafka Operators(基于CRD)，例如Confluent for Kubernetes或Red Hat公司的Strimzi。
4.Kafka不仅仅是消息传递和数据摄取
最后需要明确一点：Kafka不仅仅是消息传递和数据摄取。如今大多数Kafka项目也利用Kafka Connect进行数据集成或Kafka Streams/ksql DB进行连续数据处理。因此使用Kafka，可以在分布式和可扩展的基础设施支持数据的消息传递、存储、集成和处理：
一个完全托管的Kafka平台不仅运营Kafka，还运营整个生态系统。例如，完全托管的连接器支持与原生AWS服务(如S3、Redshift或Lambda)以及非AWS系统(如MongoDB Atlas、Salesforce或Snowflake)进行无服务器数据集成。此外，使用ksqlDB的完全托管流分析支持大规模连续数据处理。
而一个完整的Kafka平台提供了整个生态系统，其中包括安全性(基于角色的访问控制、加密、审计日志)、数据治理(模式注册、数据质量、数据目录、数据沿袭)以及许多其他特性，如全局弹性、灵活的DevOps自动化、指标和监控。
(1)示例1：事件流+数据湖/Lake House
以下示例展示了如何使用完整的平台通过各种Confluent组件以及与AWS湖屋服务的集成进行实时分析：
① 摄取和处理
使用Schema Registry捕获具有一致数据结构的事件流，使用ksqlDB、轻量级SQL语法开发实时ETL管道，并使用Kafka Connect连接器通过批处理统一实时流。
②存储和分析
使用预先构建的Confluent连接器将数据流式传输到企业的AWS数据湖或数据仓库中，以对大量流式数据执行查询，从而进行实时和批量分析。
这个例子很好地展示了数据湖或Lake house服务和事件流如何相互补充。所有服务都是SaaS。甚至集成(由Kafka Connect提供支持)也是无服务器的。
(2)示例2：无服务器应用程序和微服务集成
以下示例展示了如何使用完整的平台将现有的应用程序和无服务器微服务与各种Confluent和AWS服务集成，并构建新的应用程序：
①无服务器集成
以可重复的方式连接现有的应用程序和数据存储，而无需管理和操作任何东西。Apache Kafka和Schema Registry确保保持应用程序兼容性。ksqlDB允许使用SQL语法开发实时应用程序。Kafka Connect提供与Lambda和数据存储的轻松集成。
②AWS无服务器平台
停止为后端组件(例如计算、数据库和存储)配置、维护或管理服务器，以便企业可以专注于提高开发人员团队的敏捷性和创新。
5.Kafka无处不在：云平台、内部部署、边缘
公共云是数据中心的未来。但是有两个主要原因不能在公共云基础设施中运行所有内容：
- 棕地架构：许多企业在数据中心拥有大量应用程序和基础设施。混合云架构是唯一的选择，例如大型机。
- 边缘用例：由于成本、延迟、安全或法律原因，某些场景在公共云中没有意义，例如智能工厂。
Apache Kafka的多集群和跨数据中心部署已经成为一个常态而非例外。多个场景需要多集群解决方案，包括灾难恢复、分析聚合、云迁移、关键任务延伸部署和全球Kafka。
各种AWS基础设施支持在公共云之外部署Kafka。Confluent平台在AWS Outposts上获得认证，因此可以在各种AWS硬件产品上运行。
(1)示例3：与Kafka原生集群链接的混合集成
以下是棕地现代化的一个示例：
①连接
预先构建的连接器不断从本地现有服务中获取有价值的数据，包括企业数据仓库、数据库和大型机。此外，在需要时也可以进行双向通信。
②桥接
混合云流支持一致、可靠的实时复制，为新应用程序以及与第一方和第三方SaaS接口的集成构建现代事件驱动架构。
③现代化
公共云基础设施提高了将应用程序推向市场的灵活性，并在释放资源以专注于创造价值的活动而不是管理服务器时降低总体拥有成本。
(2)示例4：在AWS Wavelength上使用云原生5G基础设施的低延迟Kafka
低延迟数据流需要靠近边缘机器、设备、传感器、智能手机和其他接口运行的基础设施。AWS Wavelength专为这些场景而构建。企业不必在边缘安装自己的IT基础设施。
以下架构显示了Confluent、AWS和Verizon构建的示例：
(3)现场演示：混合云复制
行业专家通过现场演示来展示内部部署的Kafka集群和Confluent Cloud之间的流复制，其中包括使用ksqlDB进行流处理以及与KafkaConnect的数据集成(使用完全托管的AWS S3连接器)。
6.反向ETL及其与数据湖和Kafka的关系
以下将探讨人们可能听说过的一个术语——反向ETL。这个流行术语仍处于早期发展阶段，但得到越来越多的供应商的关注。简而言之，这意味着将数据存储在人们喜欢的长期存储(数据库、数据仓库、数据湖、Lake house)中，然后再次从那里取出数据以连接到其他业务系统。
在Kafka世界中，这与变更数据捕获(CDC)相同。因此，反向ETL并不是什么新鲜事物。Confluent公司为许多相关系统提供CDC连接器，其中包括Oracle、MongoDB和Salesforce。
正如以上提到的，数据存储供应商试图提供动态数据业务。行业专家认为，事件流平台是企业架构中处理动态数据的正确位置。通过这种方式，每个应用程序都可以实时使用数据。
7.使用AWS和Confluent的无服务器和云原生Kafka
云优先策略是当今企业采用的主要策略。无论用例是新的绿地项目、棕地集成架构还是具有混合部署的现代边缘场景，Kafka将成为处理动态数据的一个事实标准。然而，Kafka只是拼图的一部分，大多数企业更喜欢采用完整的云原生服务。
AWS和Confluent是一个经过验证的组合，适用于跨行业的各种用例，可以在任何地方部署和运行Kafka环境，包括公共云中的无服务器Kafka和公共云之外的云原生Kafka。虽然本文侧重于Confluent和AWS之间的关系，但Confluent也与GCP和Azure建立了类似的强大合作伙伴关系，以提供大量的动态数据。
原文标题：Serverless Kafka in a Cloud-Native Data Lake Architecture，作者：Kai Wähner
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
原文链接：https://server.51cto.com/Micro-678320.htm
