曾經(jīng)有段時間，大概兩年前，SQL-on-Hadoop就要打開Hadoop的數(shù)據(jù)訪問。這是基于以下兩個原因：SQL自有的那些特征，消除Hadoop/MapReduce專家對數(shù)據(jù)訪問的排他性。是的，一些架構(gòu)細節(jié)也是重要的，比如SQL引擎是否直接觸及Hadoop集群的數(shù)據(jù)節(jié)點。但是，大多數(shù)情況下，解決方案被巧妙地概括為：SQL，on Hadoop。

今天，SQL-on-Hadoop解決方案被認為是最好的，不是因為他們SQL引擎自身，而是他們能夠使得Hadoop和傳統(tǒng)數(shù)據(jù)倉庫協(xié)作。Hadoop可以視為篡位者，數(shù)據(jù)倉庫的同等或者外圍部分；SQL-on-hadoop引擎，用來決定Hadoop這三個角色哪一個（或者更多）能被實現(xiàn)完成。

Gigaom研究剛剛發(fā)布行業(yè)路線：Hadoop/數(shù)據(jù)倉庫互操作性。分析師George Gilbert調(diào)查了SQL-on-Hadoop市場，評估了六個解決方案。這六個“中斷向量”的每一個或者主要趨勢將影響市場和明年的玩家：模式靈活性、數(shù)據(jù)引擎互操作性、定價模式、企業(yè)可管理性、負載優(yōu)化作用和查詢引擎的成熟度。

場景

作為根據(jù)這些向量評價各種SQL-on-Hadoop產(chǎn)品的背景，Gilbert確定三個關(guān)鍵分析使用場景。第一個是核心數(shù)據(jù)倉庫，許多學院派專家熟悉的概念：一個相當昂貴的基于硬件數(shù)據(jù)庫平臺提供高度組織化的數(shù)據(jù)，它的數(shù)據(jù)結(jié)構(gòu)被優(yōu)化為商業(yè)認為需要運行的查詢類型。

第二個是所謂的“數(shù)據(jù)湖”（被一些廠商稱為“企業(yè)數(shù)據(jù)中心”）。這里，Hadoop充當各種不同數(shù)據(jù)來源的收集點，包括無結(jié)構(gòu)化，半結(jié)構(gòu)化和結(jié)構(gòu)化數(shù)據(jù)。Hadoop 2.0的YARN資源管理器促進使用各種分析引擎以特別的方式去探索“湖”的數(shù)據(jù)，由此數(shù)據(jù)倉庫能夠解脫出來，自由為設(shè)計和調(diào)整的查詢服務(wù)。

實際上，核心數(shù)據(jù)倉庫，輔助數(shù)據(jù)倉庫和數(shù)據(jù)湖構(gòu)成數(shù)據(jù)處理層次，并具有相應(yīng)層次的成本。平臺的分層選擇能夠使得較低產(chǎn)值的任務(wù)（不過，可以說，更高的商業(yè)價值）在較便宜的平臺上處理——為企業(yè)組織產(chǎn)生更高的效率。

企業(yè)投資回報率

便宜了多少呢？Gilbert說，Hadoop成本每TB數(shù)據(jù)與基于硬件的數(shù)據(jù)倉庫相比，至少少一個數(shù)量級。因為Hadoop能夠啟用數(shù)據(jù)湖和輔助數(shù)據(jù)庫場景，他們的實現(xiàn)能夠使Hadoop給企業(yè)用戶明顯的投資回報率。

一個懸而未決的問題是，是否并且何時Hadoop能夠同樣地在核心數(shù)據(jù)倉庫中提供服務(wù)。如果能這樣做，這將有助于數(shù)據(jù)倉庫供應(yīng)商，Hadoop分銷商或者兩者兼而有之？確實，這種動態(tài)性可能是預(yù)測未來分銷商兼并由傳統(tǒng)玩家主導(dǎo)——或者可能甚至是相反的。