基于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. 交付进度。综上,考虑到上述的因素,很难在一个月内完成开发工作,保守估计至少需要两个月。

热门相关:我寄人间   邪王独宠:纨绔异能妃   隐身侍卫   疯狂的家庭   从她胸口流出的纯净水