从LinkedIn的数据处理机制学习数据架构如果您对文章中的观点有任何异议，或者文章中有任何遗漏之处，请随时告诉我。LinkedIn.com数据用例以下是我们在浏览LinkedIn网页时可能都见过的一些数据用例。更新后的个人资料几乎可以实时出现在招聘搜索页面上。更新的配置文件可以几乎实时地出现在网页中。共享更新，它可以近乎实时地出现在新闻提要页面中，然后更新到其他只读页面，例如“您可能认识的人”、“看过我个人资料的人”、“相关搜索”等。令人震惊的是，如果我们使用良好的宽带，这些页面可以在几毫秒内加载！让我们向领英工程团队致敬！早期的LinkedIn数据架构与其他初创公司一样，LinkedIn在早期也是使用单一的RDBMS（关系数据库管理系统）来存储用户资料和个人关系。是不是很原始？后来，这个RDMBS扩展为另外两个数据库系统，其中一个用于支持用户资料的全文搜索，另一个用于实现社交图谱。这两个数据库通过Databus获取最新的数据。Databus是一个变更捕获系统，其主要目标是从可信源（如Oracle）捕获对数据集的更改，并将这些更改更新到附加的数据库系统。但是没过多久，这种架构就很难满足网站的数据需求了。因为根据Brewerd的CAP理论，似乎不可能同时满足以下条件：一致性：所有应用程序同时看到相同的数据可用性：确保每个请求都能收到响应，无论成功或失败分区故障tolerance弹性：某些系统中消息的丢失或故障不影响整个系统的正常运行。根据以上规则，LinkedIn工程师团队实现了他们所说的时间线一致性（或者说近线系统的最终一致性，下面会解释）和另外两个属性：可用性和分区容错性。下面介绍LinkedIn目前的数据结构。如果LinkedIn现在的数据架构要支持不到一秒的百万级用户相关交易，上面的数据架构显然是不够的。因此，LinkedIn工程团队提出了由在线、离线和近线数据系统组成的三阶段数据架构。一般来说，LinkedIn数据存储在以下几种不同形式的数据系统中（见下图）：RDBMSOracleMySQL（作为Espresso的底层数据存储）RDBMSEspresso（LinkedIn自研的基于文档的NoSQL数据存储系统）Voldemart（分布式键值存储系统）HDFS（Hadoopmap-reduce任务的数据存储）基于Lucene的缓存MemcachedLucene索引，用于存储查询和关系图等功能数据Espresso使用的索引映射：LinkedIn数据库系统包括DataBus，NoSQL、RDBMS和索引上面提到的数据存储库分为三种不同类型的系统，解释如下：在线数据库系统在线系统处理与用户的实时交互；像Oracle这样的主要数据库就属于这一类。主数据存储用于支持用户写操作和少量读操作。以Oracle为例，Oraclemaster会执行所有的写操作。最近，LinkedIn正在开发另一个名为“Espresso”的数据系统，以满足日益复杂的数据需求，而这些数据似乎不应该像Oracle那样从RDBMS中获取。他们能否消除全部或大部分Oracle，并将数据完全移动到像Espresso这样的NoSQL数据存储？让我们拭目以待。Espresso是一个NoSQL数据仓库，支持水平扩展、索引、时间线一致性、基于文档和高可用性，旨在取代用于支持公司网页运营的传统Oracle数据库。它旨在提高LinkedIn的InMail消息服务的可用性。目前，以下应用程序正在使用Espresso作为可信源系统。看到如何使用NoSQL数据存储来处理这么多应用程序的数据需求，真是太棒了！会员间消息，社交行为，如：更新文章分享用户个人资料公司信息新闻文章离线数据库系统离线系统主要包括Hadoop和一个Teradata数据仓库来进行批处理和分析工作。之所以称为离线，是因为它对数据执行批量操作。ApacheAzkaban用于管理Hadoop和ETL任务，这些任务从mainsourceoftruthsystem获取数据并传递给map-reduce进行处理，处理结果存储在HDFS中，然后通知给“消费者”（例如:Voldemart)通过合适的方式获取这些数据并切换索引，以确保获取到最好的数据。#p#近线数据库系统（时间线一致性）近线系统的目标是实现时间线一致性（或最终一致性），它处理诸如'你可能认识的人（只读数据集）'，搜索以及诸如此类的功能作为社交图谱，这些功能的数据会不断更新，但对延迟的要求并不像在线系统那么高。以下是几种不同类型的近线系统：Voldemart，一种Key-Value存储系统，服务于系统中的只读页面。Voldemart的数据来自Hadoop框架（HadoopAzkaban:orchestrationtheexecutionplanofHadoopmap-reducetasks）。这些是近线系统，从Hadoop等离线系统获取数据。以下页面的数据来自Voldemart：您可能认识的人查看过此页面的人仍在查看的人相关搜索您可能感兴趣的工作您可能感兴趣的事件下面是几个不同的索引，由Databus组织-变更数据捕获系统-更新：SeaS（搜索即服务）的“会员搜索索引”。当您在LinkedIn上搜索不同的成员时，此数据来自搜索索引。通常此功能对招聘人员有很大帮助。社交图索引有助于显示人们联系中的成员和关系。通过这个索引，用户可以几乎实时地获得网络关系的变化。通过读取副本集获得的会员资料数据。这些数据将由“标准化服务”访问。只读副本集是源数据库的副本，因此来自源数据库的更新可以同步到这些副本集。添加只读副本集的主要原因是通过跨只读副本集分散读取查询来减轻源数据库的压力（执行用户启动的写入操作）。下图显示了如何使用Databus将数据更改捕获事件更新到近线系统：使用数据用例来显示如果您更新个人资料中的最新技能和头衔，它们将如何工作。您还接受了连接请求。那么系统内部究竟发生了什么：将更新写入OracleMaster数据库，然后Databus为了实现时间线的一致性做了如下一系列精彩的事情：将数据变化，比如***技能和职位信息，更新到标准化的服务中。将上述更改更新到搜索索引服务。更新对图形索引服务的关系更改。数据架构经验如果你想像LinkedIn.com一样设计一个支持数据一致性、高扩展性和高可用性的数据架构，可以借鉴以下经验：数据库读写分离：你应该规划两个数据库，一个用于一个执行写操作的系统可以称为“信任源”系统，另一个执行读操作的系统可以称为派生数据库系统。这里的经验法则是将用于用户启动的写入的数据库与用于用户读取的数据库分开。派生数据库系统：用户的读操作应该分配给派生数据库或只读副本集。衍生数据库系统可以建立在以下系统上：Lucene索引NoSQL数据存储，如：Voldemart、Redis、Cassandra、MongoDB等。对于用户的读操作，应该尝试创建索引或基于键值主可信源数据库系统的数据（来自Hadoopmap-reduce等系统），每次写入用户发起的数据到主可信源数据库系统。对源系统的更改会更新到这些索引或派生数据（键值）。为保证派生数据库系统中的数据唯一，可以选择应用复制（application-dualwrite），即在应用层同时写入主库和派生数据库系统，或者日志挖掘（读取主数据存储系统的事务提交日志）。创建派生数据时，您可以对主要或更改的数据集执行基于Hadoop的map-reduce作业，然后更新HDFS并通知派生数据存储系统（如Voldemart的NoSQL存储）获取数据。为了数据的一致性，您可以将这些数据存储库创建为分布式系统，集群中的每个节点都包含主节点和从节点。所有节点都可以创建水平扩展的数据分片。为了最大限度地延长这些分布式数据存储系统的正常运行时间，您可以使用ApacheHelix等集群管理工具。参考文献SiddarthAnandLinkedInDataInfrastructure论文https://github.com/linkedin/databushttp://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/
