随着大数据和数据湖的发展，数据建模似乎濒临灭亡。数据湖的开发者留下了大量数据沼泽，所以建模活动还是必须的。那么为什么仍然存在关于数据建模的问题呢？当然有各种各样的原因。有些问题至少已有 30 年历史，而最近人们更加认为使用云数据平台和分析数据架构的 ELT 方法所致。下面我们看看常见的阻碍数据建模的原因：

1.缺乏兴趣——企业真的不在乎

尽管 CIO 和 CEO 宣传“数据驱动”，但对于某些企业而言，数据的管理和利用并没有放在主要日程上，至少在高层是这样。这可能是可以理解的——并非每个企业都是“数据企业”；数据可能很重要，但仅在特定的独立领域内使用。有些组织从事采购和销售产品、提供法律顾问等行业，这并不是说他们不使用数据，而是，就目前而言即使使用 Excel 这种处理工具也满足使用了。

这可能发生在传统的组织中，可能发生在行业领军企业，也可能发生在技术初创企业中，在这些组织中，良好的数据是运营次要考虑因素。

解决方案：除非组织遭受足够多的数据相关痛苦，或者高级管理层选择支持战略性数据支持业务方法，否则数据建模以及治理和其他数据内容将主要在项目级别完成，以实现本地目标。

2.缺乏“全局”——没有全面的业务数据模型

数据建模通常被视为支持运营和分析产品开发的详细活动，从数据策略中删除，并且仅作为详细业务分析的一部分影响业务用户。但是，如果没有组织数据分布的高级地图，公司如何“数据驱动”，或者业务领域如何就数据所有权和责任达成一致？CDO 应该如何合理跨越多个应用程序或孤岛的数据，每个应用程序或孤岛都有相互独立的目标，成为“客户”的真正来源，或者了解特定数据流的原因？

90年代的情况是庞大、详细的 3NF“企业数据模型”，通常会运行到 100 或 1000 个实体。有时，这是为特定行业“现成”购买的，但随后需要在企业内部进行验证和调整。毫不奇怪，这些做法通常会陷入困境，被更紧迫的业务优先事项所取代。

解决方案：高级“业务数据建模”或“概念数据建模”的艺术已经存在超过 15 年。在经验丰富的从业者手中，对于中型企业或部门，应该可以在 1-3 个月内制作出良好的初稿，包括与企业所有部门的适当互动。通常，这可以与针对更多高级管理人员和员工的数据素养练习一起完成。随着从一个业务域更详细的数据工作引发对概念或全新概念的差异化的需求，可以改进和扩展这样的模型。

从“顶层”开始数据建模本身就非常有用，这是组织数据处理方法的基础。

3.数据作为应用程序完成或事后的想法

尽管许多应用程序产生并依赖于数据，但一直存在一种趋势，尤其是程序开发中，忽视数据建模，而不是应用程序设计中首要事情。这尤其体现在两个方面：

a) 使用第三方程序加速业务能力

许多应用程序都有自己的数据模型，该模型存在于“要么接受要么放弃”的基础上——您可以调整数据需求，以适应应用程序的数据模型。另一方面，其他应用程序积极鼓励业务用户进行本地定制，而不考虑数据模型是否真的有意义。

更广泛的集成问题可能会被搁置一旁，只要应用程序可以获取或交换数据以满足即时需求，也许是通过 API。一些应用程序甚至积极阻止在其自身环境之外提取数据。

解决方案：仅购买能够提供清晰数据模型和/或用于分析目的的精心构建的提取/数据共享选项的应用程序。建议将这部分作为采购必要条件，而不仅仅是“是/否”的回答。

b) 内部应用程序开发人员将数据建模视为事后的想法

这是企业内部的问题，开发人员通常在时间压力下工作，向内部或外部用户提供数据展示，这些用户对数据的存储方式没有直接兴趣。

解决方案：数据建模师应该是任何应用程序团队的核心部分。数据模型初稿通常应该是开始第一个真正的敏捷开发的先决条件。将产生的数据供下游使用，无论是出于操作目的还是分析目的，都应该是整体框架的一部分。这是数据驱动开发的最佳实践，数据网格模式强烈建议这种做法。

4.效率问题——建模只会减慢速度

模型就是这样——对现实世界的简化。在进行数据建模的情况下，通常会捕获一些隐式规则和关系，希望能够适应企业管理其现实世界交互的方式。

