背景
MapReduce不能满足大数据快速实时adhoc查询计算的性能要求。
Facebook
的数据仓库存储在少量大型Hadoop/HDFS
集群。Hive
是Facebook在几年前专为Hadoop
打造的一款数据仓库工具。
在以前,Facebook的科学家和分析师一直依靠Hive
来做数据分析。但Hive
使用MapReduce
作为底层计算框架,是专为批处理设计的。但随着数据越来越多,使用Hive
进行一个简单的数据查询可能要花费几分到几小时,显然不能满足交互式查询的需求。Facebook也调研了其他比Hive更快的工具,但它们要么在功能有所限制要么就太简单,以至于无法操作Facebook庞大的数据仓库。
2012年开始试用的一些外部项目都不合适,他们决定自己开发,这就是Presto。2012年秋季开始开发,目前该项目已经在超过 1000名Facebook雇员中使用,运行超过30000个查询,每日数据在1PB级别。Facebook称Presto的性能比Hive要好上10倍多。2013年Facebook正式宣布开源Presto。
简介
基于内存的并行计算,Facebook推出的分布式SQL交互式查询引擎。
多个节点管道式执行。
支持任意数据源,包括Hive、RDBMS(Mysql、Oracle、Tidb等)、Kafka、MongoDB、Redis等。
数据规模GB~PB,是一种Massively parallel processing(mpp)(大规模并行处理)模型。
数据规模PB,并不是把PB数据放到内存,只是在计算中拿出一部分放在内存、计算、抛出、再拿、再计算。
Presto是一个分布式的查询引擎,本身并不存储数据,但是可以接入多种数据源,并且支持跨数据源的级联查询。
Presto是一个OLAP
的工具,擅长对海量数据进行复杂的分析;但是对于OLTP
场景,并不是Presto
所擅长,所以不要把Presto当做数据库来使用。
架构
Presto
查询引擎是一个Master-Slave
的拓扑架构。
-
由一个Coordinator节点,一个Discovery Server节点,多个Worker节点组成,Discovery Server通常内嵌于Coordinator节点中。
-
Coordinator负责解析SQL语句,生成执行计划,分发执行任务给Worker节点执行。
-
Worker节点负责实际执行查询任务。Worker节点启动后向Discovery Server服务注册,Coordinator从Discovery Server获得可以正常工作的Worker节点。
-
如果配置了Hive Connector,需要配置一个Hive MetaStore服务为Presto提供Hive元信息,Worker节点与HDFS交互读取数据。
一个查询分解为多个stage 每个 stage拆分多个task,每个task处理一个or多个split ,一个task被分解为一个或多个Driver
数据模型
Presto
使用Catalog
、Schema
和Table
这3层结构来管理数据。
- Catalog:就是数据源。Hive是数据源,Mysql也是数据源,Hive 和Mysql都是数据源类型,可以连接多个Hive和多个Mysql,每个连接都有一个名字。一个Catalog可以包含多个Schema,可以通过
show catalogs
命令看到Presto连接的所有数据源。 - Schema:相当于一个数据库实例,一个Schema包含多张数据表。
show schemas from 'catalog_name'
可列出catalog_name下的所有schema。 - Table:数据表,与一般意义上的数据库表相同。
show tables from 'catalog_name.schema_name'
可查看'catalog_name.schema_name'
下的所有表。
在Presto中定位一张表,一般是catalog
为根,例如:一张表的全称为 hive.test_data.test,标识 hive(catalog)下的 test_data(schema)中test表。
可以简理解为:数据源的大类.数据库.数据表。
优点 & 特点
多数据源、支持SQL、扩展性(可以自己扩展新的connector)、混合计算(同一种数据源的不同库 or表;将多个数据源的数据进行合并)、高性能、流水线(pipeline)。
与其他组件的关系及对比
其他组件
hive
数据仓库、交互式略弱的查询引擎、只能访问HDFS文件磁盘
但是presto无法代替hive
Presto是一个低延迟高并发的内存计算引擎,相比Hive,执行效率要高很多。
在使用Hive数据源的时候,如果表是分区表,一定要添加分区过滤,不加分区扫描全表是一个很暴力的操作,执行效率低下并且占用大量集群资源,大家尽量避免这种写法。
Hive分区就是分目录,把一个大的数据集根据业务需要分割成更细的数据集。
presto是常驻任务,接受请求立即执行,全内存并行计算;
hive需要用yarn做资源调度,接受查询需要先申请资源,启动进程,并且中间结果会经过磁盘。
Spark SQL
基于Spark core mpp模式
kylin
cube预计算
Druid
时序、数据放内存、索引、预计算
MySQL
和MySQL
相比,首先Mysql是一个数据库,具有存储和计算分析能力,而Presto只有计算分析能力;
其次数据量方面,Mysql作为传统单点关系型数据库不能满足当前大数据量的需求,于是有各种大数据的存储和分析工具产生,Presto就是这样一个可以满足大数据量分析计算需求的一个工具。
缺点
不适合多个大表的join操作,因为presto是基于内存的,太多数据内存放不下的。
如果一个presto查询查过30分钟,那就kill吧,说明不适合,也违背了presto的实时初衷。
参考链接1:Presto简介
参考链接2:Presto
参考链接3:Presto入门介绍
参考链接4:Presto原理分析