The modern data warehouse architecture creates problems across many layers. Image courtesy of Chad Sanderson.

数据仓库是现代数据堆栈的基础，所以当我们看到 Convoy 数据负责人 Chad Sanderson 在 LinkedIn 上宣称“数据仓库坏了”时，它引起了我们的注意。

当然，Chad 指的不是技术，而是它的使用方式。

在他看来，数据质量和可用性问题源于传统的最佳实践，即在仓库中“转储”数据，然后对其进行操作和转换以满足业务需求。这与 Snowflake 和 Databricks 等提供商为确保其客户在存储和消费方面的效率（换句话说，节省资金和资源）所做的一般努力并不不一致。

无论您是否同意下面详述的 Chad 的方法，无可争议的是他的观点如何引发大量辩论。

“一个阵营生我的气，因为他们认为这不是什么新鲜事，它需要长期的手动流程和具有 30 年经验的数据架构师。另一个阵营生我的气，因为他们的现代数据堆栈从根本上不是这样设置的，这也不是他们构建数据产品的方式，”Chad 说。

我会让您自己决定“不可变数据仓库”（或主动与被动 ETL）是否适合您的数据团队。

无论哪种方式，我都强烈支持推动我们的行业向前发展，不仅需要对数据仓库和数据可观察性平台等技术的概述，还需要就如何部署它们进行坦诚的讨论和独特的视角。

我们会让乍得从这里拿走它。

不可变数据仓库如何结合规模和可用性

乍得桑德森的观点

现代数据堆栈有许多排列，但数据仓库是一个基础组件。过度简化：

• 数据通过被动管道（实际上只是 ETL 中的“E”）提取并转储到……
  
• 一个数据仓库，在它被处理和存储之前……
  
• 转换为数据消费者所需的格式……
  
• 特定用途，例如分析仪表板、机器学习模型或在 Salesforce 或 Google Analytics 等记录系统中的激活……
  
• 借助跨堆栈运行的技术或流程，例如数据可观察性、治理、发现和编目。
  

在深入探讨这种方法的挑战和建议的替代方案之前，值得探索一下我们是如何得出我们所定义的“现代数据堆栈”的。

我们是怎么来到这里的？

在数据的早期，在 Bill Inmon 等先驱者的带领下，最初的 ETL（提取、转换、加载）过程涉及从源中提取并在进入数据仓库之前对其进行转换。

许多企业今天仍然以这种方式运作。对于数据质量至关重要的大型公司，此过程涉及手动、密集的治理框架，数据工程师和嵌入不同领域的数据架构师之间紧密耦合，以便快速利用数据获得运营洞察力。

谷歌、Facebook 等科技巨头放弃了这一过程，开始将几乎所有内容都倾倒在数据仓库中。对于快速成长的初创公司来说，逻辑组织数据的投资回报率并没有这个更快、更具可扩展性的过程那么高。更不用说，加载（ELT 中的“L”）变得更容易集成到云中。

一路走来，流行的转换工具使仓库中的数据转换比以往任何时候都容易。模块化代码和显着减少的运行时间使 ETL 模型从根本上不那么痛苦……以至于流行的转换工具的使用从数据工程师扩展到数据消费者，如数据科学家和分析师。

似乎我们找到了一个新的最佳实践，我们正在走向事实上的标准化。如此之多，以至于提出替代方案会引起迅速而强烈的反应。

被动 ETL 或仓库转换的挑战

一旦数据进入数据仓库，严重依赖于转换数据的架构和流程存在几个问题。

• 第一个问题是数据消费者（分析师/数据科学家）和数据工程师之间产生的脱节，真正的鸿沟。
  

项目经理和数据工程师将在分析师的上游建立管道，分析师的任务是回答内部利益相关者提出的某些业务问题。不可避免地，分析师会发现数据并不能回答他们所有的问题，并且项目经理和数据工程师已经继续前进。

• 当分析师的反应是直接进入仓库并编写一个脆弱的 600 行 SQL 查询以获得他们的答案时，就会出现第二个挑战。或者，数据科学家可能会发现他们构建模型的唯一方法是从生产表中提取数据，这些生产表作为服务的实现细节运行。
  

生产表中的数据不适用于分析或机器学习。事实上，服务工程师经常明确声明不要对这些数据采取关键依赖关系，因为它可能随时发生变化。然而，我们的数据科学家需要完成他们的工作，所以无论如何他们都会这样做，当表格被修改时，一切都会在下游中断。

• 第三个挑战是，当您的数据仓库成为垃圾场时，它就会变成数据垃圾场。
  

Hadoop 时代的一项较早的 Forrester 研究发现，企业内 60% 到 73% 的所有数据未用于分析。希捷最近的一项研究发现，企业可用的数据中有 68% 未被使用。

