存档

‘Facebook’ 分类的存档

Instagram: 2年10亿美元背后的技术架构

2015年7月3日 没有评论

转自:Archfan

参考:Instagram的技术探索

Instagram是一款免费照片分享移动应用,目前支持IOS和Android。在1年多的时间里,Instagram发展到140万个用户,1.5亿张图片(几个TB),仅有3个工程师,以10亿美元的天价被Facebook收购。不得不说,Instagram是业界的一个神话。今天我们就来看看到底是什么样的技术架构支撑着这个10亿美元的公司。

Instagram团队之前发表过一篇文章:What Powers Instagram:Hundreds of Instances,Dozens of Technologies。这篇文章中提到的技术架构堪称经典,很适合初创项目的快速启动。

这个小团队使用了很多不同的技术和策略,保证他们能轻松的应付快速增长带来的压力。他们混合使用SQL、NoSQL,一堆开源项目,和云服务;云服务他们选择了Amazon,他们认为Amazon要比他们自己部署IDC更有优势;用异步队列来串联组件;系统架构在众多的对外API和内部Services之上;数据存储在内存和云端;大部分代码是动态语言;等等等等。非常时髦的一个架构,基于这个架构之上他们得以快速前进,并且保持精简。

那篇文章非常值得一读,有兴趣的同学可以直接看原文。这里我列出一些要点:

  • 架构原则:1.保持简单;2.不重复造轮子;3.尽量使用成熟稳定的技术
  • 3个工程师
  • 大量使用Amazon服务,工程师不用耗费时间自己维护服务器
  • 100+个EC2实例用于各种用途
  • Ubuntu Linux 11.04(“Natty Narwhal”),他们认为这个版本更加稳定
  • Amazon的ELB(Elastic Load Balancer)路由请求,ELB后面起了3个Nginx实例
  • ELB上关闭了SSL,因为它降低了CPU的使用率
  • DNS使用Amazon的Route53
  • 25+个Django应用服务运行在High-CPU Extra-Large类型的机器上
  • CPU使用比内存使用更加容易达到边界值,所以使用High-CPU Extra-Large的实例来平衡内存和CPU
  • Gunicorn是他们的WSGI服务器。Apache更难配置,更耗CPU
  • Fabric被用来在所有机器上并行执行命令。部署花费更少的时间。
  • PostgreSQL(存储用户,照片元数据,标签等)运行在12个Quadruple Extra-Large Memory实例上
  • 12个PostgreSQL副本运行在不同的节点上
  • PostgreSQL的Master-Replica使用流复制模式,利用EBS的快照来频繁备份
  • EBS部署在软件RAID上,使用mdadm以获取适当的IO
  • 将所有工作中的数据集存储在内存中,因为EBS每秒磁盘寻道次数有限
  • Vmtouch(轻量级的文件系统缓存诊断工具)被用来管理内存数据,尤其是当故障转移时目标机器没有足够空余的内存
  • 用XFS做文件系统,保证数据快照时RAID阵列上数据的一致性
  • Pgbouncer用作PostgreSQL的连接池
  • 有几个TB的照片存在Amazon S3上
  • 用Amazon CloudFront做CDN
  • Redis用来支撑feed,活动消息,session系统和其它服务
  • Redis运行在几台Quadruple Extra-Large Memory实例上,偶尔也会做下切分
  • Redis也是Master-Replica,副本持久化到磁盘上,并由EBS通过快照备份(这么搞是因为他们发现直接在Master上做dump相当吃力)
  • Geo-Search使用Solr,Solr提供的JSON接口也很简单易用
  • 6个memcached实例做缓存,因为Amazon Elastic Cache服务并不便宜,mmc客户端使用pylibmc和libmemcached
  • Gearman用做:向Twitter,Facebook等平台异步分享照片;新照片发布的通知;feed的反送
  • 200个Python进程处理Gearman的任务队列
  • Pyapns处理超过10亿条Apple的push通知,异常稳定
  • Munin用做监控和系统度量工具,用Python-Munin写了很多图表插件,如每分钟注册人数,每秒钟图片发表数等等
  • Pingdom做内部服务的监控
  • PagerDuty用来处理通知和事件
  • Sentry用来做Python的错误报告

