sgreen screen浏览器官网
不管是impala还是greenplum在推出时,官方都会去跟传统的基于hadoop的HIVE做比较,强调数据查询性能,数据表结构等;
作为一个大数据实践者,在选择做数据中心提供数据分析等服务时,基于MPP思想的内存计算交互查询确实是个比较好的方案;但很少因此对他们在一起做比较整理,以及与越来越好的spark sql ,kylin 等做一个较为整体视角的比较。
本文着眼点即在此。
Greenplum篇
1.GreenPlum实现了基于数据库的分布式数据存储和并行计算,而MapReduce是基于文件的分布式数据存储和计算;
2.GreenPlum 选择PostgreSQL做为数据库底层引擎,通过Interconnect核心软件组件实现了对统一集群中多个
Postgresql实例的高效协同和并行计算,Interconnect承载了并行查询计划产生和分发,协调节点上执行器的
并行工作,负责数据分布、Pipeline计算、镜像复制、健康探测等等诸多任务。
3. GreenPlum选择Postgresql出于以下考虑:
1)Postgresql号称较先进的数据库,有非常强大的SQL支持能力和丰富的统计函数和统计语法支持,
支持分析函数(OLAP window函数),可以通过多种语言编写存储过程,对Madlib、R支持很好;
2)扩展方面强大,支持Python、C、Perl、TCL、PLSQL等语言扩展功能,支持扩展用户自定义函数(UDF)功能;
3)诸如ACID事务处理、数据强一致性、数据类型支持、独特的MVCC带来高效数据更新能力;
4) Postgresql许可是仿照BSD许可模式, 没有被大公司控制,社区比较纯洁;
5) 支持odbc、jdbc等接口,与第三方工具、BI报表集成非常容易;
4. MPP采用两阶段提交和全局事务管理机制来保证集群上分布式事务一致性,Greenplum像Postgresql一样
满足关系型数据库的包括ACID在内所有特征;
5. GreenPlum架构
数据库由Master Severs和Segment Severs通过Interconnect互联组成。
Master主机负责:
访问系统的入口,建立与客户端的连接和管理
SQL的解析并形成执行计划;
执行计划向Segment的分发收集Segment的执行结果;
Master不存储业务数据
只存储数据字典(系统目录表和元数据)
Segment主机负责:
业务数据的存储和存取;
用户查询SQL的执行。
NetWork InterConnect: 并行调度功能
Master Node支持高可用,类似于Hadoop的namenode和second namenode, 实现主备的高可用。
当Primary Master出现故障时,Standby Master担它全部工作, Standby Master通过同步进程,
保持与Primary Maser的数据一致。
Segment Server:
每个Segment存放一部分用户数据;
一个节点可以有多段;
用户不能直接存取访问,所有对段的访问都经过Master;
数据库监听进程监听来自于Master的链接;
6.GreenPlum最小并行单元不是节点层级,而是在实例层级(非Oracle实例概念,指一个分布式子库),每个实例都有
自己的Postgresql目录结构,都有各自一套Postgresql数据库守护进程(可进行单实例访问),甚至一个运行在
单节点的GP也是一个小型并行计算框架,一个节点配置6?8个实例,相当于一个节点有6?8个PG数据库同时工作,
可以充分利用每个节点的CPU和IO;
7.Greenplum还研发了非常多的高级数据分析管理功能和企业级管理模块:
外部表并行数据加载
可更新数据压缩表
行、列混合存储
数据表多级分区
BitMap索引
Hadoop外部表
Gptext全文检索
并行查询计划优化器和Orca优化器
Primary/Mirror镜像保护机制
资源列表管理
WEB/Brower监控
8.Greenplum的分布式并行计算架构,其中每个节点上所有Postgresql实例都是并行工作的,
外部表数据加载是并行的、
查询计划执行是并行的、
索引的建立和使用是并行的,
统计信息收集是并行的、
表关联(包括其中的重分布或广播及关联计算)是并行的,
排序和分组聚合都是并行的,
备份恢复也是并行的,
甚而数据库启停和元数据检查等维护工具也按照并行方式来设计,得益于这种无所不在的并行,Greenplum在数据加载和数据计算中表现出强悍的性能
9.Greenplum较大的特点总结就一句话:基于低成本的开放平台基础上提供强大的并行数据计算性能和海量数据管理能力
但如果你指望MPP并行数据库能够像OLTP数据库一样,在极短的时间处理大量的并发小任务,这个并非MPP数据库所长
并行和并发是两个完全不同的概念,MPP数据库是为了解决大问题而设计的并行计算技术,而不是大量的小问题的高并发请求。
Greenplum主要定位在OLAP领域,而MPP数据库都不擅长做OLTP交易系统
Greenplum与Hadoop
- 相似处
- 分布式存储数据在多个节点服务器上
- 采用分布式并行计算框架
- 支持横向扩展来提高整体的计算能力和存储容量
- 都支持X86开放集群架构
- 差异
- MPP按照关系数据库行列表方式存储数据(有模式),Hadoop按照文件切片方式分布式存储(无模式)
- 两者采用的数据分布机制不同, MPP采用Hash分布, 计算节点和存储紧密耦合, 数据分布粒度在记录级的更小粒度(一般在1k以下)
- Hadoop FS按照文件切块后随机分配, 节点和数据无耦合, 数据分布粒度在文件块级(缺省64MB)
- MPP采用SQL并行查询计划, Hadoop采用Mapreduce框架
- 扩展性问题
- Hadoop架构支持单独增加数据节点或计算节点,HDFS数据存储对计算层来说是透明的
- MPP数据库扩展时,一般情况下是计算节点和数据节点一起增加的,在增加节点后,
- 需要对数据做重分布才能保证数据与节点的紧耦合(重新hash数据),进而保证系统的性能;
- Hadoop在增加存储层节点后,虽然也需要Rebalance数据,但相较MPP而言,不是那么紧迫。
- 节点宕机方面
Hadoop节点宕机退服,对系统的影响较小,并且系统会自动将数据在其它节点扩充到3份;MPP数据库节点宕机时,系统的性能损耗大于Hadoop节点。
impala
Impala架构
Impala是Cloudera在受到Google的Dremel启发下开发的实时交互SQL大数据查询工具,它可以看成是Google Dremel架构和MPP (Massively Parallel Processing)结构的结合体。Impala没有再使用缓慢的Hive&Map-Reduce批处理,而是通过使用与商用并行关系数据库中类似的分布式查询引擎(由Query Planner、Query Coordinator和Query Exec Engine三部分组成),可以直接从HDFS或HBase中用SELECT、JOIN和统计函数查询数据,从而大大降低了延迟,其架构如图4所示,Impala主要由Impalad,State Store和CLI组成。Impalad与DataNode运行在同一节点上,由Impalad进程表示,它接收客户端的查询请求(接收查询请求的 Impalad为Coordinator,Coordinator通过JNI调用java前端解释SQL查询语句,生成查询计划树,再通过调度器把执行计划分发给具有相应数据的其它Impalad进行执行),读写数据,并行执行查询,并把结果通过网络流式的传送回给Coordinator,由 Coordinator返回给客户端。同时Impalad也与State Store保持连接,用于确定哪个Impalad是健康和可以接受新的工作。Impala State Store跟踪集群中的Impalad的健康状态及位置信息,由state-stored进程表示,它通过创建多个线程来处理Impalad的注册订阅和与各Impalad保持心跳连接,各Impalad都会缓存一份State Store中的信息,当State Store离线后,因为Impalad有State Store的缓存仍然可以工作,但会因为有些Impalad失效了,而已缓存数据无法更新,导致把执行计划分配给了失效的Impalad,导致查询失败。 CLI提供给用户查询使用的命令行工具,同时Impala还提供了Hue,JDBC,ODBC,Thrift使用接口。
impala与greenplum
impala与greenplum都是对SQL解析做执行计划,基于内存计算查询数据整合返回,而非启动mapreduce,spark任务来执行处理,与常见的业务系统关系型数据库使用起来,有传承之处。并且有更好的横向扩展能力,这是传统关系型数据库不具备的。当然现在很多关系型数据库也退出对应的集群方案,来支持海量数据的横向扩展。这里的重点是,虽然如此但各有侧重面。关系型数据库的集群方案,有一个重点关注的方面是数据强一致性和事务处理。而MPP数据库主要表现在查询性能,支持海量数据上。
当数据库越来越好的发展,各自也都会支持一些特性。进入到对方的领域。但记着,没有什么数据库是万能的,能在不同业务场景下都适用的。技术人员要把握的是,这些数据库,它们是什么?它们在干什么?它们要去哪里(发展方向)?
抓住事物的本质永远是最主要的,不要过多耗费在花枝招展的细节上失去整体。物理学上的第一性原理,是具有认识事物的普遍意义的。特斯拉的马斯克也十分的推崇第一性原理。
在建设数据中心或数据仓库的时候,具体选择MPP数据库还是Hive,Spark SQL,亦或者预处理数据库如kylin,因为但从技术本身上,kylin也确有好处。但有时候也要考虑公司的技术延续性,不可盲目的追求技术本身,剑宗到底不如气宗来的正大光明。不过我挺喜欢剑宗的,其主要原因是气宗后来变得正统而虚伪,似乎正统的最后都会这样。
篇幅原因,建设数据仓库在选择上,是否还要选择预处理kylin这样的,我们下一篇具体再对我公司的具体情况作出讨论和选择。