结果，数据科学家和分析师花费了太多时间在过度处理的生产代码大海捞针中搜索上下文。作为数据工程师，除了数据质量，我们还需要强调数据的可用性。

如果您的用户无法在您当前的数据仓库中可靠地找到和利用他们需要的东西，那有什么意义呢？

另一种方法：引入不可变数据仓库

不可变数据仓库概念（也称为活动 ETL）认为，仓库应该是通过数据来表示现实世界，而不是乱七八糟的随机查询、损坏的管道和重复信息。

有五个核心支柱：

• #1 映射业务并分配所有者。为了让企业真正从他们拥有的大量数据中获得价值，团队需要退后一步，在通过代码定义实体和事件之前对他们的业务进行语义化建模，以用于明确的分析目的。这可以是一个迭代过程，从业务中最关键的元素开始。
  

实体关系图 (ERD) 是基于真实世界的业务图，而不是当今数据仓库或生产数据库中存在的图。它定义了关键实体、它们的关系（基数等）以及表明它们已经交互的真实世界动作。为每个实体和事件建立一个工程所有者。端到端自动化沿袭可以帮助建立 ERD 并使其可操作。

• #2 数据消费者预先定义他们的需求并创建合同。也许最有争议的租户是数据应该从业务需求中冒出来，而不是从非结构化管道中涓涓细流。不是数据分析师和科学家在仓库的尘土飞扬的货架上梳理，看看是否有足够接近他们需要的数据集，除非数据消费者首先直接请求和定义数据，否则不会有数据进入仓库。
  

没有业务问题、流程或驱动问题的数据进入仓库。一切都是为完成任务而设计的。

这个过程必须设计得简单，因为数据需求总是在变化，增加的摩擦将威胁采用。在 Convoy，实施新合同需要几分钟到几小时，而不是几天到几周。

接下来，是时候起草数据合同了，这是业务和工程主管之间关于事件/实体的架构应该是什么以及该资产最有效最需要的数据的协议。例如，现有的 inboundCall 事件可能缺少 OrderID，这使得很难将电话呼叫与已完成的订单联系起来。

SLA、SLI 和 SLO 是一种数据合同类型，您可以将其应用于这种变更管理和利益相关者对齐模型。

• #3 在活跃环境中同行评审的文档。同样，我们需要对投入生产的代码 (GitHub) 或 UX (Figma) 进行同行评审，数据资产也应该有一个等价物。但是，本次审查的正确抽象级别不是代码，而是语义。
  

该审查过程应该具有与 GitHub 拉取请求相同的结果——版本控制、相关方的签署等——所有这些都通过云处理。通过应用基于云的现代技术，我们可以加速旧流程，使其在增长最快的互联网业务中更加可行。

数据目录可以作为数据仓库定义前的表面，但挑战在于数据消费者要保持元数据最新，没有胡萝卜也没有大棒。对于使用 ELT 流程并完成模型返回并记录其工作的数据科学家的动机是什么？

• #4 数据通过管道传输到合同中定义的预先建模的仓库。转换发生在消费层的上游（最好是在服务中）。然后，工程师在他们的服务中实施数据合同。数据通过管道传输到数据仓库，理想情况下，元数据可以通过建模自动加入和分类。
  
• #5 重点放在防止数据丢失以及确保数据的可观察性、完整性、可用性和生命周期管理上。事务发件箱模式用于确保生产系统中的事件与数据仓库中的事件匹配，而日志和偏移处理模式（我们在 Convoy 广泛使用）可防止数据丢失。这两个系统一起确保数据以完整的完整性保存，因此不可变数据仓库是整个业务中发生的事情的直接表示和真实来源。
  

数据质量和可用性需要两种不同的心态。数据质量在很大程度上是一项技术挑战。想想“后端”工程。另一方面，数据可用性是一项“前端”工程挑战，需要用于创造出色客户体验的相同技能。最后，不可变数据仓库不适用于 PB 测量竞赛和大数据统计。弃用和维护与配置一样重要。

这种方法利用技术的优势来实现两全其美。传统方法的治理和业务驱动方法，具有与现代数据堆栈相关的速度和可扩展性。

不可变数据仓库的工作原理。像 API 一样处理数据。

The layers of an immutable data warehouse. Image courtesy of Chad Sanderson

让我们先回顾一下围绕不可变数据仓库的完整堆栈。

• 1. 描述层：与传统仓库不同，描述层将业务逻辑移至服务层之上，并将数据消费者置于驾驶座上。消费者能够提供他们的要求而无需技术技能，因为数据工程师是代码翻译的关键要求。这些合同可以保存在数据目录甚至通用文档存储库中。
  
