无线客户端实战

今天是2013阿里技术嘉年华第一天,现场的火热程度,就像这头伏第一天一样,被一股热浪包围着。

在二楼的TechShow,我们团队的客户端数据分析产品“无线数读”占据了最热的角落,就在一排大机架的后面,正对着散热口。到会场的时候发现展台人气超高,心里暗自得意呢,还以为有这么多数据的粉丝。其实应该是“淘公仔”面子大,今天关注“数据说话”的朋友中,冲着淘公仔来的不少吧。

无线专场最后一场,我分享了一点无线淘宝的数据和做客户端数据遇到的经验。这一年多在无线数据上碰到很多坑,其实到现在也没有填完,现场分享的只是冰山一角,如果大家有兴趣,以后可以慢慢再聊。如果对无线数据感兴趣,希望在无线数据的分析和挖掘方面一展身手,我相信把简历给我是最正确的选择,没有之一,哈哈。

今天给大家分享了一个数据,在无线淘宝的用户中,有45.96%用的是苹果设备。初看这个数据很高兴,因为iOS用户的人均购买金额一直都大于Android,愿意花钱的人占比多一些当然没什么不好。但从另外一个角度来看,Android现在的设备出货量远大于iOS,也就是用Android手机的人,还有很多没有成为移动电子商务的用户。去年Android一直是男性用户居多,人均购买金额低可以理解。今年Android女性用户已经明显开始发力,Android用户的增长如果不能跟上设备出货量的增长,是个很危险的事情。在电商领域,得女性用户者得天下。男人负责赚钱养家,女人负责貌美如花嘛。

这里再附送一份我们最近研究的数据,是根据一些第三方的数据做的模型,计算得到的上半年中国的设备出货量(单位:万台,包括水货)

Android Q1:6365
Android Q2: 7508
iPhone Q1:1033
iPhone Q2:1100
iPad Q1:488
iPad Q2:390

数据是经过模型修正的,可能有一些出入,不知道大家觉得准确度如何,或者你有更准确的数据,欢迎分享给我。

刚刚微博上被人at,无节操的转发一下:

@不知一不知二

#ADC2013#阿里技术嘉年华,坚持到> 了最后一场,作为一个没有目的闲逛的闲散人员,我听了好多场,完整听完的就两场……总体感觉:程序员的表达能力还有待提高。不过也有讲得好的@tinyfool 巨能扯,很轻松的就吸引了观众的注意力,所有场次中@NinGoo 讲得最棒,条理清晰,内容充实,而且PPT超漂亮

昨天我们无线数读的PD MM瞄了一眼我正在修改的keynote,说,“枫哥,你做的PPT一点都不像技术屌丝”,我这算是被开除技术屌丝籍了么。。。

===== 一零二四的分割线 =====
最近刚开了个微信公众帐号【数据说话】,这是2013.7.13在上面推送的一篇文章。

如果有兴趣,欢迎关注,我会分享一些互联网和移动互联网方面的数据和观点。有几种方式可以都可以进行关注:
1. 可以用任何一款有扫码功能的App(微信,火眼,或者淘宝客户端等)扫描本站右上角的二维码
2. 微信->朋友们->添加朋友->搜号码,输入微信号【DataTalk】搜索
3. 微信->朋友们->添加朋友->查找微信公众帐号,输入【数据说话】或者【DataTalk】搜索

注:演讲的PPT已经分享在微盘:http://vdisk.weibo.com/s/Kjk2F/1374039026

大数据下的工行

2013.6.23,工行发生重大系统故障,已经有一阵子了。今天想起写这个话题,完全是因为昨天看到了一条现在已经被和谐的微博,当时随手收藏却忘记了粉一下Po主,和谐之后已经死无对证,找不到“传谣”的人了,于是标题的最后形容某群体组织的四个字的专有名词变成了“工行”,不过也好,原来想的标题估计是跨不过深壑的。

先来还原一下现场。2013.6.21,@中国工商银行电子银行 微博发布维护公告:

尊敬的客户:为了能够向您提供更加优质的服务,我行将于2013年6月23日0:10—1:40进行系统优化。期间,我行网上银行、电话银行、手机银行、短信银行、银企互联等相关系统将暂停服务。由此给您带来不便,敬请谅解。

