三個(gè)案例告訴你，數(shù)倉(cāng)數(shù)據(jù)流如何搭建？

作者：張鋒 2022-11-25 10:07:12

Confluent盡量多用自身開(kāi)發(fā)的軟件來(lái)實(shí)現(xiàn)內(nèi)部數(shù)據(jù)倉(cāng)庫(kù)管道的現(xiàn)代化的做法，該使用案例在大多數(shù)組織中都是簡(jiǎn)單和標(biāo)準(zhǔn)的：將Salesforce數(shù)據(jù)提取、轉(zhuǎn)換和加載（ETL）到Google BigQuery數(shù)據(jù)倉(cāng)庫(kù)中，以便企業(yè)可以使用這些數(shù)據(jù)。

?譯者 | 張鋒

策劃 | 云昭

不同項(xiàng)目都有各自的難點(diǎn)，數(shù)據(jù)流、分析和其他軟件開(kāi)發(fā)都是如此。下面顯示了三個(gè)案例研究，它們具有顯著不同的數(shù)據(jù)倉(cāng)庫(kù)現(xiàn)代化體系結(jié)構(gòu)和技術(shù)。這些例子來(lái)自不同的垂直行業(yè)：軟件和云業(yè)務(wù)，金融服務(wù)，物流和運(yùn)輸，以及旅游住宿業(yè)。

1、Confluent從使用Stitch的批量ETL到使用Kafka的流式ETL的數(shù)據(jù)倉(cāng)庫(kù)現(xiàn)代化

組織通常依靠第三方ETL工具定期將數(shù)據(jù)從CRM和其他應(yīng)用程序加載到其數(shù)據(jù)倉(cāng)庫(kù)中。這些批處理工具在Salesforc中捕獲業(yè)務(wù)事件的時(shí)間與這些事件可供使用和處理的時(shí)間之間引入了延遲。批處理工作負(fù)載通常會(huì)導(dǎo)致Salesforce報(bào)告和內(nèi)部?jī)x表板之間出現(xiàn)差異，從而導(dǎo)致對(duì)數(shù)據(jù)完整性和可靠性的擔(dān)憂。

Confluent一開(kāi)始使用了Talend的Stitch Batch ETL工具。舊架構(gòu)是這樣的：

批處理ETL和中間的第三方工具

導(dǎo)致信息更新不充分和不一致

在過(guò)去幾年中，Confluent投資于在內(nèi)部數(shù)據(jù)倉(cāng)庫(kù)管道中構(gòu)建流處理功能。Confluent利用其自己的完全托管的Confluent Cloud連接器（在本例中為Salesforce CDC Source和BigQuery Sink連接器）、用于數(shù)據(jù)治理的Schema Registry和用于可靠流式ETL的KSQLDB+Kafka Streams將SFDC數(shù)據(jù)發(fā)送到BigQuery。這里是現(xiàn)代化的架構(gòu)：

2、PayPal將每天300億個(gè)事件的讀取時(shí)間從12小時(shí)縮短到幾秒鐘

PayPal有大量的Kafka項(xiàng)目，用于許多關(guān)鍵和分析工作負(fù)載。在此使用案例中，它將Kafka消費(fèi)者擴(kuò)展為每天300-350億個(gè)事件，以將其分析工作負(fù)載遷移到Google云平臺(tái)（GCP）。

流應(yīng)用程序?qū)?lái)自Kafka的事件直接接收到BigQuery。這是PayPal的一個(gè)關(guān)鍵項(xiàng)目，因?yàn)榇蠖鄶?shù)分析讀數(shù)都基于此。數(shù)據(jù)倉(cāng)庫(kù)現(xiàn)代化和構(gòu)建云原生架構(gòu)的成果是：將讀取時(shí)間從12小時(shí)縮短到幾秒鐘。

3、Shippeo從本地部署數(shù)據(jù)庫(kù)到多個(gè)云原生數(shù)據(jù)湖

