ClickHouse-管理与运维

简介

本文将对 ClickHouse 管理与运维相关的知识进行说明，主要包含用户、权限、熔断机制、数据备份和服务监控等知识。

---

用户配置

user.xml 配置文件默认位于 /etc/clickhouse-server 路径下，ClickHouse 使用他来定义用户相关的配置项，包括系统参数的设定、用户的定义、权限以及熔断机制等。

用户 profile

用户 profile 的作用类似于用户角色，可以预先在 user.xml 中为 ClickHouse 定义多组 profile，并为每组 profile 定义不同的配置项，以实现配置得到复用。

<yandex>
	<profiles> <!-- 配置 profile -->
		<default> <!-- 用户自定义角色 -->
			<max_memory_usage>100000000</max_memory_usage>
			<use_uncompressed_cache>0</use_uncompressed_cache>
		</default>
		<test1> <!-- 自定义名称，默认角色 -->
			<allow_experimental_live_view>1</allow_experimental_live_view>
			<ddistributed_product_mode>allow</ddistributed_product_mode>
		</test1>
	</profiles>
</yandex>

另外 profile 配置支持继承，实现继承的方式是在定义中引用其他的 profile 名称：

<normal_inherit>
	<profile>test1</profile>
	<profile>test2</profile>
	<distributed_product_mode>deny</distributed_product_mode>
</normal_inherit>

配置约束

constraints 标签可以设置一组约束条件，以保障 profile 内的参数值不会被随意修改。约束条件有如下三种规则：

• Min：最小值约束，在设置相应参数的时候，取值不能小于该阈值。
• Max：最大值约束，在设置相应参数的时候，取值不能大于该阈值。
• Readonly：只读约束，该参数值不允许被修改。

示例如下：

<profiles> <!-- 配置 profile -->
	<default> <!-- 用户自定义角色 -->
		<max_memory_usage>100000000</max_memory_usage>
		<use_uncompressed_cache>0</use_uncompressed_cache>

		<constraints>
			<max_memory_usage>
				<min>5000000</min>
				<max>10000000</max>
			</max_memory_usage>
			<distributed_product_mode>
				<readonly/>
			</distributed_product_mode>
		</constraints>
	</default>
</profiles>

用户定义

使用 users 标签可以配置自定义用户。如果打开 user.xml 配置文件，会发现已经默认配置 default 用户。定义一个新用户必须包含以下属性：

• username
username 用于指定登录用户名，这是全局唯一属性。
• password
password 用于设置登录密码，支持明文、SHA256 加密、 double_sha1 加密三种方式，可以任选其中一种进行设置。
  • 明文密码：在使用明文密码时直接使用 password 标签定义密码。
  • SHA256 加密：在使用 SHA256 加密算法时直接指定 password_sha256_hex 标签定义密码。
  • double_sha1 加密：在使用 double_sha1 加密算法的时候，则需要通过 double_sha1 标签定义密码。
• networks
networks 表示被允许登录的网络地址，用于限制用户登录的客户端地址。
• profile
  用户所使用的 profile 配置，直接引用相应的名称即可。
• quota
  用于设置该用户能够使用的资源限额，可以立即为一种熔断机制。

示例如下：

<user_test>
	<password>123456</password>
	<networks>
		<ip>::/0</ip>
	</networks>
	<profile>default</profile>
	<quota>default</quota>
</user_test>

---

权限管理

权限管理始终是一个的话题，ClickHouse 分别从访问、查询和数据等角度出发，层层递进提供了一个立体的权限体系。

访问权限

访问层控制是整个权限体系的第一层防护，它又可一步细分为两类权限。

1. 网络访问权限
   网络访问权限使用 networks 标签设置，用于限制某个用户登录的客户端地址，有 IP 地址、host 主机名称以及正则匹配三种形式，可以任选其中一种进行设置：

   • IP 地址：直接使用 IP 地址进行设置。
   • host 主机名称：通过 host 主机名称进行设置。
   • 正则匹配：通过表达式来匹配 host 名称。

2. 数据库与字典访问权限
   在客户端连入服务之后，可以进一步限制某个用户数据库和字典的访问权限，他们分别通过 allow_databases 和 allow_dictionaries 标签进行设置。如果不进行设置，则表示无任何限制。

查询权限

