SQL on Hadoop技术综述与主流SQL
SQL on Hadoop技术综述
一、系统架构
runtime framework v.s. mpp
在SQL on Hadoop系统中，有两种架构：
1、一种是基于某个运行时框架来构建查询引擎，典型案例是Hive；
2、另一种是仿照过去关系数据库的MPP架构，就是参考过去的MPP数据库架构打造一个专门的系统，于是就有了Impala，Presto等等。
前者现有运行时框架，然后套上sql层，后者则是从头打造一个一体化的查询引擎。
对于SQL on Hadoop系统很重要的一个评价指标就是：快。
DAG v.s. MR：最主要的优势，中间结果不写磁盘（除非内存不够），一气呵成。
- 流水线计算：上游stage一出结果马上推送或者拉到下一个stage处理，比如多表join时前两个表有结果直接给第三个表，不像MR要等两个表完全join完再给第三个表join。
- 高效的IO：本地查询没有多余的消耗，充分利用磁盘。这个后面细说。
- 线程级别的并发：相比之下MR每个task要启动JVM，本身就有很大延迟，占用资源也多。
MPP模式也有其劣势：
- 一个是扩展性不是很高，这在关系数据库时代就已经有过结论；
- 另一个是容错性差，对于Impala来说一旦运行过程中出点问题，整个查询就挂了。
但是，经过不断的发展，Hive也能跑在DAG框架上了，不仅有Tez，还有Spark。上面提到的一些劣势，其实大都也可以在计算模型中解决。基于Spark的Spark SQL完全不逊色于Presto，基于Tez的Hive也不算很差，至少在并发模式下能超过Presto，足见MPP模式并不是绝对占上风的。
二、核心组件
不管是上面提到的那种架构，一个SQL on Hadoop系统一般都会有一些通用的核心组件，这些组件根据设计者的考虑放在不同的节点角色中，在物理上节点都按照master/worker的方式去做
三、执行计划
编译流程
从SQL到执行计划，大致分为5步。
- 第一步将SQL转换成抽象语法树AST。这一步一般都有第三方工具库可以完成，比如antlr。
- 第二步对AST进行语义分析，比如表是否存在，字段是否存在，SQL语义是否有误（比如select中被判定为聚合的字段在group by中有没有出现）。
- 第三步生成逻辑执行计划,这是一个由逻辑操作符组成的DAG。比如对于Hive来说扫表会产生TableScanOperator，聚合会产生GroupByOperator。对于类MPP系统来说，情况稍微有点不同。逻辑操作符的种类还是差不多，但是会先生成单机版本，然后生成多机版本。多机版本主要是把aggregate，join，还有top n这几个操作并行化，比如aggregate会分成类似MR那样的本地aggregate，shuffle和全局aggregate三步。
- 第四步做逻辑执行计划做优化。
- 第五步把逻辑执行计划转换成可以在机器上运行的物理计划。
四、优化器
关于执行计划的优化，虽然不一定是整个编译流程中最难的部分，但却是最有看点的部分，而且目前还在不断发展中。Spark系之所以放弃Shark另起炉灶做Spark SQL，很大一部分原因是想自己做优化策略，避免受Hive的限制。早期在Hive中只有一些简单的规则优化，比如谓词下推（把过滤条件尽可能的放在table scan之后就完成），操作合并（连续的filter用and合并成一个operator，连续的projection也可以合并）。后来逐渐增加了一些略复杂的规则，比如相同key的join + group by合并为1个MR，还有star schema join。
但是，基于规则的优化（RBO）不能解决所有问题。在关系数据库中早有另一种优化方式，也就是基于代价的优化CBO。CBO通过收集表的数据信息（比如字段的基数，数据分布直方图等等）来对一些问题作出解答，其中最主要的问题就是确定多表join的顺序。CBO通过搜索join顺序的所有解空间（表太多的情况下可以用有限深度的贪婪算法），并且算出对应的代价，可以找到最好的顺序。这些都已经在关系数据库中得到了实践。
五、存储格式
对于分析类型的workload来说，最好的存储格式自然是列存储，这已经在关系数据库时代得到了证明。目前hadoop生态中有两大列存储格式，一个是由Hortonworks和Microsoft开发的ORCFile，另一个是由Cloudera和Twitter开发的Parquet。
ORCFile顾名思义，是在RCFile的基础之上改造的。RCFile虽然号称列存储，但是只是“按列存储”而已，将数据先划分成row group，然后row group内部按照列进行存储。
ORCFile已经弥补了这些特性，包括：
- 块过滤与块统计：每一列按照固定行数或大小进一步切分，对于切分出来的每一个数据单元，预先计算好这些单元的min/max/sum/count/null值，min/max用于在过滤数据的时候直接跳过数据单元，而所有这些统计值则可以在做聚合操作的时候直接采用，而不必解开这个数据单元做进一步的计算。
- 更高效的编码方式：RCFile中没有标注每一列的类型，事实上当知道数据类型时，可以采取特定的编码方式，本身就能很大程度上进行数据的压缩。常见的针对列存储的编码方式有RLE（大量重复数据），字典（字符串），位图（数字且基数不大），级差（排序过的数据，比如日志中用户访问时间）等等。
Parquet的设计原理跟ORC类似，不过它有两个特点：
- 通用性：相比ORCFile专门给Hive使用而言，Parquet不仅仅是给Impala使用，还可以给其他查询工具使用，如Hive、Pig，进一步还能对接avro/thrift/pb等序列化格式。
- 基于Dremel思想的嵌套格式存储：关系数据库设计模式中反对存储复杂格式（违反第一范式），但是现在的大数据计算不仅出现了这种需求（半结构化数据），也能够高效的实现存储和查询效率，在语法上也有相应的支持（各种UDF，Hive的lateral view等）。Google Dremel就在实现层面做出了范例，Parquet则完全仿照了Dremel。
多数据源查询：Presto支持从mysql，cassandra，甚至kafka中去读取数据，这就大大减少了数据整合时间，不需要放到HDFS里才能查询。Impala和Hive也支持查询hbase。
近似查询：count distinct（基数估计）一直是sql性能杀手之一，如果能接受一定误差的话可以采用近似算法。Impala中已经实现了近似算法（ndv），Presto则是请blinkDB合作完成。两者都是采用了HyperLogLog Counting。
主流SQL on Hadoop总结
使用SQL 引擎一词是有点随意的。例如Hive 不是一个引擎，它的框架使用MapReduce、TeZ 或者Spark 引擎去执行查询，而且它并不运行SQL，而是HiveQL，一种类似SQL 的语言，非常接近SQL。“SQL-in-Hadoop” 也不适用，虽然Hive 和Impala 主要使用Hadoop，但是Spark、Drill、HAWQ 和Presto 还可以和各种其他的数据存储系统配合使用。不像关系型数据库，SQL 引擎独立于数据存储系统。相对而言，关系型数据库将查询引擎和存储绑定到一个单独的紧耦合系统中，这允许某些类型的优化。另一方面，拆分它们，提供了更大的灵活性，尽管存在潜在的性能损失。
前世今生
查询分析是大数据要解决的核心问题之一，自从Google在2006年之前的几篇论文奠定云计算领域基础，尤其是GFS、Map-Reduce、Bigtable被称为云计算底层技术三大基石。GFS、Map-Reduce技术直接支持了Apache Hadoop项目的诞生。Bigtable和Amazon Dynamo直接催生了NoSQL这个崭新的数据库领域，撼动了RDBMS在商用数据库和数据仓库方面几十年的统治性地位。FaceBook的Hive项目是建立在Hadoop上的数据仓库基础构架，提供了一系列用于存储、查询和分析大规模数据的工具。当我们还浸淫在GFS、Map-Reduce、Bigtable等Google技术中，并进行理解、掌握、模仿时，Google在2009年之后，连续推出多项新技术，包括：Dremel、Pregel、Percolator、Spanner和F1。其中，Dremel促使了实时计算系统的兴起，Pregel开辟了图数据计算这个新方向，Percolator使分布式增量索引更新成为文本检索领域的新标准，Spanner和F1向我们展现了跨数据中心数据库的可能。
在Google的第二波技术浪潮中，基于Hive和Dremel，新兴的大数据公司Cloudera开源了大数据查询分析引擎Impala，Hortonworks开源了Stinger，Fackbook开源了Presto。类似Pregel，UC Berkeley AMPLAB实验室开发了Spark图计算框架，并以Spark为核心开源了大数据查询分析引擎Shark。Hive、Impala、Shark、Stinger和Presto的进化图谱如下图所示
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-53tobN6t-1619950785505)(img\进化图谱)]
基于Map-Reduce模式的Hadoop擅长数据批处理，不是特别符合即时查询的场景。实时查询一般使用MPP (Massively Parallel Processing)的架构，因此用户需要在Hadoop和MPP两种技术中选择。
在Google的第二波技术浪潮中，一些基于Hadoop架构的快速SQL访问技术逐步获得人们关注。现在有一种新的趋势是MPP和Hadoop相结合提供快速SQL访问框架。当前热门的开源工具包括：Impala、Shark（SparkSQL)、Stinger(Hive on Tez)和Presto。这也显示了大数据领域对于Hadoop生态系统中支持实时查询的期望。总体来说，Impala、Shark、Stinger和Presto四个系统都是类SQL实时大数据查询分析引擎，但是它们的技术侧重点完全不同。而且它们也不是为了替换Hive而生，Hive在做数据仓库时是非常有价值的。这四个系统与Hive都是构建在Hadoop之上的数据查询工具，各有不同的侧重适应面，但从客户端使用来看它们与Hive有很多的共同之处，如数据表元数据、Thrift接口、ODBC/JDBC驱动、SQL语法、灵活的文件格式、存储资源池等。Hive与Impala、Shark、Stinger、Presto在Hadoop中的关系如下图所示。Hive适用于长时间的批处理查询分析，而Impala、Shark、Stinger和Presto适用于实时交互式SQL查询，它们给数据分析人员提供了快速实验、验证想法的大数据分析工具。可以先使用Hive进行数据转换处理，之后使用这四个系统中的一个在Hive处理后的结果数据集上进行快速的数据分析。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xMKBDlKr-1619950785508)(img\sql)]
- Hive：披着SQL外衣的Map-Reduce。Hive是为方便用户使用Map-Reduce而在外面封装了一层SQL，由于Hive采用了SQL，它的问题域比Map-Reduce更窄，因为很多问题，SQL表达不出来，比如一些数据挖掘算法，推荐算法、图像识别算法等，这些仍只能通过编写Map-Reduce完成
- Impala：Google Dremel的开源实现（Apache Drill类似），因为交互式实时计算需求，Cloudera推出了Impala系统，该系统适用于交互式实时处理场景，要求最后产生的数据量一定要少
- **Shark/Spark：**为了提高Map-Reduce的计算效率，Berkeley的AMPLab实验室开发了Spark，Spark可看做基于内存的Map-Reduce实现，此外，伯克利还在Spark基础上封装了一层SQL，产生了一个新的类似Hive的系统Shark
- **Stinger Initiative（Tez optimized Hive）：**Hortonworks开源了一个DAG计算框架Tez，Tez可以理解为Google Pregel的开源实现，该框架可以像Map-Reduce一样，可以用来设计DAG应用程序，但需要注意的是，Tez只能运行在YARN上。Tez的一个重要应用是优化Hive和PIG这种典型的DAG应用场景，它通过减少数据读写IO，优化DAG流程使得Hive速度提供了很多倍
- **Presto：**FaceBook于2013年11月份开源了Presto，一个分布式SQL查询引擎，它被设计为用来专门进行高速、实时的数据分析。它支持标准的ANSI SQL，包括复杂查询、聚合（aggregation）、连接（join）和窗口函数（window functions)。Presto设计了一个简单的数据存储的抽象层，来满足在不同数据存储系统（包括HBase、HDFS、Scribe等）之上都可以使用SQL进行查询。
对比分析
下面的图1展示了主要的SQL 引擎的流行程度，数据由奥地利咨询公司Solid IT 维护的DB-Engines 提供。DB-Engines 每月为超过200个数据库系统计算流行得分。得分反应了搜索引擎的查询，在线讨论的提及，提供的工作，专业资历的提及，以及tweets
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WnIVdaxU-1619950785509)(img\SQLengines)]
虽然Impala、Spark SQL、Drill、Hawq 和Presto 一直在运行性能、并发量和吞吐量上击败Hive，但是Hive 仍然是最流行的（至少根据DB-Engines 的标准）。原因有3个：
-
Hive 是Hadoop 的默认SQL 选项，每个版本都支持。而其他的要求特定的供应商和合适的用户；
-
Hive 已经在减少和其他引擎的性能差距。大多数Hive 的替代者在2012年推出，分析师等待Hive 查询的完成等到要自杀。然而当Impala、Spark、Drill 等大步发展的时候，Hive只是一直跟着，慢慢改进。现在，虽然Hive 不是最快的选择，但是它比五年前要好得多；
-
虽然前沿的速度很酷，但是大多数机构都知道世界并没有尽头。
在下面的图2中可以看出，相对于领先的商业数据仓库应用，用户对顶尖的SQL 引擎更感兴趣
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-otkkmKVj-1619950785511)(img\对比)]
对于开源项目来说，最佳的健康度量是它的活跃开发者社区的大小。如下面的图3所示，Hive 和Presto 有最大的贡献者基础。（Spark SQL 的数据暂缺）
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2wIvpSy2-1619950785512)(img\SQLenginess)]
在2016年，Cloudera、Hortonworks、Kognitio 和Teradata 陷入了Tony Baer 总结的基准测试之战，令人震惊的是，供应商偏爱的SQL 引擎在每一个研究中都击败了其他选择，这带来一个问题：基准测试还有意义吗？
AtScale 一年两次的基准测试并不是毫无根据的。作为一个BI 初创公司，AtScale 销售衔接BI 前端和SQL 后端的软件。公司的软件是引擎中立的，它尝试尽可能多的兼容，其在BI 领域的广泛经验让这些测试有了实际的意义。AtScale 最近的关键发现，包括了Hive、Impala、Spark SQL 和Presto：
- 4个引擎都成功运行了AtScale 的BI 基准查询；
- 取决于数据量、查询复杂度和并发用户数，每个引擎都有自己的性能优势：
- Impala 和Spark SQL 在小数据量的查询上击败了其他人；
- Impala 和Spark SQL 在大数据量的复杂join 上击败了其他人；
- Impala 和Presto 在并发测试上表现的更好。
-
对比6个月之前的基准测试，所有的引擎都有了2-4倍的性能提升。
Alex Woodie 报告了测试结果，Andrew Oliver 对其进行分析。让我们来深入了解这些项目。
Apache Hive
Apache Hive 是Hadoop 生态系统中的第一个SQL 框架。Facebook 的工程师在2007年介绍了Hive，并在2008年将代码捐献给Apache 软件基金会。2010年9月，Hive 毕业成为Apache 顶级项目。Hadoop 生态系统中的每个主要参与者都发布和支持Hive，包括Cloudera、MapR、Hortonworks 和IBM。Amazon Web Services 在Elastic MapReduce（EMR）中提供了Hive 的修改版作为云服务。
Hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供完整的SQL查询功能，可以将SQL语句转换为Map-Reduce任务进行运行，十分适合数据仓库的统计分析。其架构如下图所示，Hadoop和Map-Reduce是Hive架构的根基。Hive架构包括如下组件：CLI（Command Line Interface）、JDBC/ODBC、Thrift Server、Meta Store和Driver(Complier、Optimizer和Executor)
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-txK64BDm-1619950785514)(img\hive)]
早期发布的Hive 使用MapReduce 运行查询。复杂查询需要多次传递数据，这会降低性能。所以Hive 不适合交互式分析。由Hortonworks 领导的Stinger 明显的提高了Hive 的性能，尤其是通过使用Apache Tez，一个精简MapReduce 代码的应用框架。Tez 和ORCfile，一种新的存储格式，对Hive 的查询产生了明显的提速。
Cloudera 实验室带领一个并行项目重新设计Hive 的后端，使其运行在Apache Spark 上。经过长期测试后，Cloudera 在2016年初发布了Hive-on-Spark 的正式版本。
在2016年，Hive 有100多人的贡献者。该团队在2月份发布了Hive 2.0，并在6月份发布了Hive 2.1。Hive 2.0 的改进包括了对Hive-on-Spark 的多个改进，以及性能、可用性、可支持性和稳定性增强。Hive 2.1 包括了Hive LLAP（”Live Long and Process“），它结合持久化的查询服务器和优化后的内存缓存，来实现高性能。该团队声称提高了25倍。
9月，Hivemall 项目进入了Apache 孵化器，正如我在我的机器学习年度总结的第二部分中指出的。Hivemall 最初由Treasure Data 开发并捐献给Apache 软件基金会，它是一个可扩展的机器学习库，通过一系列的Hive UDF 来实现，设计用于在Hive、Pig 和Spark SQL 上运行MapReduce。该团队计划在2017年第一季度发布了第一个版本。
Apache Impala
2012年，Cloudera 推出了Impala，一个开源的MPP SQL 引擎，作为Hive 的高性能替代品。Impala 使用HDFS 和HBase，并利用了Hive 元数据。但是，它绕开了使用MapReduce 运行查询。
Impala可以看成是Google Dremel架构和MPP (Massively Parallel Processing)结构的结合体。Impala没有再使用缓慢的Hive&Map-Reduce批处理，而是通过使用与商用并行关系数据库中类似的分布式查询引擎（由Query Planner、Query Coordinator和Query Exec Engine三部分组成），可以直接从HDFS或HBase中用SELECT、JOIN和统计函数查询数据，从而大大降低了延迟，其架构如下图所示
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-sKjsB7Pd-1619950785515)(img\impala)]
Impala主要由Impalad，State Store和CLI组成。
Impalad与DataNode运行在同一节点上，由Impalad进程表示，它接收客户端的查询请求（接收查询请求的Impalad为Coordinator，Coordinator通过JNI调用java前端解释SQL查询语句，生成查询计划树，再通过调度器把执行计划分发给具有相应数据的其它Impalad进行执行），读写数据，并行执行查询，并把结果通过网络流式的传送回给Coordinator，由Coordinator返回给客户端。同时Impalad也与State Store保持连接，用于确定哪个Impalad是健康和可以接受新的工作。Impala State Store跟踪集群中的Impalad的健康状态及位置信息，由state-stored进程表示，它通过创建多个线程来处理Impalad的注册订阅和与各Impalad保持心跳连接，各Impalad都会缓存一份State Store中的信息，当State Store离线后，因为Impalad有State Store的缓存仍然可以工作，但会因为有些Impalad失效了，而已缓存数据无法更新，导致把执行计划分配给了失效的Impalad，导致查询失败。CLI提供给用户查询使用的命令行工具，同时Impala还提供了Hue，JDBC，ODBC，Thrift使用接口
Cloudera 的首席战略官Mike Olson 在2013年底说到Hive 的架构是有根本缺陷的。在他看来，开发者只能用一种全新的方式来实现高性能SQL，例如Impala。2014年的1月、5月和9月，Cloudera 发布了一系列的基准测试。在这些测试中，Impala 展示了其在查询运行的逐步改进，并且显著优于基于Tez 的Hive、Spark SQL 和Presto。除了运行快速，Impala 在并发行、吞吐量和可扩展性上也表现优秀。
2015年，Cloudera 将Impala 捐献给Apache 软件基金会，进入了Apache 孵化计划。Cloudera、MapR、Oracle 和Amazon Web Services 分发Impala，Cloudera、MapR 和Oracle 提供了商业构建和安装支持。
2016年，Impala 在Apache 孵化器中取得了稳步发展。该团队清理了代码，将其迁移到Apache 基础架构，并在10月份发布了第一个Apache 版本2.7.0。新版本包括了性能提升和可扩展性改进，以及一些其他小的增强。
9月，Cloudera 发布了一项研究结果，该研究比较了Impala 和Amazon Web Services 的Redshift 列存储数据库。报告读起来很有意思，虽然主题一贯的需要注意供应商的基准测试。
Spark SQL
Spark SQL 是Spark 用于结构化数据处理的组件。Apache Spark 团队 在2014年发布了Spark SQL，并吸收了一个叫Shark 的早期的Hive-on-Spark 项目。它迅速成为最广泛使用的Spark 模块。
Spark SQL 用户可以运行SQL 查询，从Hive 中读取数据，或者使用它来创建Spark Dataset和DataFrame（Dataset 是分布式的数据集合，DataFrame 是统一命名的Dataset 列）。
Spark SQL 的接口向Spark 提供了数据结构和执行操作的信息，Spark 的Catalyst 优化器使用这些信息来构造一个高效的查询。早期shark架构如下：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-INlndw33-1619950785515)(img\sparksql)]
2015年，Spark 的机器学习开发人员引入了ML API，一个利用Spark DataFrame 代替低级别Spark RDD API 的包。这种方法被证明是有吸引力和富有成果的；
2016年，随着2.0 的发布，Spark 团队将基于RDD 的API改为维护模式。DataFrame API现在是Spark 机器学习的主要接口。
此外，在2016年，该团队还在Spark 2.1.0的Alpha 版本中发布了结构化的流式处理。结构化的流式处理是构建在Spark SQL 上的一个流处理引擎。用户可以像对待静态源一样，用同样的方式查询流式数据源，并且可以在单个查询中组合流式和静态源。Spark SQL 持续运行查询，并且在流式数据到达的时候更新结果。结构化的流通过检查点和预写日志来提供一次性的容错保障。
Apache Drill
2012年，由Hadoop 分销商的领导者之一MapR 领导的一个团队，提出构建一个Google Dremel 的开源版本，一个交互式的分布式热点分析系统。他们将其命名为Apache Drill。Drill 在Apache 孵化器中被冷落了两年多，最终在2014年底毕业。该团队在2015年发布了1.0。
MapR 分发和支持Apache Drill。
2016年，超过50个人对Drill 做出了贡献。该团队在2016年发布了5个小版本，关键的增强功能包括：
-
- Web 认证
- 支持Apache Kudu 列数据库
- 支持HBase 1.x
- 动态UDF 支持
2015年，两位关键的Drill 贡献者离开了MapR，并启动了Dremio，该项目尚未发布。
Apache HAWQ
Pivotal 软件在2012年推出了一款商业许可的高性能SQL 引擎HAWQ，并在尝试市场营销时取得了小小的成功。改变战略后，Pivotal 在2015年6月将项目捐献给了Apache，并于2015年9月进入了Apache 孵化器程序。
15个月之后，HAWQ 仍然待在孵化器中。2016年12月，该团队发布了HAWQ 2.0.0.0，加入了一些错误修复。我猜它会在2017年毕业。
对HAWQ 喜爱的一个小点是它支持Apache MADlib，一个同样在孵化器中的SQL 机器学习项目。HAWQ 和MADlib 的组合，应该是对购买了Greenplum 并且想知道发生了什么的人们的一个很好的安慰。
Presto
Facebook 工程师在2012年发起了Presto 项目，作为Hive 的一个快速交互的取代。在2013年推出时，成功的支持了超过1000个Facebook 用户和每天超过30000个PB级数据的查询。2013年Facebook 开源了Presto。
Presto 支持多种数据源的ANSI SQL 查询，包括Hive、Cassandra、关系型数据库和专有文件系统（例如Amazon Web Service 的S3）。Presto 的查询可以联合多个数据源。用户可以通过C、Java、Node.js、PHP、Python、R和Ruby 来提交查询。
Airpal 是Airbnb 开发的一个基于web 的查询工具，让用户可以通过浏览器来提交查询到Presto。Qubole 位Presto 提供了管理服务。AWS 在EMR 上提供Presto 服务，其简化的架构图如下：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-PE1gQiRg-1619950785516)(img\presto)]
客户端将SQL查询发送到Presto的协调器。协调器会进行语法检查、分析和规划查询计划。调度器将执行的管道组合在一起，将任务分配给那些里数据最近的节点，然后监控执行过程。客户端从输出段中将数据取出，这些数据是从更底层的处理段中依次取出的。Presto的运行模型与Hive有着本质的区别。Hive将查询翻译成多阶段的Map-Reduce任务，一个接着一个地运行。每一个任务从磁盘上读取输入数据并且将中间结果输出到磁盘上。然而Presto引擎没有使用Map-Reduce。它使用了一个定制的查询执行引擎和响应操作符来支持SQL的语法。除了改进的调度算法之外，所有的数据处理都是在内存中进行的。不同的处理端通过网络组成处理的流水线。这样会避免不必要的磁盘读写和额外的延迟。这种流水线式的执行模型会在同一时间运行多个数据处理段，一旦数据可用的时候就会将数据从一个处理段传入到下一个处理段。 这样的方式会大大的减少各种查询的端到端响应时间。同时，Presto设计了一个简单的数据存储抽象层，来满足在不同数据存储系统之上都可以使用SQL进行查询。存储连接器目前支持除Hive/HDFS外，还支持HBase、Scribe和定制开发的系统。
2015年6月，Teradata 宣布计划开发和支持该项目。根据宣布的三阶段计划，Teredata 提出将Presto 集成导Hadoop 生态系统中，能够在YARN 中进行操作，并且通过ODBC 和JDBC 增强连接性。Teredata 提供了自己的Presto 发行版，附带一份数据表。2016年6月，Teradata 宣布了Information Builders、Looker、Qlik、Tableau 和ZoomData 的鉴定结果，以及正在进行中的MicroStrategy 和Microsoft Power BI。
Presto 是一个非常活跃的项目，有一个巨大的和充满活力的贡献者社区。该团队发布的速度比Miki Sudo 吃热狗的速度还要快–我统计了下，2016年共发布了42个版本。Teradata 并没有打算总结有什么新的东西，我也不打算在42个发行说明里去筛选，所以就让我们说它更好吧。
其他Apache 项目:这里还有5个其他的Apache 生态系统的SQL 混合项目。
Stinger
Stinger是Hortonworks开源的一个实时类SQL即时查询系统，声称可以提升较Hive 100倍的速度。与Hive不同的是，Stinger采用Tez。所以，Hive是SQL on Map-Reduce，而Stinger是Hive on Tez。Tez的一个重要作用是优化Hive和PIG这种典型的DAG应用场景，它通过减少数据读写IO，优化DAG流程使得Hive速度提供了很多倍。其架构如下图所示，
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DtKVAcTt-1619950785517)(img\stinger)]
Stinger是在Hive的现有基础上加了一个优化层Tez（此框架是基于Yarn），所有的查询和统计都要经过它的优化层来处理，以减少不必要的工作以及资源开销。虽然Stinger也对Hive进行了较多的优化与加强，Stinger总体性能还是依赖其子系统Tez的表现。而Tez是Hortonworks开源的一个DAG计算框架，Tez可以理解为Google Pregel的开源实现，该框架可以像Map-Reduce一样，用来设计DAG应用程序，但需要注意的是，Tez只能运行在YARN上**。**
Apache Calcite
Apache Calcite 是一个开源的数据库构建框架。它包括：
-
SQL 解析器、验证器和JDBC 驱动
-
查询优化工具，包括关系代数API，基于规则的计划器和基于成本的查询优化器
Apache Hive 使用Calcite 进行基于成本的查询优化，而Apache Drill 和Apache Kylin 使用SQL 解析器。Calcite 团队在2016年推出了5个版本包括bug 修复和用于Cassandra、Druid 和Elasticsearch 的新适配器。
Apache Kylin
Apache Kylin 是一个具有SQL 接口的OLAP 引擎。由eBay 开发并捐献给Apache，Kylin 在2015年毕业成为顶级项目。
2016年成立的创业公司Kyligence 提供商业支持和一个叫做KAP 的数据仓库产品，虽然在Crunchbase 上没有列出它的资金情况，有消息来源称它有一个强大的背景，并且在上海有个大办公室。
Apache Phoenix
Apache Phoenix 是一个运行在HBase 上的SQL 框架，绕过了MapReduce。
Salesforce 开发了该软件并在2013年捐献给了Apache。2014年5月项目毕业成为顶级项目。Hortonworks 的Hortonworks 数据平台中包含该项目。自从领先的SQL 引擎都适配HBase 之后，我不清楚为什么我们还需要Phoenix。
Apache Tajo
Apache Tajo 是Gruter 在2011年推出的一个快速SQL 数据仓库框架，一个大数据基础设施公司，并在2013年捐献给Apache。
2014年Tajo 毕业成为顶级项目。在作为Gruter 主要市场的韩国之外，该项目很少吸引到预期用户和贡献者的兴趣。除了Gartner 的Nick Heudecker 曾提过，该项目不在任何人的工作台上。
Apache Trafodion
Apache Trafodion 是另一个SQL-on-HBase 项目，由HP 实验室构思，它告诉你几乎所有你需要知道的。2014年6月HP 发布Trafodion，一个月之后，Apache Phoenix 毕业投产。6个月之后，HP 的高管们认为相对于另一款SQL-on-HBase 引擎，它的商业潜力有限，所以他们将项目捐献给了Apache，项目于2015年5月进入孵化器。
如果孵化结束，Trafodion 承诺成为一个事务数据库。不幸的是，这个领域有大量的选择，而开发团队唯一的竞争优势似乎是“它是开源的，所以它很便宜”。