由于前期的文件已经多次介绍了Big SQL的特点和工作机制，如《BigInsights金刚钻之首：BigSQL - SQL on Hadoop》，《BigSQL发动机的结构和工作原理》和《BigSQL让HBase更易用》等，而Spark SQL在网上也有很多相关文章，所以，这两个SQL on Hadoop引擎的功能特点在此不在细述。

两种SQL引擎在一些数据处理的场景都是可以胜任和互换的。然而，Spark SQL目前还很不成熟，包括对SQL标准的支持、对数据访问的安全性控制（行级和列级的访问控制）和并发有待改进，而且它在处理数据时受内存容量的限制。所以，在更多的场景中，Big SQL无论在功能上还是性能上才是最佳选择。

鉴于Big SQL和Spark的流行性，企业想要部署和使用这两种技术的期望是合理的。幸运的是，Spark的应用程序不难与Big SQL共享Big SQL表中的数据。这种可能得益于Big SQL的设计，特别是它重用了Hive的HCatalog元数据管理并支持不同的Hadoop文件格式的存储数据(而不是专有的格式)。这种方法使得Spark SQL非常容易地获取Big SQL表的数据。

下面，我们看一个简单的例子，以说明Spark SQL如何访问Big SQL的数据。

在BigInsights中，假设您已经在Hive仓库或在DFS目录中已经创建了一个Big SQL表，现在您只需调用标准Spark SQL语句和表达式，以创建一个HiveContext并使用HiveQL语法查询Big SQL表。一旦您把数据读入到Spark，您就可以使用适当的Transformation和Action进行数据处理。

这例子简单明了吧！

那么，Big SQL和Spark SQL之间如何选择呢？看看下面这张图就明白了：

对于很多场景，Spark SQL想做的事情，Big SQL可能一点兴趣都没有。例如，应用场景是获取数据用于机器学习，或者是数据科学家从零开始编写探索性的查询，那Spark SQL是个相当好的选择，而且它利用内存计算能过获取很好的性能。

然而，如果您想从数据仓库Offload工作负载：其查询，报表和应用程序以最小的修改代价运行在Hadoop上，那么对每个查询都要维护两个版本是不可接受的。对于生产环境，数据访问的安全性也是另一个非常重要的要求。还有，需要多用户并发…这时，Big SQL才是最佳答案。

所以，Big SQL和Spark SQL不是互斥的。您应该同时使用Big SQL和Spark SQL解决不同的问题。

更多大数据与分析相关行业资讯、解决方案、案例、教程等请点击查看>>>

详情请咨询在线客服！

客服热线：023-66090381