DZone>云计算专区 > 云原生数据湖架构中的无服务器Kafka
云原生数据湖架构中的无服务器Kafka
了解如何在混合云上利用云原生和无服务器的Apache Kafka来处理与数据湖互补的运动数据。
由
CORE -
8月9日，21日 -云区 -演讲
喜欢 (1)
评论
保存
Tweet
151次浏览
加入DZone社区，获得完整的会员体验。
Apache Kafka成为处理运动中数据的事实标准。Kafka具有开放性、灵活性和可扩展性。不幸的是，后者使操作成为许多团队的挑战。**理想情况下，团队可以使用无服务器的Kafka SaaS产品，专注于业务逻辑。**然而，混合场景需要一个云原生平台，提供自动化和弹性工具，以减少运营负担。本博文探讨了如何在混合云架构中利用云原生和无服务器Kafka产品。我们从数据湖的静态数据的角度出发，探讨其与Kafka的动态数据的关系。
静止的数据--仍然是正确的方法？
静止数据意味着将数据存储在数据库、数据仓库或数据湖中。这意味着在许多用例中，数据处理得太晚了--即使有实时流组件（如Kafka）摄入数据。数据处理仍然是一个网络服务调用、SQL查询或地图-还原批处理，而不是为你的问题提供一个结果。
不要误会我的意思。静止的数据并不是一件坏事。一些用例，如报告（商业智能）、分析（批处理）和模型训练（机器学习）需要这种方法。如果你做得对的话!
Cloudera的数据湖的错误方法
几年前，Cloudera和Hortonworks（加上IBM等几个合作伙伴）将数据湖引入大多数企业。大多数公司都有一个大数据愿景（但他们不知道如何从中获得商业价值）。数据湖由20多个不同的开源框架组成。
当新的框架出现时，会加入新的框架，以便数据湖是最新的。唯一的问题是什么？ 仍然没有商业价值。加上供应商没有好的商业模式。仅仅销售支持是行不通的，尤其是当两个非常相似的供应商相互竞争时。其结果是Cloudera/Hortonworks的合并。而几年后，又转到了私募基金。
在2021年，Cloudera仍然支持这么多不同的框架，包括许多数据湖技术，但也包括事件流平台，如Storm、Kafka、Spark Streaming和Flink。我很惊讶一个相对较小的公司如何能做到这一点。好吧，说实话，我并不感到惊讶。TL;DR: 他们不能!他们对每个框架都有一点了解（而且只有垂死的Hadoop生态系统非常了解）。这种商业模式是行不通的。另外，在2021年，Cloudera仍然没有一个真正的SaaS产品。这也不足为奇。围绕20多个框架建立一个真正的SaaS产品是不容易的。
因此，我的观点得到了证实。如果你是一个相对较小的公司，最好做对一件事，而不是试图做所有的事。
来自AWS的湖屋战略
这就是为什么今天的数据湖是由其他供应商建立的：主要的云供应商（AWS、GCP、Azure、阿里巴巴）、MongoDB、Databricks和Snowflake。他们都有自己特定的使用案例和权衡。然而，他们都有一个共同点，即他们的数据湖有一个云优先战略和无服务器的SaaS产品。
让我们深入了解一下AWS，以了解在2021年，具有良好商业模式的现代云原生战略是什么样子。
AWS是公共云基础设施的市场领导者。此外，AWS定期发明新的基础设施类别。例如，EC2实例开启了云时代，实现了敏捷和弹性的计算能力。S3成为对象存储的事实上的标准。今天，AWS有数百种创新的SaaS服务。
AWS的数据湖战略是基于新的流行语Lake House。
正如你所看到的，关键信息是，一个解决方案不能解决所有问题。然而，更重要的是，所有这些问题都是通过云原生、无服务器的AWS解决方案来解决的。
这就是公有云中的云原生数据湖产品必须的样子。 很明显，其他超大规模的公司，如GCP和Azure，也在朝着他们的无服务器产品的方向发展。
不幸的是，由于延迟、安全和成本等原因，公有云不是每个问题的正确选择。
混合云和多云成为常态
近年来，许多新的创新解决方案处理另一个市场：边缘和内部基础设施。一些例子包括AWS Local Zones, AWS Outposts, AWS Wavelength。我非常喜欢AWS设置新的基础设施和软件类别的创新方法。大多数云计算供应商都有非常类似的产品，但AWS在很多情况下都会推出，而其他公司往往或多或少会复制它。因此，我在这篇文章中重点介绍AWS。
说到这里，每个云供应商都有特定的优势。GCP以其在围绕Kubernetes、TensorFlow和其他开源服务方面的领导地位而闻名。IBM和甲骨文在为他们自己的产品提供服务和基础设施方面是最好的。
我看到到处都有对多个云供应商的需求。与我交谈的大多数客户都有一个多云战略，使用AWS和其他供应商，如Azure、GCP、IBM、Oracle或阿里巴巴。使用不同的云供应商有很好的理由，包括成本、数据定位、跨供应商的灾难恢复、供应商的独立性、历史原因，以及专门的云服务。
幸运的是，无服务器的Kafka SaaS Confluent Cloud在所有主要的云上都有。因此，完全管理的Kafka生态系统与Azure和GCP的使用也有类似的例子。 现在，让我们最后来看看这篇文章的Kafka部分... :-)
从 "静态的数据 "到 "动态的数据"
在这段长长的介绍之后，我们现在真正回到了无服务器的Kafka。 只有具备了背景知识，才有可能理解运动中的数据的兴起以及对云原生和无服务器服务的需求。
我们先来看看要指出的关键信息。
- 在各行业的大多数用例中，实时性击败慢速数据。
- 对于事件流，需要采用与现代数据湖相同的云原生方法。
- 事件流和数据湖/湖屋技术是互补的，而不是竞争的。
由Apache Kafka驱动的事件驱动架构和运动数据的兴起，使企业能够建立实时的基础设施和应用程序。
Apache Kafka。 运动数据的事实标准
我不会在这篇文章中探讨Kafka成功的原因和使用案例。相反，你可以查看我关于Kafka在各行业的使用案例的概述，或者阅读我的一些垂直领域的博文，以了解更多细节。
简而言之，大部分的附加价值来自于在运动中处理数据，而不是在静止状态下存储数据，然后再进行处理（或太晚）。Forrester公司的Mike Gualtieri的下图很好地说明了这一点。
Kafka API是运动数据的事实标准API，就像Amazon S3的对象存储一样。
虽然我理解Snowflake和MongoDB等厂商希望进入运动数据领域，但我怀疑这是否有什么意义。正如前面在Cloudera部分所讨论的，最好是专注于一件事，并把它做得非常好。这显然就是为什么Confluent不仅与云计算供应商有强大的合作关系，而且还与Snowflake和MongoDB有合作关系。
Apache Kafka是经过战斗考验的、可扩展的开源框架，用于处理运动中的数据。然而，它更像是一个汽车引擎。
一个完整的、无服务器的Kafka平台
当我谈到云、无服务器、AWS等时，你可能会问自己。"如果你能简单地使用亚马逊MSK，为什么还要考虑AWS上的Kafka呢？" 这是一个强制性的、合理的问题!
简短的回答。亚马逊MSK是PaaS，不是完全管理的，也不是无服务器的Kafka SaaS产品。
这里有一个简单的反问。你更喜欢买哪一个？
- 一个经过战斗考验的汽车引擎（没有车轮、刹车、车灯等）。
- 一辆完整的汽车（包括成熟的、自动化的安全保障、安全和维护）。
- 一辆自动驾驶汽车（包括安全的自动驾驶，不需要掌舵、加油、换刹车、产品召回等）。
在Kafka的世界里，你只能从Confluent得到一辆自动驾驶汽车。这不是一个销售或营销宣传，而是事实。所有其他的云产品都为你提供了一个自我管理的产品，你需要自己选择经纪商、修复bug、进行性能调整等。对于亚马逊MSK也是如此。因此，我建议对不同的产品进行评估，以了解 "完全管理 "或 "无服务器 "是否只是一个营销术语或现实。
查看"开源Apache Kafka与Confluent、Cloudera、Red Hat、Amazon MSK等供应商的比较"，了解更多细节。
无论你是想建立一个数据湖/湖心岛架构，还是想与其他第三方应用集成，或者建立新的定制业务应用。无服务器是云计算的发展方向!
无服务器、完全管理的Kafka
如果你在公有云上，完全管理的无服务器产品是最好的选择。不需要担心运营工作。相反，你可以通过基于消费的定价和关键任务的SLA和支持，采用 "即用即付 "的模式来关注业务问题。
一个真正的完全管理和无服务器的产品不会让你访问服务器基础设施。你能访问你的AWS S3对象存储或Snowflake服务器配置吗？没有，因为那样你就得担心操作，并有可能影响甚至破坏集群。
自我管理的云原生Kafka
不是每个Kafka集群都在公有云上运行。因此，有些Kafka集群需要由自己的运营团队进行部分管理。我见过很多企业自己在Kafka的运营中挣扎，尤其是当用例不仅仅是将数据摄入数据湖，而是关键任务的交易或分析工作负载时。
云原生的Kafka通过自动化来支持运营团队。 这减少了风险和努力。例如，自我平衡的 集群接管了分区的再平衡工作。自动滚动升级允许你升级到每一个新的版本，而不是运行一个昂贵的、有风险的迁移项目（往往会造成无法迁移到新版本的后果）。计算和存储的分离（通过分层存储）使得拥有Terrabytes甚至Petabytes数据的大型Kafka集群更具成本效率，等等。
哦，顺便说一下。一个云原生的Kafka集群不一定要在Kubernetes上运行。Ansible或普通的容器/裸机部署是在你自己的数据中心或边缘部署Kafka的其他常见选择。但Kubernetes无疑提供了关于自动化和弹性规模的最佳云原生体验。因此，在过去几年中，各种Kafka运营商（基于CRD）被开发出来，例如Confluent for Kubernetes或Red Hat的Strimzi。
Kafka不仅仅是消息传递和数据摄取
最后但并非最不重要的一点是，我们要清楚：Kafka不仅仅是消息传递和数据摄取。我看到今天大多数 Kafka项目还利用Kafka Connect进行数据整合和/或Kafka Streams/ksqlDB进行连续数据处理。因此，有了Kafka，一个单一的（分布式和可扩展的）基础设施就可以实现消息传递、存储、整合和数据处理。
一个完全管理的Kafka平台不只是操作Kafka，而是整个生态系统。例如，完全管理的连接器实现了与S3、Redshift或Lambda等本地AWS服务以及MongoDB Atlas、Salesforce或Snowflake等非AWS系统的无服务器数据集成。此外，利用ksqlDB进行完全管理的流分析，可以实现大规模的连续数据处理。
一个完整的Kafka平台提供了整个生态系统，包括安全（基于角色的访问控制、加密、审计日志）、数据治理（模式注册、数据质量、数据目录、数据脉络），以及许多其他功能，如全球弹性、灵活的DevOps自动化、指标和监控。
示例1：事件流+数据湖/湖心岛
下面的例子展示了如何使用一个完整的平台，通过各种Confluent组件加上与AWS湖畔小屋服务的集成来进行实时分析。
摄取和处理
使用Schema Registry捕获具有一致数据结构的事件流，使用ksqlDB开发具有轻量级SQL语法的实时ETL管道，使用Kafka Connect Connectors将实时流与批处理统一起来。
存储和分析
使用预建的Confluent连接器将数据流导入您的AWS数据湖或数据仓库，以执行对大量流数据的查询，进行实时和批量分析。
这个例子很好地说明了数据湖或湖心岛服务和事件流是如何互补的。所有的服务都是SaaS。甚至整合（由Kafka Connect提供）也是无服务器的。
示例2：无服务器应用程序和微服务集成
下面的例子展示了如何使用一个完整的平台来整合现有的和建立新的应用程序和无服务器的微服务与各种Confluent和AWS服务。
无服务器集成
以可重复的方式连接现有和应用程序和数据存储，而无需管理和操作任何东西。Apache Kafka和Schema Registry确保保持应用的兼容性。 ksqlDB允许使用SQL语法开发实时应用。Kafka Connect提供了与Lambda和数据存储的轻松集成。
AWS无服务器平台
停止为计算、数据库和存储等后端组件配置、维护或管理服务器，以便您可以专注于提高开发人员团队的敏捷性和创新性。
Kafka无处不在。 云、内部部署、边缘
公共云是数据中心的未来。然而，有两个主要原因，不要在公共云基础设施中运行一切。
- Brownfield架构。许多企业在数据中心有大量的应用程序和基础设施。混合云架构是唯一的选择。想想大型机就是一个例子。
- 边缘用例。由于成本、延迟、安全或法律原因，一些场景在公共云中没有意义。想想智能工厂就是一个例子。
Apache Kafka的多集群和跨数据中心的部署已经成为常态，而不是例外。有几个场景需要多集群解决方案，包括灾难恢复、分析的聚合、云迁移、关键任务的扩展部署和全球Kafka。在博文"分布式、混合式、边缘和全球Apache Kafka部署的架构模式"中了解更多信息。
各种AWS基础设施使Kafka的部署在公共云之外。Confluent平台通过了AWS Outposts的认证，因此可以在各种AWS硬件产品上运行。
例子3：用Kafka-Native Cluster Linking进行混合集成
下面是一个用于棕地现代化的例子。
连接
预先建立的连接器不断地从现有的内部服务中带来有价值的数据，包括企业数据仓库、数据库和主机。此外，在需要时也可以进行双向通信。
桥接
混合云流实现了一致的、可靠的实时复制，为新的应用和与第一和第三方SaaS接口的整合建立了一个现代事件驱动的架构。
现代化
公共云基础设施提高了应用程序进入市场的敏捷性，并在释放资源以专注于创造价值的活动而不是管理服务器时降低了总拥有成本。
示例4：低延迟Kafka与AWS Wavelength上的云原生5G基础设施
低延迟的数据流需要在靠近边缘机器、设备、传感器、智能手机和其他接口处运行的基础设施。AWS Wavelength就是为这些场景而生的。企业不需要在边缘安装自己的IT基础设施。
下面的架构显示了一个由Confluent、AWS和Verizon构建的例子。
在博文"Low Latency Data Streaming with Apache Kafka and Cloud-Native 5G Infrastructure"中了解更多关于运动数据的低延迟用例。
现场演示。 混合云复制
我录制了一个现场演示，展示了内部Kafka集群和Confluent云之间的流式复制，包括用ksqlDB进行流式处理和用Kafka Connect（使用完全管理的AWS S3连接器）进行数据整合。
AWS和Confluent关于无服务器Kafka的联合网络研讨会的幻灯片
我最近和AWS一起做了一个网络研讨会，介绍Confluent和AWS服务结合的附加价值。这在过去几年中成为许多事务性和分析性工作负载的标准模式。
逆向ETL及其与数据湖和Kafka的关系
在这篇文章的最后，我想再探讨一个你可能听说过的术语。这个流行语仍处于早期阶段，但越来越多的供应商提出了一个新的趋势。反向ETL。简而言之，这意味着在你最喜欢的长期存储（数据库/数据仓库/数据湖/湖心岛）中存储 数据，然后再把数据从那里取出来，连接到其他业务系统。
在Kafka的世界里，这与变化数据捕获（CDC）相同。因此，反向ETL并不是一个新事物。Confluent为许多相关系统提供CDC连接器，包括Oracle、MongoDB和Salesforce。
正如我前面提到的，数据存储供应商试图进入运动中的数据业务。我不确定这将走向何方。就我个人而言，我相信事件流平台是企业架构中处理运动数据的正确位置。这样，每个应用程序都可以实时地消费数据--与另一个数据库或数据湖解耦。但未来会显示出来。我认为澄清这个新的流行语以及它与Kafka的关系是这篇博文的一个好结局。这可能值得在未来写一篇自己的文章。
无服务器和云原生Kafka与AWS和Confluent的关系
云优先战略是当今的常态。无论用例是新的绿地项目、棕地的传统集成架构，还是带有混合复制的现代边缘场景。Kafka成为处理运动中的数据的事实标准。然而，Kafka只是拼图中的一块。大多数企业更喜欢一个完整的、云原生的服务。
AWS和Confluent是一个成熟的组合，适用于各行业的各种用例，可以在各地部署和运营Kafka环境，包括公有云中真正的无服务器Kafka和公有云外的云原生Kafka。当然，虽然这篇文章主要关注Confluent和AWS之间的关系，但Confluent与GCP和Azure也有类似的强大合作关系，在这些超大规模上也能提供运动的数据。
今天你是如何在云中运行Kafka的？你是自己操作吗？你使用部分管理的服务吗？还是使用真正的无服务器产品？你的项目是绿地，还是使用混合架构？让我们在LinkedIn上联系并讨论一下吧!通过订阅我的时事通讯，随时了解新的博客文章。
主题。
Kafka、 无服务器、 数据湖、 运动中的数据、 Hadoop、 Snowflake、 大查询、 AWS、 大数据、 分析
经Kai Wähner, DZone MVB许可发表于DZone。点击这里查看原文。
DZone贡献者所表达的观点属于他们自己。
DZone上的热门文章
评论
