|
|
|
|
|
# 076 | 社交公司们的大数据贡献
|
|
|
|
|
|
|
|
|
|
|
|
在Hadoop诞生初期，雅虎扮演了“活雷锋”的角色，几乎凭借一己之力撑起了整个Hadoop系统的发展。2006年雅虎把Hadoop开源以后，其他公司渐渐加入了Hadoop生态圈，其中三大社交公司Facebook、LinkedIn和Twitter的加入，为Hadoop生态圈的繁荣发展做出了巨大贡献。
|
|
|
|
|
|
|
|
|
|
|
|
## 一、Facebook对Hadoop生态圈的贡献
|
|
|
|
|
|
|
|
|
|
|
|
最先加入雅虎Hadoop项目里的是还在创业阶段的Facebook，它从2008年开始在内部使用Hadoop。**因为用MapReduce做数据分析需要写很多C++或者Java程序，这非常不方便，因此Facebook决定做一个叫作SQL on Hadoop的项目，也就是后来鼎鼎大名的Hive。** 这个项目的目标是，要在Hadoop上搭建一个可以用类似SQL进行数据查询、分析的应用。
|
|
|
|
|
|
|
|
|
|
|
|
最开始的时候，Facebook内部专门成立了一个Hive团队，后来团队成员从最初的两个人扩展到六个人。这时，Hive项目只是Facebook一个公司在开发和推广。
|
|
|
|
|
|
|
|
|
|
|
|
Hive的开发风格体现了Facebook的特色：快、糙、猛。Hive开发者的代码写得很快，因此Hive的代码质量是所有开源软件里面相对比较粗糙的：Bug比较多，且维护难度大，但基本上实现了所有必需的功能。如果说在没有遇到Bug且不需要维护的情况下，Hive还是可以凑活着用的。
|
|
|
|
|
|
|
|
|
|
|
|
但Hive后来的发展走向不再是Facebook来主导了，究其原因有以下两个。
|
|
|
|
|
|
|
|
|
|
|
|
1. Facebook不断撤出对Hive的投资。一方面，Hive团队纷纷出走；另一方面，Facebook把开发重心转移向另外一个新的内部工具Presto。Presto后来也被Facebook开源，并被包括Airbnb、美团、京东等诸多企业采用。
|
|
|
|
|
|
这种变化的主要原因是Facebook内部的赛马机制，Presto团队在产品上取得了胜利，从而可以获得越来越多的资源。而Hive团队获得的资源越来越少，无法再支撑其继续发展。
|
|
|
|
|
|
|
|
|
|
|
|
2. Hive是最像SQL语言的，也是最方便的，因此，Hadoop的发行商们纷纷加入Hive项目的开发和维护，这其中对Hive最为青睐的就是Cloudera和从雅虎出来的Hortonworks。所以，2011年以后Hive项目就渐渐地由Facebook主导变成由这两个公司主导了。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
**Facebook的另外一个贡献是，开源了NoSQL数据库项目：Cassandra。** Cassandra项目最初是由Facebook开发的，其实是效仿了亚马逊的Dynamo。但后来Facebook却转投了HBase的怀抱，而任由Cassandra自生自灭。
|
|
|
|
|
|
|
|
|
|
|
|
这个决定是当时Facebook的一位高管做的，具体是哪位高管无从查证，但这个决定背后的动机很明显，因为Facebook觉得谷歌的架构（HBase是谷歌BigTable的山寨版）更可靠，而对亚马逊的架构信心不足。
|
|
|
|
|
|
|
|
|
|
|
|
Cassandra的发展因此出现了一段时间的停滞，直到DataStax接手Cassandra项目。有关Cassandra的故事，我会留到讲DataStax的时候再详细介绍。
|
|
|
|
|
|
|
|
|
|
|
|
而Facebook投奔的HBase，也是Hadoop生态圈非常重要的成员，由已经被微软收购的公司Powerset贡献。HBase的故事，我会留到讲Powerset的时候再详细展开。
|
|
|
|
|
|
|
|
|
|
|
|
## 二、LinkedIn对Hadoop生态圈的贡献
|
|
|
|
|
|
|
|
|
|
|
|
LinkedIn是一家主导社交、求职的媒体公司，也是很早就开始用Hadoop去做内部数据的分析。它早年和Facebook、IBM等公司一起给Hadoop贡献了不少源代码，对Hadoop整个生态圈的发展做出了巨大贡献。
|
|
|
|
|
|
|
|
|
|
|
|
**LinkedIn对Hadoop做出的巨大、原创性的贡献是其开源项目Kafka。** 简单地说，Kafka是一个在不同数据源之间进行数据交换的消息队列的实现。这个项目由LinkedIn首创，是一个目前为止在整个Hadoop生态圈里都无可替代的开源项目。
|
|
|
|
|
|
|
|
|
|
|
|
Kafka诞生的背景是，LinkedIn内部有很多不同的数据源，而且LinkedIn需要在这些数据源之间进行有效的数据整合工作。这个项目被LinkedIn开源后备受关注，LinkedIn也因此获得了很多关注。
|
|
|
|
|
|
|
|
|
|
|
|
创业的诱惑可能是每个成功项目的创始人们都无法拒绝的，Kafka的创始人们也没能免俗。于是在2014年，Kafka的创始人们离开了LinkedIn，并创办了Confluent，致力于Kafka的商业化使用。有关Kafka的详细情况，留待讲Confluent的时候我再详细叙述。
|
|
|
|
|
|
|
|
|
|
|
|
**LinkedIn另一个著名的开源项目是流处理引擎：Samza。** Samza和Kafka的搭配使用，是LinkedIn内部流数据的实时查询标配的解决方案，一直支撑着LinkedIn业务的发展。遗憾的是，跟Kafka比起来，Samza的名气相差甚远，最重要的原因就是Samza没有另外一个社交公司Twitter的流处理引擎Storm好用。
|
|
|
|
|
|
|
|
|
|
|
|
## 三、Twitter对Hadoop生态圈的贡献
|
|
|
|
|
|
|
|
|
|
|
|
对Hadoop生态圈有着巨大贡献的另外一家社交公司是Twitter，它最重要的贡献是：开源的流处理引擎Storm。严格来说，最初开发Storm的并不是Twitter，而是一家叫作BackType的初创公司。Twitter收购BackType以后，Storm自然就属于Twitter了。Storm在Twitter手中被发扬光大，并开源出来。
|
|
|
|
|
|
|
|
|
|
|
|
Hadoop本身是用Java开发的，所以这个生态圈里的大部分项目都基于Java语言，但Storm却是用比较小众的语言Clojure开发的，这也是Storm项目的特殊性。熟悉Clojure这个语言的程序员很少，因此想要找出一个写Clojure比较出彩的程序员并不是一件容易的事情，这也就导致了Storm的开发圈子要相对封闭一些。
|
|
|
|
|
|
|
|
|
|
|
|
但是，开发圈子的封闭性并没有影响Storm被广泛接受和使用。在很长一段时间里，Storm都是进行流计算的首选引擎。
|
|
|
|
|
|
|
|
|
|
|
|
Storm也被国内的大公司广泛采用，用得最多的要属阿里巴巴了。作为全球最大的电商，阿里巴巴的流数据处理规模很快就超越了Storm可以处理的范围，因此它必须自己对这个开源项目进行优化、改进。
|
|
|
|
|
|
|
|
|
|
|
|
然而Storm使用的开发语言是Clojure，这个语言本来就比较小众，国内可以熟练使用这个语言的人更是罕见，于是阿里巴巴的团队把整个Storm的引擎又用Java重新写了一遍，并将其命名为JStorm。JStorm后来被阿里巴巴集团捐给了Apache软件基金会，成为了Storm项目下面的一个子项目。
|
|
|
|
|
|
|
|
|
|
|
|
不过，近些年来随着Spark对流计算的支持和Flink的异军突起，流计算的开源市场又有点风起云涌的感觉了。有关Spark的内容，我会在Databricks的文章里面详细讲解。有关Flink的内容，我会在data Artisans的文章里详细讲解。
|
|
|
|
|
|
|
|
|
|
|
|
**总结来说，在Hadoop从属于雅虎一家公司到逐渐被硅谷的其他互联网公司接受、再到形成生态圈的过程中，Facebook、LinkedIn和Twitter这三大社交媒体公司对Hadoop的贡献是巨大的。**
|
|
|
|
|
|
|
|
|
|
|
|
如果没有这么多公司投入这么多资源去完善Hadoop，并通过各种开源项目解决整个生态圈缺失的功能，那么Hadoop很难成长到今天这样的规模。现在，Hadoop已经不仅仅是一个大数据平台了，更代表了一种标准。在今天，无论什么企业要提供什么样的产品，都需要兼容Hadoop生态圈。
|
|
|
|
|
|
|
|
|
|
|
|
不过，这些社交公司对Hadoop生态圈的热衷，也可以说是因为这些公司单独的技术实力不够强大、难以和谷歌抗衡，因此抱团取暖、共同促进和完善这个生态圈，是它们和谷歌并存的不二法门。
|
|
|
|
|
|
|
|
|
|
|
|
因此，**Hadoop的诞生，可以说是天时、地利、人和的必然产物。** 在我看来，即使没有Hadoop，也会在相似的时间点、在某一群公司的共同努力下，诞生一个类似Hadoop的项目。
|
|
|
|
|
|
|