从公告来看,这次维护涉及的面非常广,而时间只有90分钟。一般来说这种计划内的维护都会包括实际操作时间和系统验证的时间,金融类系统的验证工作一般也会比较耗时。因此推测前期准备工作应该还是比较充分。但凌晨2点到4点左右是业务最低峰时间(按照网购业务的低峰期推测),问题可能就出在这里,由于缺乏实际业务压力,验证工作可能只是做了功能性测试。到早上9点,业务压力上来以后,问题陆续出现,根据上述微博在当天12:50发布的消息推测,系统在10点半左右彻底崩溃:

6月23日上午10点38分至11点23分,中国工商银行部分地区因计算机系统升级原因造成柜面和电子渠道业务办理缓慢。目前系统已恢复,各项业务业务正常办理。中国工商银行对因此给客户带来的不便深表歉意。

大约11:23,系统故障排除,业务陆续恢复。这次故障同时影响柜台、ATM、网银和电话银行等各个业务渠道,问题应该是出在交易系统的数据库,和当天凌晨的升级肯定有因果关系。今天网上有消息称工行发布了内部通报:

“6月23日上午,数据中心(上海)监控发现主机CPU利用率升高,经分析判断与6月23日凌晨实施的主机DB2数据库软件升级版本有关(从V9升级到V10),在紧急回退升级系统软件版本后系统运行恢复正常。”

并且关于紧急回退版本的具体原因被归结为:

由于IBM提供的主机DB2V10版本内存清理机制存在缺陷引发。

首先补充一点技术背景知识,我对DB2也不是很熟悉,但是根据多年的Oracle/MySQL DBA经验,升级数据库有两种方案,一种是将新版本安装到新位置,用新版本数据库软件启动实例,执行升级脚本升级数据库的元数据,这样因为旧版本的软件还在,如果升级出现问题,还可以使用旧版本重新启动实例并执行降级脚本;另外一种是直接覆盖升级旧版本的数据库到新版本,但这样遇到问题就需要重新安装旧版本数据库软件。很明显,所有的数据库升级操作都应该选择第一种方案,而这次工商银行的升级也应该是做出了正确的选择。

好,现在假设我们是这次升级的负责人,凌晨顺利升级完成,检测所有功能正常,回家倒头睡觉。早上九点陆续收到告警,心里一惊,立即登录系统发现系统可用内存被快速消耗,随着业务压力越来越大,数据库链连接不断上涨,内存用尽,大量数据被交换到swap导致I/O响应越来越慢,最终数据库主机挂死,异常宕机。这时候又面临两种选择:一种是重新启动主机,回退到旧版本数据库,这需要大约30分钟到60分钟的重启和执行降级脚本的时间,但可以保证数据的一致性;另外一种选择,先不管已经挂死的主机,立即切换到灾备中心的备库(这里还需要假设备库的数据库版本没有升级,否则在业务压力下问题重现的几率非常高,所以也提醒我们,在制定数据库升级的方案时,主备库最好能错开时间执行),这样只需要将备库切换成主库的时间,一般几分钟内就能恢复业务,但是由于原来的主库宕机时,还有部分数据在内存和磁盘缓存的日志文件中可能没有同步到备库,可能会导致部分最新的交易数据受损。

在这种情况下,你会如何选择?尤其是你心里还很清楚,灾备中心平时很少做切换演习工作,你根本不敢保证切换到备库就能100%将业务恢复正常,还要承担部分交易数据不一致的后果。宕机一个小时会成为新闻头条,但要是交易数据不一致导致用户或者银行的money受损,那自己的头可能被老板敲成一条。。。

所以,理性的人一定会选择重启故障主机,使用旧版本数据库软件启动实例,执行降级脚本,恢复业务。这个过程由于紧张,加上应用软件可能还有些依赖要依次启动,业务流量需要限流慢慢放入系统,以便系统充分预热,因此恢复的时间会比计划内的维护时间要长很多,最终到11:23分,数据库终于有新的连接进来,各业务方陆续反馈恢复正常,你终于可以长吁一口气,揉一下眼睛,敲一下脑袋,开始思考怎么写故障报告吧。

