presto 基本概念和架构

Presto是一款Facebook开源的MPP架构的OLAP查询引擎,可针对不同数据源执行大容量数据集的一款分布式SQL执行引擎。因为工作中接触到Presto,研究它对理解SQL Parser、常见算子的实现(如SQL中table scan,join,aggregation)、资源管理与调度、查询优化(如向量化执行、动态代码生成)、大数据下各个组件为何适用不同场景等等都有帮助。我希望通过这个系列可以了解一条SQL在大数据场景下该如何高效执行。233酱准备不定时持续更新这个系列,本文主要从Presto的使用举
摘要由CSDN通过智能技术生成

Presto是一款Facebook开源的MPP架构的OLAP查询引擎,可针对不同数据源执行大容量数据集的一款分布式SQL执行引擎。因为工作中接触到Presto,研究它对理解SQL Parser、常见算子的实现(如SQL中table scan,join,aggregation)、资源管理与调度、查询优化(如向量化执行、动态代码生成)、大数据下各个组件为何适用不同场景等等都有帮助。我希望通过这个系列可以了解一条SQL在大数据场景下该如何高效执行。233酱准备不定时持续更新这个系列,本文主要从Presto的使用举例,Presto的应用场景、Presto的基本概念三个部分来初步介绍Presto。

presto 优点:

  • 完全基于内存的并行计算,Massively parallel processing(mpp)(大规模并行处理)模型
  • 流水线
  • 本地化计算
  • 动态编译执行计划
  • 小心使用内存和数据结构
  • 类BlinkDB的近似查询
  • GC控制
  • presto数据处理能力到达PB级别,支持查询数据源有hive、kafka、cassandra、redis、mongodb、sql server等

presto 缺点:

  • No fault tolerance;当一个Query分发到多个Worker去执行时,当有一个Worker因为各种原因查询失败,那么Master会感知到,整个Query也就查询失败了,而Presto并没有重试机制,所以需要用户方实现重试机制。

  • Memory Limitations for aggregations, huge joins;比如多表join需要很大的内存,由于Presto是纯内存计算,所以当内存不够时,Presto并不会将结果dump到磁盘上,所以查询也就失败了,但最新版本的Presto已支持写磁盘操作,这个待后续测试和调研。

  • MPP(Massively Parallel Processing )架构;这个并不能说其是一个缺点,因为MPP架构就是解决大量数据分析而产生的,但是其缺点也很明显,假如我们访问的是Hive数据源,如果其中一台Worke由于load问题,数据处理很慢,那么整个查询都会受到影响,因为上游需要等待上游结果。

  presto不太支持存储过程,支持部分标准sql

  presto的查询速度比hive快5-10倍

  上面讲述了presto是什么,查询速度,现在来看看presto适合干什么

  适合:PB级海量数据复杂分析,交互式SQL查询,⽀持跨数据源查询

  不适合:多个大表的join操作,因为presto是基于内存的,多张大表在内存里可能放不下

  和hive的对比:

    hive是一个数据仓库,是一个交互式比较弱一点的查询引擎,交互式没有presto那么强,而且只能访问hdfs的数据

            presto是常驻任务,接受请求立即执行,全内存并行计算;hive需要用yarn做资源调度,接受查询需要先申请资源,启动进程,并且中间结果会经过磁盘。

    presto是一个交互式查询引擎,可以在很短的时间内返回查询结果,秒级,分钟级,能访问很多数据源

    hive在查询100Gb级别的数据时,消耗时间已经是分钟级了

    但是presto是取代不了hive的,因为p全部的数据都是在内存中,限制了在内存中的数据集大小,比如多个大表的join,这些大表是不能完全放进内存的,实际应用中,对于在presto的查询是有一定规定条件的,比比如说一个查询在presto查询超过30分钟,那就kill掉吧,说明不适合在presto上使用,主要原因是,查询过大的话,会占用整个集群的资源,这会导致你后续的查询是没有资源进行查询的,这跟presto的设计理念是冲突的,就像是你进行一个查询,但是要等个5分钟才有资源继续查询,这是很不合理的,交互式就变得弱了很多

Presto架构:

                               

 

 

 

Presto查询引擎是一个Master-Slave的架构,由一个Coordinator节点,一个Discovery Server节点,多个Worker节点组成,Discovery Server通常内嵌于Coordinator节点中。

  • Coordinator负责解析SQL语句,生成执行计划,分发执行任务给Worker节点执行。

  • Worker节点负责实际执行查询任务。

  • Discovery Server:Worker节点启动后向Discovery Server服务注册,Coordinator从Discovery Server获得可以正常工作的Worker节点。

  • 如果配置了Hive Connector,需要配置一个Hive MetaStore服务为Presto提供Hive元信息,Worker节点与HDFS交互读取数据。

一个查询分解为多个stage, 每个stage拆分多个task,每个task处理一个or多个split ,一个task被分解为一个或多个Driver。

1、基本概念

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
Presto和Spark是两种用于大数据处理的开源工具,它们在某些方面有所不同。以下是它们之间的一些区别[^1]: 1. **架构和设计**:Presto是一个分布式SQL查询引擎,它使用内存计算和分布式执行来实现高性能查询。它采用了MPP(Massively Parallel Processing)架构,将查询分解为多个任务并在多个节点上并行执行。相比之下,Spark是一个通用的大数据处理框架,它提供了分布式数据处理、机器学习和图计算等功能。Spark使用RDD(Resilient Distributed Datasets)作为其核心数据结构,并通过DAG(Directed Acyclic Graph)调度任务。 2. **查询性能**:在涉及BI类型查询时,Presto表现出色,因为它专注于快速查询和低延迟。Presto的查询优化器和执行引擎针对交互式查询进行了优化。而Spark SQL在大型分析查询方面表现出色,它利用了Spark的内存计算和分布式执行能力,适用于复杂的数据处理和分析任务。 3. **易用性和配置**:在配置方面,Presto相对较容易设置和管理。它使用基于文本的配置文件,并提供了易于理解和调整的参数。相比之下,Spark SQL的配置相对复杂,需要更多的配置和调优。 4. **应用场景**:Presto和Spark SQL都是用于处理大数据的工具,但它们在应用场景上有所不同。Presto适用于需要快速查询和低延迟的BI类型查询,例如实时分析和交互式查询。而Spark SQL适用于大型分析查询和复杂的数据处理任务,例如批处理、机器学习和图计算。 综上所述,Presto和Spark在架构、查询性能、易用性和应用场景等方面存在一些区别。选择使用哪个工具取决于具体的需求和场景。
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值