與連續(xù)處理實時工作負載的動態(tài)數(shù)據(jù)相比，為報告和分析存儲靜止數(shù)據(jù)需要不同的功能和服務等級協(xié)議(SLA)。目前有許多開源框架、商業(yè)產(chǎn)品和SaaS云服務。不幸的是，這些底層技術經(jīng)常被誤解，被過度用于單片和不靈活的架構，并被供應商用于錯誤的用例。本文將探討面臨的這個困境，了解如何使用原生云技術構建現(xiàn)代數(shù)據(jù)堆棧。

構建云原生數(shù)據(jù)倉庫和數(shù)據(jù)湖的最佳實踐

以下探索一下通過數(shù)據(jù)倉庫、數(shù)據(jù)湖、數(shù)據(jù)流和湖屋構建原生云數(shù)據(jù)分析基礎設施的經(jīng)驗和教訓：

教訓1：在正確的地方處理和存儲數(shù)據(jù)

首先要問問自己：數(shù)據(jù)的用例是什么?

以下是一些數(shù)據(jù)用例示例和實現(xiàn)業(yè)務用例的示例工具：

• 管理循環(huán)報告=>數(shù)據(jù)倉庫及其開箱即用的報告工具。
• 結構化和非結構化數(shù)據(jù)的交互式分析=>數(shù)據(jù)倉庫或其他數(shù)據(jù)存儲之上的商業(yè)智能工具，如Tableau、Power BI、Qlik或TIBCO Spotfire。
• 事務性業(yè)務負載=>在Kubernetes環(huán)境或無服務器云基礎設施中運行的自定義Java應用程序。
• 高級分析，以了解歷史數(shù)據(jù)=>存儲在數(shù)據(jù)池中的原始數(shù)據(jù)集，用于應用強大的人工智能/機器學習技術(如TensorFlow)算法。
• 新事件的實時操作=>流式應用程序在相關數(shù)據(jù)時連續(xù)處理和關聯(lián)數(shù)據(jù)。

(1)根據(jù)需要在正確的平臺上進行實時或批量計算

批處理工作負載在為此而構建的基礎設施中運行得最好。例如，Hadoop或ApacheSpark。實時工作負載在為此而構建的基礎設施中運行得最好。例如ApacheKafka。

然而，有時兩個平臺都可以使用。了解底層基礎設施，以最佳方式利用它。Apache Kafka可以替換一個數(shù)據(jù)庫!盡管如此，它應該只在少數(shù)有意義的場景中進行(例如，簡化架構或增加業(yè)務價值)。

例如，作為事件序列的可重播性(帶有時間戳的保證順序)內(nèi)置于不可變的Kafka日志中。從Kafka中重放和重新處理歷史數(shù)據(jù)是很直接的，也是很多場景的完美用例，其中包括：

• 新的消費者應用程序
• 錯誤處理
• 合規(guī)/法規(guī)處理
• 查詢和分析已有事件
• 分析平臺的模式變化
• 模型訓練

另一方面，如果需要進行復雜的分析，如映射減少或變換、具有數(shù)十個join的SQL查詢、傳感器事件的健壯時間序列分析、基于攝取日志信息的搜索索引，等等。然后，最好選擇Spark、Rockset、ApacheDruid或Elasticsearch作為用例。

(2)使用云原生對象存儲實現(xiàn)分層存儲以提高效率并降低成本

單個存儲基礎設施無法解決所有這些問題。因此，在上述用例中，將所有數(shù)據(jù)攝取到單個系統(tǒng)將無法成功。因此需要選擇最好的方法。

