|
|---|
|
|
|
|
|
|
o**********e
发帖数: 18403 | 1 【 以下文字转载自 Programming 讨论区 】
发信人: goodbug (好虫), 信区: Programming
标 题: Pinterest陶涛：三个教训和三个发展选择
发信站: BBS 未名空间站 (Wed Sep 3 03:19:03 2014, 美东)
http://tech.huanqiu.com/per/2013-08/4307208_2.html
我们作为创业公司总结了一些经验和教训跟大家分享一下：
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，我前面讲过了。我们这里实时讲的是
分钟级别的，而不是秒的级别。 这是我讲的所有的内容，非常感谢大家听我罗嗦这么
半天，谢谢。 | s*******h
发帖数: 3219 | | o**********e
发帖数: 18403 | 3 哈哈...
【在 s*******h 的大作中提到】
: 多少人看成陶铸
|
|
|
|
|
|
|
