云原生數據湖架構中的無(wú)服務(wù)器Kafka

人們需要了解如何在混合云上利用云原生和無(wú)服務(wù)器Apache Kafka來(lái)處理與數據湖互補的動(dòng)態(tài)數據。而Kafka是一種高吞吐量的分布式發(fā)布訂閱消息系統，它可以處理消費者在網(wǎng)站中的所有動(dòng)作流數據。

人們需要了解如何在混合云上利用云原生和無(wú)服務(wù)器Apache Kafka來(lái)處理與數據湖互補的動(dòng)態(tài)數據。而Kafka是一種高吞吐量的分布式發(fā)布訂閱消息系統，它可以處理消費者在網(wǎng)站中的所有動(dòng)作流數據。

如今，Apache Kafka成為處理動(dòng)態(tài)數據的一個(gè)事實(shí)標準。Kafka具有開(kāi)放、靈活和可擴展的特性，但也使許多團隊面臨運營(yíng)的挑戰。在理想情況下，企業(yè)的IT團隊可以使用無(wú)服務(wù)器Kafka SaaS產(chǎn)品來(lái)專(zhuān)注于業(yè)務(wù)邏輯。然而，混合場(chǎng)景需要在一個(gè)云原生平臺運行，該平臺提供自動(dòng)化和彈性工具來(lái)減輕運營(yíng)負擔。本文探討了如何在混合云架構中利用云原生和無(wú)服務(wù)器Kafka產(chǎn)品，并從數據湖的靜態(tài)數據的角度出發(fā)，探索它與Kafka的動(dòng)態(tài)數據的關(guān)系。

1.靜態(tài)數據仍然是一種正確的方法嗎?

靜態(tài)數據是指將數據存儲在數據庫、數據倉庫或數據湖中。這意味著(zhù)在許多用例中數據處理得太晚了——即使實(shí)時(shí)流組件(如Kafka)攝取了數據。數據處理仍然是Web服務(wù)調用、SQL查詢(xún)或map-reduce批處理過(guò)程，而不是解決遇到的問(wèn)題。

靜止數據并不是一件壞事。報告(商業(yè)智能)、分析(批處理)和模型訓練(機器學(xué)習)等幾個(gè)用例需要這種方法。

(1)Cloudera數據湖的錯誤做法

多年前，Cloudera公司和Hortonworks公司以及IBM等合作伙伴為大多數企業(yè)引入了數據湖技術(shù)。這些企業(yè)都有采用大數據的愿景(但他們不知道如何從中獲得商業(yè)價(jià)值)。而數據湖由20多個(gè)不同的開(kāi)源框架組成。

新框架在出現時(shí)會(huì )添加，以便數據湖是最新的。那么面臨的主要問(wèn)題是什么?沒(méi)有商業(yè)價(jià)值。此外可能沒(méi)有與良好商業(yè)模式的供應商合作，而只有銷(xiāo)售部門(mén)提供支持是行不通的，尤其是當兩個(gè)非常相似的供應商相互競爭時(shí)，其最終結果是Cloudera公司與Hortonworks公司合并。

Cloudera公司仍然為這么多不同的框架提供支持，其中包括許多數據湖技術(shù)，還有諸如Storm、Kafka、Spark Streaming和Flink等事件流平臺。人們很驚訝這家規模相對較小的公司如何做到這一點(diǎn)。很多人只對每個(gè)框架有一些了解，而且可能只對過(guò)時(shí)的Hadoop生態(tài)系統非常了解，因此這種商業(yè)模式行不通。而直到今年，Cloudera公司仍然沒(méi)有真正的SaaS產(chǎn)品。這也不足為奇，因為要構建一個(gè)具有20多個(gè)框架構建真正的SaaS產(chǎn)品并不容易。

事實(shí)表明，對于規模相對較小的企業(yè)來(lái)說(shuō)，最好只做一件事，而不是試圖做所有的事情。

(2)AWS公司的Lake House策略

云計算供應商需要一起構建數據湖，其中包括全球主要的云提供商(AWS、GCP、Azure、阿里巴巴)、MongoDB、Databricks和Snowflake。他們都有自己的特定用例和權衡，但有一個(gè)共同點(diǎn)是，他們的數據湖都有云優(yōu)先策略和無(wú)服務(wù)器SaaS產(chǎn)品。

