Facebook技术体系窥探之P级数据 | ChenQJ | On the Road

Facebook技术体系窥探之P级数据

Posted on 2010/11/25 by chenqj

我们来看一下Facebook处理P级数据的两个案例：图片存储和数据仓库

Facebook目前是世界上最大的图片共享网站，用户上传了超过20亿的图片，每张图片会被处理成四种分辨率，所以总的存储在80亿以上。为了存储这些图片，图片存储方案经过了三个阶段的改进

第一阶段，使用商用的NFS做文件存储，庞大的图片数量产生了大量的元数据，远远超过了NFS的缓存能力，导致I/O居高不下

第二阶段，建立自己的缓存层，将较小的图片（小头像）放入叫做“Cachr”的缓存系统中，同时，对NFS文件句柄做缓存

第三阶段，新的图片体系：Haystack。Haystack将服务层和存储层合并为一个物理层，实现了一个基于HTTP的图片服务器，把图片存储在名为Haystack的通用对象存储中，目标是减少图片读取时不必要的元数据读取操作。Haystack图片体系在功能上可以分为：HTTP Server，Photo Store，Haystack Object Store，FileSystem，Storage几个部分。

Storage是普通的2U存储刀片服务器，有超过12个1TB的SATA硬盘，采用RAID6做冗余。FileSystem采用XFS文件系统。

Haystack Object Store采用日志模式，只支持追加操作。存储文件由连续的Needle组成，每个Needle代表一个对象。用于做图片存储时，包含了图片的实际数据以及header和footer。Needle可以通过<Offset, Key, Alternative Key, Cookie>唯一标示

Haystack Store 还包括一个索引文件，每个Needle都在索引文件中有对应的索引记录，且顺序一致。索引文件提供了查找Haystack store file中的needle所必须的最小的metedata。索引文件可以通过haystack store file重建。索引文件的大小一般小于store文件的1%。

Photo Store启动时会将索引文件加载到内存中重新组织，图片是通过一个64位的Key在内存中定位的。获取图片的Offset和size后就可以在Haystack Object Store中读取实际的图片数据了

HTTP框架是使用了libevent提供的evhttp server。使用多线程，同一时间内，每个线程能够处理一个HTTP请求。因为主要负载在I/O操作，因此HTTP服务器的性能并不是至关重要的。

Facebook通过Scribe收集了大量的数据日志，每天的增量超过了10T，这些数据日志可以帮助广告推送、NewsFeed生成，好友推荐，入侵检测等。如何在可控时间内完成这些海量数据的挖掘工作成为了一大难题。最初，Facebook采用传统的数据挖掘方案，但随着数据量的增大任务运行的时间越来越长，并不具备可扩展性。于是Facebook开始尝试使用Hadoop，并在使用过程中开发了自己的数据仓库系统Hive。如今Facebook的Hive-Hadoop 集群拥有超过2250台机器和23000个核心，数据容量超过36PB，大部分任务通过Hive完成，每天有超过25000个Hive Jobs在运行。整个系统体系如下图所示

整个系统通过Scribe收集日志，经过过滤后存储在Scribe-Hadoop集群上，成为Hive-Hadoop 生产集群的数据源之一。另外一个数据源则是系统存储数据的Mysql集群。Hive-Hadoop生产集群运算完成后，将运算结果写回到Mysql集群中，或者送到Orcale RAC中做进一步的挖掘。同时，还通过Hive复制将数据推送到一个Adhoc Hive-Hadoop 集群，用来为业务分析人员提供Adhoc查询。为了方便业务分析人员使用Hive，Facebook还开发了一个Web工具叫HiPal

在数据收集部分，Facebook在Scribe和HDFS的基础上开发了一个接近实时的数据收集系统，称之为DataFreeway系统。数据流如下所示

 

从图片存储和Hive-Hadoop方案可以看出，面对海量数据，Facebook仍延续他们一贯的实用风格，积极使用开源工具，或是构建简单实用的方案。这里没有科学家，只有解决问题的开发工程师