ClickHouse环境搭建

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: ClickHouse环境搭建

1 ClickHouse 的安装

1.1 准备工作

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

1.1.2 CentOS 取消打开文件数限制

(1)在 hadoop102 的 /etc/security/limits.conf 文件的末尾加入以下内容

[careate@hadoop102 ~]$ sudo vim /etc/security/limits.conf
* soft nofile 65536
* hard nofile 65536
* soft nproc 131072
* hard nproc 131072

(3)执行同步操作

[careate@hadoop102 ~]$ sudo /home/careate/bin/xsync /etc/security/limits.conf
[careate@hadoop102 ~]$ sudo /home/careate/bin/xsync 
/etc/security/limits.d/20-nproc.conf

1.1.3 安装依赖

[careate@hadoop102 ~]$ sudo yum install -y libtool

在 hadoop103、hadoop104 上执行以上操作

[careate@hadoop102 ~]$ sudo yum install -y *unixODBC*

1.1.4 CentOS 取消 SELINUX

(1)修改/etc/selinux/config 中的 SELINUX=disabled

[careate@hadoop102 ~]$ sudo vim /etc/selinux/config
SELINUX=disabled

(2)执行同步操作

[careate@hadoop102 ~]$ sudo /home/careate/bin/xsync /etc/selinux/config

(3)重启三台服务器

1.2 单机安装

官网:https://clickhouse.tech/

下载地址:http://repo.red-soft.biz/repos/clickhouse/stable/el7/

1.2.1 在 hadoop102 的/opt/software 下创建 clickhouse 目录

[careate@hadoop102 software]$ mkdir clickhouse

1.2.2 将安装文件上传到 hadoop102 的software/clickhouse 目录下

1.2.3 将安装文件同步到 hadoop103、hadoop104

[careate@hadoop102 software]$ xsync clickhouse

1.2.4 分别在三台机子上安装这 4 个 rpm 文件

[careate@hadoop102 clickhouse]$ sudo rpm -ivh *.rpm

1.2.5 修改配置文件

[careate@hadoop102 clickhouse]$ sudo vim /etc/clickhouse-server/config.xml

(1)把 <listen_host>::</listen_host> 的注释打开,这样的话才能让 ClickHouse 被除本机以外的服务器访问

(2)分发配置文件

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

在这个文件中,有 ClickHouse 的一些默认路径配置,比较重要的

数据文件路径: /var/lib/clickhouse/

日志文件路径:/var/log/clickhouse-server/clickhouse-server.log</log

1.2.6 启动 Server

[careate@hadoop102 clickhouse]$ sudo systemctl start clickhouse-server

1.2.7 三台机器上关闭开机自启

[careate@hadoop102 clickhouse]$sudo systemctl disable clickhouse-server

1.2.8 使用 client 连接 server

[careate@hadoop102 clickhouse]$ clickhouse-client -m

-m :可以在命令窗口输入多行命令

2 副本

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

https://clickhouse.tech/docs/en/engines/table-engines/mergetree-family/replication/

2.1 副本写入流程

2.2 配置步骤

(1)启动 zookeeper 集群

(2)在 hadoop102 的/etc/clickhouse-server/config.d 目录下创建一个名为 metrika.xml

的配置文件,内容如下:

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

<?xml version="1.0"?>
<yandex>
<zookeeper-servers>
 <node index="1">
 <host>hadoop102</host>
 <port>2181</port>
 </node>
 <node index="2">
 <host>hadoop103</host>
 <port>2181</port>
 </node>
 <node index="3">
 <host>hadoop104</host>
 <port>2181</port>
 </node>
</zookeeper-servers>
</yandex>

(3)同步到 hadoop103 和 hadoop104 上

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

(4)在 hadoop102 的/etc/clickhouse-server/config.xml 中增加

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

(5)同步到 hadoop103 和 hadoop104 上

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

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

注意:因为修改了配置文件,如果以前启动了服务需要重启

[careate@hadoop102|3 ~]$ sudo clickhouse restart

注意:我们演示副本操作只需要在 hadoop102 和 hadoop103 两台服务器即可,上面的操作,我们 hadoop104 可以你不用同步,我们这里为了保证集群中资源的一致性,做了同步。

(6)在 hadoop102 和 hadoop103 上分别建表

副本只能同步数据,不能同步表结构,所以我们需要在每台机器上自己手动建表

①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);

②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);

③参数解释

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');

(8)在 hadoop103 上执行 select,可以查询出结果,说明副本配置正确

3 分片集群

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

要解决数据水平切分的问题,需要引入分片的概念。通过分片把一份完整的数据进行切分,不同的分片分布到不同的节点上,再通过 Distributed 表引擎把数据拼接起来一同使用。

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

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

