荷蘭銀行構建可擴充套件的後設資料驅動的資料攝取框架

banq發表於2022-11-01
套件框架

資料攝取是一個異構系統，具有多個來源，具有資料格式、排程和資料驗證要求。現代資料堆疊正試圖在孤島中解決這個問題。組織最終必須捆綁一切以使其工作。ABN AMRO荷蘭銀行 分享了它如何構建後設資料驅動的資料攝取平臺以保持沿襲、質量和排程的案例研究。

資料工程師的典型任務是獲取資料、驗證資料，如果需要，應用聚合等轉換，或將資料與其他來源組合，最後將資料儲存到最終位置，例如儲存資料夾或資料庫。當您在自動活動流中捕獲所有這些任務時，您將獲得一個攝取框架，允許您處理許多檔案，而無需手動檢查、移動和攝取每個檔案。此外，擁有可重用的可擴充套件框架使您能夠有效地處理所有資料需求。
後設資料在構建任何可擴充套件的攝取框架中都起著關鍵作用，在這篇部落格中，我將深入探討此類框架的概念，提供一些構建後設資料驅動的資料攝取框架的實際示例和關鍵要點，旨在提供在處理大量資料時如何利用後設資料值得深思。
在這篇部落格中，我故意不談論工具。可擴充套件、後設資料驅動的資料攝取框架的概念是獨立於工具的，您對工具的選擇取決於許多專案或組織特定的元素，例如成本、合同、戰略和經驗。

它是如何開始的
我們的開發團隊需要構建一個應用程式來滿足組織的業務和技術資料沿襲要求。例如，業務資料沿襲顯示了透過在組織中使用應用程式的資料消耗、使用目的、與此使用相關的風險，以及所有這些元素與不同組織方面（如法規、政策和組織結構）的聯絡。

技術資料沿襲顯示資料如何從任何源應用程式流向其所有消費應用程式以及沿途應用的所有資料轉換。您可以想象，要構建這樣的應用程式，您需要整合許多資料來源，例如有關組織中執行的應用程式的資料、它們生成的資料集、這些資料集的消費應用程式、處理相關應用程式的 IT 團隊，以及與（提供和消費）應用程式中資料的使用和轉換相關的所有資訊。

考慮到我們可以預期的資源數量、它們的更新時間表（大部分是每天），以及在不久的將來可能會有更多資源的公告，我們立即知道我們需要構建一個能夠勝任的資料處理框架處理所有這些不同資料集帶來的所有資料需求。我們設計了一個後設資料驅動的資料攝取框架，它是一個靈活且高度可擴充套件的框架，用於自動化您的資料工程活動。

後設資料在資料攝取框架中的作用
資料攝取框架中的後設資料包含描述處理資料檔案時要執行的步驟的資訊。將後設資料引入您的資料處理框架有很多好處：

  • 可擴充套件性：輕鬆增加或減少流經系統的資料量，並輕鬆向框架新增、修改或刪除功能。即插即用！
  • 可重用性：由於通用設計，功能很容易被其他來源甚至其他應用程式重用。
  • 可維護性：只需維護一組程式碼，您可以將其應用於所有（或部分）源。
  • 減少開發時間：透過編寫通用工作流，所需的自定義程式碼量急劇減少。這樣可以節省很多時間！


攝取框架和示例流程的藍圖
圖 1 顯示了攝取框架的示例藍圖。在此示例中，經過驗證並在需要時將轉換後的資料提取到 SQLDB、NoSQL DB (Graph) 中，或者兩者都提取，或者不提取。該框架能夠應用三種型別的驗證；

  • 快照驗證（確保接收檔案的日期是最新日期）；
  • 行數異常（對檔案中記錄數量的完整性檢查）；
  • 資料型別驗證（確保列的資料型別是預期的資料型別）。

實際上，您可能需要應用更多的驗證或質量檢查。但是，並非所有檢查都適用於所有來源。某些來源可能有資格進行更多（或更少）的驗證檢查，具體取決於檔案特定的功能，如敏感性、治理等。