以下了解AWS公司具有良好商業(yè)模式的現代云原生戰略將在今年有什么發(fā)展。

AWS公司作為全球公共云基礎設施的市場(chǎng)領(lǐng)導者，定期開(kāi)發(fā)并推出新的基礎設施類(lèi)別。例如，EC2實(shí)例開(kāi)啟了云時(shí)代，并提供了敏捷和彈性的計算能力;S3成為對象存儲的事實(shí)上的行業(yè)標準。如今，AWS公司擁有數百種創(chuàng )新的SaaS服務(wù)。

(3)AWS的數據湖策略基于新的流行術(shù)語(yǔ)Lake House

眾所周知，雖然關(guān)鍵信息是一種解決方案，但并不能解決所有問(wèn)題。更重要的是，這些問(wèn)題都可以通過(guò)云原生、無(wú)服務(wù)器AWS解決方案解決。

這就是公共云中的云原生數據湖產(chǎn)品的外觀(guān)。顯然，像GCP和Azure等其他云計算報務(wù)商的無(wú)服務(wù)器產(chǎn)品也朝著(zhù)相同的方向發(fā)展。

然而，由于網(wǎng)絡(luò )延遲、安全性和成本等原因，公共云并不是解決所有問(wèn)題的理想選擇。

(4)混合云和多云成為常態(tài)

近年來(lái)，許多新的創(chuàng )新解決方案針對另一個(gè)市場(chǎng)：邊緣計算和內部基礎設施。一些示例包括AWS本地區域、AWS Outposts、AWS Wavelength。AWS公司通常會(huì )設置新基礎設施以及提供軟件類(lèi)別的創(chuàng )新方法，大多數云計算提供商都有非常相似的產(chǎn)品。AWS公司在許多情況下推出它，而其他公司通?；蚨嗷蛏俚剡M(jìn)行復制。

話(huà)雖如此，每個(gè)云計算提供商都有各自的優(yōu)勢。谷歌云平臺(GCP)以其在Kubernetes、Tensor Flow等開(kāi)源服務(wù)方面的行業(yè)領(lǐng)先地位而聞名。IBM和Oracle更擅長(cháng)為自己的產(chǎn)品提供服務(wù)和基礎設施。

用戶(hù)對于采用多個(gè)云提供商的服務(wù)有著(zhù)更多的需求。大多數企業(yè)都有使用AWS公司和其他供應商(如Azure、GCP、IBM、Oracle或阿里巴巴)的多云戰略。使用不同云計算供應商提供的云服務(wù)的理由很充分，其中包括成本、數據位置、跨供應商的災難恢復、供應商獨立性、歷史原因和專(zhuān)用的特定于云的服務(wù)。

幸運的是，無(wú)服務(wù)器Kafka SaaS Confluent Cloud可用于所有主要云。因此，類(lèi)似的示例可用于將完全托管的Kafka生態(tài)系統與Azure和GCP云平臺一起使用。

2.從“靜態(tài)數據”到“動(dòng)態(tài)數據”

在進(jìn)行相關(guān)介紹之后，現在又回到了無(wú)服務(wù)器Kafka。只有知道這些背景，人們才有可能了解動(dòng)態(tài)數據的興起以及對云原生和無(wú)服務(wù)器服務(wù)的需求。

先從關(guān)鍵信息開(kāi)始：

• 在跨行業(yè)的大多數用例中，實(shí)時(shí)數據勝過(guò)慢速傳輸的數據。
• 對于事件流，需要采用與現代數據湖相同的云原生方法。
• 事件流和數據湖技術(shù)是互補的，而不是競爭性的。

由Apache Kafka提供支持的事件驅動(dòng)架構和動(dòng)態(tài)數據的興起，使企業(yè)能夠構建實(shí)時(shí)基礎設施和應用程序。

(1)Apache Kafka：動(dòng)態(tài)數據的事實(shí)標準

簡(jiǎn)而言之，大多數附加值來(lái)自處理相關(guān)的動(dòng)態(tài)數據，而不是存儲靜態(tài)數據并稍后處理(有可能為時(shí)已晚)。Forrester公司的分析師Mike Gualtieri采用下圖很好地說(shuō)明了這一點(diǎn)：

Kafka API是用于動(dòng)態(tài)數據的事實(shí)上的標準API，就像用于對象存儲的Amazon S3：