• 2. 数据仓库：仓库主要用作“数据展示”和底层计算层。
  
• 3. 语义层：数据消费者构建经过验证并与业务共享的数据产品。语义层中的资产应该被定义、版本化、审查，然后通过 API 提供给应用层使用。
  
• 4. 应用层：这是使用数据完成某些业务功能的地方，例如实验、机器学习或分析。
  
• 5. 端到端支持：支持跨数据堆栈的数据操作的解决方案，例如数据可观察性、目录、测试、治理等。理想的情况是一旦数据进入仓库就拥有完美的、预先建模的、高度可靠的数据，但您仍然需要涵盖现实世界可能向您抛出的所有排列（并在流程超出范围时具有强制机制）。
  

不可变数据仓库本身是为流式设计的——从流式数据到批处理数据比反之更容易——因此由三种不同类型的 API 提供。

• 语义事件 API：此 API 用于作为公司核心构建块的语义真实世界服务级别事件，而不是来自前端应用程序的事件。例如，在 Convoy 的情况下，这可能是在创建货件或暂停货件时。来自现实世界的事件构建在服务代码中，而不是 SQL 查询中。
  
• CRUD 抽象 API：数据消费者不需要查看所有生产表，特别是当它们只是他们用来生成洞察力或权力决策的数据服务的实现细节时。相反，当更新生产表中数据资产的属性时，API 包装器或抽象层（例如 dbt）将公开对仓库中的数据消费者有意义的 CRUD 概念——例如，无论是否数据是新的或行量在预期的阈值内。
  
• 前端 API：已经有许多工具可以处理前端事件定义和发射，例如 Snowplow、Mixpanel 和 Amplitude。话虽如此，一些前端事件非常重要，团队需要能够使用长偏移管道来确保其交付和完整性。在某些情况下，前端事件对于机器学习工作流程至关重要，而“足够接近”的系统无法解决它。
  

随着事情的变化（也许一项服务需要变得很多），或者如果数据科学家心目中的模式与现实世界中发生的事情不相符，还需要一个位于仓库外部的映射层。

映射应该通过流式数据库在仓库上游或在仓库本身中处理。这一层是 BI 工程师将工程中的内容与数据消费者需要的内容相匹配的地方，可以自动化生成 Kimball 数据集市。

不可变数据仓库也面临挑战。以下是一些可能的解决方案。

我并不认为不可变数据仓库是灵丹妙药。与任何方法一样，它也有其优点和缺点，而且肯定不是每个组织都适用。

与数据网格和其他崇高的数据架构计划一样，不可变数据仓库是一种理想状态，很少成为现实。实现一个——或试图实现一个——是一个旅程，而不是一个目的地。

应该考虑和缓解的挑战是：

• 定义描述层的前期成本
  
• 处理没有明确所有权的实体
  
• 实施新方法以实现快速实验
  

虽然定义描述层是有成本的，但它可以通过软件大大加速，并通过优先考虑最重要的业务组件来迭代完成。

这需要包括数据工程师在内的协作设计工作，以防止数据质量责任在分布式数据消费者之间分散。如果你第一次没有做对也没关系，这是一个迭代过程。

处理没有明确所有权的实体可能是一个棘手的治理问题（并且经常困扰数据网格支持者）。在业务方面对这些问题进行分类通常不在数据团队的职权范围内。

如果有一个跨多个团队的核心业务概念是由单体而不是微服务生成的，那么最好的前进方式是建立一个强大的审查系统和一个专门的团队随时待命以进行更改。

仍然可以允许数据工程师进行实验并给予灵活性，而不会限制工作流程。一种方法是通过单独的暂存层。但是，不应允许下游或跨外部团队使用来自这些暂存区域的 API 数据。

关键是，当你从实验转移到生产或让边境团队可以访问时，它必须经过相同的审查过程。就像在软件工程中一样，你不能仅仅因为你想更快地移动而在没有审查过程的情况下进行代码更改。

祝您在数据质量之旅中好运

现代数据堆栈有许多排列，作为一个行业，我们仍在经历一个实验阶段，以了解如何最好地铺设我们的数据基础设施。

很明显，我们正在迅速迈向未来，在这个未来，更多的关键任务、面向外部和复杂的产品都由数据仓库“提供支持”。

无论选择何种方法，这都要求我们作为数据专业人士提高标准，并加倍努力以实现可靠、可扩展、可用的数据。无论类型如何，数据质量都必须是所有数据仓库的核心。

从我的角度来看，底线是：当你建立在一个巨大的、无定形的基础上时，东西会破裂并且很难找到。当你找到它时，很难弄清楚那个“东西”到底是什么。

不可变与否，也许是我们尝试新事物的时候了。