e-works数字化企业网  »  文章频道  »  基础信息化  »  大数据

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

2017/7/31    来源:运维派    作者:朱志      
关键字:TB级大数据  大数据  
现在各种大数据会议充满了AI(人工智能)的主题,还好仍有人强调数据敏捷性,要不我今天分享的Data APP敏捷实践话题就落伍了。敏捷诞生也有二十多年了,经历了两次高潮,何时提敏捷都不落伍。
    现在各种大数据会议充满了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%的页面功能,程序能部署上线已经不错了……如果没有变更,或许会好一点。”
 
 数据
 
    参与项目的每个人说的都没有错,可是结果不好,没有人承担责任,一定是整个团队都出了问题。回顾雄心壮志开启移动端开发的初衷,在没有公司资源辅助投入的情况下,我们作为甲方中的乙方,似乎把业务人员的口味调高了;随着项目深入,业务人员对移动端的认知稳步提升,三次大规模的需求变更就是业务人员进步的实证。其实,大家都害怕移动端不能一炮打响!
 
    然而,随着时间的发展,每个人都热情高涨的添砖加瓦,要啥给啥,只有技术人员为进度所迫不断降低对自己的要求(包括范围和质量),缺乏沟通也没有实时的产出物可以验证,而交付和期望的差距已经发展到不可收拾的境地。到了约定交付的时候,发现业务用户的情感在瞬间熄灭,领导层的许诺也随之崩塌,这也是许多瀑布型项目失败的原因。
 

责任编辑:李欢
本文为授权转载文章,任何人未经原授权方同意,不得复制、转载、摘编等任何方式进行使用,e-works不承担由此而产生的任何法律责任! 如有异议请及时告之,以便进行及时处理。联系方式:editor@e-works.net.cn tel:027-87592219/20/21。
e-works
官方微信
掌上
信息化
编辑推荐
新闻推荐
博客推荐
视频推荐