以上就是Instagram的博文里面提到的技术要点,怎么样,准备好构建下一个10亿美元的应用了么?


Facebook的数据仓库是如何扩展到300PB的

2014年10月2日 没有评论

英文原文:Scaling the Facebook data warehouse to 300 PB

中文翻译:Facebook的数据仓库是如何扩展到300PB的 本文转自这里

Facebook在数据仓库上遇到的存储可扩展性的挑战是独一无二的。我们基于Hive的数据仓库中存储了超过300PB的数据,并且以每日新增600TB的速度增长。去年这个数据仓库所存储的数据量增长了3倍。考虑到这个增长趋势,存储效率问题是我们数据仓库基础设施方面目前乃至将来一段时间内最需要关注的。

在提高数据仓库的存储效率方面我们有许多创新点,例如建立冷数据存储的数据中心、对HDFS采用类似RAID的技术在保证数据高可用性不变的前提下降低冗余率、在数据被写入到HDFS之前先做压缩以减少数据占用的存储空间。在Facebook对于大量原始日志的转换(transformations)操作最广泛使用的系统是Hive,Facebook的Hive是建立在Corona Map-Reduce框架之上的用于处理数据、建立数据仓库表等工作的查询引擎。在这篇文章中,我们主要讨论Hive表的存储格式的演化,这个工作主要的目的是使Hive表的存储格式要尽可能高效压缩原始数据。

RCFile

我们的数据仓库中数据被加载到表里面时首先使用的存储格式是Facebook自己开发的Record-Columnar File Format(RCFile)。RCFile是一种“允许按行查询,提供了列存储的压缩效率”的混合列存储格式。它的核心思想是首先把Hive表水平切分成多个行组(row groups),然后组内按照列垂直切分,这样列与列的数据在磁盘上就是连续的存储块了。

当一个行组内的所有列写到磁盘时,RCFile就会以列为单位对数据使用类似zlib/lzo的算法进行压缩。当读取列数据的时候使用惰性解压策略( lazy decompression),也就是说用户的某个查询如果只是涉及到一个表中的部分列的时候,RCFile会跳过不需要的列的解压缩和反序列化的过程。通过在我们的数据仓库中选取有代表性的例子实验,RCFile能够提供5倍的压缩比。

超越RCFile,下一步采用什么样的方法?

随着数据仓库中存储的数据量持续增长,组内的工程师开始研究提高压缩效率的技术和方法。研究的焦点集中在列级别的编码方法,例如行程长度编码(run-length encoding)、词典编码(dictionary encoding)、参考帧编码(frame of reference encoding)、能够在通用压缩过程之前更好的在列级别降低逻辑冗余的数值编码方法。我们也尝试过新的列类型(例如JSON是在Facebook内部广泛使用的格式,把JSON格式的数据按照结构化的方式存储既可以满足高效查询的需求,同时也降低了JSON元数据存储的冗余)。我们的实验表明列级别的编码如果使用得当的话能够显著提高RCFile的压缩比。

与此同时,Hortonworks也在尝试类似的思路去改进Hive的存储格式。Hortonworks的工程团队设计和实现了ORCFile(包括存储格式和读写接口),这帮助我们为Facebook的数据仓库设计和实现新的存储格式提供了一个很好的开始。

ORCFile详解

Hive的数据以ORCFile的格式写到磁盘时,数据被分成一系列的256MB的条带(stripe),一个条带类似于在RCFile中的一个行组。在每一个条带内,ORCFile首先对每个列的数据进行编码,然后把整个条带内的所有列使用类似zlib压缩算法进行压缩。对于一个字符串格式的列使用词典编码,而且是对一个条带内的所有的行数据放到一起进行列编码。在每个条带内会对每10,000行数据存储一个索引,并记录每一列中的最大值和最小值。这些在过滤式的查询时能够跳过一些不在范围内的行。

