ClickHouse—入门

第一章 ClickHouse入门

ClickHouse 是俄罗斯的 Yandex 于 2016 年开源的列式存储数据库（DBMS），使用 C++语言编写，主要用于在线分析处理查询（OLAP），能够使用 SQL 查询实时生成分析 数据报告

列式存储

以下面表为例

采用行式存储时，数据在磁盘上的组织结构为：

• 优势：查找某个人所有的属性时，可以通过一次磁盘查找+顺序读取就可以
• 劣势：当查找所有人的年龄时，会遍历许多不需要的数据

采用列式存储时，数据在磁盘上的组织结构为：

• 优势：
  • 对于列的聚合、计数、求和等统计操作，优于行式存储
  • 由于列的数据类型都是相同的，针对于数据存储更容易进行数据压缩，每一列选择更优的数据压缩算法，大大提高了数据的压缩比重
  • 数据压缩比更好， 节省磁盘空间、对cache也有了更大的发挥空间

DBMS的功能

几乎覆盖了标准SQL的大部分语法，包括DDL和DML，以及配套的各种函数，用户管理及权限管理，数据的备份与恢复

多样化引擎

ClickHouse和MySQL类似，把表级的存储引擎插件化，根据表的不同需求可以设定不同的存储引擎。目前包括合并树、日志、接口和其他四大类20多种引擎

高吞吐写入能力

ClickHouse采用类LSM Tree结构，数据写入后定期在后台Compaction。通过类LSM tree的结构，ClickHouse在数据导入时全部是顺序append写入，写入后数据段不可更改，在后台compaction时也是多个段merge sort后顺序写回磁盘，顺序写的特性，充分利用了磁盘的吞吐能力，即便在HDD上也有着优异的写入性能

官方公开 benchmark 测试显示能够达到 50MB-200MB/s 的写入吞吐能力，按照每 行 100Byte 估算，大约相当于 50W-200W 条/s 的写入速度

数据分区与线程级并行

ClickHouse将数据划分为多个partition，每个partition再进一步划分为多个index granularity（索引粒度），然后通过多个CPU核心分别处理其中的一部分来实现并行数据处理。在这种设计下，单条Query能利用整机所有CPU，极致的并行处理能力，极大的降低了查询延时

ClickHouse即使对于大量数据的查询也能够化整为零平行处理，但是有一个弊端就是对于单条查询使用多CPU，就不利于同时并发多条查询，故对于高qps的查询业务，ClikcHouse并不是强项

性能对比

某网站精华帖，对几款数据库做了性能对比

• 单表查询

• 关联查询

• 结论：ClickHouse像很多OLAP数据库一样，单表查询速度由于关联查询，而且ClickHouse的两者差距更为明显

第二章 ClickHosue 安装

确定防火墙处于关闭状态：

CentOS取消打开文件数限制

sudo vim /etc/security/limits.conf，在文件末尾加上以下内容

* soft nofile 65536
* hard nofile 65536
* soft nproc 131072
* hard nproc 131072
1
2
3
4

sudo vim /etc/security/limits.d/20-nproc.conf，在文件的末尾加上以下内容

* soft nofile 65536
* hard nofile 65536
* soft nproc 131072
* hard nproc 131072
1
2
3
4

安装依赖

sudo yum install -y libtool
sudo yum install -y *unixODBC*
1
2

CentOS取消SELINUX

sudo vim /etc/selinux/config

SELINUX=disabled
1

以上操作结束后，记得重启服务器

安装

官网：Fast Open-Source OLAP DBMS - ClickHouse

下载地址：Index of /repos/clickhouse/stable/el6 (red-soft.biz)

创建相应的目录make clickhouse，放ClickHouse相关的包，安装相应的文件

sudo rpm -ivh *.rpm
1

可通过sudo rpm -qa|grep clickhouse，查看安装情况

修改配置文件

sudo vim /etc/clickhouse-server/config.xml，将 ::注释打开，这样ClickHouse才能被除本机以外的服务器访问

在这个配置文件中，需要特别注意一些默认路径配置

• 数据文件路径：/var/lib/clickhouse/
• 日志文件路径：/var/log/clickhouse-server/clickhouse-server.log

启动Server

sudo systemctl start clickhouse-server
1

关闭开机自启sudo systemctl disable clickhouse-server

使用client连接serverclickhouse-client -m

