Category Archives: 0和1

谈谈ODPS商业化(三):阿里金融的业务

  这篇BLOG是ODPS商业化一系列文章之一,更多请点击这里……

  阿里金融是ODPS第一个用户,业务发展很快,备受关注。网上能找到很多报道,例如以前一篇BLOG引用过《 一笔B2B贷款的旅行》。近期又披露了A-GDS系统和水文模型,大家可以自己搜索(作为参与者,终于能把这些曾经保密的词写在公开渠道,真爽)。通过这些已经能大体了解到阿里金融如何利用海量数据挖掘信息,并据此确定信用风险和额度并发放贷款。所以这篇BLOG会短一些。

  阿里金融团队里,程序员和数据分析师占绝大多数。这些同学都在ODPS上忙什么?

  金融的核心是对风险进行量化评估。举个例子,发信用卡给某人,必须先拿到对方的信息,根据各种指标进行打分,估算出这个人赖账的概率,评估期望收益减去成本之后的盈利空间,并确定授信额度。通过特征计算信用额度是一门专业的金融建模技术,称为“信用评分卡”。大家可以到豆瓣上搜一些经典教科书。“信用评分卡”一般是由一系列的特征选择、回归统计和评价算法组成。

  传统金融行业能获得一个人的信息是有限的,几页纸的表格资料就填写好了:生日、性别、教育、婚姻、城市、单位、职称、收入、财产、负债、健康……所以传统的信用评分卡模型,输入训练集的特征矩阵也就上百列。同样的方法拿到互联网企业来用,嗯,我们能收集你这个人的一切数据:用iPhone还是Android,接收包裹的地址是高档小区还是地下室,在天猫旗舰店买首饰和包包有多腐败……如果你是淘宝或B2B卖家,支付宝里赚到的每一笔现金流都可以反映你的还债能力,甚至会测评你对假设情景的掩饰和撒谎程度。于是信用评分卡模型就必须能处理好几百万列的特征矩阵。而且,疯狂的数据科学家们想到,每月、每周甚至每天的授信额度都应该动态调整,就像江河里的水位一样随季节涨落,例如双11之前,根据往年的数据预测,模型会自动给电商卖家逐步调高额度,而春节之前又降到最低(这也是“水文”模型名字的来历)。

  业务需求如此,海量数据必须要存,要过滤,要计算,要建模,包括调度和监控、授权和审计、数据质量控制、元数据管理等重要问题都要有解决方案。于是神说,要有ODPS,要有水文模型,要有A-GDS。

  阿里金融的生产流程都在晚上跑,是典型的数仓场景:把上游数据定时拖进来,ETL清洗整理后进入数据仓库,然后针对上层业务提供垂直的数据集市。每天离线作业完成之后,数据就会被灌入OTS和RDS这类在线服务,为日常业务提供支持。而在白天,分析师们使用SQL进行数据探查,写程序或调用统计机器学习的工具包进行数据挖掘和建模,并把开发测试好的模型发布到线上生产。

  阿里金融在ODPS上每天处理30PB数据,800亿个信息项,运算100多个数据模型。ODPS上的信用评分卡模型(以逻辑回归为核心的十几个算法组成的建模流程)一般会跑上百万维特征,上亿行样本的训练集。有了强大平台的支持,阿里金融就可以给没有资产可抵押的小微企业发放贷款,每一笔贷款成本是传统银行的1/1000,且坏账率非常低。

  写到结尾,我终于可以像购物节目里面的亢奋主持人一样说点煽情的:“ODPS可以120%的满足你的所有梦想,现在打开电脑,登陆www.aliyun.com,展开你的神奇大数据之旅吧!”

  顺便提一下,其他金融类业务也都在用ODPS了。余额宝前两天在微博上发了一组好玩的数据统计,“广东、山东、河南男人们的私房钱最多”。

  这篇BLOG是ODPS商业化一系列文章之一,更多请点击这里……

