數(shù)據(jù)處理和數(shù)據(jù)工程的4個設計原則

設計模式的實踐在面向對象編程（OOP）中最為流行，在Erich Gamma和Richard Helm的經(jīng)典著作《設計模式：可重用的面向對象軟件的元素》中已得到有效的解釋和總結。 以下是維基百科中"設計模式"的定義：

"軟件設計模式是針對軟件設計中給定上下文中的常見問題的通用，可重用的解決方案。 它不是可以直接轉換為源代碼或機器代碼的最終設計。 它是如何解決可在許多不同情況下使用的問題的描述或模板。 設計模式是形式化的最佳實踐，程序員可以在設計應用程序或系統(tǒng)時用來解決常見問題。"

對于數(shù)據(jù)科學，許多人可能會問過同樣的問題：數(shù)據(jù)科學編程是否具有設計模式？ 我會說是的。 但是，為了將它們與OOP區(qū)別開來，我將它們稱為"數(shù)據(jù)科學設計原理"，其本質含義與OOP設計模式相同，但級別更高。 受羅伯特·馬丁（Robert Martin）的"清潔架構"一書的啟發(fā)，本文重點介紹了數(shù)據(jù)處理和數(shù)據(jù)工程的4個頂級設計原則。 我的下一篇文章將討論優(yōu)化性能的通用設計原理。 在這兩個領域中，都有可重復使用的解決方案和最佳實踐，它們已被證明能夠：

· 縮短整體開發(fā)周期；

· 使數(shù)據(jù)過程更易于維護（無論使用哪種編程語言或數(shù)據(jù)準備工具）；

· 使系統(tǒng)更加開放和易于操作；

· 從一開始就確保數(shù)據(jù)質量。

設計原則1：始終從數(shù)據(jù)集和數(shù)據(jù)實體的設計入手

每個數(shù)據(jù)過程都具有3個最小的組成部分：輸入數(shù)據(jù)，輸出數(shù)據(jù)和它們之間的數(shù)據(jù)轉換。 無論何時設計數(shù)據(jù)流程，首先要做的就是清楚地定義輸入數(shù)據(jù)集以及輸出數(shù)據(jù)集，包括：

· 所需的輸入數(shù)據(jù)集和參考數(shù)據(jù)

· 要創(chuàng)建的輸出數(shù)據(jù)集

· 每個數(shù)據(jù)集中的數(shù)據(jù)字段

· 每個字段的數(shù)據(jù)類型，例如文本，整數(shù)，浮點數(shù)，列表等，

· 確定每個記錄的唯一性的字段

· 每個字段的預期數(shù)據(jù)模式，包括它是否可以缺少值和明確的值列表

· 數(shù)據(jù)集與組織中其他現(xiàn)有數(shù)據(jù)集的關系

這類似于應用于數(shù)據(jù)庫的所謂數(shù)據(jù)建模，有時也稱為"數(shù)據(jù)庫邏輯設計"。 此處的關鍵字是"邏輯的"，因為它應該在實施決策之前發(fā)生。 數(shù)據(jù)集可以寫入磁盤并永久存儲在公司內部，并且最終將成為其他流程和應用程序訪問或使用的真正資產(chǎn)。 因此，它是真正重要的，并且應該準確準確地定義，并采用由數(shù)據(jù)治理驅動的最佳實踐和策略。 特別是，應根據(jù)業(yè)務需求或下游組件或流程的需求定義輸出數(shù)據(jù)集。 輸入數(shù)據(jù)集應與其源保持一致，以便可以輕松地在不同系統(tǒng)之間跟蹤數(shù)據(jù)沿襲。

在進行邏輯設計之后，可以將給定數(shù)據(jù)集的物理位置和數(shù)據(jù)結構確定為系統(tǒng)設計的一部分。 通常，物理結構可能與邏輯設計不同。 一個典型的例子是，邏輯設計中的字段名稱應使用普通詞以使其更有意義和可讀性，而物理字段名稱必須考慮系統(tǒng)或軟件的限制。 例如：

· 邏輯字段名稱：員工名稱

· 物理字段名稱（不能有空格，并且對字符數(shù)有限制）：emp_nm

更改組織中的數(shù)據(jù)平臺時，邏輯定義不應更改，而數(shù)據(jù)集的物理表示形式可以根據(jù)系統(tǒng)要求和功能進行重新設計。