第三章 数据类型

整型

固定长度的整型，包括有符号整型或无符号整型

整型范围：（-2^(n-1) ~ 2^(n-1)-1）

• Int8：[-128 ~ 127]
• Int16：[-32768 ~ 32767]
• Int32：[-2147483648 ~ 2147483647]
• Int64：[-9223372036854775808 ~ 9223372036854775807]

无符号整型：（0 ~ 2^n - 1）

• UInt8：[0 ~ 255]
• UInt16：[0 ~ 65535]
• UInt32：[0 ~ 4294967295]
• UInt64：[0 ~ 18446744073709551615]

使用场景：个数、数量、存储型ID

浮点型

• Float32：float
• Float64：double

尽可能以整数形式存储数据，例如，将固定精度的数字转换为整数值，如时间用毫秒为单位表示，浮点型进行计算可能引起四舍五入的误差

使用场景：数据值较小，不涉及大量的统计计算，精度要求不高时。例如，保存商品的重量

布尔型

没有单独类型来存储布尔值，可使用UnIt8类型，取值限制为0或1

Decimal型

有符号的浮点数，可在加、减、乘法运算过程中保持精度，对于除法，最低有效数字会被丢弃

有三种声明（s标识小数位）：

• Decimal32(s)：相当于Decimal(9-s,s)，有效位数为 1 ~ 9
• Decimal64(s)：相当于 Decimal(18-s,s)，有效位数为 1 ~ 18
• Decimal128(s)，相当于 Decimal(38-s,s)，有效位数为 1 ~ 38

使用场景：一般金额字段、汇率、利率等字段为了保证小数点精度，都使用Decimal进行存储

字符串

String：字符串可以任意长度。它可以包含任意的字符集，包括空字节

FixedString（N）：固定长度N的字符串，N必须是严格的正自然数，当服务端读取长度小于N的字符串时，通过在字符串末尾添加空字节来达到N字节长度。当服务端读取长度大于N的字符串时，将返回错误消息

使用场景：名称、文字描述、字符型编码。固定长度的可以保存一些定长的内容，比如一些编码，性别等但是考虑到一定的变化风险，带来收益不够明显，所以定长字符串使用意义有限

枚举类型

Enum保存 ‘string’ = integer 的对应关系

• Enum8：用 ‘String’ = Int8 对描述
• Enum16：用 ‘String’ = Int16 对描述

使用场景：对一些状态、类型的字段算是一种空间优化，也算是一种数据约束，但是实际使用中往往因为一些数据内容的变化增加一定的维护成本，甚至是数据丢失问题，谨慎使用

时间类型

ClickHouse的三种时间类型

• Date：接受年-月-日的字符串，如’2019-12-16’
• Datetime：接受年-月-日 时:分:秒的字符串，如’2019-12-16 20:50:10’
• Datetime64：接受年-月-日 时:分:秒.亚秒的字符串，如’2019-12-16 20:50:10.66’

日期类型，用两个字节存储，表示从1970-01-01到当前的日期值

数组

Array(T)：由T类型元素组成的数组

T可以是任意类型，包含数组类型，但不推荐使用多维数组，比如ClickHouse对多维数组的支持有限

不能在MergeTree表中存储多维数组

创建数组方式一，使用array函数
SELECT array(1, 2) AS x, toTypeName(x) ;

创建数组方式二，使用方括号
SELECT [1, 2] AS x, toTypeName(x);
1
2
3
4
5

第四章 表引擎

表引擎的使用

表引擎是ClickHouse的一大特色。表引擎决定了如何存储表的数据，包括：

• 数据的存储方式、位置，写到哪里以及从哪里读取数据
• 支持哪些查询以及如何支持
• 并发数据访问
• 索引的使用（如果存在）
• 是否可以执行多线程请求
• 数据复制参数

表引擎的使用方式，必须显示在创建表时定义该表使用的引擎，以及引擎使用的相关参数

特别注意：引擎的名称大小写敏感

TinyLog

以列文件的形式保存在磁盘上，不支持索引，没有并发控制。一般保存少量数据的小表，生产环境上作用有限，可以用于平时练习测试用

create table t_tinylog ( id String, name String) engine=TinyLog;
1

Memory

内存引擎，数据以未压缩的原始形式直接保存在内存当中，服务器重启数据就会消失。读写操作不会相互阻塞，不支持索引。简单查询下有非常高的性能表现（超过10G/s）