谈谈ODPS商业化(二):ODPS的计量计费模型

  这篇BLOG是ODPS商业化一系列文章之一,更多请点击这里……

  ODPS正式商业化以后,微博上议论比较多的是计量计费模型。刚好这件事我全程参与,仔细写写。ODPS的计量计费规则和价格请以阿里云官方网站上的说明和数字为准。这里的内容只反映当前状态,不能保证实时更新。

  ODPS收费以项目(Project)为单位,对存储、计算和数据下载三个方面分别计费。存储和数据下载的收费形式与其他云产品很类似。而计算这边,目前ODPS仅开放了SQL任务,计费公式为:一次SQL计算费用 = 计算输入数据量 * SQL复杂度 * SQL价格。具体而言:
  1.计算输入数据量:指一个SQL语句实际扫描的数据量,大部分的SQL语句有分区过滤和列裁剪,所以一般情况下这个值会远小于源表数据大小。
  2.SQL复杂度:先统计SQL语句中的关键字,再折算为SQL复杂度
  SQL关键字个数 = Join个数 + Group By个数 + Order By个数 + Distinct个数 + 窗口函数个数 + analyze个数 + max( insert into个数-1, 1)
  meter
  例如,用户输入的SQL语句是:INSERT INTO TABLE out1 SELECT * FROM shop a JOIN sale_detail b ON a.shop_name = b.shop_name;则其SQL关键字个数是2,而SQL复杂度是1。
  再例如,用户输入的SQL语句是:SELECT DISTINCT total1 FROM (SELECT id1, COUNT(f1) AS total1 FROM in1 GROUP BY id1) ORDER BY total1 DESC LIMIT 100; 则其SQL关键字个数是4,而SQL复杂度是1.5。

  对于上面这个模型,大家常常提出各种问题:为什么只考虑数据量,而不引入CPU、内存、网络通信等直观的技术指标?进一步,为什么不引入计算时间,使用像“CPU*小时”或“内存*小时”这样的计量单位?为什么引入SQL复杂度这样一个稍微麻烦的概念?模型里包含的关键字和公式里的权重是依据什么标准确定的?从一开始,ODPS策略团队的数据分析师就在这些拷问中不断纠结和探索。

  由于ODPS在阿里内部已经大规模投入使用,每天生产上跑着几十个BU的上万个作业,吞吐上百P的数据。因此分析师先拿到日志,各种清洗,各种图表,各种统计探查,各种回归和分类,获得了很多好玩的发现。由此产生的结论是源于严谨的数据分析和产品逻辑,并通过各方面很多审核。

  下面就来说说建模的过程。由于保密原因很多具体细节不能公开分享,但总体思路也许值得大家看一看。

  首先,要明确什么是好的计量计费模型?计量计费模型是产品特征的重要组成部分,需要遵循的的几个原则:
  1.基于统计,简单,可解释:不拍脑袋YY,模型的逻辑源于统计事实;在可行范围内尽量简化;公式的输入参数都应该是用户可见的条件;
  2.可预期,可重复:在跑计算作业之前,用户能根据输入和环境配置算出这次计算底能花多少钱;完全同样的作业重复跑价格不变;
  3.正引导性:用户采用符合“最佳实践”的操作方式不会受到惩罚,最好受到奖励。
  关于以上这些计量计费原则,举一些类比的例子。
  例子一:手机话费的计量,两个人面对面用手机打电话,与一个在城南一个在城北打电话,实际成本肯定不一样,但是如果电信运营商直接按照通信链路经过了几个路由器,几次转发来计费,用户就要晕倒了。所以真实的计费就采用相对粗略的、阶梯的、区域的划分。因为这符合前文提到的3条建模原则。
  例子二:伊拉克战争中,由于基础设施匮乏,电力局收电费,不是按照电表算,而是到用户家里数灯泡和电器的个数,一个灯泡多少钱,一个空调多少钱。这个计费策略当然很粗略,但是它在这个特定场景下是行之有效的。仔细看看,你会发现它同样符合上面的3条建模原则。

  接下来,要考虑怎么衡量一个计算作业的成本?
  很常见的想法是:把一次计算占用的进程、内存,以及中间IO交换的数字都拿出来,分摊对应的硬件成本,也就是CPU、内存、网络设备和磁盘。
  这个思路是错的,因为实际运行的作业占用各种资源肯定不均衡,总有瓶颈。集群的计算节点是个有机整体,部件不能拆开单用,如果某瓶颈环节100%占满了(例如磁盘和网络IO能力),即使其他硬件空闲(例如CPU),也不可能拿去给其他作业使用了。
  所以正确做法应该是:先统计到底哪项功能指标是瓶颈,平均闲置率最低,然后以该指标直接换算整个节点全部成本,其他指标都可以忽略。当然,不同的计算作业瓶颈不一样,成本分摊的方式也会不一样,例如Mapreduce类作业一般是IO密集型的,磁盘和网络IO交换是瓶颈;而MPI类的算法一般是CPU密集型,CPU和内存是瓶颈。

  有了上面两项思考逻辑做为基础,回过头来,我们看看上文用户提到的问题。

  SQL计算的计量模型为什么引入输入数据量作为参数?
  很明显,因为SQL以及它背后的Mapreduce计算是典型的IO密集型运算。而且“输入数据量”符合上文计量计费原则1和原则2,用户可以自己查看、控制和预估。
  这样还有个好处,就是让用户时刻注意语句的写法。因为这里的“输入数据量”是指实际扫描的数据量,如果SQL语句有分区过滤和列裁剪,费用就会远小于源表数据大小:
  a) 列裁剪:例如用户SQL是select f1,f2,f3 from t1; 只计算t1表中f1,f2,f3三列的数据量,其他列不会参与计费。
  b) 分区过滤:例如SQL语句中含有where ds>”20130101”,ds是分区列,则计费的数据量只会包括实际读取的分区,不会包括其他分区的数据。
  有了这个游戏规则,精明的用户一定会尽量用select f1, f2, f3 from…替代select * from…,能用分区裁剪就尽量避免全局扫描。而这正符合数据仓库开发的最佳实践。很多成熟的数仓团队已经把它作为生产纪律强制执行。比如“不准使用select * from …”这一条,如果上游表追加了新的一列(这在数仓生产中很常见),使用select *的SQL作业往往运行失败。因此,我们的模型又符合了前文建模原则3,鼓励最佳实践,平台和用户都会因此获得好处。
  一个有趣的现象是,当我们用这个计量计费模型试算阿里内部不同团队的作业时,也发现了分化:有一些BU,例如阿里金融,拥有很多资深的数仓专家(这些家伙甚至能用SQL实现一个跳棋程序),这种团队的计算花费汇总下来,往往接近甚至低于平台的成本曲线,说明其主力生产SQL经过了精心优化;然而也有一些BU的团队,显然刚开始接触大数据分析业务,把ODPS当MYSQL用,于是产生的计算费用远远高于平台耗费的成本。我们可以推测,对外的场景下也会有类似的事发生,而且随着时间推移,用户行为会整体向更经济的方向移动。这也是平台团队想要看到的,因为我们可以腾出更多资源给新用户和新业务。

  为什么不引入CPU、内存、网络通信等更直观的技术指标?为什么不引入计算时间,使用像“CPU*小时”或“内存*小时”这样的计量单位?
  的确传统的超算中心是这么计费的。我们认为做错了。因为这样做违反了上文计量计费建模原则1和原则2。
  运行一个SQL作业占用多少CPU、内存、网络通信,完全是由平台方的具体技术实现决定的。这些参数其实和用户无关,用户也无法控制,无法预测。平台定义某条SQL很贵,用户也没办法跑来看代码,挑战说ODPS不应该用这么多内存。
  另外,参考前面说的,其实不需要那么好多个指标,只需要关注一两个关键的瓶颈指标。
  进一步,对于ODPS这样的离线计算场景而言,不可能保证每次运算的时间精确一致,更无法预测。如果以运行时间为依据收费,有可能第一次运算用了10分钟,第二次由于调度原因或者发生了failover,用了12分钟。如果完全相同的计算,今天收1块,明天收1.2块,用户就疯掉了。
  反过来说,采用这种计量计费模型,也会让平台技术团队丧失持续优化系统的动力。

  为什么引入SQL复杂度?模型包括的关键字和公式里的权重是依据什么标准确定的?
  由于ODPS支持强大的SQL语法。实际运行中除了显式输入输出,中间阶段还会进行多次临时文件磁盘交换(专业术语一般称为Shuffle)。例如:可以在一条语句里,join十几个表,套上七八个子查询,再加上各种全局分组和排序……这些操作都会导致IO的明显增多。问题是直接采用中间IO量或者Shuffle次数计费,又违反了上文的计量计费原则1,于是我们必须寻找替代方案。
  幸好能造成Shuffle的SQL关键词操作只有7个:Insert Into、Join、Group By、Order By、Distinct、 窗口函数和analyze。因此我们尝试用关键字个数来拟合中间IO,获得了不错的效果。公式里的权重值都是依据阿里内部实际生产的日志回归出来的,是科学和严谨的。

  说到这里。用户可以看看Google BigQuery是怎么收费的。他们甚至在官网上贴了一篇文字,描述其计量计费模型的“设计哲学”。Google BigQuery与ODPS商业化的进程一先一后,大家彼此完全独立思考,得出的方法论和最终模型却殊途同归,这实在是一件很好玩的事。至于Google BigQuery公式里不包括SQL复杂度,原因也很简单:他们的SQL功能比ODPS SQL弱很多,例如根本就不支持两个大表的Join。由于这个原因,所以其SQL基本就对应于ODPS SQL中,复杂度为1的那个子集。

  和ODPS类似的公有云产品还有AWS EMR。不过EMR本质上是租用虚拟机然后在上面搭hadoop,不是多租户的,也就是多个用户无法分享单节点上的计算和存储。因此大家的收费模型思路不同,针对不同的场景各有优劣。我很想看看接下来市场的反馈。

  当然ODPS还有很多需要做的,例如接下来会推出计费计算器:输入SQL,返回需要花多少钱。再例如会提供更多打包计费的方式,例如包年包月,以简化用户的智力负担。ODPS还支持SQL以外的更多功能,例如mapreduce编程模型、xlib机器学习算法,它们如何计量计费还在摸索中。

  总结一下。如果您是ODPS用户,希望这篇文章展示了ODPS计量计费模型的逻辑,能帮你优化作业节省成本,也希望您能体会到其中的诚意。如果您是同行,云计算领域的产品经理,期望这篇文章对你规划自己产品的收费策略有借鉴意义。我们在创新,要获得问题的答案,甚至定义问题本身,都需要洞察和思考。

  最后感谢ODPS策略团队,尤其是数据分析师@班马明,上面这些逻辑都是他被几百张图表痛苦折磨几个月之后逐步梳理出来的。事实不止一次证明,数据分析师要有一颗产品经理的心,反之亦然。顺便提一下,面对ODPS系统的海量日志数据,@班马明同学“吃自己的狗粮”,利用ODPS本身完成了数据的抽取、探查、挖掘和验证。

  这篇是ODPS商业化一系列文章之一,更多请点击这里……

