CTE：SQL with as 语法

with as 定义

CTE 即 common table express，我们常用的 with as 短语，也叫做子查询部分（subquery factoring），主要是定义一个SQL片段，该SQL片段会被整个SQL语句所用到，也有可能在union all的不同部分，作为提供数据的部分。特别对于UNION ALL比较有用，因为union all的每一个部分可能相同，但是如果每个部分都去执行一遍的话，则成本太高，所以使用with as短语，则只要执行一遍即可。如果with as短语所定义的表名被调用两次以上，则优化器会自动将with as 短语所获取的数据放入一个temp表里。

CTE（common table express）语法

WITH Common_table_express [(column_name[,n])] AS (CTE_query_definitation)

例如：

1
2
3

with events_cte as (select event_name,event_time,ip,ua from event_table where ds==20210101)

select * from events_cte

其中cte是公用表表达式，该表达式在使用上与表变量类似，只是SQL 在处理方式上不同。

Presto执行计划 - 分发Statement到不同的QueryExecution

阅读源码时梳理逻辑用，无阅读价值

获取QueryExecution

queryexecution表示一次查询执行，用于启动、停止与管理一个查询，以及统计这个查询的相关信息。

在 经过Antlr 4语法解析起进行语法分析后，最终生成了一个Node，然后转成Statement，然后再包装成PreparedQuery

再看后续代码，在 dispatchQueryFactory.createDispatchQuery()方法中对不同类型的Statement 进行分发处理，其中对应的类为：QueryExecutionFactory

1
2
3
4
5
6
7
8

 preparedQuery = queryPreparer.prepareQuery(session, query);
// .... 
DispatchQuery dispatchQuery = dispatchQueryFactory.createDispatchQuery(
                    session,
                    query,
                    preparedQuery,
                    slug,
                    selectionContext.getResourceGroupId());

Presto执行计划-生成计划

阅读源码时梳理逻辑用，无阅读价值

在创建 dispatchQuery 的最后，返回了一个LocalDispatchQuery，其构造函数最后一个参数调用了 SqlQueryExecution 的start()方法

Presto执行计划-词法语法分析

阅读源码时梳理逻辑用，无阅读价值

如果要跟可以从上一节提交查询过程中client 发送给coordinator 的提交查询API (/v1/statement)开始跟

client初始提交query后，coordinator 创建了一个Query，然后组装nextUri 后直接response了，这时候 query 尚未排队，只有当client 来请求query状态了（/v1/statement/queued/{queryId}/{slug}/{token}），这时才将其加入到调度队列中

Presto查询计划

生成查询计划

生成查询计划 分为 语法分析、词法分析、语义分析、执行计划生成、执行计划优化、执行计划分阶段执行。

基本概念

Node

经过词法和语法分析后，会生成抽象语法树（AST），该语法树中的每一个节点都是Node（SQL语句的一部分，例如select部分，where部分），Node是一个抽象类，其实现类如下图，特别庞大：

Presto提交查询

阅读源码时梳理逻辑用，无阅读价值

提交查询的流程

Presto/Trino 客户端对查询语句的提交分三个步骤：

1. 从指定的文件、命令行参数或者Cli窗口中获取需要执行的SQL语句。
2. 将得到的SQL语句组装成一个RESTFul 请求，发送给Coordinator，并返回处理的response
3. Client 会不停地循环分配获取查询结果，返回给终端显示/返回给JDBC connect，直到查询结果完全显示

cli提交查询的入口在：client 目录下的trino-cli 工程中，入口类io.trino.cli.Trino

即席数据分析中的缓存机制和离线队列机制

每一次ad-hoc查询，均是会占用有限的计算资源，而OLAP 系统在现有技术下，并不能支撑很高的查询并发，为了有效改善这个问题，在查询时间范围内数据未发生变化或者变化量小，有效运用缓存可以有效提高查询效率和用户体验

缓存机制的实现：

对SQL的查询结果进行缓存，可以在 adhoc 层 或者 api 层进行处理