一般用到它的地方不多，除了用来测试，就是在需求非常高的性能，同时数据流不太大（上限大概1亿行）的场景

MergeTree（重点）

ClickHouse中最强的的表引擎当属MergeTree（合并树）引擎及该系列（*MergeTree）中其他引擎，支持索引和分区，地位相当于innodb之于Mysql，而且基于MergeTree衍生了很多小弟，是非常有特色的引擎

create table t_order_mt(
     id UInt32,
     sku_id String,
     total_amount Decimal(16,2),
     create_time Datetime
) engine =MergeTree
     partition by toYYYYMMDD(create_time)
     primary key (id)
     order by (id,sku_id);
1
2
3
4
5
6
7
8
9

Merge还有很多其他参数（绝大多数用默认值即可），但是上面三个参数是需要特别关注的：partion by、primary key、order by

partition by 分区（可选）

作用：降低扫描范围，优化查询速度

若不填：只会使用一个分区

分区目录：MergeTree以列文件 + 索引文件 + 表定义文件组成，若设定了分区那这些文件就会保存到不同的分区目录中

并行：分区后，面对涉及分区的查询统计，ClickHouse会以分区为单位进行并行处理

数据写入与分区合并：任何一个批次的数据写入都会产生一个临时分区，不会纳入任何一个已有的分区，写入后的某个时刻（大概10-15分钟后），ClickHouse会自动执行合并操作（也可手动 optimize执行），临时把分区的数据，合并到已有的分区中
optimize table xxxx final;
1
2
3
4
5
6
7
8
9
10

primary key主键（可选）

ClickHouse中的主键，和其他数据库不太一样，它只提供了数据的一级索引，但是却不是唯一约束，这意味着可以存在相同primary key的数据

主键的设定主要依据：是查询语句中的where条件

根据条件通过对主键进行某种形式的二分查找，能够定位到对应的index granularity，避免了全表扫描

index granularity：索引粒度，指在稀疏索引中两个相邻索引对应数据的间隔。ClickHouse中的MergeTree默认是8192，官方不建议修改此值，除非该列存在大量重复值，比如在一个分区中几万行才有一个不同数据

稀疏索引：可以用很少的索引数据，定位更多的数据，代价就是只能定位到索引粒度的第一行，然后再进行一点扫描
1
2
3
4
5
6
7
8
9

order by（必选）

order by设定了分区内的数据按照哪些字段顺序进行了有序保存

order by是MergeTree中唯一一个必填项，甚至比primary key还重要，当用户不设置主键的情况下，很多处理会依照order by字段进行处理
	要求：主键必须是order by字段的前缀字段
1
2
3
4

二级索引

目前在 ClickHouse 的官网上二级索引的功能在 v20.1.2.4 之前是被标注为实验性的，在这个版本之后默认是开启的

老版本使用二级索引前需要增加设置：set allow_experimental_data_skipping_indices=1;
1
2
3

数据TTL

TTL（Time To Live），MergeTree提供了可以管理数据表或者列的生命周期功能
1）列级别TTL
    create table t_order_mt3(
         id UInt32,
         sku_id String,
         total_amount Decimal(16,2) TTL create_time+interval 10 SECOND,
         create_time Datetime 
    ) engine =MergeTree
        partition by toYYYYMMDD(create_time)
         primary key (id)
         order by (id, sku_id);
total_amount 字段数据会在到期后归0

2）表级TTL
alter table t_order_mt3 MODIFY TTL create_time + INTERVAL 10 SECOND;
create_time再10秒后丢失
	涉及判断的字段必须是Date、Datetime类型，推荐使用分区的日期字段
	-SECOND、MINUTE、HOUR、DAY、WEEK、MONTH、QUARTER、YEAR
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

ReplacingMergeTree

MergeTree的一个变种，它存储特性完全继承MergeTree，但多了一个去重功能

• 去重时机：数据的去重只会再合并的过程中出现。合并会在未知时间的后台中进行，所以你无法预先作出计划，有一些数据可能仍被处理
• 去重范围：若表经过了分区，去重只会在分区内部进行去重，不能执行跨分区的去重
  • ReplacingMergeTree 能力有限，适用于在后台清除重复的数据以节省空间，但是它不保证没有重复的数据出现

