在设计和构建正确的数据架构方面投入时间绝对至关重要。我在职业生涯早期就是这样吃了亏。当时我兴奋地开始构建我的解决方案，却忽略了关于架构设计和使用哪些产品的重要决策。项目进行到三个月时，我意识到架构无法支持一些必需的数据源。我们基本上不得不从头开始重新规划项目，采用另一种架构和不同的产品，浪费了大量的金钱和时间。没有正确的规划，终端用户将无法从您的解决方案中获得价值，他们会对错过的截止日期感到愤怒，您的公司面临落后于竞争对手的风险。
构建数据解决方案时，您需要一个经过深思熟虑的蓝图。这就是数据架构发挥作用的地方。数据架构定义了一种高层次的架构方法和概念，概述了一组要使用的技术，并说明了将用于构建您的数据解决方案以捕获大数据的数据流。决定数据架构可能非常具有挑战性，因为没有一种适合所有的架构。您不能翻阅书籍找到一套存货清单架构方法及其相应使用的产品。没有简单的流程图可供遵循，也没有决策树将引导您找到完美的架构。您的架构方法和所使用的技术将因客户而异，因用例而异。
高层次架构方法和概念的主要类型正是本书所关注的内容。它不是存货清单，但它会让您对它们的含义有所了解。虽然按照它们的特征将数据架构分为类型是有用的（我将在本书中做），但这与从一堆预定义的一刀切模板中进行选择并不相同。每个数据架构都是独特的，需要定制化的方法来满足特定的业务需求。
数据架构是指信息系统中数据的总体设计和组织。为数据架构预定义模板似乎是快速设置新系统的简单方法。然而，数据架构模板通常未能考虑到应用于其上的系统的具体要求和约束，这可能导致数据质量、系统性能和维护方面出现问题。此外，组织的需求和数据系统很可能会随着时间的推移而发生变化，需要对数据架构进行更新和调整。标准化模板可能不够灵活，无法适应这些变化，这可能会引入系统中的低效和限制。
本章简要介绍了本书将涵盖的主要类型：关系型数据仓库（Relational Data Warehouse)、数据湖(Data Lake)、现代数据仓库(Modern Data Warehouse)、数据编织(Data Fabric)、数据湖仓库(Data Lakehouse)和数据网格(Data Mesh)。每种类型将在本书后面的章节中详细介绍。
数据架构的演变
关系型数据库以结构化的方式存储数据，数据元素之间的关系由键来定义。数据通常组织成表格，每个表格由行和列组成。每行代表一个数据实例，而每列代表数据的特定属性。
关系型数据库旨在处理结构化数据，并提供了一个使用标准化语言称为结构化查询语言（SQL）创建、修改和查询数据的框架。关系模型最初由Edgar F. Codd在1970年首次提出，自70年代中期以来，它已成为数据库管理系统的主导模型。大多数操作应用程序需要永久存储数据，而关系型数据库是绝大多数情况下的首选工具。
在关系型数据库中，一致性和数据完整性至关重要，数据通常以一种称为写入时模式的方法进行组织。模式指的是定义表格、字段、数据类型和约束之间组织和关系的正式结构。它充当了存储和管理数据的蓝图，并确保数据库内部的一致性、完整性和高效组织。关系型数据库（以及关系型数据仓库）在数据进入之前需要一些前期工作。您必须创建数据库及其表格、字段和模式，然后编写代码将数据传输到数据库中。在写入时模式方法中，数据模式在数据写入或摄取到数据库时被定义和强制执行。数据必须遵循预定义的模式，包括数据类型、约束和关系，然后才能被存储。
相比之下，在读取时模式方法中，模式是在读取或访问数据时应用的，而不是在写入时。数据可以被摄入到存储系统中，而无需遵循严格的模式，结构只在查询或使用数据时定义。这种方法在存储非结构化或半结构化数据时提供了更大的灵活性，后面的章节将对此进行讨论。 在高层次上，数据架构提供了一个框架，以支持组织的需求，组织和管理数据。这涉及到定义数据的收集、存储、处理和访问方式，以及维护数据质量、安全性和隐私性。虽然数据架构可以采用许多不同的形式，但一些共同的元素包括：
- 数据存储
- 数据处理
- 数据访问
- 数据安全性和隐私
- 数据治理
总体而言，数据架构的主要目标是使组织能够有效管理和利用其数据资产，以支持其业务目标和决策过程。表2-1提供了我在本书中涵盖的数据架构特征的高级比较，可以作为您确定哪种架构最适合您的用例的起点。
关系型数据仓库
关系型数据库在数据存储领域是数十年的支柱。第一个在生产中使用的关系型数据仓库是由杰克·E·舍默博士于1979年在斯坦福大学开发的Teradata系统，他于同年成立了Teradata公司。1983年，富国银行安装了第一个Teradata系统，并将其用于分析金融数据。
随着组织生成的数据量越来越庞大，要在没有长时间延迟的情况下处理和分析这些数据变得越来越具有挑战性。关系型数据库的局限性导致了关系型数据仓库的发展，它们在20世纪80年代后期变得更加普及，大约是在关系型数据库出现之后的15年左右。关系型数据仓库（RDW）是一种专门用于数据仓库和业务智能应用的特定类型的关系型数据库，具有优化的查询性能和对大规模数据分析的支持。虽然关系型数据仓库和事务处理都使用关系模型来组织数据，但关系型数据仓库通常规模更大，并针对分析查询进行了优化。
关系型数据仓库具有计算引擎和存储。计算引擎是用于查询数据的处理能力。存储是关系存储，保存着通过表格、行和列结构化的数据。RDW的计算能力只能用于其关系存储-它们是绑定在一起的。
RDW的一些最重要的特性包括事务支持（确保数据被可靠和一致地处理）、审计跟踪（记录系统中对数据执行的所有活动）和模式强制执行（确保数据以预定义的方式组织和结构化）。
在20世纪70年代和80年代，组织使用关系型数据库进行订单录入和库存管理等运营应用。这些应用程序被称为在线事务处理（OLTP）系统。OLTP系统可以对数据库中的数据进行创建、读取、更新和删除更改，或CRUD操作。CRUD操作构成了数据架构中数据操作和管理的基础。它们对于设计和实施与数据交互的数据存储系统和用户界面至关重要。
CRUD操作需要应用程序快速响应，以免最终用户因数据更新所需时间过长而感到沮丧。您可以在运行中的关系型数据库上运行查询和生成报告，但这会使用大量资源，并可能与同时运行的其他CRUD操作冲突。这可能会导致一切变慢。
关系型数据仓库在一定程度上是为了解决这个问题而发明的。关系型数据库中的数据被复制到数据仓库中，用户可以对数据仓库而不是关系型数据库运行查询和报告。这样，他们就不会使承载关系型数据库的系统负担过重，也不会拖慢最终用户的应用程序。RDW还将来自多个应用程序的数据集中起来，以改善报告，如图2-1所示。
第4章将更详细地讨论RDW。
数据湖
数据湖是一个较新的概念，首次出现大约在2010年左右。您可以将数据湖视为一个被美化了的文件系统，与您笔记本电脑上的文件系统并没有太大区别。数据湖只是存储空间------与关系型数据仓库不同，它没有与之关联的计算引擎。幸运的是，有许多计算引擎可以与数据湖一起使用，因此数据湖的计算能力通常比关系型数据仓库便宜。另一个不同之处在于，虽然关系型数据仓库使用关系存储，数据湖使用对象存储，它不需要将数据结构化为行和列。
数据湖存储技术始于Apache Hadoop分布式文件系统（HDFS），这是一个几乎完全部署在本地的免费开源技术，在2010年代初非常流行。HDFS是一个可扩展、容错的分布式存储系统，旨在运行在廉价硬件上。它是Apache Hadoop生态系统的核心组件，我将在第16章中更详细地讨论。随着云计算的日益重要，数据湖在云中采用了不同类型的存储，现在大多数数据湖都存在于云中。
与关系型数据仓库相比，数据湖是一种按需模式，这意味着无需进行前期工作就可以将数据放入数据湖中：它可以像在笔记本电脑上复制文件夹那样简单。数据湖中的数据以其自然（或原始）格式存储，这意味着它可以直接从源系统进入数据湖，而无需转换为另一种格式。例如，如果您将关系数据库中的数据导出为原始CSV格式的文件，您可以将其不经修改地存储在数据湖中。然而，如果您想将其存储在关系型数据仓库中，您就必须将其转换为适合表的行和列的格式。
当您将数据文件复制到数据湖中时，其模式可能不会随之复制，或者可能在不同的文件中。因此，您必须通过创建或从单独的文件中提取来定义模式，因此有了"按需模式"的说法。正如图2-2所示，来自源系统（如操作应用程序数据库、传感器数据和社交媒体数据）的数据都可以落入数据湖中。这些文件可能包含结构化数据（如来自关系数据库的数据）、半结构化数据（如CSV、日志、XML或JSON文件）或非结构化数据（例如来自电子邮件、文档和PDF的数据）。它们甚至可以包含二进制数据（如图像、音频和视频）。
数据湖起初被视为解决关系型数据仓库的所有问题的解决方案，包括高成本、可扩展性有限、性能差、数据准备开销大以及对复杂数据类型的有限支持。销售Hadoop和数据湖的公司，如Cloudera、Hortonworks和MapR，将它们吹捧得好像充满了独角兽和彩虹，可以复制和清理数据，并以神奇的轻松方式向最终用户提供。他们声称数据湖完全可以取代关系型数据仓库，采用"一种技术包打天下"的方式。有不少公司决定通过使用免费开源工具来节省成本。
问题在于，查询数据湖实际上并不那么容易：这需要一些相当高级的技能。IT部门会告诉最终用户："嘿，我们已经把你们需要的所有数据都复制到了这个数据湖中。只需打开一个Jupyter笔记本，使用Hive和Python，就可以使用这些文件夹中的文件构建报告。"但这完全失败了，因为大多数最终用户根本没有接近完成这一切所需的技能。公司通过艰难的方式发现，这些复杂、难以使用的解决方案实际上因为硬件和支持成本、生产延迟和生产力损失而变得更加昂贵。此外，数据湖没有一些人们喜欢的数据仓库功能，如事务支持、模式强制执行和审计追踪。这导致了三大数据湖供应商中的两家，Hortonworks和MapR，都倒闭了。
但数据湖并没有消失。相反，它的目的转变成了一个不同但非常有用的目的：分段和准备数据。第5章将详细讨论数据湖。
现代数据仓库
关系型数据仓库和数据湖本身都是简单的架构。它们只使用一种技术来集中数据，并且几乎没有支持性产品。当您使用更多的技术和产品来支持关系型数据仓库或数据湖时，它们就会演变成本章和接下来的章节讨论的架构。数据湖未能取代关系型数据仓库，但仍为分段和准备数据提供了好处。为什么不兼有两者的优势呢？大约在2011年，许多公司开始构建将数据湖与关系型数据仓库并列的架构，形成了我们现在称之为现代数据仓库（MDW）的数据架构，如图2-3所示。现代数据仓库中的"现代"指的是使用更新的技术和方法来进行数据仓库管理。
这是一种"两全其美"的方法：数据湖用于分段和准备数据，数据科学家使用它来构建机器学习模型；数据仓库用于提供、安全性和合规性，业务用户使用它进行查询和报告。第10章将更详细地介绍现代数据仓库架构。
数据编织
数据编织开始出现大约在2016年。你可以将数据编织架构看作是现代数据仓库架构的演变，增加了更多的技术来源数据、保护数据并使其可用。此外，对系统如何摄取数据、转换、查询、搜索和访问数据进行了改进，如图2-4所示。随着所有这些增加，系统变成了一个"编织"------一个可以摄取任何类型数据的大型框架。第11章将会更详细地讨论这一点。
数据湖仓
数据湖仓架构是数据湖和数据仓库的混合词。数据湖仓架构在2020年左右开始流行，当时公司Databricks开始使用这个术语。湖仓的概念是摒弃关系型数据仓库，只使用一个存储库------数据湖，在您的数据架构中。各种类型的数据------结构化、半结构化和非结构化数据------都被摄取到数据湖中，并且所有的查询和报告都是从数据湖中进行的。
我知道你在想什么："等一下。你说数据湖最初出现时采取了同样的方法，结果失败了！发生了什么变化？"答案如图2-5所示，是一个运行在现有数据湖之上的事务存储软件层，使其更像一个关系型数据库。这个层的竞争性开源选项包括Delta Lake、Apache Iceberg和Apache Hudi。所有这些将在第12章中更详细地讨论。
数据网格
数据网格这一术语最早由Nextdata的创始人兼首席执行官、《数据网格：规模化交付数据驱动价值》（O'Reilly，2022）的作者Zhamak Dehghani在2019年5月的博客文章中提出。在2020年12月，Dehghani进一步阐明了数据网格的概念，并提出了四项基本原则。自那以后，数据网格架构一直是一个极其热门的话题，在许多博客、演示、会议和媒体报道中都有讨论，甚至出现在了Gartner数据管理的炒作周期中。关于数据网格架构有很多值得称赞之处，但尽管有大量的炒作，它只适用于少数几种使用案例。
现代数据仓库、数据编织和数据湖仓架构都涉及将数据集中存储：将业务数据复制到由IT部门拥有并受IT控制的中央位置，然后由IT创建分析数据（图2-6的左侧）。这种集中式方法带来了三个主要挑战：数据所有权、数据质量以及组织/技术扩展性。数据网格的目标是解决这些挑战。
在数据网格中，数据被保留在公司的几个领域内，例如制造、销售和供应商（图2-6的右侧）。每个领域都有自己的小型IT团队，负责管理数据、清洗数据、创建分析数据并提供访问。每个领域还拥有自己的计算和存储基础设施。这导致了一种分散式架构，在这种架构中，数据、人员和基础设施都被扩展了------你拥有的领域越多，你就会有越多的人员和基础设施。系统可以处理更多的数据，而IT不再是瓶颈。
重要的是要理解，数据网格是一个概念，而不是一种技术。没有什么"一揽子数据网格"可以购买。实施数据网格涉及到非常大的组织和文化转变，而很少有公司准备好进行这样的转变。（事实上，大多数公司甚至还不够大，无法被视为数据网格架构的候选对象：这非常适合企业级的方法。）构建它需要确定哪些现有技术可以重新利用，以及哪些部分需要创建。每个领域都可以决定使用什么技术来构建数据网格的一部分，这可能包括构建现代数据仓库、数据编织或数据湖仓架构。关于数据网格架构，还有很多需要讨论的地方，我将在第13章和第14章中进行讨论。
总结
现在您已经对数据架构的类型有了高层次的了解，下一章将讨论如何确定最适合使用的数据架构：一个称为架构设计会议的过程。