?譯者 | 張鋒

策劃 | 云昭

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

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

Confluent盡量多用自身開發(fā)的軟件來實現(xiàn)內(nèi)部數(shù)據(jù)倉庫管道的現(xiàn)代化的做法，該使用案例在大多數(shù)組織中都是簡單和標準的：將Salesforce數(shù)據(jù)提取、轉(zhuǎn)換和加載（ETL）到Google BigQuery數(shù)據(jù)倉庫中，以便企業(yè)可以使用這些數(shù)據(jù)。但實際上它要比聽起來更為復雜。

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

Confluent一開始使用了Talend的Stitch Batch ETL工具。舊架構是這樣的：

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

導致信息更新不充分和不一致

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

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

PayPal有大量的Kafka項目，用于許多關鍵和分析工作負載。在此使用案例中，它將Kafka消費者擴展為每天300-350億個事件，以將其分析工作負載遷移到Google云平臺（GCP）。

流應用程序?qū)碜訩afka的事件直接接收到BigQuery。這是PayPal的一個關鍵項目，因為大多數(shù)分析讀數(shù)都基于此。數(shù)據(jù)倉庫現(xiàn)代化和構建云原生架構的成果是：將讀取時間從12小時縮短到幾秒鐘。

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

Shippeo是一個法國供應鏈可視化管理平臺，致力于為企業(yè)提供準確的物流配送預測信息以及實時跟蹤信息服務。平臺配備有基于機器學習的ETA算法，可以快速分析和提醒運輸途中出現(xiàn)的問題，幫助企業(yè)有效地應對危機。

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

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

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

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

Sykes Holiday Cottages是英國領先且發(fā)展最快的獨立度假別墅租賃機構之一，在英國、愛爾蘭和新西蘭擁有超過19000間度假別墅。

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

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

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

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

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

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

當前吞吐量約為每分鐘50K（峰值超過300K）條消息。隨著新事件的捕獲，這將大大增加。此外，上述每個組件都必須相應地進行縮放。

新的體系結構使Web團隊能夠捕獲新事件并使用自助服務工具分析數(shù)據(jù)，而不依賴于數(shù)據(jù)工程。

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

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

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

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

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

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

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

• 異構數(shù)據(jù)源和目的，包括使用Confluent REST代理的REST API
• 易于訪問
• 具有Schema約束的端到端數(shù)據(jù)治理和具有Confluent Schema Registry的Schema演變
• 可擴展，容錯，易于小型團隊操作

關于這種云原生基礎設施優(yōu)化有很多細節(jié)，比如如何使用Kafka和Flink構建可擴展的實時事件處理等等。

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

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

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

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

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

譯者介紹

張鋒，51CTO社區(qū)編輯，長期從事技術顧問工作，專注于運維/云原生領域，精通網(wǎng)絡疑難故障分析，有很豐富的大型銀行運維工具建設實踐經(jīng)驗。?