谈谈ODPS商业化(一)

  首先深深道歉,居然五个月没有发BLOG。这几个月是我近年来最辛苦,心理压力最大的一段经历。也直接导致很多生活习惯被打破,例如早睡,例如定期备份工作目录,例如定期修改登录密码,再如逛书店,也包括每周写一两篇博客。这些习惯现在正逐渐恢复。感谢回来的读者。

  很多人可能已经知道了,ODPS在7月上旬终于实现了一期商业化,部分功能结束邀请试用,全网开放,开始收费。大家可以访问阿里云官网开通ODPS服务,并下载用户手册和SDK客户端。除了阿里云以公有云的形式对外租用ODPS的存储和计算能力,还有两个渠道可以使用ODPS:御膳房,是阿里数据平台事业部推出的大数据解决方案,可以支撑淘宝天猫大买家和ISV利用阿里丰富的数据;天池,是阿里技术发展部的平台,主要针对高校和科研单位进行合作,目前正进入冲刺阶段的2014阿里大数据竞赛就是基于这个平台举办。

  阿里对ODPS做了很多宣传,网上看到不少讨论。如果要了解ODPS的方方面面,我认为下面对子楠和常亮的采访是比较好的资料:

  汤子楠:飞天、ODPS经历了许多血淋淋教训

  徐常亮:ODPS的愿景、技术实现与难点

  还有不少朋友在知乎上问与ODPS有关的问题,我们也都尽可能做了回答。

  尽管刚刚对外开放,已经看到大量的第三方用户上来,在ODPS上做各种各样有趣的大数据业务。尤其是各个领域的创业团队给我留下了深刻印象:金融保险、电商营销,运动手环,手机游戏,基因测序……

  接下来我会写一系列的博客,从个人观点谈一谈ODPS的产品和业务。计划谈的主题可能包括:

