敏捷转型:从搭建TB级大数据应用说起

社区广播:运维派(Yunweipai.com)是国内最早成立的IT运维社区,欢迎大家投稿,让运维人不再孤寂的成长!

作者介绍

朱志,建设银行厦门开发中心技术管理处负责人,目前主要负责大数据技术平台规划和技术资产管理。在银行IT项目管理、数据分析、数据治理以及架构设计领域工作了十五年,曾领导过建总行人力资源项目、ERP报表项目、分行数据分析平台ODSB项目、管理会计项目以及新一代信息系统数据分析平台的建设。

现在各种大数据会议充满了AI(人工智能)的主题,还好仍有人强调数据敏捷性,要不我今天分享的Data APP敏捷实践话题就落伍了。敏捷诞生也有二十多年了,经历了两次高潮,何时提敏捷都不落伍。

今天介绍的这个Data APP基本目标是支撑100,000+用户、120亿条数据、TB级存储、秒级响应。比起性能,更受用户欢迎的功能在于支持不同机构或业务条线发布数据,支持不同岗位不同角色不同用户按需订阅,而这些丝毫不用技术人员介入。

Data APP

看这个逻辑架构图,Oracle、GreenPlum、Teradata不同系列的数据库产品(不同的计算区)计算出来的各种指标,通过ETL技术把各种数据源源不断地汇入公共访问区,接着通过Redis、HBase和Kylin等时下流行的开源技术实现两级缓存以应对海量的移动用数访问。移动端采用了HTML5技术屏蔽设备操作系统差异,同时VUE.js和ECharts等技术实现了数据展现和自动推送。通过参数化设计将业务运营从开发中分离出来,让工程师更加关注如何支持好业务数据和用户自然增长。

这种自我生长的APP模式,就像一颗树苗,依靠树根从土壤(GreenPlum和Teradata构成的计算区)源源不断地吸收养分,再通过树干(公共访问区)以及树枝(各级Cache)生出树叶(用户在移动APP端用数),通过这种架构的孕育,树苗长成参天大树不过是时间问题。

APP

注:树型架构,出处参见高焕堂 Annpping Kao所著《思考软件,创新设计——A段架构师的思考技术》第5页“1.4软件的复杂时本质性的-架构师从复杂设计出简单”)

这个APP从什么时候开始蕴藏着如此巨大的能量?

