詳解新一代資料湖--資料平臺

一提到企業資料平臺，人們往往想到的是各種資料目錄結構、資料質量監控、CI/CD、以及資料民主公眾化(Data Democratization，即：提供資料查詢的公共渠道)等方面。它們在滿足使用者的多元化需求與體驗的同時，不斷通過合理的架構、以及高效的分揀手段，來持續提高其自身的質量和使用價值。不過，我們在資料獲取、過濾、以及分析環節，往往會受到因素的限制：

• 團隊成員的知識儲備。

• 在雲服務中的使用效率。

• 與現有業務和產品的整合度。

• 總體處置的成本。

自定義的資料獲取引擎

基於上述考慮，企業在搭建與整合資料平臺時，往往會以開源技術作為平臺的核心，以流式和批處理的方式提供資料服務，並試圖將資料服務層與資料持久化引擎進行解耦。當然，他們也可以一股腦地將這些任務交給諸如：BigQuery、Redshift、以及Snowflake等增值服務提供商、及其特定產品來實現。

資料平臺架構的示例

資料模型(域驅動設計)

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

• 生產者(producers)和消費者(consumers)。其中，消費者域是由來自多個生產者域的資料組合而成。

• 特定的資料可以擁有一個主域和一個輔域。

• 資料域的組織結構並非一成不變，可能會出現更改、合併、演化、以及移除。

在資料域處置方面，我們常用的方法是遵循自底向上的設計原則。這意味著：從生產者的資料域開始，資料產品將被視為自己的消費者進行構建。因此，資料平臺需要為它們提供所有必要的工具、服務、支援、標準化流程、以及整合。

從生產者域到消費者域(資料即產品)

銷售域是消費者資料域的一個極其常見的例子，當然也是非常複雜的。在那些擁有多渠道訂單(如：電子商務、社交媒體、實體店等)的大公司中，渠道和部門之間有關銷售的概念雖然略有不同，但是它往往是由那些來自多個域的資料所組成。

銷售域

例如：由於每個團隊所需要的資料、資料的驗證過程、以及衡量指標有所不同，因此電商部門和財務部門的銷售資料產品就可能不一樣。

資料的獲取模式

眾所周知，資料平臺最具價值的資源便是資料。同時，資料也是最為複雜的。我們通常有兩種上傳資料的方式：

• 拉式(Pull)：核心團隊基於集中式的管理，通過開發資料管道，將資料引入平臺中。不過，由於最初鮮少有與其他團隊的依賴關係，因此該方法比較有效;但是到了後期，則可能陷入瓶頸。

• 推式(Push)：它對於運營、架構和正規化來說是絕好的方法，但不一定適合其他團隊。例如，分銷團隊在分析銷售資料時，需要銷售團隊將他們的資料推送到資料平臺中。而由於銷售團隊業務繁忙，而且這並不是他們的首要任務，因此分銷團隊可能會等待較長的時間。

可見，「推式」方法雖好，但是許多公司往往有著各種遺留下來的系統，以至於團隊無法及時準備好適合推送的資料。而通過提供「拉式」方法，我們則可以開發自動化的資料獲取引擎服務。

什麼是資料獲取引擎服務(Data Ingestion Engine Service)?

總的說來，它是一個無需程式碼，只需各種SQL語句和對映，即可創建ETL流程和資料流程的自助服務平臺。其目標是通過提供多種風格，來涵蓋如下方面：

• 允許團隊自行將資料推送到交換區。

• 提供一個集中式的核心團隊，為非技術團隊上傳資料。

• 通過提供自助服務平臺，來簡化技術團隊的資料獲取過程。

如果我們對所有類型的資料獲取管道，都採取相同的方法，將會擁有一整套自動化的連線器，可方便團隊推送他們的各種資料。例如：變更資料的捕獲，各類事件、映象、以及檔案等。也就是說，通過為產品所有者構建可用於資料推送的通用元件，我們將能夠實現自動化的獲取層。

批處理的資料流

如上圖所示，我們必須提供各種工具和標準化的流程(包括：資料獲取與質量控制等)，以允許生產者將他們的資料，通過Web門戶或GitOps等自動化的方式，推送到資料平臺上。

下面，我們將重點討論如何開發一個獲取引擎。

微服務架構之推送

事件驅動型的微服務架構，是被應用到基於資料流的「推送策略(Push Strategy)」的最佳場景之一。此類架構通常是基於諸如Apache Kafka等永續性的訊息傳遞系統，並遵循的是「釋出-訂閱(publish-subscribe)」的通訊模式。

微服務架構模式

如上圖所示，這種模式提供了一種可擴展的、鬆散耦合的架構，即：

• 釋出者向主題(topic)傳送一條訊息。

• 所有已註冊該主題的訂閱者都會收到此訊息，也就實現了：事件被一次產生，多次消費的效果。

• 由於釋出者和訂閱者之間並無依賴關係，因此他們的操作可以彼此獨立。

我們可以通過提供標準化的獲取連線器，來訂閱此類主題，並將各種事件以近乎實時的方式，獲取到我們的資料平臺。當然，此類架構在資訊範圍方面會存在著如下缺陷：

• 由於永續性主題通常具有基於時間或大小的限制，因此在出現錯誤時，其重新處理的過程較為複雜。

• 不具備重新發送歷史資料的流程。

• 不提供針對各種海量場景的非同步資料質量性API。

資料湖(Data Lake)

在儲存與分析原始資料，以及機器學習環境中，也就產生了資料湖的概念。它是一種基於物件儲存的資料儲存庫，能夠方便我們進行如下儲存：

