Monthly Archives: June 2013

的确是被黑了,请亲友们注意安全

  上次BLOG提到,怀疑自己被黑了。最近一直在查这件事。

  今天收集到一些信息,请公司里的安全高手帮忙看了看。(上一篇BLOG其实是我做的实验)。确认的确是被黑了。黑客还挺狡猾,在程序里设置了判断,从Cookies发现是我本人在访问这个网站,则一切显示正常,否则就显示乱七八糟骗人的内容。

  我的各种密码也许已经泄漏,昨天发现有人在试验修改我工作帐号的设置。各位亲友如果对从我的网站、邮箱、旺旺、手机发出来的信息有疑惑,请及时和我本人联系。建议大家更换自己常用的重要上网密码。

  WUWU~,这个世界真不安全,我还是回火星吧。

2013阿里大数据暑期学校开始报名了

  自主研发的ODPS是阿里数据交换平台(DXP)的重要组成部分,支撑着阿里金融淘宝指数数据魔方等关键业务。

  2013阿里大数据暑期学校的主题正是ODPS。我们将从ODPS底层的飞天大规模分布式系统讲起,为同学们分享研发ODPS平台的几项关键技术:平台框架和服务化、跨集群调度、Tunnel数据交换服务、BSP图编程模型、分布式SQL引擎、分布式数据分析和数据挖掘算法。授课的主讲人基本上都是ODPS开发团队一线的技术经理,并邀请了清华大学、中国科学院、浙江大学等知名高校的专家。欢迎相关专业的博、硕士研究生和高年级本科同学报名。名额有限,赶快点击http://102.alibaba.com/

  这次课程中,《分布式大规模数据分析和数据挖掘算法》的主讲人是我们算法平台团队的大牛品数(杨旭);而杭州站特有的《海量数据下数据挖掘实战》的主讲人是我们最主要的客户晓风(朱洪波)。强烈推荐!

李朔取蔡州,几何原本,书房,旁观者,介质

  最近经常半夜在书房里翻老妈的旧书。

  昨晚偶尔浏览司马光的李朔取蔡州那一段,描写当然非常精彩。不过如果只看这些,视野很有限。应该再往前翻翻,从唐宪宗任命严缓为招讨使开始看:武元衡被刺杀,韩弘养寇自重,李光颜刚勇奋战,裴度经略全局……

  明朝徐光启翻译欧几里德的《几何原本》,除数学上的贡献。译本语言水平非常高。创造了很多此前汉语中不存在的专业词汇,如:点、线、直线、曲线、平行线、角、直角、锐角、钝角、三角形、四边形。徐光启在译序里这么写:“《几何原本》者,度数之宗,所以穷方圆平直之情,尽规矩准绳之用也。”

  现在大家总是幻想如果明朝朝廷采纳徐光启的上书,大量制造并装备西式火炮,东北前线与满族的战争的结果是否会不同。其实这是制度问题,不是技术和装备问题。即使不用火器,明朝军队的装备和人数也比努尔哈赤的军队好。更早一点,戚继光与倭寇作战时,就已经发现对方的铁炮(由葡萄牙人传入日本的火绳枪)威胁很大。由于后勤质量问题,明朝这边的鸟铳经常炸膛,因此被戚继光放弃。

  在微博上看到的,NIGELLA的书房。以前说过我的梦想是一个大书房

study

  通过豆瓣阅读购买电子书,最近正在看《旁观者》。德鲁克说他曾认真研究过大学开设的课程,发现其中只有两门对培养管理者有用:短篇小说写作和诗歌赏析。书店里管理励志的书堆成山,包括德鲁克自己的那几本经典,对所谓管理者未必有用。效果还真有可能比不上他这本文艺腔的回忆录。第一章,1923年,德鲁克14岁差8天,参加维也纳共和日大游行,独自走在“社会主义青年军”方阵最前面,担任红旗旗手,却在游行中突然脱离队伍回家。他是天才,14岁就能清醒。如果当时德鲁克选择从众,变成一个小纳粹,今天就看不到《卓有成效的管理者》了吧。

  以前BLOG写过,如果电子书替代实体书,我的书房梦想就有点尴尬。说到实体书和电子书,大多数人认为只是阅读体验和个人习惯问题。如果想深入思考介质和内容的关系,建议看看Tinyfool写的这篇《书的历史与未来——从介质、内容和表现形式的相互影响谈起》。王兴有一次说,中国所谓四大发明,三项都与信息技术有关

阿里技术嘉年华要举行了,我们的主题报告和Workshop

  2013阿里技术嘉年华将于7月13-14日在杭州举行。好多牛人带来技术分享。这里面和我工作直接相关的内容有下面两个:

  13日上午,ODPS团队的高级产品经理 水易(汤子楠)会在大数据主题论坛上做一个报告,介绍ODPS的产品设计思路、主要功能和基础技术架构。开放数据处理服务 (Open Data Processing Service, ODPS) 是基于飞天平台构建的离线大数据存储与分析系统,以云计算服务的方式实现海量数据的存储、分享与离线处理,在数据仓库构建、海量数据统计、数据挖掘、数据商业智能等应用领域有着广阔的应用前景。

  14日下午,算法团队的高级专家 品数(杨旭)会在Tech Loft主持一个workshop,讨论分布式数据分析算法。MapReduce模式在很多算法上已无法达到高效,如何扩展模式并使之与MapReduce统一调度?如何高效实现大数据算法? 怎样定义数据结构? 如何保证开发测试的质量? 算法研发如何与业务紧密结合? 希望更多人参与分享和讨论。

  更多报告内容请参考这里,期待与大家交流。

关于建模思路

  大数据的商业模式,目前能看清楚的有两种:互联网小微金融(参考这里)和精准广告投放(参考这里)。这两项业务的建模团队正是分布式算法产品的主要客户。

  尽管拥有相同的数据和平台,金融团队和广告团队的思路却有差异。例如同样使用逻辑回归,金融BI偏向传统统计学,应用银行业经典的“评分卡”建模,强调严谨的假设验证和细致的特征工程;而广告BI倾向于机器学习方式,把上亿行样本的上万甚至上亿列特征一口气扔进建模算法里面去自动迭代训练,更粗暴,更敏捷。

  技术路线常常源于业务需求。在广告营销领域,通过A/B Test获取反馈的成本较低,模型的更新节奏也比较快,业务方也不关心模型内部细节。而金融风险模型直接作用于真金白银,信息循环沉淀的周期又长达数月,因此建模思路偏保守,模型上线之前风险委员会的review很细致,往往得把所涉及到的每一列特征都讲清楚。

  算法平台团队对此感触很深。前一阵,两个BI团队的数据科学家终于凑到一起开会。交锋很有意思,例如把模型当作白盒还是黑盒来用,再如特征工程中的很多人工操作能否用自动化蛮力替代。

  会上我也说了几句。必须重新审视建模流程的各个环节,也许一些招数其实源于小数据时代计算资源有限导致的妥协。今天我们有了上万节点处理上P数据能力的平台,建模必然面临创新。