国产一级a片免费看高清,亚洲熟女中文字幕在线视频,黄三级高清在线播放,免费黄色视频在线看

簡(jiǎn)介

Dremel 是Google 的“交互式”數(shù)據(jù)分析系統(tǒng)?？梢越M建成規(guī)模上千的集群，處理PB級(jí)別的數(shù)據(jù)。MapReduce處理一個(gè)數(shù)據(jù)，需要分鐘級(jí)的時(shí)間。作為MapReduce的發(fā)起人，Google開發(fā)了Dremel將處理時(shí)間縮短到秒級(jí)，作為MapReduce的有力補(bǔ)充。Dremel作為Google BigQuery的report引擎，獲得了很大的成功。最近Apache計(jì)劃推出Dremel的開源實(shí)現(xiàn)Drill，將Dremel的技術(shù)又推到了浪尖上。

Google Dremel設(shè)計(jì)

根據(jù)Google公開的論文《Dremel: Interactive Analysis of WebScaleDatasets》可以看到Dremel的設(shè)計(jì)原理。還有一些測(cè)試報(bào)告。論文寫于2006年，公開于2010年，Google在處理大數(shù)據(jù)方面，果真有得天獨(dú)厚的優(yōu)勢(shì)。下面的內(nèi)容，很大部分來(lái)自這篇論文。

隨著Hadoop的流行，大規(guī)模的數(shù)據(jù)分析系統(tǒng)已經(jīng)越來(lái)越普及。數(shù)據(jù)分析師需要一個(gè)能將數(shù)據(jù)“玩轉(zhuǎn)”的交互式系統(tǒng)。如此，就可以非常方便快捷的瀏覽數(shù)據(jù)，建立分析模型。Dremel系統(tǒng)有下面幾個(gè)主要的特點(diǎn)：

• Dremel是一個(gè)大規(guī)模系統(tǒng)。在一個(gè)PB級(jí)別的數(shù)據(jù)集上面，將任務(wù)縮短到秒級(jí)，無(wú)疑需要大量的并發(fā)。磁盤的順序讀速度在100MB/S上下，那么在1S內(nèi)處理1TB數(shù)據(jù)，意味著至少需要有1萬(wàn)個(gè)磁盤的并發(fā)讀! Google一向是用廉價(jià)機(jī)器辦大事的好手。但是機(jī)器越多，出問題概率越大，如此大的集群規(guī)模，需要有足夠的容錯(cuò)考慮，保證整個(gè)分析的速度不被集群中的個(gè)別慢(壞)節(jié)點(diǎn)影響。
• Dremel是MR交互式查詢能力不足的補(bǔ)充。和MapReduce一樣，Dremel也需要和數(shù)據(jù)運(yùn)行在一起，將計(jì)算移動(dòng)到數(shù)據(jù)上面。所以它需要GFS這樣的文件系統(tǒng)作為存儲(chǔ)層。在設(shè)計(jì)之初，Dremel并非是MapReduce的替代品，它只是可以執(zhí)行非?？斓姆治?，在使用的時(shí)候，常常用它來(lái)處理MapReduce的結(jié)果集或者用來(lái)建立分析原型。
• Dremel的數(shù)據(jù)模型是嵌套(nested)的。互聯(lián)網(wǎng)數(shù)據(jù)常常是非關(guān)系型的。Dremel還需要有一個(gè)靈活的數(shù)據(jù)模型，這個(gè)數(shù)據(jù)模型至關(guān)重要。Dremel支持一個(gè)嵌套(nested)的數(shù)據(jù)模型，類似于Json。而傳統(tǒng)的關(guān)系模型，由于不可避免的有大量的Join操作，在處理如此大規(guī)模的數(shù)據(jù)的時(shí)候，往往是有心無(wú)力的。
• Dremel中的數(shù)據(jù)是用列式存儲(chǔ)的。使用列式存儲(chǔ)，分析的時(shí)候，可以只掃描需要的那部分?jǐn)?shù)據(jù)的時(shí)候，減少CPU和磁盤的訪問量。同時(shí)列式存儲(chǔ)是壓縮友好的，使用壓縮，可以綜合CPU和磁盤，發(fā)揮最大的效能。對(duì)于關(guān)系型數(shù)據(jù)，如果使用列式存儲(chǔ)，我們都很有經(jīng)驗(yàn)。但是對(duì)于嵌套(nested)的結(jié)構(gòu)，Dremel也可以用列存儲(chǔ)，非常值得我們學(xué)習(xí)。
• Dremel結(jié)合了Web搜索 和并行DBMS的技術(shù)。首先，他借鑒了Web搜索中的“查詢樹”的概念，將一個(gè)相對(duì)巨大復(fù)雜的查詢，分割成較小較簡(jiǎn)單的查詢。大事化小，小事化了，能并發(fā)的在大量節(jié)點(diǎn)上跑。其次，和并行DBMS類似，Dremel可以提供了一個(gè)SQL-like的接口，就像Hive和Pig那樣。

