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

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

创新互联拥有十余年成都网站建设工作经验,为各大企业提供成都网站设计、成都网站制作服务，对于网页设计、PC网站建设（电脑版网站建设）、成都app软件开发、wap网站建设（手机版网站建设）、程序开发、网站优化（SEO优化）、微网站、域名注册等，凭借多年来在互联网的打拼，我们在互联网网站建设行业积累了很多网站制作、网站设计、网络营销经验，集策划、开发、设计、营销、管理等网站化运作于一体，具备承接各种规模类型的网站建设项目的能力。

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

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

在线数据库系统

在线系统处理用户的实时互动；主数据库像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）通过合适的方式来获取这些数据并切换索引来保证能获取到***的数据。

#p#

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

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

Voldemart，一个Key-Value存储系统，为系统中的只读页面提供服务。Voldemart的数据来源于Hadoop框架（Hadoop Azkaban：编排Hadoop map-reduce任务的执行计划）。这就是近线系统，它们从类似Hadoop的离线系统获取数据。下面这些页面的数据都是来自于Voldemart：
下面是几种不同的索引，这些索引由Databus-一个变化数据捕捉系统-来更新的：

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

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

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

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

数据架构经验

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

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

参考文献

Siddarth Anand LinkedIn Data Infrastructure paper
https://github.com/linkedin/databus
http://gigaom.com/2013/03/03/how-and-why-linkedin-is-becoming-an-engineering-powerhouse/
http://highscalability.com/blog/2012/3/19/linkedin-creating-a-low-latency-change-data-capture-system-w.html

分享标题：从LinkedIn的数据处理机制学习数据架构
URL分享：http://www.csdahua.cn/qtweb/news42/103792.html

成都网站优化推广公司_创新互联，为您提供ChatGPT、手机网站建设、品牌网站建设、全网营销推广、网站制作、网站建设

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源：快上网

成都快上网为您推荐相关内容