荷蘭銀行構建可擴充套件的後設資料驅動的資料攝取框架
​
圖 1：資料攝取框架示例。圖片由 Ilse Epskamp 提供。

讓我們介紹一些我們想用框架處理的資料檔案。這些檔案的要求如下：

荷蘭銀行構建可擴充套件的後設資料驅動的資料攝取框架
​
圖 2：檔案的示例資料要求。Ilse Epskamp 的表。

您會看到，只有四個檔案，您已經擁有許多需要應用的框架特性的可能組合。有些檔案需要多次驗證檢查，而另一些則只需要一次。一些檔案有轉換要求，而另一些則沒有。一個只在圖表中攝取，一個只在 SQL 中，一個在兩者中，一個是沒有的。
您可以想象，為每個源編寫自定義流程不僅需要花費大量時間，而且還會導致大量重複程式碼，因為即使並非所有源都需要完全相同的處理方式，但在應用功能方面存在很多重疊。您希望擁有一個可擴充套件的處理框架，使您可以動態地僅選擇要應用於源的功能，而無需手動編寫所有工作流程。


可擴充套件攝取框架的三大支柱
可擴充套件的攝取框架建立在 3 個支柱之上：

  • 資料（主體）；
  • 後設資料（指令）；
  • 程式碼（執行引擎）。

荷蘭銀行構建可擴充套件的後設資料驅動的資料攝取框架
​
資料、後設資料和程式碼驅動任何可擴充套件的攝取框架。圖片由 Ilse Epskamp 提供。

實際示例：使用和不使用後設資料的資料型別驗證
讓我們在故事中新增一些程式碼。我們將對兩個示例資料集應用資料型別驗證，一次不使用後設資料，一次使用後設資料，以演示後設資料在程式碼中的作用。假設我們有兩個檔案；Employee 檔案和 Accounts 檔案。

荷蘭銀行構建可擴充套件的後設資料驅動的資料攝取框架
​
樣本資料員工和客戶。圖片由 Ilse Epskamp 提供。

對於員工檔案，我們要驗證 ID 列是否為資料型別integer。對於 Accounts 檔案，我們要驗證 ACTIVE 列是否為boolean型別。只有這樣我們才能接受這些檔案。我們可以為這兩個檔案編寫自定義驗證。這可能看起來像這樣：

if file=="employees":
   isInteger=False
   if(df.schema("ID").datatype.typeName=="integer"):
     isInteger=True
   result=isIntegerif file=="accounts":
   isBoolean=False
   if(df.schema("ACTIVE").datatype.typeName=="boolean"):
     isBoolean=True
   result=isBoolean


這會很好。但是，假設您每天載入 100 個檔案，並且您希望對其中的一半應用此驗證檢查。或者假設您想檢查同一個檔案的多個列。想想您需要編寫的自定義工作流程的數量！為每個場景編寫自定義工作流不可擴充套件且難以維護。讓我們再做一次，但現在使用後設資料。

首先，我們為這兩個來源定義後設資料。在此示例中，每個源都有一個專用的 JSON 檔案*，其中包含所有相關的後設資料鍵值對。具體來說，我們新增了一個用於驗證檢查的部分，我們在其中啟用特定列的資料型別驗證，並具有特定的預期結果。
*在此示例中，提取的後設資料使用 JSON 檔案配置。或者，您可以使用適合您的應用程式的任何格式或工具。

employees.json:

"filename": "employees",
"validation": {
   "validateColumnDataType": {
   "enabled":  true,
   "colname":  "ID"
   "datatype": "integer"
   }
}

accounts.json:

"filename": "accounts",
"validation": {
   "validateColumnDataType": {
   "enabled":  true,
   "colname":  "ACTIVE"
   "datatype": "boolean"
   }
}

現在我們準備好了後設資料。下一步是編寫一個通用函式，我們可以在處理資料檔案時呼叫它。

def validate_col_datatype(data,col,type): 
   passed=False 
   if(data.schema(col).datatype.typeName==type): 
     passed=True 
   return pass

剩下的就是新增一些程式碼來讀取後設資料並在源啟用時執行驗證功能。

