TB级大数据应用搭建实践.docx

TB级大数据应用搭建实践.docx

《TB级大数据应用搭建实践.docx》由会员分享，可在线阅读，更多相关《TB级大数据应用搭建实践.docx（10页珍藏版）》请在冰豆网上搜索。

TB级大数据应用搭建实践

TB级大数据应用搭建实践

本文介绍的BigDataAPP基本目标是支撑100,000+用户、120亿条数据、TB级存储、秒级响应。

比起性能，更受用户欢迎的功能在于支持不同机构或业务条线发布数据，支持不同岗位不同角色不同用户按需订阅，而这些丝毫不用技术人员介入。

如上逻辑架构图，Oracle、GreenPlum、Teradata不同系列的数据库产品（不同的计算区）计算出来的各种指标，通过ETL技术把各种数据源源不断地汇入公共访问区，接着通过Redis、HBase和Kylin等时下流行的开源技术实现两级缓存以应对海量的移动用数访问。

移动端采用了HTML5技术屏蔽设备操作系统差异，同时VUE.js和ECharts等技术实现了数据展现和自动推送。

通过参数化设计将业务运营从开发中分离出来，让工程师更加关注如何支持好业务数据和用户自然增长。

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

（注：

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

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

1962年9月12日，肯尼迪发表了著名的月球演说之后（https:

//er.jsc.nasa.gov/seh/ricetalk.htm），NASA硬着头皮开始登月，阿波罗1号竟然在地面就爆炸了，经历多次失败，直到阿波罗8号首次完成了载人环行月球一周并返回地球之后，NASA才确信人类登上月球只是时间问题。

很多人知道阿波罗11号登月成功，却不知道在肯尼迪航天中心纪念的是阿波罗8号，因为这个阿波罗8号是工程师所怀念的成功原型。

是的，这几个简单的界面就是DataAPP的“阿波罗8号”，接下来重点介绍如何通过敏捷开发打造出这个“阿波罗8号”。

知易行难（2016年5月-2016年8月）

把时间拨回到2016年5月-8月这段时间，在如此体量而又优越的企业平台，引入技术不是一蹴而就的事情，要完成一个从没实践过的应用，通常分三步走：

第一步，按图索骥。

大数据这条路上，一定要看每年发布的大数据蓝图（《BigDataLandScape》由MattTurck首先于2012年提出，通过这张图的更新，可以找到业界的技术投资潮流）。

这张图的使用诀窍，在于要透过复杂的表象按照大数据技术的抽象分类（可参考）来寻找可能的技术方向。

这个项目刚开始的时候，我们想法很简单，采用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+持续集成CI“。

客观的说，不是每个人都马上适应TDD，更苛刻地说，大部分人无法适应TDD思维。

把TDD上升到精神层面，可能挑战的是人的惰性，坚持下来会激发人的激情，做不好就会全军覆没。

作为可以借鉴的经验，我们把TDD先下降到战术层面，把TDD当作带测试案例的需求文档，把TDD当作设计思路的形成过程，那就说TDD对工程师的好处在于可以省略掉需求分析和设计文档（还好没有正式立项，要不会有人追杀我的）。

TDD真是敏捷开发的重要一环，没有有效的测试程序，识别技术债也是空想，重构会成为空中楼阁，CI就如同行尸走肉般无用。

TDD是敏捷转型技术部分的底线，没有退让的余地。

所以，我们先用免文档诱导，再靠行政命令固化，最后晓之以情动之以理，把所以同志带到TDD的道路上。

结果，意想不到的是最后转型的人居然是团队里最资深的成员（此处略去称谓，简称“老大哥”）。

还好，逮到了一次机会。

老大哥每个周末都辛勤地用CV大法（拷贝+粘贴）应付指标口径的变更（变更来自数据分析师的修正），在我看来，这是用战术上的勤奋掩盖战略上的懒惰。

慢慢的，大哥顶不住了，找我增援。

我以“2Piazzas”法则（敏捷重要法则之一，团队不宜太大，两个披萨够吃为宜，当然，我们团队里最壮的哥们经常挑战这个法则，因为他一个人就能吃两Pizza）为由拒绝了。

同时，找了和大哥最亲密的小伙伴小锋，一起研究代码，写了几个TDD的范例，同时直接重构出几个函数。

当江湖上最后一位大哥拥抱了TDD，通往快速迭代的道路上就再也没有障碍了。

领导特别关注的项目，压力虽然大，也有很多好处，我们争取到了每周上一次线的频繁犯错机会。

根据用户故事和技术债，我们拟定了一周上功能一周调性能的策略。

敏捷响应业务的速度，让业务人员都惊呆了，11月19日版本封版前一天，试点分行又提出了新的岗位和指标变更需求，结果我们用了半天就完成了，并顺利封版上线，从侧翼支持了江西行新一代三期试点。

时间就这样，一周一周一月一月得过去了，我们的APP在功能上收获了“用户直接订阅指标”、“后台配置指标全集”、“不同指标适应不同维度”、“按用户要求设立警戒线”等等大块功能，为了满足毫秒级响应的用户体验，也慢慢地集成了Redis、Mondrian、Kylin等多种技术，完成了手机APPOLAP的多级缓存，完成了大规模用户推广的准备工作。

天下武功，唯快不破。

在这个快速迭代的过程中，我们知道，成功的秘诀在于快。

“快”不是偷工减料，而是紧盯目标，只要能达到效果就上，绝不浪费时间犹豫不决，每一次的故事，我们只在乎，APP是不是能更快的支撑业务变更、是不是能运行得更快、是不是能让运维更方便。

无招胜有招

不得不承认，这次敏捷转型有些偶然性，没有多少挣扎（前面其实有三个月试了个大错死不承认），我们就找到了“阿波罗八号”原型。

绝境中，传统开发到敏捷开发的转型。

若是将来运气没有那么好，咋办？

是的，如果开发不能让业务通过运营进行发展，那么开发就是失败的；如果开发次次都只靠拍脑袋想解决方案，那翻船的可能性也会大增。

Matt说：

“BigDatasuccessisnotaboutimplementingonepieceoftechnology（likeHadooporanythingelse）,butinsteadrequiresputtingtogetheranassemblylineoftechnologies,peopleandprocesses.”敏捷关键在于“以人为本”。

工程师是人，天职是提高效率，商业模式要靠数据科学家，运营要靠业务，要做好两者的桥梁，工程师要两者都略懂一点，或许才能做好数据科学与业务发展的桥梁。

现在虽是臆想，未来也许也可尝试！