大資料資產管理架構設計篇-來自《資料資產管理核心技術與應用》一書的權威講解

张永清發表於2024-10-11

資料資產管理是一項系統而複雜的工程,涉及到後設資料、資料血緣、資料質量、資料服務、資料監控、資料安全、資料許可權等眾多方面,為了更高效的管理好資料資產,因此在很多大型的企業或者組織中,通常會構建一個資料資產管理平臺來管理這些各種各樣的資料資產,資料資產管理平臺通常會包含如下功能: 關注清哥聊技術公眾號,獲取更多權威技術文章。

  • 後設資料:主要負責後設資料的維護和檢視,讓後設資料成為資料資產的一個“電子目錄”,方便外部使用者檢視和檢索其需要的資料是儲存在哪個資料庫以及哪個表的哪個欄位中,也方便外部使用者知道資料資產中每個資料庫、表、欄位的具體含義。
  • 資料血緣:主要負責資料與資料之間的血緣關係跟蹤,以方便使用者在使用資料時,能快速知道資料的處理過程以及來龍去脈。
  • 資料質量:主要負責資料質量的監控與告警,當資料質量出現問題時,能夠快速讓相關的人員知道,資料質量的監控是持續提高資料質量的關鍵所在,也是資料資產持續最佳化、改進、提高質量的關鍵。
  • 資料服務:主要負責資料服務的管理,包括服務的建立、開發、釋出上線以及被業務請求呼叫。資料服務是資料對外使用和產生價值的最常見方式之一,所以資料服務的管理與維護至關重要。
  • 資料監控:主要負責資料鏈路、資料任務、資料處理資源、資料處理結果等的監控與告警,當資料出現問題時,能夠透過監控與告警,讓資料問題得到及時快速的解決。
  • 資料安全:主要負責資料安全的管理,資料安全是資料資產管理中最重要的環節,也是資料資產管理的基礎。透過評估資料的安全風險、制定資料安全管理的規章制度、對資料進行安全級別的分類,完善資料安全管理相關規範文件,保證資料是被合法合規、安全地獲取、處理、儲存以及使用
  • 資料許可權:主要負責資料許可權的分配與管理,透過資料許可權的控制,能夠更好的去保護資料資產中的隱私資訊和敏感資訊。

資料資產管理架構在設計時,通常需要考慮和解決如下問題:

  • 資料冗餘:一般指的是由於資料沒有進行統一的管理,導致很多不同的平臺或者系統都儲存了相同的資料,特別是對於一些很多業務或者系統都需要共用的資料。
  • 資料孤島和資料分散:由於資料沒有進行統一的集中式管理,所以資料很容易分散在不同的系統中並且容易產生資料孤島。
  • 資料口徑無法統一:每個業務系統都有自己的資料管理和分析,導致資料計算的口徑會存在不一致,這樣的話,就導致在做資料決策時,不知道到底以那一份資料口徑為準。

1、資料資產的架構設計

資料資產架構是指為了讓資料資產管理更加資訊化、高效化、平臺化而構建的一套系統架構。通常來說資料資產架構會包含如下的一些方面:

1.1、資料獲取層

資料獲取層通常又叫資料採集層,主要負責從各種不同的資料來源中去獲取資料,如下圖

資料獲取層在獲取資料時會存在多種不同型別的資料來源,從每一種型別的資料來源中獲取資料的方式是不一樣的,所以在資料獲取層的架構設計中,需要考慮相容多種不同資料來源,並且在出現新的型別的資料來源時,需要能夠支援花最小的程式碼改造代價去做擴充套件。所以通常建議資料資產架構設計中資料獲取層的架構可以設計成即插即用的外掛型別,如下圖所示,這種設計方式可以很好的解決資料來源的可擴充套件性的問題。

從圖中可以看到

  • 設計了一個抽象型別的外掛,這個外掛中包含了從資料來源中獲取資料時需要的三個基本的步驟,也是需要實現的三個通用的底層方法。
  • 資料資產管理平臺的資料獲取層在載入完實現好的外掛後,便可以去按照步驟順序去呼叫已經實現好的三個通用的方法來獲取資料。

1.2、資料處理層

資料處理層主要負責將從不同資料來源中獲取到的資料做處理,是整個資料資產架構的核心部分,資料處理的方式通常包含實時和離線兩種方式,通常情況下資料處理層需要完成的主要功能如下圖所示。

  • 資料脫敏:對原始資料中的敏感資訊進行脫敏操作,防止隱私資料被洩露。
  • 資料清洗:去除原始資料中的無效資料、重複資料等,以提供資料處理的質量。
  • 資料整合:將同時來自於多個不同的資料來源的資料進行整合形成統一的資料集。
  • 資料轉換:對原始資料進行轉換(比如進行統一的格式轉換、型別轉換等),以滿足資料倉儲或者資料湖的儲存設計。
  • 資料加密:對一些隱私資料進行加密,方便資料儲存後確保資料的安全性,對隱私資料進行保護。
  • 資料壓縮:為了節約儲存成本,在資料儲存前,對資料進行壓縮處理,在不丟失資料的前提下,減小資料的儲存大小。

