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

TB级大数据应用搭建实践本文介绍的BigData APP基本目标是支撑100,000+用户、120亿条数据、TB级存储、秒级响应。比起性能，更受用户欢迎的功能在于支持不同机构或业务条线发布数据，支持不同岗位不同角色不同用户按需订阅，而这些丝毫不用技术人员介入。如上逻辑架构图，Oracle、GreenPlum、Teradata不同系列的数据库产品（不同的计算区）计算出来的各种指标，通过ETL技术把各种数据源源不断地汇入公共访问区，接着通过Redis、HBase和Kylin等时下流行的开源技术实现两级缓存以应对海量的移动用数访问。移动端采用了HTML5技术屏蔽设备操作系统差异，同时VUE.js和ECharts等技术实现了数据展现和自动推送。通过参数化设计将业务运营从开发中分离出来，让工程师更加关注如何支持好业务数据和用户自然增长。这种自我生长的APP模式，就像一颗树苗，依靠树根从土壤（GreenPlum和Teradata构成的计算区）源源不断地吸收养分，再通过树干（公共访问区）以及树枝（各级Cache）生出树叶（用户在移动APP端用数），通过这种架构的孕育，树苗长成参天大树不过是时间问题。（注：树型架构，出处参见高焕堂 Annpping Kao所著《思考软件，创新设计——A段架构师的思考技术》第5页“1.4软件的复杂时本质性的-架构师从复杂设计出简单”）这个APP从什么时候开始蕴藏着如此巨大的能量？1962年9月12日，肯尼迪发表了著名的月球演说之后（/seh/ricetalk.htm），NASA硬着头皮开始登月，阿波罗1号竟然在地面就爆炸了，经历多次失败，直到阿波罗8号首次完成了载人环行月球一周并返回地球之后，NASA才确信人类登上月球只是时间问题。很多人知道阿波罗11号登月成功，却不知道在肯尼迪航天中心纪念的是阿波罗8号，因为这个阿波罗8号是工程师所怀念的成功原型。是的，这几个简单的界面就是Data APP的“阿波罗8号”，接下来重点介绍如何通过敏捷开发打造出这个“阿波罗8号”。知易行难（2016年5月-2016年8月）把时间拨回到2016年5月-8月这段时间，在如此体量而又优越的企业平台，引入技术不是一蹴而就的事情，要完成一个从没实践过的应用，通常分三步走：第一步，按图索骥。大数据这条路上，一定要看每年发布的大数据蓝图（《Big Data LandScape》由Matt Turck首先于2012年提出，通过这张图的更新，可以找到业界的技术投资潮流）。这张图的使用诀窍，在于要透过复杂的表象按照大数据技术的抽象分类（可参考）来寻找可能的技术方向。这个项目刚开始的时候，我们想法很简单，采用H5技术屏蔽IOS和Android，用ECharts实现移动端数据可视化，沿用数据平台公共访问区已有的GreenPlum。第二步，按部就班。一项技术要成为企业的选择，必须经历一系列的测试，从功能到非功能，根据预先设定的指标进行匹配，找到最合适的。入选企业级技术产品目录后，再逐步推广，产生规模效应。选好的技术不涉及商业产品，时间紧任务重，赶快出活才是硬道理。第三步，用户至上。在应用架构、数据架构和技术平台几个层级上，解决了共享问题之后，要按照用户体验组合这些组件服务，在保证后台功能相对稳定的同时，积极拥抱用户在前端需求的快速变化。用户体验组（移动端用数需求负责人），多次走访基层网点和分行部门及高层的管理人员，按照不同岗位提炼出了典型应用场景（晨会、周会、经营分析会），形成了100多页需求。逻辑推理加稳步执行，这顿想象中共襄盛举的数据自助餐应该水到渠成。经过三个月的努力，按计划到了初始版本交付的时间。原计划要交付分行三类管理岗位和一个总行部门的功能，结果只交付了基层网点负责人的部分页面。就拿首页来说，在测试环境还好，上了生产之后，运行了一周惨不忍睹，页面要跑10来秒，数据对不上、缺数也是常有的事。更悲哀的是，付出艰辛努力经历了试运行失败的同志们，还要被“不就是推几个数到手机上这么简单的事情”的质疑所摧残。一切印证了一句古话，大道至简，知易行难！置之死地而后生（2016年9月）按照原有需求交付软件，已经不现实了。要解决问题，得先看看到底发生了什么？负责需求的业务人员说：“我们设计了20几个场景，需求写了几百页，我们从来没有这么认真对待过需求……”负责指导实施的架构师说：“我们选择了最先进最流行的技术，实现了H5典型页面和数据服务，数据慢主要是因为……（反正是别人，不是自己，列了一些）”负责实施任劳任怨一脸无辜地程序员说：“手机页面需求大版本变更了3次，我们100多个页面足足做了3次，我们没日没夜加班也就实现了总量60%的页面功能，程序能部署上线已经不错了……如果没有变更，或许会好一点。”参与项目的每个人说的都没有错，可是结果不好，没有人承担责任，一定是