ClickHouse操作手册由以下主要部分组成：
必备条件
CPU
如果您使用预编译的DEB/RPM包安装ClickHouse，请使用支持SSE4.2指令集的x86_64架构的CPU。如果需要在不支持SSE4.2指令集的CPU上，或者在AArch64（ARM）和PowerPC64LE（IBM Power）架构上运行ClickHouse，您应该从源码编译ClickHouse。
ClickHouse实现了并行数据处理，处理时会使用所有的可用资源。在选择处理器时，请注意：ClickHouse在具有大量计算核、时钟频率稍低的平台上比计算核少、时钟频率高的平台上效率更高。例如，ClickHouse在16核 2.6GHz的CPU上运行速度高于8核 3.6GHz的CPU。
建议使用 睿频加速 和 超线程 技术。 它显着提高了正常工作负载的性能。
RAM
我们建议使用至少4GB的内存来执行重要的查询。 ClickHouse服务器可以使用很少的内存运行，但它需要一定量的内存用于处理查询。
ClickHouse所需内存取决于:
- 查询的复杂程度。
- 查询处理的数据量。
要计算所需的内存大小，您应该考虑用于GROUP BY、DISTINCT、JOIN 和其他操作所需的临时数据量。
ClickHouse可以使用外部存储器来存储临时数据。详情请见在外部存储器中分组。
交换文件
请在生产环境禁用交换文件。
存储子系统
您需要有2GB的可用磁盘空间来安装ClickHouse。
数据所需的存储空间应单独计算。预估存储容量时请考虑:
-
数据量
您可以对数据进行采样并计算每行的平均占用空间。然后将该值乘以计划存储的行数。
-
数据压缩比
要计算数据压缩比，请将样本数据写入ClickHouse，并将原始数据大小与ClickHouse实际存储的数据进行比较。例如，用户点击行为的原始数据压缩比通常为6-10。
请将原始数据的大小除以压缩比来获得实际所需存储的大小。如果您打算将数据存放于几个副本中，请将存储容量乘上副本数。
网络
如果可能的话，请使用10G或更高级别的网络。
网络带宽对于处理具有大量中间结果数据的分布式查询至关重要。此外，网络速度会影响复制过程。
软件
ClickHouse主要是为Linux系列操作系统开发的。推荐的Linux发行版是Ubuntu。您需要检查tzdata（对于Ubuntu）软件包是否在安装ClickHouse之前已经安装。
监控
可以监控到：
- 硬件资源的利用率。
- ClickHouse 服务的指标。
硬件资源利用率
ClickHouse 本身不会去监控硬件资源的状态。
强烈推荐监控以下监控项：
ClickHouse 服务的指标。
ClickHouse服务本身具有用于自我状态监视指标。
要跟踪服务器事件，请观察服务器日志。 请参阅配置文件的 logger部分。
ClickHouse 收集的指标项：
- 服务用于计算的资源占用的各种指标。
- 关于查询处理的常见统计信息。
可以在系统指标，系统事件以及系统异步指标等系统表查看所有的指标项。
可以配置ClickHouse向Graphite推送监控信息并导入指标。参考Graphite监控配置文件。在配置指标导出之前，需要参考Graphite官方教程搭建Graphite服务。
此外，您可以通过HTTP API监视服务器可用性。将HTTP GET请求发送到/ping。如果服务器可用，它将以 200 OK 响应。
要监视服务器集群的配置，应设置max_replica_delay_for_distributed_queries参数并使用HTTP资源/replicas_status。 如果副本可用，并且不延迟在其他副本之后，则对/replicas_status的请求将返回200 OK。 如果副本滞后，请求将返回503 HTTP_SERVICE_UNAVAILABLE，包括有关待办事项大小的信息。
常见问题
安装
您无法使用Apt-get从ClickHouse存储库获取Deb软件包
- 检查防火墙设置。
- 如果出于任何原因无法访问存储库，请按照开始中的描述下载软件包，并使用命令
sudo dpkg -i <packages>手动安装它们。除此之外你还需要tzdata包。
连接到服务器
可能出现的问题:
- 服务器未运行。
- 意外或错误的配置参数。
服务器未运行
检查服务器是否正在运行
命令:
$ sudo service clickhouse-server status
如果服务器没有运行，请使用以下命令启动它:
$ sudo service clickhouse-server start
检查日志
主日志 clickhouse-server 默认情况是在 /var/log/clickhouse-server/clickhouse-server.log 下。
如果服务器成功启动，您应该看到字符串:
<Information> Application: starting up.— Server started.<Information> Application: Ready for connections.— Server is running and ready for connections.
如果 clickhouse-server 启动失败与配置错误，你应该看到 <Error> 具有错误描述的字符串。 例如:
2019.01.11 15:23:25.549505 [ 45 ] {} <Error> ExternalDictionaries: Failed reloading 'event2id' external dictionary: Poco::Exception. Code: 1000, e.code() = 111, e.displayText() = Connection refused, e.what() = Connection refused
如果在文件末尾没有看到错误，请从如下字符串开始查看整个文件:
<Information> Application: starting up.
如果您尝试在服务器上启动第二个实例 clickhouse-server ，您将看到以下日志:
2019.01.11 15:25:11.151730 [ 1 ] {} <Information> : Starting ClickHouse 19.1.0 with revision 54413
2019.01.11 15:25:11.154578 [ 1 ] {} <Information> Application: starting up
2019.01.11 15:25:11.156361 [ 1 ] {} <Information> StatusFile: Status file ./status already exists - unclean restart. Contents:
PID: 8510
Started at: 2019-01-11 15:24:23
Revision: 54413
2019.01.11 15:25:11.156673 [ 1 ] {} <Error> Application: DB::Exception: Cannot lock file ./status. Another server instance in same directory is already running.
2019.01.11 15:25:11.156682 [ 1 ] {} <Information> Application: shutting down
2019.01.11 15:25:11.156686 [ 1 ] {} <Debug> Application: Uninitializing subsystem: Logging Subsystem
2019.01.11 15:25:11.156716 [ 2 ] {} <Information> BaseDaemon: Stop SignalListener thread
查看系统日志
如果你在 clickhouse-server 没有找到任何有用的信息或根本没有任何日志，您可以使用命令查看 system.d :
$ sudo journalctl -u clickhouse-server
在交互模式下启动clickhouse服务器
$ sudo -u clickhouse /usr/bin/clickhouse-server --config-file /etc/clickhouse-server/config.xml
此命令将服务器作为带有自动启动脚本标准参数的交互式应用程序启动。 在这种模式下 clickhouse-server 打印控制台中的所有事件消息。
配置参数
检查:
-
Docker设置。
如果您在IPv6网络中的Docker中运行ClickHouse，请确保
network=host被设置。 -
端点设置。
检查 listen_host 和 tcp_port 设置。
ClickHouse服务器默认情况下仅接受本地主机连接。
-
HTTP协议设置。
检查HTTP API的协议设置。
-
安全连接设置。
检查:
- tcp_port_secure 设置。
- SSL证书 设置.
连接时使用正确的参数。 例如，使用
clickhouse_client的时候使用port_secure参数 . -
用户设置。
您可能使用了错误的用户名或密码。
查询处理
如果ClickHouse无法处理查询，它会向客户端发送错误描述。 在 clickhouse-client 您可以在控制台中获得错误的描述。 如果您使用的是HTTP接口，ClickHouse会在响应正文中发送错误描述。 例如:
$ curl 'http://localhost:8123/' --data-binary "SELECT a"
Code: 47, e.displayText() = DB::Exception: Unknown identifier: a. Note that there are no tables (FROM clause) in your query, context: required_names: 'a' source_tables: table_aliases: private_aliases: column_aliases: public_columns: 'a' masked_columns: array_join_columns: source_columns: , e.what() = DB::Exception
如果你使用 clickhouse-client 时设置了 stack-trace 参数，ClickHouse返回包含错误描述的服务器堆栈跟踪信息。
您可能会看到一条关于连接中断的消息。 在这种情况下，可以重复查询。 如果每次执行查询时连接中断，请检查服务器日志中是否存在错误。
查询处理效率
如果您发现ClickHouse工作速度太慢，则需要为查询分析服务器资源和网络的负载。
您可以使用clickhouse-benchmark实用程序来分析查询。 它显示每秒处理的查询数、每秒处理的行数以及查询处理时间的百分位数。
访问权限和账户管理
ClickHouse支持基于RBAC的访问控制管理。
ClickHouse权限实体包括：
你可以通过如下方式配置权限实体：
我们建议你使用SQL工作流的方式。当然配置的方式也可以同时起作用, 所以如果你正在用服务端配置的方式来管理权限和账户，你可以平滑的切换到SQL驱动的工作流方式。
!!! note "警告" 你无法同时使用两个配置的方式来管理同一个权限实体。
用法
默认ClickHouse提供了一个 default 账号，这个账号有所有的权限，但是不能使用SQL驱动方式的访问权限和账户管理。default主要用在用户名还未设置的情况，比如从客户端登录或者执行分布式查询。在分布式查询中如果服务端或者集群没有指定用户名密码那默认的账户就会被使用。
如果你刚开始使用ClickHouse，考虑如下场景：
- 为
default用户开启SQL驱动方式的访问权限和账户管理 . - 使用
default用户登录并且创建所需要的所有用户。 不要忘记创建管理员账户 (GRANT ALL ON *.* WITH GRANT OPTION TO admin_user_account)。 - 限制
default用户的权限并且禁用SQL驱动方式的访问权限和账户管理。
当前解决方案的特性
- 你甚至可以在数据库和表不存在的时候授予权限。
- 如果表被删除，和这张表关联的特权不会被删除。这意味着如果你创建一张同名的表，所有的特权仍旧有效。如果想删除这张表关联的特权，你可以执行
REVOKE ALL PRIVILEGES ON db.table FROM ALL查询。 - 特权没有生命周期。
用户账户
用户账户是权限实体，用来授权操作ClickHouse，用户账户包含：
- 标识符信息。
- 特权用来定义用户可以执行的查询的范围。
- 可以连接到ClickHouse的主机。
- 指定或者默认的角色。
- 用户登录的时候默认的限制设置。
- 指定的设置描述。
特权可以通过GRANT查询授权给用户或者通过角色授予。如果想撤销特权，可以使用REVOKE查询。查询用户所有的特权，使用SHOW GRANTS语句。
查询管理：
设置应用规则
对于一个用户账户来说，设置可以通过多种方式配置：通过角色扮演和设置描述。对于一个登陆的账号来说，如果一个设置对应了多个不同的权限实体，这些设置的应用规则如下（优先权从高到底）：
- 用户账户设置。
- 用户账号默认的角色设置。如果这个设置配置了多个角色，那设置的应用是没有规定的顺序。
- 从设置描述分批给用户或者角色的设置。如果这个设置配置了多个角色，那设置的应用是没有规定的顺序。
- 对所有服务器有效的默认或者default profile的设置。
角色
角色是权限实体的集合，可以被授予用户账号。
角色包括：
- 特权
- 设置和限制
- 分配的角色列表
查询管理:
使用GRANT 查询可以把特权授予给角色。用REVOKE来撤回特权。
行策略
行策略是一个过滤器，用来定义哪些行数据可以被账户或者角色访问。对一个特定的表来说，行策略包括过滤器和使用这个策略的账户和角色。
查询管理：
设置描述
设置描述是设置的汇总。设置汇总包括设置和限制，当然也包括这些描述的对象：角色和账户。
查询管理:
配额
配额用来限制资源的使用情况。参考配额.
配额包括特定时间的限制条件和使用这个配额的账户和角色。
Management queries:
开启SQL驱动方式的访问权限和账户管理
-
为配置的存储设置一个目录.
ClickHouse把访问实体的相关配置存储在访问控制目录，而这个目录可以通过服务端进行配置.
-
为至少一个账户开启SQL驱动方式的访问权限和账户管理.
默认情况，SQL驱动方式的访问权限和账户管理对所有用户都是关闭的。你需要在
users.xml中配置至少一个用户，并且把权限管理的值设置为1。
数据备份
尽管 副本 可以提供针对硬件的错误防护, 但是它不能预防人为操作失误: 数据的意外删除, 错误表的删除或者错误集群上表的删除, 以及导致错误数据处理或者数据损坏的软件bug. 在很多案例中，这类意外可能会影响所有的副本. ClickHouse 有内置的保护措施可以预防一些错误 — 例如, 默认情况下 不能人工删除使用带有MergeTree引擎且包含超过50Gb数据的表. 但是，这些保护措施不能覆盖所有可能情况，并且这些措施可以被绕过。
为了有效地减少可能的人为错误，您应该 提前 仔细的准备备份和数据还原的策略.
不同公司有不同的可用资源和业务需求，因此不存在一个通用的解决方案可以应对各种情况下的ClickHouse备份和恢复。 适用于 1GB 数据的方案可能并不适用于几十 PB 数据的情况。 有多种具备各自优缺点的可能方法，将在下面对其进行讨论。最好使用几种方法而不是仅仅使用一种方法来弥补它们的各种缺点。。
!!! note "注" 需要注意的是，如果您备份了某些内容并且从未尝试过还原它，那么当您实际需要它时可能无法正常恢复（或者至少需要的时间比业务能够容忍的时间更长）。 因此，无论您选择哪种备份方法，请确保自动还原过程，并定期在备用ClickHouse群集上演练。
将源数据复制到其它地方
通常摄入到ClickHouse的数据是通过某种持久队列传递的，例如 Apache Kafka. 在这种情况下，可以配置一组额外的订阅服务器，这些订阅服务器将在写入ClickHouse时读取相同的数据流，并将其存储在冷存储中。 大多数公司已经有一些默认推荐的冷存储，可能是对象存储或分布式文件系统，如 HDFS.
文件系统快照
某些本地文件系统提供快照功能（例如, ZFS），但它们可能不是提供实时查询的最佳选择。 一个可能的解决方案是使用这种文件系统创建额外的副本，并将它们与用于SELECT 查询的 分布式 表分离。 任何修改数据的查询都无法访问此类副本上的快照。 作为回报，这些副本可能具有特殊的硬件配置，每个服务器附加更多的磁盘，这将是经济高效的。
clickhouse-copier
clickhouse-copier 是一个多功能工具，最初创建它是为了用于重新切分pb大小的表。 因为它能够在ClickHouse表和集群之间可靠地复制数据，所以它也可用于备份和还原数据。
对于较小的数据量，一个简单的 INSERT INTO ... SELECT ... 到远程表也可以工作。
part操作
ClickHouse允许使用 ALTER TABLE ... FREEZE PARTITION ... 查询以创建表分区的本地副本。 这是利用硬链接(hardlink)到 /var/lib/clickhouse/shadow/ 文件夹中实现的，所以它通常不会因为旧数据而占用额外的磁盘空间。 创建的文件副本不由ClickHouse服务器处理，所以你可以把它们留在那里：你将有一个简单的备份，不需要任何额外的外部系统，但它仍然容易出现硬件问题。 出于这个原因，最好将它们远程复制到另一个位置，然后删除本地副本。 分布式文件系统和对象存储仍然是一个不错的选择，但是具有足够大容量的正常附加文件服务器也可以工作（在这种情况下，传输将通过网络文件系统或者也许是 rsync 来进行).
数据可以使用 ALTER TABLE ... ATTACH PARTITION ... 从备份中恢复。
有关与分区操作相关的查询的详细信息，请参阅 更改文档.
第三方工具可用于自动化此方法: clickhouse-backup.
配置文件
ClickHouse支持多配置文件管理。主配置文件是/etc/clickhouse-server/config.xml。其余文件须在目录/etc/clickhouse-server/config.d。
!!! 注意： 所有配置文件必须是XML格式。此外，配置文件须有相同的根元素，通常是<clickhouse>。
主配置文件中的一些配置可以通过replace或remove属性被配置文件覆盖。
如果两者都未指定，则递归组合配置的内容，替换重复子项的值。
如果指定replace属性，则将整个元素替换为指定的元素。
如果指定remove属性，则删除该元素。
此外，配置文件还可指定"substitutions"。如果一个元素有incl属性，则文件中的相应替换值将被使用。默认情况下，具有替换的文件的路径为/etc/metrika.xml。这可以在服务配置中的include_from元素中被修改。替换值在这个文件的/clickhouse/substitution_name元素中被指定。如果incl中指定的替换值不存在，则将其记录在日志中。为防止ClickHouse记录丢失的替换，请指定optional="true"属性（例如，宏设置）。
替换也可以从ZooKeeper执行。为此，请指定属性from_zk = "/path/to/node"。元素值被替换为ZooKeeper节点/path/to/node的内容。您还可以将整个XML子树放在ZooKeeper节点上，并将其完全插入到源元素中。
config.xml 文件可以指定单独的配置文件用于配置用户设置、配置文件及配额。可在users_config元素中指定其配置文件相对路径。其默认值是users.xml。如果users_config被省略，用户设置，配置文件和配额则直接在config.xml中指定。
用户配置可以分为如config.xml和config.d/等形式的单独配置文件。目录名称为配置user_config的值，去掉.xml后缀并与添加.d。由于users_config配置默认值为users.xml，所以目录名默认使用users.d。例如，您可以为每个用户有单独的配置文件，如下所示：
$ cat /etc/clickhouse-server/users.d/alice.xml
<clickhouse>
<users>
<alice>
<profile>analytics</profile>
<networks>
<ip>::/0</ip>
</networks>
<password_sha256_hex>...</password_sha256_hex>
<quota>analytics</quota>
</alice>
</users>
</clickhouse>
对于每个配置文件，服务器还会在启动时生成 file-preprocessed.xml 文件。这些文件包含所有已完成的替换和复盖，并且它们旨在提供信息。如果zookeeper替换在配置文件中使用，但ZooKeeper在服务器启动时不可用，则服务器将从预处理的文件中加载配置。
服务器跟踪配置文件中的更改，以及执行替换和复盖时使用的文件和ZooKeeper节点，并动态重新加载用户和集群的设置。 这意味着您可以在不重新启动服务器的情况下修改群集、用户及其设置。
使用建议
CPU频率调节器
始终使用 performance 频率调节器。 on-demand 频率调节器在持续高需求的情况下，效果更差。
echo 'performance' | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
CPU限制
处理器可能会过热。 使用 dmesg 查看CPU的时钟速率是否由于过热而受到限制。 该限制也可以在数据中心级别外部设置。 您可以使用 turbostat 在负载下对其进行监控。
RAM
对于少量数据（压缩后约200GB），最好使用与数据量一样多的内存。 对于大量数据，以及在处理交互式（在线）查询时，应使用合理数量的RAM（128GB或更多），以便热数据子集适合页面缓存。 即使对于每台服务器约50TB的数据量，与64GB相比，使用128GB的RAM也可以显着提高查询性能。
不要禁用 overcommit。cat /proc/sys/vm/overcommit_memory 的值应该为0或1。运行
$ echo 0 | sudo tee /proc/sys/vm/overcommit_memory
大页(Huge Pages)
始终禁用透明大页(transparent huge pages)。 它会干扰内存分配器，从而导致显着的性能下降。
echo 'never' | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
使用 perf top 来查看内核在内存管理上花费的时间。 永久大页(permanent huge pages)也不需要被分配。
存储子系统
如果您的预算允许您使用SSD，请使用SSD。 如果没有，请使用硬盘。 SATA硬盘7200转就行了。
优先选择许多带有本地硬盘驱动器的服务器，而不是少量带有附加磁盘架的服务器。 但是对于存储极少查询的档案，架子可以使用。
RAID
当使用硬盘，你可以结合他们的RAID-10，RAID-5，RAID-6或RAID-50。 对于Linux，软件RAID更好（使用 mdadm). 我们不建议使用LVM。 当创建RAID-10，选择 far 布局。 如果您的预算允许，请选择RAID-10。
如果您有4个以上的磁盘，请使用RAID-6（首选）或RAID-50，而不是RAID-5。 当使用RAID-5、RAID-6或RAID-50时，始终增加stripe_cache_size，因为默认值通常不是最佳选择。
echo 4096 | sudo tee /sys/block/md2/md/stripe_cache_size
使用以下公式从设备数量和块大小中计算出确切的数量: 2 * num_devices * chunk_size_in_bytes / 4096。
1024KB的块大小足以满足所有RAID配置。 切勿将块大小设置得太小或太大。
您可以在SSD上使用RAID-0。 无论使用哪种RAID，始终使用复制来保证数据安全。
启用有长队列的NCQ。 对于HDD，选择CFQ调度程序，对于SSD，选择noop。 不要减少 ‘readahead’ 设置。 对于HDD，启用写入缓存。
文件系统
Ext4是最可靠的选择。 设置挂载选项 noatime. XFS也是合适的，但它还没有经过ClickHouse的全面测试。 大多数其他文件系统也应该可以正常工作。 具有延迟分配的文件系统工作得更好。
Linux内核
不要使用过时的Linux内核。
网络
如果使用的是IPv6，请增加路由缓存的大小。 3.2之前的Linux内核在IPv6实现方面存在许多问题。
如果可能的话，至少使用10GB的网络。1GB也可以工作，但对于使用数十TB的数据修补副本或处理具有大量中间数据的分布式查询，情况会更糟。
虚拟机监视器(Hypervisor)配置
如果您使用的是OpenStack，请在nova.conf中设置
cpu_mode=host-passthrough
。
如果您使用的是libvirt，请在XML配置中设置
<cpu mode='host-passthrough'/>
。
这对于ClickHouse能够通过 cpuid 指令获取正确的信息非常重要。 否则，当在旧的CPU型号上运行虚拟机监视器时，可能会导致 Illegal instruction 崩溃。
Zookeeper
您可能已经将ZooKeeper用于其他目的。 如果它还没有超载，您可以使用相同的zookeeper。
最好使用新版本的Zookeeper – 3.4.9 或更高的版本. 稳定的Liunx发行版中的Zookeeper版本可能已过时。
你永远不要使用手动编写的脚本在不同的Zookeeper集群之间传输数据, 这可能会导致序列节点的数据不正确。出于相同的原因，永远不要使用 zkcopy 工具: https://github.com/ksprojects/zkcopy/issues/15
如果要将现有的ZooKeeper集群分为两个，正确的方法是增加其副本的数量，然后将其重新配置为两个独立的集群。
不要在ClickHouse所在的服务器上运行ZooKeeper。 因为ZooKeeper对延迟非常敏感，而ClickHouse可能会占用所有可用的系统资源。
默认设置下，ZooKeeper 就像是一个定时炸弹:
当使用默认配置时，ZooKeeper服务器不会从旧的快照和日志中删除文件（请参阅autopurge），这是操作员的责任。
必须拆除炸弹。
下面的ZooKeeper（3.5.1）配置在 Yandex.Metrica 的生产环境中使用截至2017年5月20日:
zoo.cfg:
# http://hadoop.apache.org/zookeeper/docs/current/zookeeperAdmin.html
# The number of milliseconds of each tick
tickTime=2000
# The number of ticks that the initial
# synchronization phase can take
initLimit=30000
# The number of ticks that can pass between
# sending a request and getting an acknowledgement
syncLimit=10
maxClientCnxns=2000
maxSessionTimeout=60000000
# the directory where the snapshot is stored.
dataDir=/opt/zookeeper/{{ '{{' }} cluster['name'] {{ '}}' }}/data
# Place the dataLogDir to a separate physical disc for better performance
dataLogDir=/opt/zookeeper/{{ '{{' }} cluster['name'] {{ '}}' }}/logs
autopurge.snapRetainCount=10
autopurge.purgeInterval=1
# To avoid seeks ZooKeeper allocates space in the transaction log file in
# blocks of preAllocSize kilobytes. The default block size is 64M. One reason
# for changing the size of the blocks is to reduce the block size if snapshots
# are taken more often. (Also, see snapCount).
preAllocSize=131072
# Clients can submit requests faster than ZooKeeper can process them,
# especially if there are a lot of clients. To prevent ZooKeeper from running
# out of memory due to queued requests, ZooKeeper will throttle clients so that
# there is no more than globalOutstandingLimit outstanding requests in the
# system. The default limit is 1,000.ZooKeeper logs transactions to a
# transaction log. After snapCount transactions are written to a log file a
# snapshot is started and a new transaction log file is started. The default
# snapCount is 10,000.
snapCount=3000000
# If this option is defined, requests will be will logged to a trace file named
# traceFile.year.month.day.
#traceFile=
# Leader accepts client connections. Default value is "yes". The leader machine
# coordinates updates. For higher update throughput at thes slight expense of
# read throughput the leader can be configured to not accept clients and focus
# on coordination.
leaderServes=yes
standaloneEnabled=false
dynamicConfigFile=