create table t_order_rmt(
     id UInt32,
     sku_id String,
     total_amount Decimal(16,2) ,
     create_time Datetime 
) engine =ReplacingMergeTree(create_time)
     partition by toYYYYMMDD(create_time)
     primary key (id)
     order by (id, sku_id);

ReplacingMergeTree() 填入的参数为版本字段，重复数据保留版本字段值最大的
如果不填版本字段，默认按照插入顺序保留最后一条
1
2
3
4
5
6
7
8
9
10
11
12

SummingMergeTree

对于不查询明细，只关心以维度进行汇总聚合结果的场景，若只使用普通的MergeTree，无论是存储空间的开销，还是查询临时聚合的开销都比较大

ClickHouse为了这种场景，提供了一种能够"预聚合"的引擎SummingMergeTree

create table t_order_smt(
 id UInt32,
 sku_id String,
 total_amount Decimal(16,2) ,
 create_time Datetime 
) engine =SummingMergeTree(total_amount)
 partition by toYYYYMMDD(create_time)
 primary key (id)
 order by (id,sku_id );
 
 -以SummingMergeTree()中指定的列作为汇总数据列
 -可以填写多列，必须为数字列，若不填，以所有非维度列且为数字列的字段为汇总数据列
 -以order by的列为准，作为维度列
 -其他的列按插入顺序保留第一行
 -不在一个分区的数据不会被聚合
 -只有在同一批次插入或分片合并时才会进行聚合
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

第五章 SQL操作

基本上传统关系型数据库（以MySQL为例）的SQL语句，ClickHouse基本都支持，以下是ClickHouse和标准SQL（MySQL）不一致的地方

Insert

基于于标准SQL一致

1、标准
insert into [table_name] values(…),(….) 

2、从表到表的插入
insert into [table_name] select a,b,c from [table_name_2]
1
2
3
4
5

Update和Delete

ClickHouse提供了Delete、Update的能力，这类操作被称为Mutation查询，它可以看作Alter的一种

虽然可以实现修改、删除，但是和一般的OLTP数据库不一样，Mutation语句是一种很"重"的操作，而且不支持事务

重的原因主要是每次修改、删除都会导致放弃目标数据的原有分区，重建新分区，故应尽量做批量变更，不要进行频繁小数据的操作

1、删除操作
alter table t_order_smt delete where sku_id ='sku_001';

2、修改操作
alter table t_order_smt update total_amount=toDecimal32(2000.00,2) where id =102;
1
2
3
4
5

由于操作比较重，所以Mutation语句分两步执行，同步执行的部分只是进行新增数据分区，并把旧分区打上逻辑上的失效标记。直到触发分区合并的时候，才会删除就数据释放磁盘空间，一般不会开放这样的功能给用户，由管理员完成。

查询操作

基本上与标准SQL差别不大

• 支持子查询
• 支持CTE（Common table Expression 公用表达式with 子句）
• 支持各种JOIN，但是JOIN操作无法使用缓存，所以即使是两次相同的JOIN语句，ClickHouse也会视为两条新SQL
• 窗口函数
• 不支持自定义函数
• GROUP BY操作增加了 with rollup\with cube\with total用来计算小计和总计

alter操作

与MySQL修改字段基本一致

1、新增字段
alter table tableName add column newcolname String after col1;

2、修改字段
alter table tableName modify column newcolname String;

3、删除字段
alter table tableName drop column newcolname;
1
2
3
4
5
6
7
8

导出数据

clickhouse-client --query "select * from t_order_mt where create_time='2020-06-01 12:00:00'" --format CSVWithNames> 
/opt/module/data/rs1.csv
1
2

更多支持格式，参照：Formats for Input and Output Data | ClickHouse Docs

第六章 副本

副本的主要目的是保障数据的高可用性，即使一台 ClickHouse 节点宕机，那么也可以从其他服务器获得相同的数据

数据复制|ClickHouse Docs

副本写入流程

配置步骤

（1）启动 zookeeper集群

（2）在 hadoop102 的/etc/clickhouse-server/config.d 目录下创建一个名为 metrika.xml 的配置文件,内容如下（注：也可以不创建外部文件，直接在 config.xml 中指定）：

<yandex>
    <zookeeper-servers>
     <node index="1">
         <host>hadoop102host>
         <port>2181port>
     node>
     <node index="2">
         <host>hadoop103host>
         <port>2181port>
     node>
     <node index="3">
         <host>hadoop104host>
         <port>2181port>
     node>
    zookeeper-servers>
