2022-10-09 分類: 網(wǎng)站建設
人們需要了解如何在混合云上利用云原生和無服務器Apache Kafka來處理與數(shù)據(jù)湖互補的動態(tài)數(shù)據(jù)。而Kafka是一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng),它可以處理消費者在網(wǎng)站中的所有動作流數(shù)據(jù)。
如今,Apache Kafka成為處理動態(tài)數(shù)據(jù)的一個事實標準。Kafka具有開放、靈活和可擴展的特性,但也使許多團隊面臨運營的挑戰(zhàn)。在理想情況下,企業(yè)的IT團隊可以使用無服務器Kafka SaaS產(chǎn)品來專注于業(yè)務邏輯。然而,混合場景需要在一個云原生平臺運行,該平臺提供自動化和彈性工具來減輕運營負擔。本文探討了如何在混合云架構中利用云原生和無服務器Kafka產(chǎn)品,并從數(shù)據(jù)湖的靜態(tài)數(shù)據(jù)的角度出發(fā),探索它與Kafka的動態(tài)數(shù)據(jù)的關系。
1.靜態(tài)數(shù)據(jù)仍然是一種正確的方法嗎?靜態(tài)數(shù)據(jù)是指將數(shù)據(jù)存儲在數(shù)據(jù)庫、數(shù)據(jù)倉庫或數(shù)據(jù)湖中。這意味著在許多用例中數(shù)據(jù)處理得太晚了——即使實時流組件(如Kafka)攝取了數(shù)據(jù)。數(shù)據(jù)處理仍然是Web服務調用、SQL查詢或map-reduce批處理過程,而不是解決遇到的問題。
靜止數(shù)據(jù)并不是一件壞事。報告(商業(yè)智能)、分析(批處理)和模型訓練(機器學習)等幾個用例需要這種方法。
(1)Cloudera數(shù)據(jù)湖的錯誤做法多年前,Cloudera公司和Hortonworks公司以及IBM等合作伙伴為大多數(shù)企業(yè)引入了數(shù)據(jù)湖技術。這些企業(yè)都有采用大數(shù)據(jù)的愿景(但他們不知道如何從中獲得商業(yè)價值)。而數(shù)據(jù)湖由20多個不同的開源框架組成。
新框架在出現(xiàn)時會添加,以便數(shù)據(jù)湖是最新的。那么面臨的主要問題是什么?沒有商業(yè)價值。此外可能沒有與良好商業(yè)模式的供應商合作,而只有銷售部門提供支持是行不通的,尤其是當兩個非常相似的供應商相互競爭時,其最終結果是Cloudera公司與Hortonworks公司合并。
Cloudera公司仍然為這么多不同的框架提供支持,其中包括許多數(shù)據(jù)湖技術,還有諸如Storm、Kafka、Spark Streaming和Flink等事件流平臺。人們很驚訝這家規(guī)模相對較小的公司如何做到這一點。很多人只對每個框架有一些了解,而且可能只對過時的Hadoop生態(tài)系統(tǒng)非常了解,因此這種商業(yè)模式行不通。而直到今年,Cloudera公司仍然沒有真正的SaaS產(chǎn)品。這也不足為奇,因為要構建一個具有20多個框架構建真正的SaaS產(chǎn)品并不容易。
事實表明,對于規(guī)模相對較小的企業(yè)來說,最好只做一件事,而不是試圖做所有的事情。
(2)AWS公司的Lake House策略云計算供應商需要一起構建數(shù)據(jù)湖,其中包括全球主要的云提供商(AWS、GCP、Azure、阿里巴巴)、MongoDB、Databricks和Snowflake。他們都有自己的特定用例和權衡,但有一個共同點是,他們的數(shù)據(jù)湖都有云優(yōu)先策略和無服務器SaaS產(chǎn)品。
以下了解AWS公司具有良好商業(yè)模式的現(xiàn)代云原生戰(zhàn)略將在今年有什么發(fā)展。
AWS公司作為全球公共云基礎設施的市場領導者,定期開發(fā)并推出新的基礎設施類別。例如,EC2實例開啟了云時代,并提供了敏捷和彈性的計算能力;S3成為對象存儲的事實上的行業(yè)標準。如今,AWS公司擁有數(shù)百種創(chuàng)新的SaaS服務。
(3)AWS的數(shù)據(jù)湖策略基于新的流行術語Lake House眾所周知,雖然關鍵信息是一種解決方案,但并不能解決所有問題。更重要的是,這些問題都可以通過云原生、無服務器AWS解決方案解決。
這就是公共云中的云原生數(shù)據(jù)湖產(chǎn)品的外觀。顯然,像GCP和Azure等其他云計算報務商的無服務器產(chǎn)品也朝著相同的方向發(fā)展。
然而,由于網(wǎng)絡延遲、安全性和成本等原因,公共云并不是解決所有問題的理想選擇。
(4)混合云和多云成為常態(tài)近年來,許多新的創(chuàng)新解決方案針對另一個市場:邊緣計算和內(nèi)部基礎設施。一些示例包括AWS本地區(qū)域、AWS Outposts、AWS Wavelength。AWS公司通常會設置新基礎設施以及提供軟件類別的創(chuàng)新方法,大多數(shù)云計算提供商都有非常相似的產(chǎn)品。AWS公司在許多情況下推出它,而其他公司通?;蚨嗷蛏俚剡M行復制。
話雖如此,每個云計算提供商都有各自的優(yōu)勢。谷歌云平臺(GCP)以其在Kubernetes、Tensor Flow等開源服務方面的行業(yè)地位而聞名。IBM和Oracle更擅長為自己的產(chǎn)品提供服務和基礎設施。
用戶對于采用多個云提供商的服務有著更多的需求。大多數(shù)企業(yè)都有使用AWS公司和其他供應商(如Azure、GCP、IBM、Oracle或阿里巴巴)的多云戰(zhàn)略。使用不同云計算供應商提供的云服務的理由很充分,其中包括成本、數(shù)據(jù)位置、跨供應商的災難恢復、供應商獨立性、歷史原因和專用的特定于云的服務。
幸運的是,無服務器Kafka SaaS Confluent Cloud可用于所有主要云。因此,類似的示例可用于將完全托管的Kafka生態(tài)系統(tǒng)與Azure和GCP云平臺一起使用。
2.從“靜態(tài)數(shù)據(jù)”到“動態(tài)數(shù)據(jù)”在進行相關介紹之后,現(xiàn)在又回到了無服務器Kafka。只有知道這些背景,人們才有可能了解動態(tài)數(shù)據(jù)的興起以及對云原生和無服務器服務的需求。
先從關鍵信息開始:
在跨行業(yè)的大多數(shù)用例中,實時數(shù)據(jù)勝過慢速傳輸?shù)臄?shù)據(jù)。 對于事件流,需要采用與現(xiàn)代數(shù)據(jù)湖相同的云原生方法。 事件流和數(shù)據(jù)湖技術是互補的,而不是競爭性的。由Apache Kafka提供支持的事件驅動架構和動態(tài)數(shù)據(jù)的興起,使企業(yè)能夠構建實時基礎設施和應用程序。
(1)Apache Kafka:動態(tài)數(shù)據(jù)的事實標準簡而言之,大多數(shù)附加值來自處理相關的動態(tài)數(shù)據(jù),而不是存儲靜態(tài)數(shù)據(jù)并稍后處理(有可能為時已晚)。Forrester公司的分析師Mike Gualtieri采用下圖很好地說明了這一點:
Kafka API是用于動態(tài)數(shù)據(jù)的事實上的標準API,就像用于對象存儲的Amazon S3:
雖然Snowflake公司和MongoDB公司等供應商希望進入動態(tài)數(shù)據(jù)業(yè)務,但這可能并沒有什么意義。正如以上針對Cloudera公司所討論的那樣,最好只專注于一件事并將其做好。這就是為什么Confluent公司不僅與云計算提供商,而且還與Snowflake和MongoDB更加緊密合作的原因。
Apache Kafka是經(jīng)過實戰(zhàn)測試且可擴展的開源框架,用于處理動態(tài)數(shù)據(jù)。然而,它更像是一臺汽車引擎。
3.完整的無服務器Kafka平臺當人們談論云計算、無服務器、AWS公司等時,可能會問自己:“如果可以簡單地使用Amazon MSK,為什么還要考慮采用AWS上的Kafka?”而回答這個問題的答案是:Amazon MSK是PaaS,而不是完全托管和無服務器的Kafka SaaS產(chǎn)品。
那么你更喜歡購買以下的哪一個產(chǎn)品?
①一臺經(jīng)過充分測試的汽車引擎(沒有車輪、剎車、燈等)
②一輛完整的汽車(包括成熟和自動化的安保、安全和維護)
③一輛自動駕駛汽車(包括無需轉向、加油、換剎車、產(chǎn)品召回等的安全自動駕駛)
而在Kafka的世界里,人們可以從Confluent公司獲得一輛自動駕駛汽車。這并不是銷售或營銷的一種宣傳,而是事實。所有其他云計算產(chǎn)品都為用戶提供自我管理的產(chǎn)品,企業(yè)需要自己選擇代理、修復錯誤、進行性能調整等。AWS MSK也是如此。因此建議評估不同的產(chǎn)品,以了解“完全托管”或“無服務器”是營銷術語還是事實。
無論是要構建數(shù)據(jù)湖/Lake House架構、與其他第三方應用程序集成,還是構建新的自定義業(yè)務應用程序:無服務器是云計算的發(fā)展方向,
(1)無服務器、完全托管的Kafka如果企業(yè)采用公共云,完全托管的無服務器產(chǎn)品是好選擇,無需擔心運營工作。與其相反,應該使用即用即付模型以及基于消費的定價和關鍵任務服務等級協(xié)議(SLA)關注和支持解決業(yè)務問題。
真正完全托管的無服務器產(chǎn)品不會讓企業(yè)訪問服務器基礎設施。那么是否可以訪問AWS S3對象存儲或Snowflake服務器配置?并不是這樣,因為那樣將會擔心這樣的操作可能影響甚至破壞集群。
(2)自我管理的云原生Kafka并非每個Kafka集群都在公共云中運行。因此,一些Kafka集群需要由企業(yè)的運維團隊自己進行管理。很多企業(yè)都在為管理Kafka而陷于困境,特別是如果用例不僅僅是將數(shù)據(jù)攝取到數(shù)據(jù)湖中,而是關鍵的事務或分析工作負載。
云原生Kafka通過自動化支持運營團隊,減少了企業(yè)的風險和工作量。例如,自平衡集群接管分區(qū)的重新平衡。自動滾動升級允許企業(yè)升級到每個新版本,而不是運行昂貴且有風險的遷移項目。計算和存儲的分離(使用分層存儲)支持大型但經(jīng)濟高效的Kafka集群,其中包含TB級甚至PB級的數(shù)據(jù)。
順便說一句:云原生Kafka集群不必在Kubernetes上運行。Ansible或普通容器/裸機部署是在企業(yè)的數(shù)據(jù)中心或邊緣部署Kafka的其他常見選項。但是Kubernetes提供了關于具有彈性規(guī)模的自動化的好云原生體驗。因此,供應商在過去幾年開發(fā)了各種Kafka Operators(基于CRD),例如Confluent for Kubernetes或Red Hat公司的Strimzi。
4.Kafka不僅僅是消息傳遞和數(shù)據(jù)攝取最后需要明確一點:Kafka不僅僅是消息傳遞和數(shù)據(jù)攝取。如今大多數(shù)Kafka項目也利用Kafka Connect進行數(shù)據(jù)集成或Kafka Streams/ksql DB進行連續(xù)數(shù)據(jù)處理。因此使用Kafka,可以在分布式和可擴展的基礎設施支持數(shù)據(jù)的消息傳遞、存儲、集成和處理:
一個完全托管的Kafka平臺不僅運營Kafka,還運營整個生態(tài)系統(tǒng)。例如,完全托管的連接器支持與原生AWS服務(如S3、Redshift或Lambda)以及非AWS系統(tǒng)(如MongoDB Atlas、Salesforce或Snowflake)進行無服務器數(shù)據(jù)集成。此外,使用ksqlDB的完全托管流分析支持大規(guī)模連續(xù)數(shù)據(jù)處理。
而一個完整的Kafka平臺提供了整個生態(tài)系統(tǒng),其中包括安全性(基于角色的訪問控制、加密、審計日志)、數(shù)據(jù)治理(模式注冊、數(shù)據(jù)質量、數(shù)據(jù)目錄、數(shù)據(jù)沿襲)以及許多其他特性,如全局彈性、靈活的DevOps自動化、指標和監(jiān)控。
(1)示例1:事件流+數(shù)據(jù)湖/Lake House以下示例展示了如何使用完整的平臺通過各種Confluent組件以及與AWS湖屋服務的集成進行實時分析:
① 攝取和處理
使用Schema Registry捕獲具有一致數(shù)據(jù)結構的事件流,使用ksqlDB、輕量級SQL語法開發(fā)實時ETL管道,并使用Kafka Connect連接器通過批處理統(tǒng)一實時流。
②存儲和分析
使用預先構建的Confluent連接器將數(shù)據(jù)流式傳輸?shù)狡髽I(yè)的AWS數(shù)據(jù)湖或數(shù)據(jù)倉庫中,以對大量流式數(shù)據(jù)執(zhí)行查詢,從而進行實時和批量分析。
這個例子很好地展示了數(shù)據(jù)湖或Lake house服務和事件流如何相互補充。所有服務都是SaaS。甚至集成(由Kafka Connect提供支持)也是無服務器的。
(2)示例2:無服務器應用程序和微服務集成以下示例展示了如何使用完整的平臺將現(xiàn)有的應用程序和無服務器微服務與各種Confluent和AWS服務集成,并構建新的應用程序:
①無服務器集成
以可重復的方式連接現(xiàn)有的應用程序和數(shù)據(jù)存儲,而無需管理和操作任何東西。Apache Kafka和Schema Registry確保保持應用程序兼容性。ksqlDB允許使用SQL語法開發(fā)實時應用程序。Kafka Connect提供與Lambda和數(shù)據(jù)存儲的輕松集成。
②AWS無服務器平臺
停止為后端組件(例如計算、數(shù)據(jù)庫和存儲)配置、維護或管理服務器,以便企業(yè)可以專注于提高開發(fā)人員團隊的敏捷性和創(chuàng)新。
5.Kafka無處不在:云平臺、內(nèi)部部署、邊緣公共云是數(shù)據(jù)中心的未來。但是有兩個主要原因不能在公共云基礎設施中運行所有內(nèi)容:
棕地架構:許多企業(yè)在數(shù)據(jù)中心擁有大量應用程序和基礎設施?;旌显萍軜嬍俏ㄒ坏倪x擇,例如大型機。 邊緣用例:由于成本、延遲、安全或法律原因,某些場景在公共云中沒有意義,例如智能工廠。Apache Kafka的多集群和跨數(shù)據(jù)中心部署已經(jīng)成為一個常態(tài)而非例外。多個場景需要多集群解決方案,包括災難恢復、分析聚合、云遷移、關鍵任務延伸部署和全球Kafka。
各種AWS基礎設施支持在公共云之外部署Kafka。Confluent平臺在AWS Outposts上獲得認證,因此可以在各種AWS硬件產(chǎn)品上運行。
(1)示例3:與Kafka原生集群鏈接的混合集成以下是棕地現(xiàn)代化的一個示例:
①連接
預先構建的連接器不斷從本地現(xiàn)有服務中獲取有價值的數(shù)據(jù),包括企業(yè)數(shù)據(jù)倉庫、數(shù)據(jù)庫和大型機。此外,在需要時也可以進行雙向通信。
②橋接
混合云流支持一致、可靠的實時復制,為新應用程序以及與第一方和第三方SaaS接口的集成構建現(xiàn)代事件驅動架構。
③現(xiàn)代化
公共云基礎設施提高了將應用程序推向市場的靈活性,并在釋放資源以專注于創(chuàng)造價值的活動而不是管理服務器時降低總體擁有成本。
(2)示例4:在AWS Wavelength上使用云原生5G基礎設施的低延遲Kafka低延遲數(shù)據(jù)流需要靠近邊緣機器、設備、傳感器、智能手機和其他接口運行的基礎設施。AWS Wavelength專為這些場景而構建。企業(yè)不必在邊緣安裝自己的IT基礎設施。
以下架構顯示了Confluent、AWS和Verizon構建的示例:
(3)現(xiàn)場演示:混合云復制行業(yè)專家通過現(xiàn)場演示來展示內(nèi)部部署的Kafka集群和Confluent Cloud之間的流復制,其中包括使用ksqlDB進行流處理以及與KafkaConnect的數(shù)據(jù)集成(使用完全托管的AWS S3連接器)。
6.反向ETL及其與數(shù)據(jù)湖和Kafka的關系以下將探討人們可能聽說過的一個術語——反向ETL。這個流行術語仍處于早期發(fā)展階段,但得到越來越多的供應商的關注。簡而言之,這意味著將數(shù)據(jù)存儲在人們喜歡的長期存儲(數(shù)據(jù)庫、數(shù)據(jù)倉庫、數(shù)據(jù)湖、Lake house)中,然后再次從那里取出數(shù)據(jù)以連接到其他業(yè)務系統(tǒng)。
在Kafka世界中,這與變更數(shù)據(jù)捕獲(CDC)相同。因此,反向ETL并不是什么新鮮事物。Confluent公司為許多相關系統(tǒng)提供CDC連接器,其中包括Oracle、MongoDB和Salesforce。
正如以上提到的,數(shù)據(jù)存儲供應商試圖提供動態(tài)數(shù)據(jù)業(yè)務。行業(yè)專家認為,事件流平臺是企業(yè)架構中處理動態(tài)數(shù)據(jù)的正確位置。通過這種方式,每個應用程序都可以實時使用數(shù)據(jù)。
7.使用AWS和Confluent的無服務器和云原生Kafka云優(yōu)先策略是當今企業(yè)采用的主要策略。無論用例是新的綠地項目、棕地集成架構還是具有混合部署的現(xiàn)代邊緣場景,Kafka將成為處理動態(tài)數(shù)據(jù)的一個事實標準。然而,Kafka只是拼圖的一部分,大多數(shù)企業(yè)更喜歡采用完整的云原生服務。
AWS和Confluent是一個經(jīng)過驗證的組合,適用于跨行業(yè)的各種用例,可以在任何地方部署和運行Kafka環(huán)境,包括公共云中的無服務器Kafka和公共云之外的云原生Kafka。雖然本文側重于Confluent和AWS之間的關系,但Confluent也與GCP和Azure建立了類似的強大合作伙伴關系,以提供大量的動態(tài)數(shù)據(jù)。
網(wǎng)站欄目:云原生數(shù)據(jù)湖架構中的無服務器Kafka
本文網(wǎng)址:http://m.rwnh.cn/news33/203783.html
成都網(wǎng)站建設公司_創(chuàng)新互聯(lián),為您提供靜態(tài)網(wǎng)站、ChatGPT、標簽優(yōu)化、軟件開發(fā)、網(wǎng)站建設、建站公司
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉載內(nèi)容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載,或轉載時需注明來源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容