Shippeo是一個(gè)法國(guó)供應(yīng)鏈可視化管理平臺(tái)，致力于為企業(yè)提供準(zhǔn)確的物流配送預(yù)測(cè)信息以及實(shí)時(shí)跟蹤信息服務(wù)。平臺(tái)配備有基于機(jī)器學(xué)習(xí)的ETA算法，可以快速分析和提醒運(yùn)輸途中出現(xiàn)的問(wèn)題，幫助企業(yè)有效地應(yīng)對(duì)危機(jī)。

Shippeo為物流提供商、托運(yùn)人和承運(yùn)商提供實(shí)時(shí)和多式聯(lián)運(yùn)可見(jiàn)性。它的軟件使用自動(dòng)化和人工智能來(lái)分享實(shí)時(shí)洞察，實(shí)現(xiàn)更好的協(xié)作，并釋放您的供應(yīng)鏈的全部潛力。該平臺(tái)可以即時(shí)訪問(wèn)每次交付的預(yù)測(cè)性實(shí)時(shí)信息。

下圖描述了Shippeo如何將傳統(tǒng)數(shù)據(jù)庫(kù)（MySQL和PostgreSQL）和云原生數(shù)據(jù)倉(cāng)庫(kù)（Snowflake和BigQuery）與Apache Kafka和Debezium集成：

這是云原生企業(yè)架構(gòu)利用“單項(xiàng)優(yōu)勢(shì)”方法構(gòu)建數(shù)據(jù)倉(cāng)庫(kù)和分析的絕佳示例。Kafka將分析工作負(fù)載從事務(wù)系統(tǒng)中分離出來(lái)，并為緩慢的消費(fèi)者處理背壓。

4、Sykes Cottages通過(guò)Confluent Cloud、Kafka Connect和Snowflake全面管理端到端管道

Sykes Holiday Cottages是英國(guó)領(lǐng)先且發(fā)展最快的獨(dú)立度假別墅租賃機(jī)構(gòu)之一，在英國(guó)、愛(ài)爾蘭和新西蘭擁有超過(guò)19000間度假別墅。

客戶在網(wǎng)絡(luò)上的體驗(yàn)是重中之重，也是保持競(jìng)爭(zhēng)力的一種方式。我們的目標(biāo)是讓客戶在每個(gè)階段都能獲得完美的度假小屋體驗(yàn)和樂(lè)趣。讓數(shù)據(jù)管道為這一創(chuàng)新提供動(dòng)力至關(guān)重要。數(shù)據(jù)倉(cāng)庫(kù)現(xiàn)代化和數(shù)據(jù)流提供了通過(guò)數(shù)據(jù)驅(qū)動(dòng)的方法進(jìn)一步創(chuàng)新Web體驗(yàn)的新方法。

5、從不一致和緩慢的批處理工作負(fù)載

雖然已經(jīng)使用了幾年，但現(xiàn)有的管道出現(xiàn)了一些問(wèn)題，影響了這個(gè)循環(huán)。在這個(gè)管道的早期，ETL過(guò)程將數(shù)據(jù)轉(zhuǎn)換為行和列（結(jié)構(gòu)化數(shù)據(jù)）。制作了各種副本，并通過(guò)靜態(tài)報(bào)告呈現(xiàn)結(jié)果。需要數(shù)據(jù)工程師來(lái)處理變化，如新事件或上下文信息。規(guī)模也具有挑戰(zhàn)性，因?yàn)檫@主要是手動(dòng)完成的。

Sykes Holiday Cottages嚴(yán)格地將數(shù)據(jù)保存在半結(jié)構(gòu)化格式中，直到將其接收到倉(cāng)庫(kù)中，然后使用ELT對(duì)數(shù)據(jù)進(jìn)行一次轉(zhuǎn)換，這樣可以簡(jiǎn)化管道并使其更加靈活。

6、基于事件的實(shí)時(shí)更新和連續(xù)流處理

新的Web事件（以及與之相關(guān)的任何上下文）都可以包裝在消息中，并且可以一直流到倉(cāng)庫(kù)，而不需要進(jìn)行任何代碼更改。然后，Web團(tuán)隊(duì)可以通過(guò)查詢或可視化工具獲得新事件。

當(dāng)前吞吐量約為每分鐘50K（峰值超過(guò)300K）條消息。隨著新事件的捕獲，這將大大增加。此外，上述每個(gè)組件都必須相應(yīng)地進(jìn)行縮放。

