为了给报表提速，我把金仓KES的列存储折腾了个遍：聊聊KES的技术能力

一、背景报表把新库难住了上篇我们那套跑了八年的老交易系统去年搬到了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_cntFROM sys_report_detailGROUP 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 replicamax_wal_senders 3synchronous_standby_names ‘sync_standby1’hot_standby on备库角色跟主库对上连接串指向主库就行。搭完之后我们做过一轮演练流程很简单业务正常写入的时候直接把主库进程杀掉掐表看多久恢复。告警响起来之后备库自动顶上应用连接串配合VIP漂移从主库趴下到业务恢复访问全程一分半以内。官方资料里有个更漂亮的数字某银行项目演练28秒完成主备切换医保平台的架构做到RPO不超一秒、RTO小于三十秒、全年可用性四个九到五个九的档位。我们自己没赶上那么快的切换估计跟环境和选的半同步策略有关但一分钟级别的恢复对我们这种业务来说已经够用了。另外想给备库正个名。很多人觉得备库就是平时躺平、故障时顶班的 insurance其实它是能干活的。热备状态的备库直接接只读查询我们把报表、对账、导出这些重查询全压到备库上主库只管交易等于高可用和读写分离一份钱买两样。要是没用这个思路备库一年到头白吃着机房的电那才是真浪费。读写分离这块前面提过备库开着热备状态就能直接接查询配合中间件做自动路由应用侧基本无感。再往上一个档位是共享存储集群官方叫KES RAC多节点共享一份存储账务核心那种烧钱也要保连续性的场景可以考虑我们预算有限没上但文档和工具链是齐的要用的时候不至于从零摸索。六、兼容与迁移老系统进得来聊KES的技术能力绕不开兼容性这堵墙毕竟国产化替代的第一个拦路虎就是它。我们那套八年老系统的代码里光存储过程就有小两百个全是老牌商业库的方言写的当时评估的时候我心里直打鼓。实际走下来比预想顺。KES的多语法解析引擎对老牌商业库的方言吃得很透常用语法基本原生支持什么ROWNUM分页、层次查询、包、触发器、自治事务这些我们脚本里出现的频率很高的写法大多直接就能跑。开发组反馈说少数改写的地方集中在个别函数和数据类型上KES的迁移评估工具会给出映射建议照着改就行。举两个例子感受下老库里满天飞的NVL、DECODE这些函数KES里都有对应的写法评估报告里逐条标出来树形查询那个老语法CONNECT BYKES也是直接认的我们组织机构树那条几百行的查询几乎原样跑通。整体上应用代码改动量控制在个位数的百分比这在我们的工期里是完全可接受的。工具链是配套齐的。迁移前用评估工具扫一遍源库对象、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_logWHERE 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_activityGROUP BY stateORDER BY 2 DESC;空闲连接异常增多、某个业务把连接池占满这类问题先看这张视图十有八九能定位个大概。再配合慢SQL分析和锁等待的视图日常八成的巡检和排障就够用了。再往上还有两件趁手的家伙。KStudio是图形化开发管理工具对象浏览、数据编辑、执行计划可视化都有给业务侧运维和新人用很友好我们组里的实习生现在基本都是从KStudio入门的。KMonitor是监控平台集群健康、性能指标、告警集中收口我们把它跟钉钉打通慢查询和节点异常直接推到值班群。工具链是官方一家的东西风格统一不用东拼西凑这点比很多拼积木式的方案强。备份恢复这块也顺手带一句。物理备份、逻辑导出都有配套工具我们配的是每日增量加每周全量的策略配合备库心里踏实。上季度做过一次恢复演练从备份集把两亿行的核心表拉回测试库验证关键数据校验和一致整个流程一小时出头没有卡壳的地方。灾备这种事平时多流汗战时少流泪这话放数据库上一样通用。九、泼冷水它的脾气也得说老规矩夸完泼冷水这篇没有任何商业合作纯个人使用记录坏话好话都代表我自己。先泼列存。列存表不是普通表换皮它有自己的脾气。我们踩的第一个坑是改数行存表随手一句UPDATE的事列存表上就不是这么顺畅了我们用的版本里批量改数得绕路走先删后灌或者重跑分区写法上要多设计一层。后来我们干脆定了个规矩列存表只做追加和整批刷新单行修改一律在行存侧处理完再同步过来规矩立好之后就没再拧巴过。第二个坑在执行计划列存表的行数统计偶尔不太准优化器估错行数的时候复杂JOIN会选到歪路。有次一条报表跑了两个多小时我们给关键步骤加了中间聚合的物化结果才治好。所以我的建议是上列存之前把官方文档里它支持的约束和限制逐条过一遍不同版本的实现细节差别不小别想当然。再说产品本身。它不开源遇到疑难杂症不像那些开源库能翻社区帖子碰运气基本靠啃官方文档和原厂支持。文档质量是不错的中文写得很细但覆盖面总有边角碰上冷门问题就得自己搭环境验证。另外网上实战文章还不算多这也是我写这两篇的初衷多留点真实素材给后面的人。还有个小提醒生态对接要提前测。我们对接的BI工具里绝大多数驱动即插即用但有一个老版本工具连KES的时候取数据类型映射出了岔子升级驱动才解决。换库这件事牵一发动全身周边系统挨个验证一遍别嫌麻烦。十、写在最后它适合谁大半年用下来让我给KES的技术能力做个画像我总结成十二个字底子全、跑得快、扛得住、管得住。底子全是一个库把事务、分析、文档、空间这些场景都接住了不用再养一堆数据库互相搬数据跑得快列存加向量化加并行报表从四十分钟压到一分钟是实打实测出来的扛得住主备半同步加自动切换一分钟级恢复托住了我们的底线管得住三员分立、国密、审计、监控一条龙政企的合规检查不用打游击。什么样的团队适合它我总结三类。第一类是正在做国产化替代的尤其老系统里存储过程一大堆的它的方言兼容加迁移工具链能省下大把 rewrite 的时间。第二类是报表分析越压越重的行存明细加列存分析的组合拳能省掉一套独立数仓的钱和同步链路的泪。第三类是信创合规硬性要求的政企单位安全那一整套是按测评标准长出来的天然对口。最后还是那句老话文章代替不了测试。列存的收益跟你的数据形态强相关别人的四比一压缩到你那儿可能是两比一也可能是八比一。给你们个我自己的POC清单把最疼的报表SQL挨条拿来列存建一套灌生产脱敏数据先跑压缩比再跑查询耗时然后故意断一次网看备库接管最后把周边BI工具全部连一遍。四个环节都过了选型基本就稳了数字会给你答案。