在大資料處理中,最常用的架構方式就是Lambda架構和Kappa架構,如下所示

  • Lambda架構:是一套強調將離線和實時任務分開處理的大資料處理架構,如下圖所示

從圖中可以看到Lambda架構是將離線處理和實時處理分開進行維護的,這就意味著需要開發和維護兩套不同的資料處理程式碼,系統的複雜度很高,管理和維護的成本也很高。

  • Kappa架構:是一套將離線和實時資料處理整合在一起的大資料處理架構,如下圖所示

Kappa架構其實可以看成是Lambda架構的最佳化和改進,在Kappa架構中實時任務需要承擔全部資料的處理,會讓實時任務處理的壓力較大,但是Kappa架構將實時程式碼和離線程式碼進行了統一,方便了程式碼進行管理和維護也讓資料的口徑保持了統一,同時也降低了維護兩套程式碼的工作量。

相比於Lambda架構,Kappa架構最大的問題在於一旦需要對歷史資料進行重新處理,那麼Kappa架構將難以實現,因為Kappa架構通常所使用的都是實時流處理的技術元件,比如像Flink等,但是如果做歷史資料處理時,可能像Flink這樣的技術元件就難以勝任,而擅長做離線資料處理的類似Spark這樣的技術元件會更加適合,但是Flink的程式碼和Spark的程式碼通常是無法做共用的。

從對Lambda架構和Kappa架構的對比分析來看,兩者各有優點,也有缺點,在實際應用當中,可能還需要同時結合這兩種架構的優缺點來設計最符合自身業務和需求的資料處理架構。通常建議如下:

  • Lambda架構和Kappa架構 可以同時存在,對於經常有需要做歷史資料處理的資料型別,建議保留為Lambda架構。
  • 對於幾乎不需要做歷史資料處理的資料型別,建議儘可能走Kappa架構來實現。

1.3、資料儲存層

資料儲存層主要負責各種型別的資料的儲存,在架構設計時,還需要綜合考慮如下問題來制定資料儲存的架構和策略。

  • 資料查詢的效能:比如查詢的響應時間、資料訪問的吞吐量、查詢的TPS等。
  • 資料的冷熱程度:根據資料的冷熱程度,對資料進行劃分,對於冷熱程度不一樣的資料,可以分開儲存,通常對於冷資料,可以採用一些成本更低的儲存介質來進行儲存,方便節省資料儲存的成本。

資料儲存的技術方案可以有很多選型,如下所示,通常需要根據實際的業務需要來進行綜合的選擇。

  • 傳統資料倉儲儲存:傳統的資料倉儲的代表就是Hive,可以負責海量資料的儲存和基於Hive做資料分析和挖掘,但是Hive 數倉存在以下不足
  • 通常只能儲存結構化的資料或者經過處理後生成的結構化資料。
  • Hive數倉中更新資料的能力較弱,一般只能做資料的批次插入。
    • 資料湖儲存:資料湖是在傳統數倉上發展而來的,也是可以完成海量資料的儲存,相比於資料倉儲,資料湖具有如下優勢:
    • 資料湖可以儲存結構化資料,也可以儲存半結構化資料和非結構化資料。
    • 資料湖中可以直接儲存沒有經過任何處理的原始資料,也可以支援直接對原始資料做分析。
    • 資料湖中支援資料快速做更新、刪除等操作。
    • 更適合做機器學習、探索性分析、資料價值挖掘等。

