#数据技术选型#即席查询Shib+Presto，集群任务调度HUE+Oozie

郑昀创建于2014/10/30 最后更新于2014/10/31

一）选型：Shib+Presto

应用场景：即席查询（Ad-hoc Query）

1.1.即席查询的目标

使用者是产品/运营/销售运营的数据分析师；

要求数据分析师掌握查询SQL查询脚本编写技巧，掌握不同业务的数据存储在不同的数据集市里；

不管他们的计算任务是提交给数据库还是 Hadoop，计算时间都可能会很长，不可能在线等待；

所以，

使用者提交了一个计算任务（PIG/SQL/Hive SQL），控制台告知任务已排队，给出大致的计算时间等友情提示，这些作业的权重较低，

使用者和管理员可以查看排队中的计算任务，包括已执行任务的执行时间、运行时长和运行结果；

当计算任务有结果后，控制台界面有通知提示，或者发邮件提示，使用者可以在线查看和下载数据。

1.2.即席查询的当下技术选型

图形交互界面：Shib；

数据查询引擎：Facebook Presto。

1.3.为什么要更换数据查询引擎？

基于 MapReduce 的 Hadoop 适合数据批处理，但不适合即席查询场景。基于 InnoDB/MyISAM 存储引擎的 MySQL 自然也不适合。当然我们也观察过 InfiniDB/InfoBright 这种列式存储数据库引擎（仍基于MySQL），它们更适合基本不再变更的历史归档数据，所以不太适合电商应用场景。

我们的鹰眼（Tracing）项目就曾折翼在即时查询上，后端的 HBase 扛不住在大数据量下的实时插入和查询。

『Hive 更适合于长时间的批处理查询分析，Impala、Shark、Stinger和Presto 适用于实时交互式SQL查询，它们给数据分析师提供了快速实验、验证想法的大数据分析工具。所以可以先使用 Hive 进行数据转换处理，之后使用这四个系统中的一个在 Hive 处理后的结果数据集上进行快速的数据分析。

Impala、Shark、Stinger和Presto四个系统都是类SQL实时大数据查询分析引擎，但是它们的技术侧重点完全不同。而且它们也不是为了替换Hive而生，Hive在做数据仓库时是非常有价值的。这四个系统与Hive都是构建在Hadoop之上的数据查询工具，各有不同的侧重适应面，但从客户端使用来看它们与Hive有很多的共同之处，如数据表元数据、Thrift接口、ODBC/JDBC驱动、SQL语法、灵活的文件格式、存储资源池等。』——《开源大数据查询分析引擎现状，2014》

最终我们选择了 Presto。

FaceBook于2013年11月份开源了Presto，一个分布式SQL查询引擎，它被设计为用来专门进行高速、实时的数据分析。它支持标准的ANSI SQL，包括复杂查询、聚合（aggregation）、连接（join）和窗口函数（window functions)。Presto设计了一个简单的数据存储的抽象层，来满足在不同数据存储系统（包括HBase、HDFS、Scribe等）之上都可以使用SQL进行查询。

Presto 简化的架构如下图1所示，客户端将 SQL 查询发送到 Presto 的协调器。协调器会进行语法检查、分析和规划查询计划。调度器将执行的管道组合在一起，将任务分配给那些离数据最近的节点，然后监控执行过程。客户端从输出段中将数据取出，这些数据是从更底层的处理段中依次取出的。

Presto 的运行模型与 Hive 有着本质的区别。Hive 将查询翻译成多阶段的 Map-Reduce 任务，一个接着一个地运行。每一个任务从磁盘上读取输入数据并且将中间结果输出到磁盘上。然而 Presto 引擎没有使用 Map-Reduce。它使用了一个定制的查询执行引擎和响应操作符来支持SQL的语法。除了改进的调度算法之外，所有的数据处理都是在内存中进行的。不同的处理端通过网络组成处理的流水线。这样会避免不必要的磁盘读写和额外的延迟。这种流水线式的执行模型会在同一时间运行多个数据处理段，一旦数据可用的时候就会将数据从一个处理段传入到下一个处理段。

这样的方式会大大的减少各种查询的端到端响应时间。

同时，Presto 设计了一个简单的数据存储抽象层，来满足在不同数据存储系统之上都可以使用 SQL 进行查询。存储连接器目前支持除 Hive/HDFS 外，还支持 HBase、Scribe 和定制开发的系统。