現(xiàn)代的原生云系統(tǒng)將存儲和計算分離開來。對于數(shù)據(jù)流平臺(如Apache Kafka)和分析平臺(如Apache Spark、Snowflake或谷歌Big Query)來說也是如此。SaaS解決方案實現(xiàn)了創(chuàng)新的分層存儲解決方案(隱藏在內(nèi)部，所以看不到它們，從而實現(xiàn)了存儲和計算之間的低成本分離。

現(xiàn)代數(shù)據(jù)流服務也利用了分級存儲。

第二個教訓：不要為靜止數(shù)據(jù)進行反向設計

問問自己：如果現(xiàn)在而不是以后處理數(shù)據(jù)(不管以后意味著什么)，是否有任何額外的業(yè)務價值?

如果是，那么第一步不要將數(shù)據(jù)存儲在數(shù)據(jù)庫、數(shù)據(jù)湖或數(shù)據(jù)倉庫中。數(shù)據(jù)在靜止狀態(tài)下存儲，不再用于實時處理。如果在用例中實時數(shù)據(jù)優(yōu)于慢速數(shù)據(jù)，那么像Apache Kafka這樣的數(shù)據(jù)流平臺是正確的選擇!

研究發(fā)現(xiàn)，很多人把他們所有的原始數(shù)據(jù)放入數(shù)據(jù)存儲中，只是為了發(fā)現(xiàn)他們可以在以后實時利用這些數(shù)據(jù)。然后，在啟動反向ETL工具后，通過變更數(shù)據(jù)捕獲(CDC)或類似方法再次訪問數(shù)制湖中的數(shù)據(jù)?；蛘撸绻褂肧park Structured Streaming(=“real-time”)，但獲取“實時流處理”數(shù)據(jù)的第一件事是從S3對象存儲中讀取數(shù)據(jù)(=“at rest and too later”)是不合適的。

(1)反向ETL不是實時用例的正確方法

如果將數(shù)據(jù)存儲在數(shù)據(jù)倉庫或數(shù)據(jù)湖中，則無法再實時處理數(shù)據(jù)，因為它已經(jīng)在靜止狀態(tài)下存儲。這些數(shù)據(jù)存儲是為索引、搜索、批處理、報告、模型培訓以及存儲系統(tǒng)中有意義的其他使用案例而構建的。但是，不能從靜態(tài)存儲中實時處理動態(tài)數(shù)據(jù)。

(2)數(shù)據(jù)流是為實時連續(xù)處理數(shù)據(jù)而構建的

這就是事件流發(fā)揮作用的地方。像Apache Kafka這樣的平臺支持實時處理事務和分析工作負載的動態(tài)數(shù)據(jù)。

在現(xiàn)代事件驅(qū)動架構中不需要反向ETL!它“內(nèi)置”到開箱即用的架構中。如果適當且技術上可行，每個使用者直接實時使用數(shù)據(jù)。數(shù)據(jù)倉庫或數(shù)據(jù)湖仍然以接近實時或批量的速度處理數(shù)據(jù)。

同樣，這并不意味著不應該將數(shù)據(jù)放在數(shù)據(jù)倉庫或數(shù)據(jù)湖中。但只有在以后需要分析數(shù)據(jù)時才這樣做。靜態(tài)數(shù)據(jù)存儲不適合實時工作。

教訓3：不需要Lambda架構來分離批處理和實時工作負載

問問自己：用最喜歡的數(shù)據(jù)分析技術消費和處理傳入數(shù)據(jù)的最簡單方法是什么?

(1)實時數(shù)據(jù)勝過慢數(shù)據(jù)，但并不總是如此

考慮所在的行業(yè)、業(yè)務單位、解決的問題以及構建的創(chuàng)新應用程序。實時數(shù)據(jù)勝過慢數(shù)據(jù)。這種說法幾乎總是正確的?；蛘咴黾邮杖?，降低成本，降低風險，或者改善客戶體驗。

靜態(tài)數(shù)據(jù)意味著將數(shù)據(jù)存儲在數(shù)據(jù)庫、數(shù)據(jù)倉庫或數(shù)據(jù)湖中。這樣，即使實時流組件(如Kafka)接收數(shù)據(jù)，數(shù)據(jù)在許多用例中處理得太晚。數(shù)據(jù)處理仍然是一個Web服務調(diào)用、SQL查詢或map-reduce批處理過程，無法為問題提供結果。

靜止的數(shù)據(jù)并不是一件壞事。有幾個用例都可以很好地使用這種方法，例如報告(業(yè)務智能)、分析(批處理)和模型訓練(機器學習) 。但在幾乎所有其他用例中，實時性能優(yōu)于批處理。

(2)Kappa架構簡化了批處理和實時工作負載的基礎設施

Kappa架構是一個基于事件的軟件架構，可以實時處理事務和分析工作負載的任何規(guī)模的所有數(shù)據(jù)。

Kappa架構背后的核心前提是，可以使用單個技術堆棧執(zhí)行實時處理和批處理。這是一種與眾所周知的Lambda架構截然不同的方法。后者將批處理工作負載和實時工作負載分離到單獨的基礎設施和技術堆棧中。

Kappa基礎設施的核心是流式結構。首先，事件流平臺日志存儲傳入數(shù)據(jù)。從那里，流處理引擎可以持續(xù)實時地處理數(shù)據(jù)，或者通過任何通信范式和速度(包括實時、近實時、批處理和請求響應)將數(shù)據(jù)攝入任何其他分析數(shù)據(jù)庫或業(yè)務應用程序。

教訓4：理解靜態(tài)數(shù)據(jù)共享和流數(shù)據(jù)交換之間的權衡

問問自己：需要如何與其他內(nèi)部業(yè)務單位或外部企業(yè)共享數(shù)據(jù)?

(1)使用數(shù)據(jù)流、數(shù)據(jù)湖、數(shù)據(jù)倉庫和數(shù)據(jù)湖屋進行混合和多云復制的用例

跨數(shù)據(jù)中心、區(qū)域或云計算提供商復制數(shù)據(jù)有很多理由：

• 災難恢復和高可用性：創(chuàng)建災難恢復集群，并在業(yè)務中斷時時進行故障轉(zhuǎn)移。
• 全球和多云復制：跨區(qū)域和云計算移動和聚合數(shù)據(jù)。
• 數(shù)據(jù)共享：與其他團隊、業(yè)務線或企業(yè)共享數(shù)據(jù)。
• 數(shù)據(jù)遷移：將數(shù)據(jù)和工作負載從一個集群遷移到另一個集群(就像從傳統(tǒng)的內(nèi)部部署數(shù)據(jù)倉庫遷移到云原生數(shù)據(jù)湖屋)。

(2)實時數(shù)據(jù)復制勝過慢速數(shù)據(jù)共享

圍繞內(nèi)部或外部數(shù)據(jù)共享的故事與其他應用程序并無不同。實時復制勝過緩慢的數(shù)據(jù)交換。因此，如果實時信息增加了業(yè)務價值，那么靜態(tài)存儲數(shù)據(jù)然后將其復制到另一個數(shù)據(jù)中心、區(qū)域或云提供者是一種反模式。

以下示例顯示了獨立利益相關者(即不同企業(yè)中的域)如何使用跨公司流數(shù)據(jù)交換：

創(chuàng)新不會止步于自己的邊界。流復制適用于實時數(shù)據(jù)優(yōu)于慢速數(shù)據(jù)的所有用例(適用于大多數(shù)場景)。舉幾個例子：

(3)從供應商到制造商到中間商再到售后的端到端供應鏈優(yōu)化

• 跨越國家的追蹤。
• 將第三方附加服務集成到自己的數(shù)字產(chǎn)品中。
• 開放API，用于嵌入和組合外部服務，以構建新產(chǎn)品。

另外，要理解為什么API(=REST/HTTP)和數(shù)據(jù)流(=Apache Kafka)是互補關系，而不是競爭關系。

教訓5：數(shù)據(jù)網(wǎng)格不是單一的產(chǎn)品或技術

問問自己：如何創(chuàng)建一個靈活和敏捷的企業(yè)架構來更有效地創(chuàng)新，并更快地解決業(yè)務問題?

(1)數(shù)據(jù)網(wǎng)格是邏輯視圖，而不是物理視圖

數(shù)據(jù)網(wǎng)格轉(zhuǎn)變?yōu)橐环N借鑒現(xiàn)代分布式架構的范式：將域視為首要關注點，應用平臺思維創(chuàng)建自助式數(shù)據(jù)基礎設施，將數(shù)據(jù)視為產(chǎn)品，并實現(xiàn)開放標準化以實現(xiàn)可互操作的分布式數(shù)據(jù)產(chǎn)品生態(tài)系統(tǒng)。

