作者：Barr Moses & Chad Sanderson
数据仓库是现代数据架构的基础，因此当我看到 Convoy 数据负责人Chad Sanderson在 LinkedIn 上宣称“数据仓库已经破损”时，引起了我的注意。
1. 谷歌网络安全证书 - 快速进入网络安全职业生涯。
2. 谷歌数据分析专业证书 - 提升你的数据分析能力
3. 谷歌 IT 支持专业证书 - 支持你的组织的 IT 需求
当然，Chad 并不是在谈论技术，而是谈论技术的使用方式。
他认为，数据质量和可用性问题源于传统最佳实践，即将数据“倾倒”到数据仓库中，然后再进行操作和转换，以适应业务需求。
这与像 Snowflake 和 Databricks 这样的供应商确保他们的客户在存储和消费中高效（换句话说，节省金钱和资源）的总体努力是一致的。
无论你是否同意 Chad 下面详细描述的方法，无法争辩的是他的观点引发了大量的讨论。
Chad 表示：“一个阵营对我感到愤怒，因为他们认为这没什么新意，需要长时间的手动过程和拥有 30 年经验的数据架构师。另一个阵营对我感到愤怒，因为他们的现代数据架构基本上不是这种设置，而且这不是他们构建数据产品的方式。”
我会让你自己决定“不可变数据仓库”（或主动与被动 ETL）是否是你们数据团队的正确路径。
不管怎样，我坚信推动我们行业前进不仅需要对技术的概述，还需要对如何部署它们的坦诚讨论和独特视角。
Chad Sanderson 的观点
现代数据架构有许多变体，但数据仓库是一个基础组件。简单来说：
-
数据通过被动管道（实际上只是 ETL 中的“E”）被提取并倾倒到…
-
一个数据仓库在处理和存储数据之后…
-
转换为数据消费者所需的格式，以便于…
-
特定用途如分析仪表盘、机器学习模型，或在 Salesforce 或 Google Analytics 等记录系统中的激活…
-
技术或流程如数据可观察性、治理、发现和目录等贯穿整个堆栈。
在深入探讨这种方法的挑战及建议的替代方案之前，值得探讨一下我们如何定义“现代数据堆栈”。
在数据的早期，像 Bill Inmon 这样的开创者们，最初的 ETL（提取、转换、加载）过程涉及从源头提取数据并在进入数据仓库之前进行转换。
许多企业今天仍然如此运作。对于数据质量至关重要的大公司而言，这一过程涉及手动、密集的治理框架，并且数据工程师与嵌入不同领域的数据架构师之间有紧密的联系，以便快速利用数据进行操作洞察。
像 Google、Facebook 等科技巨头抛弃了这一过程，开始将几乎所有数据都存入数据仓库。对于快速增长的初创公司而言，逻辑组织数据的投资回报率远不如这种更快、更具扩展性的过程。更不用说，加载（即 ELT 中的“L”）在云中集成变得更加容易。
在这个过程中，流行的转换工具使数据在仓库中的转换变得比以往任何时候都更容易。模块化代码和显著减少的运行时间使 ETL 模型变得极大地减轻了痛苦……以至于流行的转换工具的使用从数据工程师扩展到了数据消费者，如数据科学家和分析师。
我们似乎发现了一种新的最佳实践，并且正朝着事实上的标准化迈进。甚至提出替代方案也会引发迅速而强烈的反应。
现代数据仓库架构在多个层面上产生了问题。图片由 Chad Sanderson 提供。
依赖于在数据仓库中转换数据的架构和流程存在几个问题。
第一个问题是它在数据消费者（分析师/数据科学家）与数据工程师之间真正产生的断层，甚至是深渊。
项目经理和数据工程师将在分析师上游建立管道，分析师将负责回答内部利益相关者提出的某些业务问题。不可避免地，分析师会发现数据无法回答他们的所有问题，而项目经理和数据工程师已经离开了。
第二个挑战出现，当分析师的回应是直接进入仓库编写一个脆弱的 600 行 SQL 查询来获取答案。或者，数据科学家可能发现他们构建模型的唯一方式是从作为服务实现细节的生产表中提取数据。
生产表中的数据并非用于分析或机器学习。事实上，服务工程师通常明确表示不要对这些数据建立关键依赖，因为它随时可能发生变化。然而，我们的数据科学家需要完成工作，所以他们还是这样做了，当表被修改时，一切都会崩溃。
第三个挑战是当你的数据仓库成为一个垃圾场时，它就会变成数据废料场。
一项较早的 Forrester 研究发现，企业中 60%到 73%的数据未被用于分析。一项较新的 Seagate 研究发现，68%的企业可用数据未被利用。
结果是，数据科学家和分析师花费太多时间在过度处理的生产代码针毯中寻找上下文。作为数据工程师，我们需要强调数据可用性，除了数据质量之外。
如果你的用户不能可靠地在当前数据仓库中找到并利用他们需要的内容，那有什么意义呢？
不可变数据仓库概念（也称为主动 ETL）认为，仓库应通过数据表示现实世界，而不是随机查询、破碎管道和重复信息的混乱。
有五个核心支柱：
-
业务被映射并分配了负责人。为了使企业真正从其拥有的大量数据中获得价值，团队需要退后一步，在通过代码定义实体和事件之前，先对其业务进行语义建模，以便用于分析。这可以是一个迭代过程，从业务中最关键的元素开始。
实体关系图（ERD）是基于现实世界的业务地图，而不是今天存在于数据仓库或生产数据库中的内容。它定义了关键实体、它们之间的关系（基数等），以及表明它们已互动的现实世界行为。为每个实体和事件设立工程负责人。端到端的自动化血统可以帮助建立 ERD 并使其具有可操作性。
-
数据使用者提前定义他们的需求，合同就会被创建。最具争议的观点可能是数据应从业务需求中浮现，而不是从无结构的管道中流出。与其让数据分析师和科学家在你仓库的尘封架子上寻找足够接近他们需求的数据，不如在数据消费者直接请求并定义之前，数据不会进入仓库。
没有业务问题、流程或问题驱动的数据不会进入数据仓库。所有内容都是为了完成特定任务而量身定制的。
设计这个过程时必须简单，因为数据需求总在变化，增加的摩擦将威胁到采用。Convoy 的合同实施通常需要几分钟到几小时，而不是几天到几周。
接下来是制定数据合同，这是一项业务和工程领导之间关于事件/实体模式及其最有效所需数据的协议。例如，现有的 inboundCall 事件可能缺少 OrderID，这使得将电话与已完成的订单关联变得困难。
SLA、SLI 和 SLO 是你可以应用于这种变更管理和利益相关者对齐模型的数据合同之一。
-
在活跃环境中进行的同行评审文档。就像我们需要代码（GitHub）或用户体验（Figma）进行同行评审一样，数据资产也应有类似的评审机制。然而，这种评审的适当抽象层级不是代码，而是语义。
这个评审过程应有与 GitHub 拉取请求相同的结果——版本控制、相关方签字等——所有这些都通过云端处理。通过应用现代的云技术，我们可以加快旧流程，使它们更适合快速增长的互联网企业。
数据目录作为数据仓库定义表面的一部分是有用的，但挑战在于缺乏激励措施来促使数据使用者保持元数据的更新。使用 ELT 流程并完成模型的数据科学家有什么激励回去记录他们的工作？
-
数据按照合同中定义的预建模式输入数据仓库。转换在消费层之前的上游发生（理想情况下在服务中）。工程师然后在他们的服务中实施数据合同。数据被导入数据仓库，利用建模元数据可以理想地自动进行 JOIN 和分类。
-
强调防止数据丢失，并确保数据可观测性、完整性、可用性和生命周期管理。使用事务性外发模式以确保生产系统中的事件与数据仓库中的一致，而日志和偏移处理模式（我们在 Convoy 广泛使用的）则防止数据丢失。这两个系统共同确保数据完整保存，使得不可变数据仓库直接反映和真实呈现业务中的发生情况。
数据质量和可用性需要两种不同的思维方式。数据质量主要是技术挑战，类似于“后端”工程。另一方面，数据可用性是“前端”工程挑战，需要用来创建出色客户体验的相同技能。
最后，不可变数据仓库不适合用来进行 PB 级别的测量比赛或展示大数据统计。弃用和维护与配置同样重要。
这种方法利用了技术的优势，达到两全其美的效果。结合了传统方法的治理和业务驱动的优势以及现代数据堆栈相关的速度和可扩展性。
不可变数据仓库的层级。图片由 Chad Sanderson 提供
让我们从回顾不可变数据仓库的完整堆栈开始。
-
描述层： 与传统仓库不同，描述层将业务逻辑移动到服务层之上，让数据消费者掌控。消费者可以提出他们的需求，无需技术技能，因为数据工程师充当重要的需求到代码的翻译者。这些合同可以保存在数据目录或一般文档库中。
-
数据仓库： 仓库主要作为‘数据展示’和底层计算层。
-
语义层： 数据消费者构建经过验证并与业务共享的数据产品。语义层中的资产应定义、版本化、审查，然后通过 API 提供给应用层使用。
-
应用层： 这是数据用于完成某些业务功能的地方，例如实验、机器学习或分析。
-
端到端支持： 支持数据栈中数据操作的解决方案，如数据可观测性、目录、测试、治理等。理想情况下，一旦数据到达仓库，它应该是完美的、预建模的、高度可靠的，但你仍需覆盖现实世界可能带来的所有变数（并在流程超出界限时有执行机制）。
不可变数据仓库本身设计用于流处理——从流处理转到批处理比反向更容易——因此由三种不同类型的 API 提供支持。
图片由 Monte Carlo 提供。
-
语义事件 API： 这个 API 处理的是公司核心构建块的语义现实世界服务级事件，而不是来自前端应用程序的事件。例如，在 Convoy 的情况下，这可能是一个货物创建或解除保留的事件。来自现实世界的事件是在服务代码中构建的，而不是 SQL 查询。
-
CRUD 抽象 API： 数据消费者不需要看到所有生产表，特别是当这些表只是他们用来生成洞察或推动决策的数据服务的实现细节时。相反，当生产表中的数据资产属性被更新时，API 包装器或抽象层（例如 dbt）将展示对数据消费者有意义的 CRUD 概念——例如，数据是否是最新的，或者行量是否在预期范围内。
-
前端 API： 目前已有许多工具处理前端事件定义和发射，例如 Snowplow、Mixpanel 和 Amplitude。不过，一些前端事件的重要性足够高，以至于团队需要能够确保其交付和完整性，使用长偏移管道。在某些情况下，前端事件对机器学习工作流至关重要，“足够接近”的系统无法满足要求。
还需要有一个映射层，该层位于仓库之外，以应对事物的变化（例如，一个服务可能需要变成多个服务）或数据科学家心中的模式与现实世界中发生的情况不符的情况。映射应通过流数据库在仓库上游处理，或在仓库本身进行处理。这个层级是业务智能工程师将工程中产生的数据与数据消费者需求匹配的地方，这可以自动化以生成Kimball 数据集市。
我并不幻想不可变数据仓库是万灵药。像任何方法一样，它有其优缺点，并且肯定不适合所有组织。
像数据网格和其他雄心勃勃的数据架构倡议一样，不可变数据仓库是一种理想状态，而不常见于现实。实现它——或试图实现它——是一个过程，而不是一个终点。
应考虑和缓解的挑战包括：
-
定义描述层的前期成本
-
处理没有明确所有权的实体
-
实施新的方法以实现快速实验
虽然定义描述层有一定成本，但通过软件可以大大加快这一过程，并通过优先考虑最重要的业务组件进行迭代。
这需要一个协作设计的努力，涵盖数据工程师，以防止数据质量责任在分布式数据消费者之间扩散。如果第一次没有做到完美也没关系，这是一个迭代过程。
处理没有明确所有权的实体可能是一个棘手的治理问题（这也是数据网格倡导者经常面临的难题）。这些问题通常不在数据团队的业务范围之内。
如果有一个核心业务概念跨多个团队，并且由一个整体系统而不是微服务生成，那么前进的最佳方式是建立一个强大的审查系统，并有一个专门的团队待命进行更改。
数据工程师仍然可以进行实验，并获得灵活性而不限制工作流。一个实现这一点的方法是通过一个单独的暂存层。然而，这些暂存区域的 API 数据不应允许下游使用或跨外部团队使用。
关键是，当你从实验阶段转到生产阶段或使其对边界团队可访问时，它必须经过相同的审核过程。就像在软件工程中一样，你不能因为想要更快地推进就跳过审核过程进行代码更改。
现代数据堆栈有很多变体，作为一个行业，我们仍在经历实验阶段，以了解如何最好地建立我们的数据基础设施。
显而易见的是，我们正快速迈向一个未来，在这个未来中，更多关键任务、面向外部和复杂的产品将由数据仓库“提供支持”。
不管选择了哪种方法，这都需要我们作为数据专业人员提升标准，并加倍努力，确保数据的可靠性、可扩展性和可用性。数据质量必须是所有数据仓库的核心，无论其类型如何。
从我的角度看，底线是：当你建立在一个大而模糊的基础上时，东西容易坏，而且很难找到。而当你找到它时，可能很难准确地弄清楚那个“东西”是什么。
不管是否不可变，也许是时候尝试一些新的方法了。