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

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

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

· 縮短整體開發周期；

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

· 使系統更加開放和易于操作；

· 從一開始就確保數據質量。

設計原則1：始終從數據集和數據實體的設計入手

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

· 所需的輸入數據集和參考數據

· 要創建的輸出數據集

· 每個數據集中的數據字段

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

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

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

· 數據集與組織中其他現有數據集的關系

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

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

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

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

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

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

· 用于數據質量檢查

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

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

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

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

設計原則2：將業務規則與處理邏輯分開

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

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

· 可能經常更改并且需要快速周轉

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

業務規則的管理和執行對于數據過程的成功至關重要。 好的設計應考慮以下方面：

1.模塊化

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

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

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

2.業務規則的元數據存儲

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

3.業務規則的版本控制和記錄

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

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

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

· 數據集是否具有預期的格式？

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

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

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

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

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

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

結論

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