g*****g
发帖数: 34805 | 1 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，我前面讲过了。我们这里实时讲的是
分钟级别的，而不是秒的级别。 这是我讲的所有的内容，非常感谢大家听我罗嗦这么
半天，谢谢。 |
l*****t
发帖数: 2019 | 2 nothing new here.
swing to Hbase sounds like a bad idea.
【在 g*****g 的大作中提到】
: http://tech.huanqiu.com/per/2013-08/4307208_2.html
: 我们作为创业公司总结了一些经验和教训跟大家分享一下：
: 1、保持简单，这对创业公司来讲非常重要，一个简单的系统出错的可能性就很小
: ，出错以后解决问题的可能性就变得很大。保持简单我们认为对创业公司来说是非常关
: 键的问题。
: 2、我们认为一项技术的超级用户遇到的难度是远远大于普通用户的。我们知道大
: 家今天都在用一些开元软件，这些开元软件是逐步发展的过程，很多软件在早期并没有
: 经历过很大的压力测试，在一定的流量基础上他们都工作的非常少，但是超过一定流量
: 的话都有各种各样的问题。如果你作为超级用户，你可能接触到的问题是前人完全没有
: 遇到的，你很难在社区里得到任何求助，需要自己读它的代码，去看是不是我能解决，
|
g*****g
发帖数: 34805 | 3 Playing safe is more practical than being new and cool. Chosen stack can be
a hit and miss. It may not always be the best pick, just the one they happen
to have the most experience.
【在 l*****t 的大作中提到】
: nothing new here.
: swing to Hbase sounds like a bad idea.
|
c***d
发帖数: 996 | 4 有一句很有用， 现在的消费互联网公司其实都是在卖产品， 不是在卖技术。 这个角
度来讲互联网公司更接近nike, 而不是波音或者洛克希德马丁。那个姓王的在google没
搞懂的也是这个。
所谓的高科技公司是在一个新的平台上卖产品， 这个平台本身的科技含量比较高， 但
这个平台本身并不成为最大的利润机器。 要我说摩托罗拉诺基亚的技术含量比
facebook高，用户和市场的问题没有解决就什么都不是。
【在 g*****g 的大作中提到】
: http://tech.huanqiu.com/per/2013-08/4307208_2.html
: 我们作为创业公司总结了一些经验和教训跟大家分享一下：
: 1、保持简单，这对创业公司来讲非常重要，一个简单的系统出错的可能性就很小
: ，出错以后解决问题的可能性就变得很大。保持简单我们认为对创业公司来说是非常关
: 键的问题。
: 2、我们认为一项技术的超级用户遇到的难度是远远大于普通用户的。我们知道大
: 家今天都在用一些开元软件，这些开元软件是逐步发展的过程，很多软件在早期并没有
: 经历过很大的压力测试，在一定的流量基础上他们都工作的非常少，但是超过一定流量
: 的话都有各种各样的问题。如果你作为超级用户，你可能接触到的问题是前人完全没有
: 遇到的，你很难在社区里得到任何求助，需要自己读它的代码，去看是不是我能解决，
|
b*******s
发帖数: 5216 | |
g*********e
发帖数: 14401 | 6 这样挺好，最后不会遇到瓶颈把自己给做死了。当然门槛低，竞争也激烈。
【在 c***d 的大作中提到】
: 有一句很有用， 现在的消费互联网公司其实都是在卖产品， 不是在卖技术。 这个角
: 度来讲互联网公司更接近nike, 而不是波音或者洛克希德马丁。那个姓王的在google没
: 搞懂的也是这个。
: 所谓的高科技公司是在一个新的平台上卖产品， 这个平台本身的科技含量比较高， 但
: 这个平台本身并不成为最大的利润机器。 要我说摩托罗拉诺基亚的技术含量比
: facebook高，用户和市场的问题没有解决就什么都不是。
|
p*****2
发帖数: 21240 | 7 这个主要原因作者也提到了 就是前google员工的原因 包括java
所以他们并没有客观比较各种技术
当然python恶心不假
【在 l*****t 的大作中提到】
: nothing new here.
: swing to Hbase sounds like a bad idea.
|
p*****2
发帖数: 21240 | 8 公司那么有钱搞点cool技术没啥问题 比如twitter的scala facebook硬搞php也没问题
你们公司搞cassandra 都是先驱
p这点做的保守了 不知道为什么压力这么大
be
happen
【在 g*****g 的大作中提到】
: Playing safe is more practical than being new and cool. Chosen stack can be
: a hit and miss. It may not always be the best pick, just the one they happen
: to have the most experience.
|
g*****g
发帖数: 34805 | 9 pinterest太小，Twitter硬搞ruby效果有限，才换的scala. SOA一点点用 Java换出去
，是经过无数次实践最可靠的办法，轮子也多。要想酷大可开源自己开发的一些类库，
没必要死拧语言。
题
【在 p*****2 的大作中提到】
: 公司那么有钱搞点cool技术没啥问题 比如twitter的scala facebook硬搞php也没问题
: 你们公司搞cassandra 都是先驱
: p这点做的保守了 不知道为什么压力这么大
:
: be
: happen
|
p*****2
发帖数: 21240 | 10 应该是小
其实上边python 下边c++是可以玩的
不知道为什么没有提
里边也许有政治因素
【在 g*****g 的大作中提到】
: pinterest太小，Twitter硬搞ruby效果有限，才换的scala. SOA一点点用 Java换出去
: ，是经过无数次实践最可靠的办法，轮子也多。要想酷大可开源自己开发的一些类库，
: 没必要死拧语言。
:
: 题
|
|
|
g*****g
发帖数: 34805 | 11 不是说了为啥不用C, Python底下加C用来写轮子也罢，写商业逻辑得把自己坑死。
C++也是一样的。
【在 p*****2 的大作中提到】
: 应该是小
: 其实上边python 下边c++是可以玩的
: 不知道为什么没有提
: 里边也许有政治因素
|
g*****g
发帖数: 34805 | 12 啥东西不都一样，能造个飞机飞起来的国家多了去了。能造了到处卖的就少了。
【在 c***d 的大作中提到】
: 有一句很有用， 现在的消费互联网公司其实都是在卖产品， 不是在卖技术。 这个角
: 度来讲互联网公司更接近nike, 而不是波音或者洛克希德马丁。那个姓王的在google没
: 搞懂的也是这个。
: 所谓的高科技公司是在一个新的平台上卖产品， 这个平台本身的科技含量比较高， 但
: 这个平台本身并不成为最大的利润机器。 要我说摩托罗拉诺基亚的技术含量比
: facebook高，用户和市场的问题没有解决就什么都不是。
|
z****e
发帖数: 54598 | 13 用c这些语言主要是换个平台就要重新编译一遍
现在又不象以前，windows一统天下
现在macosx，linux什么满天飞，前一段每次重编译python的类库都在祈祷
千万别出问题，不是自己写的类库，出了问题我可没把握在短时间搞定
【在 g*****g 的大作中提到】
: 不是说了为啥不用C, Python底下加C用来写轮子也罢，写商业逻辑得把自己坑死。
: C++也是一样的。
|
s********k
发帖数: 6180 | 14 所以大家觉得做技术的人怎么打造自己的核心竞争力？一直在某个技术领域继续专研，
还是慢慢多接触产品市场等等
【在 c***d 的大作中提到】
: 有一句很有用， 现在的消费互联网公司其实都是在卖产品， 不是在卖技术。 这个角
: 度来讲互联网公司更接近nike, 而不是波音或者洛克希德马丁。那个姓王的在google没
: 搞懂的也是这个。
: 所谓的高科技公司是在一个新的平台上卖产品， 这个平台本身的科技含量比较高， 但
: 这个平台本身并不成为最大的利润机器。 要我说摩托罗拉诺基亚的技术含量比
: facebook高，用户和市场的问题没有解决就什么都不是。
|
p*****2
发帖数: 21240 | 15
看来公孙不靠谱呀。
另外Go也需要在不同平台编译吧，是不是也是一个大缺陷？
【在 z****e 的大作中提到】
: 用c这些语言主要是换个平台就要重新编译一遍
: 现在又不象以前，windows一统天下
: 现在macosx，linux什么满天飞，前一段每次重编译python的类库都在祈祷
: 千万别出问题，不是自己写的类库，出了问题我可没把握在短时间搞定
|
z****e
发帖数: 54598 | 16 python的类库很多是c，fortran写的
主要是这些库出问题
【在 p*****2 的大作中提到】
:
: 看来公孙不靠谱呀。
: 另外Go也需要在不同平台编译吧，是不是也是一个大缺陷？
|
d****i
发帖数: 4809 | 17 Python写商业逻辑都用不着C，如果要用到C/C++的话，一般都是因为有大量的计算或者
需要直接和OS层面talk。我们的Java也是这样用的。
【在 g*****g 的大作中提到】
: 不是说了为啥不用C, Python底下加C用来写轮子也罢，写商业逻辑得把自己坑死。
: C++也是一样的。
|
M****z
发帖数: 1058 | |
s********k
发帖数: 6180 | 19 这个50万不是腾讯当年叫卖的价钱吗？或者100万？
【在 M****z 的大作中提到】
: P当年好像是50万美元叫卖都没人买
|
h*****a
发帖数: 1718 | 20 技术不重要啊，产品重要，尤其对这种级别的startup而言。搞新技术，除非有特别熟
悉这个技术的一班人马，你怎么去justify呢？
题
【在 p*****2 的大作中提到】
: 公司那么有钱搞点cool技术没啥问题 比如twitter的scala facebook硬搞php也没问题
: 你们公司搞cassandra 都是先驱
: p这点做的保守了 不知道为什么压力这么大
:
: be
: happen
|
|
|
h*****a
发帖数: 1718 | 21 对，关键是growth和monetization，技术的选择不是考虑的关键。确实P的tech stack
里面的一些选择比较random，一个主要的原因是早期开发者对什么技术比较熟悉能尽快
上手。以后不够ideal的选择会慢慢被替换掉，但绝对不是high priority的工作。
【在 g*****g 的大作中提到】
: pinterest太小，Twitter硬搞ruby效果有限，才换的scala. SOA一点点用 Java换出去
: ，是经过无数次实践最可靠的办法，轮子也多。要想酷大可开源自己开发的一些类库，
: 没必要死拧语言。
:
: 题
|
h*****a
发帖数: 1718 | 22 等到会C++的engineers加入的时候，网站都已经几个米的用户了。那时候大家忙着做的
就是怎么样让网站稳定，做新feature，转C++根本没有资源去搞。
【在 p*****2 的大作中提到】
: 应该是小
: 其实上边python 下边c++是可以玩的
: 不知道为什么没有提
: 里边也许有政治因素
|
p*****2
发帖数: 21240 | 23
当时已经转Java了吗。我的理解是下边的核心代码用C++，上边还是python. 不知道这
个和完全转java哪个cost高。当然转java也可以一个service的转。long term的话，比
上C＋＋更靠谱。
【在 h*****a 的大作中提到】
: 等到会C++的engineers加入的时候，网站都已经几个米的用户了。那时候大家忙着做的
: 就是怎么样让网站稳定，做新feature，转C++根本没有资源去搞。
|
h*****a
发帖数: 1718 | 24 转Java主要是move到SOA的一部分。本来performance即使到现在也不是主要的问题。
【在 p*****2 的大作中提到】
:
: 当时已经转Java了吗。我的理解是下边的核心代码用C++，上边还是python. 不知道这
: 个和完全转java哪个cost高。当然转java也可以一个service的转。long term的话，比
: 上C＋＋更靠谱。
|
p*****2
发帖数: 21240 | 25
python做SOA的主要问题是什么？如果performance可以的呀？还是long term考虑？
【在 h*****a 的大作中提到】
: 转Java主要是move到SOA的一部分。本来performance即使到现在也不是主要的问题。
|
h*****a
发帖数: 1718 | 26 Pinterest到今天最大的codebase也还是Python而且几乎所有engineer都在继续
contribute python code。SOA框架中的新的service，都用Java或者Go来写了，但用其
他语言重写Python code还不是我们目前要做的。目前做到的只是把旧的Python code从
messy的codebase里面分离出来成为一个新的SOA框架中的service的时候，用Java重写
一下，但也不是必须的。只有在分离code的成本比较高的时候才这样做。
Python的perf固然不够理想，但目前来说还不是Pinterest growth或者成功与否的瓶颈
所在。
【在 p*****2 的大作中提到】
:
: python做SOA的主要问题是什么？如果performance可以的呀？还是long term考虑？
|
h*****a
发帖数: 1718 | 27 Python做SOA也没什么问题。你看我另一个帖子，基本上算回答了。用Java肯定一个考
虑是会的人比较多，而且perf比Python要好一些。
【在 p*****2 的大作中提到】
:
: python做SOA的主要问题是什么？如果performance可以的呀？还是long term考虑？
|
c***d
发帖数: 996 | 28 我的心得是技术不是钻研出来的， 是用出来的。 能解决问题的技术就是好技术。 产
品和市场也不是慢慢接触出来的， 互联网市场能看到的规律就是长江后浪推前浪， 乱
拳打死老师傅。干这行就是糙快猛， 执行能力第一。
【在 s********k 的大作中提到】
: 所以大家觉得做技术的人怎么打造自己的核心竞争力？一直在某个技术领域继续专研，
: 还是慢慢多接触产品市场等等
|
h*****a
发帖数: 1718 | 29 同意。如果解决的问题是比较hot的问题，具体的技术有的时候是次要一些的。当然技
术也有价值，不过一般来说招人的时候默认你能pick up一个新的程序语言或者数据库
。而且现在的市场条件下，找到一个工作经验和skill set非常match的人太困难了。
【在 c***d 的大作中提到】
: 我的心得是技术不是钻研出来的， 是用出来的。 能解决问题的技术就是好技术。 产
: 品和市场也不是慢慢接触出来的， 互联网市场能看到的规律就是长江后浪推前浪， 乱
: 拳打死老师傅。干这行就是糙快猛， 执行能力第一。
|
p*****2
发帖数: 21240 | 30
明白。多谢大牛。
【在 h*****a 的大作中提到】
: Pinterest到今天最大的codebase也还是Python而且几乎所有engineer都在继续
: contribute python code。SOA框架中的新的service，都用Java或者Go来写了，但用其
: 他语言重写Python code还不是我们目前要做的。目前做到的只是把旧的Python code从
: messy的codebase里面分离出来成为一个新的SOA框架中的service的时候，用Java重写
: 一下，但也不是必须的。只有在分离code的成本比较高的时候才这样做。
: Python的perf固然不够理想，但目前来说还不是Pinterest growth或者成功与否的瓶颈
: 所在。
|
|
|
l*****t
发帖数: 2019 | 31 true. I am saying "nothing new here", what Pinterest has done is like a
million companies have done. nothing to learn from them. we did the same
thing 3 years ago when we started our stuff nobody knew these things and
picked up hbase and made it work. but now have to literate to redo it to
something from scratch.
kinda like your company's recent work on Kafka, which was pretty late too.
should have done right from the getgo.
just a price to being safe.
be
happen
【在 g*****g 的大作中提到】
: Playing safe is more practical than being new and cool. Chosen stack can be
: a hit and miss. It may not always be the best pick, just the one they happen
: to have the most experience.
|
l*****t
发帖数: 2019 | 32 because of googler?
same thing happened in Facebook when Googlers drove away the amazon folks.
题
【在 p*****2 的大作中提到】
: 公司那么有钱搞点cool技术没啥问题 比如twitter的scala facebook硬搞php也没问题
: 你们公司搞cassandra 都是先驱
: p这点做的保守了 不知道为什么压力这么大
:
: be
: happen
|
l*****t
发帖数: 2019 | 33 对呀。所以p的经历没啥好学的。
stack
【在 h*****a 的大作中提到】
: 对，关键是growth和monetization，技术的选择不是考虑的关键。确实P的tech stack
: 里面的一些选择比较random，一个主要的原因是早期开发者对什么技术比较熟悉能尽快
: 上手。以后不够ideal的选择会慢慢被替换掉，但绝对不是high priority的工作。
|
g*****g
发帖数: 34805 | 34 We couldn't do it from get-go, and you can see the reason here.
https://github.com/Netflix/suro/wiki/FAQ#why-not-use-kafka-directly
【在 l*****t 的大作中提到】
: true. I am saying "nothing new here", what Pinterest has done is like a
: million companies have done. nothing to learn from them. we did the same
: thing 3 years ago when we started our stuff nobody knew these things and
: picked up hbase and made it work. but now have to literate to redo it to
: something from scratch.
: kinda like your company's recent work on Kafka, which was pretty late too.
: should have done right from the getgo.
: just a price to being safe.
:
: be
|
p*****2
发帖数: 21240 | 35
我觉得是。我们公司很多A过来的，只用Java。
还有一个postgres大牛过来不让用mongo，cassandra。
【在 l*****t 的大作中提到】
: because of googler?
: same thing happened in Facebook when Googlers drove away the amazon folks.
:
: 题
|
h*****a
发帖数: 1718 | 36 P的模式基本上就是湾区startup的常态。对没在startup干过的可能有点启发，否则一
般都知道了。
【在 l*****t 的大作中提到】
: 对呀。所以p的经历没啥好学的。
:
: stack
|
V*********r
发帖数: 666 | 37
不光python，所有的动态语言比如ruby和javascript都一样，编译C扩展是不可避免的
node.js和rails也是一大堆类库都是C语言写的，每次跑都要重新编译
不知道你为什么老是抱怨这个，好像脱离了jvm就难以生存一样
【在 z****e 的大作中提到】
: 用c这些语言主要是换个平台就要重新编译一遍
: 现在又不象以前，windows一统天下
: 现在macosx，linux什么满天飞，前一段每次重编译python的类库都在祈祷
: 千万别出问题，不是自己写的类库，出了问题我可没把握在短时间搞定
|
r***s
发帖数: 737 | 38 it depends.
as a startup, the business goal itself is risky. thus it make sense to
minimize
risk in other aspects.
for mature companies, always playing safe means no life.
Risk taking does not mean being new and cool, chasing the trend for the sake
of it is simply stupid. Risk taking means drastic changes to either business
model or technology stack, for the purpose of disrupting the market, improve
efficiency or reduce cost. Efforts put in for trying to reach these goals
may
not always pay off, as you are probably the first one who tries to do it,
and
you may fail.
but if you don't actively seek out changes, changes will be imposed on you
in a bad way.
be
happen
【在 g*****g 的大作中提到】
: Playing safe is more practical than being new and cool. Chosen stack can be
: a hit and miss. It may not always be the best pick, just the one they happen
: to have the most experience.
|
r***s
发帖数: 737 | 39 open your eyes, see the "business purpose" of everything
learn to perform cost effective calculation and trade off.
【在 s********k 的大作中提到】
: 所以大家觉得做技术的人怎么打造自己的核心竞争力？一直在某个技术领域继续专研，
: 还是慢慢多接触产品市场等等
|
y**********u
发帖数: 6366 | 40 弯曲大部分startup都没有P的scale啊，所以P这样算是很难的
【在 h*****a 的大作中提到】
: P的模式基本上就是湾区startup的常态。对没在startup干过的可能有点启发，否则一
: 般都知道了。
|
|
|
z****e
发帖数: 54598 | 41 可以活，活得很苦逼
做分布式，平台碎片化是其主要的特征
不比做hpc，mainframe那些，机器就那么几台
而且高度同质化，伺候好就好了
【在 V*********r 的大作中提到】
:
: 不光python，所有的动态语言比如ruby和javascript都一样，编译C扩展是不可避免的
: node.js和rails也是一大堆类库都是C语言写的，每次跑都要重新编译
: 不知道你为什么老是抱怨这个，好像脱离了jvm就难以生存一样
|
ET
发帖数: 10701 | 42 不能说没啥好学的。
下次你领军时，因为business scale需要上新技术时，你可以把P的故事讲给你下面人
听。
growing pain. it is how it is.
【在 l*****t 的大作中提到】
: 对呀。所以p的经历没啥好学的。
:
: stack
|
ET
发帖数: 10701 | 43 exactly.
【在 y**********u 的大作中提到】
: 弯曲大部分startup都没有P的scale啊，所以P这样算是很难的
|
p*****2
发帖数: 21240 | 44 这样看来foursquare还是值得尊重的呀
毕竟敢于大胆尝试
【在 h*****a 的大作中提到】
: P的模式基本上就是湾区startup的常态。对没在startup干过的可能有点启发，否则一
: 般都知道了。
|
g*****g
发帖数: 34805 | 45 Startup有两种，做产品的和做轮子的。前者颠覆性的是产品，后者颠覆性的是轮子。P
显然属于前者，你把两者混淆了。
做产品的Startup做出颠覆性轮子是极其罕见的，没那个人力物力，利用现有轮子快速
实现产品才是王道。做轮子的绝大多数是大公司养了几个闲人，折腾出个轮子反响不错
拉出来单开个公司。诸如Hadoop, Cassandra都是如此。
sake
business
improve
【在 r***s 的大作中提到】
: it depends.
: as a startup, the business goal itself is risky. thus it make sense to
: minimize
: risk in other aspects.
: for mature companies, always playing safe means no life.
: Risk taking does not mean being new and cool, chasing the trend for the sake
: of it is simply stupid. Risk taking means drastic changes to either business
: model or technology stack, for the purpose of disrupting the market, improve
: efficiency or reduce cost. Efforts put in for trying to reach these goals
: may
|
z****e
发帖数: 54598 | 46 做颠覆性轮子需要跟上潮流
做os，db那是大门时代的技术创业
等00年之后，那都是jboss,bea这种搞ejb的创业
前几年是做nosql的创业
现在风潮都涌向了ml了
时代一过，要想再搞啥技术创业，都没戏了
象现在搞啥ejb或者db创业，肯定被拍死，因为开源太剽悍了
。P
【在 g*****g 的大作中提到】
: Startup有两种，做产品的和做轮子的。前者颠覆性的是产品，后者颠覆性的是轮子。P
: 显然属于前者，你把两者混淆了。
: 做产品的Startup做出颠覆性轮子是极其罕见的，没那个人力物力，利用现有轮子快速
: 实现产品才是王道。做轮子的绝大多数是大公司养了几个闲人，折腾出个轮子反响不错
: 拉出来单开个公司。诸如Hadoop, Cassandra都是如此。
:
: sake
: business
: improve
|
p*****2
发帖数: 21240 | 47 做轮子的startup也不少吧
。P
【在 g*****g 的大作中提到】
: Startup有两种，做产品的和做轮子的。前者颠覆性的是产品，后者颠覆性的是轮子。P
: 显然属于前者，你把两者混淆了。
: 做产品的Startup做出颠覆性轮子是极其罕见的，没那个人力物力，利用现有轮子快速
: 实现产品才是王道。做轮子的绝大多数是大公司养了几个闲人，折腾出个轮子反响不错
: 拉出来单开个公司。诸如Hadoop, Cassandra都是如此。
:
: sake
: business
: improve
|
ET
发帖数: 10701 | 48 当然不少。但显然比consumer product受到的关注程度低。
退出大多都是悄无声息的就被买了。
【在 p*****2 的大作中提到】
: 做轮子的startup也不少吧
:
: 。P
|
p*****2
发帖数: 21240 | 49 consumer 成功的也是极少数呀
感觉都很难 但是牛人搞一般都不差 总能掀起点风浪
【在 ET 的大作中提到】
: 当然不少。但显然比consumer product受到的关注程度低。
: 退出大多都是悄无声息的就被买了。
|
M****z
发帖数: 1058 | 50 好像还专门跑到扭腰去卖，没卖出去
【在 s********k 的大作中提到】
: 这个50万不是腾讯当年叫卖的价钱吗？或者100万？
|
|
|
M****z
发帖数: 1058 | 51 consumer web早就过了黄金进入窗口了 |
l*****t
发帖数: 2019 | 52 Thanks. good blog. very classic.
Won't blame Netflix. LinkedIn itself had big problem migrating from 0.7 to 0
.8, almost same issue.
Many orgs chose not to face the same issue how to rollout something
horizontally without nontrivial effort from each stack. Luckily we don't
have this problem. Both 0.7 project and 0.8 migration happening smoothly
without much work from the dec teams, almost completely done by a 2-person
team.
【在 g*****g 的大作中提到】
: We couldn't do it from get-go, and you can see the reason here.
: https://github.com/Netflix/suro/wiki/FAQ#why-not-use-kafka-directly
|
l*****t
发帖数: 2019 | 53 还好吧。P刚起来的scale 有没有50人的WhatsApp大？
【在 y**********u 的大作中提到】
: 弯曲大部分startup都没有P的scale啊，所以P这样算是很难的
|
l*****t
发帖数: 2019 | 54 尼玛，HPC你也做过呀。你搞得东西真杂呀。
【在 z****e 的大作中提到】
: 可以活，活得很苦逼
: 做分布式，平台碎片化是其主要的特征
: 不比做hpc，mainframe那些，机器就那么几台
: 而且高度同质化，伺候好就好了
|
l*****t
发帖数: 2019 | 55 I have done more than talking about stories like P. :)
【在 ET 的大作中提到】
: 不能说没啥好学的。
: 下次你领军时，因为business scale需要上新技术时，你可以把P的故事讲给你下面人
: 听。
: growing pain. it is how it is.
|
l*****t
发帖数: 2019 | 56 yeah, 4square has some guts migrating onto Kafka in late 2012 or something,
kinda like those people who adopted Spark in 2012, when everyone was against
it.
【在 p*****2 的大作中提到】
: 这样看来foursquare还是值得尊重的呀
: 毕竟敢于大胆尝试
|
d********f
发帖数: 43471 | 57 鼠标程序员的确离开了jvm很难生存
【在 V*********r 的大作中提到】
:
: 不光python，所有的动态语言比如ruby和javascript都一样，编译C扩展是不可避免的
: node.js和rails也是一大堆类库都是C语言写的，每次跑都要重新编译
: 不知道你为什么老是抱怨这个，好像脱离了jvm就难以生存一样
|
h*****a
发帖数: 1718 | 58 好像他们也不太行了吧。当然行不行不一定是技术的原因，但startup第一要务是生存
，第二要务是grow，技术只是辅助手段罢了。尝试新技术如果带来比较大的风险，那还
是谨慎一点好。
【在 p*****2 的大作中提到】
: 这样看来foursquare还是值得尊重的呀
: 毕竟敢于大胆尝试
|
l*****t
发帖数: 2019 | 59 除了 system 的 startup 比如当年的 cloudera, datastax现在的databricks，大部分
startup借用你的讲法都是做产品的。
但是这不是不做不做轮子的问题，而是采购轮子的问题。很多startup包括established
都不愿意做研究工作、几个好的poc和pilot，就根据自己的经验和接受能力去定去上马
了。问题是现在新轮子出的挺快的，不改变culture不行了。不是10年前，说一句it's
not about the technology it's about good people making it work的时代了。
。P
【在 g*****g 的大作中提到】
: Startup有两种，做产品的和做轮子的。前者颠覆性的是产品，后者颠覆性的是轮子。P
: 显然属于前者，你把两者混淆了。
: 做产品的Startup做出颠覆性轮子是极其罕见的，没那个人力物力，利用现有轮子快速
: 实现产品才是王道。做轮子的绝大多数是大公司养了几个闲人，折腾出个轮子反响不错
: 拉出来单开个公司。诸如Hadoop, Cassandra都是如此。
:
: sake
: business
: improve
|
l*****t
发帖数: 2019 | 60 所以造就了几个了轮子公司的伟大。
的确，做轮子太难了。
【在 z****e 的大作中提到】
: 做颠覆性轮子需要跟上潮流
: 做os，db那是大门时代的技术创业
: 等00年之后，那都是jboss,bea这种搞ejb的创业
: 前几年是做nosql的创业
: 现在风潮都涌向了ml了
: 时代一过，要想再搞啥技术创业，都没戏了
: 象现在搞啥ejb或者db创业，肯定被拍死，因为开源太剽悍了
:
: 。P
|
|
|
l*****t
发帖数: 2019 | 61 比轮子成功得多多了吧。
【在 p*****2 的大作中提到】
: consumer 成功的也是极少数呀
: 感觉都很难 但是牛人搞一般都不差 总能掀起点风浪
|
l*****t
发帖数: 2019 | 62 是呀，business的人才和能力，比技术人才重要多了。但是我们技术人员也是吃皇粮的
，也得好好尽忠职守呀。
【在 h*****a 的大作中提到】
: 好像他们也不太行了吧。当然行不行不一定是技术的原因，但startup第一要务是生存
: ，第二要务是grow，技术只是辅助手段罢了。尝试新技术如果带来比较大的风险，那还
: 是谨慎一点好。
|
p*****2
发帖数: 21240 | 63
这个同意。不过正像consumer追求流行一样，developer也会追求新技术。这个就是爱
好，跟打游戏差不多。当然对于企业来说未必是好事。不过新技术很多时候也确实能更
容易解决问题。不然也不会技术的淘汰节奏这么快了。我们应该都经历了几次更新换代
了。
【在 h*****a 的大作中提到】
: 好像他们也不太行了吧。当然行不行不一定是技术的原因，但startup第一要务是生存
: ，第二要务是grow，技术只是辅助手段罢了。尝试新技术如果带来比较大的风险，那还
: 是谨慎一点好。
|
p*****2
发帖数: 21240 | 64
很多轮子都卖了呀？也不能说不成功。
【在 l*****t 的大作中提到】
: 比轮子成功得多多了吧。
|
h*****a
发帖数: 1718 | 65 这点没有问题。P用的zookeeper, Hbase, Kafka, Storm，Go，Thrift, Finagle等等也
都是新技术。不过是不是新技术刚一发布就要用我觉得不一定。
一般来说用新技术要有几个条件，一是确实有相应的需求能用新技术更好解决，二是要
有人能尽快上手。三是从现有stack migrate过去的成本不高。一更是必要条件。
【在 p*****2 的大作中提到】
:
: 很多轮子都卖了呀？也不能说不成功。
|
p*****2
发帖数: 21240 | 66
同意。所以有人说现在搞spark已经很晚了，我不信。
一般要经过一段时间的experiment，先做一些小东西，慢慢觉得可以了，就可以更大规
模应用。很多时候experiment了之后也未必要用。
【在 h*****a 的大作中提到】
: 这点没有问题。P用的zookeeper, Hbase, Kafka, Storm，Go，Thrift, Finagle等等也
: 都是新技术。不过是不是新技术刚一发布就要用我觉得不一定。
: 一般来说用新技术要有几个条件，一是确实有相应的需求能用新技术更好解决，二是要
: 有人能尽快上手。三是从现有stack migrate过去的成本不高。一更是必要条件。
|
h*****a
发帖数: 1718 | 67 好啊，你有什么经验可以到时候share一下，我们也在考虑要用spark。
【在 p*****2 的大作中提到】
:
: 同意。所以有人说现在搞spark已经很晚了，我不信。
: 一般要经过一段时间的experiment，先做一些小东西，慢慢觉得可以了，就可以更大规
: 模应用。很多时候experiment了之后也未必要用。
|
p*****2
发帖数: 21240 | 68
太好了。回头好好聊聊。
【在 h*****a 的大作中提到】
: 好啊，你有什么经验可以到时候share一下，我们也在考虑要用spark。
|
w**z
发帖数: 8232 | 69 thrift 还是别碰为好。
【在 h*****a 的大作中提到】
: 这点没有问题。P用的zookeeper, Hbase, Kafka, Storm，Go，Thrift, Finagle等等也
: 都是新技术。不过是不是新技术刚一发布就要用我觉得不一定。
: 一般来说用新技术要有几个条件，一是确实有相应的需求能用新技术更好解决，二是要
: 有人能尽快上手。三是从现有stack migrate过去的成本不高。一更是必要条件。
|
p*****2
发帖数: 21240 | 70
确实好多人complain过。不过有啥好替代品吗？
【在 w**z 的大作中提到】
: thrift 还是别碰为好。
|
|
|
z****e
发帖数: 54598 | 71 对呀对呀
我们用的都是破铜烂铁
不象你们有hpc的consultants可以用
我们都是自己动手，苦逼呀
【在 d********f 的大作中提到】
: 鼠标程序员的确离开了jvm很难生存
|
z****e
发帖数: 54598 | 72 隔壁组，隔壁组
读书时候，搞hpc的computing跟我们是一个dept的
工作时候，搞mainframe的组跟我们也是一个dept的
对于这种高大上的东西，我对它们的了解停留在看猪跑的阶段
没怎么吃过猪肉
【在 l*****t 的大作中提到】
: 尼玛，HPC你也做过呀。你搞得东西真杂呀。
|
z****e
发帖数: 54598 | 73 soa/ws/rest
【在 p*****2 的大作中提到】
:
: 确实好多人complain过。不过有啥好替代品吗？
|
z****e
发帖数: 54598 | 74 就是corba的借尸还魂
【在 w**z 的大作中提到】
: thrift 还是别碰为好。
|
p*****2
发帖数: 21240 | 75
我的理解是thrift的性能比rest强。不过我也没用过，不知道差多少
【在 z****e 的大作中提到】
: soa/ws/rest
|
z****e
发帖数: 54598 | 76 难不成数据结构你不用json了？
用json才是主流吧
rest用http协议，不过改成tcp/ip或者udp/ip也不难
vert.x对于主流的网络协议都有现成的例子可以直接抄
剩下的没有啥可优化的，网络协议不可能再简单了
总不能ip都不用吧
【在 p*****2 的大作中提到】
:
: 我的理解是thrift的性能比rest强。不过我也没用过，不知道差多少
|
ET
发帖数: 10701 | 77 成功就是massive。
就概率而言，当然还是B2B成功性更大些。
【在 p*****2 的大作中提到】
: consumer 成功的也是极少数呀
: 感觉都很难 但是牛人搞一般都不差 总能掀起点风浪
|
ET
发帖数: 10701 | 78 看看square， 出了多少open source 的库！
我觉得这公司显然有很多天才，现在就是不知道公司的方向何在。
【在 p*****2 的大作中提到】
:
: 我的理解是thrift的性能比rest强。不过我也没用过，不知道差多少
|
h*****a
发帖数: 1718 | 79 我们这边T过来的人不少，Thrift也已经用了很久了。你觉得Thrift有什么地方不好吗？
【在 w**z 的大作中提到】
: thrift 还是别碰为好。
|
h*****a
发帖数: 1718 | 80 看你传输的data的情况吧，binary v.s. txt, rpc v.s. http I think.
【在 p*****2 的大作中提到】
:
: 我的理解是thrift的性能比rest强。不过我也没用过，不知道差多少
|
|
|
w**z
发帖数: 8232 | 81 总的来说，Thrift 这个project 已经没有多少新的development 了， 还在0.9.1， 已
经一年没有新的release了。 用起来真的很不方便。每次改点东西server， client 都
要改。还有个问题，不同的软件 需要不同版本的thrift， 就惨了。我们 scribe 用
的thrift 版本和 C* 用的thrift 版本不一样，无解啊。
吗？
【在 h*****a 的大作中提到】
: 我们这边T过来的人不少，Thrift也已经用了很久了。你觉得Thrift有什么地方不好吗？
|
p***o
发帖数: 1252 | 82 这以后会影响到C*吗?
【在 w**z 的大作中提到】
: 总的来说，Thrift 这个project 已经没有多少新的development 了， 还在0.9.1， 已
: 经一年没有新的release了。 用起来真的很不方便。每次改点东西server， client 都
: 要改。还有个问题，不同的软件 需要不同版本的thrift， 就惨了。我们 scribe 用
: 的thrift 版本和 C* 用的thrift 版本不一样，无解啊。
:
: 吗？
|
w**z
发帖数: 8232 | 83 他们后来加了native protocol可以不用thrift.
【在 p***o 的大作中提到】
: 这以后会影响到C*吗?
|
h*****a
发帖数: 1718 | 84 确实，你说的问题我们也有。目前code generation和version不兼容确实有些头疼。不
过暂时也只能这样。那你们有什么更好的solution?
【在 w**z 的大作中提到】
: 总的来说，Thrift 这个project 已经没有多少新的development 了， 还在0.9.1， 已
: 经一年没有新的release了。 用起来真的很不方便。每次改点东西server， client 都
: 要改。还有个问题，不同的软件 需要不同版本的thrift， 就惨了。我们 scribe 用
: 的thrift 版本和 C* 用的thrift 版本不一样，无解啊。
:
: 吗？
|
w**z
发帖数: 8232 | 85 新项目都上rest 了，或者rabbit mq, 老的就那么的了。
【在 h*****a 的大作中提到】
: 确实，你说的问题我们也有。目前code generation和version不兼容确实有些头疼。不
: 过暂时也只能这样。那你们有什么更好的solution?
|
P****i
发帖数: 12972 | 86 这一点PB，Json比较好
【在 w**z 的大作中提到】
: 总的来说，Thrift 这个project 已经没有多少新的development 了， 还在0.9.1， 已
: 经一年没有新的release了。 用起来真的很不方便。每次改点东西server， client 都
: 要改。还有个问题，不同的软件 需要不同版本的thrift， 就惨了。我们 scribe 用
: 的thrift 版本和 C* 用的thrift 版本不一样，无解啊。
:
: 吗？
|
w**z
发帖数: 8232 | 87 pb 好像也要compile 吧， 还是走HTTP 好。
【在 P****i 的大作中提到】
: 这一点PB，Json比较好
|
g*****g
发帖数: 34805 | 88 这种追求性能的数据库，binary protocol是必须有的。
【在 w**z 的大作中提到】
: 他们后来加了native protocol可以不用thrift.
|
y**********u
发帖数: 6366 | 89 http 和 rpc有什么区别呢？
还有很多时候读写数据库，用haproxy，性能和rest有什么大区别呢？
【在 w**z 的大作中提到】
: pb 好像也要compile 吧， 还是走HTTP 好。
|
w**z
发帖数: 8232 | 90 http 当然会有一些overhead， 但是一般的应用，应该不会对响应时间有那么高的要求。
【在 y**********u 的大作中提到】
: http 和 rpc有什么区别呢？
: 还有很多时候读写数据库，用haproxy，性能和rest有什么大区别呢？
|
|
|
y**********u
发帖数: 6366 | 91 这几天最大的问题是batch写mysql经常会IO bound，和http基本上关系不大，但是可惜
优化的空间似乎也不大了，除了sharding
求。
【在 w**z 的大作中提到】
: http 当然会有一些overhead， 但是一般的应用，应该不会对响应时间有那么高的要求。
|
w**z
发帖数: 8232 | 92 读还是写？
【在 y**********u 的大作中提到】
: 这几天最大的问题是batch写mysql经常会IO bound，和http基本上关系不大，但是可惜
: 优化的空间似乎也不大了，除了sharding
:
: 求。
|
y**********u
发帖数: 6366 | 93 写
可惜
【在 w**z 的大作中提到】
: 读还是写？
|
l*****t
发帖数: 2019 | 94 是不是都是Facebook用thrift？其他公司用avro或pb？
【在 w**z 的大作中提到】
: 总的来说，Thrift 这个project 已经没有多少新的development 了， 还在0.9.1， 已
: 经一年没有新的release了。 用起来真的很不方便。每次改点东西server， client 都
: 要改。还有个问题，不同的软件 需要不同版本的thrift， 就惨了。我们 scribe 用
: 的thrift 版本和 C* 用的thrift 版本不一样，无解啊。
:
: 吗？
|
s**********k
发帖数: 88 | 95 我感觉Facebook出的东西远没有Google等的solid.Facebook喜欢在别人的轮子上稍微改
吧改吧就丢出来。
像RocksDB是从google的LevelDB改了点东西丢出来的，很多小bug，甚至编译都要出问
题。
Thrift是从PB得到启发搞出来的。
把Memcached修了修
把jemalloc修了修
......
【在 l*****t 的大作中提到】
: 是不是都是Facebook用thrift？其他公司用avro或pb？
|