1. adhoc/api层可以对Query对象或者SQL进行Hash，hash值设定为缓存的key，计算完成后将查询结果存入 redis(同时需要保存最后计算时间）
2. 缓存原则是越底层做合适，但缓存跟业务场景关联性强，比如有的业务场景不允许缓存误差，那么缓存设定在底层就不合适，所以adhoc需要支持多个产品或者业务，可以由api层来做缓存
3. 对于已经配置好的看板，可以设置定时任务，每天凌晨可以有调度定时执行查询，查询后根据缓存机制进行缓存
4. 预判场景，有些不合适缓存的尽可能不缓存，比如单纯的查明细、结果数据大、数据导出等
5. 需要从界面端带一个参数：是否使用缓存，如果为true 表示可以走缓存逻辑，如果为false 则表明是用户强制刷新
6. 返回给界面端的response带一个 最后计算时间

Java 性能诊断工具简介

在 Java 的世界里，有许多诊断工具可供选择，既包括像 jmap、jstat 这样的简单命令行工具，又包括 JVisualvm、JProfiler 等图形化综合诊断工具，同时还有 SkyWalking、ARMS 这样的针对分布式应用的性能监控系统。下面分别对其进行介绍。

简单命令行工具

JDK 内置了许多命令行工具，它们可用来获取目标 JVM 不同方面、不同层次的信息。

• jinfo - 用于实时查看和调整目标 JVM 的各项参数。
• jstack - 用于获取目标 Java 进程内的线程堆栈信息，可用来检测死锁、定位死循环等。
• jmap - 用于获取目标 Java 进程的内存相关信息，包括 Java 堆各区域的使用情况、堆中对象的统计信息、类加载信息等。
• jstat - 一款轻量级多功能监控工具，可用于获取目标 Java 进程的类加载、JIT 编译、垃圾收集、内存使用等信息。
• jcmd - 相比 jstat 功能更为全面的工具，可用于获取目标 Java 进程的性能统计、JFR、内存使用、垃圾收集、线程堆栈、JVM 运行时间等信息。

图形化综合诊断工具

使用上述命令行工具或组合能帮您获取目标 Java 应用性能相关的基础信息，但它们存在下列局限：

1. 无法获取方法级别的分析数据，如方法间的调用关系、各方法的调用次数和调用时间等（这对定位应用性能瓶颈至关重要）。
2. 要求用户登录到目标 Java 应用所在的宿主机上，使用起来不是很方便。
3. 分析数据通过终端输出，结果展示不够直观。

JVM调优参数的设置实例

其一是标准参数（-），所有的JVM实现都必须实现这些参数的功能，而且向后兼容；
其二是非标准参数（-X），默认jvm实现这些参数的功能，但是并不保证所有jvm实现都满足，且不保证向后兼容；
其三是非Stable参数（-XX），此类参数各个jvm实现会有所不同，将来可能会随时取消，需要慎重使用；

1
2
3
4

-XX:+<option> 启用option，例如：-XX:+PrintGCDetails启动打印GC信息的选项，其中+号表示true，开启的意思
-XX:-<option> 不启用option，例如：-XX:-PrintGCDetails关闭启动打印GC信息的选项，其中-号表示false，关闭的意思
-XX:<option>=<number> 设定option的值为数字类型，可跟单位，例如 32k, 1024m, 2g。例如：-XX:MaxPermSize=64m
-XX:<option>=<string> 设定option的值为字符串，例如： -XX:HeapDumpPath="C:\Users\Daxin\Desktop\jvmgcin"

GC 类型

java的gc回收的类型主要有几种 UseSerialGC，UseConcMarkSweepGC，UseParNewGC，UseParallelGC，UseParallelOldGC，UseG1GC

SerialGC(-XX:+UseSerialGC)

使用串行回收器进行回收，这个参数会使新生代和老年代都使用串行回收器，新生代使用复制算法，老年代使用标记-整理算法。Serial收集器是最基本、历史最悠久的收集器，它是一个单线程收集器。一旦回收器开始运行时，整个系统都要停止。

Client模式下默认开启，其他模式默认关闭。

kudu安装部署异常记录

init kudu failed the cpu on this system does not support sse4.2

判断主机/虚拟机是否支持 sse4_2 指令集：

1

grep -q sse4_2 /proc/cpuinfo && echo "SSE 4.2 supported" || echo "SSE 4.2 not supported“"

由于物理主机的CPU是支持该指令集的，所以只需要修改虚拟机的主机模式

Unable to init master catalog manager