最好走的路越走越难,最难走的路越走越容易

Follow guwendong on Web
  • Subscribe to Beyond Search via RSS
  • Follow @clickstone on SinaWeibo
  • Join Resys Google Group
  • Follow @clickstone on Douban
  • Follow @clickstone on Twitter

Category Archives: 好文收藏

Early Amazon: Inventory Cache

原文链接:http://glinden.blogspot.com/2006/01/early-amazon-inventory-cache.html

原文作者 Greg Linden 毕业于华盛顿大学计算机学院,1997 年加入 Amazon,开发了享誉业界的 Amazon 推荐引擎。
著名的 Item-based 推荐算法的提出者之一;Findory.com 创始人。
其 Blog – Geeking with Greg 是个性化推荐领域最有影响力的博客(没有之一)。

本文首发 http://www.resyschina.com/2012/03/early-amazon-inventory-cache.html,由 @raully7 翻译。

类似谷歌的20%时间,亚马逊的员工有时也会做一些不如日常事务那么紧要的额外工作。

我当时负责了好几个项目,但我想跳出来,以掌握更多部分的代码。只是读代码过于无聊了,我需要做一些特别的事情,让我更深的理解他们。

所以空闲时候,我开始试着做性能优化。主要关注于那些高流量的页面——首页、书籍详情页、搜索结果页。我问自己,obidos(注1:亚马逊的页面渲染引擎)把时间耗在什么鬼地方了?

很快我发现了些有趣的东西。第一个上手改造的是购物车。

当你走进一个超市,你做的第一件事很可能就是推一个购物车。同样当人们访问亚马逊时,系统做的第一件事情也是给他们分配一个购物车——在数据库里开辟部分空间以存储购买的商品。

然而,超市并不需要应付大量机器访问或多窗口购物的情况;如果需要,他们也得有更多的购物车,而且几乎每个都是空的。

考虑这些并不实际购买的情况,延后到第一次购买物品时再分配购物车就变得很有意义了。把所有购物车的花销加起来,这个小改动带来的帮助比想像的要大的多。

另一个更大的问题是实时库存检查。当你查找一本书时,亚马逊检查仓库货架内是否有存货。如果没找到,他会再查找过多久才能订购这本书。所有这些都是实时完成的。

这是书籍详情页中最耗时的操作。库存检查是个丑陋的业务逻辑。

但我们真的需要实时的信息吗?也许用几分钟前的结果就够了。恩,是的,可以缓存数据,稍有延迟并不是什么大问题。

因为是用业余时间做这件事情,我从一些并不太大的改动开始。我认为,有多大压力是由网站业务决定的,我要做的是把加锁减到最少。同时我认为能通过缓存预加载,使得用户在缓存刷新时也没有任何延迟。

我鼓捣出的东西似乎运作良好。在测试中,访问延迟从一个很大值降低到了接近零。我开始同其他人讨论这个原型,听取他们的改进意见。

正巧,他们正在对亚马逊进行重新设计,包括彻底的改造和增加新功能。有人找到我希望能在搜索结果页也显示书的库存情况,然而没有缓存这是完全不可能实现的。除非能很快把我的原型实现并弄上线。我们也确实这么做了。

当然,这些如今看来是过时的。当我实现这个库存缓存时,它被设计为一个西雅图的小仓库工作,运行在单台大铁壳(honkin’ iron)服务器上。如今海量的货物散步在若干个巨大的配送中心中——其中一些甚至大的能装下13个足球场——通过切换到一个商品服务器集群能在几秒内获得结果,这最终使得旧缓存不再适用。他运转良好到超出了他的时代,长到年轻时的功绩躺在自己的衰老下被遗忘。(It lasted well beyond its time, so long that the heroics of its youth lay forgotten under the problems of its senility.)

这里我将库存缓存作为个人自由时间带来收益的若干例子中的一个。 20%时间产生了远远超出其比例的价值。

注1:obidos是amazon早期的页面渲染引擎,一直被使用到06年8月底。因临近亚马逊河的小镇Óbidos而得名。http://en.wikipedia.org/wiki/Obidos_(software)


Greg的这系列文章,很多都是回忆他20%时间里鼓捣的事情。也侧面说明了真激情确实可以一辈子。

月初James Whittaker离开谷歌时,也专门写了一篇吐槽文。其中一段回忆到昔日公司的创新气氛:

In such an environment you don’t have to be part of some executive’s inner circle to succeed. You don’t have to get lucky and land on a sexy project to have a great career. Anyone with ideas or the skills to contribute could get involved.

20%时间,一直我们这些国内工程师艳羡和乐于谈论的,似乎总是可望不可及。环境不论,很多事情其实可以从自己做起。

 

Early Amazon: boy-am-i-hard-to-please

原文链接:http://glinden.blogspot.jp/2006/01/early-amazon-boy-am-i-hard-to-please.html

原文作者 Greg Linden 毕业于华盛顿大学计算机学院,1997 年加入 Amazon,开发了享誉业界的 Amazon 推荐引擎。
著名的 Item-based 推荐算法的提出者之一;Findory.com 创始人。
其 Blog – Geeking with Greg 是个性化推荐领域最有影响力的博客(没有之一)。

