# 一、業務背景

## 1、應用場景

在多變的資料服務場景中，應用中常見如下的業務需求，透過對多種資料結構的靈活組合，快速實現業務模型構建，整體示意圖如下：

![](http://img.blog.itpub.net/blog/2021/10/18/3d296a35e05a9ae6.png?x-oss-process=style/bb)

像常用的畫圖工具，左邊提供基礎圖形庫，中間是畫布，右邊是元件的控制細節，對比到這裡的邏輯如下：

- 欄位皮膚：提供業務資料結構的欄位對映，和常規欄位型別配置，用來支撐組合皮膚的表單配置。

- 資料結構：對現有業務結構做對映，可能是檔案、資料表、JSON等，生成相對標準的欄位選項；
    - 拓補欄位：維護一批基礎的欄位型別，用來做拓補操作，完善整個業務結構；

- 組合皮膚：承載欄位的組合管理，生成新的資料結構，根據業務場景，完成底層資料的抽取儲存或者API服務生成。
    
    - 業務主體：透過業務需求的判斷，明確皮膚支撐的業務屬性，透過基礎結構組合新的業務主體；
    - 組合結構：皮膚上呈現的欄位，是多個業務結構的抽取，即不同業務結構中的部分欄位組合；

- 規則皮膚：對組合皮膚上欄位進行規制設定，常見涉及：描述，型別，預設值等，對皮膚欄位進行相對統一的標準化管理。

- 描述資訊：對於組合皮膚上的欄位描述，也可以是原有對映的結果，作為新業務主體的屬性說明；
    - 型別維護：複雜的環節，不同資料型別在不同的儲存中處理方式不同，需要統一維護型別儲存對映；
    - 業務規則：對於新的業務主體，設定屬性的規則，可以是：唯一性，預設值，等等；

## 2、構建服務

基於上述功能的實現，可以快速實現以下服務能力，通常應用在業務多變的場景中：

- 資料主體構建：透過組合皮膚的結構生成，快速完成相關資料的抽取和儲存，作為新的業務場景中的主體資料。

- 服務API生成：在資料服務中，直接透過配置，生成API服務能力，並控制引數的響應結構，這種情況通常會以實時查詢的方式處理。

- 資料智慧分析：在資料分析場景中，側重統計的結果，基於欄位和圖表結構，生成相應的統計分析任務，靈活管理分析報表。

這裡是簡述相對單一的應用服務，如果把這裡的流程分段放大，在整個資料服務體系下，就是圍繞後設資料管理的複雜的基礎系統：圍繞資料結構對映，進行後設資料標準化管理，在此基礎上二次組織資料，快速響應業務需求。在這樣的流程下，可以快速建立業務鏈路，提供高效的服務能力，降低試錯的成本。

# 二、後設資料概念

## 1、基礎描述

從定義上說，後設資料(Metadata)即描述資料的資料，但是在實際使用的時候，還是存在很多細分的概念，看下面的案例：使用者性別；

![](http://img.blog.itpub.net/blog/2021/10/18/5a7189b45ee54c67.png?x-oss-process=style/bb)

從細分角度看，可以對上面資料進行兩塊劃分，即業務層與技術層：

- 業務層：名稱.釋義.說明.值型別;
- 技術層：路由庫.路由表.儲存型別.值型別;

這裡的分層只是描述的側重點，業務層偏向應用端，技術層偏向底層系統的互動和實現，在對性別的描述上都是核心維度。

所以從本質上看後設資料，介於系統和業務中間，提供雙方都能明白的語義和邏輯，可以更加高效的支撐資料的業務價值。

## 2、血緣關係

上面是從單個指標看後設資料的結構，如果從整個鏈路上看，就會形成層級線路，通常稱為血緣關係：

![](http://img.blog.itpub.net/blog/2021/10/18/36c802df86c4798b.png?x-oss-process=style/bb)

從上層業務側追溯到底層結構，形成血緣關係的概念，概念本身並不重要的，背後的核心是鏈路的管理，鏈路上的節點（中間實體）是透過多種計算手段生成；

如果某個節點資料一旦出現質量問題，則需要根據這裡的鏈路關係進行逐級向底層排查，完成問題修復後，還需要根據關係向上逐級修復清洗；如此透過血緣關係進行資料質量的分析和把控。

## 3、業務價值

後設資料管理是一個持續又漫長的過程的，任何系統的搭建都需要業務來衡量其存在的價值，其核心邏輯在於：統一標準化管理後設資料資訊，規範業務層的定義，並透過技術層面快速定位資料，自動化抽取資料，靈活支撐業務應用。

- 圍繞核心業務：通常在專案初期的時候，只圍繞一些核心業務主體，使其在使用的時候靈活高效，後續在持續擴充套件其他能力。

- 資料成本分析：基於後設資料中鏈路，分析各個節點資料的生產維護管理等成本，為資料服務中商業定價提供參考，可能直接影響服務是否可提供的決策。

- 配置視覺化：在資料服務平臺中，最忌諱的一點就是靠手動去維護各種作業，不管在什麼場景下，都要考慮可配置化管理，保證動作可追溯。

- 流程自動化：不管是後設資料結構對映，還是配置後資料的抽取，要保證指令生成後可以自動完成該一系列動作，並完成流程監控分析。

- 資產化分析：通常會把後設資料視為資料資產體系，因此圍繞後設資料去統計資料的使用情況，產生的價值，以及熱點資料識別和分佈，業務主體關聯度等，並輸出相應分析結果。

如果單從業務角度去看，後設資料系統的存在，就是為了可以快速理解後設資料，並且靈活的組織管理，以此降低服務能力的實現成本。

# 三、架構設計

## 1、系統分層

![](http://img.blog.itpub.net/blog/2021/10/18/f0653aae710d3789.png?x-oss-process=style/bb)

- 採集層：後設資料系統中的基礎節點，架構體系的底層，維護後設資料獲取通道和對映管理以及落地儲存，並實現結構管理和資料處理過程；在資料來源中可能存在多種情況：數倉環境、檔案結構等，在特定情況中，還需要一定程度的手動維護進行結構拓補；

- 管理層：對於後設資料核心能力打造，和相應的標準化管理，或者二次加工，資料來源層面直接採集的資料通常不具備標準的業務語義，更多偏向技術側的說明和邏輯，在經過標準化維護之後，在放開給應用層之前，還需要經過質量檢測：例如工作城市，如果缺乏相應的列舉字典，顯然是不合格的，必須經過必要的處理才能放開；即管理層放開的資料需要標準化和整體維度完善；

- 應用層：基於後設資料能力的應用層開發，對於實際業務場景提供解決方案和功能入口，以及相應的系統中使用者許可權隔離等基本功能；

從系統分層的角度理解流程並不複雜，但是實際的實現過程簡直不堪回首，技術棧使用非常複雜，多個版本邏輯重構再重構，並且不斷的改進最佳化，最終才能實現相對穩定的服務能力。

## 2、後設資料採集

在採集資料的時候，面對的最大問題就是多種類資料來源解析適配，以及資料排程任務的抽象，必須開發對應的工具來實現各種場景的後設資料解析能力：

- 解析能力：適配解析各種資料來源特點，檔案格式，SQL指令碼，抽象任務等，完成標準後設資料的轉換沉澱；

- 型別識別：十分複雜的一個節點，型別在描述資料的時候至關重要，結構化儲存可以直接讀取，檔案類結構通常需要型別轉換標識，任務流程會直接統一管理，依次保證資料在不同環境中的合理儲存；

- 更新訊息：業務的發展中，各種資料結構是頻繁變動的，這就需要與後設資料系統進行同步，通常要向訊息服務（匯流排）傳送通知，然後觸發後設資料更新動作；

核心能力：結構與型別識別解析、獲取初始化資料，並且透過訊息通知線路，完成動態更新流程的觸發。

## 3、後設資料管理

核心能力的打造，通常在系統初期都是圍繞基本能力和業務需求的方向，以求快速落地實現，提供業務支撐能力；

- 基礎能力：標準化後設資料結構，進行結構儲存和可搜尋能力實現，這個節點進行統一維護，資料型別識別和轉換是至關重要的；補充說一句，在資料平臺中，都會存在型別服務系統，以提供相應的識別能力和規範不同場景下的轉換；

- 實體與關係：資料業務中兩個核心概念，實體必然由屬性構成這是常說的，實體之間維護的關係：關聯、、繫結、輸出、輸入等，是構建血緣關係和資料鏈路的核心標識；

- 資料抽取：基於對後設資料的組織和實體的定義，生成資料抽取規則，進而完成資料的快速獲取，後續就是對接具體的業務，例如資料儲存方式，搬運方式，最終落地業務線使用；

- 視覺化分析：包括資料質量分析，鏈路與週期分析，血緣分析等，這類功能一般在核心業務能力完成之後，會按需求等級，逐步迭代實現；

透過核心能力的建設，以求實現對資料的快速定位，高效管理，靈活應用的目標，提高資料服務能力的效率，適應業務發展的多變性。

## 四、原始碼地址

```
GitEE·地址
https://gitee.com/cicadasmile
Wiki·地址
https://gitee.com/cicadasmile/butte-java-note/wikis
```

![](http://img.blog.itpub.net/blog/2021/10/18/97fa8e57cfdbe2e8.png?x-oss-process=style/bb)

資料服務基礎能力之後設資料管理

相關文章