基于SparkSQL与Tachyon的PINGO架构

　PINGO是一个由百度大数据部与百度美国研发中心合作而成的分布式交换查询平台。在PINGO之前，百度的大数据查询作业主要由基于Hive的百度QueryEngine去完成。QueryEngine很好的支持着百度的离线计算任务，可是它对交互式的在线计算任务支持并不好。为了更好的支持交互式任务，我们在大约一年前设计了基于SparkSQL与Tachyon的PINGO的雏形。在过去一年中， 通过跟不同业务的结合，PINGO逐渐的演变成一套成熟高效的交互式查询系统。本文将详细介绍PINGO的架构迭代过程以及性能评估。
　　PINGO设计目标
　　QueryEngine是基于Hive的百度内部的大数据查询平台，这套系统在过去几年中较好的支撑了百度的相关业务。 图1展示了QueryEngine的架构图，其服务入口叫做Magi。用户向Magi提交查询请求， Magi为这次请求分配一个执行机， 执行机会调用Hive读取Meta信息并向Hadoop队列提交任务。 在这一过程中， 用户需要自行提供计算需要的队列资源。随着近几年对大数据平台的要求越来越高， 我们在使用QueryEngine过程中也发现了一些问题：首先QueryEngine需要由用户提供计算资源， 这使得数据仓库的用户需要去了解Hadoop以及相关的管理流程， 这增加了用户使用数据的门槛。 第二， 对于很多小型计算任务而言， MR的任务的起动时间也较长， 往往用户的计算任务只需要1分钟， 但是排队/提交任务就需要超过一分钟甚至更长的时间。这样的结果是，QueryEngine虽然很好的支持线下执行时间长的任务，但是对线上的一些交换式查询任务（要求延时在一到两分钟内）确是无能为力。
　　
　　图1： Query Engine 的执行流程
　　为了解决这些问题， 在大约一年前，我们尝试在离线计算的技术栈上搭建起一套具有在线服务属性的SQL计算服务 PINGO。如图2所示： PINGO使用了SparkSQL为主要的执行引擎， 主要是因为Spark具有下面的特点：
　　内存计算：Spark以RDD形式把许多数据存放在内存中，尽量减少落盘，从而提升了计算性能。可常驻服务：Spark可以帮助实现常驻式的计算服务， 而传统的Hadoop做不到这一点。常驻式的计算服务有助于降低数据查询服务的响应延迟。机器学习支持：对于数据仓库的使用， 不应仅仅局限于SQL类的统计任务。 Spark的机器学习库可以帮助我们将来扩展数据仓库， 提供的交互式的数据挖掘功能。计算功能多元：虽然PINGO是一个查询服务， 不过仍然有其他类型的计算需求， 如数据预处理等。 使用Spark可以使我们用一个计算引擎完成所有的任务， 简化系统的设计。
　　
　　图2： PINGO初版系统架构设计