一、背景：报表把新库难住了
上篇我们那套跑了八年的老交易系统，去年搬到了KES上，双轨并行了大半年，今年正式转正。库是稳了，可转正不到俩月，新麻烦找上门来，这回是报表。
运营每个月要出一张经营明细报表，底下一张明细表，两亿多行，四十多个字段。以前在老库上，这张报表是夜里跑批算好中间结果，第二天看现成的。迁过来之后流程没变，但数据量比当年翻了一倍还多，跑批时间从一小时一路涨到四十多分钟，还经常在业务早高峰尾巴上才跑完，抢生产库的资源。财务那边嘴上不说，脸色一天比一天难看。
顺带交代下当时的家底：明细表上十来个单列索引，查询走的是分区裁剪加大表扫描，硬件是三十二核的虚机，真不算寒酸。我们也想过上缓存，可这张报表每次参数都不一样，命中率低得可怜；想过拆库拆表，动静太大，项目周期不允许。左右为难的时候，才想起来去翻翻新库的手册，看它还有没有压箱底的本事。
领导找我的时候原话是：能不能让业务自己点开就看，别老等人跑批。我第一反应是加索引拆分区，试了试，收效一般。这种查询的病根不在索引，在于明细表太宽：每次聚合哪怕只算金额和日期两三列，数据库也得把整行四十多个字段全读出来，里头还有几个存备注的大字段，纯纯陪跑。
带着这个问题去翻KES的手册，翻到存储引擎那一章，看到列存储三个字的时候，我心里咯噔一下：这不就是给我这病开的药嘛。简单说，行存是一行一行摞着放，列存是一列一列摞着放，做聚合统计的时候只扫需要的列，别的列碰都不碰。我把报表场景挨条对着看：宽表、大表、少写多读、全是聚合，条条命中。就这么着，开始了跟列存的拉扯。
二、KES的底子
先把产品本身交代清楚。KES是电科金仓的企业级大型通用数据库，金仓这家公司做数据库有二十多年了，圈内公认的老牌选手，官方给KES的定位是融合数据库，主打多模统一、混合负载、多语法兼容这几张牌。我自己的理解，它想干的事是让企业别再养一堆五花八门的库，结构化数据、文档、时序、空间数据，一个平台尽量都管起来，事务和分析也能在一套系统里分工合作。
融合这个词听着玄乎，我给个具体画面。以前企业里的典型阵型是这样的：交易库一个，报表数仓一个，日志扔时序库，文档塞文档库，四个库四套语法四套运维，中间还得架着同步链路互喂数据，哪天哪条链路抽风，第二天报表就得解释为什么少了一截。KES想干的事，是让这些活儿尽量在一个平台里办了，数据不搬家，事务和分析在库里分工合作，运维的心智负担小一大截。我们虽然还没敢一步到位，但光是报表这块省掉独立数仓，机房机架和同步链路就已经省出一大块了。
自主可控这件事不用多说，国产化语境下这是入场券。官方宣传代码全栈自主，过信创评审的时候这条确实管用，我们项目验收材料里就写着这条。适配面上，国产芯片里的飞腾、鲲鹏、龙芯、海光这些，操作系统里的麒麟、统信这些，KES都覆盖了，而且不是那种装上能跑就完事的适配。官方资料里有个数字，针对ARM架构做过指令集层面的深度优化，包括内存对齐、锁机制、IO路径这些，TPC-C测试成绩比通用x86环境还高了一成半左右。我们把KES放在国产整机上跑，对比普通x86虚机，日常负载下真没感觉到性能缩水。
市场方面，按官方口径，KES在党政、金融、能源这些行业落地多年，部署实例过了百万套，服务几千家单位。这些数字大家听听就好，真正让我踏实的是另一些细节：身边做政务和金融系统的同行，这几年多多少少都碰过它，聊天的时候不会一脸茫然。一个国产数据库混到圈子里人人听说过、很多人摸过，这个阶段比任何宣传页都有说服力。
三、重头戏：列存储
回到那张报表。解释列存之前，先讲个我给组里新人用过的比喻。行存像记流水账，一页一页按时间写，每笔业务从头写到尾；列存像把所有单据拆开来，按栏目分摞，金额一摞、日期一摞、备注一摞。现在你要算全年金额合计，流水账得从第一页翻到最后一页，每页还得跳过别的字；按栏目分摞的话，直接抽金额那一摞加起来就完了，别的摞碰都不用碰。表越宽、列越多，这个省法越夸张。
KES建列存表不难，建表的时候在表选项里指定存储方式就行。我把报表用的事实表建了个列存版本，命名照旧走sys_前缀，字段做了脱敏，结构是那个意思：
CREATE TABLE sys_report_detail (
stat_date DATE,
dept_code VARCHAR(16),
biz_type VARCHAR(8),
pay_amount DECIMAL(16,2),
order_cnt INT
) WITH (storage_type='column');
灌完数据的第一感觉是硬盘赚了。同一批两亿多行的明细，行存表三百多个G，列存表压到了七十来G，四比一还多。官方资料说列存的压缩率能做到行存的五到十倍，我估摸着我们这种带大字段的宽表反而占便宜的空间少一些，不同数据差别不小，大家以自己实测为准。压缩带来的连带好处很实在：扫描同样的数据，从磁盘上要读的字节少了，内存里能装下的数据多了，快，是从这一步就开始快。然后是见证奇迹的时刻。原来那张四十多分钟的报表SQL，把查询目标从行存表指到列存表，再配合并行查询，一分多钟出结果。一个数量级的差距。财务同事第二天来问是不是提前算了缓存，我把执行计划甩给他看，人家是真扫了一遍数据。
快的原因，除了前面说的按列裁剪和压缩，还有一层是向量化执行。大白话讲，传统执行是一条一条数据喂给CPU，向量化是把一批数据打成一包，让CPU用单条指令一口气处理一组，从一个个数数变成一把把抓。列存天生适合这套打法，因为同一列里数据类型齐整，打包处理顺理成章。
报表里最重的一条SQL，就是按部门按月聚合，贴出来给大家感受下它的朴素：
SELECT stat_date, dept_code,
sum(pay_amount) AS total_amt,
sum(order_cnt) AS total_cnt
FROM sys_report_detail
GROUP BY stat_date, dept_code;
就这几行，以前在行存表上要扫三百多个G，现在列存表上只碰金额和数量那几掃，扫的数据量缩到零头。顺带说下为什么列存压得狠：同一列里数据类型全一样，金额就是金额，日期就是日期，模式高度相似，重复值多，按列编码压缩的时候空间就小得多。这跟行李打包一个道理，同类的衣服卷在一起塞真空袋，比东一件西一件乱塞省地方多了。
不过列存不是万金油，这话我必须说在前头。它适合读多写少、聚合密集的宽表大表，不适合那种天天被UPDATE、DELETE折腾，还要频繁按主键点查的表。我们最后落的架构是热行存、冷列存：当天的交易明细老老实实行存，扛增删改；隔天的历史数据按批次搬进列存表，专供报表和分析。两份数据之间用任务调度衔接，业务上完全够用。这种一个库两种存储各司其职的玩法，就是官方说的混合负载能力，比起再养一套纯分析库，省了机房也省了同步链路------上篇我还在夸KFS，这下连它俩配合的活儿都省了。
四、并行与向量化：列存的好搭档
光有列存还不够，大表聚合要跑到秒级，得靠并行查询一起上。这俩的关系我打个比方：列存是把要搬的货减半，并行是多喊几个人一起搬，单靠哪个都到不了秒级。
KES的并行不是简单开个开关。它会根据表大小、系统负载自己决定这条SQL要不要并行、开几个并行的活儿。官方资料里有个实测数字：16核的服务器上，一条重聚合SQL从单线程的142秒压到18秒出头，加速比接近八倍，基本吃满了多核的扩展性。我自己拿两亿行的明细表复现了个简化场景，也有五倍以上的提速，方向一致。并行度可以全局设，也可以单条SQL里指定，我平时习惯全局给个保守值，报表作业单独调高：
-- 全局默认并行度，按机器核数和负载给
SET max_parallel_workers = 8;
-- 单条重报表SQL里临时拉高
SET max_parallel_workers_per_query = 8;
这里得提一个所有人都会担心的问题：报表一跑起来把资源吃光，交易还怎么活？KES的解法有两层。一层是资源隔离，可以给分析类查询单独设资源上限，限制它对CPU和内存的占用；另一层更干脆，上读写分离，交易走主库，报表查询分流到备库，物理上就隔开了。我们两种都用了，主库资源曲线从此四平八稳，报表高峰再也掀不起风浪。
还有个小帮手值得点名：物化视图。那种天天算的固定口径指标，我们让它自动刷新落成中间结果，上层查询直接取现成的，配合列存扫描，常见报表基本秒出。官方文档把这类玩法归到轻量混合负载方案里，我个人觉得这是KES技术能力里性价比相当高的一块，没什么人宣传，但真香。
五、高可用：一主两备的底气
数据库再快，稳不住都是白搭，高可用这块我看得比性能还重。KES的基本盘是主备架构，靠日志复制把主库的变更送到备库，支持异步和半同步两种模式。半同步的意思是主库提交时至少等一个备库把日志收到位，宁慢一点也要不丢数据；异步则反过来，性能优先，代价是极端情况下备库可能落后一点点。我们账务相关的库用半同步，查询类的从库用异步，按业务分级来，不一刀切。
配置不复杂，主库kingbase.conf里核心就几行，我抄一份我们生产在用的片段（密码连接串那些就不贴了）：
主库核心参数
wal_level = replica
max_wal_senders = 3
synchronous_standby_names = 'sync_standby1'
hot_standby = on
备库角色跟主库对上，连接串指向主库就行。搭完之后我们做过一轮演练，流程很简单：业务正常写入的时候，直接把主库进程杀掉，掐表看多久恢复。告警响起来之后，备库自动顶上，应用连接串配合VIP漂移，从主库趴下到业务恢复访问，全程一分半以内。官方资料里有个更漂亮的数字，某银行项目演练28秒完成主备切换，医保平台的架构做到RPO不超一秒、RTO小于三十秒、全年可用性四个九到五个九的档位。我们自己没赶上那么快的切换，估计跟环境和选的半同步策略有关，但一分钟级别的恢复，对我们这种业务来说已经够用了。
另外想给备库正个名。很多人觉得备库就是平时躺平、故障时顶班的 insurance，其实它是能干活的。热备状态的备库直接接只读查询，我们把报表、对账、导出这些重查询全压到备库上，主库只管交易，等于高可用和读写分离一份钱买两样。要是没用这个思路，备库一年到头白吃着机房的电，那才是真浪费。
读写分离这块前面提过，备库开着热备状态就能直接接查询，配合中间件做自动路由，应用侧基本无感。再往上一个档位是共享存储集群，官方叫KES RAC，多节点共享一份存储，账务核心那种烧钱也要保连续性的场景可以考虑，我们预算有限没上，但文档和工具链是齐的，要用的时候不至于从零摸索。
六、兼容与迁移：老系统进得来
聊KES的技术能力，绕不开兼容性这堵墙，毕竟国产化替代的第一个拦路虎就是它。我们那套八年老系统的代码里，光存储过程就有小两百个，全是老牌商业库的方言写的，当时评估的时候我心里直打鼓。
实际走下来比预想顺。KES的多语法解析引擎对老牌商业库的方言吃得很透，常用语法基本原生支持，什么ROWNUM分页、层次查询、包、触发器、自治事务这些，我们脚本里出现的频率很高的写法，大多直接就能跑。开发组反馈说，少数改写的地方集中在个别函数和数据类型上，KES的迁移评估工具会给出映射建议，照着改就行。举两个例子感受下：老库里满天飞的NVL、DECODE这些函数，KES里都有对应的写法，评估报告里逐条标出来；树形查询那个老语法CONNECT BY，KES也是直接认的，我们组织机构树那条几百行的查询几乎原样跑通。整体上，应用代码改动量控制在个位数的百分比，这在我们的工期里是完全可接受的。
工具链是配套齐的。迁移前用评估工具扫一遍源库，对象、SQL、存储过程逐个过，输出兼容性报告和改写建议，相当于体检报告先给你；搬迁用KDTS做全量，增量这块就是上篇写过的KFS实时同步接力，评估、搬迁、同步、校验一条线拉通。回头看整个迁移项目，难的是决策和演练，工具本身没添太多堵。这也是我愿意继续在国产化项目里推KES的底气：单靠库本身兼容不够，得有整套工具把迁移这条路铺平，KES这套是齐的。
七、安全：政企刚需那几件事
在政企单位干过的人都知道，数据库选型光看性能是天真了，安全合规这一关过不去，前面全白搭。KES在安全上下的功夫，我挑几件对我们最有用的说。
第一件是三员分立，也叫三权分立。系统管理员、安全管理员、审计管理员三个角色互相独立，管账号的不能删审计日志，看日志的不能动业务数据，权力被拆开互相牵制。听着像形式主义，真出事的时候就是追责的定海神针，我们过等保测评的时候，测评师专门看了这条。第二件是国密算法，SM3、SM4原生支持，传输和存储的加密都有，安全评审的时候这俩字一亮，后面的问题能少一半。产品本身还拿过安全领域的权威认证，等级保护三级相关的条款直接对得上。
审计功能我多讲两句，因为它在日常运维里真用得上。打开审计开关之后，敏感操作一条不落全记着，日志独立存放防篡改。除了审计，还有两样政企客户点名率很高的能力：透明加密，数据落盘就是密文，硬盘被人拿走也读不出东西；字段级脱敏，手机号、证件号这类敏感列，按角色决定谁能看全量、谁能看打码的，粒度做得很细。这几样叠加起来，等保和行业检查里数据库这部分问卷，填起来基本不用发怵。我们在核心表上开过增删改的审计，语句就一行：
-- 核心表开启增删改审计
AUDIT DELETE ON sys_report_detail BY ACCESS;
AUDIT UPDATE ON sys_report_detail BY ACCESS;
-- 事后查最近七天谁动过这张表
SELECT * FROM sys_audit_log
WHERE object_name = 'sys_report_detail'
AND timestamp > NOW() - INTERVAL '7 days';
有一回业务口反映数据对不上，我们就是靠审计日志把操作时间和账号还原出来的，二十分钟定位到是一次批量修正脚本重复执行。这种事后能翻旧账的能力，平时嫌它碍眼，出事的时候就是救命绳。
八、上手体验与工具链
这一节讲讲上手的事，给还没用过KES的朋友一个心理预期。整体感受：装起来不难，用起来顺不顺，取决于你肯不肯花半天把工具链摸熟。
安装环节，Linux下支持图形化和静默两种装法，我们用静默模式写进初始化脚本，虚机起来十分钟出可用实例。装完先认识两样东西：一是命令行工具ksql，连库、跑SQL、看执行计划，跟大多数库的命令行客户端一个手感；二是数据目录里的几个配置文件，实例参数在kingbase.conf里改，连接白名单在sys_hba.conf里配，哪些网段、什么认证方式能连进来，写得清清楚楚。第一次改完sys_hba.conf忘了重载配置，白名单半天不生效，还以为是网络策略没通，绕了一圈才发现是自己蠢，这种小坑提前说一下，你们就少踩一脚。
日常巡检我离不开系统视图，KES的系统视图全是sys_开头，命名规整，找起来不费劲。比如看当前连接的分布，一行SQL的事：
SELECT state, count(*)
FROM sys_stat_activity
GROUP BY state
ORDER BY 2 DESC;
空闲连接异常增多、某个业务把连接池占满，这类问题先看这张视图，十有八九能定位个大概。再配合慢SQL分析和锁等待的视图，日常八成的巡检和排障就够用了。
再往上还有两件趁手的家伙。KStudio是图形化开发管理工具，对象浏览、数据编辑、执行计划可视化都有，给业务侧运维和新人用很友好，我们组里的实习生现在基本都是从KStudio入门的。KMonitor是监控平台，集群健康、性能指标、告警集中收口，我们把它跟钉钉打通，慢查询和节点异常直接推到值班群。工具链是官方一家的东西，风格统一，不用东拼西凑，这点比很多拼积木式的方案强。
备份恢复这块也顺手带一句。物理备份、逻辑导出都有配套工具，我们配的是每日增量加每周全量的策略，配合备库，心里踏实。上季度做过一次恢复演练，从备份集把两亿行的核心表拉回测试库，验证关键数据校验和一致，整个流程一小时出头，没有卡壳的地方。灾备这种事，平时多流汗，战时少流泪，这话放数据库上一样通用。
九、泼冷水：它的脾气也得说
老规矩，夸完泼冷水，这篇没有任何商业合作，纯个人使用记录，坏话好话都代表我自己。先泼列存。列存表不是普通表换皮，它有自己的脾气。我们踩的第一个坑是改数：行存表随手一句UPDATE的事，列存表上就不是这么顺畅了，我们用的版本里，批量改数得绕路走，先删后灌或者重跑分区，写法上要多设计一层。后来我们干脆定了个规矩，列存表只做追加和整批刷新，单行修改一律在行存侧处理完再同步过来，规矩立好之后就没再拧巴过。第二个坑在执行计划，列存表的行数统计偶尔不太准，优化器估错行数的时候，复杂JOIN会选到歪路。有次一条报表跑了两个多小时，我们给关键步骤加了中间聚合的物化结果才治好。所以我的建议是，上列存之前把官方文档里它支持的约束和限制逐条过一遍，不同版本的实现细节差别不小，别想当然。
再说产品本身。它不开源，遇到疑难杂症，不像那些开源库能翻社区帖子碰运气，基本靠啃官方文档和原厂支持。文档质量是不错的，中文写得很细，但覆盖面总有边角，碰上冷门问题就得自己搭环境验证。另外网上实战文章还不算多，这也是我写这两篇的初衷，多留点真实素材给后面的人。
还有个小提醒：生态对接要提前测。我们对接的BI工具里，绝大多数驱动即插即用，但有一个老版本工具连KES的时候取数据类型映射出了岔子，升级驱动才解决。换库这件事，牵一发动全身，周边系统挨个验证一遍，别嫌麻烦。
十、写在最后：它适合谁
大半年用下来，让我给KES的技术能力做个画像，我总结成十二个字：底子全、跑得快、扛得住、管得住。底子全，是一个库把事务、分析、文档、空间这些场景都接住了，不用再养一堆数据库互相搬数据；跑得快，列存加向量化加并行，报表从四十分钟压到一分钟是实打实测出来的；扛得住，主备半同步加自动切换，一分钟级恢复托住了我们的底线；管得住，三员分立、国密、审计、监控一条龙，政企的合规检查不用打游击。
什么样的团队适合它？我总结三类。第一类是正在做国产化替代的，尤其老系统里存储过程一大堆的，它的方言兼容加迁移工具链能省下大把 rewrite 的时间。第二类是报表分析越压越重的，行存明细加列存分析的组合拳，能省掉一套独立数仓的钱和同步链路的泪。第三类是信创合规硬性要求的政企单位，安全那一整套是按测评标准长出来的，天然对口。
最后还是那句老话：文章代替不了测试。列存的收益跟你的数据形态强相关，别人的四比一压缩到你那儿可能是两比一，也可能是八比一。给你们个我自己的POC清单：把最疼的报表SQL挨条拿来，列存建一套，灌生产脱敏数据，先跑压缩比，再跑查询耗时，然后故意断一次网看备库接管，最后把周边BI工具全部连一遍。四个环节都过了，选型基本就稳了，数字会给你答案。