如果流程需要多個步驟，則還需要定義中間數(shù)據(jù)集的內容，這可以用于不同目的：

· 用于數(shù)據(jù)質量檢查

· 提供流程檢查點和階段，以便在流程失敗時無需始終從頭開始重新運行

· 充當另一個子流程的輸入，或可供其他系統(tǒng)或用戶使用

與用于數(shù)據(jù)處理邏輯的代碼相比，數(shù)據(jù)實體花費更長的時間和更多的精力來進行更改以產(chǎn)生更大的影響，這主要是因為它已經(jīng)保存了數(shù)據(jù)并且可以被其他流程使用。 另一方面，一旦定義了輸入，中間和輸出數(shù)據(jù)集，則數(shù)據(jù)處理本身的框架就位。 我們經(jīng)?？吹綌?shù)據(jù)工程師開始構建流程，而沒有先明確定義輸出。 這很容易導致2種后果：1）更改輸出時，進行更大的更改，甚至對流程進行修改； 2）輸出取決于處理邏輯，因此，錯過了一些要求或定義不明確。 因此，在開始設計技術流程之前，請務必先定義數(shù)據(jù)集。 實際上，無論如何，處理邏輯很大程度上取決于輸入和輸出的數(shù)據(jù)定義。

數(shù)據(jù)集和數(shù)據(jù)實體的邏輯設計還與遵循組織標準的初始業(yè)務需求收集，數(shù)據(jù)發(fā)現(xiàn)和數(shù)據(jù)治理過程緊密相關。 此外，謹慎的邏輯設計應考慮組織內的數(shù)據(jù)共享，如果在公司的其他地方存在字段或數(shù)據(jù)，則應避免重復數(shù)據(jù)集（請參閱我的文章：主數(shù)據(jù)管理：數(shù)據(jù)策略的重要組成部分）。 最后，具有良好治理的清晰數(shù)據(jù)集邏輯設計是從一開始就確保數(shù)據(jù)質量的關鍵步驟（請參閱我的文章：確保和維持數(shù)據(jù)質量的7個步驟）。

設計原則2：將業(yè)務規(guī)則與處理邏輯分開

在羅伯特·馬?。≧obert Martin）的"清潔體系架構"一書中，原則之一是從軟件角度尤其是從OOP功能將業(yè)務規(guī)則與插件分開。 但是，在數(shù)據(jù)工程中，存在相似的原理，而業(yè)務規(guī)則具有更廣泛的含義。 首先，業(yè)務規(guī)則由不同類型組成，例如，營銷，財務，安全性或合規(guī)性中的特定方法。 在許多情況下，業(yè)務部門也可以驅動數(shù)據(jù)清理和標準化的規(guī)則，因此，它們被視為業(yè)務規(guī)則。 業(yè)務規(guī)則通常具有3個特征：

· 需要由業(yè)務組織或業(yè)務分析師進行審查

· 可能經(jīng)常更改并且需要快速周轉

· 如果未正確配置或執(zhí)行它們，則會導致嚴重的影響和后果

業(yè)務規(guī)則的管理和執(zhí)行對于數(shù)據(jù)過程的成功至關重要。 好的設計應考慮以下方面：

1.模塊化

相同類型的規(guī)則應在相同的數(shù)據(jù)過程，模塊或功能中處理。 另一方面，不同類型的規(guī)則不應駐留在相同的流程，模塊或功能中。 否則，將難以管理業(yè)務規(guī)則變更的影響，并且流程將變得更加難以維護。

讓我們舉一個處理客戶調查數(shù)據(jù)的小例子，您需要清理原始數(shù)據(jù)，對其進行標準化，然后將標準化數(shù)據(jù)加載到數(shù)據(jù)庫表中。 這里的輸出是標準數(shù)據(jù)庫表，而您的測量數(shù)據(jù)是原始輸入。 有兩種構建過程的方法：