查询权限是整个权限体系中的第二层防护，它决定了一个用户能够执行的查询语句。查询权限可以分为以下四类：

• 读权限：包括 SELECT 、 EXISTS 、 SHOW 、 DESCRIBE 查询。
• 写权限：包括 INSERT 、 OPTIMIZE 查询。
• 设置权限：包括 SET 查询。
• DDL 权限：包括 CREATE 、 DROP 、 ALTER 、 RENAME 、 ATTACH 、 DETACH 和 TRUNCATE 查询。

以上四类权限通过以下两种配置标签控制：

• readonly：读权限、写权限和设置权限均由此标签控制，共有三种取值：
• 当取值为 0 时，不进行任何限制。
• 当取值为 1 时，只拥有读权限。
• 当取值为 2 时，拥有读权限和设置权限。
• allow_ddl：DDL 权限由此标签控制，共有两种取值：
• 当取值为 0 时，不允许 DDL 查询。
• 当取值为 1 时，允许 DDL 查询。

数据行级权限

数据权限是整个权限体系中的第三层防护，它决定了一个用户能够看到什么数据。数据权限使用 databases 标签定义，他是用户定义中的一项选填参数，databases 通过定义用户级别的查询过滤器来实现数据的行级粒度查询，规则定义如下：

<databases>
	<database_name> <!-- 数据库名称 -->
		<table_name> <!-- 表名称 -->
			<filter> id < 10 </filter> <!-- 数据过滤条件 -->
		</table_name>
	</database_name>
</databases>

对于数据权限的使用有一点需要明确，在使用这项功能之后 PREWHERE 优化将不会生效。

---

熔断机制

熔断是限制资源被过度使用的一种自我保护机制，当使用的资源达到阈值时，那正在进行的操作都会被中断。

时间周期的累计用量熔断

这种方式下系统资源的用量是按照时间周期累积统计的，当累积量达到阈值，则直到下个计算周期开始之前，该用户无法继续进行操作。这种方式通过在 user.xml 中的 quota 标签进行配置，示例如下：

<quotas>
	<default> <!-- 自定义名称 -->
		<internal>
			<duartion>3600</duartion> <!-- 时间周期 单位：秒 -->
			<queries>0</queries> <!-- 在周期内允许执行的查询次数 -->
			<errors>0</errors> <!-- 在周期内允许发生异常的次数 -->
			<result_rows>0</result_rows> <!-- 在周期内允许查询返回的结果行数 -->
			<read_rows>0</read_rows> <!-- 在周期内允许分布式查询节点读取的数据行数-->
			<execution_time>0</execution_time> <!-- 在周期内允许执行的查询时间 -->
		</internal>
	</default>
</quotas>

上述配置的 0 表示不做限制。

单次查询的用量熔断

这种方式下系统资源的用量是按照单词查询统计的，而具体的熔断规则则是由许多不同配置项组成，这些配置项需要定义在用户 profile 中。

1. 针对普通查询的熔断配置

   • max_memory_usage：在单个 ClickHouse 服务进程中，运行一次查询限制使用的最大内存量，默认值为 10GB。
   • max_memory_usage_for_user：以用户为单位进行统计，单个用户在运行查询时限制使用的最大内存量，默认值为 0，即不做限制。
   • max_memory_usage_for_all_queries：所有运行的查询累加在一起所限制的最大内存量，默认值为 0，即不做限制。

2. 针对数据写入和聚合查询相关的熔断配置

   • max_partitions_per_insert_block：在单次写入时，限制创建的最大分区个数，默认值为 100 个。
   • max_rows_to_group_by：在执行 GROUP BY 聚合查询时限制去重后聚合 KEY 的最大个数，默认值为 0，即不做限制。当超过阈值时，处理方式由 group_by_overflow_mode 参数指定。
   • group_by_overflow_mode 当 max_rows_to_group_by 熔断规则触发时，group_by_overflow_mode 会提供三种处理方式：
     • throw：抛出异常，默认值。
     • break：立即停止查询，并返回当前数据。
     • any：仅根据当前已存在的聚合 KEY 继续完成聚合查询。
   • max_bytes_before_external_group_by：在执行 GROUP BY 聚合查询时限制使用的最大内存量，默认值为 0，即不做限制。当超过阈值时，聚合查询将会进一步借用本地磁盘。

