Kudu 删除表range分区

Kudu 删除表range分区

https://kudu.apache.org/docs/command_line_tools_reference.html#table-drop_range_partition

注意事项

  1. 一次只能删一个分区
  2. 分区条件必须前后精准匹配
  3. 可以通过kudu table describe查看表信息(包括分区信息):
1
2
# 查看表信息,包括列、分区信息
kudu table describe 10.128.2.162:7051,10.128.2.72:7051,10.128.2.172:7051 bn_op_1228

Kudu表复制(表数据迁移)

Kudu 表复制(表数据迁移)

https://kudu.apache.org/docs/command_line_tools_reference.html#table-copy

注意事项:

  1. 要求复制表于原表的列的结构一致(不要求分区和副本一致,所以可以调整表的副本数)
  2. 可以先只复制表结构
  3. predicates 预言 大小比值 只支持数值类型,时间戳类型不支持
  4. 注意超时设置
  5. write_type 参数有3种:
    1. 空字符 ,表示只复制表结构
    2. insert,直接插入
    3. upsert,更新插入

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

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

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

获取QueryExecution

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

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

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

io.trino.dispatcher.DispatchManager.createQueryInternal()
1
2
3
4
5
6
7
8
 preparedQuery = queryPreparer.prepareQuery(session, query);
// ....
DispatchQuery dispatchQuery = dispatchQueryFactory.createDispatchQuery(
session,
query,
preparedQuery,
slug,
selectionContext.getResourceGroupId());

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 客户端对查询语句的提交分三个步骤:

  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带一个 最后计算时间

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安装部署异常记录

kudu 管理运维常用命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
service kudu-master restart
service kudu-tserver restart

# master server 管理界面
http://presto-1:8050/tablets

# tablet server 管理界面
http://presto-2:8051/tablet-servers

# 列出集群中的 tablet server
kudu tserver list presto-1,presto-2,presto-3

# 列出集群中的 master server
kudu master list presto-1,presto-2,presto-3

# 查看指定tserver_address的状态
kudu tserver status <tserver_address>

# 检测集群状态
sudo -u kudu kudu cluster ksck presto-1,presto-2,presto-3
sudo -u kudu kudu cluster ksck presto-1,presto-2,presto-3 > ./ksck.out 2>&1
<!-- more -->
# 检查tserver_address的状态
sudo -u kudu kudu remote_replica check <tserver_address>

# 列出所有表
kudu table list presto-1:7051,presto-2:7051,presto-3:7051

# 删除表
sudo -u kudu kudu table delete presto-1:7051,presto-2:7051,presto-3:7051 table_name
events
metrics_kudu
#
kudu remote_replica copy <tablet_id> <src_address> <dst_address> [-force_copy]

修复replicas

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
sudo -u kudu kudu cluster ksck master1,master2,master3 > ./ksck.out 2>&1
发现有56个表处于非健康状态:
==================
Errors:
==================
table consistency check error: 56 out of 183 table(s) are not healthy

举例:
在ksck.out中可以看到具体是哪个表的哪个tablet出问题了:
The consensus matrix is:
Config source | Replicas | Current term | Config index | Committed?
---------------+--------------+--------------+--------------+------------
master | A B C* | | | Yes
A | A B C* | 1427 | 2450 | Yes
B | A B C* | 1427 | 2450 | Yes
C | A B C* | 1427 | 2450 | Yes
Tablet 3689e076ed354f94a0967d1eed4b7d16 of table 'impala::dl_zz_kudu.tm_scada_hdzysj_change' is unavailable: 2 replica(s) not RUNNING
868688d5077b4e02b14a8a0a57958668: TS unavailable
0b4f24052ed74405b5d58fecd83f33e7: TS unavailable
a59cf0d8d1ed45d8b1af094f4a28d686 (xxxxx:7050): RUNNING [LEADER]

0 replicas' active configs differ from the master's.
All the peers reported by the master and tablet servers are:
A = 0b4f24052ed74405b5d58fecd83f33e7
B = 868688d5077b4e02b14a8a0a57958668
C = a59cf0d8d1ed45d8b1af094f4a28d686

可以看到只有a59cf0d8d1ed45d8b1af094f4a28d686这一个replication是好的,另外俩都不可用了。
修复命令:
sudo -u kudu kudu remote_replica unsafe_change_config xxxx:7050 3689e076ed354f94a0967d1eed4b7d16 a59cf0d8d1ed45d8b1af094f4a28d686

sudo -u kudu kudu remote_replica unsafe_change_config xxxx:7050 {tablet_id} {replica_id}
Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×