【51CTO.com快譯】

介紹

本文是對數據平臺即服務（Data Platform- as- a- Service,）的后續研究，描述了其高層體系結構，并對數據湖進行了詳細介紹。架構的重要之處不在于供應商或特定產品，而在于我們使用的組件的功能。最終，產品的選擇取決于許多因素：

• 團隊的知識。
• 云服務中的使用效率。 
• 能夠與我們現有的產品集成。
• 運行成本。

自定義數據域引擎

在本例中，我們設計了一個主要基于 Azure 服務的解決方案。同時，設計了一個架構，允許以敏捷的方式集成或者遷移到其他云服務上。

云數據平臺架構

擁有敏捷的云數據平臺，而不限制供應商取決于：

• 使用開源技術作為平臺的核心。這使我們能夠將我們的平臺轉移到另一個云提供商。
• 提供數據集線器服務，用于流式和批處理數據。
• 自動化數據管道允許我們輕松地將數據移動到不同的數據存儲庫。
• 數據服務層與數據持久化引擎解耦。

數據模型（域驅動設計）

數據平臺需要全局數據模型定義。目前，許多企業、特別是一些技術類型的公司，都會采用域驅動設計(Domain Driven Design，DDD)的方法。

關于數據域的一些重要事項如下：
• 數據域有兩種視圖，生產者數據域和消費者數據域。通常，這些域是不同的，因為消費者的域是來自多個生產者域的數據組成的。
• 特定數據可以有一個主域和一個輔助域。
• 數據域組織不是靜態的。可以被更改、合并、演化或刪除。
在數據域方面，常用的方法是遵循自底向上的設計。這就意味著從生產者數據域開始，數據產品將被視為自己的消費者進行構建。因此，數據平臺需要為他們提供所有必要的工具、服務、支持、標準化流程和集成。

從生產者到消費域

銷售域是消費者數據域的一個非常常見的用例，并且非常復雜。什么是銷售？在一家擁有多渠道訂單（電子商務、社交媒體、實體店...）的大公司里，渠道和部門之間的銷售概念略有不同。但是他們是由那些來自多個域的數據所組成的。

銷售域

因為每個團隊可能會有不同的數據產品，需要不同的數據、數據驗證過程和指標。就好像電商部門和財務部門的銷售數據產品是一樣的嗎？這取決于很多因素。

數據攝取模式

眾所周知，一個新的數據平臺最寶貴的資源就是數據，上傳數據有兩種方法：
• Pull : 基于核心團隊和集中管理，開發數據管道，將數據攝取到平臺中。
• Push：在操作、架構和范式方面，這是最好的方法，但它取決于其他團隊。例如，分銷團隊需要分析銷售數據。擁有銷售數據需要銷售團隊將數據推送到數據平臺。

遵循“推送”方法，在操作、架構和范式方面，這是一個很好的決策。這取決于企業架構的實際情況，我們必須提供“Pull”功能，因為在許多公司中，通常有許多遺留系統或團隊沒有準備好推送數據。 

在我們看來，提供“Pull”服務的最佳方式是開發一個自動化數據攝取引擎服務。

什么是數據攝取引擎服務？

數據攝取引擎服務是一個自助服務平臺，只需要SQL語句和映射，無需代碼，允許創建ETL進程和流式處理。

其目標是通過提供多種風格，來涵蓋如下方面：：

• 允許團隊自行將數據推送到交換區。
• 提供一個核心和集中的團隊，為非技術團隊上傳數據。
• 提供一個自助服務平臺，簡化技術團隊的數據攝取。
如果我們對所有類型的數據攝取管道采用相同的方法，將會擁有一整套自動化的連接器，可方便團隊推送他們的各種數據。例如：
• 更改數據捕獲。
• 事件。
• 圖像、文件等...

這里的主要思想是通過構建產品所有者將來用于推送數據的公共組件，從一個不需要的“拉取策略”轉向“Push模型”。從而實現自動攝取層。

批處理數據流

如圖所示，我們必須提供所有的工具和標準流程（攝取、數據質量等），以允許生產商將其數據自動推送到數據平臺。這種自助服務可以是 Web 門戶或 GitOps 解決方案。

下面的文章將詳細介紹如何開發一個攝取引擎。

微服務架構：Push 

事件驅動的微服務體系架構是應用基于流的“推送策略”的最佳方案之一。這些體系結構遵循發布-訂閱通信模式，通常基于持久消息傳遞系統，如Apache Kafka。

微服務架構模式

這種模式提供了可擴展和松散耦合的架構：

• 發布者向主題發送一條消息。
• 所有注冊此主題的訂閱者都會收到此消息。事件一次生成，多次消耗。
• 發布者和訂閱者操作可以相互獨立地操作。它們之間沒有依賴關系。
我們可以提供一個標準的接受連接器來訂閱這些主題，并將事件以實時的方式攝取數據平臺。這些架構在信息范圍方面存在挑戰，通常不會涵蓋：
• 這些持久主題通常具有基于時間或大小的限制。在出現錯誤場景的情況下，重新處理更為復雜。
• 重新發送歷史數據的過程。
• 用于大規模場景的異步數據質量API。

數據湖 

數據湖是分析、機器學習環境和存儲原始數據的自然選擇。數據湖是一個數據存儲庫，通常基于對象存儲，它允許我們存儲的內容如下：

• 關系數據庫中的結構化數據。
• 來自 NoSQL 或其他來源（CSV、XML、JSON）的半結構化數據。
• 非結構化數據和二進制數據（文檔、視頻、圖像）。
• 目前，云存儲服務已經有了很大改進，并提供了不同的服務質量，使我們能夠：

