曾經(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)——或者可能甚至是相反的。