Category Archives: 0和1

度假、让·鲍德里亚和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月,空无,百度文库

KDD 2012第一天

  我现在在KDD 2012大会现场。由于今年的主题是Mining the Big Data,有趣的报告太多了。我主要在穿插着听以下三个Track:

  1.关于海量数据处理,基于MapReduce、Stream的数据挖掘算法实现的BigMine

  2.关于生物信息数据挖掘的BIOKDD,以及与健康信息有关的HI-KDD

  3.Yahoo专家的特邀报告Data mining in streams

  见到很多朋友,如果你也在现场请联系我或者微博上@我,大家多交流。

KDD2012将在北京举行

  第18届知识发现与数据挖掘ACM学术会议,也就是KDD 2012,8月12日将在北京举办。这次大会的主题是Mining the Big Data。由于阿里云是赞助商之一,所以我弄到了参会名额。

  这次的KDD cup 2012,题目使用了腾讯微博和搜索引擎的数据。负责主持的是Kaggle,数据挖掘领域著名的竞技平台,里面举行的比赛奖金颇丰。

  2004的KDD cup,题目是生物信息领域的,pFind团队的yfu大牛取得全球并列第一。

  而让KDD cup名声大震的,当数2006年的Netflix Prize,悬赏100万美元。现在国内推荐系统领域领军人物xVector,就是凭借这次大赛成为大众偶像。这是戏剧性的一次大赛,纽约时报全程报导,xVector的团队在最后20分钟痛失第一。

  我们会上见。

由背包兔谴责盛大云说起

  盛大云故障的事好像越闹越大,背包兔今天在微博里谴责盛大说:

     同时我们严厉谴责盛大这种用普通无备份的虚拟主机来冒充能数据备份的云主机,是一种彻底的欺诈行为!

  对于云主机的磁盘技术,存在不同的方案和思路,做些分析。

  亚马逊EC2的方式是采用本地磁盘作为系统盘,然后再挂上S3云存储作为数据盘。这样做的好处是系统盘会有很高的IO性能,同时节省成本。但也面临着一些风险,如果系统盘损坏了就有可能无法恢复。盛大在技术方案的选择上,照搬了亚马逊。盛大云的本地磁盘应该是做了RAID,这次也确实比较背,同一个机器上多块磁盘都同时坏了。

  而阿里云ECS所有的存储都放在飞天分布式平台上,也就是说无论系统盘还是数据盘,都是云存储,会有多份备份。同时阿里云ECS还会定时自动备份镜像。这样做的好处是安全性得到很大的保证,一旦有磁盘损坏就能自动秒级迁移到其他副本上,如果运气很差多份拷贝都坏了(估计比被雷劈中概率还要小上百倍),还可以回滚到此前的历史镜像。也正因为这样,阿里云的市场运营团队才有胆子公开宣传:发生故障给予100倍赔偿。

  当然阿里云的技术方案是有代价的:首先系统盘的IO就不会那么出色,其次造成的成本压力比较高。技术团队一直在对云存储进行大量的优化,已经取得了很好的进展,申请了一些专利(完全自主开发的平台,相对拿来开源方案,就有这个好处,有一支队伍掌握自己的命运)。同时由于市场逐渐打开,销售额上去了,摊薄了前期投入的硬件成本,所以最近价格也逐渐降下来了。

  对于站长们来说,不管用的是哪一家云,还是建议能更深入吃透云背后的技术原理,设计自己的方案。例如这次事故,如果预先把应用程序和关键数据分开,把关键数据设置放在云磁盘里,可能受到的影响就小一些。有能力开发脚本的,还应该开发一些定时备份的工具。

第一句话&回不了天通苑

  随手记录两件事。

  早上带着小婴儿外出做客。女儿刚坐到车里的婴儿安全座椅上,突然说了人生的第一句话,叫的是“爸爸”。所以一整天我都特开心,每次她一喊“爸爸”,就屁颠屁颠跑过去,给女儿递她够不着的好吃的和玩具,或者让她拽头发。

  下午北京持续大暴雨,回天通苑的立汤路积水断路了。立水桥河水倒灌,好多车都熄火漂起来了。想绕路,还没走多远就堵死,一些红绿灯都失效了。看到市政工人很幸苦,在大雨里站在十字路口没膝的积水里,举着"此处篦子已经打开,请绕行"的牌子提醒来往车辆。交通台不断念叨:“东二环、南二环、西二环,北三环……我们尤其同情住在天通苑和北苑的同学们……大家没事尽量别出门了,司机们发现积水不要冒险涉水通过……”

  最终只好开到亲戚家借住一晚上。据说接下来三个小时降水量会超过50毫米,大雨会一直持续到明天早上10点。