除了压缩改进,新的存储格式的一个显著优点就是列和行会以偏移(offset)的形式被记录,这样就不需要用分隔符去标记行尾。然而在RCFile中是通过预留某些ASCII值作为分隔符,那么这些分隔符就不允许出现在数据流中。同时查询引擎能够利用条带和每一列在文件级别的元数据去优化查询效率。

自适应的列编码

当我们开始在数据仓库中测试ORCFile的时候,我们发现有些Hive表压缩表现良好,有的反而会引起数据膨胀,导致我们数据仓库中一个有代表性的表集合上的测试中压缩效率提升非常不明显。因为如果某一列数据的熵很大的时候,词典编码会引起数据膨胀,所以如果默认对所有的字符串类型的列都进行词典编码是不合适的。对于某一列是否需要词典编码我们考虑两种方法:通过用户指定的列元数据静态指定;在运行时通过考察列值的情况动态选择编码方法。我们选择后者是因为它能够很好的兼容我们数据仓库已有的数量众多的表。

我们进行了很多测试目的是找到最大化压缩比同时又不影响ORCFile写性能的方法。由于字符串类型在我们最大的那些表中占据主导,同时数据仓库中大约80%的列是由字符串类型组成的,所以优化字符串类型的压缩比最重要。对于每个条带内每一列的不同数值的数目设置一个阈值,同时我们修改了ORCFile的写接口,对于每个条带内的数据如果使用词典编码能够带来压缩效率提升我们就对数据进行词典编码。同时我们对列值进行采样,考察组成列值的字符集合。因为如果这个字符集合比较小的话像zlib这样的通用压缩算法可以有比较好的压缩比,这种情况下词典编码就不是很必要了,有的时候甚至会起副作用。

对于很大的整形数据,我们可以考虑使用行程长度编码或者词典编码。大多数情况下行程长度编码只比通用压缩算法稍微好一点,然而当列数据是由少数几个不同数值组成的时候词典编码会表现比较出色。基于这个结果,对于很大的整形数据我们也是采用词典编码而不是行程长度编码。对于字符串类型和数值类型的数据采用这个思路编码能够给ORCFile带来很高的压缩效率。

我们也实验了很多其他的提高压缩比的方法。其中值得一提的思路就是自适应行程长度编码,也就是一种启发式的策略,只有当使用行程长度编码能够提高压缩比的时候才会使用。在ORCFile的开源版本中这个策略应用到为整形数据在多种方法中自适应地选择编码算法的过程中。这个方法虽然提高了压缩比,但是写性能下降了。我们也研究了条带大小对压缩比的影响。出乎我们的意料,增加条带的大小并不能显著提高压缩比。因为随着条带大小的增加,词典元素的数量会增加,这会导致编码后的列值所占用的字节数量增大。所以想要存储较少的词典带来的优势不符合预期,以256MB作为一个条带大小的这个经验值还是挺靠谱的。

写性能

考虑到在我们的规模下数据的写入速度会影响查询性能,我们对开源的ORCFile的写入接口进行了很多改进用于提高写入性能。其中关键的一点是消除冗余或者不必要的操作,同时要优化内存使用情况。

我们对ORCFile写接口的改进中最关键的就是创建有序词典的过程。在开源ORCFile的版本中为了保证词典的有序,写接口是用红黑树(red-black tree)来存储的词典。然后在自适应的词典编码中,即使某一列不适合使用词典编码存储,它也要花费O(log(n))的时间复杂度向红黑树插入一个新的key。如果使用一个存储高效的哈希映射来存放词典,只有在需要的时候排序,词典的内存占用量降低了30%,而且更重要的是写性能提高了1.4倍。为了更快、更高效利用内存地调整词典大小,初始词典是由一个字节数组为元素的数组存储的。然而这会使得访问词典元素这个操作非常频繁,我们选择使用Airlift库的Slice类用来代替词典实现高效内存拷贝,能把写性能再提高20%-30%。