Google Dremel應(yīng)用場(chǎng)景

設(shè)想一個(gè)使用場(chǎng)景。我們的美女?dāng)?shù)據(jù)分析師，她有一個(gè)新的想法要驗(yàn)證。要驗(yàn)證她的想法，需要在一個(gè)上億條數(shù)據(jù)上面，跑一個(gè)查詢，看看結(jié)果和她的想法是不是一樣，她可不希望等太長(zhǎng)時(shí)間，最好幾秒鐘結(jié)果就出來(lái)。當(dāng)然她的想法不一定完善，還需要不斷調(diào)整語(yǔ)句。然后她驗(yàn)證了想法，發(fā)現(xiàn)了數(shù)據(jù)中的價(jià)值。最后，她可以將這個(gè)語(yǔ)句完善成一個(gè)長(zhǎng)期運(yùn)行的任務(wù)。

對(duì)于Google,數(shù)據(jù)一開始是放在GFS上的?？梢酝ㄟ^MapReduce將數(shù)據(jù)導(dǎo)入到Dremel中去，在這些MapReduce中還可以做一些處理。然后分析師使用Dremel，輕松愉悅的分析數(shù)據(jù)，建立模型。最后可以編制成一個(gè)長(zhǎng)期運(yùn)行的MapReduce任務(wù)。

這種處理方式，讓筆者聯(lián)想到Greenplum的Chorus. Chorus也可以為分析師提供快速的數(shù)據(jù)查詢，不過解決方案是通過預(yù)處理，導(dǎo)入部分?jǐn)?shù)據(jù)，減少數(shù)據(jù)集的大小。用的是三十六計(jì)，走為上計(jì)，避開的瞬時(shí)分析大數(shù)據(jù)的難題。Chorus最近即將開源，可以關(guān)注下。

還有一點(diǎn)特別的就是按列存儲(chǔ)的嵌套數(shù)據(jù)格式。如圖所示，在按記錄存儲(chǔ)的模式中，一個(gè)記錄的多列是連續(xù)的寫在一起的。在按列存儲(chǔ)中，可以將數(shù)據(jù)按列分開。也就是說(shuō)，可以僅僅掃描A.B.C而不去讀A.E或者A.B.C。難點(diǎn)在于，我們?nèi)绾文芡瑫r(shí)高效地掃描若干列，并做一些分析。

Google Dremel數(shù)據(jù)模型

在Google, 用Protocol Buffer常常作為序列化的方案。其數(shù)據(jù)模型可以用數(shù)學(xué)方法嚴(yán)格的表示如下：

其中t可以是一個(gè)基本類型或者組合類型。其中基本類型可以是integer,float和string。組合類型可以是若干個(gè)基本類型拼湊。星號(hào)(*)指的是任何類型都可以重復(fù)，就是數(shù)組一樣。問號(hào)(?)指的是任意類型都是可以是可選的。簡(jiǎn)單來(lái)說(shuō)，除了沒有Map外，和一個(gè)Json幾乎沒有區(qū)別。

下圖是例子，Schema定義了一個(gè)組合類型Document.有一個(gè)必選列DocId，可選列Links，還有一個(gè)數(shù)組列Name?？梢杂肗ame.Language.Code來(lái)表示Code列。

這種數(shù)據(jù)格式是語(yǔ)言無(wú)關(guān)，平臺(tái)無(wú)關(guān)的。可以使用Java來(lái)寫MR程序來(lái)生成這個(gè)格式，然后用C++來(lái)讀取。在這種列式存儲(chǔ)中，能夠快速通用處理也是非常的重要的。

