由于前期的文件已經多次介紹了Big SQL的特點和工作機制，如《》，《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