yandex>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

（3）同步到 hadoop103、hadoop104上

sudo /home/atguigu/bin/xsync /etc/clickhouse-server/config.d/metrika.xml
1

（4）在 hadoop102 的/etc/clickhouse-server/config.xml 中增加

<zookeeper incl="zookeeper-servers" optional="true" />
<include_from>/etc/clickhouse-server/config.d/metrika.xmlinclude_from>
1
2

（5) 同步到hadoop103、hadoop104上

sudo /home/atguigu/bin/xsync /etc/clickhouse-server/config.xml
1

分别在 hadoop102 和 hadoop103 上启动 ClickHouse 服务

注意：因为修改了配置文件，若一起启动了服务需要重启

sudo clickhouse restart
1

注意：我们演示副本操作只需要在 hadoop102 和 hadoop103 两台服务器即可

（6）副本只能同步数据，不能同步表结构，故我们需要在每台机器上自己手动建表

在hadoop102

create table t_order_rep2 (
 id UInt32,
 sku_id String,
 total_amount Decimal(16,2),
 create_time Datetime
) engine =ReplicatedMergeTree('/clickhouse/table/01/t_order_rep','rep_102')
 partition by toYYYYMMDD(create_time)
 primary key (id)
 order by (id,sku_id);
1
2
3
4
5
6
7
8
9

在hadoop103上

create table t_order_rep2 (
 id UInt32,
 sku_id String,
 total_amount Decimal(16,2),
 create_time Datetime
) engine =ReplicatedMergeTree('/clickhouse/table/01/t_order_rep','rep_103')
 partition by toYYYYMMDD(create_time)
 primary key (id)
 order by (id,sku_id);
1
2
3
4
5
6
7
8
9

ReplicatedMergeTree的参数解释

• 第一个参数：分片的 zk_path 一般按照：/clickhouse/table/{shard}/{table_name} 的格式写，如果只有一个分片就写 01 即可
• 第二个参数：副本名称，相同的分片副本名称不能相同

（7）在hadoop102执行insert语句

insert into t_order_rep2 values
(101,'sku_001',1000.00,'2020-06-01 12:00:00'),
(102,'sku_002',2000.00,'2020-06-01 12:00:00'),
(103,'sku_004',2500.00,'2020-06-01 12:00:00'),
(104,'sku_002',2000.00,'2020-06-01 12:00:00'),
(105,'sku_003',600.00,'2020-06-02 12:00:00');
1
2
3
4
5
6

（8）hadoop103 上执行 select，可以查询出结果，说明副本配置正确

select * from t_order_rep;
1

第七章 分片集群

副本虽然能够提高数据的可用性，降低丢失风险，但是每台服务器实际上必须容纳全量数据，对数据的横向扩容没有解决

副本虽然能够提高数据的可用性，降低丢失风险，但是每台服务器实际上必须容纳全量数据，对数据的横向扩容没有解决

Distributed 表引擎本身不存储数据，有点类似于 MyCat 之于 MySql，成为一种中间件， 通过分布式逻辑表来写入、分发、路由来操作多台节点不同分片的分布式数据

注意：ClickHouse 的集群是表级别的，实际企业中，大部分做了高可用，但是没有用分片，避免降低查询性能以及操作集群的复杂性

集群写入流程（3分片2副本共6个节点）

集群读取流程（3 分片 2 副本共 6 个节点）

3 分片 2 副本共 6 个节点集群配置（供参考）

配置的位置还是在之前的/etc/clickhouse-server/config.d/metrika.xml，内容如下

注意：注：也可以不创建外部文件，直接在 config.xml 的中指定

<yandex>
    <remote_servers>
        <gmall_cluster>  
        <shard> 
            <internal_replication>trueinternal_replication>
            
             <replica> 
                 <host>hadoop101host>
                 <port>9000port>
             replica>
             
             <replica> 
                 <host>hadoop102host>
                 <port>9000port>
             replica>
        shard>
         <shard> 
             <internal_replication>trueinternal_replication>
             <replica> 
                 <host>hadoop103host>
                 <port>9000port>
             replica>
             <replica> 
                 <host>hadoop104host>
                 <port>9000port>
             replica>
         shard>
         <shard> 
             <internal_replication>trueinternal_replication>
             <replica> 
                 <host>hadoop105host>
                 <port>9000port>
             replica>
             <replica> 
                 <host>hadoop106host>
                 <port>9000port>
             replica>
         shard>
        gmall_cluster>
    remote_servers>