上圖，是一個(gè)示例數(shù)據(jù)的抽象的模型；下圖是這份數(shù)據(jù)在Dremel實(shí)際的存儲(chǔ)的格式。

如果是關(guān)系型數(shù)據(jù)，而不是嵌套的結(jié)構(gòu)。存儲(chǔ)的時(shí)候，我們可以將每一列的值直接排列下來(lái)，不用引入其他的概念，也不會(huì)丟失數(shù)據(jù)。對(duì)于嵌套的結(jié)構(gòu)，我們還需要兩個(gè)變量R (Repetition Level) ,D (Definition Level) 才能存儲(chǔ)其完整的信息。

Repetition Level是記錄該列的值是在哪一個(gè)級(jí)別上重復(fù)的。舉個(gè)例子說(shuō)明：對(duì)于Name.Language.Code  我們一共有三條非Null的記錄。

1. 第一個(gè)是”en-us”，出現(xiàn)在第一個(gè)Name的第一個(gè)Lanuage的第一個(gè)Code里面。在此之前，這三個(gè)元素是沒有重復(fù)過的，都是第一個(gè)。所以其R為0。
2. 第二個(gè)是”en”，出現(xiàn)在下一個(gè)Lanuage里面。也就是說(shuō)Lanague是重復(fù)的元素。Name.Language.Code中Lanague排第二個(gè)，所以其R為2.
3. 第三個(gè)是”en-gb”，出現(xiàn)在下一個(gè)Name中，Name是重復(fù)元素，排第一個(gè)，所以其R為1。

我們可以想象，將所有的沒有值的列，設(shè)值為NULL。如果是數(shù)組列，我們也想象有一個(gè)NULL值。有了Repetition Level，我們就可以很好的用列表示嵌套的結(jié)構(gòu)了。但是還有一點(diǎn)不足。就是還需要表示一個(gè)數(shù)組是不是我們想象出來(lái)的。

Definition Level 是定義的深度，用來(lái)記錄該列是否是”想象”出來(lái)的。所以對(duì)于非NULL的記錄，是沒有意義的，其值必然為相同。同樣舉個(gè)例子。例如Name.Language.Country,

• 第一個(gè)”us”是在R1里面，其中Name,Language,Country是有定義的。所以D為3。
• 第二個(gè)”NULL”也是在R1的里面，其中Name,Language是有定義的,其他是想象的。所以D為2。
• 第三個(gè)”NULL”還是在R1的里面，其中Name是有定義的,其他是想象的。所以D為1。
• 第四個(gè)”gb”是在R1里面，其中Name,Language,Country是有定義的。所以D為3。

就是這樣，如果路徑中有required，可以將其減去，因?yàn)閞equired必然會(huì)define，記錄其數(shù)量沒有意義。

理解了如何存儲(chǔ)這種嵌套結(jié)構(gòu)。寫沒有難度。讀的時(shí)候，我們只讀其中部分字段，來(lái)構(gòu)建部分的數(shù)據(jù)模型。例如，只讀取DocID和Name.Language.Country。我們可以同時(shí)掃描兩個(gè)字段，先掃描DocID。記錄下第一個(gè)，然后發(fā)現(xiàn)下一個(gè)DocID的R是0；于是該讀Name.Language.Country，如果下一個(gè)R是1或者2就繼續(xù)讀，如果是0就開始讀下一個(gè)DocID。

到此為止，我們已經(jīng)知道了Dremel的數(shù)據(jù)結(jié)構(gòu)。就像其他數(shù)據(jù)分析系統(tǒng)一樣，數(shù)據(jù)結(jié)構(gòu)確定下來(lái)，功能就決定了一大半。對(duì)于Dremel的數(shù)據(jù)查詢，必然是“全表掃描”，但由于其巧妙的列存儲(chǔ)設(shè)計(jì)，良好的數(shù)據(jù)模型設(shè)計(jì)可以回避掉大部分Join需求和掃描最少的列。

Google Dremel查詢方式