1962年9月12日,肯尼迪发表了著名的月球演说之后(https://er.jsc.nasa.gov/seh/ricetalk.htm),NASA硬着头皮开始登月,阿波罗1号竟然在地面就爆炸了,经历多次失败,直到阿波罗8号首次完成了载人环行月球一周并返回地球之后,NASA才确信人类登上月球只是时间问题。很多人知道阿波罗11号登月成功,却不知道在肯尼迪航天中心纪念的是阿波罗8号,因为这个阿波罗8号是工程师所怀念的成功原型。是的,这几个简单的界面就是Data APP的“阿波罗8号”,接下来重点介绍如何通过敏捷开发打造出这个“阿波罗8号”。

知易行难(2016年5月-2016年8月)

第一步,按图索骥。

大数据这条路上,一定要看每年发布的大数据蓝图(《Big Data LandScape》由Matt Turck首先于2012年提出,通过这张图的更新,可以找到业界的技术投资潮流)。这张图的使用诀窍,在于要透过复杂的表象按照大数据技术的抽象分类(可参考http://www.bigdatalandscape.com)来寻找可能的技术方向。

这个项目刚开始的时候,我们想法很简单,采用H5技术屏蔽IOS和Android,用ECharts实现移动端数据可视化,沿用数据平台公共访问区已有的GreenPlum。

大数据

数据

第二步,按部就班。

一项技术要成为企业的选择,必须经历一系列的测试,从功能到非功能,根据预先设定的指标进行匹配,找到最合适的。入选企业级技术产品目录后,再逐步推广,产生规模效应。选好的技术不涉及商业产品,时间紧任务重,赶快出活才是硬道理。

第三步,用户至上。

在应用架构、数据架构和技术平台几个层级上,解决了共享问题之后,要按照用户体验组合这些组件服务,在保证后台功能相对稳定的同时,积极拥抱用户在前端需求的快速变化。用户体验组(移动端用数需求负责人),多次走访基层网点和分行部门及高层的管理人员,按照不同岗位提炼出了典型应用场景(晨会、周会、经营分析会),形成了100多页需求。

架构

逻辑推理加稳步执行,这顿想象中共襄盛举的数据自助餐应该水到渠成。经过三个月的努力,按计划到了初始版本交付的时间。原计划要交付分行三类管理岗位和一个总行部门的功能,结果只交付了基层网点负责人的部分页面。

就拿首页来说,在测试环境还好,上了生产之后,运行了一周惨不忍睹,页面要跑10来秒,数据对不上、缺数也是常有的事。更悲哀的是,付出艰辛努力经历了试运行失败的同志们,还要被“不就是推几个数到手机上这么简单的事情”的质疑所摧残。一切印证了一句古话,大道至简,知易行难!

数据

置之死地而后生(2016年9月)

按照原有需求交付软件,已经不现实了。要解决问题,得先看看到底发生了什么?

负责需求的业务人员说:“我们设计了20几个场景,需求写了几百页,我们从来没有这么认真对待过需求……”

负责指导实施的架构师说:“我们选择了最先进最流行的技术,实现了H5典型页面和数据服务,数据慢主要是因为……(反正是别人,不是自己,列了一些)”

负责实施任劳任怨一脸无辜地程序员说:“手机页面需求大版本变更了3次,我们100多个页面足足做了3次,我们没日没夜加班也就实现了总量60%的页面功能,程序能部署上线已经不错了……如果没有变更,或许会好一点。”

参与项目的每个人说的都没有错,可是结果不好,没有人承担责任,一定是整个团队都出了问题。回顾雄心壮志开启移动端开发的初衷,在没有公司资源辅助投入的情况下,我们作为甲方中的乙方,似乎把业务人员的口味调高了;随着项目深入,业务人员对移动端的认知稳步提升,三次大规模的需求变更就是业务人员进步的实证。其实,大家都害怕移动端不能一炮打响!

然而,随着时间的发展,每个人都热情高涨的添砖加瓦,要啥给啥,只有技术人员为进度所迫不断降低对自己的要求(包括范围和质量),缺乏沟通也没有实时的产出物可以验证,而交付和期望的差距已经发展到不可收拾的境地。到了约定交付的时候,发现业务用户的情感在瞬间熄灭,领导层的许诺也随之崩塌,这也是许多瀑布型项目失败的原因。
我们如何才能扭转这个局面?想起这三年关注的数据敏捷开发,干脆把死马当活马医,于是这次危机就成了我们敏捷开发实践的机会。于是,我们就按敏捷的教科书上说的,第一要把需求变成用户故事,第二要把故事按轻重缓急排个序,实施团队在此基础上构建软件的最小可运行集。

第一天,我们就依葫芦画瓢把原来的Word需求文档,通过CV大法整理成教科书中要求的用户故事的样子——作为XX(具体人名),为了XX目的,需要提供XX功能。整理了不到十个用户故事,小伙伴们开始怀疑这样做的意义!敏捷的本意就是关注目标,避免过于浪费的过程。把内容写在便签纸上,贴在墙上,标上约束,足够提醒程序员要做什么。最关键的是,要让技术人员和业务人员通过直接沟通在故事的验收标准(测试用例)达成一致。

看到五颜六色的便签图片了吗,黄色或绿色便签用来写用户故事,橙色用来写约束,红色用来标问题或是技术债。事情做完或问题解决后,便签就会从墙上摘下来放进盒子里,随着时间的推移,放进盒子里的便签越来越多,团队的自信心就这么一点一点的找回来,大家慢慢的忘了什么事情做不成,而只去想“能做成什么”。
还有一个事情要说一下,关于用户故事的排序问题,如果直接询问业务人员,很难得到确定的回答。那个时候已经九月初离第二次试运行上线只有一个月了,如果每一天都当作最后一天来过,用户需要的是什么,我们又能做出什么回应?运气很好,恰恰是这两个问题,把我们和用户拉到了一起。毕加索抽象公牛的手稿,启发了我们对抽象的思考。按不同岗位的工作场景编写的需求,本质的诉求在于让业务人员通过手机移动端随时可以看到关键指标,而不在于业务场景和页面需求的多少。有了抽象思维,整个小组达成了共识,与其“按期交付100个不可运行的页面“,不如“只交付最有用且保证质量的5个页面”。我们开始意识到,通过抽象思维,可以总结页面模式,不需要那么多页面和场景也能达到目的。
可是,什么样的页面模式才能达到我们的目的?我们如何找到“阿波罗8号”?我们的运气很好,珅哥用VUE改出的第一套页面模板(首页、指标趋势分析、机构信息和结构解析四个页面),就得到了用户和其他开发人员的认可,再多的指标再多的场景,只要把这个四个页面的性能调到1秒以内,任何指标分分钟实施完。为了测试用户体验,我们甚至把业务参数化设计也放到一边,改用json配置先看看哪些业务参数易变。

是不是很神奇?以为我会说得很曲折,必须承认就是运气!

天下武功,唯快不破(2016年10月-2016年11月)

教科书上说,要拥抱变化!实践告诉我们,很多时候,人不是害怕改变,而是害怕被改变,想着主动改变或许就不会那么害怕改变,这需要勇气。

TDD

当需求变成了用户故事,我们的设计开发也变成了”测试驱动开发TDD+持续集成CI“。客观的说,不是每个人都马上适应TDD,更苛刻地说,大部分人无法适应TDD思维。把TDD上升到精神层面,可能挑战的是人的惰性,坚持下来会激发人的激情,做不好就会全军覆没。

作为可以借鉴的经验,我们把TDD先下降到战术层面,把TDD当作带测试案例的需求文档,把TDD当作设计思路的形成过程,那就说TDD对工程师的好处在于可以省略掉需求分析和设计文档(还好没有正式立项,要不会有人追杀我的)。TDD真是敏捷开发的重要一环,没有有效的测试程序,识别技术债也是空想,重构会成为空中楼阁,CI就如同行尸走肉般无用。TDD是敏捷转型技术部分的底线,没有退让的余地。所以,我们先用免文档诱导,再靠行政命令固化,最后晓之以情动之以理,把所以同志带到TDD的道路上。结果,意想不到的是最后转型的人居然是团队里最资深的成员(此处略去称谓,简称“老大哥”)。

还好,逮到了一次机会。老大哥每个周末都辛勤地用CV大法(拷贝+粘贴)应付指标口径的变更(变更来自数据分析师的修正),在我看来,这是用战术上的勤奋掩盖战略上的懒惰。慢慢的,大哥顶不住了,找我增援。我以“2 Piazzas”法则(敏捷重要法则之一,团队不宜太大,两个披萨够吃为宜,当然,我们团队里最壮的哥们经常挑战这个法则,因为他一个人就能吃两Pizza)为由拒绝了。同时,找了和大哥最亲密的小伙伴小锋,一起研究代码,写了几个TDD的范例,同时直接重构出几个函数。当江湖上最后一位大哥拥抱了TDD,通往快速迭代的道路上就再也没有障碍了。

领导特别关注的项目,压力虽然大,也有很多好处,我们争取到了每周上一次线的频繁犯错机会。根据用户故事和技术债,我们拟定了一周上功能一周调性能的策略。敏捷响应业务的速度,让业务人员都惊呆了,11月19日版本封版前一天,试点分行又提出了新的岗位和指标变更需求,结果我们用了半天就完成了,并顺利封版上线,从侧翼支持了江西行新一代三期试点。

时间就这样,一周一周一月一月得过去了,我们的APP在功能上收获了“用户直接订阅指标”、“后台配置指标全集”、“不同指标适应不同维度”、“按用户要求设立警戒线”等等大块功能,为了满足毫秒级响应的用户体验,也慢慢地集成了Redis、Mondrian、Kylin等多种技术,完成了手机APPOLAP的多级缓存,完成了大规模用户推广的准备工作。
天下武功,唯快不破。在这个快速迭代的过程中,我们知道,成功的秘诀在于快。“快”不是偷工减料,而是紧盯目标,只要能达到效果就上,绝不浪费时间犹豫不决,每一次的故事,我们只在乎,APP是不是能更快的支撑业务变更、是不是能运行得更快、是不是能让运维更方便。

无招胜有招

不得不承认,这次敏捷转型有些偶然性,没有多少挣扎(前面其实有三个月试了个大错死不承认),我们就找到了“阿波罗八号”原型。绝境中,传统开发到敏捷开发的转型。若是将来运气没有那么好,咋办?是的,如果开发不能让业务通过运营进行发展,那么开发就是失败的;如果开发次次都只靠拍脑袋想解决方案,那翻船的可能性也会大增。

Matt说:“BigData success is not about implementing one piece of technology (like Hadoop oranything else), but instead requires putting together an assembly line oftechnologies, people andprocesses.”敏捷关键在于“以人为本”。工程师是人,天职是提高效率,商业模式要靠数据科学家,运营要靠业务,要做好两者的桥梁,工程师要两者都略懂一点,或许才能做好数据科学与业务发展的桥梁。现在虽是臆想,未来也许也可尝试!

工程师是人,就会恐惧,会焦虑,要让人做出自己不敢做不敢想的事情,需要梦想和文化的支撑。本文介绍的只是我们团队的转型体验,技术很重要,可是我们没有纠结于特定技术,因为我们用实践体会了敏捷宣言:

个体互动胜于流程和工具
Individualsand interactions over processes and tools

可工作的软件胜于可理解的文档
Workingsoftware over comprehensive document

客户协作胜于合同谈判
Customercollaboration over contract negotiation

响应改变胜于遵从计划
Respondingto change over following a plan

文章来自微信公众号:DBAplus社群

网友评论comments

发表评论

电子邮件地址不会被公开。 必填项已用*标注

暂无评论

Copyright © 2012-2017 YUNWEIPAI.COM - 运维派 - 粤ICP备14090526号-3
扫二维码
扫二维码
返回顶部