【环球网科技报道 记者 李文瑶】8月30日,2013中国软件开发者大会在北京新云南皇冠假日酒店召开。此次会议以“软件定义未来”为主题,邀请近百名国内外业界领袖和知名技术专家共论技术热点与最佳实践,揭示下一代软件开发技术趋势与对各行业的深刻影响。
Pinterest首位中国工程师陶涛
在此次大会上,Pinterest首位中国工程师陶涛做了题为“Pinterest系统构架变迁”的主题演讲。在演讲中,他总结了Pinterest在创业过程中的3个经验教训与3个选择。他认为,一个公司在发展过程中,不论规模的大小,都需要考虑机器效率与人工效率之间的平衡。
以下为演讲实录:
陶涛:谢谢大家,谢谢蒋涛董事长和刘江主编给我这个机会,同时感谢CSDN所有的工作人员和志愿者把会议组织的这么成功。
我今天要讲的题目是Pinterest系统构架的变迁。我大概简单介绍一下Pinterest,因为它还是一家比较小的创业公司,很多人不是很熟悉。
Pinterest是一家互联网站,很多互联网公司其实是在前互联网时代,就是没有互联网的时候都有一些原型。互联网本质上来说就是把前互联网时代的一些东西搬到了互联网时代。Pinterest在前互联网时代是什么东西呢?就是这个东西。我们知道我们小时候有一些街坊大叔大妈、爷爷奶奶们有一些爱好,会把报纸上非常漂亮的图片和文章剪下来贴在大册子上面,作为收藏的目的。在美国其实也有类似的概念,即便到今天为止还是有很多人,他会把办公室或者工作间放上一个大板子,用图钉把一些感兴趣的图片或者便签,或者收藏的东西拼在这个大板子上,这些就是Pinterest的原型。
我们看今天Pinterest的网站还可以看到很多那时候的生活的习惯。这是Pinterest今天的网站的形式,首先每个人可以建一个主页,主页下面,我们知道前面的大板子叫做Board,我们延用了这个概念,比如说我喜欢养狗,我就建了狗的Board。
Pinterest还是社交网站,社交网站我们知道非常典型的就是facebook或者推特,Pinterest延用了推特的形式,我可以follow一个感兴趣的人,它就出现在一个图片流里头,这就叫瀑布流,刚才刘江主编介绍了,这是Pinterest最早引进的,甚至今天瀑布流的方式比Pinterest更有名,很多网站都采用这种方式。这是简单的介绍了Pinterest是什么。
我们下面进入一些技术话题。在技术话题的最开始我想介绍两个人,一个是Yashh,一个是Marty,他们改变了Pinterest整个的框架。我不是最早加入的,早期的历史我不知道。我来之前Marty说我是不是应该照一张更好看的图片。我说你虽然长的不好看,但是我们是技术大会,所以问题不大。
Pinterest最早在2010年3月份的时候上线,那时候没有任何流量,也很少用户,除了自己的员工以外有很少的用户。做这样一个网站其实非常简单,有一台web机,一台数据库就够了,那时候有两个工程师,也是两个创始人。这是他们的图片,他们笑得非常开心,一个原因当时没有流量,没有流量就没有压力。同时他们也在憧憬以后美好的未来,所以笑得非常开心。
大概过了一年,发展到2011年的1月份,我们求爷爷告奶奶,终于有一些流量了,我们很开心。为了庆祝一下,他们需要改造一下这个系统支持这个流量。这时候我们采用Amazon EC2,当时非常流行,很多硅谷的公司都在使用,所以我们选择了它。这时候你有实际的流量的时候,你一台master是不够的,所以我们加了一台。
这时候有两个工程师加两个创始人,这是早期的图片,这是非常典型的硅谷创业公司的景象,大家聚在一块吃比萨。背对着我们的是工程师,用电脑的是设计师,分比萨的是创始人,它和Ben两位创始人是负责产品的。穿红衣服的女士很有意思,她在早期是Pinterest的用户,很早阶段就很喜欢,很活跃的在上面拼各种东西,很快的积累了人气,用微博的说法就是草根大V的形式。当时的系统很不稳定,她一贴东西我们的网站就有问题,当时怎么办呢?既然对付不了她就招安了吧。她对很多核心用户都很了解,她负责跟各种用户进行交流,了解用户的需要。今天看虽然只有5、6个人,但是麻雀虽小五脏俱全,我们有设计、产品,有跟客户交流的人员。到今天为止其实整个公司的构架也基本上这样,但是每个都已经成倍增加了。
继续往下发展,2011年对Pinterest来说是一个大爆发的一年,我们可以看到流量成指数型的增长。用一句话形容他们当时的心情是白岩松的一本书,痛并快乐着。一方面非常开心,我们的流量很快的增长,证明产品被认可了。同时也带来很大的压力,有一种有病乱投医的状况。
我们当时实验了很多的技术,包括大家还是在用Amazon EC2,但是我们回过头来看这个列表有很大的问题,这个问题是什么呢?最后一行,我们只有三个工程师,你整这么一堆东西能对付的了吗?很显然对付不了。那么到最后他们完全承受不了工作压力的时候就退一步来想一下是不是有一些问题。
我们作为创业公司总结了一些经验和教训跟大家分享一下:
1、保持简单,这对创业公司来讲非常重要,一个简单的系统出错的可能性就很小,出错以后解决问题的可能性就变得很大。保持简单我们认为对创业公司来说是非常关键的问题。
2、我们认为一项技术的超级用户遇到的难度是远远大于普通用户的。我们知道大家今天都在用一些开元软件,这些开元软件是逐步发展的过程,很多软件在早期并没有经历过很大的压力测试,在一定的流量基础上他们都工作的非常少,但是超过一定流量的话都有各种各样的问题。如果你作为超级用户,你可能接触到的问题是前人完全没有遇到的,你很难在社区里得到任何求助,需要自己读它的代码,去看是不是我能解决,如果解决不了的话怎么办?如果解决了当然是可以去改一下它的代码,如果解决不了的话,有的时候构架的限制解决不了是很麻烦的问题。
3、新技术往往看上去很美。这个话其实有两层意思,一种是真的看上去很美,如果看上去不美也不能叫新技术了。第二层意思是往往只是看上去很美,真正用起来并不美。我们知道一项技术在使用的时候真正麻烦的首先是配置,每天要进行操作,错了以后如何去改,这些都是不美的地方。我们认为在采用新技术的时候需要非常谨慎。
我个人非常欣赏我们创始人有一句话,Pinterest本质上不是一家靠出卖技术为生的公司。卖技术很简单,人家是出卖技术为生的,技术一定要领先时代,否则没人使用你的东西。对于Pinterest这样的网站我们卖的是产品,我们创始人Ben曾经有一次说过,我们不是在做技术竞争,一项技术的难和简单不是我们最终要考虑的目的,我们要考虑用户需求什么。如果一项技术很简单,但是解决了一个用户需要的问题,那也是很好的项目。 有了这些经验教训以后我们就对框架进行了很大的改进。
这是2012年1月份的时候,这时候主要的人已经涨到15个工程师,25个员工,但是使用的技术相对减少了。我们还是用Amazon EC2、NGX。2012年1月份大概10个人,我2月份的时候去面试的,那时候就这个样。2012年6月份的时候,我加入公司几个月,我们当时有三四十人,当时公司的发展挺好的,主要的框架改进基本完成了。
下面我们看到这些故事以后讲一下创业公司发展的选择,当然这只是Pinterest发展过程中的选择,不一定适用于所有的公司。我们想问一下自己大概这些问题:
1、这个技术是不是满足你的需求。如果一项技术不满足你的需求,它看上去再美也没有用。
2、这个技术的成熟程度。包括是否被广泛的使用,社区是否活跃,容错性特别好、扩展性特别好,方便调试,这一系列的问题都和技术的成熟有关。
3、花费问题,我们知道创业公司最缺的就是钱。比如说技术成熟,今天Pinterest使用这个数据库也是奢侈的举动。 我们看早期技术的选择。首先是Hosting,我们采用Amazon EC2的选择,Amazon EC2包括了很多各种配置的菜单,如果我今天立马需要一台服务器,我可以现在去定,5分钟以后拿到这台机器,这是无法取代的功能,非常方便。
Amazon 同时负载了防火墙、DNS。我没有统计,但是有感觉,在硅谷的创业公司几乎都在用Amazon 平台。Amazon 的平台稳定性相对比较好。我印象过去一年半的时间里只有一次大的事故,当时新泽西刮大风,把整个电网吹断了,整个网站全部瘫痪了,这是唯一一次比较大的事故,大部分时间比较好。但是Amazon 也有它的问题,它非常贵。
第二,Amazon 整个云计算IO性能非常差,这是以前没有使用Amazon 的时候无法想象的差,但是现在我们也没有办法,我们没有足够的人去建自己的数据中心,暂时只能使用Amazon 的云平台。
我们的语言早期选择了Python,这个语言很成熟了,而且这几年数量在逐渐增加的状态。它的社区非常活跃,有比较方便的web构架。有Python以后你可以很方便的调试。这是早期语言的选择。稍候我还会重新再来讨论一下这个语言的选择问题。
我们的存储使用了my SQL和Memcached,很多公司都会用Memcached,你抓几个人,十个人有九个人用过,它的读的效率非常高。它有很好的技术支持,有发展20多年的技术,而且技术支持社区非常活跃。但是最重要的问题是它免费。
我们同时也使用Redis,Redis支持各种不同的存储的选择,可以只放在内存里,或者可以备份在硬盘里,可以独立的作为存储方式使用,Redis也是免费的。 同样的看一下Cassandra,MongoDB、Membase我们最后淘汰的没有选择使用的。我这里讲的是2011年底的情况,这三个项目其实一直在开发,首先Cassandra和Memcached丢数据,Membase表面上免费实际上不免费。
发展到2013年,就是今年的4月份,我们大概有70个工程师,总员工超过130个人了。这时候我就不再称Pinterest是一家创业公司了,叫一个小型的公司比较合适。我们使用的最核心的东西还是Amazon EC2、Memcached这些东西。同时因为人员的增加和整个的功能性的增加,我们会继续扩展,开始把整个组织构架转向这种叫面向服务的体系结构、框架。由于这种转变有一些非核心的,不像最核心的内容那样周期的东西,我们可以放在一些不是那么重要的一些存储结构上面,所以我们重新使用了它。
这大概是今年6月份的时候我们新装修好办公室以后,搬新家的时候一幅照片。当时前一天晚上HR发信说都要穿Pinterest的T恤衫,但是我没有看到这个信息,后来我想这个事很不好,所以以后我就天天穿,到今天我也穿Pinterest的T恤衫。
我前面讲到140人的公司很难说是初创公司,可以说是小规模的公司了。问题还是那些问题,但是我们需要考虑的是机器的效率和人的效率的平衡。在很小的公司,比如说只有3、4个工程师的时候,人的时间是最宝贵的,如果你能用很好很快速的解决问题的方法的话,可以大大解决人员的开销,但是你到一百三四十人的时候,七八十个工程师,可以做一些优化。这时候你的流量也可以十倍、百倍增加了,任何在硬件上的开销节省都可以转换成很大一部分钱。这时候做了一些其他的改进,首先我前面说了我们要重新看一下语言的问题。
python这个语言问题比较大,效率很低。python的CPU效率非常低,这似乎没有特别好的解决方案。你可以在CPU使用很频繁的地方用C语言来写,但是C语言是一门大家都不愿去碰的语言。所以我们当时的讨论就是说我既然要转换成这样的话,我就换语言。语言上我们有很多种选择,但是我个人理解语言更多的是工程师之间的妥协,而不是技术方面的问题。比如说我个人很喜欢Scala这门语言,我用了很多年。但是我当时提出用Scala的时候,一堆砖头扔过来。几乎很多人说我没有用过,也不喜欢,还有一个工程师用过,但是非常恨这门语言,所以最终没有选择。
C++基本上没有提上日程,基本上是前谷歌的员工用了,但是就是唠叨了几句,因为知道提出来也不会用。Go语言太新,我们当时测试过,它的效率很低,我们可以说重写一遍效率比较高,但是我们不知道一门新的语言潜在的问题很多,想再等等。我个人非常喜欢Go这门语言,原因是它的作者都是我们业界的有名人士,它的效率一定会解决。
最后我们选择了劳动大众很喜欢的语言JAVA,它到今天为止还是很大的语言,有很活跃的社区和支持。我们当时在推特内部使用这套框架很好用,效率也非常高。并且推特有一套比较完整的开元的软件,这个包括其他大公司,谷歌、facebook都没有完整的开元。我们觉得用推特这套框架是非常完整的选择,最后我们选择了JAVA。 我们最终重新提上日程的NoSQL,原因很简单,有一些非核心功能的增加,这些开发人员并不太想去使用Memcached,因为它的格式比较固定,同时很多人不想去做。我们之前用过很有很糟印象的不会再使用了。之前没有试过的HBase今天会选择。还有Pinterest里有很多前谷歌的员工。HBase本身基于Big table这篇文章写的,所以最终选择了它。
我们开始建自己的搜索,我们采用Solr+Lucene这套框架。我们使用的过程中发现Solr的效果不是太好,但是很简单,所以我们推倒了自己重新写,但是Lucene做的非常好,短期内不会碰它这块。
这大概是今天Pinterest的大概的框架,跟后端的连接是用的lukeeper来连接的。我们使用的推特开元的东西去减少整个过程产生的问题。Pinterest是一家图片网站,所以我们有大量的图片。我们暂时存在空间里,这个存储非常贵,我们的图片非常大,所以我们正在做一套自己图片存储的东西。我们一些应用使用ribits,其他的应用使用HBase。我们用的startD的性能比较简单。
这是我们智能算法的都是,我们数据处理的一套东西。最上面是API,它会写到KQ里头,分两层,一层是拷到S-street上面去,利用一些软件计算,当年的职能算法是在这上面来算,处理这些。还有一套准实时的东西,我们有一些lesser,去监听整个Kafka的状态,如果产生任何事件以后,会交给实时处理的简单的服务,这个服务会形成实时的推荐和搜索,写入实时推荐和搜索引擎。
这是我们非实时数据处理的,我们选择的Hive、Redshift和Casoading,Hive非常简单,但是很慢。Redshift比Hive快,我们正在向这方面改。我们非常复杂的计算采用Casoading,采用JAVA的语言。这大概只是搜索和推荐每天要运行的所有的数据,大概一百多个,我们用Azkaban来做。Azkaban有一些问题我们也内部做了改进。
我们的实时处理大概用了Kafka和listeners,我前面讲过了。我们这里实时讲的是分钟级别的,而不是秒的级别。 这是我讲的所有的内容,非常感谢大家听我罗嗦这么半天,谢谢。