我们探讨了数据建模在数据工程中的重要性、数据建模的历史以及数据日益复杂的情况。我们还谈到了理解数据格局的重要性、其挑战以及业务需求在推动成功的数据项目中的关键作用。
坚实的数据建模基础可帮助组织创建高效、可扩展且灵活的数据架构，以满足各种分析和处理需求。随着我们在本系列中的进步，我们将更深入地研究数据建模技术、模式和最佳实践的复杂性。
什么是数据建模？
在数据工程的上下文中，数据建模创建组织数据的结构化表示。这种表示通常以可视化方式说明，有助于理解数据中的关系、约束和模式，并作为在设计数据系统（如数据仓库、数据湖或任何分析解决方案）时获得业务价值的蓝图。
在最直接的形式中，数据建模是我们设计数据流的方式，使其以结构化的方式高效地流动，具有良好的数据质量和尽可能少的冗余。
为什么它在数据工程中很重要？
在快速增长和变化的数据环境中，拥有清晰的数据结构和架构至关重要。最好的方法是有一个好的数据模型和策略。
数据建模的一个重要部分是业务逻辑，它作为 SQL/Python 代码、一些拖放式 ETL 工具或在现代业务规则引擎中集成到数据流中。
由于时间限制、快节奏的开发或有时缺乏知识，大多数数据项目最初都忽略了数据建模。与其花时间勾勒出数据应如何从其源头、组织的需求流向最终用户希望如何分析其数据，不如使用“肮脏的” MVP快速构建项目。
数据建模与明确的目标齐头并进。它集成了技术和数据要求以及业务和性能要求。有了这些，在公司内部保持一致，就可以更容易地从数据的角度理解业务，并从长远来看取得成功。
概念、逻辑到物理数据模型
- 概念模型代表一个高级视图（数据的自上而下），
- 逻辑模型提供更详细的数据关系表示，
- 物理模型定义数据库中的实际实现或数据存储系统（自下而上）。
不同层次的数据建模
数据建模可以应用于不同的级别，并且包含的不仅仅是建模。除了概念、逻辑和物理数据模型之外，您还可以对源 OLTP 数据库、仓库、BI 工具和 ML 功能进行建模。更重要的是，我们在本文中进一步讨论了整个组织的整体数据建模。
最后，可以对数据工程生命周期的每一层进行建模。仅举几例：
- 生成或源数据库：对应用程序源数据库的实体建模，并将表规范化为其第三范式 (3NF)。选择所选数据库的最佳功能。
- 数据集成和 ETL 流程：定义源到目标的映射、转换和数据清理规则，以将来自多个源的数据移动和整合到数据仓库或其他中央存储中。
- 数据仓库（分析级别）：创建非规范化或多维模型，例如星型或雪花模式，实现高效查询和数据聚合。
- 数据湖：应用于为多样化且通常是非结构化的数据源创建一致的结构、目录和元数据管理策略，以改进数据发现、治理和可访问性。
- BI 工具和报告（演示级别）：设计报告和可视化工具中使用的数据结构、聚合和计算。构建表示层可能涉及创建语义层，例如数据立方体，以简化业务用户对底层数据的访问。
- 机器学习和人工智能：特征工程、规范化和数据编码，以确保与各种算法和工具的兼容性。
考虑到这些不同的层次，关键是对端到端的业务需求进行建模。有时，这些在存储计算和流程组织的业务规则中建模。通过将业务逻辑集成到数据建模中，组织可以确保其数据架构与其目标保持一致并支持有效的决策制定。
务规则引擎示例
例如，Dagster 是一种现代业务规则引擎，您可以在其中用 Python 代码表达逻辑，与无代码/较少代码方法相比，这使其可测试和可扩展.
Microsoft 有RuleEngine和其他几个Drools。
如果您想利用 SQL 进行转换，dbt 是另一个选择。
数据建模的历史：快速回顾
要了解数据建模，我们必须回顾历史并了解该术语的起源。多年来，数据建模的历史随着技术和需求的变化而不断发展。这种演变可以大致分为几个关键阶段：
- 数据管理的早期（1960 年代-1970 年代）：第一个数据库和数据模型出现了。分层和网络数据模型是主要的数据建模技术，为更高级的数据模型奠定了基础。BI 和数据仓库仍处于起步阶段。
- 关系数据库的出现（1980 年代） ： Edgar F. Codd引入的关系模型彻底改变了数据建模和管理。关系数据库促成了实体关系图 (ERD)模型的开发，该模型成为设计和实现事务系统数据库的主要方法。
- 数据仓库和 BI的诞生（1990 年代） ：BI 和数据仓库在此期间获得了突出地位。Ralph Kimball 引入了维度建模，成为数据仓库设计的标准。Bill Inmon 提出了另一种方法，即自上而下的方法，该方法侧重于创建企业范围的规范化数据模型。Kimball 和 Inmon 的方法解决了为决策制定分析和报告数据的挑战。
- 数据源和大数据的扩展（2000 年代）：随着组织开始从各种来源（包括网络和社交媒体）收集和分析数据，数据的数量、种类和速度显着增加。这种数据增长导致了Hadoop、NoSQL 数据库和数据湖等大数据技术和平台的出现。这种情况下的数据建模必须适应不断变化的环境，结合新的数据类型和存储系统。
- 现代数据工程（2010 年代至今）：随着计算能力的下降、云计算、高级分析和机器学习的兴起，数据工程已经发展到可以处理日益复杂和多样化的数据生态系统。现代数据工程领域的数据建模需要适应各种数据源、格式和存储技术，例如基于云的数据仓库、数据湖和实时流数据。
在现代数据工程的背景下，数据建模侧重于创建灵活、可扩展且高效的数据模型，以满足各种分析和处理需求。数据保险库建模、数据网格等新技术已经出现，我们稍后将在第二部分讨论这些差异。
为什么数据建模不再流行？
从 2003 年到现在一直在数据生态系统工作，我可以亲身体验这种转变。
它失去人气的一个可能原因是，一小群专门的工程师通常着手对组织内的旧数据平台进行现代化改造。
由于缺乏时间和资源，这些小团队在展示可行的 MVP 后立即被迫向企业交付有价值的产品。因此，团队没有花足够的时间来开发强大的基础，而是修补了 MVP 版本以用于生产。
这种快速方法一开始可能没问题，因为您可以测试您的假设，无论新方法是否与业务人员交谈。在大多数情况下，批准后退一步并在大局上保持一致将是更好的一步。
数据的复杂性
数据及其生态系统正在迅速变得更加复杂。尤其是在处理数据时——数据总是过时的，依赖于第三方工具或服务，而且你有多个来源甚至系统。所有这些都使得数据很难处理。
除了这些明显的困难之外，建模数据甚至更加复杂。最好考虑存储数据、转换、聚合、正确的粒度、将它们汇总等等。这些是我们将在本章中介绍的内容。
Big-O 为什么重要
如果您不专注于很好地建模数据，移动数据可能会呈指数级快速增长。如果您对此一无所知，那么您可能无法交付性能良好的代码。它接近于使用Big-O表示法进行编程。本质上，它定义了常数时间 O(1)、线性时间 O(N) 或二次时间 O(N^2) 中函数的复杂性。
假设您不关心复制数据集版本略有不同的时间，本质上是数据如何流经您的组织。在这种情况下，可能会导致大量冗余和高成本。
由于数据工程可以（并且应该）被视为应用于数据的计算函数（幂等性），因此您可以看到复制数据的复杂性如何可以非常快地达到 O(N^2)。
粒度和汇总，为什么这些很重要
粒度是相关的，也是必须考虑的。您的数据粒度定义了您存储的详细信息，如果您不小心，则会增加重复。例如，如果您想要一个按国家/地区聚合的数据和另一个包含每个城市、时间和用户的完整详细信息的数据，通过建模，您可以将其存储一次并在顶部聚合。
有一些技术可以帮助防止复制称为汇总。如果您不需要这些详细信息，汇总会大大减少要存储的数据量。它保持聚合以获得更快的查询时间，以避免重复所有行。比如 Druid 等数据库就内置了这样的特性。
数据建模来拯救
那么复杂数据的解决方案是什么？如果我们从数据建模的角度来看数据工程，我很乐观地认为我们有一个角度来对抗这些力量并保持较低的存储数据复杂性。
数据建模的关键概念
在介绍数据建模之后，让我们先看看适用于所有数据建模技术的数据建模的关键概念，然后再深入研究每种不同的数据建模技术。
指标/KPI
指标、KPI和（计算的）度量是作为业务绩效如何衡量和定义的构建块的术语，作为如何定义组织的 KPI 的知识。
对它们有共同的理解是至关重要的。领先一步，指标通常显示在业务报告和仪表板中，可直接访问整个组织。指标与数据建模相关，作为一种定义目标的方式。您必须定义它们以了解您构建数据堆栈的目的。通过在整个组织内达成一致的指标，您可以创建一个数据模型来引导您到达那里。
归一化：归一化与非归一化
由 Edgar F. Codd 创建的规范化是关系数据建模中的一个基本概念，旨在通过避免存储数据的多个实例来最小化冗余并确保数据一致性。无冗余关系数据模型通常称为规范化数据模型或第三范式 (3NF)中的数据模型。相比之下，OLAP 多维数据集和分析解决方案通常使用具有维度和事实的维度建模，这针对快速查询延迟进行了优化。
在实践中，创建关系数据模型通常涉及以第三范式隐式设计模型，而无需详细执行各个规范化步骤。数据可以分为主数据和交易数据，其中主数据描述具有随时间变化的属性的业务对象，而交易数据表示与事件发生时间相关的特定业务事件。
“大数据”出现的一项众所周知的技术是 One Big Table (OBT) 方法，它创建一个包含所需粒度内所有维度的宽非规范化表。将数据存储在 OBT 中可以通过消除连接需求简化查询并提供更快的响应时间，尤其是在使用列式存储格式时。但是，管理 OBT 可能具有挑战性，因为更新或回填维度需要修改许多行。数据湖表格式使这个过程更易于管理。
OBT 的概念并不新鲜；Oracle 中的物化视图在过去也有类似的使用。规范化和反规范化之间的选择取决于具体的用例、存储能力和查询性能要求。这两种方法都有优点和局限性，数据工程师必须仔细评估这些因素才能设计出有效的数据模型。
历史或渐变维度 (SCD)
如果您的组织需要从法律角度或纯分析角度跟踪历史和发生的变化。这些决定必须尽早做出，并且会对数据建模部分产生相当大的影响。
最常见的方法是渐变维度（类型 2）。渐变维度 (SCD) 是在数据仓库中随着时间的推移存储和管理当前和历史数据的维度。它被认为是跟踪维度记录历史的最关键的 ETL 任务之一并被实施。
其他方法正在引入所有内容的快照。有了新的数据湖表格式，您就拥有了Time Travel的功能，这实际上可以让您返回并查看已完成的每个更改。不过要小心。结果是多次存储所有数据并影响您查询数据的方式。您应该在查询中添加一个时间戳，例如截止日期。如果您对该日期的状态进行了快照，则可以及时跳回并查询去年年底的数据。另一种技术是双时态建模；更多关于第二部分。
建模历史也不同于数据类型（主数据和事务）。主数据（例如地址）会随时间变化，而交易数据（例如帐户交易）主要是添加新行。一个常见的挑战是可能存在特定数据记录的多个版本。尽管如此，关系并不指特定版本，而是指总体实体（即，版本所属的元素）。
实体关系图 (ERD)
实体关系图 (ERD) 是数据建模中使用的可视化表示，它说明实体（通常是数据库中的表）如何在系统中相互关联。
ERD 有助于设计或调试关系数据库。作为数据建模的一部分，ER 图利用一组符号（例如矩形、菱形、椭圆形和连接线）来描述实体、关系及其属性的互连性。
这些图表反映了语法结构，将实体表示为名词，将关系表示为动词，提供了一种直观且有条理的方式来理解数据模型中的结构和关系。