其他分享
首页 > 其他分享> > Presto在大数据领域的实践和探索

Presto在大数据领域的实践和探索

作者：互联网

Presto在大数据领域的实践和探索

大数据技术与架构 大数据技术与架构

小编在去年的时候，写过一篇轰动全网的文章《你需要的不是实时数仓 | 你需要的是一款强大的OLAP数据库》，这篇文章当时被各大门户网站和自媒体疯狂转载，保守阅读量也在50万+PV，在这篇文章中提到过Preto，Presto作为OLAP计算领域的一员有着独特的优势和特点。
本篇文章是作者作为Presto小白时期，经过调研、线上调试、生产环境稳定运行这个过程中大量的实践经验和资料检索，沉淀下来的一个读书笔记。本文从原理入门、线上调优、典型应用等几个方面为读者全面剖析Presto，希望对大家有帮助。

我是谁？我从哪里来？要到哪里去？

Presto is an open source distributed SQL query engine for running interactive analytic queries against data sources of all sizes ranging from gigabytes to petabytes.
Presto allows querying data where it lives, including Hive, Cassandra, relational databases or even proprietary data stores. A single Presto query can combine data from multiple sources, allowing for analytics across your entire organization.
Presto is targeted at analysts who expect response times ranging from sub-second to minutes. Presto breaks the false choice between having fast analytics using an expensive commercial solution or using a slow "free" solution that requires excessive hardware.

这是官网对Presto的定义，Presto 是由 Facebook 开源的大数据分布式 SQL 查询引擎，适用于交互式分析查询，可支持众多的数据源，包括 HDFS，RDBMS，KAFKA 等，而且提供了非常友好的接口开发数据源连接器。
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交互读取数据。

Presto的服务进程

Presto集群中有两种进程，Coordinator服务进程和worker服务进程。coordinator主要作用是接收查询请求，解析查询语句，生成查询执行计划，任务调度和worker管理。worker服务进程执行被分解的查询执行任务task。
Coordinator 服务进程部署在集群中的单独节点之中，是整个presto集群的管理节点，主要作用是接收查询请求，解析查询语句，生成查询执行计划Stage和Task并对生成的Task进行任务调度，和worker管理。Coordinator进程是整个Presto集群的master进程，需要与worker进行通信，获取最新的worker信息，有需要和client通信，接收查询请求。Coordinator提供REST服务来完成这些工作。
Presto集群中存在一个Coordinator和多个Worker节点，每个Worker节点上都会存在一个worker服务进程，主要进行数据的处理以及Task的执行。worker服务进程每隔一定的时间会发送心跳包给Coordinator。Coordinator接收到查询请求后会从当前存活的worker中选择合适的节点运行task。
Presto在大数据领域的实践和探索
上图展示了从宏观层面概括了Presto的集群组件：1个coordinator，多个worker节点。用户通过客户端连接到coordinator，可以短可以是JDBC驱动或者Presto命令行cli。
Presto是一个分布式的SQL查询引擎，组装了多个并行计算的数据库和查询引擎（这就是MPP模型的定义）。Presto不是依赖单机环境的垂直扩展性。她有能力在水平方向，把所有的处理分布到集群内的各个机器上。这意味着你可以通过添加更多节点来获得更大的处理能力。
利用这种架构，Presto查询引擎能够并行的在集群的各个机器上，处理大规模数据的SQL查询。Presto在每个节点上都是单进程的服务。多个节点都运行Presto，相互之间通过配置相互协作，组成了一个完整的Presto集群。
Presto在大数据领域的实践和探索
上图展示了集群内coordinator和worker之间，以及worker和worker之间的通信。coordinator向多个worker通信，用于分配任务，更新状态，获得最终的结果返回用户。worker之间相互通信，向任务的上游节点获取数据。所有的worker都会向数据源读取数据。

Coordinator

Coordinator的作用是：

Presto的worker是Presto集群中的一个服务。它负责运行coordinator指派给它的任务，并处理数据。worker节点通过连接器（connector）向数据源获取数据，并且相互之间可以交换数据。最终结果会传递给coordinator。coordinator负责从worker获取最终结果，并传递给客户端。
Worker之间的通信、worker和coordinator之间的通信采用基于HTTP的协议。下图展示了多个worker如何从数据源获取数据，并且合作处理数据的流程。直到某一个worker把数据提供给了coordinator。
Presto在大数据领域的实践和探索

一层一层剥开你的心之Presto数据模型

Presto采取了三层表结构，我们可以和Mysql做一下类比：

我们在选择Presto时很大一个考量就是计算速度，因为一个类似SparkSQL的计算引擎如果没有速度和效率加持，那么很快就就会被抛弃。
美团的博客中给出了这个答案：

合理设置分区

与Hive类似，Presto会根据元信息读取分区数据，合理的分区能减少Presto数据读取量，提升查询性能。

使用列式存储

Presto对ORC文件读取做了特定优化，因此在Hive中创建Presto使用的表时，建议采用ORC格式存储。相对于Parquet，Presto对ORC支持更好。

