从 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使用的索引

image

图: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的离线系统获取数据。下面这些页面的数据都是来自于Vold emart:

    • 你可能认识的人
    • 看过本页面的人还在看
    • 相关搜索
    • 你可能感兴趣的工作
    • 你可能感兴趣的事件
  • 下面是几种不同的索引,这些索引由Databus-一个变化数据捕捉系统-来更新的:

    • 供SeaS(Search-as-a-Service)使用的’成员搜索索引‘。当你在LinkedIn上搜索不同的成员时,这些数据就是来自于搜索索引。通常这个功能对招聘人员的帮助很大。
    • 社交图索引帮助在人们的人脉关系中显示成员以及关系。通过这个索引用户几乎可以实时的得到网络关系的变化。
    • 通过读复制集获取到的成员资料数据。这些数据会被’标准化服务‘访问。读复制集是对源数据库的复制,这样能使源数据库的更新同步到这些复制集上面。增加读复制集的最主要原因是能够通过将读操查询分散到读复制集上来减轻源数据库(执行用户发起的写操作)的压力。

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

image

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

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

  • 将更新写入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存储)来取走数据。

U对于数据一致性来说,你可以以将这些数据存储库创建为分布式系统,集群中的每个节点又都包含主从节点。所有节点都可以创建水平扩展的数据Shards。

  • 为了保证这些分布式数据存储系统正常运行时间最大化,你可以使用像Apache Helix这一类的集群管理工具。
相关文章
|
16天前
|
消息中间件 存储 缓存
十万订单每秒热点数据架构优化实践深度解析
【11月更文挑战第20天】随着互联网技术的飞速发展,电子商务平台在高峰时段需要处理海量订单,这对系统的性能、稳定性和扩展性提出了极高的要求。尤其是在“双十一”、“618”等大型促销活动中,每秒需要处理数万甚至数十万笔订单,这对系统的热点数据处理能力构成了严峻挑战。本文将深入探讨如何优化架构以应对每秒十万订单级别的热点数据处理,从历史背景、功能点、业务场景、底层原理以及使用Java模拟示例等多个维度进行剖析。
44 8
|
18天前
|
存储 分布式计算 数据挖掘
数据架构 ODPS 是什么?
数据架构 ODPS 是什么?
142 7
|
18天前
|
数据采集 搜索推荐 数据管理
数据架构 CDP 是什么?
数据架构 CDP 是什么?
42 2
|
4月前
|
机器学习/深度学习 数据采集 人工智能
揭秘!47页文档拆解苹果智能,从架构、数据到训练和优化
【8月更文挑战第23天】苹果公司发布了一份47页的研究文档,深入解析了其在智能基础语言模型领域的探索与突破。文档揭示了苹果在此领域的雄厚实力,并分享了其独特的混合架构设计,该设计融合了Transformer与RNN的优势,显著提高了模型处理序列数据的效能与表现力。然而,这种架构也带来了诸如权重平衡与资源消耗等挑战。苹果利用海量、多样的高质量数据集训练模型,但确保数据质量及处理噪声仍需克服。此外,苹果采取了自监督与无监督学习相结合的高效训练策略,以增强模型的泛化与稳健性,但仍需解决预训练任务选择及超参数调优等问题。
153 66
|
17天前
|
SQL Java 数据库连接
Mybatis架构原理和机制,图文详解版,超详细!
MyBatis 是 Java 生态中非常著名的一款 ORM 框架,在一线互联网大厂中应用广泛,Mybatis已经成为了一个必会框架。本文详细解析了MyBatis的架构原理与机制,帮助读者全面提升对MyBatis的理解和应用能力。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
Mybatis架构原理和机制,图文详解版,超详细!
|
29天前
|
运维 Serverless 数据处理
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
79 1
|
2月前
|
存储 资源调度 算法
操作系统的心脏:深入理解内核架构与机制####
【10月更文挑战第16天】 本文旨在揭开操作系统最神秘的面纱——内核,通过剖析其架构设计与关键机制,引领读者一窥究竟。在这篇探索之旅中,我们将深入浅出地讨论内核的基本构成、进程管理的智慧、内存分配的策略,以及那至关重要的系统调用接口,揭示它们是如何协同工作,支撑起现代计算机系统的高效运行。这既是一次技术的深潜,也是对“看不见的手”调控数字世界的深刻理解。 ####
48 3
|
2月前
|
运维 Serverless 数据处理
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
61 3
|
3月前
|
设计模式 架构师 Java
Java开发工程师转架构师需要学习什么
Java开发工程师转型为架构师需掌握多项技能:精通Java及框架、数据库与分布式系统;熟悉设计模式与架构模式;积累项目经验;提升沟通与领导力;持续学习新技术;培养系统设计与抽象能力;了解中间件及开发工具;并注重个人特质与职业发展。具体路径应结合个人目标与实际情况制定。
71 18
|
2月前
|
存储 大数据 数据处理
洞察未来:数据治理中的数据架构新思维
数据治理中的数据架构新思维对于应对未来挑战、提高数据处理效率、加强数据安全与隐私保护以及促进数据驱动的业务创新具有重要意义。企业需要紧跟时代步伐,不断探索和实践新型数据架构,以洞察未来发展趋势,为企业的长远发展奠定坚实基础。