分析问题最终会追溯到其底层数据。重复的客户记录、无法在不同报告之间对齐的收入数据，以及相互矛盾的控制面板并不是可视化或查询问题；它们是架构问题，而数据规范化就是团队从源头修复它们的方式。

下面，我们将讨论数据规范化是如何运作的，规范化架构在实践中看起来是怎样的，以及分析和仓库团队在哪些地方遇到真正的权衡。

要点

• 数据规范化构建关系数据库，使每条信息仅存放在一个位置。这消除了重复和冲突的值。

• 分析团队可以通过首先构建规范化的核心实体表，然后再在上面叠加反规范化的报表，从而在流水线中应用规范化。

• 现代支付服务商可以将支付数据直接同步到商家的仓库中。这为规范化架构提供了一个完整且实时的数据源，而无需通过第三方连接器传输敏感的财务数据。

什么是数据规范化？

数据规范化是组织关系型数据库的过程，确保每条信息只存放在一个地方。您可以通过将数据拆分为相关的表格并通过键（key）将它们链接起来，而不是在多行中重复相同的值，从而实现这一目的。

目标是保持一致性。随着数据量的增长，这种结构上的纪律性是区分一个值得信赖的数据仓库和一个您需要不断审计的数据仓库的关键所在。

为什么数据规范化对于分析的准确性和治理很重要？

随着数据的增长，非规范化的数据会导致各种问题。

以下每一个都是架构本身的结构性缺陷：

• 更新异常 (Update anomalies)：当同一个事实出现在多行中时，就会发生这种异常。如果订阅方案的名称直接存储在每个账单行中，重命名该方案意味着更新数以千计的记录，并且遗漏其中哪怕一条也会产生差异。在规范化的模式中，方案名称存储在方案（plans）表中；账单（invoice）仅包含一个 plan_id。

• 插入异常 (Insertion anomalies)：当不记录无关的信息就无法记录某条信息时，就会发生这种情况。在一个存储客户和订单数据的扁平化表中，您无法在客户下单前添加新客户，这意味着在销售团队将潜在客户导入数据仓库时该表就会出现错误。

• 删除异常 (Deletion anomalies)：当删除特定记录时意外删除不相关的重要数据时，就会发生这种异常。如果从一张平面表中删除某客户的最后一笔订单，由于其联系信息没有单独存放，也会同时丢失。

有哪些主要规范形式？

范式是一系列日益严格的用于规定数据结构方式的规则。

利用数据规范化的团队需要理解包括第三范式 (3NF) 在内的各级范式，以便做出良好的架构决策。一个满足 3NF 的数据库通常被称为已“规范化”。

• 第一范式 (1NF)：要求每个列保持原子值——不能有列表、不能有逗号分隔的字符串，也不能有打包在单个字段中的数组。一个包含“衬衫,裤子,夹克”的产品列不符合 1NF。有三行分别包含一个 product_id 和一个 product_name 的记录则符合该范式。

• 第二范式 (2NF)：建立在 1NF 的基础上，要求每一个非主属性（非键列）完全依赖于整个主键，而不仅是主键的一部分。如果明细表使用“(order_id, product_id)”作为主键，但也存储了客户所在城市（仅依赖于 order_id），这就构成了部分依赖，并违反了 2NF。客户所在城市属于订单（orders）表。

• 第三范式 (3NF)：消除传递依赖，即非键列依赖于其他非键列而不是键本身。如果订单（orders）表同时存储了 zip_code 和 city，且 city 是由邮政编码而不是由订单决定的，那么这些字段属于单独的地理（geography）表。

• 巴斯-科德范式 (BCNF)：这是 3NF 的更严格版本，处理涉及重叠候选键的边缘情况。对于分析模型，达到 3NF 就足够了。

数据规范化在实践中是如何运作的？

了解规范化实际作用的最清晰方法是从一个有问题的表格开始并对其进行修复。以下是一个未规范化的订单表（order）的示例，并解释了它在规范化之后会发生什么。

未规范化的订单表

