有越来越多的人和商业实体已经决定尝试一下，对存储在Hadoop中的数据实现低延迟、ad-hoc SQL访问。无论怎样，从长远来看由于重叠的用例和环境喜好的不同有适合多种SQL in Hadoop解决方案生存的空间。
随着Facebook开源了最近发布的Presto，已经非常拥挤的SQL in Hadoop市场变得更加错综复杂。一些开源工具正在努力获得开发者的注意：Hortonworks 围绕着Hive创建的Stinger、Apache Drill、Apache Tajo、Cloudera的Impala、Salesforce的Phoenix（用于HBase）以及现在的Facebook Presto。
已经在产品环境中使用Hadoop的组织需要交互式的SQL查询支持，同时能够与已有的BI工具进行平滑的集成。来自于eBay的Vijay Madhavan在他的博客Hadoop场景中的SQL一文中声称：
现在大部分基于Map-Reduce的分析系统能够在非交互式和批量SLA领域良好地工作，包括当前版本的Hive、Pig、Cascading。许多产品正在努力通过提供交互式“SQL in Hadoop”解决方案支持实时交互式SLA。
SQL in Hadoop解决方案的用例包括支持交互式ad-hoc查询；支持使用MicroStrategy 或者Tableau 这样的BI系统进行报表/可视化；支持多来源（multi-source）数据，例如HDFS中的行为型数据必须被连接到RDBMS或者其他来源中的人口统计数据。
很多这样的SQL in Hadoop解决方案在某些方面有共同点：
在元数据层面上，好像HCatalog/Hive Metastore将它们自己制定成了跨不同数据源管理模式事实上（de-facto）的标准。
然后有某些数据格式，例如Parquet和ORC，它们对于选择的工作负载而言正在变得越来越流行，同时在自然环境中使用的也越来越广泛。
大部分解决方案好像都支持各种各样的ANSI SQL（不同的版本：1992、1999、2003）。
上面几点可以帮助用户在不同的SQL in Hadoop解决方案之间迁移，不会有很多令人头痛的问题。但是也有一些值得注意的区别，如下所示：
解决方案中的一部分是由Apache支持的，同时也伴随着社区的支持（Stinger、Drill、Tajo）；其他的则是由单独的实体组织拥有（Impala、Phoenix、Presto）。
另外，有一部分解决方案在数据源方面有一些限制，它们能够查询Hadoop生态系统；而另一些从架构的角度看更加灵活，可以查询关系型数据库和NoSQL数据存储（Presto、Drill）。
另一点是允许在数据上执行的操作不同：有一些是纯（分布式）查询引擎，而另一些则允许执行更新操作。
在过去的10到18个月中，有越来越多的人和商业实体已经决定尝试一下，对存储在Hadoop中的数据实现低延迟、ad-hoc SQL访问。无论怎样，从长远来看由于重叠的用例和环境喜好的不同有适合多种SQL in Hadoop解决方案生存的空间。
声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。