新的體系結(jié)構(gòu)使Web團(tuán)隊(duì)能夠捕獲新事件并使用自助服務(wù)工具分析數(shù)據(jù)，而不依賴于數(shù)據(jù)工程。

總之，這樣做的商業(yè)案例是令人信服的。根據(jù)我們的測(cè)試和預(yù)測(cè)，我們預(yù)計(jì)這項(xiàng)投資在三年內(nèi)至少有10倍的投資回報(bào)率。

7、DoorDash從多管道到Snowflake集成的數(shù)據(jù)流

即使是數(shù)字原生代，在自己的數(shù)據(jù)中心沒(méi)有傳統(tǒng)應(yīng)用程序的情況下在云中開(kāi)展業(yè)務(wù)，也需要實(shí)現(xiàn)企業(yè)架構(gòu)的現(xiàn)代化，以改進(jìn)業(yè)務(wù)流程、降低成本并為其下游應(yīng)用程序提供實(shí)時(shí)信息。

構(gòu)建多條試圖實(shí)現(xiàn)類似目的的管道是成本效率低下的。DoorDash使用云原生AWS消息傳遞和流數(shù)據(jù)處理系統(tǒng)（如Amazon SQS和Amazon Kinesis）將數(shù)據(jù)接收到Snowflake數(shù)據(jù)倉(cāng)庫(kù)中：

混合不同類型的數(shù)據(jù)傳輸并通過(guò)多個(gè)消息傳遞/排列系統(tǒng)，而沒(méi)有仔細(xì)設(shè)計(jì)其周圍的可觀察性，導(dǎo)致操作困難。

這些問(wèn)題導(dǎo)致了DoorDash的高數(shù)據(jù)延遲、巨大的成本和運(yùn)營(yíng)開(kāi)銷。因此，DoorDash遷移到由Apache Kafka和Apache Flink提供支持的云原生流平臺(tái)，以便在將數(shù)據(jù)接收到Snowflake之前進(jìn)行連續(xù)的流處理：

向數(shù)據(jù)流平臺(tái)的遷移為DoorDash帶來(lái)了許多好處：

異構(gòu)數(shù)據(jù)源和目的，包括使用Confluent REST代理的REST API
易于訪問(wèn)
具有Schema約束的端到端數(shù)據(jù)治理和具有Confluent Schema Registry的Schema演變
可擴(kuò)展，容錯(cuò)，易于小型團(tuán)隊(duì)操作

關(guān)于這種云原生基礎(chǔ)設(shè)施優(yōu)化有很多細(xì)節(jié)，比如如何使用Kafka和Flink構(gòu)建可擴(kuò)展的實(shí)時(shí)事件處理等等。

8、云原生項(xiàng)目的真實(shí)案例研究證明了其商業(yè)價(jià)值

數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)湖現(xiàn)代化，只有在有業(yè)務(wù)價(jià)值的情況下才有意義。Snowflake、Databricks或Google BigQuery等云服務(wù)的顯著優(yōu)勢(shì)是彈性擴(kuò)展、降低操作復(fù)雜性和加快上市時(shí)間。

數(shù)據(jù)流在這些計(jì)劃中發(fā)揮著至關(guān)重要的作用，以集成傳統(tǒng)和云原生數(shù)據(jù)源、連續(xù)流ETL、數(shù)據(jù)源之間的真正解耦以及多個(gè)數(shù)據(jù)接收器（數(shù)據(jù)湖、數(shù)據(jù)倉(cāng)庫(kù)、業(yè)務(wù)應(yīng)用程序）。

Confluent、PayPal、Shippeo、Sykes Cottages和DoorDash的案例研究展示了他們遷移到云原生基礎(chǔ)架構(gòu)以提高實(shí)時(shí)可見(jiàn)性和分析能力的不同成功案例。彈性擴(kuò)展和全面管理的端到端管道是通過(guò)不斷更新的信息獲取業(yè)務(wù)價(jià)值的關(guān)鍵成功因素。

原文鏈接：https://dzone.com/articles/case-studies-cloud-native-data-streaming-for-data