Presto杂记

数据湖（datalake）通常指的是一个巨大的HDFS或类似的分布式对象存储系统，在数据被转储到这些存储系统时，并没有特别考虑接下来应如何访问它们。Presto可以使它们成为有用的数据仓库。实际上，Facebook开发的目的就是对一个非常大的Hadoop数据仓库进行更快和更强大的查询，提供Hive和其他工具无法提供的能力。这也是Hive连接器的起源。

Facebook于2008年开源了Hive，它之后成了Apache Hive。Hive在Facebook内部被广泛用于在其巨大的Apache Hadoop集群上执行HDFS上的数据分析任务。
在Facebook开发出presto之前，所有的分析师都依赖于Hive，但Hive并不适用于这种大数据规模下的交互式查询。2012年，Facebook的Hive数据仓库已经有250PB了，它每天需要处理数百个用户的成千上万条查询，Hive逐渐到达极限，并且它无法查询其他数据源。

Facebook从零开始设计出了Presto，以便在其数据规模下快速地执行查询。
Presto不是创建一个新系统并将数据迁移过去，而是通过可插拨的连接器系统，在数据存储的本地读取数据。Hive连接器是presto最早的连接器之一,它直接查询存储在Hive数据仓库的数据。
2012年，4个Facebook工程师开始研发Presto，以满足Facebook在分析场景中对性能、扩展性和延伸性上的需求。
2013年年初，Presto的初始版本在Facebook内部生产环境上线。同年秋天，Facebook正式开源Presto。
许多其他大型互朕网公司也开始使用它，如Netflix、LinkedIn、Treasure Data等。
2018年末，Presto的创始人离开Facebook,成立了presto软件基金会，以使该项目保持协作与独立。

Presto使用Java编写，需要Java11 或以上版本。

Presto的catalog定义了用户可用的数据源。catalog将数据源中的所有schema和表暴露给Presto。数据访问是由Presto连接器执行，连接器由属性connecter.name配置。

如Presto服务端一样，Presto CLI也通过Maven中央仓库分发二进制包。

presto>
show catalogs;
show schemas from xx_catalog;
show tables from catalog.schema;
select … from cat.schema.tab;
use cat.schema;
select from tab;

presto --server ip:port --catalog xx --schema bb --debug

默认情况下，查询的结果将使用配置好的less程序分页（环境变量PRESTO_PAGER），其置为空来彻底禁用分页。

Presto是一个分布式SQL查询引擎，类似于大规模并行处理（massively parallel processing，MPP）数据库。通过在整个集群的服务器上分配处理任务来实现横向扩展，而非通过提高单台服务器性能来进行纵向扩展。

架构

Presto使用节点发现服务来发现集群中的所有节点。每个presto实例在启动时都会注册到发现服务并定期发送心跳信号。协调器就能够维护一个可用工作节点的最新列表。
为了简化部署并避免运行额外的服务，Presto的协调器通常会运行一个内嵌版的节点发现服务。因为它与Presto共享一个HTTP服务端，所以使用同一个端口。

Presto提供了服务提供者接口（service provider interface，SPI)。通过在连接器中实现SPI，Presto就可以在内部使用标准操作来连接到任意数据源并执行操作。连接器负责处理与特定数据源相关的细节。

查询计划生成过程利用了元数据SPI和数据统计SPI来创建查询计划。协调器会使用SPI直接连接到数据源，以收集有关表和其他元数据的信息。

查询分析器的职责十分复杂且横跨很多领域。它的角色相当具有技术性，但只要查询语句正确，它对用户就是不可见的。只有当一个查询违反了SQL语法，超出了用户权限或出现其他谬误时，分析器才暴露其存在。

