传统数据仓库过时了吗
传统数据仓库体系结构
传统数据仓库由源系统, ODS,EDW,Data Mart 这几部分组成, 源系统就是业务系统, 生产系统, ODS 是操作数据存储, EDW 是企业级数据仓库, Data Mart 是数据集市.
源系统
生产系统, 财务系统, 人力资源系统还有 12306 的订票系统等其实都是源系统, 源系统的主要作用是产生数据. 传统行业大多是将这些数据存储在 oracle,db2 上, 互联网行业选择开源数据库的居多.
ODS
ODS 是 Openrational Data Store 的简称, 叫操作数据存储, 在项目中也被叫做中间库或临时库. 数据从业务系统进入真正的数据仓库前会有一个中间层, 这中间层就是 ODS.
作为一个中间层 ODS 有着以下几个特点.
整合异构的数据, 比如各种业务数据以及 mysql 或者 oracle 的数据都是通过中间库进入数据仓库
转移一部分业务系统细节查询的功能, 如果直接对使用传统关系型数据库的业务系统进行查询, 对于 Oracle 和 db2 这样的数据库来说存在一定的局限性.
数据编码标准化转化.
DW 是静态数据而 ODS 中的数据是动态的, 可更新的.
数据内容不同, ODS 存储当前或者近期的数据, DW 存储历史性数据.
ODS 数据容量级别较小, DW 的数据容量很大.
上文提到的是传统意义上对 ODS 的定义, 而现在我们所理解的 ODS 已不再局限于此. 现在 ODS 存储的不单单是文本, 还包括图片和视频. 也就是说它变成了一个中间层, 而涉及的技术也不仅仅是关系型数据库, 还有 NoSQL 或 Redis 这样的类型数据库. 在前端采集数据量非常大的时候, 关系型数据库可能会顶不住压力, 但如果是 Redis 的话就可以将数据缓存在内存中, 然后批量刷到关系库中.
EDW 介绍
EDW 也就是企业级数据仓库, 以下是它的一些特点.
面向主题: 操作型数据库的数据组织面向事物处理任务, 各个业务系统 之间各自分离, 而数据仓库中的数据是按照一定的主题域进行组织的. 例如: 当事人, 协议, 机构, 财务, 事件, 产品等主题.
集成的: 数据仓库中的数据是在对原有分散的数据库数据抽取, 清理的 基础上经过系统加工, 汇总和整理得到的, 必须消除源数据中的不一致 性, 以保证数据仓库内的信息是关于整个企业的一致的全局信息.
相对稳定的: 数据仓库的数据主要供企业决策分析之用, 所涉及的数据操作主要是数据查询, 一旦某个数据进入数据仓库以后, 一般情况 下将被长期保留, 也就是数据仓库中一般有大量的查询操作, 但修改 和删除操作很少, 通常只需要定期的加载, 刷新.
反映历史变化: 数据仓库中的数据通常包含历史信息, 系统记录了企 业从过去某一时点 (如开始应用数据仓库的时点) 到目前的各个阶段的信 息, 通过这些信息, 可以对企业的发展历程和未来趋势做出定量分析 和预测.
无论是传统的的数据仓库还是大数据时代的数据仓库, EDW 提供的功能并无太多差异. 主要还是随机查询, 固定报表以及数据挖掘, 一般大数据层面更多的是偏向数据挖掘.
DM 介绍
数据集市的英文名称是 Data Marts. 它是一种小型的部门级的数据仓库, 主要面向部门级业务, 并且只面向某个特定的主题, 是为满足特定用户 (一般是部门级别的) 的需求而建立的一种分析型环境. 投资规模比较小, 更关注在数据中构建复杂的业务规则来支持 功能强大的分析.
大数据的概念和数据集市的概念正好相反, 数据集市是从一个超集中得出一个子集, 而大数据是集合众多业务数据, 然后从其中发掘数据的关联以及价值. 所以我们认为数据集市的概念在大数据时代已经是过时了, 这也是近些年来已经很少有人讨论数据集市的原因.
上图是我们认为的正确的体系结构, 最后的 DW 被替换成 DV(可视化数据库 / 结果库). 在 EDW 中计算的结果最终被存到 DW 中, 然后由 DW 做展示或者可视化.
PG/GP 是否已经过时
前面提到过传统型数据库有着很多局限, 接下来我们会重新梳理和设计, 让传统数据仓库也能去适应大数据时代的变化.
源系统设计
上图展示的是 SCADA(数据采集与监视控制系统), 这样的一套系统中如果存在着上万个传感器, 那么在一瞬间所产生的数据量会非常庞大. 过去 SCADA 的做法是将采集的数据存放在内存中, 但是由于数据量太大且无法发现数据价值, 所以会进行定期清除.
近些年随着大数据的发展, 这些数据的价值慢慢被体现出来, 因此有了将数据存储到后端的需求. 在数据库的选择上很多是倾向于 PG, 主要原因在于 SCADA 是和数据库捆绑在一起销售, 而如果捆绑的是 MySQL 则会存在一定风险, PG 则没有这方面的顾虑.
上面所提的这些, 其实就是想说明在源系统上 PG 可能是更好的选择.
中间库 (ODS) 设计
中间库通常被设计成数据库集群而不是单机. 下图的接口数据库其实就是一个中间库, 是由多台机器组成的集群, 每台机器上会有多个 MySQL 或 PG 实例. 这样就可以将数据分布到不同的机器上, 形成一个接口库成为集群. 这里的集群并非传统意义上的集群, 中间库应该是松散的 MySQL 集群, PG 集群, 数据量大的时候也可以选择 Redis 集群.
EDW 设计
既然谈到数据仓库设计, 那么就要先回到传统层面 -- 基于 Oracle 的数据仓库.
传统的数据仓库有这样几个特点, 一是使用分区技术加速数据访问, Oracle 中一个大表可以分为几个区, 每个区又可以放到不同物理硬盘中, 这样的设计对于性能提升其实很大, 但是在大数据时代就有些捉襟见肘. 二是应用集群技术, 前端是多台服务器提供运算能力, 后端是共享存储也就是 IO. 从架构上可以看出这其实是一个磁盘并列, 一旦 IO 出现瓶颈, 整个应用集群也会随之出现问题, 所以这样的架构同样不适于数据仓库. 三是 Oracle 的 Exadata, 它在交易平台使用的比较多, 在数据仓库上则很少见. 另外从可视化角度来看 Oracle 的 BIEE 也很难跟上时代.
综上所述, 可以说传统的数据仓库技术虽然并非完全过时, 但也在慢慢退出舞台.
当我们有海量数据的时候, 就要面临数据仓库的选型问题, 比如 Oracle,DB2,PG 生态圈或者 Hadoop 生态圈. 基于上文所述 Oracle 和 DB2 肯定要被排除在外, 在 PG 和 Hadoop 之间如果选择的是 PG 生态圈, 就会有两个选择: PostgreSQL 和 Greenplum. 对于在线交易系统选择的肯定是 PostgreSQL, 而对于真正的数据仓库就应该选择 Greenplum.
Greenplum 体系结构
Greenplum 由多个控制节点 (master) 和多个数据节点 (segment Host) 构成的集群.
之所以选择 Greenplum, 第一是因为它的高性能.
而高性能首先体现在大表分布上, Greenplum 中会将一个大表的数据均匀的分布到多个节点, 为并行执行 (并行计算) 打下基础. 其次是并行执行, Greenplum 的并行执行可以是外部表数据加载并行, 查询并行, 索引的建立和使用并行, 统计信息收集并行, 表关联并行等等. 第三点是列式存储和数据压缩, 如果常用的查询只取表中少量字段, 则列模式效率更高, 如查询需要取表中的大量字段, 行模式效率更高.
选择 Greenplum 的第二个原因是产品成熟度高. 前面提到过 Greenplum 由多个节点组成, 其实它的每个节点就是一个 PostgreSQL.PostgreSQLy 于 1986 年开始研发, 1987 年开发出第一个版本, 1988 年对外展出, 可以说 PG 经过这么多年的发展已经是非常成熟的产品.
第三个原因是容灾机制, Greenplum 可以有两个 master 节点, 其中一个宕机的时候, 另外一个会继续接收访问, 并且这两个节点的 Catalog 和事务日志会保持实时同步.
第四个原因是线性扩展, Greenplum 采用了通用的 MPP 并行处理架构, 在 MPP 架构中增加节点就可以线性提高系统的存储容量和处理能力. Greenplum 在扩展节点时操作简单, 在很短时间内就能完成数据的重新分布. Greenplum 线性扩展支持为数据分析系统将来的拓展给予了技术上的保障, 用户可根据实施需要进行容量和性能的扩展.
最后一个原因是似曾相识的开发环境, 由于 Greenplum 是基于 PostgreSQL, 在语法上和 PG 区别并不大, 所以能够让传统的 Java 开发人员平稳的过渡到 Greenplum.
引入 Hadoop
基于传统的 SQL 查询 Greenplum 可以轻松应对, 但是在机器学习上就明显不足, 虽然 Greenplum 的 MADlib 支持机器学习, 实际案例却并不多见. 因此要在 EDW 中引入 Hadoop 生态圈来满足机器学习的需求.
上图就是引入的 hadoop 生态圈, 资源管理层使用 Mesos 和 Yarm, 分布式存储层是 HDPS, 处理引擎层可以在 MapReduce 和 Spark core 间选择. 所以如果要做机器学习, 其实有两个选项, 一是 MapReduce 加 Mahout, 二是 Spark core 加 MLlib. 而 MapReduce 在性能上有所不如, 因此我们一般倾向于第二个方案.
最终数据经由 Greenplum 进入 hadoop 生态圈, 然后根据开发能力以及应用选择要存储的地方. Greenplum 在这里成为了机器学习的数据源, 另外数据在进入 hadoop 以后, 还是可以做基于 SQL 的查询.
还有一点需要注意的是数据仓库或者大数据平台的计算结果一般都会被存储到 PG 中, 这是由于 PG 对大表的处理能力要强于 MySQL.
总结
最后我们反过来梳理下整个体系结构, 底层的 DV 使用 PG,EDW 采用 Greenplum 加 Hadoop,ODS 这层最好也使用 PG, 这是为了避免项目中出现太多的异构数据库, 也便于开发人员开发.
来源: http://stor.51cto.com/art/201807/579751.htm