---

数据备份

前面我们学习了副本，那么还需要备份吗？当然是需要的，因为副本是不能解决误删除数据这类行为，因此 ClickHouse 提供如下几种方式。

导出文件备份

如果数据的体量较小，可以通过 dump 的形式将数据导出为本地文件。

clickhouse-client --query="select * from tast_backup" > /chbase/test_backup.csv

将备份再次导入

cat /chbase/test_backup.csv | clickhouse-client --query "insert into test_backup format TSV"

上述 dump 形式的优势在于可以利用 select 查询并筛选数据，然后按需备份。

通过快照备份

快照表实质上就是普通的数据表，通常按照业务规定的备份频率创建。

按分区备份

基于数据分区的备份，ClickHouse 目前提供了 FREEZE 和 FETCH 两种方式，使用方法可以参考之前的关键字。

---

服务监控

基于原生 ClickHouse 进行监控，可以从系统表和查询日志两方面入手。

系统表

在众多的 SYSTEM 系统表中，主要由以下三张表支撑对 ClickHouse 运行指标的查询，分别是 metrics 、 events 和 asynchronous_metrics。

1. metrics
metrics 表用于统计 ClickHouse 服务在运行时，当前正在运行的高层次的概要信息，包括正在执行的查询总次数、正在发生的合并操作总次数等。

   select * from system.metrics limit 5

2. events
events 用于统计 ClickHouse 服务在运行过程中已经执行过的高层次的累积概要信息，包括总的查询次数、总的 SELECT 查询次数等。

   select event, value from system.events limit 5

3. asynchronous_metrics
asynchronous_metrics 用于统计 ClickHouse 服务运行过程中，当前正在后台异步运行的高层次的概要信息，包括当前分配的内存、执行队列中的任务数量等。

   select * from system.asynchronous_metrics limit 5

查询日志

查询日志目前主要分为六种类型，分别从不同的角度记录 ClickHouse 的操作行为。
所有查询日志在默认配置下都是关闭状态，需要在 config.xml 配置中进行更改，在配置开启之后会自动生成相应的系统表以供查询。

1. query_log 是最常用的查询日志，记录了 ClickHouse 服务中所有已执行的查询记录，定义方式如下：

   <query_log>
   	<databases>system</databases>
   	<table>query_log</table>
   	<partition_by>toYYYYMM(event_date)</partition_by>
   	<flush_interval_milliseconds>7500</flush_interval_milliseconds>
   </query_log>

   如果需要单独为某个用户开启该功能，可以在 user.xml 的 profile 配置中使用 <log_query>1</log_query> 配置。

2. query_thread_log 记录所有线程的执行查询信息，定义方式如下：

   <query_thread_log>
   	<databases>system</databases>
   	<table>query_thread_log</table>
   	<partition_by>toYYYYMM(event_date)</partition_by>
   	<flush_interval_milliseconds>7500</flush_interval_milliseconds>
   </query_thread_log>

   如果需要单独为某个用户开启该功能，可以在 user.xml 的 profile 配置中使用 <log_query_threads>1</log_query_threads> 配置。

3. part_log 日志记录 MergeTree 系列表引擎的分区操作日志，定义方式如下：

   <part_log>
   	<databases>system</databases>
   	<table>part_log</table>
   	<flush_interval_milliseconds>7500</flush_interval_milliseconds>
   </part_log>

4. text_log 日志记录 ClickHouse 运行过程中产生的一系列打印日志，包括 INFO 、 DEBUG 和 Trace，定义方式如下：

   <text_log>
   	<databases>system</databases>
   	<table>text_log</table>
   	<flush_interval_milliseconds>7500</flush_interval_milliseconds>
   </text_log>

5. metric_log 日志用于将 system.metrics 和 system.events 中的数据汇聚到一起，定义方式如下：

   <metric_log>
   	<databases>system</databases>
   	<table>metric_log</table>
   	<flush_interval_milliseconds>7500</flush_interval_milliseconds>
   	<collect_interval_milliseconds>1000</collect_interval_milliseconds>
   </metric_log>

   其中 collect_interval_milliseconds 表示收集 metrics 和 events 数据的时间周期。

---

引用

---

个人备注

此博客内容均为作者学习所做笔记，侵删！
若转作其他用途，请注明来源！