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

構建云原生數據倉庫和數據湖的最佳實踐

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

教訓1：在正確的地方處理和存儲數據

首先要問問自己：數據的用例是什么?

以下是一些數據用例示例和實現業務用例的示例工具：

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

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

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

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

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

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

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

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

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

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

現代數據流服務也利用了分級存儲。

第二個教訓：不要為靜止數據進行反向設計

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

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

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

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

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

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

這就是事件流發揮作用的地方。像Apache Kafka這樣的平臺支持實時處理事務和分析工作負載的動態數據。

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

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

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

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

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

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

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

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

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

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

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

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

教訓4：理解靜態數據共享和流數據交換之間的權衡

問問自己：需要如何與其他內部業務單位或外部企業共享數據?

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

跨數據中心、區域或云計算提供商復制數據有很多理由：

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

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

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

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

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

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

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

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

教訓5：數據網格不是單一的產品或技術

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

(1)數據網格是邏輯視圖，而不是物理視圖

數據網格轉變為一種借鑒現代分布式架構的范式：將域視為首要關注點，應用平臺思維創建自助式數據基礎設施，將數據視為產品，并實現開放標準化以實現可互操作的分布式數據產品生態系統。

下面是一個數據網格的例子：

數據網格結合了現有的范式，包括領域驅動設計、數據集市、微服務和事件流。

(2)數據倉庫或數據湖不是也不可能成為整個數據網格

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

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

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

(3)云原生數據倉庫的最佳實踐超越SaaS產品

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

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

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