2024：信创迁移、海量数据治理与 AI 的敲门声

这一年发生了什么

2024 年 11 月，我加入一家新公司，进入金融核心业务系统这条赛道。资金清算、账务核对，7×24 小时不允许出错——从「性能优先」的互联网思维，切换到「正确性优先」的金融思维。

同时，AI 编程工具在这一年爆发式普及，年底我第一次认真地把 Cursor 用进了日常工作流。

技术上的变化

1. Oracle → GaussDB 信创迁移

• 数据类型映射、隐式转换差异的专项排查，把代码改造成本降低了 30%+；
• 针对分布式架构优化 SQL 分发与聚合逻辑，合理设置分布键避免数据倾斜。

体会：迁移的难点从来不是语法，而是老数据库替你默默做的那些事（隐式转换、空串与 NULL 的处理）。

2. 存储过程的大数据化改造

原 Oracle 存储过程中的批处理规则，转译为 Spark SQL 并行计算（合理分区避免 Shuffle 倾斜），中间结果落到 HBase（RowKey 前缀 = 业务日期 + 单据 ID，支持范围查询）。批处理耗时从 30+ 分钟降到 3 分钟以内，日终处理窗口缩短 80%。

3. SQL 调优与数据治理

• 最左前缀原则重构复合索引、@BatchSize 干掉 N+1，核心接口从秒级到毫秒级；
• 参与制定「分库分表 + 冷热分离 + 历史归档」策略，千万级大表按时间物理拆分，单表查询效率提升 40%+。

4. 业务状态机

设计覆盖 12 种状态流转的业务单据状态机（录入→复核→审核→执行→异常作废），支持主从单据分拆与合并。Kafka 承接状态变更的事件驱动通知。状态机是治理复杂业务最朴素也最有效的武器。

5. AI 敲门

年底开始用 Cursor + DeepSeek 辅助生成样板代码。第一感受：生成的代码 80% 可用，但剩下 20% 的边界情况，恰恰是资深的分界线。

个人感悟

金融系统教会我：慢一点没关系，错一次都不行。

这一年对「经验」的定义发生了变化：以前觉得经验是「知道怎么做」，现在认为经验是「知道哪里会坏」——而这些坑，AI 一个都没踩过。