将Trino二次开发和调试过程中遇到的问题进行记录
Trino 使用一段时间报错:
1 |
|
重启后正常,应该是发包后没有重启,后续没有出现
Presto是支持Array数据类型的,由于上层应用需要用到Array数据类型,所以当使用不支持Array数据类型的Kudu 作为存储引擎时,需要改造下Kudu 的连接器:
主要的改造思路就是,insert时将数组转换为字符串进行存储,读取时将字符串转换为数组给Presto。
在presto中几乎所有的操作都是依赖于AirLift构造的RESTful服务来完成的,包括worker节点的管理、查询语句的提交、查询状态的显示、各个task之间数据的传递等。因此presto中的RESTful服务是presto集群的基础。
presto中提供了四种类型的RESTful接口,分别是statement服务接口、query服务接口、stage服务接口、task服务接口
与sql语句相关的请求均由该服务接口处理,包括接收提交的sql语句、获取查询执行结果的语句、取消查询语句等。statement服务接口的实现类为StatementResource。
与查询相关 的RESTful请求均由query服务接口处理,包裹sql语句的提交、获取查询执行的结果、取消查询等。query服务接口实现类为QueryResource。
presto服务器进程一共有两种服务器进程:coordinator服务进程和worker服务进程
coordinator服务进程主要作用是:接收查询请求、生成查询执行计划、任务调度和worker管理
worker服务进程则执行被分解后的查询执行计划:task。
本文发表于2019年,但是presto从2013年开始就有了,2019年原作者从Facebook分道扬镳。有关这段爱恨情仇可以在trino官网(presto主流继承版本)中看到。本文的作者是presto的原作者,发表于2019年,此时presto已经是比较成熟完善的系统了,学习的价值更大。
Presto是分布式查询引擎,支持SQL负载。既能承担亚秒级别的交互式查询,也要能支持几小时的ETL任务。
主要特性是:灵活、自适应、扩展性强(支持多个外部源,包括HDFS、RDBMS、NoSQL、流处理系统)。
Presto作为交互式的查询引擎,从2013年诞生开始,已经在Facebook以及世界上众多大公司使用,以满足端上用户交互式查询分析的需求。它主要有以下特性:
SPI
全称为 (Service Provider Interface) ,是JDK内置的一种服务提供发现机制,常用于创建可扩展、可替换组件的应用程序,是java中模块化插件化的关键。
SPI 框架包含3个基本组件:
Service Interface是一组定义标准的接口和类。Service Provider是服务接口的特定实现,需要实现接口,并子类化服务本身中定义的类。java.util包下的ServiceLoader类就是SPI机制的核心类,主要功能是通过相关的类加载器扫描并加载provider的jar包,并且通过反射实例化服务的实现类。服务Provider程序可以以扩展的形式安装在Java平台的实现中,也就是说,可以将provider的jar文件放置在任何常用扩展目录中,也可以通过将其jar包添加到应用程序的类路径或通过其他一些特定于平台的方式来使使用方来调用。
ServiceLoader机制允许用户在其应用程序代码保持不变的前提下扩展程序功能或者添加新功能。例如SLF4J
本身只是API,日常编程中我们只需要使用LogFactory获得log实例,而不用关心底层是的日志实现框架是Logback还是Log4J;java.sql.Driver
是在java中定义的标准SQL服务API,如果需要从oracal数据库切换到mysql数据库,我们的数据访问层代码不需要任何修改,只需要替换掉jdbc 驱动包即可。
JDK中包含了非常多的SPI服务功能(如servlet、邮件服务、音频服务、SQL驱动,大部分位于javax),以供不同的服务厂商或者插件商基于标准定义实现自己的方案。除了能够服务于厂商或插件商,JavaSPI 也为我们实现框架扩展提供了一个不错思路。当一个功能可能会有两种以上的实现方案时,可以在应用程序中预留出 SPI 接口,剩下的适配工作便留给了开发者,这样可以在不侵入代码的前提下,通过增删依赖来扩展框架
目标:实现消息推送功能,要求后期能够切换不同推送厂商的推送服务(例如极光推送、小米推送、百度推送等等)
领导说:
“目前各个项目分散在不同的仓库中,不利于管理,需要将多个项目仓库合并到一个工程仓库来进行开发,要求保留各个仓库迁移前的commits 记录,最好还能对命名不规范的项目进行重命名”
恕我直言,可以实现!
假设要合并ABC 不同的分支到新工程X,ABC 工程作为X工程的子目录
迁移A 工程的5.0分支到新工程X的A1目录
迁移B工程的dev分支 到新工程X的B1目录
迁移C 工程的6.0分支 到新工程X的C1目录
期望:合并后的目录结构
新工程X(master分支)
.
├── A1 (原A工程的某分支)
├── B1 (原B工程的某分支)
├── C1 (原C工程的某分支)
.git
README.md
Update your browser to view this website correctly. Update my browser now