【51CTO.com快譯】一提到企業(yè)數(shù)據(jù)平臺，人們往往想到的是各種數(shù)據(jù)目錄結(jié)構(gòu)、數(shù)據(jù)質(zhì)量監(jiān)控、CI/CD、以及數(shù)據(jù)民主公眾化(Data Democratization，即：提供數(shù)據(jù)查詢的公共渠道)等方面。它們在滿足用戶的多元化需求與體驗(yàn)的同時(shí)，不斷通過合理的架構(gòu)、以及高效的分揀手段，來持續(xù)提高其自身的質(zhì)量和使用價(jià)值。不過，我們在數(shù)據(jù)獲取、過濾、以及分析環(huán)節(jié)，往往會受到因素的限制：

• 團(tuán)隊(duì)成員的知識儲備。
• 在云服務(wù)中的使用效率。
• 與現(xiàn)有業(yè)務(wù)和產(chǎn)品的集成度。
• 總體處置的成本。

自定義的數(shù)據(jù)獲取引擎

基于上述考慮，企業(yè)在搭建與集成數(shù)據(jù)平臺時(shí)，往往會以開源技術(shù)作為平臺的核心，以流式和批處理的方式提供數(shù)據(jù)服務(wù)，并試圖將數(shù)據(jù)服務(wù)層與數(shù)據(jù)持久化引擎進(jìn)行解耦。當(dāng)然，他們也可以一股腦地將這些任務(wù)交給諸如：BigQuery、Redshift、以及Snowflake等增值服務(wù)提供商、及其特定產(chǎn)品來實(shí)現(xiàn)。

數(shù)據(jù)平臺架構(gòu)的示例

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

說到數(shù)據(jù)平臺，它往往需要全局性的數(shù)據(jù)模型定義。目前，許多企業(yè)、特別是一些技術(shù)類型的公司，都會采用域驅(qū)動設(shè)計(jì)(Domain Driven Design，DDD)的方法。該方法通常會涉及到如下方面：

• 生產(chǎn)者(producers)和消費(fèi)者(consumers)。其中，消費(fèi)者域是由來自多個(gè)生產(chǎn)者域的數(shù)據(jù)組合而成。
• 特定的數(shù)據(jù)可以擁有一個(gè)主域和一個(gè)輔域。
• 數(shù)據(jù)域的組織結(jié)構(gòu)并非一成不變，可能會出現(xiàn)更改、合并、演化、以及移除。

在數(shù)據(jù)域處置方面，我們常用的方法是遵循自底向上的設(shè)計(jì)原則。這意味著：從生產(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)者域(數(shù)據(jù)即產(chǎn)品)

銷售域是消費(fèi)者數(shù)據(jù)域的一個(gè)極其常見的例子，當(dāng)然也是非常復(fù)雜的。在那些擁有多渠道訂單(如：電子商務(wù)、社交媒體、實(shí)體店等)的大公司中，渠道和部門之間有關(guān)銷售的概念雖然略有不同，但是它往往是由那些來自多個(gè)域的數(shù)據(jù)所組成。

銷售域

例如：由于每個(gè)團(tuán)隊(duì)所需要的數(shù)據(jù)、數(shù)據(jù)的驗(yàn)證過程、以及衡量指標(biāo)有所不同，因此電商部門和財(cái)務(wù)部門的銷售數(shù)據(jù)產(chǎn)品就可能不一樣。如果您對該專題感興趣的話，請參閱有關(guān)Data Mesh范例的文章。

數(shù)據(jù)的獲取模式

眾所周知，數(shù)據(jù)平臺最具價(jià)值的資源便是數(shù)據(jù)。同時(shí)，數(shù)據(jù)也是最為復(fù)雜的。我們通常有兩種上傳數(shù)據(jù)的方式：