使用压缩

数据压缩可以减少节点间数据传输对IO带宽压力，对于即席查询需要快速解压，建议采用snappy压缩

预排序

对于已经排序的数据，在查询的数据过滤阶段，ORC格式支持跳过读取不必要的数据。比如对于经常需要过滤的字段可以预先排序。

内存调优

Presto有三种内存池，分别为GENERAL_POOL、RESERVED_POOL、SYSTEM_POOL。这三个内存池占用的内存大小是由下面算法进行分配的：


builder.put(RESERVED_POOL, new MemoryPool(RESERVED_POOL, config.getMaxQueryMemoryPerNode()));
builder.put(SYSTEM_POOL, new MemoryPool(SYSTEM_POOL, systemMemoryConfig.getReservedSystemMemory()));
long maxHeap = Runtime.getRuntime().maxMemory();
maxMemory = new DataSize(maxHeap - systemMemoryConfig.getReservedSystemMemory().toBytes(), BYTE);
DataSize generalPoolSize = new DataSize(Math.max(0, maxMemory.toBytes() - config.getMaxQueryMemoryPerNode().toBytes()), BYTE);
builder.put(GENERAL_POOL, new MemoryPool(GENERAL_POOL, generalPoolSize));

简单的说，RESERVED_POOL大小由config.properties里的query.max-memory-per-node指定；SYSTEM_POOL由config.properties里的resources.reserved-system-memory指定，如果不指定，默认值为Runtime.getRuntime().maxMemory() 0.4，即0.4 Xmx值；而GENERAL_POOL值为 总内存（Xmx值）- 预留的（max-memory-per-node）- 系统的（0.4 * Xmx）。
从Presto的开发手册中可以看到：


GENERAL_POOL is the memory pool used by the physical operators in a query.
SYSTEM_POOL is mostly used by the exchange buffers and readers/writers.
RESERVED_POOL is for running a large query when the general pool becomes full.

简单说GENERAL_POOL用于普通查询的physical operators；SYSTEM_POOL用于读写buffer；而RESERVED_POOL比较特殊，大部分时间里是不参与计算的，只有当同时满足如下情形下，才会被使用，然后从所有查询里获取占用内存最大的那个查询，然后将该查询放到 RESERVED_POOL 里执行，同时注意RESERVED_POOL只能用于一个Query。
我们经常遇到的几个错误：


Query exceeded per-node total memory limit of xx
适当增加query.max-total-memory-per-node。

Query exceeded distributed user memory limit of xx
适当增加query.max-memory。

Could not communicate with the remote task. The node may have crashed or be under too much load
内存不够，导致节点crash，可以查看/var/log/message。

并行度

我们可以通过调整线程数增大task的并发以提高效率。
Presto在大数据领域的实践和探索

SQL优化

这部分内容是小编参考的各大公司的行业应用进行的总结，目的是可以帮大家找到适合自己公司业务的应用方式。具体的原文可以再最后的参考链接中找到。

Presto 在滴滴的应用

滴滴 Presto 用了3年时间逐渐接入公司各大数据平台，并成为了公司首选 Ad-Hoc 查询引擎及 Hive SQL 加速引擎，支持了包含以下的业务场景：


node-scheduler.max-splits-per-node=100
node-scheduler.max-pending-splits-per-task=10

   SELECT a1, a2,..., an, F1(b1), F2(b2), F3(b3), ...., Fm(bm), F1(distinct c1), ...., Fm(distinct cm) FROM Table GROUP BY a1, a2, ..., an

       转换为

   SELECT a1, a2,..., an, arbitrary(if(group = 0, f1)),...., arbitrary(if(group = 0, fm)), F(if(group = 1, c1)), ...., F(if(group = m, cm)) FROM
       SELECT a1, a2,..., an, F1(b1) as f1, F2(b2) as f2,...., Fm(bm) as fm, c1,..., cm group FROM
         SELECT a1, a2,..., an, b1, b2, ... ,bn, c1,..., cm FROM Table GROUP BY GROUPING SETS ((a1, a2,..., an, b1, b2, ... ,bn), (a1, a2,..., an, c1), ..., ((a1, a2,..., an, cm)))
       GROUP BY a1, a2,..., an, c1,..., cm group
   GROUP BY a1, a2,..., an

但是很遗憾，Presto并没有实现这样的功能。以上就是有赞在使用Presto的一些经验。

总结

小编在学习Presto的过程中和其他的OLAP一样，也是通过漫长的文档搜索，官网摸索逐渐精进的，事实上在任何一门新技术的使用过程中大家都会遇到各种各样的问题，如果利用现在有的资料解决问题就是考验我们的时候了。
参考列表：
https://tech.meituan.com/2014/06/16/presto.html
https://blog.csdn.net/didi_tech/article/details/108989149
https://cloud.tencent.com/developer/news/606849
https://cloud.tencent.com/developer/article/1371128

标签：探索,Presto,worker,实践,查询,Coordinator,节点,POOL
来源： https://blog.51cto.com/15127517/2682956