编程语言

  最近又在上海、杭州……到处飞。在飞机上用大黄蜂看了好多电影。

  网上总有编程语言的讨论,以及公司和团队用哪种语言不用哪种语言的议论。我刚刚在42qu上回复一个帖子,对此作了一些评论:

     java和python无所谓好坏,只在于团队合适哪个。如果工作中不能用,自己找时间自学不也很好吗?

     算了算,我曾拿来实际挣过钱的编程语言有11种,编程超过万行的有5种。其中很多最初都源于私人兴趣,拿来摆弄玩,后来工作中有合适机会就用上了。工具总是会换来换去不断演进,如何使用它们做出好产品更重要一些。

     招聘和技术方案选型总有各种考虑。如果是较平常的项目,大公司常选用主流编程语言以降低人力成本。反过来,很多极客文化较浓的创业团队最初青睐python,或者lisp,或者go,或者其他某种奇怪的编程语言,往往并非这种语言本身比Java和C++牛。而在于,熟悉小众语言(不过现在python也不算小众了)是个明显特征,意味着这个程序员有好奇心、不怕变化、喜欢私下主动踅摸技术、对编程有兴趣、有能力独立解决问题。

  帮教主宣传一下。他的python网站培训班又开始报名了,里面大量动手环节,有兴趣的去看看吧。

easyHadoop、Resys以及追女生的行动次序问题

  最近不断参加各种非正式的技术沙龙,接触网站和创业者的运营团队和数据分析团队,也就是ODPS的潜在用户,了解需求和业务。工作比较累,BLOG更新拖延了,抱歉。这次先写点零零碎碎的东西,接下来会尽快补上此前没写完的东西,例如《伯罗奔尼撒战争史》读后感系列的收尾部分。

  4月中旬,参加了easyHadoop的第二次开发者聚会。后来还和暴风的童小军向磊做了进一步交流。easyHadoop是致力于普及Hadoop、HIVE等开源Big Data数据分析解决方案的志愿者组织,开源了phpHiveAdmin、HappyETL等一系列实用工具。如果你跃跃欲试想找实践机会,参加easyHadoop社团的活动是个好选择。

  5月份还打算去上海参加第二届中国推荐系统大会。推荐系统现在很受关注,Resys在北京的每次活动都爆满抢不到座位。我最早关注,还是因为那次记错时间到贝塔咖啡,误打误撞闯入了这帮极客的线下聚会。当时是xVector分享他参加Netflix数据挖掘大赛的经历。(什么,你没听说过Netflix百万美元的推荐算法大赛,欢迎来地球。那次比赛里,在截至时间只有20分钟的时候,xVector的算法痛失领先地位,没拿到100万美元的奖金)。xVector进入工业界以后,42qu请他又讲了一次。这次上海的会,他将做一次很有干货的会前培训。

  值得一提的是,当年Netflix大赛,各参赛队都是租用亚马逊的EC2弹性计算,部署Hadoop跑统计和拟合算法的。纽约时报对这此的连续报道,也给亚马逊的AWS做了免费的广告。希望未来ODPS能在纽约时报上获得同样的露面机会。

  最后写点非技术八卦。42qu上有个小伙儿怯生生问大家,他喜欢身边的一个女孩,怎么办。一帮技术宅男七嘴八舌给他出馊主意,例如给女孩子做个网站,或者上天涯发动网络舆论帮忙。我是这么回的:

     常规流程是:闲聊、邀请、吃饭、逛商场、看电影、逛公园、送礼物、表白、小亲密、推倒……你也可尝试倒序执行。

     别相信前面那些码农的雷人YY。以上任何阶段插入“网上舆论造势”和“编写网站”啥的,均会引发“女生不兼容”异常,进程将报错退出。

百度技术沙龙:海量数据处理技术

  今天去参加InfoQ举办的百度技术沙龙,主题是海量数据处理技术解析。在开始之前,看到这个视频《盒子里的梦想》,觉得拍得挺有意思。

  第一个讲演者杨栋,在计算所的时候就认识。当时他是曙光5000分布式文件系统的主力开发者。到了百度以后,就成为分布式系统方面的主力。在很多技术交流会上都有报告。这次的PPT重点是Hypertable的各种性能优化。他特别强调profiling的重要性,我对此深有体会。

  第二个讲演者徐振华,是58同城(58.com)云平台的技术负责人。尽管这个神奇的网站规模小于百度,但是报告内容还是有不少实践方面的干货的。其中一个案例是关于离线处理的数据统计应用的。我对此特别感兴趣,报告下来也和他做了一点交流。

  后来计算所的查礼研究员也做了分享。提到了HIVE里面RCFile的技术细节。刚好最近正在了解阿里云ODPS内核里面的类似数据结构。

  转产品经理以后,每天都是大量邮件、电话、会议,交流非技术的业务和人的问题。即使出来参加活动,也是车库咖啡面向创业者。有一阵没参加比较纯粹的技术沙龙了,心情很复杂呀,呵呵。

西乔的漫画:Game Over

  3月份的《程序员》杂志,西乔美女的《神秘的程序员们》系列漫画的最新一篇《Game Over》不得不推荐啊。想看更多的,可以去她博客上找

 GameOver——《神秘的程序员们》系列漫画

  前两天被合作公司的老总称赞说:“有些东西是天生的,学不来的”。尽管是客气恭维,我还是感到高兴。一直很钦佩这位创业者,所以他的夸奖令人兴奋。