数据挖掘,微博,股票,星座和新年假期

  SNS数据挖据热度持续不降。

  前一阵数托邦工作室(DATATOPIA)利用微博数据进行数据挖据,发表了这篇关于《小时代》观众人群的分析报告,获得了很大的反响。根据数据比较,《小时代》观众的平均年龄非常低,很大比例来自二线城市,很大比例是女性,很大比例用iphone,很大比例喜欢《快乐大本营》。网上很多批评《小时代》的北上广大叔未必真正了解这群消费者。我在淘宝指数和百度指数上验证了一下,和文中的统计结论差不多。

  上个月奥巴马被刺杀的假新闻引发股灾,也是由于数据挖掘自动触发导致的。越来越多的投资公司实时监控社交媒体用于股票量化交易(据研究,Twitter情绪和股票走势之间有7分钟的提前量)。前一阵光大银行的投资事故占满报纸头版。这两天纳斯达克系统又崩溃了,最近这一两年事故真多,都是高频交易惹的祸。再加上“互联网金融”让传统银行和基金坐立不安。互联网屌丝正在颠覆金融高帅富。

  说到数据分析,《福布斯》杂志总结了Top 500的亿万富豪,发现处女座最多。被大黑特黑的处女座们一片欢呼!较真一点的话,子柳在知乎上的一个回答中提到,关于星座倾向性,必达团队曾严肃分析过淘宝消费数据,结论是“出生月份与行为模式无关”。由子柳的解释可以大概猜测到,中国的富翁中可能是天蝎座较多。中西方差异源于圣诞和春节之间的时间差,你懂的。

