Facebook图片存储架构技术全解析
Facebook平台的架构
例6-1：书籍数据映射的例子
book_get_info : isbn -> {title, author, publisher, price, cover picture} book_get_reviews: isbn -> set(review_ids) bookuser_get_reviews: books_user_id -> set(review_ids) review_get_info: review_id -> {isbn, books_user_id, rating, commentary}
6.1.2 一些Facebook 核心数据
随着所谓“ Web 2.0”的网络技术逐渐流行，数据在系统中的核心地位就变得更明显了。 Web 2.0 展现的核心主题就是它们是数据驱动的，用户本身提供了绝大部分的数据。 Facebook 像 一样，主要由一组核心数据映射构成，它们驱动 着网站的观感和功能。这些Facebook映射的极端精简集合看起来如例6-3所示。
110
第章
关系数据，可能不完全适用于给定的数据集。但不管怎样，在每一步我们都给出了一个 实际的问题、一个数据驱动的解决方案，以及该解决方案的高层实现。对于每个新的解 决方案，我们基本上会创建一个新的产品或平台，所以在任何时候我们都必须让这个新 产品符合用户的预期。反过来，我们会伴随每一步的演进创造一些新技术，有时候会改 变围绕应用的Web架构。 Facebook 平台的开源版本可以从 / 获得。就像这个版本一 样，本章的代码是用 PHP 写的。请随意查看，不过请注意，出于清晰性的考虑，这里的 代码是缩写过的。 我们从这些类型的集成的动机开始，通过一个例子来讲解一个“外部的”应用逻辑和数 据（一个书店） 、Facebook的社会关系数据（用户信息和朋友关系） ，以及它们的集成。
FACEBOOK与人人网的网站后台架构对比
FACEBOOK与人人网的网站后台架构对比作为国内外SNS站点的代表，Facebook和人人网在后台技术应用上还是有很多不同的地方，当然，造成这种不同的原因有很多。
这里我们将对比Facebook和人人网的后台架构，在找出这些差异的同时，我们也能够看出，跟国外相比，国内SNS网站的后台技术差距还有多大？差距在哪里？后台语言的选择作为一个大型站点，后台语言的选择意味着不同的架构路线、以及不同的开发框架。
考虑到SNS网站后台架构的复杂性，可选择的语言并不多，Facebook作为一个大型LAMP网站，选择了PHP；而人人网则使用Java。
当然，PHP和Java各具优势，PHP+MySQL的黄金搭档被无数站点所使用；在评价Java的优势时，黄晶老师说道，“而当项目日渐复杂的时候，Java 则能通过其良好的OO特性，保持非常好的模块性，也有益于网站重构。
”后台语言的选择有很多因素，选择哪种语言也并不重要，关键是要适合相应的生产环境，这里比较PHP与Java的优劣并没有太大的意义。
但要说明的是，每种语言都有它的劣势，如何进行有效的优化才是开发者们需要思考的，就像Facebook为PHP量身打造了HipHop那样。
数据库在后台架构中，数据库一直是我们关心的重点。
曾经日壮山河的关系型数据库，在NoSQL运动下，仿佛显得日薄西山，这句话用在SNS站点中再合适不过了。
没错，由于SNS站点的高复杂性，其对数据库的要求非常高，高性能、可扩展性以及可用性，缺一不可。
Facebook并不是一个传统意义上的LAMP站点，MySQL也主要作为一个Key-value的持久性存储使用，而它的存储系统则是NoSQL运动的一个重要组成部分——Cassandra，它的特点也正是SNS站点所需求的，尽管很多人认为NoSQL还不够成熟，缺乏可靠性，但Facebook 的成功却是一个活生生的例子。
Facebook数据库架构图，请点击原图查看通过黄晶老师的介绍我们了解到，其实人人网也不只是在使用MySQL。
Facebook架构体系
Facebook 的技术分享一，设计原则1尽可能的使用开源软件，并且在需要优化的时候进行优化2 Unix 哲学。
包括，模块化原则；整合化原则；清晰化原则等3任何组件具备扩展性4最小化故障影响5简化，简化，简化！二，架构概览Facebook 是LAMP 的坚定支持者，也差不多是用LAMP （或许用LAM2P 更适合）实现的最大的动态站点。
基础组件加上服务，中间用自己实现的一些工具进行粘合。
其中关于运维细节的事情基本不会说出来的，这是很多公司的软实力所在。
三，PHP 经验参见《Facebook 的PHP 性能与扩展性》四，MySQL 经验1主要用于做Key-Value 类型的存储操作，数据随机分布在多台逻辑实例上，访问多数基于全局ID 。
2逻辑实例分散在多台物理主机上（超过1800台），负载均衡在物理层进行。
3不做读复制。
4尽量不做逻辑数据迁移（成本太高）。
5不做JOIN 操作（豆瓣在QCon 上也阐述了这一点）。
数据是随机分布的，关联操作反而带来了极大的复杂度。
6对于数据访问，主要的操作集中在最新的数据上，针对这部分做优化，旧的数据进行归档。
7在中心DB 绝不存储非静态数据。
8使用服务或者Memcached 进行全局查询。
五，Memcached 经验参见我以前的笔记：Facebook 的Memcached 扩展经验。
Facebook 对Memcached 做了不小的改进。
另外，顺便说一下，前两天Memcached 刚在 1.2.7 发布几天之后又发布了新版本1.2.8，修正了一些问题。
一个比较有价值的是关于个人页面数据的获取的描述。
这个就完全是需要做单页面Benchmark 的细致活儿了，可能还需要产品经理能够理解工程师的“抵抗”。
1获取个人信息数据：通过Cache，隐性通过用户所在的DB 获取（基于User-ID 获知DB）2获取朋友连接信息：通过Cache，否则的话通过DB（基于User-ID 获知DB）3并行抓取每个朋友的10个照片相册ID ，从Cache抓取，如果失效，再从DB 抓取（基于相册ID）4并行抓取最近相册中的照片数据5运行PHP 把整个业务逻辑跑出来6返回数据给用户然后是对Facebook 非LAMP 体系的东西做了一番介绍，基本上也开源了。
横向扩展(Facebook)网站系统架构
横向扩展（Facebook）网站系统架构网摘简介本文是原作者就职于Facebook时，构建新数据中心时，对MySQL进行横向扩展时，处理缓存一致性和性能的一些方法。
我于2007年四月加入了Facebook，在结束了几周的课程之后，我的经理Robert Johnson来找我。
我们谈了很久，不过内容可以归结为：Bobby: “那么，Jason，我们要在2008年之前在弗吉尼亚开一个新的数据中心。
你能去帮点忙吗？”Me: “呃…. 可以?”Bobby: “很好！”我在Facebook的第一个项目上投入的要比我预期的多一点点，但是我认为这是为何我们拥有如此一个非常强大的工程组织的原因；我们还有很多难题有待解决，这里每个人都迫不及待要立刻去解决他们。
我开始了解为何我们需要建造一个新的数据中心以及我们需要解决什么问题才能让他正常工作。
有何必要？在东海岸建造一个新的数据中心的主要原因就是“延迟”。
在一个高速连接上发送一个包横穿大陆需要大概70微秒的时间，而对于普通的互联网用户而言，可能会需要的时间就长得多。
通过将服务器放在弗吉尼亚，我们可以大大减少给东海岸和欧洲的用户传送网页的时间。
第二个关注点是空间、能源和灾难恢复。
在我们位于加利福尼亚的主数据中心中已经没有多少物理空间了，而弗吉尼亚的点可以给我们充分的空间添加东西。
我们还有一个类似问题就是要给予充足的电能驱动所有的服务器。
最后，如果把我们限制在某个单独的地方，意味着如果出现灾难事件（断电、地震、怪兽），可能会导致Facebook长时间无法访问。
开始构建！在我们能处理应用级的问题之前，我们的小组在弗吉尼亚投入了大量的心血构建服务器和物理空间。
他们还完成了数据中心之间的网络和低延迟光线通道连接。
这些工作是非常巨大的工程，然而我们顶尖的团队使之看上去像是小菜一碟。
网络和硬件都到位后，我们搭建了标准的3层架构：Web服务器，memcache服务器和MySQL数据库。
FaceBook架构分析
03 FaceBook基本架构 04 浅谈FaceBook的
服务器架构
PART ONE
FaceBook简介
FaceBook简介
Facebook是一个社会化网络站点，它于2004年2月4日 上线。每个用 户在facebook上有自己的档案和个人页面，用 户之间可以通过各种方式发生互动：留言、发站内信，评论 日志。虽然目前在国内无法访问 facebook，但其强悍的技术 架构还是值得我们去研究分析和总结的，或许我们可以从中 得到一点启发。
• 例如，聊天窗口，新闻Feed等是通过分块分开进行传输的。这些 pagelets可以并行工作，不仅可以提高性能，而且即使其中一部分失效或 中断，也不影响用户的正常访问。
13
Cassandra
• Cassandra是一个可以避免单点故障的分布式存储系统。它 是NoSQL运动的一个典范，并已开放源代码（它甚至成为一 个Apache项目）。
23
PART FOUR
浅谈FaceBook的服务器架构
大体层次划分-角度1
一边是PHP整的经典的LAMP stack；另外一边是非PHP的各种service
Facebook的页面 从刚创立的时候 扎克伯格写的， 到现在，都用 PHP开发。后端 有用各种语言开 发的service。它 们之间用跨语言 的thrift RPC通信 (Scribe也是建立 在Thrift之上)。
facebook消息使用自己的架构值得注意的是这个架构是一个共享的基础架构并且是劢态集群管理的业务逻辑和持久化被封装在称为cell的东西中每一个cell都是使用者的一部分新的cell可以自由的添加
软件13008班 组长：杨渊 组员ook简介
介绍Facebook在机器学习方面的软硬件基础架构,来满足其全球规模的运算需求
介绍Facebook在机器学习方面的软硬件基础架构，来满足其全球规模的运算需求2017年末，Facebook应用机器学习组发布最新论文，对整个Facebook的机器学习软硬件架构进行了介绍。
纵览全文，我们也可以从中对Facebook各产品的机器学习策略一窥究竟。
论文中涉及到机器学习在全球规模(上亿级数据处理)上的全新挑战，并给出了Facebook的应对策略和解决思路，对相关行业和研究极其有意义。
摘要机器学习在Facebook的众多产品和服务中都有着举足轻重的地位。
本文将详细介绍Facebook在机器学习方面的软硬件基础架构，如何来满足其全球规模的运算需求。
Facebook的机器学习需求极其繁杂：需要运行大量不同的机器学习模型。
这种复杂性已经深深刻在Facebook系统堆栈的所有层面上。
此外，Facebook存储的所有数据，有相当大一部分会流经机器学习管道，这样的数据载荷为Facebook的分布式高性能训练流带来巨大的压力。
计算需求也非常紧张，在保持用于训练的GPU/CPU平台的同时平衡出大量CPU容量用于实时推理，也带来了异常紧张的。
这些问题及其他难题的解决，仍有待我们在跨越机器学习算法、软件和硬件设计上持久而不懈的努力。
引言Facebook的使命是“为人类构建社交关系赋能，让世界联系更加紧密”。
截至2017年12月，Facebook已经连接了全球超过20亿的人口。
同时，过去几年来，机器学习同样在这样一种全球尺度的实际问题上进行着一场革命，包括在机器学习算法创新方面的良性循环，用于模型训练的海量数据以及高性能计算机体系结构的进步。
在Facebook上，机器学习几乎在提升用户体验的所有层面都发挥着关键作用，包括诸如新闻推送语音和文本翻译以及照片和实时视频分类的排名等服务。
Facebook在这些服务中用到了各种各样的机器学习算法，包括支持向量机，梯度boosted 决策树和许多类型的神经网络。
本文将介绍Facebook的数据中心架构支持机器学习需求。
存储空间在下面的介绍中，我们会对于上述的每个功能层做详细的讲述。
存储空间Haystack 部署在商业存储刀片服务器上，典型配置为一个2U的服务器，包含：两个4核CPU16GB – 32GB 内存硬件 RAID，含256-512M NVRAM 高速缓存超过12个1T B SATA 硬盘每个刀片服务器提供大约10T B的存储能力，使用了硬件 RAID-6, RAID 6在保持低成本的基础上实现了很好的性能和冗余。
不佳的写性能可以通过RAID控制器和NVRAM缓存回写解决，写由于读取大多是随机的，NVRAM缓存是完全用于写入的。
文件系统Haystack 对象库是建立在10T B容量的单一文件系统之上。
图片读取请求需要在读取系统调用这些文件的位置偏移，但是为了执行读取操作，文件系统必须先找到实际物理卷上的数据。
文件系统中的每个文件都被一个叫做inode结构标识。
inode包含了一个磁盘上逻辑文件偏移和物理区块偏移的映射。
在使用的特殊类型文件系统时大文件块映射可能相当大。
基于文件系统的区块为给个逻辑区块和大文件保存映射。
这些信息通常不适合保存在inode的缓存中，而是存储在在间接地址块。
所以在读取文件的时候必须按照特定的流程。
这里可以多个是间接地址块，所以一个读取会产生多个I/O取决于是否间接地址块被缓存。
该系统只为连续范围的区块保持映射。
一个连续的大文件的块映射可以只由一个范围的标识，这样是适应inode的系统需求的。
但是，如果该文件是一个被切割的不连续的块的话，他的块地图可能非常的大。
以上可以通过文件系统主动为大的物理文件分配大块的空间来减少碎片。
目前使用的文件系统为XFS，一个很大程度提供高效的文件预分配系统。
Haystack 对象存储Haystack 是一个简单的日志结构（只能追加），存储着其内部数据对象的指针。
一个 Haystack 包括两个文件，包括指针和索引。
下面的图片将描述haystack存储文件的布局：haystack最前面的8K存储是被超级块占用。
Facebook 的系统架构
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] 是他们的定制技术，用来加速页面显示。
∙Varnish Cache [9]用作HTTP代理。
他们用这个的原因是高速和有效率。
[10].∙用来搞定用户上传的十亿张照片的存储，其由Haystack处理，Facebook自己开发了一个Ad-Hoc存储方案，其主要做了一些低层优化和“仅追加”写技术[11].∙Facebook Messages 使用了自己的架构，其明显地构建在了一个动态集群的基础架构上。
a1-基于某Facebook和Flash平台地应用架构解析汇报
本系列文章（共分三部分）将为你介绍基于Facebook和Flash平台的应用程序架构，解析你能在此平台上构建的各种应用类型，并说明这些应用如何与你的服务器、Facebook服务器通讯。
可构建的应用类型你可构建三种Flash与Facebook平台集成的应用：基于Facebook的嵌入式应用、对外服务的Web应用和桌面应用。
基于Facebook的嵌入式应用，部署在你自己的服务器上，但其用户通过Facebook站点访问。
用户看到的是一个将你的应用包容其中的Facebook容器。
你访问Facebook上的某个应用（通常是因为收到朋友邀请，或搜索某个应用时得到一个链接）时，Facebook服务器会将请求转发给你的应用服务器，得到一个页面（HTML和Javascript代码），最后在Facebook站点上展示出来。
这种方式对于访问Facebook 站点的用户而言，提供的体验是无缝的。
这类应用的例子很多，比如来自Playfish和Zyng德克萨斯扑克的谁有最聪明的大脑应用。
提供对外服务的独立Web应用，也部署在你自己的服务器上，但用户通过你提供的URL而不是Facebook站点来访问该应用。
在外部站点中，你可以通过Facebook API和Facebook Connect来增加Facebook的特性。
比如利用Facebook API实现用户登录，应用在一个新的浏览器窗口中打开Facebook登录页面，用户必须在这里登录后，才能访问你本身的应用。
为了避免在 Facebook站点上登录，为用户提供无缝体验，你就需要使用Facebook Connect了。
比如，某用户阅读一篇博客后，可能想写点评论。
那么不必让用户在你的站点上再注册一个账号吧，用他/她在Facebook上的帐户就好了。
为提升用户体验，Facebook API和Facebook Connect还允许你访问用户的全部数据，比如在评论旁边显示评论者的姓名和个人图片。
Facebook的时序数据库技术（上）
Facebook的时序数据库技术（上）Facebook的时序数据库技术(上)本⽂介绍Facebook内部监控系统所⽤到的时序数据库技术，为了避免⽂章过长，将拆成两篇⽂章来介绍，此为上篇。
声明：此⽂核⼼内容源⾃Facebook在2015年发表的论⽂《Gorilla: A Fast, Scalable, In-Memory Time Series DataBase》, 但本⽂⼤部分内容为笔者在精读论⽂以后做的总结，内容组织形式也有较⼤的出⼊。
本⽂所有的图⽚均源⾃该论⽂。
基本概念以监控数据为例，介绍时序数据库的两个重要概念”Time Series”与“Data Point”：Time Series⼀个数据源的⼀个指标，按固定时间间隔产⽣的源源不断的监控数据，称之为Time Series，中⽂通常将其翻译成”时间线”。
”按固定时间间隔”是⼀种理想假设，会存在少量的异常情形。
例如：我们希望收集每⼀台物理机上的CPU使⽤率信息，物理机Host A上的CPU 1，就是⼀个确定的数据源，⽽CPU使⽤率就是指标信息，假设我们收集指标的时间间隔为5秒钟，那么，Host A上CPU 1上按5秒钟间隔产⽣的所有指标数据，就称之为⼀个Time Series，⽽物理机Host A上的CPU 2的CPU使⽤率信息则属于另外⼀个独⽴的Time Series。
从这个定义上来看，⼀个Time Series本⾝是⽆时间边界的，只能说，在某⼀个时刻，最⽼的与最新的指标数据是什么。
Data PointTime Series中按固定时间间隔产⽣的每⼀条监控数据，称之为⼀个Data Point。
即，Data Point是构成Time Series的基本数据单元。
继续上⾯的例⼦，Host A的CPU 1的每⼀条CPU使⽤率信息，就是⼀个Data Point。
⼀个Data Point中⾄少包含两个关键组成部分：Timestamp信息，Point Value信息（具体的指标值）。
Facebook数据中心-无需空调的数据中心
Facebook数据中心曝光机密信息一览无遗一.Facebook数据中心概括【PConline 资讯】据来自Google的Double Click服务标准显示，Facebook是目前世界上最受欢迎的网站，每月有超过6900亿的页面浏览量。
而根据Hitwise的调查显示Facebook目前约占9.5%的互联网流量，比谷歌还要略多。
因此Facebook需要大量的存储基础设施来容纳其巨大的照片储存，其中稳定增长的是每一天用户都要新增100万个新的照片。
每月人们在Facebook上分享超过300亿条内容。
此外，Facebook的基础设施必须支持超过1万个网站和550,000个应用程序使用Facebook的平台服务连接平台。
Facebook位于俄勒冈州普林维尔旗帜事实上，在Facebook发展初期，都是通过租赁第三方数据中心来实现业务增长的，这些第三方数据中心一般都会采取升高地板以及利用高效供电、制冷等基础设施。
但是，这些空间往往在不到5个月的时间就会被Facebook的数据所占据，而通常建一个大型数据中心需要12个月的时间，租赁而不自建的这种发展模式，才能使得处于初期发展Facebook的基础设施规模跟得上用户的增长速度。
随着绿色节能的数据中心不断提出，Facebook也在努力使自己的数据中心更便宜，更高效。
为支持这样巨大的工程，Facebook在位于俄勒冈州普林维尔(Prineville) 耗资上千万美元打造了一座未来派节能型数据中心。
该数据中心是Facebook自行建造的首个数据中心。
Facebook鸟瞰图与普通数据中心相比，Facebook数据中心的能效高38%，建造成本低24%。
Facebook公开了数据中心的所有信息，旨在推进整个数据中心产业的发展，并逐渐弱化谷歌的最大优势之一。
facebook logo首先映入眼帘的是Facebook巨大的LOGO，环视四周发现Facebook数据中心利用密集布置的太阳能电池板收集太阳能。
Facebook数据中心建设模式分析
（一 ）采用简 单的基础设施架构 ．实现快速安装 Ｆａｃｅｂｏｏｋ数据 中心 部署速度之快 在业 内是 出名 的。数 万 平米 的数 据 中心 ．十 来个 月就 可 以试 运行 了。Ｆａｃｅｂｏｏｋ数据 中心 能够快速上线投产 的最重要 的原 因就是简单 。 建筑本身没有传统 的数据 中心繁复 ．没有太 多的 隔墙 ，不需要结构降板 ．不需要架空地板 ，也没设置 复杂的综合管架 。 机 电设施 也 比传 统 数据 中心 简单 很 多 ．其 配 电 和 制 冷 系 统 需 要 安 装 的组 件 ，特 别 是 只 能现 场 制 作 的 复杂组件 ．远 远少于传统 的数 据中心 。比如 不需要冷 机 、ＵＰＳ．空调机组等设备 ．也就 没有连接的管路 、 阀门、线 缆等工程 内容 。即使 是那些需要安 装的设备 也属于重复 性非常高 、安 装要 求相对简单 的设施 ｛如 定制 的框架式风 扇，湿膜加湿模块 框架式过 滤模块 等 ） 这样就更容易实现工厂定制和快速安装 。 瑞典 的ｌｕｌｅａ是Ｆａｃｅｂｏｏｋ第一个 不在 本土 的数 据 中心 ．建造 管理 相 对 困难 ，加之 气候 寒 冷 ．可施 工 的季节 短 暂 ，数据 中心 可 以快速 部 署 的优势 就显 得 更 为 重 要 。 为 此 ．Ｆａｃｅｂｏｏｋ定 制 了 大 量 的 预 制 组 件 ， 包 括 土 建 设 施 ，机 电 设 施 ．这 些 部 件 采 用 现 场 拼 装 的 方 式 进 行 建 设 ，大 大 提 升 了 建 设 速 度 ， 取 得 了不错的效果 。 （二 ）选择适宜的建设 地点 ，实现快速建造 Ｆａｃｅｂｏｏｋ选址特 意避开 了土地资源相 对匮乏 的 地 区 ，这样 可 以采 用经 济 性更 好 的单层 钢结 构 的形 式 ｛尽 管 土地 利用 率较 低 ） ，这在 地广 人 稀的 海外 是 非 常多见 的 ，是 大规 模厂 房最 简单 最 常用 的 土建
FaceBook架构分析
FaceBook设计原则 facebook的设计原则是 模块化 原则、整合化 原则、清
晰化 原则，其架构设计的目标是简单 、高效 。facebook的 架构是基于LAMP，差不多是用LAMP实现的最大的动态站点。
facebook架构图 概览
06
PART THREE
FaceBook网站架构 软件详情
Facebook级别规模的挑战
• Facebook每月的PV量：630,000,000,000 （6千3百亿）。 • Facebook上的图片数量超过其他图片网站的总和。 • 每个月有超过30亿的图片上传到Facebook • Facebook系统每秒可以处理120万张图片。这还不包括
Facebook的CDN处理的图片。 • 每月处理超过250亿的信息内容（包括用户状态更新，评论等） • Facebook的服务器数量超过3万台（此数据为2009年的数据）
09
Memcached
• Memcached是当今互联网上最著名的软件之一。它是一 个分布式的内存缓存系统，Facebook（包含其他很多网 站）用它作为Web服务器和MySQL服务器之间的缓存层 （因为数据库访问相对比较慢）。多年来，Facebook已 经对Memcached和它的周边软件进行了很多优化，比如 对network stack的优化。
• 一个工程师小团队在Facebook（一开始只有三人）花了18个 月时间开发HipHop已经投入正式使用。
11
Haystack
• Haystack是Facebook的高性能图片存取系统（严格来说， 是一个对象存储系统，因此它并不仅限于存储照片）。 Haystack的工作量超大；要管理超过200亿张上传的照片， 并且每一片照片被保存为四种不同的分辨率，因此有超过 800亿张照片。
Facebook广告账户结构搭建逻辑
账户结构“记得刚开始做优化师的时候，我的Leader在让人教会了我基础操作之后，对我说：‘你要开始投放了，先想想你的账户结构，然后就上广告吧。
’当时的我听到这个句话是有点蒙圈的，账户结构是什么？难道不是上广告就完事了嘛？”时至今日，再去想账户结构上的事情，也更加深刻的理解到了账户结构的重要性。
首先我们来看一张图：投放过Facebook广告的人都知道，这是最基本的Facebook广告构架图。
在Campaign层级主要是确定投放目标，AdSet层级能设置的东西比较多，出价，用户定位，预算，优化方式等都可以在这个层级进行设置，Ad 层级就是素材。
这个构架图就已经很清楚的告诉了我们，有哪些东西是需要我们去设置的，哪些方面是可以设置对比组的。
比如在AdSet层级，可以根据用户定位不同设置对比组，也可以根据地理位置不同设置对比组，只要了解清楚每个层级可以变动的因素有哪些，而那些可变动的因素就是我们可以设置对比组的方式。
再加上有些出价和兴趣等方面的组合也有很多种，综合下来，账户的对比实验如果都要设置的话，其实是设置不完的。
初期上手的时候，一开始都是不停的去做广告上新，更多的是素材层面的对比测试，留下好的素材，去掉或者优化效果不好的素材。
这时候的所有的账户结构其实就是最基本的素材测试。
而素材的不同，可以从Ad层级区分开，也可以用AdSet层级区分开。
如图：这就是最简单的两种以素材为变量进行的广告结构设置。
为了方便迭代和后期优化，很多有经验的优化师会选择以CampaignA的形式来进行初期的素材迭代。
根据迭代结果再进一步去做其他Campaign优化。
在这里不说哪种结构更优，只是通过简单的列举来说明白同一测试目标下广告框架的不同形式。
以上只是单一的以素材为测试变量下的账户结构选择，现实情况下，我们其实除了素材的更迭之外，还有国家的不同，优化方式的不同等需要我们去进行迭代测试的地方，广告框架的多样性就越加明显。
确认优化核心优化的本质就是不断的做AB测试，去劣存优。
揭秘Facebook首个数据中心：全球15亿用户的账户信息都在这里
揭秘Facebook首个数据中心：全球15亿用户的账户信息都在这里Prineville 数据中心是 Facebook 的第一个数据中心。
它目前拥有三座大型建筑，最小的一座占地 35 万平方公尺；最新的一座数据中心占地 45 万平方公尺。
三座建筑中的每一座都足够容纳一个火箭发射器，而且还能空出不少空间来。
我们通过图片来看一下：略显高调的标牌其他公司一般不会在自家的数据中心旁边放上一个标牌，但是Facebook 不这样。
这是它在 Prineville 建筑群旁边设置的入口标志。
水和太阳能Facebook 之所以选择在荒无人烟的俄勒冈州建立数据中心，就是为了利用这里的冷空气，来替代空调的服务器冷却功能。
在图片中我们也能看到有一个巨大的储水池，是为了在天气变热时起到冷却作用。
在用电方面，这个数据中心占用了当地电网所供应的大多数电量，不过 Facebook 也采用太阳能来发电。
备用设备如果数据中心出了问题，技术人员就会从这个房间里拿出一些备用设备。
它们每一个都贴上了条形码，也一直有人在保管着。
无处不在的服务器Facebook 不使用空调来调节温度，所以在服务器机房里，不那么嘈杂，温度也比较舒适。
图片左侧的服务器存储的是用户的账户信息。
还是服务器这些服务器主要负责承载 Facebook 的社交网络数据。
过道：每一条过道两边大概有 24 个服务器架子。
服务器细节 1：下面这张图可以更清楚地看到服务器的细节。
这里出现的蓝光是LED 灯发出的。
服务器细节 2：看看就好~ 排热：为了冷却CPU，需要从外部抽入冷风，然后再将冷风引到图中的过道中来。
当冷风变热，就会被排出去。
与这个建筑的其他方位不同，这些过道很嘈杂，而且很热。
风扇：这张图展示的是服务器的风扇。
Big Sur该数据中心安放了 Facebook 的Big Sur 人工智能服务器。
每一台都安装了8 个英伟达的高端芯片。
这些服务器看起来比Facebook 的其他服务器厚一点。
facebook架构纵览完整版资料
能F能FFF能 FFF能能能能 能能能能F能FFF能F能能能能能能aaaaaaaaaaaa够够够够够够够够够够够够够够够够够够够cccccccccccceeeeeeeeeeee在 在 为在 在 在 服在 为 在 服 在 为 在 在 服 在 在 在bbbbbbbbbbbboooooooooooo毫毫各 毫毫毫务 毫各毫务毫各毫毫务毫毫毫ooooooooooookkkkkkkkkkkk秒秒种 秒秒秒P秒种秒P秒种秒秒P秒秒秒的的的的的的的的的的的的BBB级级应 级级级级应级级应级级级级级级 级级目设设目设目设设设目设目别别用 别别别别用别别用别别别别别别 别别标计计标计标计计计标计标时时程 时时时时程时时程时时时时时的 的的原原原原原原原间间序 间间间间序间间序间间间间间数 数数则则则则则则则服服提 服服服服提服服提服服服服服据 据据务务供务务务务供务务供务务务务务上上服 上上上上服上上服上上上上上亿亿务 亿亿亿亿务亿亿务亿亿亿亿亿次次的 次次次次的次次的次次次次次的的平 的的的的平的的平的的的的的并并台 并并并并台并并台并并并并并发发发发发发发发发发发发发请请请请请请请请请请请请请求求求求求求求求求求求求求
ห้องสมุดไป่ตู้
设计目标和原理
Facebook的目标 能够为各种应用程序提供服务的平台
不仅仅是社区网站 基础设施的高扩展性 应用程序的高扩展性 能够服务PB级别的数据 能够在毫秒级别时间服务上亿次的并发请求
Facebook的设计原则 尽量使用开源工具 Unix设计哲学 平台中，什么都是可扩展的 高负载，低延迟 简单实用的原则
facebook的信息结构
Facebook的特别之处在哪里····为什么在facebook交友会更容易？facebook与传统的BSP（Blog Service Provider）到底有什么不同？是因为它有横竖两个导航吗？是因为它有个主人信息的聚合页面吗？ Facebook为什么成功？又有哪些不足？Facebook商业上的成功使得它混乱的设计成了皇帝的新装，即使觉得看不懂也不敢去说。
让我们拨开网页上那些纷繁的视觉表现，来看看藏在网页背后骨架—信息构架（IA Information Architecture），我们将获得一个全新视角，这种种疑问将迎刃而解。
传统的博客服务提供商（Blog Service Provider，简称BSP），比如：Qzone、新浪博客、网易博客…他们提供的博客服务，不仅仅是为每一位注册用户提供了一个属于自己的blog空间，还有用于bloger间彼此交流的平台。
也就是说，信息构架是：个人空间+社区平台。
“个人空间+社区平台”是什么样子的？一个个的blog彼此独立存在，再由一个社区平台将这些blog聚合一起，通过内容聚合在一起。
左上角的第一个表示主人态，主人可以看到BSP提供的所有服务，其中的B、D、E是他自己已经使用了的。
而下面一个个的是其他人的blog，其他人的blog包含的内容各不相同，有的用了相册，有的用了日志，有的用了视频…目前多数的BSP都是简单的把ABCDEF 都简单的呈现给客人，不管主人用不用。
图中右半部分是社区平台，以内容为维度，展示内容，进而展示用户。
比如，A 代表日志，社区平台上会有个日志栏目，其中展示出很多有意思的日志，要看这篇日志，就到达另外一个人的blog了。
交流实现了，所谓平台，价值也就在于此。
Blog原本就是一个个独立的，有了BSP提供blog服务后，才出现了社区平台，让用户能更方便的找到其他人。
不仅仅是自己写给别人看，更可以用方便的找到志同道合的人，让众多bloger形成一个社区。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
由于每个图像存储在自己的文件内，所以根据命名空间目录和文件inode（内节点），在存储层产生了大量的元数据。这些元数据量远远超过了NFS存储层的缓存能力，导致了上传和读取每张照片时成倍的I/O操作。整个照片服务的基础架构由于NFS存储层的大量元数据负荷而成为了一个瓶颈，这就是Facebook严重依赖CDNs来提供照片服务的原因之一。以下两个附加的优化部署，用来在一定程度上减轻这个问题：
Cachr ：一个缓存服务层，用来缓存Facebook中较小的“个人资料”图像。
NFS文件句柄缓存——部署在照片服务层，消除了一些NFS存储级元数据负荷
Haystack照片基础架构
新的照片基础架构将照片服务层和存储层合并为一个物理层。它实现了一个基于HTTP的照片服务器，把照片存储在名为Haystack的通用对象中。对于新层次的主要要求是消除任何照片读取操作的不必要的元数据开销，使每个读取I/O操作只是读取实际照片数据（而不是文件系统元数据）。Haystack可划分为以下一些功能层-
第一个8KB的Haystack存储由超级块所占用。紧接着超级块的是指针，每个指针由页眉、数据、和页脚组成。
一个指针是由其﹤Offset（偏移量）, Key, Alternate
Key(替换键),Cookie﹥元组唯一确定，其中偏移量是指在Haystack存储中的指针偏移量。Haystack对于关键字的值没有任何限制，有的指针可以有多个关键字。下图显示的是索引文件的结构布局—
◆2 x 4核CPUs
◆16GB – 32GB内存
◆具有256MB – 512MB NVRAM缓存的硬件RAID控制器
◆12+ 1TB SATA驱动器
每个存储片提供大约10TB的可用空间，配置为一个RAID-6分区，由硬件RAID控制器进行管理。RAID
◆HTTP服务器
◆照片存储
◆Haystack对象存储
◆文件系统
◆存储设备
以下各节中，我们会自底向上密切关注每一个功能层。
存储设备
Haystack部署于日常存储片之上。一个2U存储片的典型硬件配置的是-
照片应用程序是Facebook最流行的功能。直至目前为止，Facebook的用户已经上传了超过150万幅照片，这使得Facebook成为最大的照片共享网站。对于每一个上传的照片，
Facebook生成并保存成4种不同大小的图像，即总共有60亿的图片占1.5PB的存储容量。目前的增长速度是每星期220万个新照片，即每周消耗25TB的额外存储空间。在高峰期，平均每秒会上传550,000幅图像。这些数字给Facebook的照片存储基础架构带来了严重的挑战。
在Haystack存储文件中，每个指针有一个相应的索引纪录，而且指针索引纪录的顺序必须与Haystack存储文件中相关的指针顺序相匹配。索引文件提供查找Haystack存储文件中某一特定指针所需的最小元数据。为了快速查找，把索引记录载入并组织到一个数据结构中，这是Haystack应用程序（在我们的情况下是照片存储）的职责。索引文件不是至关重要的，因为它可以根据所需从Haystack存储文件中重建。索引的主要目的是可以快速加载指针元数据到内存中，而无须遍历庞大的Haystack存储文件，这是因为索引的大小通常还不到存储文件的1％。
照片存储删除操作
在调用Haystack删除操作之后，内存中的索引被更新，设置特定图像的偏移量为0来表示该图像已经被删除。
压缩
压缩是一个联机操作，可以回收已被删除的指针和重复指针（具有相同关键字的指针）所占用的空间。它通过复制指针创建一个新的Haystack，跳过所有重复和已删除的指针。每次这样做，就会交换文件和内存中文件的结构。
当用户上传一个照片，该照片就被分配一个唯一的64位编号。然后将照片转化为4个不同大小的图片。每个图片具有相同的随机Cookie和64位关键字，合理的图像大小（大，中，小，缩略图）是储存在替换键中。然后上传服务器调用照片存储服务器，把所有4个图像存储在Haystack中。
内存中的索引为每张照片保存以下信息：
。
照片存储服务器
照片存储服务器负责接收HTTP请求，并转化成相应的Haystack存储操作。为了尽量减少读取照片所需的I/
O操作次数，服务器在内存中保存一个Haystack存储文件中所有照片偏移量的索引。启动时，服务器读取Haystack索引文件并生成一个内存中的索引。由于每个节点数以亿计的照片（并且该数字只会随着更大容量的驱动器而增加），我们必须确保该索引能够装入可用的内存中。这是通过在内存中保留最少数量的元数据来实现，只保留查找照片所需的信息。
Haystack不允许覆盖已存在的指针偏移量，因此，如果某个指针的数据需要修改，其修改后的新版本必须使用相同的﹤Key, Alternate
Key, Cookie﹥元组。然后应用程序就可以认为，在那些有着多个关键字的指针中，具有最大偏移量的指针就是最新添加的指针。
Haystack使用开源Google稀疏散列数据结构来减小内存中的索引，因为使用它，每条记录只占2位。
照片存储写/修改操作
ห้องสมุดไป่ตู้
写操作写入照片到Haystack，并更新内存索引。如果该索引中已经包含了具有相同关键字的记录，那么这就是一个修改现有照片的操作，那么只修改索引记录偏移量，以反映新图像在Haystack存储文件中的位置。照片存储总是假设存在重复的照片（具有相同关键字的照片），只有存储在最大偏移量位置的照片是有效的。
Facebook图片存储架构技术全解析
Haystack提出了一种通用的基于HTTP的对象存储，它含有指针，映射到存储对象。在Haystack中以指针储存照片，把数以十万计的图像聚集到一个Haystack存储文件，从而消除了元数据负荷。这就使得元数据的开销非常小，并且使我们能够在存储文件和内存索引中存储每个指针的位置。这就使得能用少量的I/O操作来完成图像数据的检索，可以消除一切不必要的元数据开销。
索引文件还会定期被刷新到下面的存储设备，以便限制由硬件故障所引起的恢复操作的程度。在系统崩溃或突然断电的情况下，Haystack恢复程序丢弃所有存储中的不完整的指针，同时截断Haystack存储文件直到最后一个有效的指针，然后，在Haystack存储文件最后为所有跟踪的孤立指针写入丢失的索引记录。
NFS照片基础架构
旧的照片基础架构包含几个层次：
◆上传层接收用户上传的照片，测量原始图像的大小并将其保存到NFS存储层。
◆照片服务层接收HTTP照片请求，并向用户提供保存于NFS存储层的照片。
◆NFS存储层建立于商业存储设备之上。
目前，所选择的文件系统是的XFS，基于范围的文件系统提供有效文件预分配。
Haystack对象存储
Haystack是一个简单日志结构（只追加）的对象存储，包含描述存储对象的指针。一个Haystack包括两个文件——实际的包含指针的Haystack存储文件，以及一个索引文件。下图显示了Haystack存储文件的结构布局：
HTTP服务器
我们使用的HTTP框架是由开源lib
event图书馆所提供的简单的evhttp服务器。我们使用多线程，同一时间内，每个线程能够处理一个HTTP请求。因为我们的工作量最主要是由I/O操作产生，因此HTTP服务器的性能并不是至关重要的。
Haystack删除操作
删除操作很简单——通过设置指针的标记域中的一个“deleted（已删除）”
标记位，标记Haystack存储中的指针为已删除。然而，相关的索引记录并不进行任何方式的修改，因此一个应用程序可能会结束于引用某个已删除的指针。对于这样的指针的读操作会注意到“deleted”标记，然后终止操作，提示操作错误，给出错误信息。已删除的指针的空间不会以任何方式回收。回收已删除指针的空间的唯一方法是压缩c（见下文）
基于块的文件系统为每个逻辑块维护其映射信息，对于大文件，这些映射信息将不会像通常那样存入缓存的inode，而是储存在间接地址块，读取文件数据时需要进行转换。间接转化可能存在好几个层次，因此，根据间接地址块是否被缓存，单一的读取可能会导致若干个I/O操作。
基于范围的文件系统只为连续的块（区域）维护映射信息。对于一个连续大文件的块映射只由一个区域组成，此区域的大小正好可以装入inode之中。但是，如果该文件是严重地分散和不连续的，其区块在卷中不连续，那么其块映射可以随之增长。有了基于范围的文件系统，就可以通过积极分配一大块空间来减少碎片。
6提供了足够的冗余性和出色的读取性能，可以降低存储成本。RAID控制器NVRAM回写高速缓存可以部分缓解低劣的写性能。由于读取大多是随机的，所以NVRAM缓存完全保留给写操作。磁盘高速缓存被禁用，以保证在系统崩溃或电源断电时数据的一致性。
文件系统
Haystack对象存储实现于一个文件之上，该文件存储在一个单一文件系统上，该文件系统建立于10TB volume（卷）大小的空间之上。
Haystack写操作
Haystack写操作同步添加新的指针到Haystack存储文件中。当指针成功添加到庞大的Haystack存储文件中之后，相应的索引记录也被写入索引文件。由于索引文件不是至关重要的，为了达到更快的性能，该索引记录是异步写。
Haystack读操作
传递给Haystack读操作的参数包括指针偏移量、关键字、替换键、Cookie和数据大小。然后Haystack添加页眉和页脚的大小到数据大小中，并从文件中读取整个指针。只有当关键字、替换键和Cookie符合参数类型，所传递的数据通过校验，并且指针没有被之前的操作删除时，读操作才能成功（见下文）。
照片读取请求导致read()系统调用请求读取文件中不同偏移量的信息，但为了执行读取操作，文件系统必须首先在实际物理卷上找到数据。在文件系统中，每个文件的是由一个名为inode的结构所描述，该结构包含一个块映射，可以把逻辑文件偏移量映射到物理卷中的物理块偏离量。对于大文件，根据所使用的文件系统类型的不同，块映射可能会相当庞大。