雖然Snowflake公司和MongoDB公司等供應商希望進(jìn)入動(dòng)態(tài)數據業(yè)務(wù)，但這可能并沒(méi)有什么意義。正如以上針對Cloudera公司所討論的那樣，最好只專(zhuān)注于一件事并將其做好。這就是為什么Confluent公司不僅與云計算提供商，而且還與Snowflake和MongoDB更加緊密合作的原因。

Apache Kafka是經(jīng)過(guò)實(shí)戰測試且可擴展的開(kāi)源框架，用于處理動(dòng)態(tài)數據。然而，它更像是一臺汽車(chē)引擎。

3.完整的無(wú)服務(wù)器Kafka平臺

當人們談?wù)撛朴嬎?、無(wú)服務(wù)器、AWS公司等時(shí)，可能會(huì )問(wèn)自己：“如果可以簡(jiǎn)單地使用Amazon MSK，為什么還要考慮采用AWS上的Kafka?”而回答這個(gè)問(wèn)題的答案是：Amazon MSK是PaaS，而不是完全托管和無(wú)服務(wù)器的Kafka SaaS產(chǎn)品。

那么你更喜歡購買(mǎi)以下的哪一個(gè)產(chǎn)品?

①一臺經(jīng)過(guò)充分測試的汽車(chē)引擎(沒(méi)有車(chē)輪、剎車(chē)、燈等)

②一輛完整的汽車(chē)(包括成熟和自動(dòng)化的安保、安全和維護)

③一輛自動(dòng)駕駛汽車(chē)(包括無(wú)需轉向、加油、換剎車(chē)、產(chǎn)品召回等的安全自動(dòng)駕駛)

而在Kafka的世界里，人們可以從Confluent公司獲得一輛自動(dòng)駕駛汽車(chē)。這并不是銷(xiāo)售或營(yíng)銷(xiāo)的一種宣傳，而是事實(shí)。所有其他云計算產(chǎn)品都為用戶(hù)提供自我管理的產(chǎn)品，企業(yè)需要自己選擇代理、修復錯誤、進(jìn)行性能調整等。AWS MSK也是如此。因此建議評估不同的產(chǎn)品，以了解“完全托管”或“無(wú)服務(wù)器”是營(yíng)銷(xiāo)術(shù)語(yǔ)還是事實(shí)。

無(wú)論是要構建數據湖/Lake House架構、與其他第三方應用程序集成，還是構建新的自定義業(yè)務(wù)應用程序：無(wú)服務(wù)器是云計算的發(fā)展方向，

(1)無(wú)服務(wù)器、完全托管的Kafka

如果企業(yè)采用公共云，完全托管的無(wú)服務(wù)器產(chǎn)品是最佳選擇，無(wú)需擔心運營(yíng)工作。與其相反，應該使用即用即付模型以及基于消費的定價(jià)和關(guān)鍵任務(wù)服務(wù)等級協(xié)議(SLA)關(guān)注和支持解決業(yè)務(wù)問(wèn)題。

真正完全托管的無(wú)服務(wù)器產(chǎn)品不會(huì )讓企業(yè)訪(fǎng)問(wèn)服務(wù)器基礎設施。那么是否可以訪(fǎng)問(wèn)AWS S3對象存儲或Snowflake服務(wù)器配置?并不是這樣，因為那樣將會(huì )擔心這樣的操作可能影響甚至破壞集群。

(2)自我管理的云原生Kafka

并非每個(gè)Kafka集群都在公共云中運行。因此，一些Kafka集群需要由企業(yè)的運維團隊自己進(jìn)行管理。很多企業(yè)都在為管理Kafka而陷于困境，特別是如果用例不僅僅是將數據攝取到數據湖中，而是關(guān)鍵的事務(wù)或分析工作負載。

云原生Kafka通過(guò)自動(dòng)化支持運營(yíng)團隊，減少了企業(yè)的風(fēng)險和工作量。例如，自平衡集群接管分區的重新平衡。自動(dòng)滾動(dòng)升級允許企業(yè)升級到每個(gè)新版本，而不是運行昂貴且有風(fēng)險的遷移項目。計算和存儲的分離(使用分層存儲)支持大型但經(jīng)濟高效的Kafka集群，其中包含TB級甚至PB級的數據。