3.1 集群写入流程(3 分片 2 副本共 6 个节点)

3.2 集群读取流程(3 分片 2 副本共 6 个节点)

3.3 3 分片 2 副本共 6 个节点集群配置(供参考)

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

注:也可以不创建外部文件,直接在 config.xml 的<remote_servers>中指定

<yandex>
<remote_servers>
<gmall_cluster> <!-- 集群名称--> 
<shard> <!--集群的第一个分片-->
<internal_replication>true</internal_replication>
<!--该分片的第一个副本-->
 <replica> 
 <host>hadoop101</host>
 <port>9000</port>
 </replica>
 <!--该分片的第二个副本-->
 <replica> 
 <host>hadoop102</host>
 <port>9000</port>
 </replica>
</shard>
 <shard> <!--集群的第二个分片-->
 <internal_replication>true</internal_replication>
 <replica> <!--该分片的第一个副本-->
 <host>hadoop103</host>
 <port>9000</port>
 </replica>
 <replica> <!--该分片的第二个副本-->
 <host>hadoop104</host>
 <port>9000</port>
 </replica>
 </shard>
 <shard> <!--集群的第三个分片-->
 <internal_replication>true</internal_replication>
 <replica> <!--该分片的第一个副本-->
 <host>hadoop105</host>
 <port>9000</port>
 </replica>
 <replica> <!--该分片的第二个副本-->
 <host>hadoop106</host>
 <port>9000</port>
 </replica>
 </shard>
</gmall_cluster>
</remote_servers>
</yandex>

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

3.4.1 集群及副本规划(2 个分片,只有第一个分片有副本)

3.4.2 配置步骤

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

注:也可以不创建外部文件,直接在 config.xml 的<remote_servers>中指定

<?xml version="1.0"?>
<yandex>
<remote_servers>
<gmall_cluster> <!-- 集群名称--> 
<shard> <!--集群的第一个分片--> <internal_replication>true</internal_replication>
 <replica> <!--该分片的第一个副本-->
 <host>hadoop102</host>
 <port>9000</port>
 </replica>
 <replica> <!--该分片的第二个副本-->
 <host>hadoop103</host>
 <port>9000</port>
 </replica>
</shard>
<shard> <!--集群的第二个分片-->
 <internal_replication>true</internal_replication>
 <replica> <!--该分片的第一个副本-->
 <host>hadoop104</host>
 <port>9000</port>
 </replica>
</shard>
</gmall_cluster>
</remote_servers>
<zookeeper-servers>
<node index="1">
<host>hadoop102</host>
<port>2181</port>
</node>
<node index="2">
<host>hadoop103</host>
 <port>2181</port>
</node>
<node index="3">
 <host>hadoop104</host>
 <port>2181</port>
</node>
</zookeeper-servers>
<macros>
<shard>01</shard> <!--不同机器放的分片数不一样-->
<replica>rep_1_1</replica> <!--不同机器放的副本数不一样-->
</macros>
</yandex>

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

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

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

(1)103

[careate@hadoop103 ~]$ sudo vim 
/etc/clickhouse-server/config.d/metrika-shard.xml

(2)104

[careate@hadoop104 ~]$ sudo vim 
/etc/clickhouse-server/config.d/metrika-shard.xml

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

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

[careate@hadoop102 ~]$ sudo /home/careate/bin/xsync 
/etc/clickhouse-server/config.xml

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

[careate@hadoop102 clickhouse-server]$ sudo clickhouse restart
[careate@hadoop102 clickhouse-server]$ ps -ef |grep click

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);

可以到 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));

参数含义:

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');

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

(1)分布式表

SELECT * FROM st_order_mt_all;

(2)本地表

select * from st_order_mt;

