原文：
towardsdatascience.com/data-warehouse-redefined-f65609454a01
好吧，我再次使用了“重新定义”——我在关于重新定义数据工程的需求的文章中也这样做过。哦，我的天，他还要重新定义什么，你可能想知道。
嗯，我认为今天的数据架构中有许多事情值得仔细研究。但批判性地审视当前数据仓库定义的动机源于我的一位读者的一个问题。
我写了一个关于数据网格挑战和解决方案的三部分系列文章。文章中描述的改进后的数据网格作为数据收集方法（如数据仓库、传统、现代以及数据湖/湖屋等变体）的替代架构。然而，我强调我们仍然需要数据仓库作为向数据网格贡献信息的众多应用程序之一。
现在的问题是“我真的需要两倍的工程师来设置新的（数据网格）和旧的（数据仓库）吗？”。
为什么需要重新定义？
我认为这值得一个明确的答案，而答案的出现又带来了重新定义数据仓库的需求。
为了立即明确，我并不是轻率地说这番话。我甚至在我的咨询公司的基础上建立起了数据仓库概念的思想。因此，承认对我的客户和我自己来说，这是实现公司真正通用数据供应的错误方法并不容易。让我解释一下为什么我认为数据仓库并没有完全实现这一承诺。
让我们回顾一下起点，当时比尔·英蒙（Bill Inmon）提出了数据仓库的想法。他想要实现的核心目标是：
-
（重新）整合由运营应用程序在孤立数据库中存储业务数据而产生的信息孤岛。
-
适当分离分析工作负载和运营工作负载，以避免不必要的相互干扰，并能够完整跟踪数据历史，这在运营系统中是不可能的。
因此，将运营数据卸载到单独的系统以重新整合孤岛化的数据存储，同时减轻运营数据库的分析工作负载似乎是合理且合乎逻辑的。
他试图通过这种方法解决这两个主要问题：
-
单一应用程序或共享集成数据库的几个应用程序无法实现公司所有处理需求的不可能性。
-
当时的数据库系统（主要是关系型系统）在处理运营和分析工作负载方面存在技术上的无能。
后一个问题，因为它主要是技术性的，现在已经解决。今天，我们有工具和数据库，允许混合操作和分析工作负载——无论是使用单一的统一实时（数据）平台（URP）还是使用如数据网格这样的分布式架构，提供丰富的数据工具集，今天被称为现代数据堆栈。因此，出于这个技术原因建立数据仓库不再合理。
不幸的是，前一个问题尚未得到解决。我们仍然没有所有这些企业应用创建的所有信息的完全集成版本。即使领域驱动设计（DDD）也没有帮助我们摆脱信息孤岛的出现。信息整合在操作世界中仍然是一个遗憾的后续考虑。但如果操作平面未能妥善处理整合问题，实际上只是将问题推迟到了数据平面。
信息整合仍然需要
我们仍然需要整合孤立的信息，数据仓库是能够在操作系统下游完成这一任务的一种方法。但是，认为一个在数据平面运行的单个中心概念或架构能够完全弥补操作平面中遗漏的部分是过于天真的。
即使是维度数据仓库之父拉尔夫·金博尔也说过，企业数据仓库只能作为物理上独立的数据集市，通过数据仓库总线架构相互连接来实现。
我完全同意，这个问题只能通过高度分布式的方法来解决。然而，适应型数据网格似乎是这个问题的更好架构概念。即使随着现代企业数据建模的采用，整合任务大大简化，中央业务部门如控制、风险管理、财务或营销仍然需要整合。
这些中央业务部门通常需要在抽象业务对象上进行跨领域聚合。这些对象不能直接从单个特定领域的数据库产品中获得。因此，为几个消费者实现这种整合逻辑一次是有意义的。
由各自的银行产品系统创建的四种不同数据产品的示例——图片由作者提供
作为说明性的例子，让我们以一家为顾客提供不同产品类型的不同运营系统的商业银行的典型情况为例。在简单的例子中，我们有四个不同的银行产品系统，每个系统都创建了一个独立的数据产品，以在数据网格中提供。每种数据产品类型属于不同的业务领域——比如说存款、活期账户、定期贷款和抵押贷款。例如，控制和风险管理部门都需要分析所有产品类型的 KPI，汇总到一个源系统不提供的抽象产品类别和客户类型。因此，我们有两个部门都需要将源系统特定的产品属性映射到一个整体有效的产品类别，将其与客户数据结合，并对所有四种产品类型进行汇总。
将数据仓库简化为集成和转换
数据仓库可以为多个消费者实施跨域集成和转换服务。它们的职能本质上可以简化为创建专门的数据产品，以实现对其他孤立数据存储的集成视图。实际上，在大公司中，我们已经有几个或多或少相互连接的数据仓库。这是因为在大公司中，为所有企业数据需求创建一个单一的数据存储实际上是不可能的。就像不可能为所有企业处理需求创建一个单一的应用程序一样。
我们可以将数据仓库重新定义为纯集成和转换应用程序，或者定义为这类应用程序和服务的平面。在这种配置下，它将不再作为真理的唯一版本或所有企业级信息的单一集中数据存储。它将作为众多应用程序中的一个，以满足中央业务部门的具体需求。平面上的每个这些应用程序都应该向一个适应性的数据网格贡献数据产品，以实现通用数据供应。
解构数据仓库
除了集成服务之外，数据仓库通常还提供针对其他分析或操作消费者应用程序（BI、报告、AI/ML 应用程序）的通用查询服务。这种数据库功能通常是数据仓库本身的一部分。但它也可以分布到其他更专业的服务应用程序中，这些应用程序通过数据网格接收数据。
通过创建数据产品并将它们输入到数据网格中，我们还可以高效地向不需要此类查询功能但只想直接以批量或流的形式消费数据的消费者应用提供数据。这些消费者应用可以是操作性的，也可以是分析性的，这意味着这种方法弥合了操作和分析平面之间的巨大鸿沟。
认为数据质量可以被重建或注入到下游的运营系统中这种天真想法，最终也应该被送进坟墓。这就像汽车制造商相信其生产过程中的质量问题可以在下游的质量保证中得到纠正一样。经常引用的奖牌架构就是这种误解的标志。如果这种想法有任何适用性，那也仅限于监管报告的需求。在数据产品创建后的“质量提升”只能是对上游信息架构质量低下的权宜之计。必须从源头解决，因为任何后续的修复都会造成不成比例的大量工作。
数据仓库解耦 – 图片由作者提供
我们真正在做的是将单体数据仓库架构拆分为独立的、独立的服务，并通过数据网格将它们相互连接。提取和数据质量改进需要转移到创建数据产品的业务领域源应用程序。集成和转换仍然发生在数据仓库平面内，但重要的是要记住，业务逻辑的应用应由中央业务部门管理，而不是数据团队。数据团队是数据网格的维护者。然而，重新定义的数据仓库将由中央业务领域通过使用数据网格的服务来构建。
这种减少的功能可能不再有资格被称为数据仓库——毕竟，它更多的是数据集成和转换应用的概念平面（如果你喜欢，可以称之为协调管道）。由于我在为架构组件发明吸引人的名称方面毫无天赋，我将它留在了数据仓库的重新定义上。
在一个由分布式服务共同工作以满足整体业务需求的世界里，集中管理数据仓库的想法是向后看的。无论是向现代数据仓库（MDW）的演变，还是数据湖屋，无论是在本地还是在云端，都无法完全实现通用数据供应的承诺。
这些源自传统数据仓库思维的中心化数据收集方法正越来越多地转变为新的、庞大的数据巨兽。它们声称可以集中管理与数据相关的所有事物，但我们不应该走这条路。
虽然高度集成的应用程序可能适用于小型敏捷公司，但我们无法用这样的单体系统或架构来满足大型企业的多样化数据需求。我们需要将它们分解成更小的、解耦的组件，并通过网络协同工作。
在处理平面，我们使用众所周知的分布式微服务架构。在数据平面，通过数据产品互联处理平面中的应用程序和服务的适配数据网格比传统的数据仓库更适合这项任务。
因此，让我们重新定义数据仓库，将其简化为一个数据集成和转换的概念平面，该平面创建的数据产品是为了满足跨领域需求而设计的纯数据结构——请参阅我的文章 “将您的数据作为产品交付，而不是作为应用程序”，以了解我所说的纯数据结构是什么意思。
如果您觉得这个信息有用，请考虑点赞。我很乐意收到您的反馈，包括您的意见和问题。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
