presto主要配置文件如下： catalog/:配置各数据源的信息。presto是由开源，基于内存的分布式查询引擎。支持多数据源，可支持PB级海量数据查询，本身不作数据存储。由于基于内存查询，减少了IO开销，故查询效率很高，但不适用于多表联合查询。
拓展资料：
1、presto架构 ：
与众多分布式框架类似，由某组件进行请求处理以及分发任务至各执行节点。在presto架构中，Coordinator即为这样的角色。负责解析SQL，生成执行计划，分发任务到各节点。 Worker即各实际执行查询的节点。worker收到任务后,通过各种connector取各数据源中的数据。 Discovery service即联系Coordinator及Worker的服务。Worker启动会向Discovery server注册服务，Coordinator向Discovery server获取Worker节点信息。
2、Presto因其优秀的查询速度被我们所熟知，它本身基于MPP架构，可以快速的对Hive数据进行查询，同时支持扩展Connector，目前对Mysql、MongoDB、Cassandra、Hive等等一系列的数据库都提供了Connector进行支持。是我们常用的SQL on Hadoop的解决方案。那么我们今天就来看一下，当我们选择Presto作为我们的查询引擎之后，我们需要考虑的问题。
3、单机维度
GENERAL_POOL每次内存申请时，都会判断内存使用量是否超过了最大内存，如果超过了就报错，错误为“Query exceeded local memory limit of x”，这保护了Presto会无限申请内存，只会导致当前查询出错。同时，如果该节点的GENERAL_POOL可使用内存以及可回收内存为0，那么认为该node为Block node。RESERVED_POOL可以认为是查询最大的SQL，其能满足GENERAL_POOL的内存策略，那么肯定会满足RESERVED_POOL的策略(复用了GENERAL_POOL策略)。
4、Resource Groups
Resource Groups 可以认为是Presto实现了一个弱资源和隔离功能。其可以为每个group指定队列大小、并发大小、内存使用大小。为每个group设置合理的hardConcurrencyLimit(最大并发数)、softMemoryLimit(内存最大使用值)及maxQueued(队列大小)一方面可以使不同业务影响降低，另一方面也大概率避免OOM问题，当然善于运用user及做下二次开发，就可以让Presto支持多用户共用同一分组和权限认证功能。