查询计划可以被看作产生查询结果的程序。SQL是一种声明式语言：用户编写SQL查询来描述他们想要从系统中获得的数据。用户并不会像在命令式编程中那样指定处理数据和获得结果的步骤。
处理数据以获得期望结果的步骤将交由查询优化器决定。处理数据的一连串步骤通常叫作查询计划(query plan）。理论上来说，得到相同查询结果的查询计划的数量可能是指数级的。这些查询计划的性能千差万别，Presto的查询优化器会试图寻找最优计划。

Presto自己不存储数据，所以统计信息的提供依赖于连接器的实现。已经有Hive连接器可以向presto提供统计信息，经过一段时间的发展，会有更多连接器支持统计信息。
对Hive连接器来说，你可以使用以下方法收集统计信息。
使用Presto的ANALYZE命令来收集统计信息。
启用Presto在将数据写入表时收集统计信息的功能。
使用Hive的ANALYZE命令来收集统计信息。
Presto将统计信息存储在Hive Metastore中，这也是Hive存储统计信息的地方。如果你在Hive和Presto之间共享相同的表，它们会互相覆盖彼此的统计信息。

show stats for cat.schema.tab / (select *from cat…tab where year >2020)

查看集群节点状态
select * from system.runtime.nodes;

回顾Hadoop和Hive
最初，数据处理是通过编写MapReduce程序来完成的。开发者遵循一种特定的编程模型，以让数据处理能够自然地分布在集群中。这种模型运行得很好，也很稳健。
然而，编写MapReduce程序来分析问题很麻烦。对于依赖SQL和数据仓库的现有基础设施、工具和用户来说，很难迁移到MapReduce上。
Hive提供了MapReduce之外的另一种使用方式。它最初是用来在Hadoop之上提供一个SQL抽象层，从而使用类似于SQL的语法与HDFS中的数据进行交互。数据以文件的形式存储在HDFS中，通常叫作对象。这些文件使用各种格式，如ORC、Parquet等。这些文件以所设定的特定目录和文件布局来存储，如分区表和分桶表。这种布局称为Hive风格的表格式。
Hive的元数据描述了存储在HDFS中的数据如何映射到schema、表和列中，并通过SQL进行查询。这些元数据信息保存在MySQL等数据库中，可以通过Hive Meta store服务(HMS)进行访问。
Hive运行时提供了类似SQL的查询语言和分布式执行层来执行查询。运行时将查询翻译成一组可以在Hadoop集群上运行的MapReduce程序。Hive的演进使得查询可以翻译到其他的执行引擎，如Apache Tez和Spark等。
Hadoop和Hive在业界得到了广泛的应用。HDFS格式已经成为许多其他分布式存储系统所支持的格式，如Amazon S3和S3兼容的存储、Azure Data Lake Storage等

Presto的Hive连接器允许你连接到HDFS对象存储集群。它利用HMS中的元数据，查询和处理存储在HDFS中的数据。

Hive 连接器允许presto从HDFS中读写，但它并不局限于HDFS，而是可以与一般的分布式存储一起工作。目前，可以将Hive连接器配置为与HDFS、AWS S3…、S3兼容存储一起工作。S3兼容存储可能包括MinIO、Ceph…等。市面上有各种S3兼容存储，只要它们实现S3 API并且行为方式相同，那么在大多数情况下Presto就无须知道它们的区别。

Hive连接器可以被认为是使用查询对象存储的主要连接器。因此，对许多甚至大多数用户来说，它至关重要。
在架构上，Hive连接器与RBDMS和其他连接器有一点不同。它根本不使用Hive引擎本身，所以不能将SQL处理下推到Hive中。相反，Hive连接器只是使用HMS中的元数据，并使用Hadoop项目提供的HDFS客户端直接访问HDFS上的数据。它还假定数据以Hive表格式保存在分布式存储中。

无论使用什么存储系统，schema信息都是从HMS中获取的，并且数据布局也与Hive数据仓库相同。概念是一样的，数据却可能并不存储在HDFS上。与Hadoop不同的是，这些非Hadoop的分布式文件系统并非总有HMS等价物来存储元数据，以供Presto使用。要利用Hive风格的表格式，必须将Presto配置为要么使用现有Hadoop集群中的HMS，要么使用独立的HMS