【51CTO.com快譯】

介紹

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

• 團(tuán)隊的知識。
• 云服務(wù)中的使用效率。 
• 能夠與我們現(xiàn)有的產(chǎn)品集成。
• 運(yùn)行成本。

自定義數(shù)據(jù)域引擎

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

云數(shù)據(jù)平臺架構(gòu)

擁有敏捷的云數(shù)據(jù)平臺，而不限制供應(yīng)商取決于：

• 使用開源技術(shù)作為平臺的核心。這使我們能夠?qū)⑽覀兊钠脚_轉(zhuǎn)移到另一個云提供商。
• 提供數(shù)據(jù)集線器服務(wù)，用于流式和批處理數(shù)據(jù)。
• 自動化數(shù)據(jù)管道允許我們輕松地將數(shù)據(jù)移動到不同的數(shù)據(jù)存儲庫。
• 數(shù)據(jù)服務(wù)層與數(shù)據(jù)持久化引擎解耦。

數(shù)據(jù)模型（域驅(qū)動設(shè)計）

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

關(guān)于數(shù)據(jù)域的一些重要事項如下：
• 數(shù)據(jù)域有兩種視圖，生產(chǎn)者數(shù)據(jù)域和消費(fèi)者數(shù)據(jù)域。通常，這些域是不同的，因為消費(fèi)者的域是來自多個生產(chǎn)者域的數(shù)據(jù)組成的。
• 特定數(shù)據(jù)可以有一個主域和一個輔助域。
• 數(shù)據(jù)域組織不是靜態(tài)的?？梢员桓?、合并、演化或刪除。
在數(shù)據(jù)域方面，常用的方法是遵循自底向上的設(shè)計。這就意味著從生產(chǎn)者數(shù)據(jù)域開始，數(shù)據(jù)產(chǎn)品將被視為自己的消費(fèi)者進(jìn)行構(gòu)建。因此，數(shù)據(jù)平臺需要為他們提供所有必要的工具、服務(wù)、支持、標(biāo)準(zhǔn)化流程和集成。

從生產(chǎn)者到消費(fèi)域

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

銷售域

因為每個團(tuán)隊可能會有不同的數(shù)據(jù)產(chǎn)品，需要不同的數(shù)據(jù)、數(shù)據(jù)驗證過程和指標(biāo)。就好像電商部門和財務(wù)部門的銷售數(shù)據(jù)產(chǎn)品是一樣的嗎？這取決于很多因素。

數(shù)據(jù)攝取模式

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

遵循“推送”方法，在操作、架構(gòu)和范式方面，這是一個很好的決策。這取決于企業(yè)架構(gòu)的實際情況，我們必須提供“Pull”功能，因為在許多公司中，通常有許多遺留系統(tǒng)或團(tuán)隊沒有準(zhǔn)備好推送數(shù)據(jù)。 

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

什么是數(shù)據(jù)攝取引擎服務(wù)？

數(shù)據(jù)攝取引擎服務(wù)是一個自助服務(wù)平臺，只需要SQL語句和映射，無需代碼，允許創(chuàng)建ETL進(jìn)程和流式處理。

其目標(biāo)是通過提供多種風(fēng)格，來涵蓋如下方面：：

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

這里的主要思想是通過構(gòu)建產(chǎn)品所有者將來用于推送數(shù)據(jù)的公共組件，從一個不需要的“拉取策略”轉(zhuǎn)向“Push模型”。從而實現(xiàn)自動攝取層。

批處理數(shù)據(jù)流

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

下面的文章將詳細(xì)介紹如何開發(fā)一個攝取引擎。

微服務(wù)架構(gòu)：Push 

事件驅(qū)動的微服務(wù)體系架構(gòu)是應(yīng)用基于流的“推送策略”的最佳方案之一。這些體系結(jié)構(gòu)遵循發(fā)布-訂閱通信模式，通?；诔志孟鬟f系統(tǒng)，如Apache Kafka。

微服務(wù)架構(gòu)模式

這種模式提供了可擴(kuò)展和松散耦合的架構(gòu)：

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

數(shù)據(jù)湖 

數(shù)據(jù)湖是分析、機(jī)器學(xué)習(xí)環(huán)境和存儲原始數(shù)據(jù)的自然選擇。數(shù)據(jù)湖是一個數(shù)據(jù)存儲庫，通?；趯ο蟠鎯?，它允許我們存儲的內(nèi)容如下：

• 關(guān)系數(shù)據(jù)庫中的結(jié)構(gòu)化數(shù)據(jù)。
• 來自 NoSQL 或其他來源（CSV、XML、JSON）的半結(jié)構(gòu)化數(shù)據(jù)。
• 非結(jié)構(gòu)化數(shù)據(jù)和二進(jìn)制數(shù)據(jù)（文檔、視頻、圖像）。
• 目前，云存儲服務(wù)已經(jīng)有了很大改進(jìn)，并提供了不同的服務(wù)質(zhì)量，使我們能夠：

• 為熱數(shù)據(jù)提供高性能和低延遲。

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

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

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

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

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

MariaDB

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

Spark-SQL 和 Hive Metastore

Spark SQL 為我們提供了一個分布式查詢引擎，以更優(yōu)化的方式使用結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)，并使用類似于數(shù)據(jù)目錄的 Hive Metastore。使用 SQL，我們可以從以下位置查詢數(shù)據(jù)：

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

Hive Metastore

數(shù)據(jù)湖即服務(wù)

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

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

數(shù)據(jù)湖即服務(wù)

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

例如，我們想為我們的數(shù)據(jù)產(chǎn)品團(tuán)隊提供沙盒分析服務(wù)。我們將為每個人創(chuàng)建一個獨立的計算環(huán)境，但所有人都將訪問相同的數(shù)據(jù)。要將這些功能作為服務(wù)提供，我們需要：

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

自助服務(wù)組件

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

Delta Lake提供什么？

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

數(shù)據(jù)管道

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

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

數(shù)據(jù)湖的演變

幾年前，傳統(tǒng)數(shù)據(jù)湖、數(shù)據(jù)倉庫和數(shù)據(jù)中心之間的區(qū)別是概念性的，也是技術(shù)性的。

三者區(qū)別

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

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

• 數(shù)據(jù)中心。

數(shù)據(jù)中心

• 數(shù)據(jù)倉庫的細(xì)節(jié)和減少梗概。

數(shù)據(jù)倉庫

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

結(jié)論

 

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

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