Dremel可以使用一種SQL-like的語(yǔ)法查詢嵌套數(shù)據(jù)。由于Dremel的數(shù)據(jù)是只讀的，并且會(huì)密集的發(fā)起多次類似的請(qǐng)求。所以可以保留上次請(qǐng)求的信息，還優(yōu)化下次請(qǐng)求的explain過程。那又是如何explain的呢？

這是一個(gè)樹狀架構(gòu)。當(dāng)Client發(fā)其一個(gè)請(qǐng)求，根節(jié)點(diǎn)受到請(qǐng)求，根據(jù)metadata，將其分解到枝葉，直到到位于數(shù)據(jù)上面的葉子Server。他們掃描處理數(shù)據(jù)，又不斷匯總到根節(jié)點(diǎn)。

舉個(gè)例子：對(duì)于請(qǐng)求：

SELECT A, COUNT(B) FROM T GROUP BY A

根節(jié)點(diǎn)收到請(qǐng)求，會(huì)根據(jù)數(shù)據(jù)的分區(qū)請(qǐng)求，將請(qǐng)求變成可以拆分的樣子。原來(lái)的請(qǐng)求會(huì)變?yōu)椤?/p>

SELECT A, SUM(c) FROM (R1 UNION ALL ... Rn) GROUP BY A

R1,…RN是T的分區(qū)計(jì)算出的結(jié)果集。越大的表有越多的分區(qū)，越多的分區(qū)可以越好的支持并發(fā)。

然后再將請(qǐng)求切分，發(fā)送到每個(gè)分區(qū)的葉子Server上面去,對(duì)于每個(gè)Server

 Ri = SELECT A, COUNT(B) AS c FROM Ti GROUP BY A

結(jié)構(gòu)集一定會(huì)比原始數(shù)據(jù)小很多，處理起來(lái)也更快。根服務(wù)器可以很快的將數(shù)據(jù)匯總。具體的聚合方式，可以使用現(xiàn)有的并行數(shù)據(jù)庫(kù)技術(shù)。

Dremel是一個(gè)多用戶的系統(tǒng)。切割分配任務(wù)的時(shí)候，還需要考慮用戶優(yōu)先級(jí)和負(fù)載均衡。對(duì)于大型系統(tǒng)，還需要考慮容錯(cuò)，如果一個(gè)葉子Server出現(xiàn)故障或變慢，不能讓整個(gè)查詢也受到明顯影響。

通常情況下，每個(gè)計(jì)算節(jié)點(diǎn)，執(zhí)行多個(gè)任務(wù)。例如，技巧中有3000個(gè)葉子Server，每個(gè)Server使用8個(gè)線程，有可以有24000個(gè)計(jì)算單元。如果一張表可以劃分為100000個(gè)區(qū)，就意味著大約每個(gè)計(jì)算單元需要計(jì)算5個(gè)區(qū)。這執(zhí)行的過程中，如果某一個(gè)計(jì)算單元太忙，就會(huì)另外啟一個(gè)來(lái)計(jì)算。這個(gè)過程是動(dòng)態(tài)分配的。

對(duì)于GFS這樣的存儲(chǔ)，一份數(shù)據(jù)一般有3份拷貝，計(jì)算單元很容易就能分配到數(shù)據(jù)所在的節(jié)點(diǎn)上，典型的情況可以到達(dá)95%的命中率。

Dremel還有一個(gè)配置，就是在執(zhí)行查詢的時(shí)候，可以指定掃描部分分區(qū)，比如可以掃描30%的分區(qū)，在使用的時(shí)候，相當(dāng)于隨機(jī)抽樣，加快查詢。

Google Dremel測(cè)試實(shí)驗(yàn)

實(shí)驗(yàn)的數(shù)據(jù)源如下表示。大部分?jǐn)?shù)據(jù)復(fù)制了3次，也有一個(gè)兩次。每個(gè)表會(huì)有若干分區(qū)，每個(gè)分區(qū)的大小在100K到800K之間。如果壓縮率是25%，并且計(jì)入復(fù)制3份的事實(shí)的話。T1的大小已經(jīng)達(dá)到PB級(jí)別。這幺小且巨量的分區(qū)，對(duì)于GFS的要求很高，現(xiàn)在的Hdfs穩(wěn)定版恐怕受不了。接下來(lái)的測(cè)試會(huì)逐步揭示其是如何超過MR，并對(duì)性能作出分析。