md=read_metadata(filename)run validation if enabled 
if md["validation"]["validateColumnDataType"]["enabled"]: 
   colname = md["validation"]["validateColumnDataType"]["colname"] 
   datatype = md ["validation"]["validateColumnDataType"]["datatype"]
   result = validate_col_datatype(data,colname,datatype)

如果要在多個列上執行此資料型別驗證，只需將其他部分新增到後設資料配置檔案中。如果您不需要對源應用驗證檢查，則將 enabled 設定為false，該源的檢查將被忽略。

使用此模式時，您需要考慮如何處理結果。如果驗證失敗，您是要發出警告並繼續，還是要中斷流程？您想自動通知開發團隊或利益相關者組嗎？設計您的工作流程策略對於利用此類框架可以提供的好處非常重要。

附加的功能
您可以想出更多可以包含在框架中的功能。例如：

  • 更多的驗證和質量檢查。例如，您可以驗證檔案大小、檔案型別、檔案來源、值格式……
  • SCD型。在每個後設資料配置中指定是否要使用 SCD1 或 SCD2 將資料儲存在資料庫中，因此是否要在資料庫中建立和保留歷史資料 (SCD2) 或不 (SCD1)。以這樣一種方式設計您的攝取邏輯，如果啟用 SCD1，則資料庫中的資料將被覆蓋，如果啟用 SCD2，則保留歷史記錄。資料庫中的所有記錄都應具有反映其版本、開始日期、結束日期和上次更新日期的自定義屬性。對於 SQL 資料庫，您可以考慮使用儲存過程來更新記錄版本，或者根據您的資料庫型別使用任何可用的開箱即用功能。或者，在您的攝取邏輯中，您可以動態處理記錄版本。


後設資料配置檔案藍圖
下面是示例員工檔案的後設資料配置檔案的示例，其中包含通用檔案詳細資訊以及用於驗證、轉換和攝取的部分。

"description": "This is the metadatafile for Employees data.",
"sourcename": "HRSYSTEM",
"tablename": "all_employees",
"cardinality": "1-to-1",
"primary_key": "EMPLOYEE_ID",
"daily_delivery": true,
"file_delimiter": ";",
"validation"": {
  "validate_snapshotdate" : true,
  "validate_rowcount_anomaly" : false,
  "validate_col_datatype": {
    "enabled":  true,
    "colname":  "EMPLOYEE_ID"
    "datatype": "integer"
  }
},
"transformations": {
  "preprocessing_description": "Join with file XYZ.",
  "preprocessing_flag": true,
  "preprocessing_logic": "join_HRSYSTEM_all_employees_with_XYZ()"
},
"ingestion": {
  "sqldb": {
    "ingestion_enabled": true,
    "ingestion_environment": "dtap",
    "scd_type": "2",
    "sql_tablename": "employees"
  },
  "csmsdb": {
    "ingestion_enabled": true,
    "ingestion_environment": "dtap",
    "scd_type": "1",
    "vertex_label": "EMPLOYEES",
    "is_mapping_file": false   
  }
}



經驗
在設計和構建後設資料驅動的資料攝取框架時，我建議至少考慮以下幾點：

1.不要偷工減料
我們都知道在緊迫的時間表內修復錯誤或編寫解決方案時可能會遇到的工作壓力。由於許多原因，可能很容易將注意力集中在手頭的問題上而不檢視通用實現。但是，請花一點額外的精力來使您的工作流程通用且可重用。你以後一定會從中受益的！

2.想想你的命名約定
您的框架應該能夠動態查詢各種資源，從儲存帳戶及其目錄和檔案到資料庫及其表名。考慮一下並定義一個標準。

3. 框架監控
自動化很棒，但要保持控制。找到一種方法來掌握框架中正在發生的一切。例如，我們在框架之上構建了一個監控層，將每個決策和每個結果記錄到一個集中的事件日誌中，我們用它來構建運營報告。

4. 保持需求驅動
一旦開始，您會想到許多可能有用的功能。保持需求驅動，以確保您新增到框架中的任何功能都直接為您的客戶或您的開發團隊做出貢獻。 

相關文章