论文标题：Column-Stores vs. Row-Stores: How Different Are They Really?

论文: http://www.cs.umd.edu/~abadi/papers/abadi-sigmod08.pdf

概述

从论文的标题可以看出这篇论文不是陈述一种新的技术、架构，而更偏议论文一点，它主要的目的在于搞清楚对于分析类的查询为什么Column-Store比Row-Store好那么多？好在哪里？

一般认为原因是:

分析类查询往往只查询一个表里面很少的几个字段，Column-Store只需要从磁盘读取用户查询的Column，而Row-Store读取每一条记录的时候你会把所有Column的数据读出来，在IO上Column-Store比Row-Store效率高很多，因此性能更好。

而本文的目的是要告诉你Column-Store在存储格式优势只是一方面，如果没有查询引擎上其它几个优化措施的配合，性能也不会太好的，这篇论文认为Column-Store在查询引擎层有以下几种大的优化手段:

• 块遍历(Block Iteration)
• 压缩(Compression)
• 延迟物化(Late Materialization)
• Invisible Join

其中前三点是前人就已经总结过的、在现有Column-Store上实现过了的，而最后一点是本论文的创新。下面我们一一看一下这几种优化手段的细节，最后再看看它们优化效果的对比。

什么是列式存储

在传统的行式数据库系统中，数据按如下顺序存储：

处于同一行中的数据总是被物理的存储在一起。

常见的行式数据库系统有：MySQL、Postgres和MS SQL Server。

在列式数据库系统中，数据按如下的顺序存储：

这些示例只显示了数据的排列顺序。来自不同列的值被单独存储，来自同一列的数据被存储在一起。

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 表复制（表数据迁移）

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

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

获取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

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