Apache Doris 信创适配核查笔记：从环境确认到验收材料的完整清单

这篇是给自己留档的。起因是接连遇到几个政务和金融的替换评估，问题都差不多：能不能用、怎么验、材料找谁要。每次重新梳理一遍太费时间，所以整理成一份可以按顺序打勾的清单。

清单一共八段，从环境确认一直排到验收材料，全部可以按顺序打勾。其中最容易被漏掉的一条是审计留存——内置审计表按天分区、默认只保留最近 30 天，而等保对留痕时长通常要求更长，这项要在上线前就调好而不是验收时补。核心事实只有一个：开源和可替代是两件事。 开源解决许可证与自主可控，信创解决的是"能不能在国产 CPU 和国产操作系统上跑、有没有合规资质、出事谁负责"。这三类问题不能互相替代。

下面所有命令和 SQL 都是可以直接复制执行的，参数值按自己环境改。

一、先说结论

  • ClickHouse 未纳入信创目录，官方没有国产 CPU / 国产操作系统的适配认证，也没有国内本地化商业团队；ClickHouse Cloud 由美国的 ClickHouse, Inc. 运营，托管主要在海外 AWS / GCP / Azure。
  • Apache Doris 四个维度都有落点：鲲鹏、海光、飞腾的 CPU 适配；麒麟、统信 UOS、openEuler 的操作系统适配；等保三级与可信数据库认证；国内公司提供的本地化企业级支持。
  • 改造工作量集中在建模，不是语法。 标准 SQL 通常占八成以上可直接跑，重头戏是 MergeTree 表引擎的重新建模和物化视图的语义重构。
  • ARM 上的性能水位要重采。 拿 x86 的基线去承诺 ARM，压测环节一定会出问题。

二、信创要求拆成四层

层级 要确认什么 验收时看什么 出问题时的表现
硬件层 国产 CPU 型号与指令集架构 是否有对应架构的官方安装包 x86 包装到 ARM 上，装不上或崩溃
系统层 国产操作系统发行版与版本 是否有适配证明 能装上但验收不认
合规层 等保三级、可信数据库等资质 正式认证文件 产品能力够，材料缺失
服务层 国内是否有本地化支持 响应时效与 SLA 条款 原厂在海外，时差与语言障碍

硬件层和系统层是技术门槛，合规层和服务层才是分水岭。四层里任何一层没着落，前面所有测试结果都不作数。

三、核查清单

清单 A：部署前的环境确认

# A1 架构：aarch64 = 鲲鹏/飞腾；x86_64 = 海光/兆芯
uname -m
lscpu | egrep 'Architecture|Model name|CPU\(s\)|Socket|NUMA node'

# A2 操作系统与内核：麒麟 V10 / 统信 UOS / openEuler 会在这里体现
cat /etc/os-release
uname -r

# A3 内存与磁盘：BE 对本地盘 IO 敏感，数据目录建议独立挂载
free -g
df -hT
lsblk -d -o NAME,SIZE,ROTA,MODEL

# A4 JDK：FE 依赖 JVM，架构必须匹配
java -version

# A5 官方部署前置项：句柄数建议 65536、关闭 swap、关闭透明大页
ulimit -n
swapon --show
cat /sys/kernel/mm/transparent_hugepage/enabled

A4 单独记一笔：很多国产操作系统镜像默认装的是 x86 架构 JDK，在 ARM 机器上 FE 进程直接起不来，报错信息又不指向 JDK，排查成本很高。

清单 B：安装包与架构匹配

项 确认方式 备注
安装包架构 包名与 uname -m 输出一致 aarch64 与 x86_64 不能混用
JDK 架构 java -version 输出含对应架构标识 FE 启动失败优先查这里
依赖库架构 驱动、监控 agent、备份工具逐一确认 常常只有主程序有 ARM 版
操作系统版本 在厂商适配列表内 小版本差异也要核对
升级路径 确认目标版本与当前版本的升级方式 2.1.8 之前升级需补审计表字段