天河这种大型机还有存在的必要吗?

  在知乎上回答了一个问题“有了分布式计算平台后,像天河这种大型机还有存在的必要吗?”

  超级计算机其实也是分布式集群架构,和普通集群很类似,编程模型都是MPI、Mapreduce那一套。稍有不同的是:

  1.超级计算机用infiniband背板提高各节点间的网络IO,常规分布式集群一般都是千兆、万兆网卡。
  2.超级计算机一般会配高档的磁盘阵列,而GFS+Mapreduce方案底层基于挂在各节点上的普通硬盘。
  2.超级计算机会使用更先进的CPU和GPU,更多内存。
  3.由于发热强劲,很多超级计算机采用水冷。

  从这些细节可以看出:

  1.超级计算机更适合计算密集型作业,如果用MPI算核物理、天体物理、蛋白质折叠、渲染《阿凡达》、求解普通PC上需要几千万年的迭代方程,那么就应该用超级计算机。反过来,分布式集群Mapreduce适合IO密集型的作业,加上成本低,可以把集群规模搞得很大,因此最适合扫描过滤海量的数据,例如互联网行业的经典应用:为搜索引擎创建全网Web页面的索引。

  2.超级计算机造价更昂贵,维护成本也高,甚至每小时电费就得上万元。记得我以前做蛋白质搜索引擎的时候,在某台国内最大的超级计算机之一跑过一个80分钟的job,花了老板5000多块上机费(因为我们有项目合作,人家已经给我们打了很低的折扣了)。不过这些作业用MapReduce在普通分布式集群上跑,跑了好几天。

  云计算是建立在廉价分布式硬件+牛B的软件系统设计上,在商业上越来越成功。所以正在抢占传统超级计算机的用户市场。例如阿里云刚刚和国内的动画公司合作渲染出来的《昆塔》,计算量是阿凡达的四倍。不过就我所知,各大传统超算中心其实依然是排队、忙不过来的。随着国内经济的升级,很多造船、石油、材料、生物、天体物理、军事领域的计算需求都很强烈,这一类计算密集型任务,性能和时间往往比成本更重要。

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

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

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

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

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

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

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

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

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

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

这一期《程序员》杂志……

  这一期《程序员》杂志是大数据专题,俺们alidata部门同学的文章好多呀。关于数据产品的那篇文章里,用淘宝指数举例:“周大福钻石搜索人群68%都是女性,而成交人群100%是男性。”

  悲剧的是,在华大基因的陈钢和余昶两位牛人写的《生命科学中的大数据》中,居然看到了俺的名字。实在愧不敢当。只是一个跳槽的小兵。影响不到行业大势。我目前在阿里数据的ODPS团队,近期的业务方向与生物信息基本无关。

  据说我面试时,以前的工作背景的确加了一点分。阿里关注生物信息领域对云计算技术的需求也很正常。Google对DNAnexus投资是风向标。但目前国内的生物医疗大数据的市场产业化尚处于萌芽期,要说“布局”可能为时尚早。

  这篇文章最后的描述是真的:目前生命科学和计算机两个专业的就业情况是“冰火两重天”,尚在产业化前期的生物信息公司招募人才遇到很大麻烦。但也像他们说的:“市场正在打开,资金正在进入,人才还是很缺乏,这似乎是个好消息。”

  上次说过,华大基因近期势如破竹,收购Complete Genomics成功,上市的进程丝毫没受金融市场的坏天气影响。这是一家值得尊敬的中国创新公司,基因组学领域的华为。

  说起来,最近有一篇吐槽生物信息的BLOG很热。是这篇A farewell to bioinformatics,对此news.ycombinator.com上讨论得很热闹。我仔细看了看这篇BLOG,很多对生物信息的吐槽其实挺中肯的。但生物信息仅是生物学家的工具之一。从孟德尔种豆子起,生物学就是一门面临复杂背景噪音的学科,要证明一个假设,往往需要综合各种手段相互验证。对生物学家而言,生物信息学不一定100%可信,但也绝不是最差选择。

  找个机会和生物信息领域的朋友们深入交流一下。

度假、让·鲍德里亚和RTB

  度假一回来就去杭州出差,一呆就是两个星期。sprint 7发布比较顺利。事情多,欠很多东西没写,包括BLOG。

  在泰国时,基本都在酒店和沙滩上陪闺女玩。有次老婆去逛商业中心,我和闺女在旁边的书店里玩了好久。观察了一下,文学类的柜子,《龙纹身的女孩》和《1Q84》卖得最好。

bookstore

