简介ClickHouse 21.8.14安装包专为华为鲲鹏920aarch64服务器与麒麟V10操作系统打造是国产化环境下部署高性能OLAP数据库的便捷方案。资源共20个文件约115.69MB主要包括安装/卸载Shell脚本、服务配置与users.xml等XML配置、clickhouse-server及clickhouse-client等核心可执行程序以及用于systemd托管的service文件能够直接在麒麟V10上完成从依赖检查、编译配置到服务启动的全过程。已有2139人学习使用适合希望在自主可控平台上快速搭建ClickHouse的运维工程师与大数据架构师。借助随包脚本无需自行解决交叉编译、库依赖与性能调优等难题即可获得适配鲲鹏920的稳定运行版本同时附带完整的配置示例和工具链便于后续管理表结构、导入数据、执行查询及日常监控。该安装包为国产化IT生态中构建大数据分析能力提供了可靠的落地支撑。 接到一个部署任务在一台鲲鹏920ARM架构服务器上安装ClickHouse操作系统是麒麟V10。刚开始我没当回事觉得ClickHouse嘛官网下载解压配置一下就能跑结果打开GitHub的release页面一看21.8.14这个版本压根找不到可用的aarch64安装包只有x86_64的tar.gz和rpm连ARM目录下的包都是给Ubuntu/Debian那种新系统准备的麒麟V10直接装很容易报glibc版本不够的错。也就是说21.8.14在鲲鹏麒麟这个组合上没有现成的完整安装包可以用唯一的路径就是源码编译。这篇东西是我折腾了一周的真实记录从为什么绕不开编译这条路到硬件怎么检查、依赖怎么装、cmake怎么升级、编译怎么等、部署怎么验证再到最后踩过的几个坑和产物的复用思路一次性讲清楚。给同样要在ARM国产操作系统环境里装ClickHouse的同学做个参考。1. 官方包用不了ARM麒麟环境下的三个现实问题1.1 官方release页面上就没有合适的ARM包先说最直接的问题ClickHouse官方发布页面上的安装包在21.8这个时期基本是围绕x86_64架构做的。tar.gz和rpm包标注的架构都是x86_64即使个别版本开始提供aarch64的rpm也是针对标准Linux发行版打出来的二进制对麒麟V10这种系统适配并不强。我翻了半天发现能在鲲鹏上直接用的官方包根本不完整有的版本只有server没有client有的版本对glibc版本要求很高装上去连clickhouse --version都跑不起来。这里有个很容易踩的误区不要看到“aarch64”就以为一定兼容。ARM服务器之间也有微架构差异更重要的是操作系统的运行时库版本。鲲鹏920是ARMv8指令集理论上市面上大部分aarch64包都能跑但前提是系统的glibc版本要满足二进制的要求而麒麟V10自带的库往往没那么新于是“能下载”和“能运行”是两码事。1.2 麒麟V10的系统底子决定了源码编译更靠谱麒麟V10不同SP版本底子不一样有的基于CentOS 7衍生的思路有的底子里有openEuler的基因系统自带的glibc、libstdc、openssl这些基础库版本差异很大。ClickHouse官方二进制通常是在较新的Ubuntu/Debian环境里构建的对glibc要求偏高放到老底子的麒麟上最常见的报错就是version GLIBC_2.27 not found之类的动态库版本找不到。源码编译的好处就在这里所有的依赖库都会在编译过程中按照当前系统的环境重新构建一遍最终生成的二进制跟当前操作系统的glibc、内核版本是对齐的运行阶段就不会再出现“库版本不够”这种尴尬问题。代价是编译时间长、过程繁琐但在一台不能随便换系统的国产化服务器上这是最稳妥、也是唯一能把版本精确锁定在21.8.14的办法。2. 编译前检查清单硬件底线、系统识别与依赖安装2.1 硬件底线内存、磁盘与CPU核心数ClickHouse的源码编译是个吃硬件的活官方文档里对构建宿主机的建议是很明确的。我这次因为前期对资源估计不足后面吃了不少苦头所以先把硬性指标列出来项目建议配置说明内存至少16GB推荐32GB链接阶段内存消耗极大8GB基本会OOM磁盘预留80GB以上源码submodulebuild目录膨胀很快CPU核数越多越好并行编译64核约2小时8核可能要6-8小时Swap建议额外加8GB防止链接阶段内存峰值导致进程被杀判断机器信息用三条命令lscpu看架构和核数free -g看内存df -h看磁盘挂载情况。特别注意看build目录准备放的那个分区够不够我就是没注意/opt分区只有40GB编译到一半磁盘满了白等了一下午。2.2 系统识别与依赖清单先确认系统版本和架构uname -m cat /etc/kylin-release执行结果应该是aarch64加一个V10的版本号。这一步很重要因为麒麟V10不同版本能用的yum源、自带的GCC版本都不一样后面的安装策略要跟着调整。接下来装依赖。ClickHouse构建过程中需要git、cmake、ninja、python3、gcc等另外一些库会用到系统头文件。麒麟V10上我习惯用yum装基础部分yum install -y git gcc gcc-c make cmake ninja-build python3 yum install -y openssl-devel readline-devel zlib-devel libtool如果你是在内网离线环境记得提前准备好对应的rpm包或者内网yum源。网络热词里很多人在问麒麟V10怎么搭yum源这里提醒一句别只想着用系统ISO做本地源优先找一台同版本、同架构的机器做内网仓库省心很多。3. 源码准备版本锁定、submodule与cmake升级3.1 克隆源码时最容易被忽略的--recursive参数ClickHouse不是单仓库它把zstd、lz4、curl、rocksdb按需启用等一大批第三方库用git submodule的方式管理。如果克隆的时候不带--recursive参数源码目录里会留下一堆空的子模块目录等cmake阶段才发现缺库再回去翻就非常痛苦。我这次用的是官方推荐的方式git clone --recursive https://github.com/ClickHouse/ClickHouse.git cd ClickHouse git checkout v21.8.14.5-lts git submodule update --init --recursivegit checkout后面那个v21.8.14.5-lts是21.8系列一个具体的LTS tag对应发布页面上21.8.14.5-lts这个版本。拉下来的源码加上submodule差不多好几个GB内网环境如果网速一般这个阶段要有心理准备最好在夜里挂着让它慢慢拉。注意如果clone时没加--recursive后面单独跑git submodule update --init --recursive也能补齐但某些submodule可能因为网络原因拉取中断这时不要反复重试整个命令删除对应的失败子目录再单独更新该子模块效率高很多。3.2 升级cmake绕开系统旧版本麒麟V10自带的cmake版本通常比较旧我在这台机器上查到的是3.10.x而ClickHouse 21.8构建要求cmake 3.18以上。系统源里的cmake不够新解决办法是直接编译安装一个新版cmakewget https://cmake.org/files/v3.21/cmake-3.21.4.tar.gz tar zxf cmake-3.21.4.tar.gz cd cmake-3.21.4 ./bootstrap --prefix/usr/local make -j$(nproc) make install装完之后确认版本/usr/local/bin/cmake --version which cmake如果which cmake指向的还是旧版本可以调整PATH环境变量或者直接把新版cmake软链到/usr/local/bin下。这个步骤不做的话后面cmake配置阶段会直接报版本不满足的错误属于必踩的坑。3.3 GCC和Clang的关系ClickHouse其实自带编译器构建流程很多人第一次编译ClickHouse会疑惑不是说必须用Clang吗我系统里没装Clang怎么办实际上ClickHouse的构建机制比较特殊它会先在contrib目录下用系统GCC构建一个内置的Clang然后用这个Clang去编译ClickHouse主代码。这么设计是为了保证编译器版本完全可控避免外部环境差异影响构建结果。但这意味着系统GCC也不能太老建议GCC 9以上。麒麟V10自带的GCC版本可能偏低可以用scl工具集或者安装高版本的devtoolset来解决。如果configure阶段报GCC版本不支持基本就是这个原因。4. 编译执行参数选择、进度跟踪与OOM应对4.1 构建目录与cmake配置参数在源码根目录下创建独立的构建目录这样源码目录和编译产物分开后续清理重来都方便mkdir build cd build cmake -DCMAKE_BUILD_TYPERelease -DENABLE_TESTSOFF -DENABLE_EXAMPLESOFF ..三个参数的意思分别是使用Release优化模式不构建单元测试不构建示例程序。测试和示例代码量很大禁用掉能省不少编译时间而且部署环境里根本用不到。关于-DUSE_EMBEDDED_COMPILER这个参数默认是ON也就是启用内置的LLVM编译器执行JIT优化在ARM架构下实测是可以正常编译的不需要刻意关闭。如果你在configure阶段遇到LLVM相关的编译错误可以考虑加-DUSE_EMBEDDED_COMPILEROFF关掉再试但那个场景下ClickHouse的某些查询优化能力会受影响我建议不到最后一步别走这个开关。4.2 执行ninja构建与进度判断configure阶段通过之后开始正式构建ninja clickhouse只指定clickhouse这个target就够了ClickHouse的单二进制会一次性生成server和client没必要把所有的工具都编译出来。ninja比make好在并行度处理得更聪明默认会按CPU核数并行编译。构建进度方面ninja会打印百分比但这个过程不是匀速的有些阶段编译单个文件就要好几分钟百分比长时间不动是正常的。别一看卡住了就慌用top观察一下CPU占用如果多个核心还在满负荷跑说明编译器在工作耐心等就行。4.3 链接阶段的内存压力与Swap应对整个编译过程中最凶险的是最后链接clickhouse这个大二进制的时候链接器要把所有的目标文件合并起来内存占用会暴涨。我这次在32GB内存的机器上做链接free看到的内存峰值接近28GB如果机器内存不足进程会被系统直接杀掉。应对办法是提前准备swap。在root权限下快速加一个8GB的swap文件dd if/dev/zero of/swapfile bs1G count8 chmod 600 /swapfile mkswap /swapfile swapon /swapfile加好swap后重新跑ninja clickhouse因为前面大部分目标文件已经编译完成链接阶段重跑不会太久。这个方法不能完全替代物理内存但能有效防止OOM。如果你机器内存只有8G建议先把并行度降下来ninja -j2 clickhouse编译时间会拉长至少不会半路死掉。经验值我在鲲鹏92064核 32GB内存的机器上全量编译耗时约2小时40分钟如果用8核虚拟机没有一晚上跑不完。预算好时间别指望临时抱佛脚。5. 安装部署从编译产物到可查询的ClickHouse实例5.1 安装命令与产物定位编译成功后最简单的安装方式sudo ninja install这个命令会把clickhouse二进制装到/usr/bin配置文件模板放到/etc/clickhouse-server还会创建默认的数据目录和日志目录。如果你不想污染系统、或者想保留一个“绿色版”方便拷贝到其他机器也可以直接用build目录里编译好的产物build/programs/clickhouse这个单二进制包含了server和client的全部功能通过子命令区分。我实际更推荐先ninja install装一遍让系统把用户、目录、日志轮转脚本都配好这样后面用systemd管理省事很多。5.2 配置文件与启动安装完成后确认数据目录权限sudo useradd --system clickhouse 2/dev/null || true sudo mkdir -p /var/lib/clickhouse /var/log/clickhouse-server sudo chown -R clickhouse:clickhouse /var/lib/clickhouse /var/log/clickhouse-server然后启动服务sudo systemctl start clickhouse-server sudo systemctl status clickhouse-server如果一切正常状态会显示active。配置文件主要在/etc/clickhouse-server/config.xml默认监听127.0.0.1的9000端口原生协议和8123端口HTTP协议。如果镜像需要对外提供服务记得修改listen_host字段否则外部机器连不上。5.3 功能验证从客户端到HTTP接口服务起来后先用客户端做基本验证clickhouse-client --query SELECT version()能看到输出21.8.14.5说明编译产物运行正常。继续做一个完整的建表插入查询动作CREATE TABLE test.events ( event_date Date, event_type String, value UInt64 ) ENGINE MergeTree PARTITION BY toYYYYMM(event_date) ORDER BY (event_date, event_type); INSERT INTO test.events VALUES (2024-01-15, click, 100), (2024-01-16, view, 200); SELECT event_type, sum(value) FROM test.events GROUP BY event_type;HTTP接口也要顺手验证一下很多周边系统走的是这个协议curl http://127.0.0.1:8123/?querySELECT%201返回1就说明HTTP服务正常。Java项目里如果用JDBC连接连接串类似jdbc:clickhouse://服务器IP:8123/default驱动用官方clickhouse-jdbc即可这个在上层应用联调时很常用。6. 踩坑复盘与多机分发经验6.1 这次编译踩过的几个值得记录的坑第一个坑是submodule拉取中断。第一次clone时网络抖动某个子模块目录残留了半截文件后面git submodule update反复报错。最后手动删掉那个子模块目录再单独update才恢复。教训是中途失败不要反复整体重试锁定失败模块单独处理。第二个坑是磁盘分区不够。我把build目录建在了根目录/下结果根分区只有40GB可用编译到6成多的时候直接把分区塞满ninja报错。后来清掉build把目录挪到数据盘才顺利跑完。提前用df -h看空间是省时间的最大保障。第三个坑是链接阶段OOM。第一次在16GB内存的机器上编译链接时进程被killed日志末尾没有明确报错只看到“Killed”。加了swap后重跑就通过了。如果碰到编译进程莫名消失第一时间查dmesg里有没有OOM记录。6.2 编译产物的跨机器复用编译一次折腾这么久如果集群里有多台同样配置的机器完全没必要每台都编译一遍。我实际用的做法是把编译好的build/programs/clickhouse复制出来连同/etc/clickhouse-server和/etc/clickhouse-client两个目录一起打包拷贝到其他同为鲲鹏麒麟V10的机器上解压后创建clickhouse用户、初始化目录、导入systemd服务文件就能直接运行。前提是目标机器的glibc版本和编译机一致这个在我的场景里天然满足因为都是同一个版本镜像批量交付的机器。如果机器基础系统版本差异很大别硬拷老老实实重新编译不然运行期出现诡异崩溃会非常被动。最后再分享一个我后来养成的习惯编译这类“一个人扛全家”的大组件之前先把方案评审文档写明白尤其是版本号、依赖清单、资源预估这三项。看似多花了半小时实际上能避免后面好几天的返工。ClickHouse在ARM国产系统上的生态还在完善自己编译虽然麻烦但跑起来之后稳定性反而比到处找适配包要可靠。本文还有配套的精品资源点击获取