在開源社群中,常見的資料湖有Hudi、Delta Lake、Iceberg等。

  • 分散式資料庫儲存:分散式資料庫儲存一般用於儲存對於實時查詢要求較高或者要求實時做OLAP資料分析的資料,在開源社群中,常見的分散式資料庫有Apache Doris(可以透過官網https://doris.apache.org/瞭解更多關於Apache Doris的介紹)、Apache Druid(可以透過官網https://druid.apache.org/瞭解更多關於Apache Druid的介紹)等。

透過以上分析,資料儲存層的架構設計通常建議設計成當前最為流行的湖倉一體的架構,並且針對特殊的業務場景,可以引入一些分散式資料庫或者關係型資料庫進行輔助,如下圖所示。

資料儲存層在儲存資料時,通常還會對資料進行分層儲存,資料分層的架構實現方案通常如下圖所示,資料分層主要是為了

  • 對資料進行模組化設計來達到資料之間解耦的目的,資料透過分層可以將一些非常複雜的資料解耦為很多個獨立的資料塊,每一層完成特定的資料處理,便於開發、維護以及讓資料可以被更好的複用。
  • 讓資料的可擴充套件性更強,當資料業務發生需求變化時,只需要調整響應資料層的資料處理邏輯,避免了整個資料都需要從原始資料(也就是圖中的ODS層的資料)來重新計算,節省了開發和資料計算的資源成本。
  • 讓資料的查詢效能更快,在大資料中,由於存在海量的資料,如果全部從原始資料(也就是圖中的ODS層的資料)中來查詢業務需要的資料結果,需要掃描的資料量會非常大,將資料分層後,可以最佳化資料的查詢路徑,減少資料掃描的時間以達到提高資料查詢效能的目的。

1.4、資料管理層

資料管理層主要負責對資料進行分類、標識以及管理,主要會包含後設資料管理、資料血緣跟蹤管理、資料質量管理、資料許可權和安全管理、資料監控和告警管理等,其總體的實現架構圖如下圖所示。

資料管理層的技術核心就是後設資料、血緣資料、質量資料、監控資料等採集獲取,我們在 清華大學出版社出版的 《資料資產管理核心技術與應用》一書的前面的章節中已經有過很具體的描述,在拿到這些資料後,資料管理層主要要實現的功能就是把這些資料做整合並且展示到資料資產管理平臺中,資料管理層是資料資產管理的核心。

1.5、資料分析層

在資料分析層的架構設計中,主要包含如下兩個部分:

  • 資料分析工具的選擇:隨著大資料分析技術的發展,誕生了很多和資料分析相關的BI工具,常見的BI分析工具的相關介紹如下表所示:

BI 工具名稱

描述

適用的場景

Power BI

是由微軟推出的一款BI資料分析工具

成本較高,通常適合於微軟雲相關的服務中使用

Pentaho

開源的BI分析工具,具有資料整合、報表生成和資料視覺化等功能

開源產品。適合於自己有部署和運維能力的團隊進行使用

Quick BI

是阿里雲推出的一款BI資料分析工具

由於是阿里雲推出,所以通常只適合於阿里雲中使用。

FineBI

是由帆軟推出的一款BI資料分析工具

商業軟體,一般需要購買,通常適用於政府或者企事業單位使。

在選擇BI的資料分析工具時,一般建議結合自身的業務需求、使用成本、管理維護成本等多個方面來綜合考慮,然後再選擇最合適的BI工具。

  • 資料的加工與處理:這裡的資料加工與處理主要是指資料分析需要做的資料預加工與處理,以便資料分析工具能快速得到自己想要的資料。在大資料中,由於是海量的資料,所以在資料分析時,BI分析工具通常不會直接去從海量的原始資料中直接做分析。

透過如上兩點的分析,資料分析層的整體架構設計通常如下圖所示。

  • 資料分析時,對於實時性要求較高的資料,通常會儲存在分散式資料庫中,不做太多的預處理,讓BI工具直接去查詢和訪問,這樣可以保證整個資料分析鏈路的實時性。
  • 對於實時性要求不高的資料,可以每天透過離線的方式進行處理,通常會從資料倉儲或者資料湖中,每天離線對資料做預處理,處理的結果資料可以根據資料量的大小選擇放入普通關係型資料還是放入資料倉儲或者資料湖的ADS應用層來供BI工具做分析使用,甚至資料湖或者資料倉儲的DWD資料明細層或者DWS資料輕度彙總層也可以開放給BI資料分析工具直接做分析。

1.6、資料服務層

資料服務層通常是讓資料對外提供服務,讓資料可以服務於業務,並且負責對資料服務進行管理,資料服務層通常的架構實現如下圖所示,資料服務的具體技術實現細節可以參考清華大學出版社出版的《資料資產管理核心技術與應用》一書的第六章。

資料服務層在設計時,通常需要包括服務建立、服務釋出,服務接入、服務降級、服務熔斷、服務監控以及許可權管理等模組,對於服務訪問的許可權管理通常建議也可以採用基於角色的訪問控制 (RBAC)來實現,如下圖所示。

  • 一個角色可以擁有一個或者多個不同服務,也可以擁有一個或者多個不同的選單。
  • 角色可以賦予給使用者,也可以賦予給呼叫服務的業務需求的上游。

透過對每一層做架構分析與設計後,得到最終如下圖所示的資料資產架構圖,這是大資料處理中最常見的架構設計方案,解決了資料的可擴充套件性以及對於不管什麼型別或者什麼什麼格式的資料,都可以做資料處理、儲存以及分析。

《資料資產管理核心技術與應用》是清華大學出版社出版的一本圖書,全書共分10章,第1章主要讓讀者認識資料資產,瞭解資料資產相關的基礎概念,以及資料資產的發展情況。第2~8章主要介紹大資料時代資料資產管理所涉及的核心技術,內容包括後設資料的採集與儲存、資料血緣、資料質量、資料監控與告警、資料服務、資料許可權與安全、資料資產管理架構等。第9~10章主要從實戰的角度介紹資料資產管理技術的應用實踐,包括如何對後設資料進行管理以發揮出資料資產的更大潛力,以及如何對資料進行建模以挖掘出資料中更大的價值。

相關文章