我的大数据之路 - 基于HANA构建实时方案的历程

产品内部前期有一个共识，依据业务要求的时效性来选择技术平台，即：

• 实时类业务，时效性小于2小时，则使用HANA构建。
• 离线类业务，时效性大于2小时，则使用大数据平台构建。

经过五月、六月两月的努力，离线类的业务已基本完成开发和验证完毕，后面待在生产环境对数完毕后，即可启动切换。

因此实时类业务的方案分析和梳理，成为当下最重要、最紧急的事情。

考虑到项目当前的痛点：

• 直接从I层构建业务，没有复用主题层的模型和资产。
• 缺少数据管家参与项目，帮助把关业务方案。
• 前期欠缺资料，很多需求没有积累方案素材。
• 项目开发团队大部分为新人，对业务的了解基本来自于代码，个别业务的理解由我或者项目PM传递，但考虑到我和项目PM的业务背景，效果非常一般。

因此在盘点完现有方案后，我基于如下原则，构建业务的实时方案：

• 在HANA平台，完全复用主题层模型的数据架构和取数逻辑，仅裁剪掉业务不需要使用的字段和表。这样，当主题模型发生变更时，实时方案可直接同步。
• 优先使用HANA的视图来承载业务。
• 假如取数逻辑比较复杂，使用视图无法实现，则考虑使用HANA的存储过程。
• 经验证，假如个别视图的性能无法达标，则考虑落增量实时表。

按照上述思路，技术方案会比较简单，基础表的清单和Mapping，可以直接复用各领域主题前期输出的材料。而下游使用的业务数据表，可以请各领域的SE协助输出Mapping和表的关联逻辑，项目组直接对数即可。

结果在技术评审会上，这个方案一经抛出，即被评审专家各种痛批。

我很无语。

。。。

领导安排首席SE投入项目，计划使用一个月，将实时业务交付上线。

不得不说，首席SE很有经验，做事很有章法：

• 盘点现有业务。输出模板，要求我和项目PM在一周内完成梳理。当时由于某业务非常复杂，不得已还安排一个开发同事参与。
• 整理技术方案和痛点。将整理过程中遇到的问题，梳理为技术类问题的清单和方案类问题的清单，分别找人确认。
• 开工会、晨会、业务培训。
  • 开工会。明确项目目标和要求，和开发组成员交流，了解大家的情况和想法、个人诉求。
  • 晨会。将前期的电话会议，调整为现场会议，提高沟通效率，便于掌握交付进展。
  • 业务培训。晨会上常规的项目管理类内容完成后，即开始讲解业务，让开发同事快速入门。
• 细化方案。输出Mapping，明确依赖的表清单和取数规则。
• 周边协调。
  • 和产品内部、产品周边协调、确认问题。
  • 协调开发和验证、生产环境。

经过两周的努力后：

• 环境，包括开发和生产已协调到位。
• 前期整理的问题，已有初步结论。
• 技术方案的细节基本明确。
• 下游业务初步认可技术方案。

后续的重点工作，将从方案分析转变为交付工作。

后记1

在整理方案过程中，发现首席SE输出的方案其实和我输出的方案有某种相似性，比如：

• 业务场景，都使用主题定义的场景。
• 数据架构，都参照主题定义的模型。
• 基础视图、表、存储过程的代码，基本上照搬模型表的实现代码。

但存在明显的差异点，首席SE在梳理方案时：

• 按需出发。
  • 要求下游业务明确关键的字段和数据，进而裁剪了部分未使用到的字段。
  • 梳理实现不合理的方案细节，要求下游业务变更方案。
  • 不容易理解的方案细节，要求下游给出解释。假如下游业务团队说不清楚，则直接搁置相关特性，转需求跟踪。
• 从经验出发。
  • 简化主题模型的取数实现，降低实现难度。
  • 依据经验，提前明确以HANA表实现的基础表的清单。
  • 依据经验，提前明确使用存储过程来实现的基础特性的清单。
  • 提前准备集成数据的方案。
  • 相关人力、环境等资源，提前协调到位。

另外一点，首席SE带队来设计方案：

• 自身对业务非常了解，可以有效提高方案的输出效率，减少返工。
• 评审方案的沟通成本下降很多。因为首席SE自己输出的方案，对细节很清楚，遇到评审专家的挑战，可以快速响应。
• 和下游业务团队的沟通成本，同样下降很多。

不得不承认，功夫在诗外。假如由我来主导实时方案的实施，在上述差异点上，会花费大量的精力，可能存在较多的返工，对进度而言无疑是非常大的风险。

后记2

近期过的并不太平，几件事情挤在一起，让本来明朗的项目周边形势，又紧张起来。

• 第一件事，将现有业务迁移至HANA的方案，在评审会上被周边专家痛批了一通，意味着方案要重新做，重新评审。
• 第二件事，基础维表的数据出现了错误，导致X业务的数据出现了大面积缺失，影响到了下游一片业务。其实这事情放平时，把数据修复好，然后和下游业务团队说说好话，事情就过去了。结果大BOSS正好在客户那边交流，于是这件事情被当成典型，BOSS从客户那边带回来，作为重点任务关注。
• 第三件事，下游Y业务要放开推广，正在验证数据，发现某些设备的数据缺失现象比较突出。恰好近期Y业务自身的问题比较多，压力比较大，于是借本事件小小发挥一下，转嫁部分压力出来。于是这件事情被当成典型，BOSS要求马上处理。

这三件事情恰好发生在同一天，产品经理对于我和项目组的表现非常不满，非常不放心，于是连夜安排首席SE到项目组异地支持一个月，将业务迅速切换至HANA平台，一次性解决项目当前遇到的问题。

平心而论，我没有使用HANA做过项目，所以将业务迁移至HANA的方案，做的相对比较粗，不是首席SE想要看到的可以体现细节的技术方案；此外缺少业务背景，有很多细节说不清楚。考虑到我欠缺做数据仓库类项目的实战经验，因此领导不放心是正常的，可以理解。但也加重了我的工作量，评审方案时，从材料到讲解，均存在被炮火覆盖的可能。

首席SE空降项目组之后，快速进入角色，拉着我和项目PM以及个别项目组开发同事，一起梳理现有方案。

此时生产环境连续出现意外：

• 周日早晨，我在例行检查跑批任务的状态时，意外发现某些任务运行失败，联系同事检查后，发现跑批任务出现了大量失败的现象。相关情况上报产品经理，领导决策兵分两路，由首席SE带队定位、解决问题，其余的人则分头修复数据。我的周末就这样报销了。
• 接下来的周一的早晨，我收拾电脑出门前，随手检查了一下任务跑批情况，发现平时在6点前可以跑完的任务，居然发生了严重的延迟。考虑到近期正好是月结、半年结，数据类的问题要求及时上报，于是赶紧汇报领导。结果和周日一样的分工，首席SE带队定位、处理问题，其余的人则分头修复数据。周一上午就这么过去了。

接连发生意外事件，再加上项目组接手的业务的实现方案确实很复杂，在和项目组一起参加了几次周边的沟通会议后，首席SE后来私下里表示，终于体现到项目组的不易了。