Kudu 删除表range分区
https://kudu.apache.org/docs/command_line_tools_reference.html#table-drop_range_partition
注意事项
- 一次只能删一个分区
- 分区条件必须前后精准匹配
- 可以通过
kudu table describe查看表信息（包括分区信息）：
1 | # 查看表信息，包括列、分区信息 |
Kudu 删除表range分区
Kudu表复制（表数据迁移）
Kudu 表复制（表数据迁移）
https://kudu.apache.org/docs/command_line_tools_reference.html#table-copy
注意事项：
- 要求复制表于原表的列的结构一致（不要求分区和副本一致，所以可以调整表的副本数）
- 可以先只复制表结构
- predicates 预言 大小比值 只支持数值类型，时间戳类型不支持
- 注意超时设置
write_type参数有3种：- 空字符 ，表示只复制表结构
- insert，直接插入
- upsert，更新插入
Presto执行计划 - 分发Statement到不同的QueryExecution
Presto执行计划 - 分发Statement到不同的QueryExecution
阅读源码时梳理逻辑用，无阅读价值
获取QueryExecution
queryexecution表示一次查询执行，用于启动、停止与管理一个查询，以及统计这个查询的相关信息。
在 经过Antlr 4语法解析起进行语法分析后，最终生成了一个Node，然后转成Statement，然后再包装成PreparedQuery
再看后续代码，在 dispatchQueryFactory.createDispatchQuery()方法中对不同类型的Statement 进行分发处理，其中对应的类为：QueryExecutionFactory
1 | preparedQuery = queryPreparer.prepareQuery(session, query); |
Presto查询计划
Presto执行计划-生成计划
阅读源码时梳理逻辑用，无阅读价值
在创建 dispatchQuery 的最后，返回了一个LocalDispatchQuery，其构造函数最后一个参数调用了 SqlQueryExecution 的start()方法
Presto执行计划-词法语法分析
Presto执行计划-词法语法分析
阅读源码时梳理逻辑用，无阅读价值
如果要跟可以从上一节提交查询过程中client 发送给coordinator 的提交查询API (/v1/statement)开始跟
client初始提交query后，coordinator 创建了一个Query，然后组装nextUri 后直接response了，这时候 query 尚未排队，只有当client 来请求query状态了（/v1/statement/queued/{queryId}/{slug}/{token}），这时才将其加入到调度队列中
Presto查询计划主流程和基础概念
Presto查询计划
生成查询计划
生成查询计划 分为 语法分析、词法分析、语义分析、执行计划生成、执行计划优化、执行计划分阶段执行。
基本概念
Node
经过词法和语法分析后，会生成抽象语法树（AST），该语法树中的每一个节点都是Node（SQL语句的一部分，例如select部分，where部分），Node是一个抽象类，其实现类如下图，特别庞大：
Presto提交查询
Presto提交查询
阅读源码时梳理逻辑用，无阅读价值
提交查询的流程
Presto/Trino 客户端对查询语句的提交分三个步骤：
- 从指定的文件、命令行参数或者Cli窗口中获取需要执行的SQL语句。
- 将得到的SQL语句组装成一个RESTFul 请求，发送给Coordinator，并返回处理的response
- Client 会不停地循环分配获取查询结果，返回给终端显示/返回给JDBC connect，直到查询结果完全显示
cli提交查询的入口在：client 目录下的trino-cli 工程中，入口类io.trino.cli.Trino
即席查询中的用户体验优化机制
即席数据分析中的缓存机制和离线队列机制
每一次ad-hoc查询，均是会占用有限的计算资源，而OLAP 系统在现有技术下，并不能支撑很高的查询并发，为了有效改善这个问题，在查询时间范围内数据未发生变化或者变化量小，有效运用缓存可以有效提高查询效率和用户体验
缓存机制的实现：
对SQL的查询结果进行缓存，可以在 adhoc 层 或者 api 层进行处理
- adhoc/api层可以对Query对象或者SQL进行Hash，hash值设定为缓存的key，计算完成后将查询结果存入 redis(同时需要保存最后计算时间）
- 缓存原则是越底层做合适，但缓存跟业务场景关联性强，比如有的业务场景不允许缓存误差，那么缓存设定在底层就不合适，所以adhoc需要支持多个产品或者业务，可以由api层来做缓存
- 对于已经配置好的看板，可以设置定时任务，每天凌晨可以有调度定时执行查询，查询后根据缓存机制进行缓存
- 预判场景，有些不合适缓存的尽可能不缓存，比如单纯的查明细、结果数据大、数据导出等
- 需要从界面端带一个参数：是否使用缓存，如果为true 表示可以走缓存逻辑，如果为false 则表明是用户强制刷新
- 返回给界面端的response带一个 最后计算时间
kudu安装部署异常记录
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
kudu cli 命令
kudu 管理运维常用命令
1 | service kudu-master restart |
修复replicas
1 | sudo -u kudu kudu cluster ksck master1,master2,master3 > ./ksck.out 2>&1 |