90 年代的关系建模被认为太慢了，识别实体、关系和属性的视图通常被业务变化和新数据源所取代，并且在捕获和传输在线事件时未能增加价值。随着组织从生产纯物理产品转向更多数字产品，定期更改成为常态，建模被视为阻碍或与保持最新所需相冲突。

解决方案：在在线应用程序中，半结构化“文档模型”方法提供了事件封装和可扩展模式的一定程度的灵活性。使用此类结构的最佳实践隐含地承认 3NF 分析的原则。分析数据平台转而提供对 JSON 等格式的本地支持，并具有不同程度的承诺。

在分析领域，Data Vault 方法通过归纳关键实体之间的关系、识别来源的多样性和高变化概率以及构建历史记录来提供敏捷性。

数据网格建议将大部分建模留给本地域——尽管它也提倡双时态建模方法，并谈到需要通用标准、一种新的建模方法，甚至一种语言来实现跨域的“可组合性”。

最终，为用例或应用构建正确类型的模型是成功的最佳秘诀，无论是文档、3NF、Data Vault 还是维度。虽然建模首先是一项逻辑活动，在底层数据平台中支持一系列具有良好性能的数据建模方法可以显着简化逻辑到物理的映射。

5.直接获取数据——数据沼泽遗留问题

虽然大数据运动是由互联网生成的庞大数据驱动的，但它也是对复杂性和数据变化率问题的回应。随着一些组织开始通过利用一切数据产生巨大收益，人们越来越不愿意丢弃任何数据。而且数据湖从业者认为，建模已经过时了。现在，当连接大型数据集或多表模型的数据很痛苦时，创建大量非规范化数据集的动力就非常强烈，通常会导致大量重复。对数据安全的忽视也进一步助长了这一趋势。

受此经验的影响，基于云的“现代数据堆栈”中出现的两个互补趋势出现了一些阻力：“廉价”存储和“转换(ELT) 模式”。

许多云数据平台参与者至少在某种程度上将存储与计算分开。云对象存储具有弹性且相对成本低。大量数据出于未知原因被保留，原始数据或建模不佳的数据被直接使用并且从未正确集成。虽然存储很便宜，但不断增长的数据量推高了按消费定价的计算，使平台提供商有鼓励客户不要在乎数据建模。

这笔费用不能完全回避——即使是廉价存储的数据有时也应该被删除，无论是为了减少混乱、降低滥用风险还是让地球更轻盈。

许多组织已经转向分层数据建模方法，其中第一层采用“原始”数据，无论是直接匹配 OLTP 系统上的表格，还是未经提炼的 JSON Web 和 IoT 日志。这种 ELT 模式并不新鲜，例如在 Teradata 等平台上的数据仓库模式和实施中很常见，已有十年或更长时间。理想的目标是原始层馈送到更多层，通常是反映某些规范模型（例如 3NF 或 Data Vault）的一致性层和针对最终用户的表示或交付层（通常按维度建模）。

将数据保存更长时间是有正当理由的——监管（证明你五年前所做的是合法的）、网络安全（攻击模式可以发展数月）、数据科学和长期分析（将原始数据转化为新功能）、或者仅仅是利用直接的内置历史从旧数据重构下游新产品的能力。与此相反的是隐私法规和违规风险，以及将半衰期短的数据保存太久的环境成本。最终，这又回到了数据所有权和“为什么”的问题上。

解决方案：仅仅因为可以忽视，并不意味着应该这样。具有可靠治理、良好的数据高级模型和可靠数据架构的组织可以受益于更便宜的存储和易于使用的平台支持的数据底座和转换模式。不急于对数据进行详细的过度建模并在其价值确定之前花费大量的计算周期和工程师时间进行转换可能是有价值的。

同样，让我们现实地看待数据的“半衰期”，尤其是原始数据——很少有法规要求保留超过 7 年的历史，而 ML 模型则更少，除非着眼于长期的事件。您的数据平台在捕获依赖关系和访问历史记录方面有多好？这有助于识别那些从未或很少使用的数据集，并避免因担心下游后果而保留数据。

总之…

就像数据中的许多好东西一样，良好的建模源于组织承诺、适当应用良好实践和模式的技能、精心设计的流程以及设计师的优秀技能。在大多数数据平台上，不进行建模是灾难性的。