• 拉式(Pull)：核心團(tuán)隊(duì)基于集中式的管理，通過開發(fā)數(shù)據(jù)管道，將數(shù)據(jù)引入平臺中。不過，由于最初鮮少有與其他團(tuán)隊(duì)的依賴關(guān)系，因此該方法比較有效;但是到了后期，則可能陷入瓶頸。
• 推式(Push)：它對于運(yùn)營、架構(gòu)和范式來說是絕好的方法，但不一定適合其他團(tuán)隊(duì)。例如，分銷團(tuán)隊(duì)在分析銷售數(shù)據(jù)時(shí)，需要銷售團(tuán)隊(duì)將他們的數(shù)據(jù)推送到數(shù)據(jù)平臺中。而由于銷售團(tuán)隊(duì)業(yè)務(wù)繁忙，而且這并不是他們的首要任務(wù)，因此分銷團(tuán)隊(duì)可能會等待較長的時(shí)間。

可見，“推式”方法雖好，但是許多公司往往有著各種遺留下來的系統(tǒng)，以至于團(tuán)隊(duì)無法及時(shí)準(zhǔn)備好適合推送的數(shù)據(jù)。而通過提供“拉式”方法，我們則可以開發(fā)自動化的數(shù)據(jù)獲取引擎服務(wù)。

什么是數(shù)據(jù)獲取引擎服務(wù)(Data Ingestion Engine Service)?

總的說來，它是一個(gè)無需代碼，只需各種SQL語句和映射，即可創(chuàng)建ETL流程和數(shù)據(jù)流程的自助服務(wù)平臺。其目標(biāo)是通過提供多種風(fēng)格，來涵蓋如下方面：

• 允許團(tuán)隊(duì)自行將數(shù)據(jù)推送到交換區(qū)。
• 提供一個(gè)集中式的核心團(tuán)隊(duì)，為非技術(shù)團(tuán)隊(duì)上傳數(shù)據(jù)。
• 通過提供自助服務(wù)平臺，來簡化技術(shù)團(tuán)隊(duì)的數(shù)據(jù)獲取過程。

如果我們對所有類型的數(shù)據(jù)獲取管道，都采取相同的方法，將會擁有一整套自動化的連接器，可方便團(tuán)隊(duì)推送他們的各種數(shù)據(jù)。例如：變更數(shù)據(jù)的捕獲，各類事件、鏡像、以及文件等。也就是說，通過為產(chǎn)品所有者構(gòu)建可用于數(shù)據(jù)推送的通用組件，我們將能夠?qū)崿F(xiàn)自動化的獲取層。

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

如上圖所示，我們必須提供各種工具和標(biāo)準(zhǔn)化的流程(包括：數(shù)據(jù)獲取與質(zhì)量控制等)，以允許生產(chǎn)者將他們的數(shù)據(jù)，通過Web門戶或GitOps等自動化的方式，推送到數(shù)據(jù)平臺上。

下面，我們將重點(diǎn)討論如何開發(fā)一個(gè)獲取引擎。

微服務(wù)架構(gòu)之推送

事件驅(qū)動型的微服務(wù)架構(gòu)，是被應(yīng)用到基于數(shù)據(jù)流的“推送策略(Push Strategy)”的最佳場景之一。此類架構(gòu)通常是基于諸如Apache Kafka等持久性的消息傳遞系統(tǒng)，并遵循的是“發(fā)布-訂閱(publish-subscribe)”的通信模式。

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

如上圖所示，這種模式提供了一種可擴(kuò)展的、松散耦合的架構(gòu)，即：

• 發(fā)布者向主題(topic)發(fā)送一條消息。
• 所有已注冊該主題的訂閱者都會收到此消息，也就實(shí)現(xiàn)了：事件被一次產(chǎn)生，多次消費(fèi)的效果。
• 由于發(fā)布者和訂閱者之間并無依賴關(guān)系，因此他們的操作​​可以彼此獨(dú)立。

我們可以通過提供標(biāo)準(zhǔn)化的獲取連接器，來訂閱此類主題，并將各種事件以近乎實(shí)時(shí)的方式，獲取到我們的數(shù)據(jù)平臺。當(dāng)然，此類架構(gòu)在信息范圍方面會存在著如下缺陷：

• 由于持久性主題通常具有基于時(shí)間或大小的限制，因此在出現(xiàn)錯(cuò)誤時(shí)，其重新處理的過程較為復(fù)雜。
• 不具備重新發(fā)送歷史數(shù)據(jù)的流程。
• 不提供針對各種海量場景的異步數(shù)據(jù)質(zhì)量性API。