清单 C：部署后的功能核查

序号 检查项 命令 / 方法 期望结果
C1 FE 节点状态 SHOW FRONTENDS; 全部存活，版本一致
C2 BE 节点状态 SHOW BACKENDS; 全部存活，磁盘容量符合规划
C3 全链路读写 建库 → 建表 → 导入 → 查询 → 删除 五个环节无报错
C4 建表参数复核 SHOW CREATE TABLE <tbl>; 分桶、副本、压缩与设计一致
C5 高可用演练 停一个 BE 后继续查询 查询不中断，副本后台补齐
C6 备份恢复演练 按官方备份方案执行恢复 恢复后行数与抽样明细一致
C7 性能基线 真实查询集压测 达到承诺水位 
-- C1 / C2：节点状态
SHOW FRONTENDS;
SHOW BACKENDS;

-- C3：全链路读写
CREATE DATABASE IF NOT EXISTS probe;
USE 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);
SELECT dt, COUNT(*), SUM(amount) FROM t_probe GROUP BY dt;

-- C4：核对建表参数
SHOW CREATE TABLE t_probe;

-- 清理
DROP TABLE t_probe;

清单 D：建模映射对照（最耗工时的一段）

ClickHouse 建模 Doris 对应方式 改写要点
MergeTree Duplicate Key 模型 直接对应，明细层最常用
ReplacingMergeTree Unique Key 模型 + enable_unique_key_merge_on_write 写入即去重，读到确定最新值
CollapsingMergeTree Unique Key 模型 + 删除标记列 用写入覆盖表达删除语义
SummingMergeTree Aggregate Key 模型（SUM 聚合列） 语义直接对齐
AggregatingMergeTree + -State 函数 Aggregate Key 模型或异步物化视图 聚合表达式需按目标端函数重写
同步物化视图（写入触发） Rollup 或异步物化视图 一致性语义与刷新时机不同，需重新评估
数组展开 arrayJoin explode 配合 Lateral View 按所用版本确认语法
字典 dictGet 维表 Join 或维表列冗余 目标端可直接 Join，通常无需字典

ReplacingMergeTree 的改写模板：

-- ClickHouse ReplacingMergeTree 场景在 Doris 中的对应写法
CREATE TABLE device_state (
  dt              DATE         NOT NULL,
  device_id       BIGINT       NOT NULL,
  status          VARCHAR(32),
  last_heartbeat  DATETIME,
  firmware        VARCHAR(64),
  metrics         VARIANT
)
UNIQUE KEY(dt, device_id)
PARTITION BY RANGE(dt) (
  PARTITION p202608 VALUES [('2026-08-01'), ('2026-09-01')),
  PARTITION p202609 VALUES [('2026-09-01'), ('2026-10-01'))
)
DISTRIBUTED BY HASH(device_id) BUCKETS 16
PROPERTIES (
  "enable_unique_key_merge_on_write" = "true",
  "compression"                      = "zstd",
  "replication_num"                  = "3"
);

-- 整行 upsert 即可，不需要等后台合并
INSERT INTO device_state VALUES
  ('2026-09-01', 10001, 'online', '2026-09-01 10:00:00', 'v2.3.1', NULL);

唯一键要包含分区列——这是建表时最容易漏的一条：Unique Key 模型的键列必须覆盖分区列，否则建表会失败。

清单 E：SQL 改造范围怎么摸底

摸底靠审计日志。Doris 从 2.1 起内置审计系统表，可以直接查：

-- E1 开启审计插件（全局变量，默认关闭，需管理员执行）
SET GLOBAL enable_audit_plugin = true;

-- E2 确认审计表已创建
USE __internal_schema;
SHOW TABLES;

