内容来源:2017 年 10 月 21 日,深奇智慧联合创始人高扬在“PostgreSQL 2017中国技术大会”进行《基于Greenplum,postgreSQL的大型数据仓库实践》演讲分享。IT 大咖说(微信id:itdakashuo)做为独家视频合做方,经主办方和讲者审阅受权发布。前端
阅读字数:4263 | 11分钟阅读mysql
大数据时代,传统数据仓库技术是否已通过时?咱们将进行探讨,超越传统数据仓库,又基于传统数据仓库,如何设计超大型数据仓库平台。本专题将详细介绍Greenplum,postgreSQL在大型数据仓库中的地位和实践。sql
传统数据仓库由源系统、ODS、EDW、Data Mart这几部分组成,源系统就是业务系统、生产系统,ODS是操做数据存储,EDW是企业级数据仓库,Data Mart是数据集市。数据库
生产系统、财务系统、人力资源系统还有12306的订票系统等其实都是源系统,源系统的主要做用是产生数据。传统行业大可能是将这些数据存储在oracle、db2上,互联网行业选择开源数据库的居多。后端
ODS是Openrational Data Store的简称,叫操做数据存储,在项目中也被叫作中间库或临时库。数据从业务系统进入真正的数据仓库前会有一个中间层,这中间层就是ODS。缓存
做为一个中间层ODS有着如下几个特色。服务器
整合异构的数据,好比各类业务数据以及mysql或者oracle的数据都是经过中间库进入数据仓库微信
转移一部分业务系统细节查询的功能,若是直接对使用传统关系型数据库的业务系统进行查询,对于Oracle和db2这样的数据库来讲存在必定的局限性。架构
数据编码标准化转化。oracle
DW是静态数据而ODS中的数据是动态的、可更新的。
数据内容不一样,ODS存储当前或者近期的数据,DW存储历史性数据。
ODS数据容量级别较小,DW的数据容量很大。
上文提到的是传统意义上对ODS的定义,而如今咱们所理解的ODS已再也不局限于此。如今ODS存储的不仅仅是文本,还包括图片和视频。也就是说它变成了一个中间层,而涉及的技术也不只仅是关系型数据库,还有NoSQL或Redis这样的类型数据库。在前端采集数据量很是大的时候,关系型数据库可能会顶不住压力,但若是是Redis的话就能够将数据缓存在内存中,而后批量刷到关系库中。
EDW也就是企业级数据仓库,如下是它的一些特色。
面向主题:操做型数据库的数据组织面向事物处理任务,各个业务系统 之间各自分离,而数据仓库中的数据是按照必定的主题域进行组织的。 例如:当事人、协议、机构、财务、事件、产品等主题。
集成的:数据仓库中的数据是在对原有分散的数据库数据抽取、清理的 基础上通过系统加工、汇总和整理获得的,必须消除源数据中的不一致 性,以保证数据仓库内的信息是关于整个企业的一致的全局信息。
相对稳定的:数据仓库的数据主要供企业决策分析之用,所涉及的数据操做主要是数据查询,一旦某个数据进入数据仓库之后,通常状况 下将被长期保留,也就是数据仓库中通常有大量的查询操做,但修改 和删除操做不多,一般只须要按期的加载、刷新。
反映历史变化:数据仓库中的数据一般包含历史信息,系统记录了企 业从过去某一时点(如开始应用数据仓库的时点)到目前的各个阶段的信 息,经过这些信息,能够对企业的发展历程和将来趋势作出定量分析 和预测。
不管是传统的的数据仓库仍是大数据时代的数据仓库,EDW提供的功能并没有太多差别。主要仍是随机查询、固定报表以及数据挖掘,通常大数据层面更多的是偏向数据挖掘。
数据集市的英文名称是Data Marts。它是一种小型的部门级的数据仓库,主要面向部门级业务,而且只面向某个特定的主题,是为知足特定用户(通常是部门级别的)的需求而创建的一种分析型环境。投资规模比较小,更关注在数据中构建复杂的业务规则来支持 功能强大的分析。
大数据的概念和数据集市的概念正好相反,数据集市是从一个超集中得出一个子集,而大数据是集合众多业务数据,而后从其中发掘数据的关联以及价值。因此咱们认为数据集市的概念在大数据时代已是过期了,这也是近些年来已经不多有人讨论数据集市的缘由。
上图是咱们认为的正确的体系结构,最后的DW被替换成DV(可视化数据库/结果库)。在EDW中计算的结果最终被存到DW中,而后由DW作展现或者可视化。
前面提到过传统型数据库有着不少局限,接下来咱们会从新梳理和设计,让传统数据仓库也能去适应大数据时代的变化。
上图展现的是SCADA(数据采集与监视控制系统),这样的一套系统中若是存在着上万个传感器,那么在一瞬间所产生的数据量会很是庞大。过去SCADA的作法是将采集的数据存放在内存中,可是因为数据量太大且没法发现数据价值,因此会进行按期清除。
近些年随着大数据的发展,这些数据的价值慢慢被体现出来,所以有了将数据存储到后端的需求。在数据库的选择上不少是倾向于PG,主要缘由在于SCADA是和数据库捆绑在一块儿销售,而若是捆绑的是MySQL则会存在必定风险,PG则没有这方面的顾虑。
上面所提的这些,其实就是想说明在源系统上PG多是更好的选择。
中间库一般被设计成数据库集群而不是单机。下图的接口数据库其实就是一个中间库,是由多台机器组成的集群,每台机器上会有多个MySQL或PG实例。这样就能够将数据分布到不一样的机器上,造成一个接口库成为集群。这里的集群并不是传统意义上的集群,中间库应该是松散的MySQL集群、PG集群,数据量大的时候也能够选择Redis集群。
既然谈到数据仓库设计,那么就要先回到传统层面——基于Oracle的数据仓库。
传统的数据仓库有这样几个特色,一是使用分区技术加速数据访问,Oracle中一个大表能够分为几个区,每一个区又能够放到不一样物理硬盘中,这样的设计对于性能提高其实很大,可是在大数据时代就有些捉襟见肘。二是应用集群技术,前端是多台服务器提供运算能力,后端是共享存储也就是IO。从架构上能够看出这实际上是一个磁盘并列,一旦IO出现瓶颈,整个应用集群也会随之出现问题,因此这样的架构一样不适于数据仓库。三是Oracle的Exadata,它在交易平台使用的比较多,在数据仓库上则不多见。另外从可视化角度来看Oracle的BIEE也很难跟上时代。
综上所述,能够说传统的数据仓库技术虽然并不是彻底过期,但也在慢慢退出舞台。
当咱们有海量数据的时候,就要面临数据仓库的选型问题,好比Oracle、DB二、PG生态圈或者Hadoop生态圈。基于上文所述Oracle和DB2确定要被排除在外,在PG和Hadoop之间若是选择的是PG生态圈,就会有两个选择:PostgreSQL和Greenplum。对于在线交易系统选择的确定是PostgreSQL,而对于真正的数据仓库就应该选择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。
基于传统的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,这是为了不项目中出现太多的异构数据库,也便于开发人员开发。