bookstore

  既然肉身在墙外,难免利用酒店免费WIFI去看不和谐的东西。例如跑到维基百科里,查看“教廷枢机院”成员的家庭资产。

  这期间浏览了些闲书,例如让·鲍德里亚(Jean Baudrillard)。这位法国哲学家强调了现代消费对社会的重大影响,更关键的是,在互联网出现之前,他就颇具洞察力地预言:“新媒体”会急速膨胀,重塑社会心理。现在来看,他所预言的“新媒体”的特点与今天的SNS惊人相似:高频互动;信息发布和消费看似自由(“世界是平的”);信息过载,实际仍按阶层组成不同的圈子;同一圈内,思想共振观点趋同;而这一切背后均由资本推动,用以不断提升个人对所谓“个性化消费”的需求。

  让·鲍德里亚的观点是相当激进的,他认为总有一天资本体制会完全吞噬个体,我们都终会成为“新媒体”网络上的一个传感器、一个节点,自以为独立思考,实际上一切都在体制的引导和预测之中。正因如此,科幻电影The Matrix(黑客帝国)一开始,Neo手里拿了一本让·鲍德里亚的著作。

  之所以看这些书,也是因为在工作中有所感悟。最近接触了很多个性化和广告方面的业务。广告理论家皮埃尔·马丁诺(Pierre Martineau)说:任何购买行为过程都是购买者的个性与所谓产品的“个性”之间的一次相互作用。现代广告的专精和准确,早已超出了常人的想象。一个例子就是这次美国大选,民主党团队雇的大数据分析团队,准确预测了所有州的得票率,误差不超过1%。这个团队应用的方法基本都是广告业的成熟模型。

  前一阵参加在北京举行的KDD 2012,好多论文和报告都涉及RTB技术和算法。国内媒体也开始注意到这个领域,例如刚发表的这篇报道写得不错。说起来,到阿里一年了。很庆幸有机会接触大数据的各种应用场景:金融信用、搜索推荐、在线广告、物流网络……

推荐系统业务调研

  来还前两天的债了。后面是推荐系统的业务调研。

  粘帖之前先说点八卦话题。最早知道数据挖掘和“尿布与啤酒”,是大一在贺仲雄老师那门妙趣横生的选秀课上,至今历历在目。包括后来两个月为了写那篇软件工程的论文,每天跑去图书馆查的资料,每一份内容都记得好清楚。再往后的三年,课堂上再也找不到那种感觉了,枯燥乏味死记硬背。最好玩的是,为了应付几门不同的选修课考试,连续三个学期,三次把“关联规则分析”和“梯度下降法”等算法的步骤背得贼熟,考完又很快忘掉。

  工作之后,进入生物信息领域,视角逐渐小众。认识xVector还是因为去贝塔沙龙听技术讲座,粗心记错时间了,幸运地碰到了Resys线下聚会。此后就成了xVector的粉丝,只要他的公开讲座,就尽量去听。最近一次就是今年在上海的第二届中国推荐系统大会。后面这份调研笔记的内容,大部分都是从他的书《推荐系统实践》里抄来的。

推荐系统实践

  今年连续参加了很多次数据处理的讲座,讨论。这份文档也算结果之一吧。

==============我是分割线,以上为无用的八卦内容===============

推荐系统业务调研

一、修改历史

  略……

二、简介

  随着ODPS系统被深入应用,在数仓团队以外,各个公司的BI团队也逐渐成为我们的用户。ODPS面临的需求也就逐渐拓展到数据挖掘领域。而推荐系统和个性化算法正是目前BI团队最典型的业务。

  本文对推荐系统的领域现状、典型算法、业务流程进行梳理。这份调研不是学术性的论文、算法、专利的全面列举,而是站在产品和业务的立场进行分析,对经典的工业界常用算法进行介绍,如果涉及Big Data场景会重点关注和讨论。

  涉及信息主要源于公开的网络、杂志、书籍和技术讲座。其中涉及淘宝推荐系统的涉密内容已删除,剩下的内容都可以在公网搜索到。

  转载,请保留原作者http://wangleheng.net链接。

三、背景和应用案例

  产品太多的情况下,用户面临信息过载,解决这个问题的方案包括分类目录、搜索引擎和推荐系统。前两种方案中用户知道自己想要什么,而推荐系统则更加主动。

  推荐系统通过挖掘用户的各种数据,找到其个性化的需求,将长尾商品推荐给需要它的用户,帮助用户发现那些感兴趣但很难发现的商品。目前已经投入工业实用的知名推荐系统包括:

业务领域

著名产品名称

网址

国内类似产品

电子商务

亚马逊图书推荐

www.amazon.com

豆瓣读书

电影视频

Netflix视频推荐

www.netflix.com

暴风影音、(hulu)

个性化音乐

Pandora和Last.fm

www.pandora.com

www.Last.fm

豆瓣电台

社交网络偏好推荐

Facebook Instant Personalization

facebook.com/instantpersonalization

新浪微博

个性化阅读

Google Reader

Digg 新闻排序

www.google.com/reader

www.digg.com

百度新闻猜您喜欢

LBS

Foursquare客户端

foursquare.com/apps

大众点评客户端

