基于HANA重构业务的总结

本文于2019年7月29日完成，发布在个人博客网站上。

考虑个人博客因某种原因无法修复，于是在博客园安家，之前发布的文章逐步搬迁过来。

---

依据领导的规划，本月启动了一项业务迁移工作，作为特别行动，部门安排首席SE亲自带领南京团队交付。

本次特战的目标，使用恰当的技术，重构已有的实时业务，一劳永逸的解决业务交付过程中遇到的问题。

当前基于Oracle交付业务，存在的问题如下：

1. 业务方案不准确，存在反复。当前每月做一次生产上线，近期连续出现几次上线后第二天修复问题的现象，最近的一次上线，迫于方案导致的性能问题，被迫回退代码。
2. 实现方案复杂。新人上手需要花费巨量的时间来学习。
3. 故障恢复慢。遇到源系统数据延迟，数据错误等问题，修复数据时分析方案，实施方案，均耗时耗力。
4. 时效性不满足要求。当前基于数据仓库的技术栈交付近实时业务，在正常情况下，源系统产生数据后，一般要两小时左右才能将数据加工出来。随便出现一点问题，整体时延均会增大，导致不可用。

本次完成的内容：

1. 架构优化，基于主题的建设思路重新构建相关业务，简化加工处理的路径，减少处理层级。
2. 方案复用，复用了主题的建设方案，Mapping和取值逻辑。
3. 对齐理解，和下游业务团队对齐需求，方案。
   
   1）梳理全部字段的取数方案，逐个和数据管家，下游沟通。
   
   2）刷新关键字段的取数方案。
   
   3）裁剪不必要的字段。
4. 技术平台迁移，将基于Oracle交付的业务，迁移到HANA平台。
5. 开发团队内部，对于源系统的业务流程，数据交互等，有了初步的理解，便于后续工作的开展。

本次改造由首席SE亲自带队。

假如由我来主导，存在的差异有：

1. 沟通成本，沟通交流的成本比较高。首席SE带队，在方案评审等事项上不需要投入太大，不需要反复整理材料，反复给领导汇报。
2. 周边资源协调不会这么顺利，包括：
   
   1）周边人力，比如主题交付团队，数据管家，下游业务人员等，全力投入。
   
   2）硬件环境，测试，生产环境等。
3. 业务方案，推动下游业务梳理方案，投入程度，工作效率，输出结果等，可能会打折扣。另外交付团队在业务的理解上明显存在短板，迫切需要指导。
4. 技术方案，基于HANA交付：
   
   1）集成方案的选择和把控。
   
   2）开发方案的选择和把控，比如视图，表，存储过程的合理运用。
   
   3）上线方案的把控。
   
   首席SE去年基于HANA交付过一个项目，在HANA方面具备相当的经验。对于本次项目而言，有效的节省了技术方案验证的投入。
5. 交付进度。综上，考虑到上述的因素，很难在一个月内完成开发工作，保守估计至少需要两个月。