案例库 · 软件与 IT · 技术决策 · 2012–2018
Presto 让 Facebook 的分析师能在 PB 级数据上进行交互式 SQL 查询
一个分布式 SQL 引擎在内存中直接在工作节点之间流式传输结果,将数小时的仓库查询变成几秒到几分钟的交互体验。
Facebook (Presto)
那一手
Facebook 的数据仓库当时运行在 Hadoop 上的 Hive 上,一次典型查询可能要花几个小时:批处理没问题,但对需要反复试错的分析师来说毫无用处。2012 年,由 Martin Traverso 等人领导的团队开始构建 Presto,这是一个分布式 SQL 引擎,专为针对同一数据仓库的交互式查询而设计。
Presto 的设计绕开了 MapReduce 那种“落盘再读盘”的来回。协调器负责规划查询,并以流式方式将查询任务分发到一棵工作节点树上,树上的内存操作符处理数据,这些数据通过连接器 API 直接从数据源读取:如今支持 HDFS 和 S3,通过同一接口还可访问关系型数据库和 NoSQL 系统,甚至能在一个查询中同时访问多个系统。代码生成和向量化执行让每行处理的 CPU 开销保持在低水平。
2013 年在 Facebook 上线后,Presto 逐渐支撑起面向用户的分析工具、仪表盘和 A/B 测试基础设施,截至 2018 年底,每天处理数百 PB 数据和千万亿行数据,集群包含数千个工作节点。
为什么管用
- 流式操作符避免了阶段之间代价高昂的磁盘读写
- 一个 SQL 引擎就能统一访问 HDFS、S3、关系型数据库和 NoSQL 数据源
- 内存流水线让交互式延迟成为可能
- 代码生成和向量化执行降低了 CPU 开销
可以搬走什么
对分析而言,交互性就是一个产品:一个在内存和 CPU 之间流式传输结果的引擎,可以在不改变底层仓库的情况下,将批处理文化转变为查询文化。
后来呢
Presto 后来开源,成为部署最广泛的查询引擎之一:到 2019 年,它已经运行于 Uber、Netflix、Airbnb、Bloomberg 和 LinkedIn,并为 Amazon Athena 提供支持,同时也有 Starburst、Qubole 和 Treasure Data 提供的商业发行版。它的 GitHub 仓库至今仍将其介绍为用于大数据场景的分布式 SQL 查询引擎。
资料来源
- Presto: SQL on Everything
- prestodb/presto: The official home of the Presto distributed SQL query engine
发现哪里写错了?告诉我们。