个性化邮件

Gmail优先收件

gmail.com

 

定向广告投放

Facebook 目标投放

facebook.com->
creat a Ad

 

  推荐系统的评价依赖于各种指标:用户满意度、预测准确度、覆盖率、多样性、新颖性、惊喜度。要测量这些指标,有些可以采用离线计算方式,有些则必须采用A/B对照组在线实验。真正的工业化实践中,往往是在诸多指标中寻求平衡,并记录业务效果,所以最终的衡量标准往往还得看点击率和转化率。

四、针对各种业务数据类型的经典算法方案

4.1. 利用用户浏览、购买、评价的记录数据

  基于用户行为的应用,最典型的就是各种排行榜,例如淘宝指数。

  早期数据挖掘领域最经典方法是基于销售数据的关联规则发现,一个被反复提起的行业故事是“尿布和啤酒”的故事。这个阶段,数据挖掘算法的主要业务客户来自于金融、电信、零售,这些行业才有条件和动力收集自己的业务数据。

  而进入互联网时代,协同过滤等算法成为主流算法。这种方法的基础是网站记录下来的用户行为数据。和前面提到“尿布啤酒”案例中的数据相比,互联网应用除了记录下产品的销售数据以外,还拥有每个用户(账号或客户端)的独立行为数据,这样就可以进一步针对每个用户进行个性化推荐。

  目前工业界最常用的协同过滤算法有两种:基于用户的(user based collaborative filtering)和基于物品的(item based collaborative filtering)协同过滤算法。另外隐语义模型(latent factor model)算法也比较受关注。

4.1.1基于用户的协同过滤算法

  基于用户的协同过滤算法是整个推荐系统领域最早最经典的算法。这个算法在1992年的提出标志着推荐系统的诞生。目前最著名的使用者是Digg新闻推荐系统。

  基于用户的协同过滤算法主要包括两个步骤:
  1> 找到与目标用户兴趣相似的用户集合;
  2> 找到这个集合中用户喜欢的、且目标用户尚未点击/购买/观看的物品给目标用户。

  对于步骤1>,要计算两个用户的兴趣相似度。从日志数据里,可以得到两个用户曾经有过正面反馈的物品集合,然后把这两个集合通过Jaccard公式(交集数除以并集数)或通过余弦夹角计算出其距离。

  有了距离公式,求对于某个用户最相似的Top N用户,就成了一个典型的KNN算法。如果用双层循环,硬算用户两两之间的距离,其时间复杂度是平方级的。

  但现实情况下,实际上很多用户之间是没有任何交集的,我们可以首先计算交集,只有不为零的用户对才除以分母的并集部分。这就节省了很大一部分计算量。具体算法里可以空间换时间,先创建“物品到用户”的倒排索引,再建立一个稀疏矩阵C用于存储两个用户之间的交集总数。只要扫描所有物品的倒排索引,将其中包含的所有用户之间的交集数加1(利用C),最终就可以得到所有用户之间不为零的交集(也就是C的内容)。

  得到用户之间的兴趣相似度之后,就开始步骤2>,这就相对比较简单了,只要用一个双重循环,就可以把与目标用户最接近的Top N个用户涉及到的所有物品进行排列,然后再挑选出其中目标用户没有涉及过的前K个产品。

  对于这个算法,还可以通过各种手段进行预处理,进一步提高效果。一个最常见的问题是“哈里波特现象”,也就是大热的畅销商品导致所有用户之间都有虚假的联系,既增加了运算量,也干扰了预测结果,降低了惊喜度。因此可以对畅销热门商品施加一个权重惩罚值。

4.1.2基于物品的协同过滤算法

  基于用户的协同过滤算法,其时间复杂度是与用户数目相关的。在大多数电子商务网站上,物品数都是大大小于用户数的。因此亚马逊最早应用了基于物品的协同过滤算法。这个算法目前成了业界应用最多的算法。反过来,Digg、新浪微博等新闻类网站仍然坚持使用基于用户的协同过滤算法,是由于这些网站上的物品(新闻帖子)的数目都是大于用户数的,而且这些物品会的很快过时(几天甚至几个小时)。

  基于物品的协同过滤算法主要分为两步:
  1> 计算物品之间的相似度;
  2> 根据物品的相似度和用户的数据给用户生成推荐结果。

  与基于用户的协同过滤算法类似,基于物品的协同过滤算法的计算也可以首先建立“用户到物品”的倒排索引,然后对每个用户,将他物品列表中物品两两在矩阵C中加 1。然后将矩阵归一化就可以得到物品之间的余弦夹角。

  除了前面提到的“哈里波特现象”,基于物品的协同过滤算法也会被“超级买家现象”干扰。如果有用户大量购买各种商品(例如职业出版人和评论家)则会导致算法性能下降,因此需要对过于活跃的用户进行权重惩罚。

  另外,为了增加推荐的覆盖率和多样性,应该对前面的相似度矩阵C按最大值归一化。这样就能保证被推荐的商品不仅仅来自一个类型中心附近。

