【数据模型】重塑数据模型：现代数据平台的基石

今天，我们来看一个古老的数据工程主食——数据模型及其在现代数据平台中的地位。在经典意义上，数据模型只是描述一组相关数据资产中存在的结构、内容和关系的元数据。长期以来，维护数据模型一直是基于SQL构建的OLTP工作负载的标准做法。通常由数据工程师和数据架构师维护，他们帮助管理资产的演变，消除不必要的重复，并强制执行约定，以保持直观和一致的布局。一个关键的额外好处是向消费者（如数据分析师）告知资产以及如何最好地使用它们。因此，维护数据模型也是管理大型SQL数据仓库演变的常见做法。如果没有数据模型，最终用户将发现在一个包含数百（如果不是数千）数据资产的库中导航并正确利用它们是一项挑战。因此，拥有一整套行业工具来帮助构建和维护数据模型，并确保模型与现实世界的实现同步，这并不奇怪。

过去十年中的几个趋势同时增加了对更丰富数据模型的需求，同时使构建和维护这些模型变得更具挑战性。

1. 尽管SQL数据仓库继续发挥着重要作用，但它们不再是现代数据平台的中心部分。现代数据操作包括以数据湖为中心的各种数据计算、存储、流、消息传递、编配和数据API技术。有些消费路径完全绕过了数据仓库，由于数据科学和ML的便利性，这一趋势越来越流行。热门的新术语是Lakehouse架构，它以其更纯粹的表达方式完全废除了传统仓库，或将其降级为边缘角色。有关描述基于Microsoft数据技术的实现的博客文章，请参阅此处。
2. 架构的这种转变与数据在企业中的作用的扩大密切相关。大型组织正在看到数据团队的激增和数据消费者无处不在的本质。每个人都需要数据，而几乎每个人都在生产数据。这反过来又导致数据生产者和消费者之间的数据流复杂性增加，这是由于复杂数据谱系的演变和数据转换的中间跳跃。
3. 不断发展的隐私要求决定了数据必须如何处理以及数据可以用于什么目的。私营公司如何处理数据恰好受到了相当大的监管审查，比十年前更是如此。

这些趋势共同对需要持续跟踪数据资产的元数据类型产生了巨大影响。以下是一些例子：

• -外键关系曾经是为数据仓库构建的模型的主要内容。当消费主要转移到存储服务或文件格式本身不知道什么是外键的数据湖时，会发生什么？我们如何强制执行资产之间的关系基数（1–1、1–任意项等）？分析空间中一个非常常见的错误来源是在连接资产的过程中做出的错误假设。
• -传统的数据模型不包括与操作相关的元数据，如SLA、事件管理联系人、归档策略（数据何时从资产中过期）、保留元数据（在资产中可以找到多少年的数据）。它们也没有包括数据的可信度、针对资产（或其上游来源）的数据质量监测器类型的信息或资产完整程度的概念（例如，在基于产品遥测构建的资产的情况下）。所有这些都是数据消费者需要考虑的重要问题，以建立衍生处理的操作依赖性——数据仓库确实没有针对这些问题进行优化，但它们是数据湖的关键用例。
• -关系始终是数据模型中捕捉到的一个关键方面，但用于生产资产的来源的沿袭和元数据却不是。然而，对来源的担忧对于确定资产是否可以用于特定用例至关重要。与十年前相比，资产是否出于数据主权的原因进行了地理分区，或者是否存在例外或差异（如GDPR所记录的）、以隐私为中心的分类等细节无疑更加令人担忧。

因此，尽管基本的宏观目标基本上保持不变——管理资产的演变，增强数据消费者对资产的日常发现和理解能力，但现在所需元数据的性质远比曾经适合实体关系图的内容广泛。运行现代合规数据平台所需的元数据广度的演变是如此深刻，以至于我们现在有了一类围绕数据目录和治理产品的新数据基础设施产品，包括微软自己的产品Azure Purview，并深化了与计算和存储服务的集成，以收集元数据。然而，在实现一个全面而可信的数据模型方面仍然存在一些挑战。

这有几个原因：

1. 对于SQL数据库或仓库，数据模型被视为代码工件，复杂的工具允许模型所有者保持模型和数据库的同步。工具可以很容易地从模型中推出更改，或者从数据库的实际状态中对模型进行逆向工程。因此，只要稍微执行一点部署过程，数据模型就可以得到信任。然而，正如前面所指出的，现代数据平台要复杂得多，它由各种计算、排队、存储等服务构建而成。与SQL不同的是，SQL主要是声明性的，现代的数据平台可以自由地使用过程代码，这很难解释。因此，推断血统等方面尤其具有挑战性。
2. 如上所述，在外键的情况下，底层存储系统可能不具有自动推断相关元数据所需的构造的概念。有几个这样的例子。例如，建立应该保存资产的不变量类型的正确性监视器可以由存储不可知的子系统来实现，甚至可以使用自定义库集成到管道中。
3. 无法可靠推断的内容必须基于开发人员注释进行验证，或者根据开发人员注释生成，这是无法绕过的。我们无法推断但可以监控的一个例子是资产的SLA（最新的操作承诺时间，在此时间之前，资产应该用前一时间段的新数据更新）。它必须使用监视器进行声明和验证。然而，为了使元数据可信，我们必须确保监视器是自动生成的，并且不能绕过监视器的功能。另一个例子是元数据指示两个不同数据边界中的两个数据集在逻辑上相同，但由于数据主权要求而分离的情况。这最好通过确保消耗和产生数据资产的数据处理管道也进行类似的镜像来实现。

简言之，只有在元数据生成与这些资产的构建和监控方式密切相关的情况下，才能为数据模型实现准确、当前和可信的元数据（仔细想想，这与传统的SQL数据模型没有太大区别）。这通常也意味着将资产的构建方式限制在专门为维护具有可靠元数据的数据模型而设计的工具和服务上。

尽管存在这些挑战，但这些模型为数据的生产者和消费者提供了巨大的价值。除了上述好处外，还应考虑以下几点：

1. 避免资产冲突和重复以及数据孤岛出现的能力。（请参阅前面关于度量碎片的帖子）
2. 在低代码工具中利用元数据的能力。例如，查询工具可以利用允许隐藏联接复杂性的外键关系，或者可以在地理分区的数据集上进行抽象（考虑到数据主权）
3. 不仅可以基于SLA元数据自动验证数据契约和测量运行时违规，还可以利用沿袭元数据来抑制与同一根违规相关的警报。
4. 数据使用向导，该向导可以确定特定的数据资产是否可以支持数据用例。
5. 自动重述工具，当根数据固定时，可以跨所有权层无缝修复衍生数据。

还有更多。