數(shù)據(jù)湖(Data Lake)

在存儲與分析原始數(shù)據(jù)，以及機(jī)器學(xué)習(xí)環(huán)境中，也就產(chǎn)生了數(shù)據(jù)湖的概念。它是一種基于對象存儲的數(shù)據(jù)存儲庫，能夠方便我們進(jìn)行如下存儲：

• 來自關(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ù)既能夠?yàn)轭l繁調(diào)用的數(shù)據(jù)提供高性能與低延遲的處理能力，又能夠?yàn)榉穷l繁調(diào)用的數(shù)據(jù)提供低成本的大容量存儲空間。因此，我們可以通過選用Azure Data Lake Storage Gen2，來為云對象的存儲提供如下功能：

• 卷：可以管理海量數(shù)據(jù)、PB級信息、以及千兆位(gigabits)的吞吐量。
• 性能：針對各種待分析的用例進(jìn)行優(yōu)化。
• 安全性：允許對目錄或單個(gè)文件設(shè)置POSIX(可移植操作系統(tǒng)接口，Portable Operating System Interface)權(quán)限。即：使用服務(wù)主體和OAuth2.0，將Azure Data Lake Storage Gen2的文件系統(tǒng)掛載到DBFS(數(shù)據(jù)庫文件系統(tǒng))上。
• 事件：作為一種服務(wù)，可以為每個(gè)執(zhí)行操作(如：創(chuàng)建和刪除文件)自動生成一個(gè)事件。通過這些事件，我們可以設(shè)計(jì)事件驅(qū)動的數(shù)據(jù)流程。

我們需要根據(jù)用戶的實(shí)際需求和用例做到：

• 提供對于數(shù)據(jù)的只讀訪問權(quán)限，以便讓數(shù)據(jù)湖成為所有用戶的數(shù)據(jù)來源，以及單一的數(shù)據(jù)存儲庫。
• 結(jié)構(gòu)化數(shù)據(jù)和半結(jié)構(gòu)化數(shù)據(jù)能夠通過諸如Delta Lake的存儲庫，以列的格式存儲。
• 讓數(shù)據(jù)能夠按照業(yè)務(wù)域進(jìn)行分區(qū)存儲，并分布在多個(gè)對象存儲中。
• 提供Hive的Metastore服務(wù)，并通過使用各種外部表提供spark-SQL的訪問。這將允許用戶從數(shù)據(jù)的物理位置中抽象出來，并擁有數(shù)據(jù)的單獨(dú)鏡像。

Spark-SQL流經(jīng)MariaDB

如上圖所示，我們可以使用外部開源版本的Hive Metastore，而非具有集成限制的供應(yīng)商管理服務(wù)，來自由地集成任何Spark平臺環(huán)境(如：Databricks、Cloudera等)。

Spark-SQL和HiveMetastore

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

• 數(shù)據(jù)幀和數(shù)據(jù)集API。
• 外部工具，如Databricks Notebooks便是一個(gè)用戶友好的工具。它能夠協(xié)助非技術(shù)用戶去消費(fèi)數(shù)據(jù)。

Spark-SQL和HiveMetastore的流程

數(shù)據(jù)湖即服務(wù)(Data Lake as a Service)

基于上述理論與知識基礎(chǔ)，我們可以設(shè)計(jì)和構(gòu)建出具有如下特征的數(shù)據(jù)湖平臺：

• 其數(shù)據(jù)獲取引擎負(fù)責(zé)獲取數(shù)據(jù)，創(chuàng)建和管理在Hive Metastore的元數(shù)據(jù)。
• 其核心是由對象存儲層和Hive Metastore兩個(gè)主要組件構(gòu)成，它們提供了計(jì)算層即服務(wù)(compute layer as a service)。
• 其中的計(jì)算層是由集成到數(shù)據(jù)湖中的多個(gè)Sparks群集組成。它們通過各種Spark作業(yè)、SQLAnalytics或Databrick Notebook來訪問數(shù)據(jù)。

數(shù)據(jù)湖即服務(wù)的架構(gòu)

