从LinkedIn的数据处理机制学习数据架构

　　LinkedIn.com是当今最流行的专业社交网站之一，本文描述了LinkedIn.com是如何管理数据的。如你对文中的观点有异议亦或文中有遗漏的部分请随时告诉我。

　　LinkedIn.com数据用例

　　下面是一些数据用例，可能我们在浏览LinkedIn网页时都已经看到过了。

• 更新后的个人资料后几乎可以实时的出现在招聘搜索页面

• 更新后的个人资料后几乎可以实时的出现在人脉网页

• 分享一个更新，可以近实时的出现在新闻feed页面

• 然后会更新到其他只读页面，像”你可能认识的人“、”看过我资料的人“、”相关搜索“等。

　　令人震惊的是，如果我们使用较好的宽带，这些页面可以在数毫秒内完成加载！让我们向LinkedIn工程师团队致敬！

　　早期的LinkedIn数据架构

　　像其它初创公司一样，LinkedIn 早期也是通过单个的RDBMS （关系型数据库管理系统）的几张表来保存用户资料和人脉关系。是不是很原始？后来这个RDMBS扩展出两个额外的数据库系统，其中一个用来支撑用户个人资 料的全文搜索，另一个用来实现社交图。这两个数据库通过Databus来取得最新数据。Databus是一个变化捕捉系统，它的主要目标就是捕捉那些来至 可信源（像Oracle）中数据集的变更，并且把这些变化更新到附加数据库系统中。

　　但是，没过多久这种架构就已经很难满足网站的数据需求了。因为按照Brewerd的CAP理论想要同时满足下面的条件看似不太可能：

一致性：所有应用在同一时刻看到相同的数据

可用性：保证每个请求都能收到应答，无论成功或失败

分区容错性：部分系统的消息丢失或失败不影响系统系统整体的正常运行

　　根据上面的法则，LinkedIn工程师团队实现了他们称作为时间线一致性（或者说近线系统的最终一致性，下面会解释）以及另外两个特性：可用性和分区容错性。下面介绍目前LinkedIn的数据架构。

　　LinkedIn如今的数据架构

　　如果要支撑在不到一秒钟内处理数百万用户的相关事务，上面的数据架构已经明显不足了。因此，LinkedIn 工程师团队提出了三段式（three-phase）数据架构，由在线、离线以及近线数据系统组成。总体上讲，LinkedIn数据被存储在如下几种不同形 式的数据系统中（看下面的图）：

• RDBMS

• Oracle

• MySQL（作为Espresso的底层数据存储）

• RDBMS

• Espresso（LinkedIn自己开发的文档型NoSQL数据存储系统）

• Voldemart （分布式Key-value存储系统）

• HDFS （存放Hadoop map-reduce任务的数据）

• Caching

• Memcached

• 基于Lucene的索引

• 存放查询、关系图等功能数据的Lucene 索引

• Espresso使用的索引

　　图：LinkedIn数据库系统包括了DataBus、NoSQL、RDBMS以及Indexes