按列打开词典编码很耗费计算资源。因为每一列的字符在不同的条带里会有重复,我们已经发现对于所有条带统一进行词典编码没有优势。所以我们改进写接口,基于条带的子集合判断列编码算法,同时接下来的条带中对应的列会重复上面条带的算法。也就是说如果写接口判断对于这一列的值使用词典编码没有优势,那么在接下来的条带中会智能地不使用词典编码。由于Facebook自有的ORCFile格式带来的压缩效率的提升,我们可以降低已经使用的zlib的压缩级别,同时写性能得到20%的提升。

读性能

谈到读性能,大家很快就会想到的问题就是惰性列解压缩(laze column decompression)。例如一个要读取很多列但是只在某一列有过滤条件的查询。如果没有我们实现的惰性解压缩,所有列都会被读取并解压缩。理想情况是只有设置有过滤条件的列被解压缩和解码,这样这个查询才不会浪费大量的时间在解压缩和解码那些无关数据上。

为了这个目的,我们利用ORCFile存储格式中的索引跨步(index strides)给Facebook的ORCFile的读接口实现了惰性解压缩和惰性解码功能。在前面讲的例子中,对于有过滤条件的那一列涉及到的所有数据将要被解压缩和解码。对于其他列的数据,我们改变读接口去读取条带内相应的索引跨步(对条带的元数据操作),只需要解压缩和解码相应索引跨步前面的行数据。经过我们的测试,这个改进使得在我们Facebook的ORCFile的版本上运行的简单过滤型(select)查询比开源版本性能提高了3倍。因为没有了额外数据的惰性解码,Facebook的ORCFile在这种简单过滤型查询的性能也比RCFile高。

总结

通过应用这些改进,在数据仓库数据中我们使用ORCFile相比RCFile在压缩比上带来了5到8倍的提升。从数据仓库中选择了一系列典型的查询和数据的测试中,我们发现Facebook的ORCFile的写性能会比开源版本高3倍。

我们已经把这种新的存储格式应用到许多数十PB级别的表数据中,通过把数据从RCFile改成ORCFile存储格式,已经再生出数十PB级别的存储容量。我们正在把这种新的存储格式向数据仓库中的其他表推广,这个改进可以达到存储效率和读写性能的双重提升。我们Facebook内部的ORCFile的代码是开源的,同时我们也在与开源社区密切配合把这些改进并入Apache Hive的代码中。

下一步?

在进一步改进ORCFile的压缩比和读写效率方面我们有很多想法。包括支持新的压缩编码例如LZ4HC、不同的列当编码不同时使用不同的压缩算法和压缩等级、存储更多的统计信息并暴露给查询引擎使用、把开源社区像谓词下压(predicate pushdown)等工作引入Facebook内部。另外还有一些其他的改进思路,例如降低源表和派生表的逻辑冗余、对于冷数据集的采样、增加目前暂时以字符串格式存储的却有通用需求的Hive原生数据类型。

Facebook分析基础设施组的许多同事参与了ORCFile相关的工作,包括了本文的作者 Pamela Vagata, Kevin Wilfong and Sambavi Muthukrishnan。同时感谢Hortonworks的同事对我们的工作的配合和帮助。


深入 Facebook 消息应用服务器

2011年5月4日 没有评论

英文来源:Inside Facebook Messages’ Application Server
中文出处:开放博客,由灰狐翻译小组制作

要点:

  1. Facebook 统一消息系统(邮件、短信、聊天、消息等);
  2. HBase 作为后端存储设施,每个用户数据存储在 HBase 的单独一行里,每个实体(文件夹、主题、消息等等)都存储在自己的HBase列中;
  3. 涉及 HayStack 图片处理基础设施;
  4. 使用 Apache Lucene 维护反向索引列表;
  5. 镜像了大约 10% 用户的实时聊天和收件箱中的信息到测试集群中,并通过 dark launch 进行测试。

Facebook Messages 是我们曾经所创建的最具技术挑战性的一个代表产品。

当我们发布Facebook Messages 时所提到的是我们需要打造一个专门的应用服务器来管理其基础架构。

我们最近讨论了消息后台和我们如何处理所有来自 email, SMS, Facebook Chat 和 Inbox 的通信。

今天我们将深入消息应用服务器的核心。

