人們需要了解如何在混合云上利用云原生和無服務器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