數(shù)據(jù)湖平臺即服務(wù)是一種動態(tài)且可擴(kuò)展的計(jì)算與服務(wù)層能力。其中，作為核心的Spark集群是數(shù)據(jù)湖平臺的最小服務(wù)目錄。我們既可以創(chuàng)建一個(gè)7x24的永久性集群，又可以創(chuàng)建一個(gè)臨時(shí)的工作集群。例如，若想為數(shù)據(jù)產(chǎn)品團(tuán)隊(duì)提供沙盒分析服務(wù)，我們可以為每個(gè)成員都創(chuàng)建一個(gè)包含有相同數(shù)據(jù)，但彼此隔離的計(jì)算環(huán)境。對此，我們需要實(shí)現(xiàn)：

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

自助式的服務(wù)層

當(dāng)然，上圖只是一個(gè)非常簡單化的視圖，其中并沒有定義安全性、高可用性、以及數(shù)據(jù)質(zhì)量的相關(guān)服務(wù)。

數(shù)據(jù)湖能夠提供什么?

如下圖所示，作為一個(gè)開源層，數(shù)據(jù)湖提供了ACID功能，并確保用戶能夠看到一致性的數(shù)據(jù)。各種數(shù)據(jù)管道可以被用來刷新數(shù)據(jù)，但不會影響正在運(yùn)行中的Spark過程。

ACID：原子性、一致性、隔離性、持久性

其他重要的功能還包括：

• Schemaon-write：它在寫入數(shù)據(jù)時(shí)強(qiáng)制執(zhí)行模式檢查，如果檢測到模式不匹配，則返回作業(yè)失敗。
• SchemaEvolution：它支持諸如添加新的列等，針對兼容性方案的模式進(jìn)化。
• Time travel：數(shù)據(jù)版本控制可方便我們將數(shù)據(jù)作為代碼進(jìn)行管理。在代碼存儲庫中，用戶能夠讓數(shù)據(jù)集的每次更改，都會在其整個(gè)生命周期中生成新的數(shù)據(jù)版本。
• Merge：支持合并、更新和刪除操作，以實(shí)現(xiàn)復(fù)雜的數(shù)據(jù)獲取場景。

數(shù)據(jù)湖的進(jìn)化

如下圖所示，傳統(tǒng)的數(shù)據(jù)湖、數(shù)據(jù)倉庫、以及數(shù)據(jù)中心(Hub)之間有著概念性和技術(shù)性的區(qū)別。

數(shù)據(jù)湖、數(shù)據(jù)中心、數(shù)據(jù)倉庫圖表

Apache Hudi為傳統(tǒng)的、基于Hadoop、Spark、Parquet、Hive等數(shù)據(jù)湖技術(shù)生態(tài)，添加了新的實(shí)用功能。其中包括：將計(jì)算和存儲層進(jìn)行架構(gòu)上的解耦、無服務(wù)器化、SQL分析、Delta Engine、以及Databricks等新一代的數(shù)據(jù)湖平臺。而根據(jù)Databricks的理論，Lake House可以被理解為新一代、更為成熟的數(shù)據(jù)湖。它包含了如下兩個(gè)部分：

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

數(shù)據(jù)中心流程圖

• 用于特定或簡化場景的數(shù)據(jù)倉庫

數(shù)據(jù)倉庫流程圖

目前，隨著數(shù)據(jù)倉庫的能力得到了大幅提升，諸如Snowflake、Bigquery、以及Oracle Autonomous Data Warehouse等技術(shù)產(chǎn)品，在數(shù)據(jù)分發(fā)等方面都表現(xiàn)出了不俗的性能。

小結(jié)

總的說來，結(jié)合了Kafka等事件中心的新一代數(shù)據(jù)湖，是我們構(gòu)建數(shù)據(jù)平臺核心的優(yōu)先選擇。它作為一項(xiàng)成熟的技術(shù)，不但開源、持續(xù)進(jìn)化，而且具有極具競爭力的性價(jià)比。我們可以將其部署到各種云端服務(wù)環(huán)境中，以更好地發(fā)掘數(shù)據(jù)的價(jià)值。

原文標(biāo)題：Data Platform: The New Generation Data Lakes，作者：Miguel Garcia和Albert Palau

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