应用服务器的业务逻辑

应用服务器集成了众多Facebook服务和保护(shields)来自各种终端的复杂性。它提供了一个简单接口方便客户端进行标准消息处理,包括:创建、读取、删除、更新消息和收件箱。

下面是每一部分的流程。

当创建一个新消息或回复消息时,应用服务器代表发送者传递消息到收件人。如果收件人是通过其邮件地址,则服务器通过HayStack获得附件(如果有的话),构造HTML主体,并创建一个RFC2822消息。

输出流

当消息发送给用户时,如果地址是一个回复处理,服务器将从存在的邮件地址和传递的输入消息中获得正确收件人的信息。服务器最终将消息传递到用户邮箱,运行所有必要的预处理和后期处理过程,并决定基于多个信号的文件夹和主题的消息路由。

输入流

当读取消息时,服务器取得有关用户邮箱的多个统计,如容量;消息、主题和回复数;朋友的数量等。同时也获得文件夹相关统计和属性,各种搜索条件的主题列表(文件夹,属性,作者,关键字等等),主题属性和这个主题的其它消息。

当删除消息时,服务器标记要删除的消息和主题。一个离线任务具体清除消息内容。

当更新消息和主题时,服务器改变消息或主题属性,如读取和到达状态,标签等等。同时也处理多个用户对主题的订阅和取消订阅的请求。

管理群组主题

Facebook Messages 使用一个聊天室模型管理群组消息主题。用户能加入(订阅)和离开(取消订阅)。

当邮件地址是是这个主题的指定接收者时这个模型是必须的,应用服务器创建一个回复处理器,类似聊天室ID。当一个邮件接收者回复了主题,则消息会被发送到回复处理器地址。

为了优化读取性能和简化移植和备份处理,消息主题以一种非规格化(denormalized)的方式存储。于是每个用户都拥有一份主题元数据和消息的拷贝,服务器广播订阅和取消订阅事件,在一个分散的方式中同步所有接收者订阅和回复处理的主题元数据。服务器也管理类似用户仍旧使用老的收件箱或通过他们的邮件地址订阅的情形。

缓存用户元数据

当用户访问收件箱时,应用服务器装载最常用的用户元数据(也称活动元数据)并将它们保存在最近最少使用的缓存中(a least recently used cache,也就是LRU算法)。随后,同一用户的请求会通过少量的HBase查询被快速的处理。

我们需要减少HBase查询,因为HBase不支持join, 为处理一个读请求,服务器可能需要在分开的HBase查询中查找多个索引和匹配元数据和消息体。HBase的最佳化体现在写操作而不是在读取上,用户行为通常拥有好的时间和地域性(good temporal and spatial locality),于是缓存能帮助解决这个问题并提升性能。

我们也在通过减少用户内存占用和转移到细粒度模式进而提升缓存的有效性方面做出了很多努力。我们能缓存5%-10%的用户量和95%的活跃元数据缓存命中率。我们在全局的memcache层缓存了访问极为频繁的数据(如在Facebook首页显示没有阅读的消息数)。当新消息到达时应用服务器标记缓存为(dirties)(注:dirties表示修改了但还没有写到数据文件的数据)。

同步

HBase对事务隔离提供了有限的支持。针对同一用户的多个更新可能同时发生。为解决它们之间的潜在冲突,我们使用应用服务器作为用户请求的同步点。一个用户在任何给定的时间里由独有的服务器提供服务。这样,同一用户请求就可以在应用服务器中以一种完整孤立的方式(Fashion)同步和执行。

存储模式

MTA代理特性附件和大量消息实体,在它们能到达应用服务器之前被存储在Haystack中。然而,元数据,包含索引数据和小的消息体,它们存储在HBase中并由应用服务器维护着。每个用户的收件箱都是独立于任何其它用户的;用户数据不会在HBase中共享(shared)。每个用户数据存储在HBase的单独一行里,它包含了以下部分:

元数据实体和索引

