2.3.1 数据仓库：模式级别的表类型

数据仓库需要“写时模式”访问，这意味着我们在数据进入仓库时就设置了数据的结构。这些数据的进一步转换必须在每一步都明确其新结构。

数据仓库是完全集成和托管的解决方案，使其易于构建和开箱即用。与数据湖不同，数据仓库通常需要更多的结构和模式，这通常会对数据清洗的过程要求更高，并在读取和使用数据时降低复杂性。

现代数据仓库的概念部分归功于Kimball集团，该集团在20世纪80年代开发了数据仓库/商业智能生命周期方法论（https://oreil.ly/uxbcY）。这种系统设计上的创新支持了企业在各个层面上的业务价值，包括工程师最常从事的数据摄取和预处理阶段。Kimball在将数据存储技术确定为商业资产而不仅仅是技术偏好的过程中发挥了重要作用。

现代数据仓库通过其写时模式架构遵循这种方法，并且可以与Looker和Tableau等商业智能工具进行集成。简单来说，数据仓库中的数据一定有其存在的原因，而这些原因应当与某种业务目标相对应。

目前，常见的数据仓库技术包括以下几种。

Amazon Redshift

作为第一个广受欢迎（且随时可用）的云数据仓库，Amazon Redshift位于AWS之上，利用源连接器将数据从原始数据源传输到关系型数据库中。Redshift的列式存储结构和并行处理使其成为分析型工作负载的理想选择。

Google BigQuery

与Redshift类似，Google BigQuery利用了Google的专有云平台GCP（Google Cloud Platform）并使用了列式存储结构，通过并行处理来实现快速查询。BigQuery是一种可根据使用模式进行扩展的无服务器解决方案，这一点与Redshift不同。

Snowflake

与依赖专有云运行的Redshift或GCP不同，Snowflake的云数据仓库功能由AWS、Google、Azure和其他公有云基础设施提供支持。与Redshift不同，Snowflake允许用户为计算和存储单独付费，这让数据仓库成为寻求更灵活支付方案的团队的绝佳选择。

鉴于其预打包功能和对SQL的强大支持，数据仓库促进了快速、可操作的数据查询，使其成为数据分析团队的理想选择。

虽然数据仓库对于商业分析用例非常有价值，但它同时也存在一些缺点，你尤其应该记住那些与管理数据质量相关的缺点：

灵活性有限

数据仓库并不是市面上最灵活的数据存储解决方案。这并不是说它们不能很好地进行扩展（许多著名的现代解决方案都可以做到），而是说在数据仓库中，数据的格式是有限的。数据仓库中的条目必须强制转换为具有明确模式的表格形式。像JSON（JavaScript Object Notation）这样的半结构化数据及其查询通常不受支持，而且不良数据常常会被遗漏。

仅支持SQL

查询数据仓库需要使用查询语言，如SQL。这一过程通常不支持使用Python等指令式编程语言进行数据操作，尽管这些语言由于强大的库生态系统对机器学习非常有用。所以，许多机器学习的实现需要通过SQL将数据移出仓库，以便进一步处理。当然，这种对数据的移动经常会中断，并且会出现容量、新鲜度和模式异常。

工作流之间存在冲突

一部分数据科学家在一个快速迭代的产品上紧密合作，他们可能会发现写时模式系统提供的清洁度带来的问题比好处要多。当你想快速工作时，对数据结构采用宽松的标准会更有利。这种结构将不断变化，而不断变化的模式并不是数据仓库乐于支持的。

基于这些原因，数据团队同时采用数据仓库和数据湖来处理分析型工作负载的情况并不少见，因为它们分别有着不同的用途。