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

2022-10-09    分類: 網(wǎng)站建設(shè)

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

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

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

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

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

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

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

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

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

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

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

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

(2)AWS公司的Lake House策略

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Kafka API是用于動(dòng)態(tài)數(shù)據(jù)的事實(shí)上的標(biāo)準(zhǔn)API,就像用于對(duì)象存儲(chǔ)的Amazon S3:

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

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

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

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

當(dāng)人們談?wù)撛朴?jì)算、無(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)品。

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

①一臺(tái)經(jīng)過(guò)充分測(cè)試的汽車引擎(沒有車輪、剎車、燈等)

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

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

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

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

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

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

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

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

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

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

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

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

順便說(shuō)一句:云原生Kafka集群不必在Kubernetes上運(yùn)行。Ansible或普通容器/裸機(jī)部署是在企業(yè)的數(shù)據(jù)中心或邊緣部署Kafka的其他常見選項(xiàng)。但是Kubernetes提供了關(guān)于具有彈性規(guī)模的自動(dòng)化的好云原生體驗(yàn)。因此,供應(yīng)商在過(guò)去幾年開發(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ù)的消息傳遞、存儲(chǔ)、集成和處理:

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

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

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

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

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

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

① 攝取和處理

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

②存儲(chǔ)和分析

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

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

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

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

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

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

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

②AWS無(wú)服務(wù)器平臺(tái)

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

5.Kafka無(wú)處不在:云平臺(tái)、內(nèi)部部署、邊緣

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

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

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

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

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

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

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

①連接

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

②橋接

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

③現(xiàn)代化

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

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

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

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

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

(3)現(xiàn)場(chǎng)演示:混合云復(fù)制

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

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

以下將探討人們可能聽說(shuō)過(guò)的一個(gè)術(shù)語(yǔ)——反向ETL。這個(gè)流行術(shù)語(yǔ)仍處于早期發(fā)展階段,但得到越來(lái)越多的供應(yīng)商的關(guān)注。簡(jiǎn)而言之,這意味著將數(shù)據(jù)存儲(chǔ)在人們喜歡的長(zhǎng)期存儲(chǔ)(數(shù)據(jù)庫(kù)、數(shù)據(jù)倉(cāng)庫(kù)、數(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ù)存儲(chǔ)供應(yīng)商試圖提供動(dòng)態(tài)數(shù)據(jù)業(yè)務(wù)。行業(yè)專家認(rèn)為,事件流平臺(tái)是企業(yè)架構(gòu)中處理動(dòng)態(tài)數(shù)據(jù)的正確位置。通過(guò)這種方式,每個(gè)應(yīng)用程序都可以實(shí)時(shí)使用數(shù)據(jù)。

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

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

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

網(wǎng)站標(biāo)題:云原生數(shù)據(jù)湖架構(gòu)中的無(wú)服務(wù)器Kafka
分享URL:http://muchs.cn/news/203783.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站改版、App開發(fā)品牌網(wǎng)站設(shè)計(jì)、定制開發(fā)做網(wǎng)站、網(wǎng)站制作

廣告

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

商城網(wǎng)站建設(shè)