4.2. 利用用户对产品的个性化标签(UGC tags)

  UGC标签系统是很多Web 2.0网站的重要组成部分。使用标签数据进行推荐的网站包括Delicious、Last.fm和豆瓣。

  基本的利用用户标签个性化推荐算法包括以下几步:
  1> 统计每个用户最常用的标签;
  2> 对于每个标签,统计被打过这个标签最多的物品;
  3> 对于目标用户通过他的常用标签,查找这些标签对应的热门物品,删重并推荐。

  上面方法倾向于推荐热门标签和热门物品,降低了新颖性。可以借鉴搜索引擎TF/IDF的思路,对热门标签和热门物品进行适当惩罚。

  进一步,可以适当对标签集合做聚类,计算标签之间的相似度,对标签进行拓展,从而对标签历史比较少的新用户或新物品提供更多推荐。对于相似度的度量,可以认为当两个标签同时出现在很多物品的标记中时,它们相似度较高。因此我们可以利用常规的余弦夹角来计算标签的相似度。

  再进一步,可以通过清理一些区分性不好的标签,以便提高算法精度,例如词频很高的停止词。也可以让编辑和运营人员进行整理。

4.3. 利用上下文和社交网络数据

  上下文信息和社交网络数据,均可以为主力推荐算法提供补充,作为参数输入到前面提到的经典算法当中去。

  例如,利用时间上下文,可以给物品设定一个半衰期,让较新的物品排在前面,这种做法对新闻类的Web 2.0网站很常见。

  再如,利用位置信息上下文,对很多LBS类应用很关键。具体计算时,可以先对目标用户进行个性化推荐,再利用他所在位置得到一个用户集合,利用这个集合的信息再给出另一个推荐结果,最后把两个推荐结果进行综合。

  还有,如果能得到一个用户的社交网络信息,就可以获得他的熟人圈子和关注对象列表。基于友好用户的兴趣来推荐或解释推荐结果,对目标用户的感受而言会更加可信。尤其是对于信息流的推荐,更加适合使用社交网络的信息。

  此外,社交网络的一个标准模块是好友推荐。最常规的方法是推荐“好友的好友”。

五、淘宝的推荐系统的特点

淘宝推荐系统

5.1. 业务场景

  淘宝的推荐系统主要涉及以下这些业务场景:
  1>Detail 浏览了还浏览
  2>收藏夹弹出层推荐
  3>购物车弹出层推荐
  4>已买到宝贝你可能感兴趣
  5>淘宝无线应用
  6>EDM(重复购买提醒)
  7>各个垂直频道
  8>个性化list排序

5.2. 算法应用

  淘宝推荐系统主要用到了聚类算法,预测算法,分类算法等基础算法产生基础知识库;利用协同过滤算法、基于标签的推荐算法和关联规则发现算法进行推荐。应用方式说明如下:

  预测算法,例如logistic 回归,通过以点击率为目标,以商品,卖家等因素作为指标,建立预测模型构建淘宝优质宝贝库。

  分类算法,例如朴素朴素贝叶斯算法,用于对商品和用户进行性别判断(男性、女性、中性)。

  聚类算法,例如k-means算法,用于对人群进行细分,例如客户流失分析;也用于Big Data条件下的降维。

  关联规则发现算法,用于发现类目、商品和用户的相关性。

  协同过滤算法,提供长尾新奇商品的个性化推荐,遇到的问题主要是冷启动。

  基于标签的推荐算法,优势是实现简单,且与搜索引擎容易配合,缺点是难以区分商品品质,无法照顾惊喜度。

5.3. 特点和需求

  淘宝推荐系统的特点是用户、商品、类目和商铺的数量都很惊人(数百万店铺信息、4.4亿激活用户、8亿在线商品、数十亿收藏标签、每分钟销售商品4.8万件)。因此前文提到的多数单机内存算法,都面临大数据下的分布式化改写的问题。除此之外,淘宝TCIF团队还希望融入更多信息,例如支付信息,用户访问的第三方网站PV等等。

  淘宝推荐系统的评价指标包括CTR、GMV和转化率。

  略……

六、参考文献

  《推荐系统实践》,2012年6月,项亮,人民邮电出版社
  《推荐系统@淘宝》,2012 年 7月,空望,百度文库
  《淘宝网TCIF案例分析:基于海量数据下的消费者研究》,2012年4月,必达,2012数据库技术大会
  《淘宝海量数据技术》,2011年 11月,空无,百度文库