所以,不用惊讶为什么花费了大量成本建设的灾备中心在这种情况下毫无用处,大部分灾备中心就是这么设计的。在对事务一致性要求非常严格的场景下,牺牲一定的业务连续性时间来获取一致性,这是符合CPA定理的合理选择。2008年,淘宝面临过同样的情况,当时机房异常停电,运营商一声不吭的躲在角落里抢修。终于在UPS电源支撑到最后一分钟时,运营商才打电话通知我们,电话还没说完,所有数据库就直接嗝屁了。当时的淘宝,虽然也有了备用机房,但两边还没有完全做到1:1对等,灾备演习也还没有成为常态(计划内切换已经是常态),加上在机房和运营商抢修人员沟通时,他们拍胸脯保证一个小时内能修好。于是我也就在机房里忐忑的度过了一个小时,中间有几次想下定决心做异常切换启用备库,最后在心理底线前电源恢复,赶紧启动小型机,启动数据库,还好都能正常启动,一场忙乱,现在想起来还历历如新。

这几年,淘宝的系统架构在发展的过程中,应该说充分的考虑了2008年这种惊险一小时的整机房断电的场景,从web到应用到数据库,都做了比较充分的容灾架构,并且从2010年开始实行严格的定期灾备切换演习。现在已经可以做到高峰期暴力演习,数据库和应用流量都能够做到自动切换,而用户几乎无感知。2008年的那次断电,也可以说功不可没。

故障不可怕,可怕的是对故障视而不见,推脱责任,找替罪羊。至于工行的这次故障,据说内部通报的结论是这样的:

同时,工行总行信息科技部将该事件直接原因归为IBM公司提供的软件产品存在缺陷,并称这点“经IBM公司正式确认”。

所以,我们都懂的。

===== 一零二四的分割线 =====

最近刚开了个微信公众帐号【数据说话】,这是在上面推送的一篇文章,自从有了微博以后慢慢的很少写稍微长一点的东西了,准备用微信公众号督促一下。

如果有兴趣,欢迎关注,我会分享一些互联网和移动互联网方面的数据和观点。有几种方式可以都可以进行关注:
1. 可以用任何一款有扫码功能的App(微信,火眼,或者淘宝客户端等)扫描本站右上角的二维码
2. 微信->朋友们->添加朋友->搜号码,输入微信号【DataTalk】搜索
3. 微信->朋友们->添加朋友->查找微信公众帐号,输入【数据说话】或者【DataTalk】搜索

在Ubuntu上编译安装R

R is a free software environment for statistical computing and graphic.

在Ubuntu上编译安装时有几个小问题,记录在此备查:

1.需要fortran compiler
下载完源码,解压后直接执行

./configure –prefix=/xxx –enable-R-shlib

报错:configure: error: No F77 compiler found
这是因为Ubuntu现在默认没有fortran编译器,需要手工装一个,比如gfortran:

sudo apt-get install gfortran

当然,编译还需要gcc等工具

sudo apt-get install build-essential

2.需要readline
如果系统中没有readline,继续configure还是报错:

configure: error: –with-readline=yes (default) and headers/libs are not available

两个选择,要么使用–with-readline=no去掉对readline的依赖,要么装一个:

sudo apt-get install readline-devel

3. 需要X11的headers/libs
继续configure,继续报错:

configure: error: –with-x=yes (default) and X11 headers/libs are no t available

好吧,缺的东西还真不少,还是两个选择,要么–with-x=no,要么把缺失的依赖补上:

sudo apt-get install libxt-dev

搞定, ./configure && make && make install,收工

$ ./R

R version 2.15.2 (2012-10-26) — “Trick or Treat”
Copyright (C) 2012 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
Platform: x86_64-unknown-linux-gnu (64-bit)

R是自由软件,不带任何担保。
在某些条件下你可以将其自由散布。
用’license()’或’licence()’来看散布的详细条件。

R是个合作计划,有许多人为之做出了贡献.
用’contributors()’来看合作者的详细情况
用’citation()’会告诉你如何在出版物中正确地引用R或R程序包。

用’demo()’来看一些示范程序,用’help()’来阅读在线帮助文件,或
用’help.start()’通过HTML浏览器来看帮助文件。
用’q()’退出R.

偷懒的话,也可以直接安装编译好的包了,版本可能不是最新而已:

sudo apt-get install r-base

参考:http://rwiki.sciviews.org/doku.php?id=getting-started:installation:debian

无觅相关文章插件,快速提升流量