数据处理和数据工程的4个设计原则

设计模式的实践在面向对象编程（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个设计原理。 这些原则不仅应由数据架构师用于设计大型系统，而且还应由数据科学家和数据工程师用于较小的流程。 如果以有纪律的方式采用这些原则，那么精心设计的数据流程将使维护变得更加容易，变更的效率更高，而对系统其他部分的影响则更少，并且最后提供的数据质量将比那些未遵循的过程更好。 遵循以上原则。