元数据实体包含收件箱对象属性,如文件夹、主题、消息等等。每个实体都存储在自己的HBase列中。不像关系型数据库(RDBMS),HBase没有提供用于索引的本地支持 。我们在应用级维护辅助索引(Secondary Indexes),同样以键/值对的方式存储在分开的列中。

比如,要回答查询“loading unread threads on the second page of the Other folder,” 应用服务器首先搜寻元数据索引以获得符合条件的主题列表,然后取出指定主题的元数据实体,以它们的属性构造响应。

正如我们前面所提到的,缓存和有效的预装载能减少HBase查询量以获得更好的性能。

活动日志

用户邮箱中的任何更新(如发表和删除消息,标记主题为已读等等)会立即以时间的顺序添加到列中,这称为一个活动日志(action log)。小的消息实体也存储在活动日志中。

我们能通过回放(replaying )活动日志的方式构造或恢复用户邮箱的当前状态,我们使用最后活动日志的ID以元数据实体和索引的版本回放。当用户邮箱被加载,应用服务器比较元数据版本和最后活动日志ID,如果元数据版本滞后(lags behind)则更新邮箱内容。

活动日志存储在应用级带来极大的灵活性:

  • 我们能通过回放活动日志无缝切换到一种新的模式并且能通过一个离线的 MapReduce 任务或在线的应用服务器自身生成新的元数据实体和索引。
  • 我们能在一个批处理中执行大量HBase异步写以节省网络带宽和减少HBase压缩成本。
  • 它是与其它组件交换持久性数据的标准协议。比如,我们通过将活动日志写到记录日志(Scribe log)做应用级的备份。这个移植管道转化用户老的收件箱数据到活动日志并且通过离线MapReduce生成元数据和索引。

搜索索引

为支持全文检索,我们维护着一个从关键字到匹配消息的反向索引。当一个新消息到达时,我们使用 Apache Lucene 去解析和转化它到一个(keyword, message ID, positions)元组(tuples)中,然后以递增的方式加入到 HBase 的列中。每个关键字都拥有自己的列。所有的消息,包括聊天记录,邮件和短信都被实时索引。

dark launch 测试

应用服务器是我们从零开始构建的一个全新软件,因此在将它推向5亿用户前我们需要监控它的性能、可靠性和伸缩性。我们最初开发了一个压力测试机器人(robot)用来生成模拟请求,但是我们发现这样的结果可能会受到其它一些新因素的影响,如消息长度,不同类型请求的分发,用户活跃度的分布等等。

为了仿真一个真实的产品负荷,我们制作了 dark launch,我们镜像了大约10%用户的实时聊天和收件箱中的信息到测试集群中。Dark launches 帮助我们发现更多性能问题和识别瓶颈。我们也使用它作为一个有说服力的指标来评价我们所做的很多改进 。接下来,我们会继续努力为我们的所有用户提供崭新的消息系统。

作者:Jiakai 是 Facebook Messages 开发小组成员。


分类: Architecture, Facebook 标签:

Facebook 的系统架构

2011年4月30日 没有评论

英文来源:http://www.quora.com/What-is-Facebooks-architecture (由Michaël Figuière回答)

中文出处:享受编程和技术所带来的快乐 – http://coolshell.cn

