GreenPlum
关系型数据库集群,由数个独立的非共享的数据库服务组成的逻辑数据库;基于postgresql,采用MPP(massive parallel processing 大规模并行处理系统)架构。
分布式关系型MPP数据库集群
支持PB级别海量数据存储和处理
主要面向结构化数据、定位服务于OLAP,大数据计算或分析平台,不擅长做OLTP
性能好、数据导入高效、开源、随着硬件的增加性能呈线性增长
运维系统完善方便用户使用
查询计划、并行执行
GreenPlum适用场景
Greenplum最大的特点总结就一句话:基于低成本的开放平台基础上提供强大的并行数据计算性能和海量数据管理能力。这个能力主要指的是并行计算能力,是对大任务、复杂任务的快速高效计算,但如果你指望MPP并行数据库能够像OLTP数据库一样,在极短的时间处理大量的并发小任务,这个并非MPP数据库所长。请牢记,并行和并发是两个完全不同的概念,MPP数据库是为了解决大问题而设计的并行计算技术,而不是大量的小问题的高并发请求。
再通俗点说,Greenplum主要定位在OLAP领域,利用Greenplum MPP数据库做大数据计算或分析平台非常适合,例如:数据仓库系统、ODS系统、ACRM系统、历史数据管理系统、电信流量分析系统、移动信令分析系统、SANDBOX自助分析沙箱、数据集市等等。
而MPP数据库都不擅长做OLTP交易系统,所谓交易系统,就是高频的交易型小规模数据插入、修改、删除,每次事务处理的数据量不大,但每秒钟都会发生几十次甚至几百次以上交易型事务 ,这类系统的衡量指标是TPS,适用的系统是OLTP数据库或类似Gemfire的内存数据库。
与Hadoop比较
MPP和Hadoop都是为了解决大规模数据的并行计算而出现的技术,两种技术的相似点在于:
分布式存储数据在多个节点服务器上
采用分布式并行计算框架
支持横向扩展来提高整体的计算能力和存储容量
都支持X86开放集群架构
但两种技术在数据存储和计算方法上,也存在很多显而易见的差异:
MPP按照关系数据库行列表方式存储数据(有模式),Hadoop按照文件切片方式分布式存储(无模式)
两者采用的数据分布机制不同,MPP采用Hash分布,计算节点和存储紧密耦合,数据分布粒度在记录级的更小粒度(一般在1k以下);Hadoop FS按照文件切块后随机分配,节点和数据无耦合,数据分布粒度在文件块级(缺省64MB)。这一点Hbase好像支持对rowkey进行hash分布吧。
MPP采用SQL并行查询计划,Hadoop采用Mapreduce框架。后续也有sql on hadoop、sparkSQL出现。
基于以上不同,体现在效率、功能等特性方面也大不相同:
1 计算效率比较
Mapreduce相比而言是一种较为蛮力计算方式(业内曾经甚至有声音质疑MapReduce是反潮流的),数据处理过程分成Map-〉Shuffle-〉Reduce的过程,相比MPP数据库并行计算而言,Mapreduce的数据在计算前未经整理和组织(只是做了简单数据分块,数据无模式),而MPP预先会把数据有效的组织(有模式),例如:行列表关系、Hash分布、索引、分区、列存储等、统计信息收集等,这就决定了在计算过程中效率大为不同(个人认为mapreduce对内存占用、资源占用率低、容错性好,稳定性高、适合处理大规模集群下的离线数据挖掘和计算任务):
MAP效率对比:
Hadoop的MAP阶段需要对数据的再解析,而MPP数据库直接取行列表,效率高
Hadoop按照64MB分拆文件,而且数据不能保证在所有节点均匀分布,因此MAP过程的并行化程度低;MPP数据库按照数据记录拆分和Hash分布,粒度更细,数据分布在所有节点中非常均匀,并行化程度很高
Hadoop HDFS没有灵活的索引、分区、列存储等技术支持,而MPP通常利用这些技术大幅提高数据的检索效率;
Shuffle效率对比:(Hadoop Shuffle 对比MPP计算中的重分布)
由于Hadoop数据与节点的无关性,因此Shuffle是基本避免不了的;而MPP数据库对于相同Hash分布数据不需要重分布,节省大量网络和CPU消耗;
Mapreduce没有统计信息,不能做基于cost-base的优化;MPP数据库利用统计信息可以很好的进行并行计算优化,例如,对于不同分布的数据,可以在计算中基于Cost动态的决定最优执行路径,如采用重分布还是小表广播
Reduce效率对比:(对比于MPP数据库的SQL执行器-executor)
Mapreduce缺乏灵活的Join技术支持,MPP数据库可以基于COST来自动选择Hash join、Merger join和Nestloop join,甚至可以在Hash join通过COST选择小表做Hash,在Nestloop Join中选择index提高join性能等等(mapreduce在join这上面似乎真的是软肋,在odps上绝大多数情况下只适合单表分析);
MPP数据库对于Aggregation(聚合)提供Multiple-agg、Group-agg、sort-agg等多种技术来提供计算性能,Mapreuce需要开发人员自己实现;
以阿里云的odps来看,输入输出都是数据仓库中的关系型表格,因此有分区等概念,对比hadoop mapreduce性能有提升。
另外,Mapreduce在整个MAP->Shuffle->Reduce过程中通过文件来交换数据,效率很低,MapReduce要求每个步骤间的数据都要序列化到磁盘,这意味着MapReduce作业的I/O成本很高,导致交互分析和迭代算法开销很大,MPP数据库采用Pipline方式在内存数据流中处理数据,效率比文件方式高很多。最新版本的odps上的mapreduce支持pipeline模式
总结以上几点,MPP数据库在计算并行度、计算算法上比Hadoop更加SMART,效率更高;在客户现场的测试对比中,Mapreduce对于单表的计算尚可,但对于复杂查询,如多表关联等,性能很差,性能甚至只有MPP数据库的几十分之一甚至几百分之一。
2 功能上的对比
MPP数据库采用SQL作为主要交互式语言,SQL语言简单易学,具有很强数据操纵能力和过程语言的流程控制能力,SQL语言是专门为统计和数据分析开发的语言,各种功能和函数琳琅满目,SQL语言不仅适合开发人员,也适用于分析业务人员,大幅简化了数据的操作和交互过程。
而对MapReduce编程明显是困难的,在原生的Mapreduce开发框架基础上的开发,需要技术人员谙熟于JAVA开发和并行原理,不仅业务分析人员无法使用,甚至技术人员也难以学习和操控。为了解决易用性的问题,近年来SQL-0N-HADOOP技术大量涌现出来,几乎成为当前Hadoop开发使用的一个技术热点趋势。
这些技术包括:Hive、Pivotal HAWQ、SPARK SQL、Impala、Prest、Drill、Tajo等等很多,这些技术有些是在Mapreduce上做了优化,例如Spark采用内存中的Mapreduce技术,号称性能比基于文件的的Mapreduce提高10倍;有的则采用C/C++语言替代Java语言重构Hadoop和Mapreuce(如MapR公司及国内某知名电商的大数据平台);而有些则直接绕开了Mapreduce另起炉灶,如Impala、hawq采用借鉴MPP计算思想来做查询优化和内存数据Pipeline计算,以此来提高性能。
虽然SQL-On-Hadoop比原始的Mapreduce虽然在易用上有所提高,但在SQL成熟度和关系分析上目前还与MPP数据库有较大差距:
上述系统,除了HAWQ外,对SQL的支持都非常有限,特别是分析型复杂SQL,如SQL 2003 OLAP WINDOW函数,几乎都不支持,以TPC-DS测试(用于评测决策支持系统(大数据或数据仓库)的标准SQL测试集,99个SQL)为例,包括SPARK、Impala、Hive只支持其中1/3左右;
由于HADOOP 本身Append-only特性,SQL-On-Hadoop大多不支持数据局部更新和删除功能(update/delete);而有些,例如Spark计算时,需要预先将数据装载到DataFrames模型中;
基本上都缺少索引和存储过程等等特征
除HAWQ外,大多对于ODBC/JDBC/DBI/OLEDB/.NET接口的支持有限,与主流第三方BI报表工具兼容性不如MPP数据库
SQL-ON-HADOOP不擅长于交互式(interactive)的Ad-hoc查询,多通过预关联的方式来规避这个问题;另外,在并发处理方面能力较弱,高并发场景下,需要控制计算请求的并发度,避免资源过载导致的稳定性问题和性能下降问题;
3 架构灵活性对比
前文提到,为保证数据的高性能计算,MPP数据库节点和数据之间是紧耦合的,相反,Hadoop的节点和数据是没有耦合关系的。这就决定了Hadoop的架构更加灵活-存储节点和计算节点的无关性,这体现在以下2个方面:
扩展性方面
Hadoop架构支持单独增加数据节点或计算节点,依托于Hadoop的SQL-ON-HADOOP系统,例如HAWQ、SPARK均可单独增加计算层的节点或数据层的HDFS存储节点,HDFS数据存储对计算层来说是透明的;
MPP数据库扩展时,一般情况下是计算节点和数据节点一起增加的,在增加节点后,需要对数据做重分布才能保证数据与节点的紧耦合(重新hash数据),进而保证系统的性能;Hadoop在增加存储层节点后,虽然也需要Rebalance数据,但相较MPP而言,不是那么紧迫。
节点退服方面
- Hadoop节点宕机退服,对系统的影响较小,并且系统会自动将数据在其它节点扩充到3份;MPP数据库节点宕机时,系统的性能损耗大于Hadoop节点。
Pivotal将GPDB 的MPP技术与Hadoop分布式存储技术结合,推出了HAWQ高级数据分析软件系统,实现了Hadoop上的SQL-on-HADOOP,与其它的SQL-on-HADOOP系统不同,HAWQ支持完全的SQL语法 和SQL 2003 OLAP 语法及Cost-Base的算法优化,让用户就像使用关系型数据库一样使用Hadoop。底层存储采用HDFS,HAWQ实现了计算节点和HDFS数据节点的解耦,采用MR2.0的YARN来进行资源调度,同时具有Hadoop的灵活伸缩的架构特性和MPP的高效能计算能力.
当然,有得也有所失,HAWQ的架构比Greenplum MPP数据库灵活,在获得架构优越性的同时,其性能比Greenplum MPP数据库要低一倍左右,但得益于MPP算法的红利,HAWQ性能仍大幅高于其它的基于MapReduce的SQL-on-HADOOP系统。
4 Hadoop和MPP如何选择
总结一下,Hadoop MapReduce和SQL-on-HADOOP技术目前都还不够成熟,性能和功能上都有很多待提升的空间,相比之下,MPP数据在数据处理上更加SMART,要填平或缩小与MPP数据库之间的性能和功能上的GAP,Hadoop还有很长的一段路要走。
就目前来看,个人认为这两个系统都有其适用的场景,简单来说,如果你的数据需要频繁的被计算和统计、并且你希望具有更好的SQL交互式支持和更快计算性能及复杂SQL语法的支持,那么你应该选择MPP数据库,SQL-on-Hadoop技术还没有Ready。特别如数据仓库、集市、ODS、交互式分析数据平台等系统,MPP数据库有明显的优势。
而如果你的数据加载后只会被用于读取少数次的任务和用于少数次的访问,而且主要用于Batch(不需要交互式),对计算性能不是很敏感,那Hadoop也是不错的选择,因为Hadoop不需要你花费较多的精力来模式化你的数据,节省数据模型设计和数据加载设计方面的投入。这些系统包括:历史数据系统、ETL临时数据区、数据交换平台等等。如果涉及到复杂的数据挖掘分析、一些SQL解决不了的问题、在多用户平台上考虑代码安全性等情况下时,可以采用mapreduce编码的形式来解决,对于机器学习、深度学习算法的支持等了解不深,二者的差异暂时不清楚。
最后,提一下,Greenplum MPP数据库支持用“Hadoop外部表”方式来访问、加载Hadoop FS的数据,虽然Greenplum的Hadoop外部表性能大幅低于MPP内部表,但比Hadoop 自身的HIVE要高很多(在某金融客户的测试结果,比HIVE高8倍左右),因此可以考虑在项目中同时部署MPP数据库和Hadoop,MPP用于交互式高性能分析,Hadoop用于数据Staging、MPP的数据备份或一些ETL batch的数据清洗任务,两者相辅相成,在各自最擅长的场景中发挥其特性和优势。
车辆大数据2.0选型问题
车辆大数据2.0在开发早期选型是以mpp为底层引擎,python编写UDF形式实现数据挖掘算子,主要面临的问题是:
- 不支持python所依赖的第三方库
- 复杂的算子利用SQL解决较困难,例如涉及到过程存储等等
- 对于mapreduce框架机制不熟悉,难以在GreenPlum上实施
最终改成用spark作为底层引擎,mpp做数据ETL。