列存測(cè)試

首先，我們測(cè)試看看列存的效果。對(duì)于T1表，1GB的數(shù)據(jù)大約有300K行，使用列存的話壓縮后大約在375MB。這臺(tái)機(jī)器磁盤的吞吐在70MB/s左右。這1GB的數(shù)據(jù)，就是我們的現(xiàn)在的測(cè)試數(shù)據(jù)源，測(cè)試環(huán)境是單機(jī)。

見上圖。

• 曲線A，是用列存讀取數(shù)據(jù)并解壓的耗時(shí)。
• 曲線B是一條一條記錄挨個(gè)讀的時(shí)間。
• 曲線C是在B的基礎(chǔ)上，加上了反序列化的時(shí)間。
• 曲線d，是按行存讀并解壓的耗時(shí)。
• 曲線e加上了反序列化的時(shí)間。因?yàn)榱泻芏?，反序列化耗時(shí)超過了讀并解壓的50%。

從圖上可以看出。如果需要讀的列很少的話，列存的優(yōu)勢(shì)就會(huì)特別的明顯。對(duì)于列的增加，產(chǎn)生的耗時(shí)也幾乎是線性的。而一條一條該個(gè)讀和反序列化的開銷是很大的，幾乎都在原來(lái)基礎(chǔ)上增加了一倍。而按行讀，列數(shù)的增加沒有影響，因?yàn)橐淮涡宰x了全部列。

Dremel和MapReduce的對(duì)比測(cè)試

MR和Dremel最大的區(qū)別在于行存和列存。如果不能擊敗MapReduce，Remel就沒有意義了。使用最常見的WordCount測(cè)試，計(jì)算這個(gè)數(shù)據(jù)中Word的個(gè)數(shù)。

Q1: SELECT SUM(CountWords(txtField)) / COUNT(*) FROM T1

上圖是測(cè)試的結(jié)果。使用了兩個(gè)MR任務(wù)。這兩個(gè)任務(wù)和Dremel一樣都運(yùn)行在3000個(gè)節(jié)點(diǎn)上面。如果使用列存，Dremel的按列讀的MR只需要讀0.5TB的數(shù)據(jù)，而按行存需要讀87TB。 MR提供了一個(gè)方便有效的途經(jīng)來(lái)講按行數(shù)據(jù)轉(zhuǎn)換成按列的數(shù)據(jù)。Dremel可以方便的導(dǎo)入MapReduce的處理結(jié)果。

樹狀計(jì)算Server測(cè)試

接下來(lái)我們要對(duì)比在T2表示使用兩個(gè)不同的Group BY查詢。T2表有24 billion 行的記錄。每個(gè)記錄有一個(gè) item列表，每一item有一個(gè)amount 字段?？偣灿?0 billion個(gè)item.amount。這兩個(gè)Query分別是。

Q2: SELECT country, SUM(item.amount) FROM T2 GROUP BY countryQ3: SELECT domain, SUM(item.amount) FROM T2 WHERE domain CONTAINS ’.net’ GROUP BY domain

Q2需要掃描60GB的壓縮數(shù)據(jù)，Q3需要掃描180GB，同時(shí)還要過濾一個(gè)條件。

上圖是這兩個(gè)Query在不同的server拓?fù)湎碌男阅?。每個(gè)測(cè)試都是有2900個(gè)葉子Server。在2級(jí)拓?fù)渲?，根server直接和葉子Server通信。在3級(jí)拓?fù)渲?，各個(gè)級(jí)別的比例是1:100:2900，增加了100個(gè)中間Server。在4級(jí)拓?fù)渲?，比例?:10:100:2900.

Q2可以在3級(jí)拓?fù)湎?秒內(nèi)執(zhí)行完畢，但是為他提供更高的拓?fù)浼?jí)別，對(duì)性能提升沒有裨益。相比之下，為Q3提供更高的拓?fù)浼?jí)別，性能可以有效提升。這個(gè)測(cè)試體現(xiàn)了樹狀拓?fù)鋵?duì)性能提升的作用。

每個(gè)分區(qū)的執(zhí)行情況

對(duì)于剛剛的兩個(gè)查詢，具體的每個(gè)分區(qū)的執(zhí)行情況是這樣的。

