基于Spark+GemFire实现的内存数据库,支持SQL与SparkSQL

目前的OLAP引擎主要有Kylin、Impala、Kudu、Presto、Druid、Clickhouse、Doris、TiDB、Hawq、Hive、SparkSQL、SnappyData、Elasticsearch、Greenplum等。

虽然 TiDB 最初声称支持 100% TP 和 80% AP,但架构设计主要针对 TP 场景,缺乏针对 AP 场景的特殊优化,因此 OLAP 查询性能较差。TiDB 团队目前正在开发专门的 OLAP 产品:TiFlash,TiFlash 有以下特点:列内存、向量化执行、MPP,Doris 也有这些特点。

SnappyData是一个基于Spark+GemFire的内存数据库,一个存储引擎,全内存,行列混合存储,无需预处理,支持SQL和Spark SQL。SnappyData考虑到MPP的特点,colocate特性使得数据本地化,支持join、list update、window function等任意adhoc查询。

优势:

高性能,列存压缩+全内存,数据状态共享,秒级查询,实时性强,支持Kafka的流表和实时导入,处理简单,无需预处理,保存详细数据,数据本地存储,灵活性高,是一个支持任意字段查询、更新、窗口函数和复杂即席查询的sql数据库,易用性强,支持标准SQL和Spark SQL,精准去重,支持各种窗口函数。

缺点:

机器成本高。另外,SnappyData的计算是基于JVM的。会有GC问题,影响查询稳定性和维护成本。社区不是很活跃。

使用场景:

SnappyData适用于数据量中等(PB以下)、需求变化多、实时性要求高、响应时间短、窗函数查询复杂的那种窗函数查询;它也适用于查询详细数据和探索性即席查询。如果你想找一个好用、实时性要求高的多维OLAP引擎,而且最重要的是分析师可以使用的SQL引擎,SnappyData更适合。前提是需要在成本和效率之间取得平衡。SQL虽然可以提高开发效率,但是大内存服务器的成本确实比较高。

Clickhouse 是一个单机性能非常强大的OLAP 系统。ClickHouse 是所有开源 MPP 计算框架中最快的计算框架。它同时对具有大量行的表执行多列表和查询。人们很兴奋,但是在做多表连接时,它的性能不如单宽表查询。

性能测试结果表明,ClickHouse在单表查询中具有很大的性能优势属于搜索引擎语法的是,但在多表查询中性能相对较差,不如presto、impala、hawq。同时,在集群增减节点时,系统无法自动感知集群拓扑的变化,无法自动平衡数据,导致运维成本高。另外,Clickhouse不支持标准SQL,我们用户的访问成本也很高。另外,ClickHouse 可以用 Superset 展示,Grafana 可以用来监控 clickhouse。

对于我们的用户来说,Doris 的优势在于它功能强大且易于使用。强大的功能是指满足我们用户的需求,易用性主要是指兼容Mysql协议和语法,以及Online Schema Change。兼容Mysql协议和语法,用户的学习成本和开发成本都非常低,因为在业务发展迅速、迭代频繁的情况下,schema的变化会是一个高频操作。对我们来说,Doris 的优点是易运维、易扩展和高可用,易运维意味着 Doris 没有外部系统依赖,部署和配置都非常简单。易扩容意味着Doris可以一键增减节点,自动平衡数据。

Spark 引入了一个名为 Spark SQL 的编程模块,用于结构化数据处理。它提供了一种称为 DataFrame 的编程抽象,可以充当分布式 SQL 查询引擎。

图片[1]-基于Spark+GemFire实现的内存数据库,支持SQL与SparkSQL-老王博客

SparkSQL 是 Hadoop 中著名的 SQL 引擎。它使用 Spark 作为底层计算框架,可以作为 Spark 的 RDD 查询结构化数据。RDD的全称是Resilient Distributed Datasets,是Spark的基本数据结构。

Spark 使用 RDD 作为分布式程序的工作集合,它提供了一种受限形式的分布式共享内存。在分布式共享内存系统中,应用程序可以对全局地址空间中的任何位置进行读写操作,而 RDD 是只读的,只能执行创建、转换和求值等操作。这种内存操作大大提高了计算速度。SparkSQL的性能比其他组件差,多表查询性能并不突出。

Impala 是 Cloudera 开发的交互式 SQL 大数据查询工具。它是一个 MPP(大规模并行处理)SQL 查询引擎,用于处理存储在 Hadoop 集群中的大量数据。它是用 C++ 和 Java 编写的开源软件。

官方宣布其计算速度是一大优势。在实际测试中,我们也发现它的多表查询性能和 Presto 差不多,但是单表查询不如 Presto。而Impala有很多不支持的地方,比如:不支持更新、删除操作属于搜索引擎语法的是,不支持Date数据类型,不支持ORC文件格式等等,所以我们使用parquet格式来查询,Impala占用内存当查询很大时。

Presto是一个分布式SQL查询引擎,由FaceBook于2013年11月开源,专为高速、实时的数据分析而设计。它支持标准的 ANSI SQL,包括复杂的查询、聚合、连接和窗口函数。Presto 本身不存储数据,但它可以访问多个数据源并支持跨数据源的级联查询。Presto是一款OLAP工具,擅长对海量数据进行复杂分析;但是对于 OLTP 场景,并不是 Presto 擅长的,所以不要把 Presto 作为数据库。

Presto、Impala 和 GreenPlum 都是基于 MPP 架构的。与 Elasticsearch、Druid、Kylin 等简单的 Scatter-Gather 模型相比,它们在支持的 SQL 计算上更通用,更适合 ad-hoc 查询场景。然而,这些通用系统通常比专用系统更好。做性能优化比较困难,所以不适合查询QPS(参考值QPS>1000),延迟要求比较高(参考值搜索延迟)

与其他组件相比,整体性能优于其他组件。查询性能和支持的数据源和数据格式都应该是出色的。单表查询性能高,多表查询性能也很突出。由于 Presto 是完全基于内存的并行计算,所以 Presto 在查询的时候也占用了大量的内存,但是发现比 Impala 少。例如,多表连接需要大量内存,Impala 比 Presto 占用更多内存。

Greenplum作为关系型数据库产品,主要特点是查询速度快、数据加载速度快、批量DML处理速度快。并且性能可以随着硬件的增加而线性增加,具有很好的扩展性。因此,它主要适用于面向分析的应用程序。比如搭建企业级ODS/EDW,或者数据集市等,Greenplum都是不错的选择。

Elasticsearch 是一个典型的类搜索引擎架构系统。它在存储过程中将数据转换为倒排索引,并使用 Scatter-Gather 计算模型来提高查询性能。搜索类的查询效果较好,但是当数据量大时,Scan类和聚合类的查询性能较低。

优点:查询性能高,支持倒排索引和各种过滤聚合查询,实时性强。在文档上建立索引后,可以立即进行查询。处理方法简单,无需预处理。

缺点:支持的数据规模小,高并发不理想,灵活性差。它不支持复杂的即席查询,易用性也很差。它不支持 SQL;DSL 很昂贵,并且无法准确地进行重复数据删除。

适用场景:ES适用于全文检索、过滤条件多、数据规模较小时并发低的聚合查询。

(此处已添加圈卡,请到今日头条客户端查看)

待续…

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
评论 抢沙发

请登录后发表评论