• 來自關係型資料庫的結構化資料。

• 來自NoSQL或其他來源(如：CSV、XML、JSON等)的半結構化資料。

• 非結構化資料和二進位制資料(如：文件、視訊、影象等)。

目前，雲端儲存服務既能夠為頻繁呼叫的資料提供高效能與低延遲的處理能力，又能夠為非頻繁呼叫的資料提供低成本的大容量儲存空間。因此，我們可以通過選用Azure Data Lake Storage Gen2，來為雲物件的儲存提供如下功能：

• 卷：可以管理海量資料、PB級資訊、以及千兆位(gigabits)的吞吐量。

• 效能：針對各種待分析的用例進行優化。

• 安全性：允許對目錄或單個檔案設定POSIX(可移植作業系統介面，Portable Operating System Interface)許可權。即：使用服務主體和OAuth2.0，將Azure Data Lake Storage Gen2的檔案系統掛載到DBFS(資料庫檔案系統)上。

• 事件：作為一種服務，可以為每個執行操作(如：創建和刪除檔案)自動生成一個事件。通過這些事件，我們可以設計事件驅動的資料流程。

我們需要根據使用者的實際需求和用例做到：

• 提供對於資料的只讀訪問許可權，以便讓資料湖成為所有使用者的資料來源，以及單一的資料儲存庫。

• 結構化資料和半結構化資料能夠通過諸如Delta Lake的儲存庫，以列的格式儲存。

• 讓資料能夠按照業務域進行分區儲存，並分佈在多個物件儲存中。

• 提供Hive的Metastore服務，並通過使用各種外部表提供spark-SQL的訪問。這將允許使用者從資料的物理位置中抽象出來，並擁有資料的單獨映象。

Spark-SQL流經MariaDB

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

Spark-SQL和HiveMetastore

Spark-SQL為我們提供了一個分散式的查詢引擎，以方便我們以更為優化的方式使用結構化與半結構化資料，並使用類似於資料目錄的Hive Metastore。通過SQL，我們可以從如下位置查詢到資料：

• 資料幀和資料集API。

• 外部工具，如Databricks Notebooks便是一個使用者友好的工具。它能夠協助非技術使用者去消費資料。

Spark-SQL和HiveMetastore的流程

資料湖即服務(Data Lake as a Service)

基於上述理論與知識基礎，我們可以設計和構建出具有如下特徵的資料湖平臺：

• 其資料獲取引擎負責獲取資料，創建和管理在Hive Metastore的元資料。

• 其核心是由物件儲存層和Hive Metastore兩個主要元件構成，它們提供了計算層即服務(compute layer as a service)。

• 其中的計算層是由整合到資料湖中的多個Sparks群集組成。它們通過各種Spark作業、SQLAnalytics或Databrick Notebook來訪問資料。

資料湖即服務的架構

資料湖平臺即服務是一種動態且可擴展的計算與服務層能力。其中，作為核心的Spark叢集是資料湖平臺的最小服務目錄。我們既可以創建一個7x24的永久性叢集，又可以創建一個臨時的工作叢集。例如，若想為資料產品團隊提供沙盒分析服務，我們可以為每個成員都創建一個包含有相同資料，但彼此隔離的計算環境。對此，我們需要實現：

• 根據Spark技術，來定義組成沙箱分析的元件。

• 通過Web服務目錄、或程式碼方式(如git-ops)，提供自助式的服務功能。

自助式的服務層

當然，上圖只是一個非常簡單化的檢視，其中並沒有定義安全性、高可用性、以及資料質量的相關服務。

資料湖能夠提供什麼?

如下圖所示，作為一個開源層，資料湖提供了ACID功能，並確保使用者能夠看到一致性的資料。各種資料管道可以被用來重新整理資料，但不會影響正在運行中的Spark過程。

ACID：原子性、一致性、隔離性、永續性

其他重要的功能還包括：

• Schemaon-write：它在寫入資料時強制執行模式檢查，如果檢測到模式不匹配，則返回作業失敗。

• SchemaEvolution：它支援諸如新增新的列等，針對相容性方案的模式進化。

• Time travel：資料版本控制可方便我們將資料作為程式碼進行管理。在程式碼儲存庫中，使用者能夠讓資料集的每次更改，都會在其整個生命週期中生成新的資料版本。

• Merge：支援合併、更新和刪除操作，以實現複雜的資料獲取場景。

資料湖的進化

如下圖所示，傳統的資料湖、資料倉庫、以及資料中心(Hub)之間有著概念性和技術性的區別。

資料湖、資料中心、資料倉庫圖表

Apache Hudi為傳統的、基於Hadoop、Spark、Parquet、Hive等資料湖技術生態，添加了新的實用功能。其中包括：將計算和儲存層進行架構上的解耦、無伺服器化、SQL分析、Delta Engine、以及Databricks等新一代的資料湖平臺。而根據Databricks的理論，Lake House可以被理解為新一代、更為成熟的資料湖。它包含了如下兩個部分：

• 資料中心

資料中心流程圖

• 用於特定或簡化場景的資料倉庫

資料倉庫流程圖

目前，隨著資料倉庫的能力得到了大幅提升，諸如Snowflake、Bigquery、以及Oracle Autonomous Data Warehouse等技術產品，在資料分發等方面都表現出了不俗的效能。

小結

總的說來，結合了Kafka等事件中心的新一代資料湖，是我們構建資料平臺核心的優先選擇。它作為一項成熟的技術，不但開源、持續進化，而且具有極具競爭力的價效比。我們可以將其部署到各種雲端服務環境中，以更好地發掘資料的價值。