目录
相关文章
|
1月前
|
SQL 数据可视化 Linux
ClickHouse【环境搭建 03】Linux环境离线安装 clickhouse-22.3.3.44 配置参数说明+可视化界面使用(离线安装文件分享百度云盘)
ClickHouse【环境搭建 03】Linux环境离线安装 clickhouse-22.3.3.44 配置参数说明+可视化界面使用(离线安装文件分享百度云盘)
151 0
|
1月前
|
数据安全/隐私保护
ClickHouse【环境搭建 02】设置用户密码的两种方式(明文+SHA256)及新用户添加及只读模式 Cannot execute query in readonly mode 问题解决
ClickHouse【环境搭建 02】设置用户密码的两种方式(明文+SHA256)及新用户添加及只读模式 Cannot execute query in readonly mode 问题解决
166 0
|
1月前
|
Unix Linux 程序员
ClickHouse【环境搭建 01】Linux环境单机版在线安装 Code:210.DB::NetException + Init script is already running 问题处理
ClickHouse【环境搭建 01】Linux环境单机版在线安装 Code:210.DB::NetException + Init script is already running 问题处理
109 0
|
SQL 存储 数据库
12.【clickhouse】ClickHouse从入门到放弃-环境搭建
【clickhouse】ClickHouse从入门到放弃-环境搭建
12.【clickhouse】ClickHouse从入门到放弃-环境搭建
|
13天前
|
存储 关系型数据库 数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 多对一和多对多
【6月更文挑战第7天】该文探讨数据模型,比较了“多对一”和“多对多”关系。通过使用ID而不是纯文本(如region_id代替&quot;Greater Seattle Area&quot;),可以实现统一、避免歧义、简化修改、支持本地化及优化搜索。在数据库设计中,需权衡冗余和范式。文档型数据库适合一对多但处理多对多复杂,若无Join,需应用程序处理。关系型数据库则通过外键和JOIN处理这些关系。文章还提及文档模型与70年代层次模型的相似性,层次模型以树形结构限制了多对多关系处理。为克服层次模型局限,发展出了关系模型和网状模型。
19 6
|
15天前
|
XML NoSQL 数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 概念 + 数据模型
【6月更文挑战第5天】本文探讨了数据模型的分析,关注点包括数据元素、关系及不同类型的模型(关系、文档、图)与Schema模式。查询语言的考量涉及与数据模型的关联及声明式与命令式编程。数据模型从应用开发者到硬件工程师的各抽象层次中起着简化复杂性的关键作用,理想模型应具备简洁直观和可组合性。
14 2
|
12天前
|
SQL 人工智能 关系型数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 文档模型中Schema的灵活性
【6月更文挑战第8天】网状模型是层次模型的扩展,允许节点有多重父节点,但导航复杂,需要预知数据库结构。关系模型将数据组织为元组和关系,强调声明式查询,解耦查询语句与执行路径,简化了访问并通过查询优化器提高效率。文档型数据库适合树形结构数据,提供弱模式灵活性,但在Join支持和访问局部性上不如关系型。关系型数据库通过外键和Join处理多对多关系,适合高度关联数据。文档型数据库的模式灵活性体现在schema-on-read,写入时不校验,读取时解析,牺牲性能换取灵活性。适用于不同类型或结构变化的数据场景。
15 0
|
14天前
|
SQL JSON NoSQL
【DDIA笔记】【ch2】 数据模型和查询语言 -- 关系模型与文档模型
【6月更文挑战第6天】关系模型是主流数据库模型,以二维表形式展示数据,支持关系算子。分为事务型、分析型和混合型。尽管有其他模型挑战,如网状和层次模型,但关系模型仍占主导。然而,随着大数据增长和NoSQL的出现(如MongoDB、Redis),强调伸缩性、专业化查询和表达力,关系模型的局限性显现。面向对象编程与SQL的不匹配导致“阻抗不匹配”问题,ORM框架缓解但未完全解决。文档模型(如JSON)提供更自然的嵌套结构,适合表示复杂关系,具备模式灵活性和更好的数据局部性。
16 0
|
16天前
|
敏捷开发 存储 缓存
【DDIA笔记】【ch1】 可靠性、可扩展性和可维护性 -- 可维护性
【6月更文挑战第4天】本文探讨了Twitter面临的一次发推文引发的巨大写入压力问题,指出用户粉丝数分布是决定系统扩展性的关键因素。为解决此问题,Twitter采用混合策略,大部分用户推文扇出至粉丝主页时间线,而少数名人推文则单独处理。性能指标包括吞吐量、响应时间和延迟,其中高百分位响应时间对用户体验至关重要。应对负载的方法分为纵向和横向扩展,以及自动和手动调整。文章强调了可维护性的重要性,包括可操作性、简单性和可演化性,以减轻维护负担和适应变化。此外,良好设计应减少复杂性,提供预测性行为,并支持未来改动。
19 0
|
17天前
|
缓存 关系型数据库 数据库
【DDIA笔记】【ch1】 可靠性、可扩展性和可维护性 -- 可扩展性
【6月更文挑战第3天】可扩展性关乎系统应对负载增长的能力,但在产品初期过度设计可能导致失败。理解基本概念以应对可能的负载增长是必要的。衡量负载的关键指标包括日活、请求频率、数据库读写比例等。推特的扩展性挑战在于&quot;扇出&quot;,即用户关注网络的广度。两种策略包括拉取(按需查询数据库)和推送(预计算feed流)。推送方法在推特案例中更为有效,因为它减少了高流量时的实时计算压力。
22 0