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

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

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

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

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

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

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

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

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

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

(2)AWS公司的Lake House策略

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

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

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

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

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

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

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

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

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

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

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

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

2.從“靜態(tài)數(shù)據(jù)”到“動態(tài)數(shù)據(jù)”

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

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

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

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

(1)Apache Kafka：動態(tài)數(shù)據(jù)的事實(shí)標(biāo)準(zhǔn)

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

Kafka API是用于動態(tài)數(shù)據(jù)的事實(shí)上的標(biāo)準(zhǔn)API，就像用于對象存儲的Amazon S3：

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

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

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

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

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

①一臺經(jīng)過充分測試的汽車引擎(沒有車輪、剎車、燈等)

②一輛完整的汽車(包括成熟和自動化的安保、安全和維護(hù))

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

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

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

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

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

真正完全托管的無服務(wù)器產(chǎn)品不會讓企業(yè)訪問服務(wù)器基礎(chǔ)設(shè)施。那么是否可以訪問AWS S3對象存儲或Snowflake服務(wù)器配置?并不是這樣，因?yàn)槟菢訉?dān)心這樣的操作可能影響甚至破壞集群。

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

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

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

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

4.Kafka不僅僅是消息傳遞和數(shù)據(jù)攝取

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

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

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

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

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

① 攝取和處理

使用Schema Registry捕獲具有一致數(shù)據(jù)結(jié)構(gòu)的事件流，使用ksqlDB、輕量級SQL語法開發(fā)實(shí)時ETL管道，并使用Kafka Connect連接器通過批處理統(tǒng)一實(shí)時流。

②存儲和分析

使用預(yù)先構(gòu)建的Confluent連接器將數(shù)據(jù)流式傳輸?shù)狡髽I(yè)的AWS數(shù)據(jù)湖或數(shù)據(jù)倉庫中，以對大量流式數(shù)據(jù)執(zhí)行查詢，從而進(jìn)行實(shí)時和批量分析。

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

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

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

①無服務(wù)器集成

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

②AWS無服務(wù)器平臺

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

5.Kafka無處不在：云平臺、內(nèi)部部署、邊緣

公共云是數(shù)據(jù)中心的未來。但是有兩個主要原因不能在公共云基礎(chǔ)設(shè)施中運(yùn)行所有內(nèi)容：

棕地架構(gòu)：許多企業(yè)在數(shù)據(jù)中心擁有大量應(yīng)用程序和基礎(chǔ)設(shè)施?；旌显萍軜?gòu)是唯一的選擇，例如大型機(jī)。 邊緣用例：由于成本、延遲、安全或法律原因，某些場景在公共云中沒有意義，例如智能工廠。

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

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

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

以下是棕地現(xiàn)代化的一個示例：

①連接

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

②橋接

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

③現(xiàn)代化

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

(2)示例4：在AWS Wavelength上使用云原生5G基礎(chǔ)設(shè)施的低延遲Kafka

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

以下架構(gòu)顯示了Confluent、AWS和Verizon構(gòu)建的示例：

(3)現(xiàn)場演示：混合云復(fù)制

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

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

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

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

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

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

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

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

網(wǎng)站欄目：云原生數(shù)據(jù)湖架構(gòu)中的無服務(wù)器Kafka
本文網(wǎng)址：http://jinyejixie.com/news33/203783.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供靜態(tài)網(wǎng)站、ChatGPT、標(biāo)簽優(yōu)化、軟件開發(fā)、網(wǎng)站建設(shè)、建站公司

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)