• 為熱數據提供高性能和低延遲。

• 以較低的成本擁有較大的存儲容量和較高的延遲，用于冷數據和熱數據。

作為云對象存儲，我們選擇了Azure Data Lake Storage Gen2。此對象存儲提供了一些有趣的特性：

• 體積：它可以管理大量的數據、PB 級的信息和千兆位的吞吐量。
• 性能：針對分析用例進行優化。
• 安全性：它允許POSIX對目錄或單個文件的權限。使用服務主體和 OAuth 2.0 將 Azure Data Lake Storage Gen2 文件系統裝載到 DBFS
• 事件：它提供了一種服務，可以為每個執行的操作自動生成一個事件，例如創建和刪除文件。這些事件允許設計事件驅動的數據流程。

我們必須根據用戶和用例做出幾個決定：

• 提供對數據的只讀訪問。為所有用戶提供單一的數據存儲庫。 
• 結構化數據和半結構化數據以列格式存儲。
• 數據按業務數據域分區存儲，并分布在多個對象存儲中。
• 提供一個Hive Metastore 服務，通過使用外部表提供spark-SQL訪問。這允許擁有數據的單個圖像，并將用戶從數據的物理位置中抽象出來。

MariaDB

現在，我們可以使用由我們管理的外部配置單元元存儲（hivemetastore），這是一個開源版本，而不是帶有集成限制的供應商管理的服務。這使我們可以自由地集成任何 Spark 環境，而不管是誰提供了 Spark 平臺環境（Databricks、Cloudera 等）。

Spark-SQL 和 Hive Metastore

Spark SQL 為我們提供了一個分布式查詢引擎，以更優化的方式使用結構化和半結構化數據，并使用類似于數據目錄的 Hive Metastore。使用 SQL，我們可以從以下位置查詢數據：

• 數據幀和數據集 API。 
• 外部工具，如Databricks Notebooks。這是一個用戶友好的工具，方便非技術用戶使用數據。

Hive Metastore

數據湖即服務

如果我們把到目前為止描述的所有部分放在一起，就可以設計和構建一個數據湖平臺：

• 數據攝取引擎 負責攝取數據，在配置單元元存儲中創建和管理元數據。
• 數據湖的核心由對象存儲層和 Hive Metastore 組成。這是允許我們將計算層作為服務提供的兩個主要組件。
• 計算層由 集成到數據湖中的幾個sparks集群組成。這些集群允許使用 spark 作業、SQL 分析或 Databrick Notebooks 訪問這些數據。

數據湖即服務

在我們看來，提供這種動態且可擴展的計算/服務層的能力使我們能夠將數據湖平臺作為服務提供，否則我們將擁有與傳統本地數據湖更相似的東西。我們可以創建一個 24x7 的永久集群，也可以創建臨時集群來運行我們的工作。Spark 集群是計算和服務層的核心。它是我們將在 數據湖平臺中提供的服務目錄的最小公約數。

例如，我們想為我們的數據產品團隊提供沙盒分析服務。我們將為每個人創建一個獨立的計算環境，但所有人都將訪問相同的數據。要將這些功能作為服務提供，我們需要：

• 基于 Spark 技術定義組成沙箱分析的組件。
• 通過 Web 服務目錄或代碼方式 (git-ops) 提供自助服務功能。

自助服務組件

這是一個非常簡化的視圖，因為我們沒有定義安全性、高可用性或數據質量服務。 

Delta Lake提供什么？

Delta Lake是一個開源層，提供了ACID功能，并確保讀者永遠不會看到不一致的數據。數據管道可以在不影響正在運行的 spark 進程的情況下刷新數據。

數據管道

還有其他重要的功能，例如：

• Schema on-write：它在寫入數據時強制執行模式檢查，當檢測到模式不匹配時，作業失敗。
• Schema Evolution：它支持兼容的方案演變的模式，例如添加新列。
• Time travel：數據版本控制是機器學習用例中的一個重要功能。允許以代碼形式管理數據。作為代碼存儲庫，用戶擁有數據的版本控制，對于數據集的每一次更改，都會在其整個生命周期中生成數據的新版本。
• Merge：支持合并、更新和刪除操作，以實現復雜的攝取方案。

數據湖的演變

幾年前，傳統數據湖、數據倉庫和數據中心之間的區別是概念性的，也是技術性的。

三者區別

基于 Hadoop、Spark、Parquet、Hive 等的數據湖技術有很多局限性。目前，Delta Lake和ApacheHudi等其他選項為數據湖生態系統添加了新的功能。這些特性與解偶聯架構（計算和存儲層）、無服務器以及其他新功能，（如SQL分析或來自數據庫的Delta引擎）結合，正在開發新一代的數據湖平臺。

Databricks 將這一新一代命名為Lake House。在我們看來，現在新一代的成熟度允許數據湖提供兩個新角色：

• 數據中心。

數據中心

• 數據倉庫的細節和減少梗概。

數據倉庫

數據倉庫的功能有了很大的提高，但此時，它仍然需要高水平的技術知識來分發數據，并實現與其他產品（如Snowflake、Big query或Oracle Autonomous data Warehouse）相同的性能。

結論

 

結合Kafka等事件中心，新一代數據湖是成為我們數據平臺核心的好選擇。 它是一項成熟的技術，主要基于開源，在性價比上非常有競爭力，在不斷演進，我們可以在所有云供應商中提供。

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】