數(shù)據(jù)清理規(guī)則與字段映射規(guī)則不同：數(shù)據(jù)清理規(guī)則基于輸入數(shù)據(jù)的值，而字段映射則基于輸入和輸出的數(shù)據(jù)結構。鑒于此，選項1更好，因為它允許獨立于字段映射的規(guī)則來更改數(shù)據(jù)清理規(guī)則，因此與選項2相比，它具有更大的靈活性和簡便性，并且對規(guī)則修改的影響較小。分離不同類型的規(guī)則可以更好地管理規(guī)則，同時對其他類型的規(guī)則以及其他處理邏輯的影響最小。此外，針對一種業(yè)務規(guī)則的特殊功能或模塊可以在需要時成熟為獨立的服務，然后可以針對其他用例輕松地進行單獨更改或增強。

2.業(yè)務規(guī)則的元數(shù)據(jù)存儲

只要有可能，應將經(jīng)常更改的部分業(yè)務規(guī)則抽象出來并存儲在與編程代碼本身分開的存儲庫（例如數(shù)據(jù)庫）中。 有了這種分離之后，便可以在其之上構建應用程序或API，業(yè)務分析人員和/或業(yè)務用戶可以通過該應用程序或API查看和修改業(yè)務規(guī)則。 在處理方面，引擎僅在執(zhí)行時從存儲庫中讀取規(guī)則，然后將規(guī)則應用于輸入數(shù)據(jù)，而無需將任何業(yè)務邏輯硬編碼到流程本身中。

3.業(yè)務規(guī)則的版本控制和記錄

在將業(yè)務規(guī)則存儲在元數(shù)據(jù)存儲庫中并進行單獨管理之后，進一步的版本控制和日志記錄功能將變得非常強大，從而使用戶能夠在批準之前更改新版本中的規(guī)則，并將結果與先前版本的結果進行比較 或發(fā)布更改。 此外，記錄每個業(yè)務規(guī)則之前和之后的結果對于控制規(guī)則執(zhí)行的準確性以及確保從規(guī)則引擎創(chuàng)建的輸出數(shù)據(jù)的質量至關重要。

設計原則3：從一開始就構建異常

數(shù)據(jù)永遠不可能是完美的，因此，我們永遠都不會假設輸入數(shù)據(jù)是完美的。 在初始設計中應考慮數(shù)據(jù)異常處理，例如以下內容：

· 數(shù)據(jù)集是否具有預期的格式？

· 輸入數(shù)據(jù)集的記錄數(shù)是否正確或為空？ 如果文件為空，許多編程語言都不會失敗-需要顯式捕獲空文件異常。

· 每列的數(shù)據(jù)類型正確嗎？ 同樣，當某些記錄中的幾個值的格式錯誤時，某些程序可能會靜默失敗。

· 定義引發(fā)異常的條件：1）在繼續(xù)進行過程中是否應該發(fā)出警告，或者過程是否失敗； 2）誰將是收到警報的收件人？

首先，處理數(shù)據(jù)異常對于確保數(shù)據(jù)質量至關重要。 設計良好的流程應預先定義所有這些異常，并在流程中捕獲它們。 這些異常不僅可以導致實時警報，還可以饋入集中式數(shù)據(jù)質量報告和儀表板。

設計原則4：使用標準輸入和輸出易于集成

我們如何使數(shù)據(jù)流程易于集成？ 一個重要原則是創(chuàng)建標準化的輸入層和標準化的輸出層，以"封裝"主過程。 如下圖所示，用于標準化輸入數(shù)據(jù)的過程應與主過程分離并分離，其中其輸出是主過程的標準輸入數(shù)據(jù)集。 將來，如果有更多類型的輸入數(shù)據(jù)，則可以構建和集成一個單獨的標準化過程，而無需更改主要過程。 這也適用于輸出-當需要生成潛在不同格式的輸出時，應首先生成標準輸出層。 這樣就可以通過構建單獨的流程從標準輸出中生成將來的輸出，而無需更改主流程。 顯然，標準輸入和輸出數(shù)據(jù)集在連接點起作用，這樣其他流程可以輕松地與主流程集成。

結論

本文總結了數(shù)據(jù)處理和工程的4個設計原理。 這些原則不僅應由數(shù)據(jù)架構師用于設計大型系統(tǒng)，而且還應由數(shù)據(jù)科學家和數(shù)據(jù)工程師用于較小的流程。 如果以有紀律的方式采用這些原則，那么精心設計的數(shù)據(jù)流程將使維護變得更加容易，變更的效率更高，而對系統(tǒng)其他部分的影響則更少，并且最后提供的數(shù)據(jù)質量將比那些未遵循的過程更好。 遵循以上原則。