信创环境下部署 Apache Doris：国产 CPU 与操作系统适配核查、参数配置与迁移落地全流程

关注

原创最新推荐文章于 2026-11-12 22:45:00 发布 568 阅读 AI 写同款· GEO 优化 ›

政府科技管理者如何提升科技成果转化项目进场交易的备案效率？.docx 政府科技管理者如何提升科技成果转化项目进场交易的备案效率？立即下载

信创项目的数据库验收，看的通常不是跑分，而是四件事：安装包架构对不对、操作系统有没有适配证明、合规资质齐不齐、出事之后谁兜底。这四件事里任何一件没有着落，前面做的性能测试基本白做。

本文按这四个维度给出一条能照着走完的落地路径：部署前的环境信息采集命令、部署后的适配性核查清单、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