根据我现有的阅读和谈话,我所理解的今天Facebook的架构如下:

  • Web 前端是由 PHP 写的。Facebook 的 HipHop [1] 会把PHP转成 C++ 并用 g++编译,这样就可以为模板和Web逻贺业务层提供高的性能。
  • 业务逻辑以Service的形式存在,其使用Thrift [2]。这些Service根据需求的不同由PHP,C++或Java实现(也可以用到了其它的一些语言……)
  • 用Java写的Services没有用到任何一个企业级的应用服务器,但用到了Facebook自己的定制的应用服务器。看上去好像是重新发明轮 子,但是这些Services只被暴露给Thrift使用(绝大所数是这样),Tomcat太重量级了,即使是Jetty也可能太过了点,其附加值对 Facebook所需要的没有意义。
  • 持久化由MySQL, Memcached [3], Facebook 的 Cassandra [4], Hadoop 的 HBase [5] 完成。Memcached 使用了MySQL的内存Cache。Facebook 工程师承认他们的Cassandra 使用正在减少,因为他们更喜欢HBase,因为它的更简单的一致性模型,以到其MapReduce能力。
  • 离线处理使用Hadoop 和 Hive。
  • 日志,点击,feeds数据使用Scribe [6],把其聚合并存在 HDFS,其使用Scribe-HDFS [7],因而允许使用MapReduce进行扩展分析。
  • BigPipe [8] 是他们的定制技术,用来加速页面显示。
  • 用来搞定用户上传的十亿张照片的存储,其由Haystack处理,Facebook自己开发了一个Ad-Hoc存储方案,其主要做了一些低层优化和“仅追加”写技术 [11].
  • Facebook Messages 使用了自己的架构,其明显地构建在了一个动态集群的基础架构上。业务逻辑和持久化被封装在一个所谓的’Cell’。每个‘Cell’都处理一部分用户,新 的‘Cell’可以因为访问热度被添加[12]。 持久化归档使用HBase [13]。
  • Facebook Messages 的搜索引擎由存储在HBase中的一个倒置索引的构建。 [14]
  • Facebook 搜索引擎实现细节据我所知目前是未知状态。
  • Typeahead 搜索使用了一个定制的存储和检索逻辑。 [15]
  • Chat 基于一个Epoll 服务器,这个服务器由Erlang 开发,由Thrift存取 [16]

关于那些供给给上述组件的资源,下面是一些信息和数量,但是有一些是未知的:

  • Facebook估计有超过60,000 台服务器[16]。他们最新的数据中心在俄勒冈州的Prineville,其基于完全自定设计的硬件[17] 那是最近才公开的 Open Compute 项目[18]。
  • 300 TB 的数据存在 Memcached 中处理 [19]
  • 他们的Hadoop 和 Hive 集群由3000 服务器组成,每台服务器有8个核,32GB的内存,12TB的硬盘,全部有2万4千个CPU的核,96TB内存和36PB的硬盘。 [20]
  • 每天有1000亿的点击量,500亿张照片, 3 万亿个对象被 Cache,每天130TB的日志(2010年7月的数据) [21]

参考引用

[1] HipHop for PHP: http://developers.facebook.com/blog/post/358
[2] Thrift: http://thrift.apache.org/
[3] Memcached: http://memcached.org/
[4] Cassandra: http://cassandra.apache.org/
[5] HBase: http://hbase.apache.org/
[6] Scribe: https://github.com/facebook/scribe
[7] Scribe-HDFS: http://hadoopblog.blogspot.com/2009/06/hdfs-scribe-integration.html
[8] BigPipe: http://www.facebook.com/notes/facebook-engineering/bigpipe-pipelining-web-pages-for-high-performance/389414033919
[9] Varnish Cache: http://www.varnish-cache.org/
[10] Facebook goes for Varnish: http://www.varnish-software.com/customers/facebook
[11] Needle in a haystack: efficient storage of billions of photos: http://www.facebook.com/note.php?note_id=76191543919
[12] Scaling the Messages Application Back End: http://www.facebook.com/note.php?note_id=10150148835363920
[13] The Underlying Technology of Messages: https://www.facebook.com/note.php?note_id=454991608919
[14] The Underlying Technology of Messages Tech Talk: http://www.facebook.com/video/video.php?v=690851516105
[15] Facebook’s typeahead search architecture: http://www.facebook.com/video/video.php?v=432864835468
[16] Facebook Chat: http://www.facebook.com/note.php?note_id=14218138919
[17] Who has the most Web Servers?: http://www.datacenterknowledge.com/archives/2009/05/14/whos-got-the-most-web-servers/
[18] Building Efficient Data Centers with the Open Compute Project: http://www.facebook.com/note.php?note_id=10150144039563920
[19] Open Compute Project: http://opencompute.org/
[20] Facebook’s architecture presentation at Devoxx 2010: http://www.devoxx.com
[21] Scaling Facebook to 500 millions users and beyond: http://www.facebook.com/note.php?note_id=409881258919

(全文完)


分类: Architecture, Facebook 标签: