Facebook是如何加速SQL查询

在PB级别的数据上进行查询是一件事,如何在Facebook这种级别的产品上使用则是另外一件事。今年早期时候,他们把Alluxio分布式文件系统集成到了他们的数据架构上,实现了存储和计算的分离,以此用来加速查询。

Facebook很早就使用Apache hadoop,并且到现在还可以在Facebook的架构中看到他。它们已经把数据存储从Hadoop clusters中移开了,但是仍然使用HDFS在Warm Storage中访问数据,这是一个由Facebook开发的定制的分布式文件系统,用来在分离Hadoop之后进行数据存储的。

Facebook内部使用了很多Presto来进行SQL查询,A/B testing以及服务一些关键的仪表,比如每日的活跃用户(DAU)或者每月的平均用户等等。作为一个没有存储模块的计算单元,Presto对计算和存储分离的架构非常友好。

为了让SQL查询的延时在一个可以工作的范围(比如在一秒左右),几年之前,Facebook实现了一个数据Caching的策略。Dubbed Raptor,这个系统要求用户在Presto cluster的SSD上创建ETL pipeline来cache数据。

Raptor加速了查询的速度,因为很多查询都再也不用通过网络了,但是同时也带来了很多别的问题。

开始的时候,把计算和存储放在一起,就限制了公司去把他们分开来扩展,这显然是不好的。它也导致了数据的碎片化,从而降低了用户的体验,这主要是因为查询有时会hit warm storage,有时会hit 本地SSD的cache。而且它也是的数据的安全和隐私保护更加复杂,因为你不仅仅要保护Warm Storage中的数据,还需要保护本地SSD的数据。

去年秋天,Facebook开发实现Raptor的替代方案。它是基于Alluxio,这个新的系统的查询性能和Raptor类似,但是不需要在SSD中cache数据。

Alluxio是一个虚拟的分布式文件系统,它连接了多个计算引擎和后端存储系统。它是由Haoyuan在UC伯克利 AMPLab开发的。Facebook基于Alluxio开发了一个新的版本,让它可以在Java上运行。

Facebook使用ORC文件格式来存储数据,并且通过HDFC接口来让Presto访问。Alluxio的实现可以在SSD上工作,并且把数据存储在本地,从而加速访问,但是本地的cache却不再需要了,而且Alluxio也可以在没有SSD的情况下使用Warm storage来加速访问。

当Alluxio在上百个Facebook数据中心的节点上安装之后,用户就可以体验到和之前Raptor类似的查询性能。它们可以使用很多Join的查询来查询PB级别的数据,没有Alluxio或者Raptor之前,这些查询可能需要超过10s才能返回。在一些能够hit oft-queried表格的查询,Alluxio可以相比Prestor负载提高了30%到50%,这显然是一个不错的提升。

根据James七月份的报告,相比于Raptor,Alluxio cache减少了57%从远端数据存储单元读取的操作。Alluxio cache的hit rate查过了90%。

Jain说,现在还有一个问题,就是当有很大的数据请求过来的时候,就很容易让cache的hit rate降低,它们现在正在想办法解决这个问题。

这个方案的另外一个优点是金钱和安全,因为Presto计算单元和数据存储是分开的,这样可以分开进行提升,而不会有浪费。在安全性方面,也不需要再担心SSD上数据的安全,而只需要关注warm storage上数据的安全即可。

当然Raptor也没有完全被取代,不过预计在未来六个月会被完全取代。

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *