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

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

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

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

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

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

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

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

批處理工作負載在為此而構(gòu)建的基礎(chǔ)設(shè)施中運行得最好。例如，Hadoop或ApacheSpark。實時工作負載在為此而構(gòu)建的基礎(chǔ)設(shè)施中運行得最好。例如ApacheKafka。

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

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

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

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

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

單個存儲基礎(chǔ)設(shè)施無法解決所有這些問題。因此，在上述用例中，將所有數(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ù)流服務(wù)也利用了分級存儲。

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

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

如果是，那么第一步不要將數(shù)據(jù)存儲在數(shù)據(jù)庫、數(shù)據(jù)湖或數(shù)據(jù)倉庫中。數(shù)據(jù)在靜止?fàn)顟B(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ù)。或者，如果使用Spark 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)在靜止?fàn)顟B(tài)下存儲。這些數(shù)據(jù)存儲是為索引、搜索、批處理、報告、模型培訓(xùn)以及存儲系統(tǒng)中有意義的其他使用案例而構(gòu)建的。但是，不能從靜態(tài)存儲中實時處理動態(tài)數(shù)據(jù)。

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

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

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

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

教訓(xùn)3：不需要Lambda架構(gòu)來分離批處理和實時工作負載

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

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

考慮所在的行業(yè)、業(yè)務(wù)單位、解決的問題以及構(gòu)建的創(chuàng)新應(yīng)用程序。實時數(shù)據(jù)勝過慢數(shù)據(jù)。這種說法幾乎總是正確的?；蛘咴黾邮杖耄档统杀荆档惋L(fēng)險，或者改善客戶體驗。

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

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

(2)Kappa架構(gòu)簡化了批處理和實時工作負載的基礎(chǔ)設(shè)施

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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