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

jopen 10年前

英文原文：Data Architecture Lessons from LinkedIn.com Data Handling Mechanisms

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

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的数据处理机制学习数据架构

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

上面提到的数据存储库被归为三种不同类型的系统，下面会逐一解释：

在线数据库系统

在线系统处理用户的实时互动；主数据库像 Oracle 就属于这一类别。主数据存储用来支撑用户的写操作和少量的读操作。以 Orcale 为例，Oracle master 会执行所有的写操作。最近，LinkedIn 正在开发另一个叫做“Espresso”的数据系统来满足日益复杂的数据需求，而这些数据看似不应从像 Oracle 这类的 RDBMS 中获取。他们能否淘汰所有或大部分的 Oracle 并将数据完全转移到像 Espresso 这类的 NoSQL 数据存储系统中去？让我们拭目以待。

Espresso 是一个支持水平扩展、索引、时间线一致性、基于文档且高可用的 NoSQL 数据仓库，旨在代替支撑公司网页操作所使用的传统 Oracle 数据库。设计它的初衷是为了提高 LinkedIn 的 InMail 消息服务的可用性。目前有如下一些应用在使用 Espresso 作为可信源系统。能够看到 NoSQL 数据存储是如果被用来处理如此众多应用的数据需求很是神奇！

成员间消息,
社交动作，如：更新
文章分享
用户个人资料
公司资料
新闻文章

离线数据库系统

离线系统主要包括 Hadoop 和一个 Teradata 数据仓库，用来执行批处理和分析类的工作。之所以被称为离线是因为它对数据执行的的批处理操作。 Apache Azkaban 被用来管理 Hadoop 和 ETL 任务，这些任务从主可信源系统获取数据后交由 map-reduce 处理，处理结果被保存在HDFS，然后通知’消费者‘（例如：Voldemart）通过合适的方式来获取这些数据并切换索引来保证能获取到最新的数据。

近线数据库系统（时间线一致性）

近线系统的目标是为了实现时间线一致性（或最终一致性），它处理类似’你可能认识的人（只读数据集）‘、搜索以及社交图这些功能，这些功能的数据会持续更新，但它们对延迟性的要求并不像在线系统那样高。下面是几种不同类型的近线系统：

Voldemart，一个 Key-Value 存储系统，为系统中的只读页面提供服务。Voldemart 的数据来源于 Hadoop 框架（Hadoop Azkaban：编排 Hadoop map-reduce 任务的执行计划）。这就是近线系统，它们从类似 Hadoop 的离线系统获取数据。下面这些页面的数据都是来自于 Voldemart：
你可能认识的人
看过本页面的人还在看
相关搜索
你可能感兴趣的工作
你可能感兴趣的事件
下面是几种不同的索引，这些索引由 Databus-一个变化数据捕捉系统-来更新的：
供 SeaS（Search-as-a-Service）使用的’成员搜索索引‘。当你在 LinkedIn 上搜索不同的成员时，这些数据就是来自于搜索索引。通常这个功能对招聘人员的帮助很大。
社交图索引帮助在人们的人脉关系中显示成员以及关系。通过这个索引用户几乎可以实时的得到网络关系的变化。
通过读复制集获取到的成员资料数据。这些数据会被’标准化服务‘访问。读复制集是对源数据库的复制，这样能使源数据库的更新同步到这些复制集上面。增加读复制集的最主要原因是能够通过将读操查询分散到读复制集上来减轻源数据库（执行用户发起的写操作）的压力。

下图展示了数据变化捕获事件是如何利用 Databus 更新到近线系统的：

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

用数据用例来展示它们是如何工作的

假如你更新了你个人资料中的最新技能和职位。你还接受了一个连接请求。那么在系统内部到底发生了什么：

将更新写入 Oracle Master 数据库
然后 Databus 做了如下一系列奇妙的工作来实现时间线一致性：

将资料变更，如最新技能和职位信息，更新到标准化服务。
将上面提到的变更更新到搜索索引服务。
将关系变更更新到图索引服务。

数据架构经验

如果要设计一个像 LinkedIn.com 一样的支持数据一致性、高扩展性且高可用性的数据架构，可以借鉴下面的经验：

数据库读写分离：你应当计划两种数据库，一种用来执行写操作的可以称为“可信源”系统，另一种执行读操作的可以称为派生数据库系统。这里的经验法则就是将由用户发起的写操作和用户读操作使用的数据库区分开来。
派生数据库系统：用户的读操作应该被分配到派生数据库或者读复制集上去。而派生数据库系统则可以建立在下面的系统之上：

Lucene 索引
NoSQL 数据存储，例如：Voldemart、Redis、Cassandra、MongoDB 等。

对于用户的读操作，应该尽量从主可信源数据库系统创建索引或者基于 key-value 的数据（来源于 Hadoop map-reduce 之类的系统），并且将每次由用户发起的被写入主可信源系统的变更一并更新到这些索引或派生数据（key-value）。
为确保派生数据库系统的数据是最新的，你可以选择应用复写（application-dual writes），即在应用层同时写入主数据库和派生数据库系统，或日志挖掘（读取通过批处理任务得到的主数据存储系统的事务提交日志）。
创建派生数据时，你可以针对主数据集或者变更数据集执行基于 Hadoop 的 map-reduce 任务，然后更新HDFS并且通知派生数据存储系统（类似 Voldemart 的 NoSQL 存储）来取走数据。
对于数据一致性来说，你可以以将这些数据存储库创建为分布式系统，集群中的每个节点又都包含主从节点。所有节点都可以创建水平扩展的数据 Shards。
为了保证这些分布式数据存储系统正常运行时间最大化，你可以使用像 Apache Helix 这一类的集群管理工具。

参考文献

翻译：伯乐在线 - 塔塔
译文链接： http://blog.jobbole.com/69344/

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

相关资讯