在PB级数据上提供SQL查询是一回事，但在Facebook规模上交付SQL查询则完全是另一回事。今年早些时候，这家社交媒体巨头将Alluxio分布式文件系统实施到其庞大的数据体系结构中，以加快查询速度，同时保持计算和存储的分离。
长期以来，Facebook一直是开源软件的拥护者，它在大数据空间中产生了开源项目的份额。Apache Hive及其后续产品Presto以及Facebook RocksDB和Apache Cassandra都来自Facebook。GraphQL是PyTorch和Facebook一起推出的众多开发人员工具之一。
Facebook是Apache Hadoop的早期采用者，而Hadoop的残余在该公司的体系结构中仍然很明显。它已经不再将数据存储在Hadoop群集中，而是仍然使用HDFS来访问Warm Storage中的数据，Warm Storage是Facebook脱离Hadoop后为其自身开发的自定义分布式文件系统。Facebook软件工程师James Sun告诉我们，Warm Storage充当BLOB存储在大量旋转磁盘之上的功能，与Google Colossus或Amazon S3并无不同，它使用同步Reed-Solomon纠错编码来大规模增强数据弹性。
计算和存储的分离是现代计算机体系结构的基础，并且是许多组织如今努力的方向。但是对于Facebook来说，将计算和存储区分开是绝对必要的，因为由于浪费的存储或计算容量而造成的成本会迅速增加。
在内部，Facebook是Presto的主要用户，可为临时交互式SQL查询，A / B测试提供支持，并为关键的仪表板提供服务，例如每日活跃用户（DAU）和每月平均用户（MAU）。作为没有存储组件的计算引擎，Presto非常适合将计算与存储区分开的公司（毕竟这就是Facebook发明它的原因）。
虽然Presto在Facebook上表现不错，但物理学却没有。为了将SQL查询延迟保持在可行的范围内（即大约一秒钟），几年前Facebook实施了数据缓存策略。该系统被称为Raptor，要求用户建立ETL管道以在连接到Presto群集的SSD上缓存数据。
Raptor提供了Facebook所需的查询速度，因为不再需要通过网络传播许多Presto查询。但是Raptor在此过程中还产生了其他问题。
Facebook在其Raptor缓存系统的优缺点之间陷入困境（图片由Facebook提供）
首先，通过将计算和存储连接在一起，消除了该公司分别扩展规模的能力，这很糟糕。据Sun称，这还导致数据碎片化和用户体验下降，因为有时查询访问巨大的Warm Storage数据湖，有时查询访问本地SSD中缓存的数据。这也使安全性和隐私变得复杂，因为现在Facebook工程师不仅要担心保护Warm Storage中的数据，还要担心这些本地SSD中的数据。
去年秋天，Facebook开始实施Raptor的替代产品。新系统基于Alluxio的定制版本，提供了与Raptor相当的查询性能，但无需在本地SSD上缓存数据。
Alluxio是一个虚拟的分布式文件系统，充当基于内存的粘合剂，将多个计算引擎与多个后端存储系统连接起来。它是由加州大学伯克利分校AMPLab的Li Haoyuan“ HY” Li于2013年创建的。AMPLab的顾问兼Databricks的联合创始人Ion Stoica 曾说过，Alluxio的存在就是存储，就像Internet协议（IP）就是Internet。
Alluxio是一个分布式文件系统，可加速从多个存储系统到多个计算引擎的数据流
Facebook与同名开源软件项目背后的公司Alluxio合作，开发了定制版本的Alluxio文件系统，该系统将作为Java库运行。该版本由Alluxio在2.2版中公开发布，它没有提供完整的Alluxio产品的所有功能，但它提供了Facebook需要的核心优势。
Facebook工程师Sun解释说：
他告诉Datanami： “我们所做的是，在Facebook的整个Presto互动团队中安装了Alluxio缓存。” “我们大多已弃用Raptor，这意味着通常[用户]无需编写ETL作业或任何管道即可将Warm Storage数据转储到本地SSD中。他们只是不这样做。他们只是直接查询Warm Storage，而Alluxio缓存库将为您完成。”
Facebook以ORC文件格式存储数据，并通过HDFS接口将其提供给Presto（该公司仍然使用HDFS，但不再使用Hadoop）。Sun表示，Alluxio实施可以与SSD配合使用，并使用它们在本地存储数据以加快处理速度，但是本地缓存不是必需的，并且当不存在SSD时，Alluxio还可以加快对热存储的查询。
通过在Facebook数据中心的数百个节点上安装Alluxio，Facebook用户可以享受与Raptor相当的性能。他们可以继续提交大型复杂的查询，这些查询涉及可能超过PB数据的表顶上的大量联接和聚合。如果没有Alluxio或Raptor，这些查询最多可能需要10秒才能返回答案，这对于Facebook来说是不可行的。在遇到经常查询的表的更简单查询中，Alluxio为Presto工作负载提供了30％到50％的提升，这本身就是重要的。
根据James，Facebook软件工程师Rohit Jain和Alluxio联合创始人工程师Bin Fan 在7月的演讲中说，相对于Raptor，Alluxio缓存使远程数据存储（Warm Storage）的读取减少了57％。Alluxio缓存的命中率（意味着请求的数据驻留在本地SSD缓存中的次数）超过90％。
Alluxio缓存系统可以在Facebook上使用或不使用SSD（图片由Facebook提供）
“一旦出现未缓存的大数据请求，它就会降低我们的缓存命中率，”以前担任惠普Trafodion项目负责人的Jain说。“我们正在努力为应该缓存的内容进行更好的配置。”
主要收益来自财务和安全。由于其Presto计算引擎再次独立于数据存储，因此Facebook可以通过不过度配置计算或存储来节省资金。在安全方面，Facebook不再需要担心保护SSD中的数据，而可以将更多精力用于保护Warm Storage中的数据。
“ Alluxio不仅将提高查询性能，而且将杀死Raptor等存储孤岛，因此，我们不再需要关心安全性，隐私或HA或DR，因为Warm Storage会处理它， ”孙说。“ [缓存的]数据将存储在SSD上，但这不是语义。没有语义上的含义。只是一点而已。”
Sun说，Raptor今天还没有完全消失，但是应该在六个月内完全消失。
文章来源：https://www.datanami.com/2020/08/31/how-facebook-accelerates-sql-at-extreme-scale/