亚马逊早期的代码中,有相当一部分是由最早的两位员工编写的。他们的痕迹在 obidos 系统及其相关工具中随处可见。

可想而知他们的工作很多,但令人惊讶的是,起码我很难想象是如何办到的,他们居然还有时间进行其他一些有趣的边缘项目。我最感兴趣的一个叫做「Eyes」。

Eyes 曾经非常有用。它允许读者登记一个 Email 地址,设定一个查询条件,当有某本新书满足这个查询条件的时候,Eyes 会自动给读者发送一封 Email 通知。这种获取新书消息的方式非常棒,尤其对于写实文学来讲。

介绍 Eyes 的文案很有意思。它是这么写的:

Eyes 是你的全自动搜索器,它很神奇。告诉它你喜欢哪些作者,喜欢哪些主题,它就会自动匹配这些设定,跟踪每一本你感兴趣的新书。注册 Eyes 吧,当那些你关心的书籍上市的时候,我们就会自动发送 Email 通知到你。

好吧,如果你认为这项免费服务不够酷或者没用的话,请发送邮件到 boy-am-I-hard-to-please@amazon.com,告诉我们为什么。

Eyes 服务了许多年,直到后来被 Amazon Alerts 所取代,Amazon Alerts 不可谓不是一个好服务,但与 Eyes 相比,总好像是少了些什么。

通常,停留在记忆里面的就是这些好玩儿的事情。在我创建 Findory 的最早期,一个客服邮件地址就是 boy-am-i-hard-to-please@findory.com

要有爱,要做让自己快乐的事情。

 

Early Amazon: BookMatcher

原文链接:http://glinden.blogspot.com/2006/01/early-amazon-bookmatcher.html

原文作者 Greg Linden 毕业于华盛顿大学计算机学院,1997 年加入 Amazon,开发了享誉业界的 Amazon 推荐引擎。
著名的 Item-based 推荐算法的提出者之一;Findory.com 创始人。
其 Blog – Geeking with Greg 是个性化推荐领域最有影响力的博客(没有之一)。

在参加亚马逊面试的时候,我提出了很多想法。我列举了一坨我认为可以改进亚马逊网站的方法,其中就包括书籍推荐系统。

我喜欢读书。很中意书籍推荐系统这个想法。发现未知的有趣的书籍,这是多么好玩儿的一件事情啊。我想亲手去实现它。

在亚马逊的第一个星期,我很失望,因为我发现已经有人在做书籍推荐系统了。亚马逊网站的早期用户应该会记得,那个玩意儿叫做“BookMatcher”。

BookMatcher 首先要求用户给 20~30 本书打分,然后才会做出推荐。想必你可以猜得到,几乎没人用它。必须给 20+ 本书打分,对大多数用户来说太麻烦了。

BookMatcher 系统由一个外协公司在提供技术服务。杯具的是,它根本不 work。需要给 20+ 本书打分这样的进入门槛只是问题之一。整个推荐方法偏向于热卖的产品而忽略了长尾。系统还很慢。总而言之,这个系统既不可靠,一有压力还老是宕机。

这不是亚马逊需要的系统。亚马逊的书籍推荐应该基于稀疏数据,少量的打分或者购买记录。它需要快速给出结果。它应该能够扩展到大规模用户群以及数目巨大的品类。它应该能够帮助用户发现那些湮没在类目深处的他们无法找到的书籍。

一定有更好的选择!

补充:
今天有一条讨论很热烈的微博,和这篇文章里面描述的状况有点儿像,

@范凯robbin:昨天一位运维人员入职,我们进行了运维系统介绍和培训,以及接下来逐步清理和改造运维的计划和步骤。今天早上他来找我,说我们公司网站服务器运维现状太乱不是他喜欢的环境,辞职了。我理解他的选择,不过亦为他惋惜。一套完全运转良好的运维系统是无法给有进取心的人任何发挥的空间的。

如今国内的创业公司想找到愿意冒些风险迎接挑战的靠谱的人,难如登天。这事儿倒也自然,人各有志,莫强求,看缘份。不过我很同意 @Fenng 的说法,“正所谓,公司的问题,就是员工的机会”。你看,Greg Linden 也是这么走过来的。

去年,我一个很给力的大学同学,被国内某家名称以数字开头的互联网巨头搞去秘密研发手机操作系统,结果怎么样我就不说了,反正现在转去搞 Web App 了,号称下一代移动应用开发框架。。。好吧,其实我想说明的是,大公司也不一定就有多靠谱,还不如我们死磕一件事,从头开始稳扎稳打,只要事情是你喜欢的,百炼成钢。来吧,一定有更好的选择

 
猛戳这里

简网指阅 联合创始人 & CTO
ResysChina 发起人
1. 持续关注 个性化推荐 技术;
2. 持续关注 Semantic Web 技术;
3. 评论与上两项相关的互联网业务与产品;

我相信技术的力量!
wendell.gu@GMail.com

Archives