本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：translation-feedback@oreilly.com
Tuesday, May 31, 13:23
洛根和丹娜（数据架构师）站在大会议室外，在每周状态会议后闲聊。
"我们如何在这个新架构中处理分析数据？"达纳问道。"我们正在将数据库拆分成小部分，但我们要将所有数据重新粘合在一起，用于报告和分析。我们正在努力实施的改进措施之一是更好地进行预测规划，这意味着我们将使用更多的数据科学和统计数据来做出更具战略性的决策。我们现在有一个团队在考虑分析数据，我们需要系统的一部分来满足这一需求。我们是否要建立一个数据仓库？"
洛根说："我们研究过创建一个数据仓库，虽然它解决了整合问题，但对我们来说有一堆问题。
本书的大部分内容都与如何分析现有架构风格 （如微服务）中的权衡有关。不过，我们强调的技术也可用于理解软件开发生态系统中出现的全新功能；Data Mesh就是一个很好的例子。
在现代架构中，分析数据和操作数据的用途大相径庭（参见"数据在架构中的重要性"）；本书的大部分内容都涉及与操作数据相关的困难权衡。当客户机/服务器系统在大型企业中开始流行并变得足够强大时，架构师和数据库管理员就开始寻找一种可以进行专门查询的解决方案。
操作数据和分析数据之间的分裂几乎不是一个新问题--数据的基本不同用途与数据的存在时间一样长。随着架构风格的出现和演变，处理数据的方法也发生了类似的变化和演变。
在早期的软件开发时代（例如 大型计算机或早期的个人计算机），应用程序是单体的，包括同一物理系统上的代码和数据。考虑到我们之前所介绍的情况，跨不同物理系统的事务协调变得具有挑战性也就不足为奇了。随着对数据的要求越来越高，再加上办公室局域网的出现，，这就导致了客户机/服务器应用程序的兴起。在客户机/服务器应用程序中，功能强大的数据库服务器在网络上运行，而桌面应用程序则在本地计算机上运行，通过网络访问数据。应用和数据处理的分离使交易管理、协调和其他众多优势得以更好地实现，包括开始将历史数据用于分析等新用途的能力。
架构师们很早就尝试用数据仓库模式提供可查询的分析数据。他们试图解决的基本问题直指业务数据和分析数据分离的核心：其中一种数据的格式和模式不一定适合（甚至不允许使用）另一种数据。例如，许多分析问题需要进行聚合和计算，而这对关系数据库来说是昂贵的操作，尤其是那些已经在沉重的事务负载下运行的数据库。
发展起来的数据仓库模式略有不同，主要基于供应商提供的产品和功能。不过，这种模式有许多共同特点。基本假设是，业务数据存储在关系数据库中，可通过 Network+ 直接访问。以下是数据仓库模式的主要特征：
由于业务数据存在于各个数据库中，因此该模式的一部分指定了一种机制，用于将数据提取到另一个（海量）数据存储区，即该模式的 "仓库 "部分。在企业的所有不同数据库中进行查询以创建报告并不现实，因此将数据提取到仓库中仅用于分析目的。
通常情况下，运行模式与报告所需的模式并不一致。例如，操作系统需要围绕事务构建模式和行为，而分析系统很少使用 OLTP 数据（见第 1 章），但通常会处理大量数据，用于报告、聚合等。因此，大多数数据仓库利用星型模式来实现维度建模，将不同格式的操作系统数据转换为仓库模式。为了提高速度和简化程度，仓库设计人员会对数据进行去规范化处理，以提高性能和简化查询。
由于业务数据存在于各个系统中，因此仓库必须建立定期提取数据、转换数据并将其放入仓库的机制。设计人员要么使用复制等内置关系数据库机制，要么使用专门工具建立从原始模式到仓库模式的转换器。当然，对操作系统模式的任何更改都必须复制到转换后的模式中，这给更改协调带来了 ...