这个表格存在三个直接的问题。Ana 的电子邮箱出现了两次：如果在某一行更新它，就会产生冲突。产品名称和类别在每一行订单中重复，这意味着更改一个类别需要修改每一笔包含该类别的历史订单。而且在不附加订单的情况下，无法添加新客户或产品。

规范化后，您将获得三个表格：

• 客户 (Customers)：customer_id、name、email
  
• 产品 (Products)：product_id、name、category
  
• 订单 (Orders)：order_id、customer_id、product_id、qty、unit_price
  

Ana 的电子邮箱只存在一次。耳机的类别也只存在一次。订单通过 ID 引用这两者。一个结构化查询语言 (SQL) 的双表连接 SELECT 语句可以基于共同条件组合来自多个表格的数据：为一个在扩展时不会累积错误的架构付出的代价很小且一劳永逸。

数据规范化的常见权衡是什么？

虽然它有重要的好处，但规范化也可能给团队带来真实的成本。

这些权衡主要在以下三个方面：

• 查询复杂性：您规范化到各自表格中的每一个关系，都是以后需要编写的联合（join）操作。原来可以从一个扁平表中读取的一份报告，现在需要三个联合操作，而且这种认知负担对于直接在 SQL 中工作的分析师团队而言是会累积的。

• 前期的建模努力：设计规范化的模式需要对领域有足够的了解，以识别实体、它们的属性以及它们之间的关系。处于交付压力的团队常常跳过这一步，建立一些当前看似更容易但在以后变得昂贵的扁平结构。

• 读取性能：在非常庞大的数据表上，连接操作比扫描慢。现代数据仓库（例如 BigQuery、Snowflake、Redshift）的查询优化器能较好地处理连接操作，但反规范化结构在针对数十亿行数据的分析工作流中的原始查询速度上通常更有优势。

数据分析及仓库团队如何在工作流中应用数据规范化？

在实践中，分析团队在整个流水线中分层应用规范化。不同级别的结构满足不同的目的和关注点：数据完整性在规范化核心层处理，查询性能和分析师工作便利性在报告层处理。

具体如下：

• 暂存区 (Staging layer)：原始数据从源端几乎原样存放于此。在此阶段几乎不进行转换。目标仅仅是将数据完整、可查询地引入仓库，而不是对其进行建模。

• 规范化核心层 (Normalized core layer)：转换工具从暂存区生成规范化的实体表——一个用于客户，一个用于订阅，一个用于交易。这些表大约处于第三范式 (3NF)，并作为任何下游模型的真实数据源。

• 报告层 (Reporting layer)：在规范化核心之上，团队构建为速度和易用性设计的宽泛的逆规范化表格，以供商业智能 (BI) 工具（如 Tableau 或 Looker）使用。收入控制面板模型可能将五个规范化的表合并为一个事实表，该表可直接被 BI 工具读取。

Stripe 如何为下游规范化提供更干净、更可靠的数据支持

任何规范化模式的质量完全取决于输入数据的质量和完整性。过时或不完整的交易记录可能会造成即使再精心设计模式也无法弥补的对账缺口。

以下是支付服务商可以提供的内容：

• 同步：Stripe Data Pipeline 将 Stripe 数据（例如：扣款、客户、订阅、退款、争议、提现）直接移动到数据仓库或云存储目标，中间无需第三方连接器，也没有应用程序编程接口 (API) 的速率限制。

• 完整性：Stripe 通过同步所有 Stripe 数据、预建的财务报告和精选数据集来确保数据的完整性。

• 安全性：当团队通过第三方提取、转换和加载 (ETL) 连接器引向 Stripe 数据时，他们会将敏感的财务数据发送到额外供应商的基础设施中。Data Pipeline 直接处理传输，从而移除了中介，并在您的数据安全审查列表中消除了一家供应商。

Data Pipeline 并不取代完整的 ETL 平台。如果您要将 Stripe 数据与来自十几个其他来源的数据结合使用，您仍然需要转换工具。但该解决方案专为更好地同步您的 Stripe 数据而设计，优于第三方连接器，可确保您的财务数据能够可靠、安全且准确地同步。