在文章开始前, 各位读者大人如果听过数据仓库或者知道数据仓库, 可以思考下数据仓库跟数据库有什么区别. 如果未听过数据仓库, 我猜你也想知道为什么有数据库了, 还要数据仓库.
思考过后, 我们来开始吧.
一, 什么是数据仓库?
简单讲, 数据仓库是一种特殊的数据库. 数据仓库一般以主题为出发点进行的, 也就是业务核心, 集成多种数据源的数据, 会随着时间的变化而变化, 因为随着时间数据的量会改变, 而且以读操作为主, 所以基本不会丢失, 总结成 4 个特点可以说, 数据仓库是一个面向主题的, 集成的, 时变的, 非易失的数据集合, 支持管理者的决策过程. 它是由企业进行的大量信息的电子存储, 它的设计用于查询而不是事务处理. 这也就是它跟数据库的区别. 数据仓库一个将数据转换为信息并及时向用户提供的过程, 传统数据库大多表示数据而已.
数据仓库的特点, 如图
二, 数据仓库的组成
数据仓库不是一个 product, 而是一个 environment. 这么说是因为它不是单纯的存储数据的地方, 而是一个信息系统的架构构造, 是为数据分析和报告而构建. 主要由以下三部分组成的
1, 底层是仓库数据库服务器: 几乎是一个关系数据库系统, 使用后端工具和实用程序, 由操作数据库或其它外部数据源, 提取数据, 放入底层
2, 中间层是 OLAP 服务器
3, 顶层是前端客户层, 也叫应用层. 包括查询和报告工具, 分析工具和数据挖掘工具.
具体组成, 如图所示
三, 数据仓库模型
根据结构来说, 数据仓库有三种数据仓库模型.
企业仓库: 是一个集中式仓库, 包括细节数据和汇总数据, 为整个企业提供决策支持服务, 提供统一的方法来组织和表示数据, 还根据主题对数据进行分类以及访问的能力
数据集市: 是数据仓库的子集. 专门针对特定业务部门而设计, 例如销售, 财务. 在独立的数据集市中, 数据可以直接从源收集.
虚拟仓库: 操作数据库上视图的集合.
四, 开发数据仓库系统需要注意什么.
开发数据仓库有比较普遍的两种方法, 分别是自顶向下以及自底向上.
自顶向下: 是一种比较系统的解决方案, 并能最大限度得减少集成问题. 但是它费用高, 开发周期长, 而且缺乏灵活性, 因为整个组织就共同数据模型达成一致是比较困难得
自底向上: 灵活, 低花费, 并能快速汇报投资, 但是将分散得数据集市集成, 形成一个一致得企业数据仓库, 可能导致问题.
因此如果能结合二者, 以递增, 进化的方式实现数据仓库. 例如在一个合理短得时间里, 在不同得主题和应用之间, 提供企业范围得, 一致的, 集成得数据视图.
设计步骤一般为
(1)选取待建模的业务处理(例如订单, 销售). 如果一个商务过程是整个组织的, 并涉及多个复杂的对象, 应该选用我们上面说的数据仓库模型. 如果处理是部门的, 而且关注的是某一业务处理的分析, 就应该选择数据集市.
(2)选取业务处理的粒度(例如一个事务).
(3)选取用于每个事实表记录的维例如(时间, 商品).
(4)选取将安放在每个事实表记录中的度量. 例如销售量.
实施步骤一般为
1, 企业战略: 确定技术, 事实, 维度和属性. 包括数据映射以及转换.
2, 分阶段交付: 根据主题分阶段实施数据仓库. 比如销售系统, 应先实施预定和计费等相关业务实体, 然后相互集成.
3, 迭代原型: 应该迭代开发和测试, 而不是一个大爆炸的实现方法 .
设计数据仓库是一件比较困难以及长期的事情, 所以我们一开始应该清楚得定义它的实现范围, 也就是要明确实现目的, 而且需求应该是详细, 业务是可实现的, 可量化的.
五, 数据仓库 vs 数据库
通过上面我们了解了数据仓库, 那么现在可以来回答文中一开始的问题.
传统数据库是为存储而生, 而数据仓库很明显, 是为分析而生. 实现目的的不同一开始就注定它们的差异. 传统数据库包括增删改查, 但数据仓库注重查询. 传统数据库的主要任务是执行联机事务处理, 简称 OLTP ( Online Transaction Processing). 主要负责日常操作, 如购物, 制造.
数据仓库系统在数据分析和决策方面为用户或 "知识工人" 提供服务, 可以以不同的格式组织和提供数据, 以便应付不同的需求, 这种系统称作联机分析处理, 简称 OLAP ( Online Analytical Processing ).
下面我们通过对比 OLAP 和 OLTP 的区别, 就能详细知道数据仓库和数据库的区别. 首先考虑用户和系统的面向对象, OLTP 是面向顾客的, 用户操作员, 客户和信息技术人员的事务和查询处理. OLAP 是面向市场的, 用于知识工人的数据分析.
数据内容: OLTP 管理当前数据. 但是一般这种数据比较琐碎, 很难用于决策. OLAP 系统管理大量历史数据, 提供汇总和聚集机制, 而且在不同的粒度层上存储和管理信息.
数据库设计: OLTP 系统采用实体 - 联系 (ER) 数据模型和面向应用的数据库设计. 而 OLAP 系统采用星形或雪花模型和面向主题的数据库设计.
视图: OLTP 关注一个企业或部门内部的当前数据, 不涉及历史数据或不同单位的数据. OLAP 经常需要跨域数据库模式的不同版本.
访问模式: OLTP 系统主要由短的原子事务组成, 一般需要并发控制和恢复机制. 而 OLAP 系统的访问大部分是只读操作.
下面用个表格总结看起来比较明朗
特征 | OLTP | OLAP |
特性 | 操作处理 | 信息处理 |
面向 | 事务 | 分析 |
用户 | 办事员、DBA、数据库专业人员 | 知识工人(如经理,主管,分析人员) |
功能 | 日常操作 | 长期信息需求,决策支持 |
DB 设计 | 基于 E-R,面向应用 | 星形 / 雪花、面向主题 |
数据 | 当前的,确保最新的 | 历史的,跨时间维护 |
汇总 | 原始的、高度详细 | 汇总的、统一的 |
视图 | 详细、一般关系 | 汇总的、多维的 |
工作单元 | 短的,简单事务 | 复杂查询 |
访问 | 读 / 写 | 大多为读 |
关注 | 数据进入 | 信息输出 |
操作 | 主码上索引 / 散列 | 大量扫描 |
访问记录数量 | 数十 | 数百万 |
用户数 | 数千 | 数百 |
DB 规模 | GB 到高达 GB | ≥TB |
优先 | 高性能、高可用性 | 高灵活性、终端用户自治 |
度量 | 事务吞吐量 | 查询吞吐量、响应时间 |
六, 数据仓库有什么用
那么说了这么多, 数据仓库有什么过人之处呢. 个人总结了两点. 一个是提高生产力, 一个是有利于关系管理. 在于它的实时性以及数据丰富性.
七, 小结
数据仓库更像是一个系统工具, 比如 Hive, 就是基于 Hadoop 的开源数据仓库, 可以对存储在 HDFS 的文件数据进行查询, 分析. 篇幅所限, 这里不对 Hive 的架构做过多解释. 数据仓库在大数据架构中起着至关重要的作用, 其实上面的数据仓库架构可以说是基本涵盖了大数据的流程了, 里面的每一层每一个组件都足以让我们研究很久了.
本文首发微信公众号 "哈尔的数据城堡".
来源: https://www.cnblogs.com/Alear/p/10476453.html