什么是数据仓库？ 数据仓库是一个集中式系统，它存储来自多个源系统的当前和历史数据。它针对查询、分析和报告进行了优化，而不是针对处理事务性工作负载。它整合并汇集来自不同来源的结构化和历史数据，以支持商业智能和决策制定。
数据仓库通常存储已清理、转换并组织为一致数据模型的结构化和半结构化数据。通过提供有序的高质量数据，可以实现高效的数据分析，使业务用户、数据分析师和数据科学家能够更轻松地分析数据、确定趋势和支持决策。
操作数据库存储和管理由运营系统（支持日常业务活动的应用程序和服务，例如订单处理）生成的数据，并针对海量数据的性能、聚合和复杂分析查询进行了优化。
数据仓库简史
数据仓库概念的出现，旨在解决运营系统与分析需求之间日益脱节的问题。
在 20 世纪 80 年代和 90 年代初，企业严重依赖操作数据库生成报告。随着数据量的增长，分析查询开始拖慢交易系统并产生不一致的指标。为了弥合这一差距，早期架构引入了暂存层和操作数据存储，将报告与日常操作分开。
现代数据仓库形成于 20 世纪 90 年代初，这要归功于 Bill Inmon 的工作。他将数据仓库定义为一个集中式的、面向主题的系统，旨在为决策提供支持。大约在同一时间，Ralph Kimball 推行了维度建模，该建模优化了分析查询和商业智能的数据结构。
2000 年代，企业数据仓库和数据集市（数据仓库中面向特定领域的小型子集）变得十分普及，但它们通常在本地部署，且需要大量的前期投资。2000 年代后期大数据的兴起催生了数据湖，这扩展了存储灵活性，但并未取代数据仓库。
2010 年代向云基础架构的转移改变了数据仓库，将存储与计算分离，从而实现了弹性扩展和托管服务。如今，数据仓库作为更广泛的数据生态系统的一部分运行，与事务数据库、数据湖和分析平台协同工作，以平衡性能、灵活性和管理。
数据仓库能解决什么问题？
随着组织规模的扩大，数据在各个业务系统间变得碎片化。报告逻辑往往出现重复，指标变得不一致，而分析查询则可能会降低应用程序性能。
数据仓库可以通过以下方式帮助解决这些挑战：
将多个来源的数据集中到一个存储库中
规范跨团队的定义和指标
提高分析工作负载的查询性能
将分析处理与事务处理系统分离
支持大规模商业智能和报告
助力组织跨部门和环境高效管理数据
数据仓库中的管理控制可集中敏感记录，并通过提供数据来源及使用情况的 Atlas 审核追踪来简化法规合规。
这样不仅能获得更可靠的分析结果，还能更清晰地了解业务绩效。
数据仓库与数据库与数据湖
数据仓库、数据库和数据湖在现代数据架构中发挥着不同的作用。
数据库 支持操作工作负载和应用程序逻辑，并旨在以结构化（通常是标准化）格式存储数据，以便进行事务处理。
数据仓库 支持分析、报告和商业智能，并以维度模型存储数据，以优化快速查询和分析。
数据湖 以其原始格式存储大量原始数据，使组织能够以结构化和非结构化形式存储数据，以进行灵活分析。
这些系统通常一起使用，而不是单独使用。许多组织将事务性数据库、数据湖和数据仓库相结合，以平衡灵活性、性能和管理。
有关更深入的比较，请参阅我们关于数据湖与数据仓库的指南
OLTP 与 OLAP 对比。了解差异
为了解何时需要数据仓库，区分 OLTP 和 OLAP 系统会有所帮助。
OLTP（联机事务处理） 系统旨在支持运营工作负载。这些系统处理频繁的、小型事务，如用户注册、购买、更新和应用程序交互。
OLAP（在线分析处理） 系统专为分析而设计。它们支持对大型数据集执行复杂查询，这些数据集通常跨越数月或数年的历史数据。OLAP 系统专为处理多维数据而构建，支持跨时间、地点和产品等多个维度的快速、复杂查询。此外，OLAP 系统为商业智能和数据分析提供高级分析功能，使组织能够获得见解并做出数据驱动的决策。
OLTP 与 OLAP 对比
注意：事务型数据库与数据仓库不是相互竞争的技术。它们是为不同工作负载而设计的互补系统。在设计合理的架构中，OLTP 和 OLAP 系统协同工作，以同时支持运营效率和分析见解。
您何时需要数据仓库？
如果您遇到以下情况，可能需要数据仓库：
您分析来自多个业务系统的数据
业务用户需要一致、可信的指标
报告查询正在影响应用程序性能
您需要分析历史趋势，而不仅仅是当前状态
在应用程序数据库中，分析逻辑变得难以管理 数据管理和访问控制变得越来越重要
如果您的主要工作负载涉及实时事务或应用程序数据访问，则通常应选择 OLTP 数据库。当分析和报告成为业务的核心时，数据仓库就变得很有价值。
数据仓库架构和层
数据仓库通常设计为分层架构，其中每一层负责特定范围的数据处理。这种分离有助于团队隔离关注点、提高性能并独立演进系统的各个部分。虽然各组织的实现有所不同，但大多数数据仓库系统都采用分层方法，将数据从操作源经过转换和存储层移动，然后再提供用于分析和执行
源系统
源系统包括运营数据库、SaaS 应用程序、日志文件和外部数据源。这些系统生成流入数据仓库的原始数据，通常作为日常运营的权威真实来源
预发布和摄入
数据被摄取到预发布环境中，在那里可以对其进行验证、清理和转换准备。该层充当源系统和仓库之间的缓冲区，允许在不影响生产系统的情况下检查、组织和重新处理数据（如果需要）。
转换和建模
在此层中，数据被转换为一致的格式，并组织成分析数据模型。在此处应用业务逻辑、聚合和标准定义。
存储层级
数据通常根据访问模式存储在不同层级中。频繁访问的数据可以保存在更快的存储中，而较早的历史数据则可以更具成本效益地进行存储。此外，汇总数据——源自详细事务数据的聚合信息——通常与原始数据一起存储在数据仓库中，以便于报告和决策制定。
分析和 BI 工具
商业智能工具、分析平台和机器学习工作流程会对数据仓库进行查询，以生成见解、仪表盘和报告。这些工具利用数据仓库的分析功能来支持商业智能和高级分析。
数据仓库使用案例
数据仓库不是一个通用数据系统。它专门针对分析工作负载进行了优化，但这些优化带来的权衡使其不适合事务性使用案例。
数据仓库旨在支持跨多个维度的大量历史数据。数据通常被摄取、转换和组织成有助于提高读取性能、聚合以及快速、高效的分析查询的分析模型。但是，数据无法一致更新，也没有针对高频写入或低延迟事务进行优化。
另一方面，事务系统旨在处理大量小型实时操作。它们优先考虑即时一致性、快速插入和更新，以及应用程序工作流的可预测响应时间。
最佳使用案例
商业智能与报告
高管仪表盘和关键绩效指标 (KPI)
趋势分析与预测
历史性能分析
数据挖掘和分析工作负载 集成来自销售点系统的数据以进行事务分析和报告
当用于这些目的时，数据仓库就成为关键的决策支持系统。
不适合的使用案例
数据仓库不太适合需要立即一致性、低延迟响应或由应用程序开发驱动的频繁模式更改的工作负载。
不适合的使用案例包括：
高容量事务性工作负载
低延迟应用程序查询
实时运营更新 在未经深思熟虑建模的情况下快速变更模式
数据仓库本质上并不昂贵或复杂。当要求它们像事务系统一样运行时，它们就会变得昂贵，从而带来不必要的延迟、运营风险和架构复杂性。
数据仓库的局限性
数据仓库可以是：
成本昂贵： 它们通常需要存储海量历史数据、运行计算密集型分析查询，并维护摄取、转换和管理的管道。随着数据和使用量的增加，持续的基础设施和运营需求会增加成本。
复杂： 建设和运营数据仓库涉及管理多个层级，包括数据建模、摄取、转换和访问管理。团队定义一致的指标、管理模式更改并维护数据质量，这通常需要专门的技能和重大的协调工作。
耗时： 加载和转换数据的过程可能非常耗时，尤其是在处理大量数据时。
不够灵活： 数据仓库的结构通常是固定的，这使其难以适应不断变化的业务需求。
有限： 数据仓库已针对报告和分析进行优化，这可能会限制其在其他类型数据处理任务中的用处。
数据仓库如何与 MongoDB 协作
数据仓库通常与事务型数据库配合使用，而不是取代它们。
在典型架构中，OLTP 数据库（例如 MongoDB）存储应用程序使用的操作数据。然后，这些数据被复制或流式传输到数据仓库中，可以在不影响应用程序性能的情况下进行转换和分析。
这种方法使每个系统能够专注于自己最擅长的事情：
事务型数据库支持快速、可靠的操作
数据仓库支持分析和商业智能
现代架构日益采用 lakehouse 和基于连接器的方法，这些方法提供了结构化的方法来移动、同步操作数据并将其公开给分析平台，而无需耦合系统。在这些模式中，连接器将数据从操作数据库流式传输或复制到分析环境，而 lakehouse 平台则将仓储式分析与 data lake 存储相结合。
例如，MongoDB 与 Databricks 等平台之间的集成使得可以使用 OLAP 系统分析运营数据，同时保持 OLTP 性能。
这两个系统如何协同工作
典型的架构遵循以下模式：
应用程序将运营数据写入 MongoDB
数据会被复制、流式传输或批量加载到数据仓库中
数据仓库为分析而转换和建模数据
BI 工具和分析师查询数据仓库，这是与应用程序数据库不同的系统
在这种架构中，应用程序只与操作数据库交互，而分析工作负载则完全针对数据仓库运行。这种分离确保了分析查询不会与事务工作负载竞争，从而使每个系统能够独立且高效地运行。MongoDB 支持快速、可靠的事务，而数据仓库则支持跨大型数据集的复杂分析查询。
为什么这种方法很重要
将数据仓库与 MongoDB 结合使用有助于组织：
避免在操作数据库上运行繁重的分析查询
随着分析用量的增长，保持应用程序性能
跨团队维护一致的指标 分析历史趋势，而无需使应用程序模式复杂化
MongoDB 针对操作型工作负载进行了优化。它擅长处理高容量事务、灵活模式以及支持实时应用程序的低延迟读写。相比之下，数据仓库则针对分析型工作负载进行了优化。它们旨在跨多个维度扫描并聚合海量历史数据，通常使用计算密集型查询，而这种查询在操作型数据库中不仅效率低下还会造成干扰。
区分这些关注点有助于组织避免针对操作数据运行繁重的分析查询，在分析使用量增长时保持应用程序性能，并保持跨团队的一致和共享指标。
在此架构中，MongoDB 作为当前操作数据的主记录系统，而数据仓库则是专为报告、趋势分析和长期见解构建的派生分析系统。
现代集成模式
许多组织使用连接器和湖仓一体式架构来集成操作和分析数据。例如，MongoDB 与 Databricks 等平台之间的集成使组织能够使用 OLAP 系统分析操作数据，同时保持事务型工作负载的隔离。
这些模式支持分析、机器学习和报告使用案例，无需强制单一系统处理不兼容的工作负载。
何时引入数据仓库
当需求较低时，MongoDB 可以在运营工作负载的同时支持基础分析。它提供聚合功能和灵活的模式，非常适合简单的报告和应用层面的见解。
但是，随着报告变得越来越复杂，数据量增加，或历史分析变得至关重要，这些访问模式会对操作数据库提出相互冲突的要求。允许分析工作负载独立扩展，同时 MongoDB 继续作为操作数据的记录系统，成为一个实用的下一步。
数据仓库的局限性和权衡
虽然数据仓库功能强大，但也有局限性。
它们可以是：
昂贵
没有合适的数据建模，设计起来很复杂
填充和维护非常耗时 灵活性较差
在决定数据仓库是否是正确的解决方案时，了解这些权衡非常重要。
什么是数据仓库层级？
数据仓库通常根据数据处理、存储和访问的方式组织成层级。这些层级有助于分离关注点、提高性能和控制费用。
常见的数据仓库层级
底层：数据摄取和存储
这一层级包括源系统、摄取管道和原始存储。数据从运营系统、应用程序和外部来源中收集，并加载到仓库环境中。原始数据或经过轻微处理的数据可能会被保留，以供重新处理或审核。
中间层：转换和建模
中间层是清理、转换和建模数据以进行分析的地方。应用业务规则，执行数据质量检查，并创建分析模式。此层级对于生成一致、可信的指标至关重要。
顶级：分析和消费
最顶层包括 BI 工具、仪表盘、分析平台和机器学习工作流。业务用户、分析师和数据科学家在这一层与数据交互，以探索趋势、生成报告和支持决策。
分离这些层级有助于组织扩展分析，同时保护业务系统并控制存储和计算费用。
有哪些常见的数据仓库变体？
并非所有数据仓库都以相同方式构建。传统的本地数据仓库是基于硬件的存储解决方案，它们在加强治理、安全、数据主权和降低延迟方面具有优势，但管理起来可能会很复杂。现代数据仓库已经超越了这些本地系统，转而支持云原生和混合架构。
到 2025 年，许多现代数据仓库还将充当数据湖仓，将管理和结构与数据湖的灵活存储相结合，用于 AI 和机器学习工作负载。
常见的数据仓库变体
企业数据仓库 (EDW)
企业数据仓库是整个组织的集中式分析平台。它跨部门整合数据，并为报告和商业智能提供单一的数据源。
数据集市
数据集市是数据仓库中规模较小且面向特定主题的子集。它们通常针对特定的团队或使用案例而设计，例如财务、市场营销或销售分析。
传统数据仓库
传统的数据仓库通常在本地部署，需要大量的前期基础设施投资。它们依赖固定的模式和较长的开发周期。
云数据仓库
云数据仓库是将存储与计算分离的完全托管服务。它们提供弹性扩展、更快的设置以及即用即付定价，使其成为许多现代组织的默认选择。
现代数据仓库
现代数据仓库强调灵活性、与 data lake 的集成以及对高级分析和机器学习工作负载的支持。它们旨在与操作数据库一起使用，而不是取代它们。
选择合适的变体需要考虑数据量、延迟要求、管理需求和组织成熟度。
数据仓库与其他数据系统相比如何？
了解数据仓库与其他数据系统相比有何不同，有助于阐明何时它是正确的解决方案，何时不是。
数据仓库与数据湖
数据仓库与数据集市
何时使用数据仓库
数据仓库是专为分析、报告和决策而设计的专业系统。它将来自多个来源的数据集中在一起，应用一致的业务逻辑，并支持大规模的复杂分析查询。数据仓库针对分析访问模式进行了优化，这对有效的 AI 和机器学习应用程序至关重要。它们提供干净、可靠的数据，可以支持各种 AI 和机器学习工作流，增强业务智能和高级分析所需的分析功能。
它不能替代事务数据库。最有效的数据架构结合了 OLTP 系统和 OLAP 系统，让两者都能发挥其预定作用。
如果使用得当，数据仓库将成为商业智能和数据分析的可靠基础。如果使用不当，它会带来不必要的费用和复杂性。