可以看到99%的分區(qū)都在1s內(nèi)完成了。Dremel會(huì)自動(dòng)調(diào)度，使用新的Server計(jì)算拖后腿的任務(wù)。

記錄內(nèi)聚合

由于Demel支持List的數(shù)據(jù)類型，有的時(shí)候，我們需要計(jì)算每個(gè)記錄里面的各個(gè)List的聚合。如

Q4 : SELECT COUNT(c1 > c2) FROM(SELECT SUM(a.b.c.d) WITHIN RECORD AS c1,SUM(a.b.p.q.r) WITHIN RECORD AS c2FROM T3)

我們需要count所有sum(a.b.c.d)比sum(a.b.p.q.r)，執(zhí)行這條語(yǔ)句實(shí)際只需要掃描13GB的數(shù)據(jù)，耗時(shí)15s，而整張表有70TB。如果沒有這樣的嵌套數(shù)據(jù)結(jié)構(gòu)，這樣的查詢會(huì)很復(fù)雜。

擴(kuò)展性測(cè)試

Dremel有良好的擴(kuò)展性，可以通過增加機(jī)器來(lái)縮短查詢的時(shí)間。并且可以處理數(shù)以萬(wàn)億計(jì)的記錄。

對(duì)于查詢：

Q5: SELECT TOP(aid, 20), COUNT(*) FROM T4 WHERE bid = fvalue1g AND cid = fvalue2g

使用不同的葉子Server數(shù)目來(lái)進(jìn)行測(cè)試。

可以發(fā)現(xiàn)CPU的耗時(shí)總數(shù)是基本不變的，在30萬(wàn)秒左右。但是隨著節(jié)點(diǎn)數(shù)的增加，執(zhí)行時(shí)間也會(huì)相應(yīng)縮短。幾乎呈線性遞減。如果我們使用通過CPU時(shí)間計(jì)費(fèi)的“云計(jì)算”機(jī)器，每個(gè)租戶的查詢都可以很快，成本也會(huì)非常低廉。

容錯(cuò)測(cè)試

一個(gè)大團(tuán)隊(duì)里面，總有幾個(gè)拖油瓶。對(duì)于有萬(wàn)億條記錄的T5，我們執(zhí)行下面的語(yǔ)句。

Q6: SELECT COUNT(DISTINCT a) FROM T5

值得注意的是T5的數(shù)據(jù)只有兩份拷貝，所以有更高的概率出現(xiàn)壞節(jié)點(diǎn)和拖油瓶。這個(gè)查詢需要掃描大約1TB的壓縮數(shù)據(jù)，使用2500個(gè)節(jié)點(diǎn)。

可以看到99%的分區(qū)都在5S內(nèi)完成的。不幸的是，有一些分區(qū)需要較長(zhǎng)的時(shí)間來(lái)處理。盡管通過動(dòng)態(tài)調(diào)度可以加快一些，但在如此大規(guī)模的計(jì)算上面，很難完全不出問題。如果不在意太精確的結(jié)果，完全可以小小減少覆蓋的比例，大大提升相應(yīng)速度。

Google Dremel 的影響

Google Dremel的能在如此短的時(shí)間內(nèi)處理這么大的數(shù)據(jù)，的確是十分驚艷的。有個(gè)伯克利分校的教授Armando Fox說(shuō)過一句話“如果你曾事先告訴我Dremel聲稱其將可做些什么，那么我不會(huì)相信你能開發(fā)出這種工具”。這么給力的技術(shù)，必然對(duì)業(yè)界造成巨大的影響。第一個(gè)被波及到的必然是Hadoop。

Dremel與Hadoop

Dremel的公開論文里面已經(jīng)說(shuō)的很明白，Dremel不是用來(lái)替代MapReduce，而是和其更好的結(jié)合。Hadoop的Hive，Pig無(wú)法提供及時(shí)的查詢，而Dremel的快速查詢技術(shù)可以給Hadoop提供有力的補(bǔ)充。同時(shí)Dremel可以用來(lái)分析MapReduce的結(jié)果集，只需要將MapReduce的OutputFormat修改為Dremel的格式，就可以幾乎不引入額外開銷，將數(shù)據(jù)導(dǎo)入Dremel。使用Dremel來(lái)開發(fā)數(shù)據(jù)分析模型，MapReduce來(lái)執(zhí)行數(shù)據(jù)分析模型。

