企业数据仓库（EDW）是一个用于存放来自整个组织内各系统的结构化、可随时用于分析的数据的中央存储库。预计到 2035 年规模将突破 $53 billion，日益增长的 EDW 市场必将持久存在。然而，EDW 的价值完全取决于向其馈送的数据。您可以在云基础设施、建模工具和商业智能（BI）管理平台上投入巨资，但如果底层数据过时或不完整，每一个下游决策都会继承这些缺陷。您围绕 EDW 构建的架构、监管合规控制和数据移动层，决定了它对商家的价值。

下面，我们将解释什么是企业数据仓库，什么是构建良好的数据仓库，以及如何将数据移动作为一个首要问题来考虑。

要点

• 现代 EDW 为商业智能、财务报告和机器学习工作负载提供由结构化且随时可用于分析的数据组成的、受监管制的集中式存储库。

• 监管合规控制，包括基于角色的访问控制、列级掩码、审计日志记录和数据血缘，决定了团队是否信任并使用该仓库。

• 数据移动层是很多 EDW 项目失败的地方，而原生来源连接器能保持管道运行，同时没有持续的维护负担。

什么是企业数据仓库？

企业数据仓库（EDW）是一个集中式数据存储库，为商业智能、财务报告以及越来越多的机器学习模型背后的特征库和训练数据集提供支持。

起初，EDW 是为生成报告而构建的。如今，它们已成为人工智能（AI）系统依赖的受管基础，这就提高了对数据质量、一致性和新鲜度的要求。

企业数据仓库是如何工作的？

在较高层面上，EDW 提取来自整个商家的各种数据，将其标准化并使其可用。该过程通常分为三个阶段。

这就是企业数据仓库的工作原理。

摄取

数据从源系统（例如支付平台、客户关系管理（CRM）系统、企业资源规划（ERP）系统和产品数据库）流入单个层。此时，它仍然是原始的：模式不同、时间戳可能冲突且缺失值不一致。

模式

这就是原始数据变得有用的地方。团队使用转换工具（通常是 dbt）对原始数据进行清理、合并，并将原始数据重构成可靠的数据集。

两种常见的建模方法是：

• 星型模式： 一个中央事实表（例如订单）连接到维度表（客户、产品、日期）。它简单、查询速度快，广泛用于报告。

• 雪花模式： 星型模式的更标准化版本，其中维度被分解为更小的相关表。这减少了冗余，但也可能增加查询难度。

服务

然后将清洗后的建模数据提供给下游用户使用。分析师使用结构化查询语言（SQL）对其进行查询，管理平台会自动更新，业务团队依赖于一致的指标。

现代企业数据仓库运行于何种架构之上？

大多数现代 EDW 都是基于云的，并且建立在一个核心原则之上：计算与存储分离。这让团队可以独立于数据量来扩展处理能力。

另一个重大转变是从提取、转换、加载（ETL）向提取、加载、转换（ELT）发展。不同于在加载之前转换数据，ELT 首先将原始数据加载到仓库中，并使用 SQL 在其中进行转换。随着商家需求的变化，这使得管道更容易调整。

设计精良的 EDW 也会具有一些共同特征：

• 为并发而隔离计算： 从财务报告到数据科学的不同工作负载可同时运行，而不会争抢资源。

• 分层数据架构： 将原始数据、中间转换和可随时用于生产的模型清楚分开，确保可追溯并易于调试。

• 支持多种用例： 一个平台可以服务于 BI、分析、机器学习和商业用例，不会出现重复。

是什么让企业数据仓库变得可靠？

只有得到人们的信任，EDW 才是有价值的。监管合规和安全控制可以防止指标纠纷，降低监管合规风险，并防止敏感数据落入不法分子手中。

下面是监管合规和安全控制让企业数据仓库具备企业级水准的方式：

• 基于角色的访问控制（RBAC）： 权限按角色分配，确保用户仅能看到他们需要的数据。

• 列级掩码： 敏感字段，如税号、薪水或敏感的客户数据等，会根据用户访问权限隐藏或词元化。

• 审计日志： 每个查询都可以被追踪，这对于监管合规至关重要（例如 Service Organization Control 2 或 PCI DSS，具体取决于您的数据类型）。当出现指标纠纷时，审计日志让您能够准确追踪报告建立在哪个版本的数据上。

• 数据血缘： 团队可以将任何指标追溯至其来源，这极大地提高了调试效率。

• 一致的指标定义： 共享的语义层可防止不同团队以不同方式计算同一指标。

如何在进行现代化改造之前审计企业数据仓库的准备情况？

许多 EDW 现代化改造项目失败的原因是团队行动过快，不了解当前的状况。结构化审计有助于避免这种情况。

以下是需关注的要点：

• 盘点您的数据源和所有者： 识别将数据输入当前数据仓库或手动报告的每个系统、其所有者是谁以及它的可靠性如何。

• 映射您当前的障碍： 寻找手动工作负载、脆弱的数据管道和反复出现的故障。

• 评估数据质量和数据血缘： 检查重复记录、缺失的外键（链接到其他表中列的数据库列）、格式不一致的字段，以及仅存在于未记录的 SQL 脚本中或存在于某人脑海中而非系统中的转换。

• 确认平台要求： 确定您需要的查询并发数、预期的数据量，以及您是否需要实时或近乎实时的刷新。

• 优先考虑高影响力的切入点： 识别具有最高业务价值和最纯净源数据的报告工作流，并优先向这些方向构建。

数据移动对企业数据仓库成败有何影响？

数据移动通常决定了企业数据仓库的成功。构建自定义 ETL 连接器通常比团队预期的更复杂、更脆弱。数据移动层决定了您的 EDW 是否真正可用。

常见故障点包括：

• 破坏集成而没有任何警告的 API 更改

• 过期的凭据和身份验证更新

• 使用高峰期出现的意外速率限制

• 出现故障而没有提醒任何人的管道

这些问题可能会使管理平台上布满过时或不正确的数据，从而破坏整个商家的信心。

如果是高价值的数据源（如支付），影响就更大了。不一致的数据会同时影响财务、运营和产品团队。

对于使用 Stripe 处理支付、订阅、退款、争议和提现的组织而言，Stripe 通常是一个高容量、高价值的数据源。Stripe Data Pipeline 作为无代码连接器直接处理这个问题。

具体如下：

• 支持的目的地： Snowflake、Amazon Redshift、Databricks 等。

• 安全状态： Stripe Data Pipeline 不需要第三方 ETL 服务，这就减少了对包含金融交易和客户信息的数据的暴露。

• 维护负担： 没有要构建或维护的自定义连接器。当 Stripe 的 API 发生更改时，管道会在 Stripe 端进行调整，而不是在您这一端。