presto trino 即时查询
大体来说就是OLAP中上层的一个数据查询工具，可以使用sql在这个工具里进行数据的查询分析。
hive比较慢，快的方法有
1。内存计算 presto
2。预计算 猜测出你要啥，然后你一输入就返回给你 kylin
hive一般要跑几十秒到几分钟。
presto支持的数据量是gb到pb级别的，时间是秒级查询。
嗷嗷
coordinator（协调人）是接收cli的sql请求，然后解析生成执行计划，接着分发任务到worker，coordinator和worker组成presto server。
worker就是干活的，进行并行计算的。worker计算完成之后，再返回给coordinator，然后coordinator再返回给客户端。
catalog就映射数据源，每一个数据源要配置一个catalog。每个catalog都要配置一个connector,可以支持很多数据源。
这里要使用hive meta store的原因是，使用hive数据源的话，只需要得到hive的元数据就可以了，知道有哪些表，数据在hdfs的路径就可以了。
schema就类似database.
大数据计算的思想都源于mapreduce,所以这类框架都喜欢和它对比。
mapreduce: map要落盘，reduce要落盘，这里磁盘io就很多。如果在其它节点上，还有网络io。所以就比较慢。
presto：有相应的执行计划，主要在内存当中进行计算。和spark类似。
跨数据源连表查。
优缺点
缺点是连表查询时，都要使用临时表。此时就会产生大量的临时数据，所以速度会变慢。其它框架其实也是如此。presto时部分数据先聚合得出中间数据，然后清除上一步的原始数据，接着加载后面的数据，然后继续聚合。
新版的trino需要jdk11
chmod a+x xxx 给xxx文件的所有用户加上运行权限。 a代表就是all user.
启动成功后 jps会有一个 PrestoServer 的进程。
com/facebook/presto/presto-server 历史版本下载
Unable to create input format org.apache.hadoop.mapred.FileInputFormat
https://github.com/prestodb/presto/issues/8840 试到后没用，换个版本试试。
catalog下的properties文件名就是presto里面的catalog名。也就是和数据源对应。
Presto学习笔记 228下根本没有lzo这个文件。
打开源码发现这个类在Hadoop-apache的包里，根本不是缺少包的问题，所以网上那些答案不知道是怎么来的。
问题应该是出在presto 连接 hive的过程中。 可以试试一般Java连接hive是怎么搞的。然后看看是不是hive那边的配置出了问题之类的。
ERROR: Trino requires Java 11.0.11 at minimum (found 11.0.2+9-LTS)
版本还是低了。。
mac上安装两个版本的jdk_小白以后的博客-CSDN博客
换成trino server上还是一样的结果。
查其它表是没问题的，我怀疑是这个iceberg格式的问题，我试试创建其它格式的表试试。
Iceberg Connector 自己对整个体系的理解就有问题，没有真正理解这个配置项的意义。connector相当于就是对应不同的驱动，hive使用hive-hadoop2，iceberg使用iceberg的驱动，因为iceberg就是表格式，所以select数据的时候，肯定要使用不同的协议去解析数据。我完全不理解内部的运行原理，然后浪费了那么多时间。
先看整体架构，然后按照网上教程配置，接着尽量看懂配置项的意义，然后多看看官网的说明书。 这次的阻塞主要还是自己的基础不扎实，对各个组件不熟悉，不能通过模型快速地推论出后面的逻辑关系。缺少方法和手段去调试这些数据。。。。
ps -ef | grep java | grep -v grep | awk '{print $2}' | xargs kill -9 杀死所有的Java进程。
来自：https://zhuanlan.zhihu.com/p/400751801
相关文章