5个数据建模不良的迹象
云时代的常见挑战
随着云技术的扩展和过去十年中存储成本的降低，许多组织积累了比以往任何时候都更大量的数据。许多云数据仓库提供商（ AWS，GCP，Azure）提供的按需付费模式降低了需要前期资本资源和数字基础设施考虑的需求。
好消息是，这最终使得大多数组织更容易接触数据科学。
坏消息是，数据湖越来越像数据沼泽。
什么是数据建模？以及它面临的挑战是什么？
对于数据工程师来说，向高层管理层传达良好建模生态系统的价值通常很困难。这是因为股东所看到的只是呈现的 BI 工具和预测模型。然而，建模不良的数据从数据治理的角度给分析团队带来了重大挫折。这必然会减慢工作流程，引入重复性任务，降低报告准确性，以及许多其他负面影响。
“良好建模”的定义是一个独立的话题。但是您可以通过以下概念来考虑您的数据仓库：
- 存在一种明确的模式，说明如何查找与业务实体相关的数据表。
- 使用有意的/已知的建模技术，例如维度模型、实体关系模型、数据保险库等。
- 表和字段命名约定一致，有良好的文档记录，具有业务价值。
还应注意到，数据建模是一种全面的、多系统的方法。它始于您的 OLTP（在线事务处理）系统，这是记录数据的初始位置。以下是一些示例：
- 像 Salesforce 这样的 CRM 系统
- 像 Stripe 这样的销售点系统
- 像亚马逊这样的电子商务平台
理想情况下，当通过源系统收集数据时，您的数据应标准化为第三正常形式。然后将其摄入分析环境，也就是 OLAP（在线分析处理）系统，应用分析建模技术。在本文的上下文中，OLAP 系统与云数据仓库是同义词。但是，OLAP 系统也可以包括独立托管的工具，如 SQL Server、MySQL 或 PostgreSQL。
虽然数据分析师和数据科学家只与 OLAP 系统互动，但组织的数据建模策略需要考虑到 OLTP 和 OLAP 两方面，以实现可持续性。
以下是 5 个关键迹象，说明您的分析环境建模不良。
1.) 必须具备部落知识才能了解数据存储位置
为了让新分析师在被聘用时成功，他们需要明确的路线图，了解数据仓库中可用的数据、其来源以及其业务上下文。然而，数据建模不良的团队经常难以帮助新员工入职，不理解为什么新员工需要很长时间才能回答基本的业务问题。如果没有适当的指导，分析团队可能会经历高离职率，因为新成员没有得到成功所需的工具。
数据分析师和数据科学家应专注于解决业务问题，而不是浪费时间查找业务实体位于何处。团队越快熟悉可用的数据，就越能快速完成仪表板和预测模型。这最终提高了团队的生产力。
如果只有少数分析师知道如何回答基本的业务问题，那就是一个问题。这种孤立的方法不可扩展，只会限制团队能够解决的问题数量。
2.) 不同的分析师为相同的指标产生不同的结果
如果没有单一的真相来源，不同的团队成员很容易用不同的方法计算同一指标。例如，收入如何定义？用哪些表格来计算？需要有明确的路径来定义业务逻辑，这一切都始于一个有意识的数据模型。
我曾在环境中工作过，其中有三个不同的表代表了同一业务实体，它们都使用了不同的 SQL 逻辑来得到类似但不完全相同的记录输出。将这种情况与管理不善的报告请求队列相结合，你就会发现两个不同的分析师用不同的结果回答同一个问题。这不仅会导致利益相关者失去对数据的信任，还需要在团队之间进行繁琐且不必要的调和工作。
3.) 团队需要重用冗余的代码块进行业务逻辑
我见过一些团队有一个 SQL CASE 语句的 Google 表格，概述了特定的业务指标。它们的长度很长，很难读取。虽然它试图在团队之间提供一致性，但这样做的问题是它违反了组织内的 DRY（不要重复自己）原则。
对于许多遇到此类问题的团队来说，使用像 DBT 这样的转换工具允许分析工程师在一个地方定义业务逻辑，然后让分析师在许多地方引用它。
想想以下示例–如果你是一家电子商务公司，有一种复杂的方法来计算页面浏览量（这是可以的），为什么要在 BI 工具中分发和复制该业务逻辑呢？这不仅在逻辑没有每次都被复制和粘贴的确切方式的情况下存在风险，而且是计算资源的浪费，这是大多数云提供商的最大开支。
为了解决这个问题，考虑映射需要进行的常见聚合和业务逻辑，每日运行一个转换作业（或根据需要频繁运行）并将其写入表格。然后让你的 BI 层在其上运行。
4.) 你的数据仓库性能不佳
如上所述，建模不良的数据会引入冗余。但是它还会创建不必要的复杂性。过度的计算资源是这种情况的副产品，所有云数据仓库在某个定价门槛上都有限制。一旦达到该限制，执行新查询可能会变得非常缓慢，有时甚至不可行。
任何数据工程师都会告诉你，只购买额外的资源不是这个问题的可持续解决方案。
长而复杂的查询不仅需要长时间才能执行，而且会消耗环境中可用的资源。考虑一个需要运行涉及 20 个连接的查询的示例。很少有情况是这是一个理想的解决方案，因为它说明了回答业务问题所需的数据并没有以易于访问的格式存储。这么多的连接可能会计算成本高昂，特别是当相关表格的数据量很大或者 ON 子句涉及多个列时。如果你正在实施维度模型，你的团队可能要考虑在这些情况下在你的数据库中创建一个新的事实表。
不同的云提供商以不同的方式测量资源，但它们都遵循使用一定数量的虚拟 CPU 的相同概念。例如，BigQuery 使用槽的概念，它实际上是用于执行查询的可用计算资源数量。按需定价的组织在任何给定时间都会收到 2,000 个槽，可以使用。因此，如果一个查询非常复杂并且占用了超过可用槽数量的数量，其他查询将在执行之前排队。
5.) 你经常需要在 SQL 中硬编码值
硬编码的值通常是缺少必要数据的明显迹象。在维度模型的上下文中，这通常意味着需要创建一个新的维度表来获取其他列。
Zach Quinn 写了一篇文章，非常好地概述了这个概念，演示了如何使用查找表来消除长的 CASE 语句。将这个例子放在维度模型的上下文中–假设你的组织需要进行大量的地理空间分析。你有一个客户维度表，给出了州缩写，但你想将其显示为完整的州名。你可以编写像这样的代码：
SELECTcustomer_id, customer_name, address, city, state AS state_abrevaition, CASE WHEN state = 'NJ' THEN 'New Jersey' WHEN state = 'NY' THEN 'New York' WHEN state = 'PA' THEN 'Pennsylvania' .............. END AS state_full_name, zip_codeFROM customer_dimension但是这种类型的CASE语句并不可持续。如果我们想更详细地改进此解决方案，我们需要将一个zip_code_dimension表连接到customer_dimension表。如下所示，您将看到zip_code_dimension将为我们提供更大的粒度以进行分析。表可能如下所示：
因此，有了这个新表，想象一下能够运行以下查询：
SELECTc.customer_id, c.customer_name, c.address, c.state AS state_abreviation, z.state_name, c.zip_code, z.county_name, z.country_name, z.timezone, z.lat, z.lngFROM customer_dimension cLEFT JOIN zip_code_dimension z ON c.zip_code = z.zip_code这不仅是一个更优雅和可读的查询，可以生成完整的州名称，而且可以回答更多问题。有了zip_code_dimension，我们现在可以添加该邮编的纬度和经度，以更清晰的格式创建地图可视化。此外，还有一些其他维度字段，如果我们想在输出中包含它们，可能需要编写数百行代码。
结论
如果您发现以上任何观点在您的环境中都是相关的，那么现在可能是全面审视数据管道并了解分析团队需要填补空白的地方的时候了。为了能够正确地对团队的数据进行建模，您需要能够概念化相关的业务实体，并以有助于组织内通用问题的方式进行组织。没有一种适合所有情况的方法，但所有团队成员都需要清楚，并以一致的方式创建。