Hadoop的Hive,Pig現(xiàn)在也有了列存的模式，架構(gòu)上和Dremel也接近。但是無(wú)論存儲(chǔ)結(jié)構(gòu)還是計(jì)算方式都沒有Dremel精致。對(duì)Hadoop實(shí)時(shí)性的改進(jìn)也一直是個(gè)熱點(diǎn)話題。要想在Hadoop中山寨一個(gè)Dremel，并且相對(duì)現(xiàn)有解決方案有突破，筆者覺得Hadoop自身需要一些改進(jìn)。一個(gè)是HDFS需要對(duì)并發(fā)細(xì)碎的數(shù)據(jù)讀性能有大的改進(jìn)，HDFS需要更加的低延遲。再者是Hadoop需要不僅僅支持MapReduce這一種計(jì)算框架。其他部分,Hadoop都有對(duì)應(yīng)的開源組件，萬(wàn)事俱備只欠東風(fēng)。

Dremel的開源實(shí)現(xiàn)

Dremel現(xiàn)在還沒有一個(gè)可以運(yùn)行的開源實(shí)現(xiàn)，不過我們看到很多努力。一個(gè)是Apache的Drill，一個(gè)是OpenDremel/Dazo。

OpenDremel/Dazo

OpenDremel是一個(gè)開源項(xiàng)目，最近改名為Dazo。可以在GoogleCode上找到http://code.google.com/p/dremel/。目前還沒有發(fā)布。作者聲稱他已經(jīng)完成了一個(gè)通用執(zhí)行引擎和OpenStack Swift的集成。筆者感覺其越走越歪，離Dremel越來(lái)越遠(yuǎn)了。

Apache Drill

Drill 是Hadoop的贊助商之一MapR發(fā)起的。Drill作為一個(gè)Dremel的山寨項(xiàng)目，有和Dremel相似的架構(gòu)和能力。他們希望Drill最終會(huì)想Hive,Pig一樣成為Hadoop上的重要組成部分。為Hadoop提供快速查詢的能力。和Dremel有一點(diǎn)不同，在數(shù)據(jù)模型上，開源的項(xiàng)目需要支持更標(biāo)準(zhǔn)的數(shù)據(jù)結(jié)構(gòu)。比如CSV和JSON。同時(shí)Drill還有更大的靈活性，支持多重查詢語(yǔ)言，多種接口。

現(xiàn)在Drill的目標(biāo)是完成初始的需求，架構(gòu)。完成一個(gè)初始的實(shí)現(xiàn)。這個(gè)實(shí)現(xiàn)包括一個(gè)執(zhí)行引擎和DrQL。DrQL是一個(gè)基于列的格式，類似于Dremel。目前，Drill已經(jīng)完成的需求和架構(gòu)設(shè)計(jì)?？偣卜譃榱怂膫€(gè)組件

• Query language:類似Google BigQuery的查詢語(yǔ)言，支持嵌套模型，名為DrQL.
• Low-lantency distribute execution engine:執(zhí)行引擎，可以支持大規(guī)模擴(kuò)展和容錯(cuò)?？梢赃\(yùn)行在上萬(wàn)臺(tái)機(jī)器上計(jì)算數(shù)以PB的數(shù)據(jù)。
• Nested data format:嵌套數(shù)據(jù)模型，和Dremel類似。也支持CSV,JSON,YAML類似的模型。這樣執(zhí)行引擎就可以支持更多的數(shù)據(jù)類型。
• Scalable data source: 支持多種數(shù)據(jù)源，現(xiàn)階段以Hadoop為數(shù)據(jù)源。

目前這四個(gè)組件在分別積極的推進(jìn)，Drill也非常希望有社區(qū)其他公司來(lái)加入。Drill希望加入到Hadoop生態(tài)系統(tǒng)中去。

最后的話

本文介紹了Google Dremel的使用場(chǎng)景，設(shè)計(jì)實(shí)現(xiàn)，測(cè)試實(shí)驗(yàn)，和對(duì)開源世界的影響。相信不久的將來(lái)，Dremel的技術(shù)會(huì)得到廣泛的應(yīng)用。