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