yandex>
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
35
36
37
38
39
40
41

配置三节点版本集群及副本

集群及副本规划（2 个分片，只有第一个分片有副本）

配置步骤

1）在 hadoop102 的/etc/clickhouse-server/config.d 目录下创建 metrika-shard.xml 文件

注：也可以不创建外部文件，直接在 config.xml 的中指定

<yandex>
    <remote_servers>
        <gmall_cluster>  
        <shard> 
            <internal_replication>trueinternal_replication>
             <replica> 
                 <host>hadoop102host>
                 <port>9000port>
             replica>
             <replica> 
                 <host>hadoop103host>
                 <port>9000port>
             replica>
        shard>
        <shard> 
             <internal_replication>trueinternal_replication>
             <replica> 
                 <host>hadoop104host>
                 <port>9000port>
             replica>
        gmall_cluster>
    remote_servers>
        
    <zookeeper-servers>
        <node index="1">
            <host>hadoop102host>
            <port>2181port>
        node>
        <node index="2">
            <host>hadoop103host>
            <port>2181port>
        node>
        <node index="3">
             <host>hadoop104host>
             <port>2181port>
        node>
    zookeeper-servers>
        
    <macros>
    <shard>01shard> 
    <replica>rep_1_1replica> 
    macros>
yandex>
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
35
36
37
38
39
40
41
42
43
44
45

2）将 hadoop102 的 metrika-shard.xml 同步到 103 和 104

sudo /home/yingzi/bin/xsync /etc/clickhouse-server/config.d/metrika-shard.xml
1

3）修改 103 和 104 中 metrika-shard.xml 宏的配置

hadoop103>sudo vim /etc/clickhouse-server/config.d/metrika-shard.xml
1

hadoop104>sudo vim /etc/clickhouse-server/config.d/metrika-shard.xml
1

4）在 hadoop102 上修改/etc/clickhouse-server/config.xml

5）同步/etc/clickhouse-server/config.xml 到 103 和 104

sudo /home/atguigu/bin/xsync /etc/clickhouse-server/config.xml
1

6）重启三台服务器上的 ClickHouse 服务

sudo clickhouse restart
ps -ef |grep click
1
2

7）在 hadoop102 上执行建表语句

• 会自动同步到 hadoop103 和 hadoop104 上
• 集群名字要和配置文件中的一致
• 分片和副本名称从配置文件的宏定义中获取

create table st_order_mt on cluster gmall_cluster (
 id UInt32,
 sku_id String,
 total_amount Decimal(16,2),
 create_time Datetime
) engine 
=ReplicatedMergeTree('/clickhouse/tables/{shard}/st_order_mt','{replica}')
 partition by toYYYYMMDD(create_time)
 primary key (id)
 order by (id,sku_id);
1
2
3
4
5
6
7
8
9
10

可以到 hadoop103 和 hadoop104 上查看表是否创建成功

8）在 hadoop102 上创建 Distribute 分布式表

create table st_order_mt_all2 on cluster gmall_cluster
(
 id UInt32
 sku_id String,
 total_amount Decimal(16,2),
 create_time Datetime
)engine = Distributed(gmall_cluster,default, st_order_mt,hiveHash(sku_id));

1
2
3
4
5
6
7
8

参数含义：

• Distributed（集群名称，库名，本地表名，分片键）
• 分片键必须是整型数字，所以用 hiveHash 函数转换，也可以 rand()

9）在 hadoop102 上插入测试数据

insert into st_order_mt_all2 values
(201,'sku_001',1000.00,'2020-06-01 12:00:00') ,
(202,'sku_002',2000.00,'2020-06-01 12:00:00'),
(203,'sku_004',2500.00,'2020-06-01 12:00:00'),
(204,'sku_002',2000.00,'2020-06-01 12:00:00'),
(205,'sku_003',600.00,'2020-06-02 12:00:00');
1
2
3
4
5
6

10）通过查询分布式表和本地表观察输出结果

（1）分布式表
SELECT * FROM st_order_mt_all;

（2）本地表
select * from st_order_mt;
1
2
3
4
5