随着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解决方案生存的空间。