【文章內(nèi)容簡介】 敗，則只能整個(gè)流水線整體失敗?；赥ree結(jié)構(gòu)的MPP并行查詢引擎MPP并行數(shù)據(jù)庫與Dremel、impala、Presto、Shard query、Citusdb都采用的是基于Tree結(jié)構(gòu)并行查詢引擎。此類并行計(jì)算引擎共同特點(diǎn)是：一是針對SQL專用并行計(jì)算引擎，只支持SQL或者類SQL語義。二是執(zhí)行計(jì)劃都是樹狀結(jié)構(gòu)；三是以流水線或者將中間結(jié)果放入內(nèi)存方式來實(shí)現(xiàn)快速計(jì)算。四是粗粒度容錯(cuò)機(jī)制。它們之間不同點(diǎn)：一 MPP并行數(shù)據(jù)庫中并行查詢引擎與底層存儲(chǔ)是緊耦合的，導(dǎo)致如果采用MPP并行數(shù)據(jù)庫，則只能通過SQL來訪問數(shù)據(jù)，無法采用其他計(jì)算引擎直接處理存儲(chǔ)在數(shù)據(jù)庫中的數(shù)據(jù)。二 Impala、Presto都只是一個(gè)并行查詢引擎，它們可以直接查詢以文件方式存儲(chǔ)在HDFS上的數(shù)據(jù),這樣同一份數(shù)據(jù)既可以利用這些引擎來實(shí)現(xiàn)交互式查詢，也可以支持利用其他計(jì)算框架進(jìn)行更深入分析。三 Dremel 只支持Google自己的基于嵌套結(jié)構(gòu)列式存儲(chǔ)(Column IO)。該引擎也主要適合于聚合型計(jì)算，不支持join操作。四 上述引擎中只有MPP并行數(shù)據(jù)庫可以利用索引以及各種統(tǒng)計(jì)信息來優(yōu)化物理執(zhí)行過程，因此該系統(tǒng)執(zhí)行效率應(yīng)該是最高。五 Dremel、impala都只適合中間結(jié)果越來越小的查詢，因?yàn)檫@些系統(tǒng)都是把中間結(jié)果放在內(nèi)存，一旦某個(gè)中間節(jié)點(diǎn)輸出結(jié)果超過內(nèi)存，則整個(gè)任務(wù)會(huì)失敗，例如大表之間Join。六 shard query和citusdb 都是在單機(jī)版本關(guān)系數(shù)據(jù)庫基礎(chǔ)上，采用增加一層中間件方式來支持并行查詢。n基于Tree并行計(jì)算引擎與基于DAG并行計(jì)算引擎本質(zhì)區(qū)別基于Tree結(jié)構(gòu)并行計(jì)算引擎與基于DAG并行計(jì)算引擎從表面上看，它們之間的主要區(qū)別是在于語義層面：前者主要專用與SQL類，而后者更通用。但是MPP并行關(guān)系數(shù)據(jù)庫引擎、Imapla等都會(huì)支持通過UDF來擴(kuò)展和解決標(biāo)準(zhǔn)SQL語言表達(dá)能力，另外SQL語言本身可以通過嵌套查詢、子查詢、union等各種方法表達(dá)很復(fù)雜的計(jì)算過程，因此從語義表達(dá)層面來講他們之間不存在本質(zhì)區(qū)別。這兩者之間主要區(qū)別還是在于表達(dá)執(zhí)行計(jì)劃結(jié)構(gòu)方面：樹結(jié)構(gòu)是一個(gè)逐步匯聚的一個(gè)計(jì)算過程，無法表達(dá)split結(jié)構(gòu)，因此基于DAG表達(dá)結(jié)構(gòu)更靈活和通用。個(gè)人認(rèn)為：樹型結(jié)構(gòu)可能更加適合采用迭代器模型來實(shí)現(xiàn)流水線式的操作(只有樹結(jié)構(gòu)才有上下層的關(guān)系，因此方便實(shí)現(xiàn)上層操作符嵌套調(diào)用下層操作符)。所以不是所有計(jì)算都可以通過一個(gè)復(fù)雜SQL語句來表達(dá)！(5) 自動(dòng)并行化、數(shù)據(jù)重分布、本地調(diào)度并行計(jì)算引擎最重要的一個(gè)職責(zé)是自動(dòng)并行。根據(jù)前面的并行計(jì)算基礎(chǔ)知識(shí)，并行計(jì)算的形式主要包括：基于數(shù)據(jù)劃分水平并行、基于流水線垂直并行、基于無依賴水平并行三種方式。大數(shù)據(jù)屬于數(shù)據(jù)密集型計(jì)算，數(shù)據(jù)數(shù)量遠(yuǎn)遠(yuǎn)超過計(jì)算步驟數(shù)量。因此基于數(shù)據(jù)劃分并行方式是最有效的一種并行計(jì)算方法。在整個(gè)并行計(jì)算過程中，基于數(shù)據(jù)劃分中涉及數(shù)據(jù)可以分為兩大類：原始數(shù)據(jù)與中間結(jié)果數(shù)據(jù)。n原始數(shù)據(jù)劃分以及SN、SD架構(gòu)討論原始數(shù)據(jù)則可能存在兩種情況：一是在Sharednothing架構(gòu)中，原始數(shù)據(jù)本身就已經(jīng)劃分好了，例如HDFS或者SN架構(gòu) MPP數(shù)據(jù)庫；另外一種情況如shareddisk結(jié)構(gòu)中，原始數(shù)據(jù)沒有劃分。第一種情況下針對原始數(shù)據(jù)劃分并行計(jì)算，就要受該劃分的限制。例如在MAPREDUCE中，map輸入是存儲(chǔ)在HDFS上的數(shù)據(jù)文件，因此MAP實(shí)例個(gè)數(shù)一是不能少于該數(shù)據(jù)文件分片數(shù)，二是MAP實(shí)例最好運(yùn)行在該數(shù)據(jù)文件所在機(jī)器，也就是要求任務(wù)調(diào)度時(shí)，能把該任務(wù)調(diào)度到特定機(jī)器上，即所謂“本地調(diào)度”，將計(jì)算盡量移動(dòng)到數(shù)據(jù)。第二種情況下，由于所有計(jì)算節(jié)點(diǎn)都可以看到所有數(shù)據(jù)，因此此時(shí)可以根據(jù)計(jì)算特點(diǎn)靈活選擇：數(shù)據(jù)劃分粒度、并行度、參與計(jì)算的節(jié)點(diǎn)。例如在ORALCE并性機(jī)制中，ORALCE可以針對某張表，按block或者partition 為單位進(jìn)行劃分。根據(jù)上述分析我們可以發(fā)現(xiàn)SD架構(gòu)相對SN架構(gòu)，在針對原始數(shù)據(jù)第一級并性計(jì)算時(shí)，SD架構(gòu)更靈活，SN架構(gòu)面臨的一個(gè)缺陷就是如果原始數(shù)據(jù)分布不均衡，則存在計(jì)算傾斜問題。但是現(xiàn)在大部分大的數(shù)據(jù)庫廠商的MPP數(shù)據(jù)庫還是采用了SN架構(gòu)。根據(jù)網(wǎng)上所查資料來看,主要原因有兩點(diǎn)：一是SD架構(gòu)下，磁盤是一個(gè)共享資源，計(jì)算節(jié)點(diǎn)越多磁盤爭搶概率越大(和RAID隨機(jī)IO沖突道理一樣)，導(dǎo)致該架構(gòu)可擴(kuò)展性不夠好，也就是可能計(jì)算節(jié)點(diǎn)越多，效率相反不會(huì)提高。二是從緩存角度來看，SD架構(gòu)下每個(gè)機(jī)器緩存都要面向全數(shù)據(jù)庫，會(huì)導(dǎo)致命中概率底下；目前ORACLERAC開發(fā)一個(gè)fusion cache技術(shù)，實(shí)現(xiàn)了一個(gè)全局共享緩存來解決上述問題，但是可想而知這會(huì)影響系統(tǒng)可擴(kuò)展性。因此超過一定規(guī)模數(shù)據(jù)分析系統(tǒng)，都是采用SN架構(gòu)。中間結(jié)果數(shù)據(jù)劃分與數(shù)據(jù)重分布中間結(jié)果是由各個(gè)計(jì)算節(jié)點(diǎn)產(chǎn)生的，因此中間結(jié)果生成是就是分布在各個(gè)參與計(jì)算節(jié)點(diǎn)之上的，因此：一 ：SD架構(gòu)下數(shù)據(jù)共享好處，對中間結(jié)果無效。二 ：如果由于計(jì)算任務(wù)之間需要，需要在任務(wù)之間傳遞中間結(jié)果，則即使是SD架構(gòu)也存在數(shù)據(jù)重分布的問題，主要是中間結(jié)果重分布，也就是中間結(jié)果傳輸。另外從該過程我們還可以得出另外一個(gè)結(jié)論：一： 對于復(fù)雜的數(shù)據(jù)處理，索引只能影響第一級計(jì)算，對于中間結(jié)果，由于只使用一次，因此沒有必要去針對中間結(jié)果建立索引。也就是即使我們將數(shù)據(jù)存儲(chǔ)在關(guān)系型數(shù)據(jù)庫中，也只有第一級計(jì)算能有效利用數(shù)據(jù)庫索引。二：即使采用并行數(shù)據(jù)庫，如果我們的整個(gè)計(jì)算過程不能用一個(gè)SQL語句來表達(dá)，則我們必須自己解決中間結(jié)果的劃分與并性計(jì)算的問題。(6)并行計(jì)算引擎架構(gòu)與資源管理所有并行計(jì)算引擎實(shí)現(xiàn)基本上都是主從結(jié)構(gòu)，即一個(gè)MASTER + 多個(gè)slave節(jié)點(diǎn)的結(jié)構(gòu)。由client向MASTER提交一個(gè)job,然后由Master負(fù)責(zé)將邏輯執(zhí)行計(jì)劃變成實(shí)際執(zhí)行計(jì)劃，并由Master負(fù)責(zé)將各個(gè)任務(wù)分發(fā)到各個(gè)slave中，并負(fù)責(zé)各個(gè)任務(wù)的調(diào)度。MPP數(shù)據(jù)庫查詢引擎架構(gòu)MAPREDUCE架構(gòu)和該架構(gòu)缺點(diǎn)Mapreduce框架中，JobTracker承當(dāng)MASTER的職責(zé)，一般和HDFS中的NadeNode節(jié)點(diǎn)安裝在一個(gè)服務(wù)器上。TaskTracker安裝在各個(gè)DataNode上，承擔(dān)Slave的角色。流程如下：(1)首先用戶程序(Client Program)提交了一個(gè)job，job的信息會(huì)發(fā)送到Job Tracker中，Job Tracker是Mapreduce框架的中心，他需要與集群中的機(jī)器定時(shí)通信(heartbeat), 需要管理哪些程序應(yīng)該跑在哪些機(jī)器上，需要管理所有job失敗、重啟等操作。(2)TaskTracker是Mapreduce集群中每臺(tái)機(jī)器都有的一個(gè)部分，他做的事情主要是監(jiān)視自己所在機(jī)器的資源情況（資源的表示是“本機(jī)還能起多少個(gè)maptask，多少個(gè)reducetask”，每臺(tái)機(jī)器起map/reduce task的上限是在建立集群的時(shí)候配置的），另外TaskTracker也會(huì)監(jiān)視當(dāng)前機(jī)器的tasks運(yùn)行狀況。(3)TaskTracker需要把這些信息通過heartbeat發(fā)送給JobTracker，JobTracker會(huì)搜集這些信息以給新提交的job分配運(yùn)行在哪些機(jī)器上。MAPREDUCE結(jié)構(gòu)存在以下缺點(diǎn)：(1) jobtracker只能安裝在一臺(tái)服務(wù)器上，集中式作業(yè)控制導(dǎo)致可擴(kuò)展性不好，另外JobTracker負(fù)責(zé)事情太多，容易成為性能瓶頸。(2) 資源調(diào)度與編程模型緊耦合，只支持MAPREDUCE一種編程模型。(3) 資源劃分太簡單，每個(gè)TaskTracker只是簡單把整個(gè)機(jī)器資源按map task slot和reduce task slot來劃分，而沒有考慮不通任務(wù)所需的內(nèi)存和CPU等的資源不同。針對上述特點(diǎn)，hadoop平臺(tái)開發(fā)通用的資源管理器yarn，只負(fù)責(zé)資源管理和分配，即通過把jobtrack中的資源管理分配自和并行應(yīng)用程序調(diào)度與控制分離，從而實(shí)現(xiàn)雙層調(diào)度框架：由yarn把資源分配給各計(jì)算引擎MASTER，再由MASTER分配給各個(gè)TASK。資源管理器YARN流程如下：1) client 通過一個(gè)CLC (container launch context )向ResourceManager提交一個(gè)應(yīng)用2)RM 啟動(dòng)該應(yīng)用的 AplicationMaster。 AplicationMaster啟動(dòng)后先向ResourceManager注冊，并利用心跳信息，定期向ResourceManager報(bào)告自己存活性和資源分配請求3)ResourceManager分配一個(gè)container(container包括CPU個(gè)數(shù)和所需內(nèi)存數(shù)量)時(shí)， AplicationMaster構(gòu)造一個(gè)CLC,并在該container對應(yīng)機(jī)器上Nodemanager上啟動(dòng)該container。AplicationMaster 監(jiān)控該container的運(yùn)行狀態(tài)，并且該資源需要被回收時(shí)，由AplicationMaster停止該container。 監(jiān)控container內(nèi)部的作業(yè)的執(zhí)行進(jìn)度是AplicationMaster的職責(zé)。4)一旦整個(gè)運(yùn)行完畢，AM從RM中解除注冊，并且干凈退出。這種架構(gòu)優(yōu)點(diǎn)是：優(yōu)點(diǎn)一：減小了JobTracker（也就是現(xiàn)在的ResourceManager）的資源消耗，并且讓監(jiān)測每一個(gè)Job子任務(wù)(tasks)狀態(tài)的程序分布式化了，更安全、更優(yōu)美。也就是ApplicationMaster是每個(gè)應(yīng)用一個(gè)，并且不通應(yīng)用對應(yīng)的ApplicationMaster的實(shí)例可以運(yùn)行在不同服務(wù)器上。優(yōu)點(diǎn)二：能夠支持不同的編程模型ApplicationMaster是一個(gè)可變更的部分，用戶可以對不同的編程模型寫自己的ApplicationMaster，讓更多類型的編程模型能夠跑在Hadoop集群中。優(yōu)點(diǎn)三：對于資源的表示比之前以剩余slot數(shù)目更合理。3) 存儲(chǔ)層數(shù)據(jù)存儲(chǔ)層主要包括以下幾類：一類是基于MPP數(shù)據(jù)庫集群，這類系統(tǒng)特點(diǎn)是存儲(chǔ)層與上層并型計(jì)算引擎是緊耦合，屬于封閉性的系統(tǒng)。二是