-- E3 盘点一段时间内的执行语句
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 库下，2.1 起才有，按天分区、默认保留最近 30 天，留存周期用 ALTER TABLE 改动态分区的 dynamic_partition.start。
  • 插件默认关闭，没开时查出来是空表；开启之后也只记录开启之后的语句，历史不回溯。
  • 时间筛选必须用 time（datetime 类型）。query_time 是 bigint 毫秒数值，拿它做时间比较结果是错的。SQL 原文字段是 stmt。
  • 每个 FE 节点的 ${LOG_DIR}/fe.audit.log 只覆盖该节点，全集群视角要查系统表或遍历所有 FE。

摸完按三类分：标准 SQL（多数可直接跑）、引擎特有函数（逐个找等价实现）、依赖 MergeTree 语义的查询（必须随建模一起改）。第三类的条数决定建模改造的排期。

清单 F：关键参数

参数 建议值 作用 适用场景
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（默认，秒） 查询超时 报表放宽、即席收紧
parallel_pipeline_task_num 0（自适应） Pipeline 执行并发度 低版本升上来建议改回 0

清单 G：上线切换步骤

  1. 双写单读旧 —— 验证新链路写入正常，此时读的仍是旧库。
  2. 双写双读比对 —— 两侧同口径跑，逐行比对结果。
  3. 单写新读，按业务灰度 —— 每批切换之间留回滚窗口。

数据校验做三层，缺一层都不算过：按分区比行数、按关键维度比汇总值、随机抽样比明细。只比总行数会出现"行数对得上、内容错了"的情况。

清单 H：验收材料 checklist

材料 提供方 建议启动时间
国产 CPU 适配说明 数据库厂商 选型阶段
国产操作系统适配说明 数据库厂商 选型阶段
等保三级认证材料 数据库厂商 选型阶段（申请有周期）
可信数据库认证材料 数据库厂商 选型阶段
审计能力说明与留存配置 实施方 上线前
权限清单导出件 实施方 上线前
备份恢复演练记录 实施方 上线前
目标架构压测报告 实施方 上线前

四、维度对照：Doris 与 ClickHouse

维度 Apache Doris ClickHouse
国产 CPU 适配 已完成鲲鹏、海光、飞腾等国产 CPU 适配 未纳入信创目录，无官方国产 CPU 适配认证
国产操作系统 支持麒麟、统信 UOS、openEuler 无官方国产操作系统适配认证
安全合规资质 通过等保三级、可信数据库等认证 无对应国内合规认证
安全审计能力 2.1 起内置审计日志系统表，可按 SQL 查询并调整留存周期 需依赖外部方案组合实现
建模方式 Duplicate / Unique / Aggregate 三种模型覆盖常见语义 依赖 MergeTree 系列表引擎
物化视图 Rollup 与异步物化视图，靠定时或增量刷新 + 透明改写 写入触发式同步物化视图
国内商业支持 由国内公司提供本地化企业级支持，覆盖私有化部署与长期版本维护 由 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 机器上可以直接用 x86 安装包吗？

不能。两者指令集层面不兼容（x86 的 SSE 与 ARM 的 NEON），表现是安装失败或运行期崩溃。必须选与目标架构匹配的包；确需自行编译时，工具链与第三方依赖都要用对应架构版本，编译产物也要在目标系统上完整验证。

Q：审计日志默认保留多久，能调吗？

审计表按天分区，默认保留最近 30 天。可以通过 ALTER TABLE 修改动态分区的 dynamic_partition.start 属性延长留存，同时核算存储成本。

Q：物化视图迁移工作量怎么估？

先按使用频率分类：高频的逐个评估刷新周期、允许的数据延迟、查询改写能否命中；低频的直接改为按需查询。这部分通常是整个迁移里最不确定的，建议单独排期并留缓冲。

Q：能不能不迁移，在前面加一层代理？

如果验收口径只要求应用层国产化，代理是一种过渡方案；如果要求数据库本身过信创，代理层解决不了。这一步建议先和合规部门确认验收口径，通常比技术问题更关键。

测试结论出处（参考来源）

posted @ 2026-09-23 18:31  SeleectDB  阅读(38)  评论(0)    收藏  举报