下面是一個數(shù)據(jù)網(wǎng)格的例子：

數(shù)據(jù)網(wǎng)格結合了現(xiàn)有的范式，包括領域驅(qū)動設計、數(shù)據(jù)集市、微服務和事件流。

(2)數(shù)據(jù)倉庫或數(shù)據(jù)湖不是也不可能成為整個數(shù)據(jù)網(wǎng)格

數(shù)據(jù)網(wǎng)格基礎設施的核心應該是實時的、解耦的、可靠的和可伸縮的。Kafka是一個現(xiàn)代的云原生企業(yè)集成平臺(如今也常稱為iPaaS)。因此，Kafka為數(shù)據(jù)網(wǎng)格的基礎提供了所有的功能。

然而，并不是所有的組件都可以或者應該是基于kafka的。微服務架構的美妙之處在于，每個應用程序都可以選擇正確的技術。一個應用程序可能包含也可能不包含數(shù)據(jù)庫、分析工具或其他補充組件。數(shù)據(jù)產(chǎn)品的輸入和輸出數(shù)據(jù)端口應獨立于所選解決方案：

Kafka可以成為云原生數(shù)據(jù)網(wǎng)格的一個戰(zhàn)略組件。但是，即使不使用數(shù)據(jù)流，只使用靜止數(shù)據(jù)構建數(shù)據(jù)網(wǎng)格，也沒有什么靈丹妙藥。不要試圖用單一的產(chǎn)品、技術或供應商構建一個數(shù)據(jù)網(wǎng)格。無論該工具是專注于實時數(shù)據(jù)流、批處理和分析，還是基于API的接口。Starburst是一個基于SQL的MPP查詢引擎，由開源Trino(前身為Presto)提供支持，支持對不同數(shù)據(jù)存儲進行分析。

(3)云原生數(shù)據(jù)倉庫的最佳實踐超越SaaS產(chǎn)品

構建原生云數(shù)據(jù)倉庫或數(shù)據(jù)湖是一個龐大的項目。它需要數(shù)據(jù)攝入、數(shù)據(jù)集成、與分析平臺的連接、數(shù)據(jù)隱私和安全模式等等。在報告或分析等實際任務開始之前，所有這些都是必需的。

超出數(shù)據(jù)倉庫或數(shù)據(jù)湖范圍的完整企業(yè)架構甚至更加復雜。必須應用最佳實踐來構建一個有彈性的、可擴展、彈性的和具有成本效益的數(shù)據(jù)分析基礎設施。服務等級協(xié)議(SLA)、延遲和正常運行時間在業(yè)務域中有非常不同的需求。最好的方法是為工作選擇合適的工具。業(yè)務單元和應用程序之間的真正解耦允許專注于解決特定的業(yè)務問題。

存儲和計算分離，統(tǒng)一的實時管道而不是批處理和實時分離，避免像反向ETL這樣的反模式，適當?shù)臄?shù)據(jù)共享概念使云原生數(shù)據(jù)分析成為可能。