順便說(shuō)一句：云原生Kafka集群不必在Kubernetes上運行。Ansible或普通容器/裸機部署是在企業(yè)的數據中心或邊緣部署Kafka的其他常見(jiàn)選項。但是Kubernetes提供了關(guān)于具有彈性規模的自動(dòng)化的最佳云原生體驗。因此，供應商在過(guò)去幾年開(kāi)發(fā)了各種Kafka Operators(基于CRD)，例如Confluent for Kubernetes或Red Hat公司的Strimzi。

4.Kafka不僅僅是消息傳遞和數據攝取

最后需要明確一點(diǎn)：Kafka不僅僅是消息傳遞和數據攝取。如今大多數Kafka項目也利用Kafka Connect進(jìn)行數據集成或Kafka Streams/ksql DB進(jìn)行連續數據處理。因此使用Kafka，可以在分布式和可擴展的基礎設施支持數據的消息傳遞、存儲、集成和處理：

一個(gè)完全托管的Kafka平臺不僅運營(yíng)Kafka，還運營(yíng)整個(gè)生態(tài)系統。例如，完全托管的連接器支持與原生AWS服務(wù)(如S3、Redshift或Lambda)以及非AWS系統(如MongoDB Atlas、Salesforce或Snowflake)進(jìn)行無(wú)服務(wù)器數據集成。此外，使用ksqlDB的完全托管流分析支持大規模連續數據處理。

而一個(gè)完整的Kafka平臺提供了整個(gè)生態(tài)系統，其中包括安全性(基于角色的訪(fǎng)問(wèn)控制、加密、審計日志)、數據治理(模式注冊、數據質(zhì)量、數據目錄、數據沿襲)以及許多其他特性，如全局彈性、靈活的DevOps自動(dòng)化、指標和監控。

(1)示例1：事件流+數據湖/Lake House

以下示例展示了如何使用完整的平臺通過(guò)各種Confluent組件以及與AWS湖屋服務(wù)的集成進(jìn)行實(shí)時(shí)分析：

① 攝取和處理

使用Schema Registry捕獲具有一致數據結構的事件流，使用ksqlDB、輕量級SQL語(yǔ)法開(kāi)發(fā)實(shí)時(shí)ETL管道，并使用Kafka Connect連接器通過(guò)批處理統一實(shí)時(shí)流。

②存儲和分析

使用預先構建的Confluent連接器將數據流式傳輸到企業(yè)的AWS數據湖或數據倉庫中，以對大量流式數據執行查詢(xún)，從而進(jìn)行實(shí)時(shí)和批量分析。

這個(gè)例子很好地展示了數據湖或Lake house服務(wù)和事件流如何相互補充。所有服務(wù)都是SaaS。甚至集成(由Kafka Connect提供支持)也是無(wú)服務(wù)器的。

(2)示例2：無(wú)服務(wù)器應用程序和微服務(wù)集成

以下示例展示了如何使用完整的平臺將現有的應用程序和無(wú)服務(wù)器微服務(wù)與各種Confluent和AWS服務(wù)集成，并構建新的應用程序：

①無(wú)服務(wù)器集成

以可重復的方式連接現有的應用程序和數據存儲，而無(wú)需管理和操作任何東西。Apache Kafka和Schema Registry確保保持應用程序兼容性。ksqlDB允許使用SQL語(yǔ)法開(kāi)發(fā)實(shí)時(shí)應用程序。Kafka Connect提供與Lambda和數據存儲的輕松集成。

②A(yíng)WS無(wú)服務(wù)器平臺

停止為后端組件(例如計算、數據庫和存儲)配置、維護或管理服務(wù)器，以便企業(yè)可以專(zhuān)注于提高開(kāi)發(fā)人員團隊的敏捷性和創(chuàng )新。

5.Kafka無(wú)處不在：云平臺、內部部署、邊緣

公共云是數據中心的未來(lái)。但是有兩個(gè)主要原因不能在公共云基礎設施中運行所有內容：

• 棕地架構：許多企業(yè)在數據中心擁有大量應用程序和基礎設施?；旌显萍軜嬍俏ㄒ坏倪x擇，例如大型機。
• 邊緣用例：由于成本、延遲、安全或法律原因，某些場(chǎng)景在公共云中沒(méi)有意義，例如智能工廠(chǎng)。

Apache Kafka的多集群和跨數據中心部署已經(jīng)成為一個(gè)常態(tài)而非例外。多個(gè)場(chǎng)景需要多集群解決方案，包括災難恢復、分析聚合、云遷移、關(guān)鍵任務(wù)延伸部署和全球Kafka。

