引言 回顾数据管理的发展历程,我们大致走过了三个阶段:从最初的人工管理,到后来的文件系统管理,再到如今的数据库系统管理。数据库的出现,真正实现了数据的永久存储、有序组织和高效共享。 不过,在数据库系统应用的早期,人们对数据的利用大多还停留在基础的“增删改查”(CRUD)层面。这当然没问题,事务处理是
回顾数据管理的发展历程,我们大致走过了三个阶段:从最初的人工管理,到后来的文件系统管理,再到如今的数据库系统管理。数据库的出现,真正实现了数据的永久存储、有序组织和高效共享。
不过,在数据库系统应用的早期,人们对数据的利用大多还停留在基础的“增删改查”(CRUD)层面。这当然没问题,事务处理是业务的基石。
长期稳定更新的攒劲资源: >>>点此立即查看<<<
但故事不会止步于此。当数据积累到一定规模,企业的需求自然会升级——他们不再满足于简单的记录和查询,而是希望从海量数据中进行统计、多维分析,甚至挖掘出更深层的商业价值。这时候,一个尴尬的局面出现了:传统的、为高频事务处理而设计的操作型数据库,在面对这类复杂的分析型任务时,往往力不从心。
正是这个矛盾,催生了数据仓库的诞生。仔细对比你会发现,传统的数据库与数据仓库,在存放的数据特征、性能要求、应用范围乃至面向的使用人员上,都存在着根本性的差异。
在计算机系统中,数据处理主要遵循两种截然不同的模型:操作性数据处理和分析型数据处理。它们也常被称为联机事务处理(OLTP)和联机分析处理(OLAP)。
操作性数据处理:这指的是对数据库进行的日常联机操作,核心任务是完成数据的收集、整理、存储以及实时的增、删、改、查。这类工作通常由一线业务人员和基层管理人员来完成,追求的是高并发和快速响应。
分析型数据处理:这则是对数据的“再加工”过程。它通常面向海量的历史数据,进行复杂的查询、统计和分析,目的是从中提炼出有价值的信息和洞察,以支持决策。执行这类任务的主力,往往是数据分析师和中高级管理人员。
两种处理模式,自然对应着两类特征迥异的数据。
操作型数据的特点是:细节的、当前的、可更新的、由事务驱动。每次操作涉及的数据量小,逻辑相对简单,通常针对的是单一数据单元。
分析型数据则恰恰相反:它是综合的、历史的、不可更新的、由分析驱动。一次分析操作往往需要扫描庞大的数据集合,计算复杂,关注的是数据整体的规律和趋势。
具体来说,操作型数据服务于企业的日常运营。数据库里存放的是最新的、细节的交易记录,任何修改都会实时更新。数据组织方式的核心目标,是优化事务处理的性能。
而分析型数据则支撑企业的管理决策。数据仓库中主要存放历史数据和经过汇总的综合数据。当操作集中在查询与分析时,为了提升效率,数据的组织会以便于快速检索和分析为首要目标,甚至可以容忍一定的数据冗余。
传统数据库在操作性处理上取得了辉煌的成功,但在应对分析型需求时,却暴露出一系列瓶颈。
第一,数据是分散的。操作性处理通常只涉及单一部门或系统,导致企业数据被割裂在各个独立的操作型数据库中。而分析型操作恰恰需要跨部门、跨系统的全局视野。
第二,数据不一致问题。当试图从各个源头抽取数据时,你会发现“同名异义”、“异名同义”、计量单位不统一、字段长度不一致等问题比比皆是。在分析之前,必须花费大量精力进行数据清洗和预处理。
第三,历史数据缺失。分析决策离不开历史趋势的支撑,但操作型数据库为了保持性能,通常只保留短期的、当前的数据。
第四,数据粒度不匹配。分析关注宏观的综合指标,而操作型数据库存储的是最细颗粒度的交易记录。如果每次分析前都要对海量细节数据进行实时汇总,效率将极其低下。
正是为了克服这些困难,让两种数据处理模式都能高效运转,数据仓库的概念应运而生。
简单总结一下:数据库与数据仓库分工明确。数据库负责存放操作型数据,专注于事务处理,追求极致的处理效率;数据仓库则负责存放分析型数据,专注于决策支持,追求的是强大的分析与查询效率。两者功能不同,用途各异,其底层结构设计自然也大相径庭。
那么,究竟什么是数据仓库?一个经典的定义是:数据仓库是一个面向主题的、集成的、不可更新的、随时间不断变化的数据集合,其根本目的是为了更好地支持企业或组织的决策分析。
这四个特征至关重要:面向主题、集成的、不可更新的、随时间不断变化的。
它的核心用途始终是:面向企业决策分析。
说得更直白些,数据仓库就是一种面向特定决策主题(如客户、产品)、从多个数据源集成数据、同时包含当前数据及不同粒度历史数据、并以查询和分析为主的数据库系统。它的存在,就是为了给企业决策提供一个坚实、统一的数据基石。
下面,我们来逐一拆解数据仓库的四个核心特征。
“面向主题”的数据组织方式,是相对于“面向应用”而言的。这可能是理解数据仓库的关键。
什么是面向主题?简单说,就是在更高的抽象层次上,对分析对象(即“主题”)进行完整、一致的数据描述。它能统一地刻画该主题所涉及的所有数据以及数据间的关联。
想象一下典型的企业信息化建设:通常会按采购、销售、库存、人事、财务等业务线来建立子系统,每个子系统背后都是一个独立的操作型数据库。这就是典型的“面向应用”。
如果现在想分析“顾客”这个主题,会发生什么?你需要从销售库、客服库、财务库等多个地方费力地抽取数据,还要面对之前提到的各种不一致问题。这显然无法满足高效、准确的分析需求。
而“面向主题”的思路则不同。它会根据分析的需要,将“顾客”这个分析对象所关联的所有数据,从企业各个角落收集、汇聚、整合起来,形成一个关于“顾客”的完整、一致、统一的数据集合。这里的主题,就是诸如“顾客”、“商品”、“供应商”这样的分析对象。
两者的侧重点截然不同:面向应用关心的是“做什么事”(处理什么业务),而面向主题关心的是“分析谁”(谁是被分析的对象)。面向主题的组织方式,其精髓就在于形成关于某个主题的一致性信息集合。
既然数据仓库中的数据按主题组织,其来源必然是分散的各个操作性数据库、文件或网络。来源多,就意味着不一致:同名不同义、同义不同名、单位各异、格式不一……
因此,在数据进入仓库之前,必须经过一系列严格的预处理步骤:清洗、转换、去重。同时,数据还需要从“面向应用”的原始形态,转变为“面向主题”的新形态。不仅如此,数据仓库中不仅需要细节数据,更需要大量预先计算好的综合数据(如月度销售额、客户年消费总额),这就涉及对数据的聚合与计算。只有完成了这些步骤,数据才能被加载到数据仓库中。
“不可更新”指的是,数据一旦进入数据仓库,通常就不允许再进行修改,而是会被长期保存。这是因为数据仓库中反映的是一段相当长时期内的历史快照,它记录的是过去某个时间点的状态。数据一般按照固定的周期(如每天、每周)进行刷新和追加加载。
数据仓库并非一成不变,它会随着时间推移不断增长。因为它需要定期从操作型数据库等数据源中,捕获新的数据(包括新的历史数据和新的综合数据),并将其加载进来。
同时,数据仓库中的数据也有生命周期,超过存储期限的旧数据会被移除。另外,仓库中存在大量按时间维度组织的综合数据(如日汇总表、月报表),这也要求系统必须按照固定的时间周期,定期执行数据的加载和汇总任务。
总而言之,数据仓库本质上是一种经过特殊设计和处理的数据存储。它将来自不同源头、结构各异的异构数据进行清洗、转换、加工和集成,然后存储起来,专门服务于企业的分析查询需求,最终为决策制定提供强有力的数据支持。

转载于:https://www.cnblogs.com/zja001/p/10282276.html
侠游戏发布此文仅为了传递信息,不代表侠游戏网站认同其观点或证实其描述