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

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

　　在线数据库系统

　　在线系统处理用户的实时互动；主数据库像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更新到近线系统的：

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

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

• 将更新写入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这一类的集群管理工具。

参考文献

• 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

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