常用于日常活动的数据存储系统旨在高效地捕捉快速、小规模的更新。这些操作型数据库,通常称为在线事务处理(OLTP)系统,擅长处理记录销售、更新库存或注册用户等任务。然而,当目标是分析历史趋势、整合来自业务不同部分的信息或回答复杂的分析问题时,这些系统可能会遇到困难。它们主要不是为这类大规模分析而构建的。这时,数据仓库便发挥作用了。您可以将数据仓库视为一种专门的数据库,专为分析和报告而设计,这种做法通常被称为**商业智能(BI)**或在线分析处理(OLAP)。它不侧重于快速记录单个事务,其主要职责是从各种来源存储大量历史数据,其存储方式便于查询并随时间推移理解趋势。设想一家大型零售公司。它可能拥有独立的数据库用于实体店销售(销售点系统)、在线网站订单、库存管理和营销活动。每个系统都在操作层面很好地履行职责。数据仓库会定期从所有这些来源提取数据,进行清理,使其保持一致,并统一存储。这使得分析师能够提出横跨这些不同方面的问题,例如:“我们最近的在线营销活动在上一季度如何影响了特定产品类别的店内销售?”仅使用独立的榀作型数据库来回答这个问题将非常困难且缓慢。数据仓库的特点数据仓库通常具有一些显著特点,使其与标准操作型数据库有所不同:面向主题: 数据围绕业务的主要主题组织,例如客户、产品、销售或供应商。这与操作型数据库形成对比,操作型数据库通常围绕特定应用程序流程(如订单录入或库存控制)组织。这种面向主题的特点使得分析与这些核心方面相关的业务表现变得更容易。整合性: 当数据从不同来源引入数据仓库时,不一致性得以解决。例如,产品代码可能被标准化,客户名称格式保持一致,计量单位统一。这种整合确保了对业务的单一、连贯视角。时变性: 数据仓库长期存储信息,捕捉不同时间点的快照。数据仓库中的每一条数据都与特定时间段(例如,日、周、月、季度)相关联。这种历史视角对于分析趋势、进行预测以及比较不同时期的业绩表现非常必要。非易失性: 一旦数据加载到数据仓库中,通常不会被更改或删除。新数据会定期添加(例如,每日或每周加载),但过往数据作为历史记录保留。这种稳定性对于准确的历史分析很重要,这与记录不断更新的操作型数据库不同。为何需要数据仓库?构建和维护数据仓库需要付出努力,那么组织为何要投入其中呢?主要益处包括:统一视图: 通过整合来自不同系统的数据,提供单一事实来源。增强商业智能: 支持复杂的分析查询、报告和仪表盘制作,从而支持更好的业务决策。提升查询性能: 优化的结构和索引策略使得分析查询运行速度远快于在操作型数据库上运行。历史洞察: 存储多年的历史数据,从而可进行趋势分析和预测。解耦: 将繁重的分析工作负载与操作型系统分离,确保报告不会减慢日常业务事务的速度。结构与数据流向数据仓库通常存储高度结构化的数据,常驻于关系型数据库系统,它们经过优化,更适合读取大量数据而非频繁写入事务。其内部结构常采用特定的设计模式,例如星型模式或雪花模式,这些模式将数据组织成中心“事实”表(包含销售额等度量数据),周围是“维度”表(包含时间、产品详情或客户信息等描述性属性)。虽然这些模式的细节很复杂,但它们的目的在于使分析查询高效。数据通过称为**ETL(抽取、转换、加载)或ELT(抽取、加载、转换)**的过程进入数据仓库,我们将在下一章关于数据管道的讨论中进一步了解。这些过程负责从源头提取数据,进行清理和重塑(转换),然后将其载入数据仓库(加载)。digraph G { bgcolor="transparent"; rankdir=LR; node [shape=box, style=filled, fillcolor="#a5d8ff", fontname="sans-serif", fontsize=10]; edge [fontname="sans-serif", fontsize=9, color="#495057"]; subgraph cluster_sources { label = "数据源"; style=filled; fillcolor="#e9ecef"; node [fillcolor="#d0bfff"]; DB1 [label="操作型数据库\n(如销售)"]; DB2 [label="操作型数据库\n(如库存)"]; API [label="外部API\n(如市场营销)"]; Files [label="日志文件"]; } ETL [label="ETL / ELT\n过程", shape=ellipse, fillcolor="#96f2d7"]; DW [label="数据仓库\n(面向主题、\n整合性、历史性)", shape=cylinder, fillcolor="#ffec99", height=1.5]; subgraph cluster_consumers { label = "数据使用者"; style=filled; fillcolor="#e9ecef"; node [fillcolor="#ffc9c9"]; BI [label="BI工具和\n仪表盘"]; Analysts [label="数据分析师和\n科学家"]; Reports [label="报告"]; } DB1 -> ETL; DB2 -> ETL; API -> ETL; Files -> ETL; ETL -> DW [label=" 加载清理后的、\n 整合数据 "]; DW -> BI [label=" 查询数据 "]; DW -> Analysts [label=" 查询数据 "]; DW -> Reports [label=" 生成 "]; }数据从各种操作型源流出,经过处理(ETL/ELT),并加载到中心数据仓库。分析师和BI工具随后查询数据仓库以获取信息。与为快速事务设计的标准操作型数据库(OLTP)相比,数据仓库是为复杂的分析查询(OLAP)而构建的。它位于原始数据源和执行分析的最终用户之间,提供一个干净、整合、历史信息丰富的数据集,该数据集专为理解业务表现而定制。它与数据湖(我们接下来会探讨)的不同之处,主要体现在其侧重于存储结构化的、经过处理的、可供分析的数据,而数据湖通常以各种格式保存原始数据。