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