各種AWS基礎設施支持在公共云之外部署Kafka。Confluent平臺在A(yíng)WS Outposts上獲得認證，因此可以在各種AWS硬件產(chǎn)品上運行。

(1)示例3：與Kafka原生集群鏈接的混合集成

以下是棕地現代化的一個(gè)示例：

①連接

預先構建的連接器不斷從本地現有服務(wù)中獲取有價(jià)值的數據，包括企業(yè)數據倉庫、數據庫和大型機。此外，在需要時(shí)也可以進(jìn)行雙向通信。

②橋接

混合云流支持一致、可靠的實(shí)時(shí)復制，為新應用程序以及與第一方和第三方SaaS接口的集成構建現代事件驅動(dòng)架構。

③現代化

公共云基礎設施提高了將應用程序推向市場(chǎng)的靈活性，并在釋放資源以專(zhuān)注于創(chuàng )造價(jià)值的活動(dòng)而不是管理服務(wù)器時(shí)降低總體擁有成本。

(2)示例4：在A(yíng)WS Wavelength上使用云原生5G基礎設施的低延遲Kafka

低延遲數據流需要靠近邊緣機器、設備、傳感器、智能手機和其他接口運行的基礎設施。AWS Wavelength專(zhuān)為這些場(chǎng)景而構建。企業(yè)不必在邊緣安裝自己的IT基礎設施。

以下架構顯示了Confluent、AWS和Verizon構建的示例：

(3)現場(chǎng)演示：混合云復制

行業(yè)專(zhuān)家通過(guò)現場(chǎng)演示來(lái)展示內部部署的Kafka集群和Confluent Cloud之間的流復制，其中包括使用ksqlDB進(jìn)行流處理以及與KafkaConnect的數據集成(使用完全托管的AWS S3連接器)。

6.反向ETL及其與數據湖和Kafka的關(guān)系

以下將探討人們可能聽(tīng)說(shuō)過(guò)的一個(gè)術(shù)語(yǔ)——反向ETL。這個(gè)流行術(shù)語(yǔ)仍處于早期發(fā)展階段，但得到越來(lái)越多的供應商的關(guān)注。簡(jiǎn)而言之，這意味著(zhù)將數據存儲在人們喜歡的長(cháng)期存儲(數據庫、數據倉庫、數據湖、Lake house)中，然后再次從那里取出數據以連接到其他業(yè)務(wù)系統。

在Kafka世界中，這與變更數據捕獲(CDC)相同。因此，反向ETL并不是什么新鮮事物。Confluent公司為許多相關(guān)系統提供CDC連接器，其中包括Oracle、MongoDB和Salesforce。

正如以上提到的，數據存儲供應商試圖提供動(dòng)態(tài)數據業(yè)務(wù)。行業(yè)專(zhuān)家認為，事件流平臺是企業(yè)架構中處理動(dòng)態(tài)數據的正確位置。通過(guò)這種方式，每個(gè)應用程序都可以實(shí)時(shí)使用數據。

7.使用AWS和Confluent的無(wú)服務(wù)器和云原生Kafka

云優(yōu)先策略是當今企業(yè)采用的主要策略。無(wú)論用例是新的綠地項目、棕地集成架構還是具有混合部署的現代邊緣場(chǎng)景，Kafka將成為處理動(dòng)態(tài)數據的一個(gè)事實(shí)標準。然而，Kafka只是拼圖的一部分，大多數企業(yè)更喜歡采用完整的云原生服務(wù)。

AWS和Confluent是一個(gè)經(jīng)過(guò)驗證的組合，適用于跨行業(yè)的各種用例，可以在任何地方部署和運行Kafka環(huán)境，包括公共云中的無(wú)服務(wù)器Kafka和公共云之外的云原生Kafka。雖然本文側重于Confluent和AWS之間的關(guān)系，但Confluent也與GCP和Azure建立了類(lèi)似的強大合作伙伴關(guān)系，以提供大量的動(dòng)態(tài)數據。

原文標題：Serverless Kafka in a Cloud-Native Data Lake Architecture，作者：Kai Wähner

【51CTO譯稿，合作站點(diǎn)轉載請注明原文譯者和出處為51CTO.com】

原文鏈接：https://server.51cto.com/Micro-678320.htm