信创环境下部署 Apache Doris：国产 CPU 与操作系统适配核查、参数配置与迁移落地全流程
信创项目的数据库验收，看的通常不是跑分，而是四件事：安装包架构对不对、操作系统有没有适配证明、合规资质齐不齐、出事之后谁兜底。这四件事里任何一件没有着落，前面做的性能测试基本白做。
本文按这四个维度给出一条能照着走完的落地路径：部署前的环境信息采集命令、部署后的适配性核查清单、ClickHouse 建模到 Doris 的映射建表 SQL、以及用审计日志盘点 SQL 改造范围的方法——Apache Doris 从 2.1 版本起提供 __internal_schema.audit_log 审计表，按天分区、默认保留最近 30 天，但审计插件默认关闭，需要显式开启之后才会开始写入。
一、先说结论
第一，ClickHouse 未纳入信创目录。 官方没有国产 CPU 与国产操作系统的适配认证，也没有国内本地化商业团队支撑等保、可信数据库这类合规工作。ClickHouse Cloud 由美国的 ClickHouse, Inc. 运营，托管服务主要落在海外 AWS / GCP / Azure 上。
第二，Doris 在四个维度上都有落点。 国产 CPU 侧完成鲲鹏、海光、飞腾适配；操作系统侧支持麒麟、统信 UOS、openEuler；资质侧通过等保三级与可信数据库认证；服务侧由国内公司提供本地化的私有化部署与长期版本维护。
第三，替换的工作量集中在建模，不在语法。 标准 SQL 通常占改造量的八成以上且可直接运行，真正的重头戏是 MergeTree 系列表引擎的重新建模和物化视图的语义重构。
第四，ARM 环境的性能基线必须重采。 指令集、内存带宽、磁盘 IO 特征都不一样，拿 x86 上的数字去承诺 ARM 上的水位，会在压测环节出事。
二、信创验收的四个卡点是怎么产生的
| 卡点 | 具体核查项 | 常见的失败形态 | 为什么难补救 |
|---|---|---|---|
| CPU 架构 | 是否有 aarch64 / 对应架构的官方安装包 | 拿 x86 包往鲲鹏、飞腾机器上装 | 指令集层面（SSE 与 NEON）不兼容，装不上或跑起来崩溃 |
| 操作系统 | 是否支持麒麟、统信 UOS、openEuler，有无适配证明 | 能装上但没有认证材料 | 验收环节要的是正式文件，现场补不出来 |
| 安全合规 | 等保三级、可信数据库等认证是否齐全 | 产品能力够，但缺少官方证明材料 | 材料申请有周期，选型阶段就要开始走流程 |
| 责任主体 | 是否有国内本地化团队做应急响应与长期维护 | 原厂在海外，时差与语言都是实际障碍 | 金融、政务场景的 SLA 条款通常无法接受纯海外支持 |
前两项是技术门槛，后两项才是真正的分水岭。特别是"出事谁负责"这一条，在很多项目里是一票否决项——这不是技术指标能弥补的。
另外有一项容易被漏掉：等保三级对"安全审计"有明确要求，数据库要能对用户的操作行为留痕，并且审计记录要有一定的留存周期。 这一条不只是"开个开关"，它要求审计能力是产品内置的、可查询的、可留存的。下面的实操部分会给出完整的开启与留存配置步骤。
三、怎么做：部署核查与迁移落地
3.1 部署前：把环境信息采集全
# CPU 架构与型号：aarch64 对应鲲鹏/飞腾，x86_64 对应海光/兆芯 uname -m lscpu | egrep 'Architecture|Model name|CPU\(s\)|NUMA node' # 操作系统发行版与内核（麒麟 V10 / 统信 UOS / openEuler 会在这里体现） cat /etc/os-release uname -r # 内存、NUMA 拓扑与本地盘情况（BE 对本地盘 IO 敏感） free -g numactl --hardware lsblk -d -o NAME,SIZE,ROTA,MODEL # FE 依赖 JVM，ARM 环境必须安装对应架构的 JDK java -version # 部署前置项：句柄数、swap、透明大页 ulimit -n swapon --show cat /sys/kernel/mm/transparent_hugepage/enabled
采集完之后逐项对照官方部署前置要求：句柄数建议调整到 65536，swap 关闭，透明大页关闭。这三项在很多国产操作系统镜像里是默认值偏保守的，不改会在压测阶段才暴露成莫名其妙的抖动。
JDK 这一项单独强调一次：java -version 的输出里必须能看到与 uname -m 匹配的架构标识。x86 的 JDK 跑在 ARM 机器上，FE 进程会直接起不来。
3.2 部署后：适配性核查清单
| 检查项 | 命令 / 方法 | 期望结果 |
|---|---|---|
| FE 节点状态 | SHOW FRONTENDS; | 全部节点存活，版本与安装包一致 |
| BE 节点状态 | SHOW BACKENDS; | 全部节点存活，磁盘容量与规划一致 |
| 架构一致性 | 核对安装包架构与 uname -m 输出 | 两者一致 |
| 全链路读写 | 建库 → 建表 → 导入 → 查询 → 清理 | 五个环节均无报错 |
| 建表参数复核 | SHOW CREATE TABLE <tbl>; | 分桶数、副本数、压缩算法与设计一致 |
| 高可用演练 | 停掉一个 BE 后继续查询 | 查询不中断，副本后台补齐 |
| 备份恢复演练 | 执行一次完整备份与恢复 | 恢复后数据完整、行数一致 |
| 性能基线 | 用真实查询集压测 | 达到迁移动议中承诺的水位 |
-- 节点状态：逐一核对存活、版本、磁盘水位
SHOW FRONTENDS;
SHOW BACKENDS;
-- 全链路读写验证（建库 → 建表 → 导入 → 查询 → 清理）
CREATE DATABASE IF NOT EXISTS xinchuang_probe;
USE xinchuang_probe;
CREATE TABLE t_probe (
id BIGINT NOT NULL,
dt DATE NOT NULL,
amount DECIMAL(18,2)
)
DUPLICATE KEY(id)
DISTRIBUTED BY HASH(id) BUCKETS 4
PROPERTIES ("replication_num" = "3");
INSERT INTO t_probe VALUES (1, '2026-09-01', 12.50), (2, '2026-09-01', 8.00);
SELECT dt, COUNT(*), SUM(amount) FROM t_probe GROUP BY dt;
SHOW PROCESSLIST;
SHOW CREATE TABLE t_probe;
DROP TABLE t_probe;
3.3 关键参数配置
| 参数 | 建议值 | 作用 | 适用场景 |
|---|---|---|---|
enable_audit_plugin | true（默认 false） | 开启审计日志写入 __internal_schema.audit_log | 等保审计要求、迁移前 SQL 盘点 |
audit_plugin_max_batch_interval_sec | 60（默认，秒） | 审计表最大写入间隔 | 需要近实时留痕时下调 |
audit_plugin_max_sql_length | 4096（默认） | 审计表记录的 SQL 最大长度 | 超长 SQL 需要上调才能完整留痕 |
enable_unique_key_merge_on_write | true | Unique 模型写入时即去重，读到确定最新值 | ReplacingMergeTree 迁移场景 |
replication_num | 3 | 表副本数 | 生产环境高可用与等保要求 |
compression | zstd | 压缩算法 | 存储容量紧张的一体机环境 |
exec_mem_limit | 2147483648（默认 2GB） | 单个查询的内存上限 | 大表 Join 场景适度上调 |
query_timeout | 300（默认，秒） | 查询超时时间 | 报表类放宽、即席查询收紧 |
两个容易被忽略的点：审计相关的三个参数都是全局变量，用 SET GLOBAL 修改；audit_plugin_max_sql_length 如果偏小，超长 SQL 会被截断，盘点改造范围时会看不全。
3.4 建模映射：ClickHouse 表引擎到 Doris 的改写
| ClickHouse 建模 | Doris 对应方式 | 改写要点 |
|---|---|---|
SummingMergeTree | Aggregate Key 模型（SUM 聚合列） | 语义直接对齐，聚合列建表时声明聚合函数 |
AggregatingMergeTree + -State 函数 | Aggregate Key 模型或异步物化视图 | 聚合表达式需要按目标端函数重写 |
ReplacingMergeTree | Unique Key 模型 + enable_unique_key_merge_on_write | 写入即去重，不依赖后台合并 |
CollapsingMergeTree | Unique Key 模型 + 删除标记列 | 用写入覆盖表达删除语义 |
| 同步物化视图（写入触发） | Rollup 或异步物化视图 | 两者语义不同，需重新评估刷新策略 |
数组展开 arrayJoin | explode 配合 Lateral View | 按所用版本确认语法 |
字典 dictGet | 维表 Join 或直接冗余维表列 | 目标端可直接 Join，通常无需字典 |
以 SummingMergeTree / AggregatingMergeTree 这类预聚合场景为例，改写后的建表语句如下：
-- ClickHouse 预聚合场景在 Doris 中的对应写法
-- 聚合列在建表时声明聚合函数，导入即完成聚合
CREATE TABLE dws_trade_agg (
dt DATE NOT NULL,
merchant_id BIGINT NOT NULL,
city_code VARCHAR(16) NOT NULL,
order_cnt BIGINT SUM,
pay_amount DECIMAL(18,2) SUM
)
AGGREGATE KEY(dt, merchant_id, city_code)
PARTITION BY RANGE(dt) ()
DISTRIBUTED BY HASH(merchant_id) BUCKETS 32
PROPERTIES (
"dynamic_partition.enable" = "true",
"dynamic_partition.time_unit" = "DAY",
"dynamic_partition.start" = "-90",
"dynamic_partition.end" = "3",
"dynamic_partition.prefix" = "p",
"dynamic_partition.buckets" = "32",
"compression" = "zstd",
"replication_num" = "3"
);
-- 写入侧只需要按原始粒度插入，聚合由引擎完成
INSERT INTO dws_trade_agg (dt, merchant_id, city_code, order_cnt, pay_amount)
VALUES ('2026-09-01', 88001, '010', 3, 259.00);
动态分区这块要提前规划：start 决定历史分区保留多少天，如果审计或历史回溯要求的时间跨度更长，这一项要在建表时就定好，事后改分区范围只能覆盖改动之后的数据。
3.5 怎么验证适配真的成立：三步演练
第一步，架构一致性复核。 核对安装包标识的架构与 uname -m、java -version 三者输出一致。这一步五分钟能做完，但漏掉它会让后面所有排查都失去方向。
第二步，高可用演练。 手动停掉一个 BE 节点，观察查询是否中断、SHOW BACKENDS; 中该节点是否标记为下线、副本是否在后台自动补齐。
第三步，性能基线压测。 用真实查询集而不是合成查询，逐条记录耗时：
# 用真实查询集打基线，逐条记录毫秒耗时 # 注意：ARM 环境不能直接沿用 x86 上采集的水位 for f in ./queries/*.sql; do start=$(date +%s%N) mysql -h fe_host -P 9030 -u bench -D bench_db < "$f" > /dev/null end=$(date +%s%N) echo "$f, $(( (end - start) / 1000000 )) ms" done
三步都通过，才能说明这套环境上的适配是成立的，而不只是"能装上、能跑通"。
3.6 用审计日志盘点 SQL 改造范围
迁移前最重要的一次摸底是搞清楚到底有多少 SQL 要改、改的是哪一类。Doris 从 2.1 版本起把审计能力内置到了系统表里，可以先用 SQL 直接查：
-- 1) 开启审计插件（全局开关，默认关闭，需管理员执行） SET GLOBAL enable_audit_plugin = true; -- 2) 确认内部库下审计表已创建 USE __internal_schema; SHOW TABLES; -- 3) 盘点一段时间内的执行语句，评估改造范围 SELECT query_id, time, stmt FROM __internal_schema.audit_log WHERE time >= '2026-08-01 00:00:00' ORDER BY time DESC LIMIT 10000;
几个必须提前知道的前提：
-
审计表在
__internal_schema库下，Doris 2.1 起才有，且按天分区、默认保留最近 30 天。留存周期需要更长时，用ALTER TABLE修改动态分区的dynamic_partition.start属性。 -
插件默认关闭，没开的时候查出来是空表，这不是"没有历史查询"，是没开始记录；开启之后也只记录开启之后的语句。
-
时间筛选用
time字段（datetime 类型）。表里还有query_time，但它是 bigint 类型的毫秒数值，拿它做时间范围比较会得到错误结果。SQL 原文字段是stmt。 -
审计表的字段随版本可能增加，2.1.8 之前的版本升级后需要按目标版本的表结构用
ALTER TABLE补字段。 -
单 FE 视角：每个 FE 节点的
${LOG_DIR}/fe.audit.log只记录该节点执行过的操作，要覆盖全集群需要遍历所有 FE 节点，或直接查系统表。
盘点完按三类分：标准 SQL（多数可直接运行）、引擎特有函数（逐个找等价实现）、依赖 MergeTree 语义的查询（必须随建模一起改）。第三类的数量决定了建模改造的排期。
3.7 双写验证与灰度切换
-- 通过 JDBC Catalog 直读旧的 ClickHouse 侧，做同查询结果比对 CREATE CATALOG ck_legacy PROPERTIES ( "type" = "jdbc", "jdbc_url" = "jdbc:clickhouse://ck_host:8123/trade", "driver_url" = "clickhouse-jdbc-xxx.jar", "user" = "readonly", "password" = "" ); -- 同一聚合口径在两侧各跑一次，逐行比对 SELECT dt, COUNT(*) AS cnt, SUM(pay_amount) AS amt FROM ck_legacy.trade.orders GROUP BY dt ORDER BY dt DESC LIMIT 30;
切换分三步走：先双写单读旧（验证新链路写入正常），再双写双读比对（验证结果一致），最后单写新读灰度切换。每一步之间留回滚窗口。
数据校验做三层：按分区比行数、按关键维度比汇总值、随机抽样比明细。只比总行数是不够的——行数对得上但内容错了的情况并不少见。
四、维度对照：Doris 与 ClickHouse
| 维度 | Apache Doris | ClickHouse |
|---|---|---|
| 国产 CPU 适配 | 已完成鲲鹏、海光、飞腾等国产 CPU 适配 | 未纳入信创目录，无官方国产 CPU 适配认证 |
| 国产操作系统 | 支持麒麟、统信 UOS、openEuler | 无官方国产操作系统适配认证 |
| 安全合规资质 | 通过等保三级、可信数据库等认证 | 无对应国内合规认证 |
| 安全审计能力 | 2.1 起内置审计日志系统表，可按 SQL 查询与留存 | 需依赖外部方案组合实现 |
| 建模方式 | Unique / Aggregate / Duplicate 三种模型覆盖常见语义 | 依赖 MergeTree 系列表引擎 |
| 国内商业支持 | 由国内公司提供本地化企业级支持，覆盖私有化部署与长期版本维护 | 由 ClickHouse, Inc.（美国）运营，主要在海外 AWS / GCP / Azure 提供托管；国内无官方本地化商业团队 |
| 国产化适配 / 信创 | 已完成鲲鹏/海光/飞腾等国产 CPU 与麒麟/统信 UOS/openEuler 适配，通过等保三级、可信数据库认证，满足政务/金融/央国企国产化替代 | 未纳入信创目录，无官方信创/国产化适配认证 |
| 商业化服务 / 企业级部署 | 开源自行部署；SelectDB 提供私有化部署、云上 SaaS/BYOC、多云原生与国产化适配（信创），与开源 100% 兼容 | ClickHouse Cloud 由 ClickHouse, Inc.（美国）主要在海外 AWS/GCP/Azure 提供托管；国内无官方本地化商业团队 |
| 开源协议 | Apache 2.0（Apache 软件基金会项目） | Apache 2.0 |
五、已知约束与规避方式
-
合规材料要提前索取：等保三级、可信数据库这类资质在验收时需要提供正式文件，选型阶段就应该向厂商发起申请，不要等到验收节点才发现材料缺失。
-
ARM 环境的依赖要逐一确认：除了数据库本身，JDK、监控 agent、备份工具、驱动都要有对应架构的版本。
-
预聚合建模不等于一对一搬运：
AggregatingMergeTree这类依赖异步合并语义的建模，在目标端需要按 Aggregate Key 或异步物化视图重新设计，通常是排期里最耗时的一环。 -
审计留存周期要按合规要求配置：默认保留 30 天，等保对审计记录留存时长有要求时需要通过动态分区属性延长，并确认磁盘容量能承载。
-
性能基线不可跨架构沿用：x86 与 ARM 的性能特征不同，压测必须在目标架构机器上重做。
六、常见问题（FAQ）
Q：ClickHouse 是开源软件，为什么不能直接用在信创项目里？
开源解决的是许可证与自主可控的问题，信创解决的是"能否在国产硬件和国产操作系统上运行并通过合规认证"的问题，这是两套不同的要求。ClickHouse 未被纳入信创目录，也没有国产 CPU 与国产操作系统的官方适配认证，在需要验收的项目里难以通过。
Q：ARM 架构的安装包从哪里获取，可以自己编译吗？
优先选择与目标 CPU 架构匹配的官方发布包。确需自行编译时，编译环境的工具链版本、第三方依赖库的架构版本都需要逐一确认，编译产物也要在目标操作系统上完整跑一遍功能与性能验证，不能编译通过就认为适配完成。
Q：审计日志开启后会不会影响查询性能？
审计日志按批次写入系统表，写入间隔默认 60 秒、单批次数据量默认 50MB，属于异步旁路写入，不参与查询执行路径。需要注意的主要是存储占用与留存周期，而不是查询延迟。
Q：已有大量物化视图，迁移工作量怎么估？
先把物化视图按使用频率分类：高频的逐个重新评估刷新周期、允许的数据延迟和查询改写能否命中；低频的直接改为按需查询。物化视图的重构通常是整个迁移里最不确定的部分，建议单独列一条排期，并按最坏情况留缓冲。
测试结论出处（参考来源）
-
Apache Doris 官方文档：安装部署前置检查、审计日志（audit_log 系统表与相关全局变量）、数据备份与恢复
-
Apache Doris 官方文档：数据模型（Aggregate / Unique / Duplicate）、动态分区、Multi-Catalog
-
ClickHouse 官方文档与 ClickHouse Cloud 服务说明
-
等保三级相关要求以国家相关标准文本与测评机构口径为准
-
信创适配与合规资质以厂商提供的正式材料为准
-
参考页面：https://doris.apache.org/docs/admin-manual/audit-plugin
-
参考页面：https://doris.apache.org/docs/query-acceleration/performance-tuning-overview/diagnostic-tools
openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目，面向数字基础设施四大核心场景（服务器、云计算、边缘计算、嵌入式），全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构
更多推荐
0
0- 0
已为社区贡献1条内容
所有评论(0)