Greenplum高性能數(shù)據(jù)引擎探秘
原創(chuàng)【51CTO獨(dú)家特稿】Greenplum數(shù)據(jù)引擎是為新一代數(shù)據(jù)倉(cāng)庫(kù)和大規(guī)模分析處理而建立的軟件解決方案。其最大的特點(diǎn)是不需要高端的硬件支持仍然可以支撐大規(guī)模的高性能數(shù)據(jù)倉(cāng)庫(kù)和商業(yè)智能查詢。在數(shù)據(jù)倉(cāng)庫(kù)、商業(yè)智能的應(yīng)用上,尤其海量數(shù)據(jù)的處理方面性能極其優(yōu)異。
高性能的大規(guī)模數(shù)據(jù)處理能力是DBA對(duì)數(shù)據(jù)庫(kù)夢(mèng)寐以求的能力之一。從字面上不難看出,“高性能的大規(guī)模數(shù)據(jù)處理能力”中,一方面是針對(duì)“大規(guī)模的數(shù)據(jù)”,另一方面就是“數(shù)據(jù)的處理”,施加于二者之上的要求是“高性能”。
所以,高性能數(shù)據(jù)引擎也都是基于這兩個(gè)方面的來(lái)最求高效:“大規(guī)模”需要的是數(shù)據(jù)吞吐能力,就是所謂的I/O;“數(shù)據(jù)處理”需要的是并行計(jì)算能力,即充分利用硬件資源對(duì)任務(wù)及進(jìn)程的最大化運(yùn)行。
在理解提升I/O和并行計(jì)算的能力之前,我們需要深入Greenplum的核心,了解一下Greenplum的Shared Nothing架構(gòu)。
Shared Nothing架構(gòu)
與Oracle RAC的Shared Everything架構(gòu)不同,Greenplum采用Shared Nothing架構(gòu)。整個(gè)集群由很多個(gè)數(shù)據(jù)節(jié)點(diǎn)(Segment Host)和控制節(jié)點(diǎn)(Master Host)組成,其中每個(gè)數(shù)據(jù)節(jié)點(diǎn)上可以運(yùn)行多個(gè)數(shù)據(jù)庫(kù)。
簡(jiǎn)單來(lái)說(shuō),Shared Nothing是一個(gè)分布式的架構(gòu),每個(gè)節(jié)點(diǎn)相對(duì)獨(dú)立。典型的Shared Nothing系統(tǒng)會(huì)集數(shù)據(jù)庫(kù)、內(nèi)存Cache、等存儲(chǔ)狀態(tài)的信息;而不在節(jié)點(diǎn)上保存狀態(tài)的信息。
對(duì)于應(yīng)對(duì)大規(guī)模數(shù)據(jù)處理的服務(wù)器集群設(shè)備,若將Session狀態(tài)信息保存在各個(gè)數(shù)據(jù)節(jié)點(diǎn)上,各節(jié)點(diǎn)的Session復(fù)制會(huì)極大的影響性能;若采用Shared Nothing,保持每個(gè)節(jié)點(diǎn)的無(wú)狀態(tài)性,不再使用Session來(lái)保持全局的狀態(tài),而是將Session直接放在數(shù)據(jù)庫(kù)中,在數(shù)據(jù)庫(kù)前再加一層如Memcached分布式Cache,這樣將可極大的提高性能,當(dāng)改變Session中的對(duì)象時(shí),將同步到Cache和數(shù)據(jù)庫(kù)。
基于Shared Nothing的分布式架構(gòu)模式,Greenplum在高效處理I/O數(shù)據(jù)吞吐和并發(fā)計(jì)算的過(guò)程就很好理解。
高效I/O的實(shí)現(xiàn)
I/O瓶頸是數(shù)據(jù)庫(kù),特別是大規(guī)模數(shù)據(jù)分析處理中永恒的話題。在Greenplum中,需要存儲(chǔ)的數(shù)據(jù)在進(jìn)入進(jìn)入數(shù)據(jù)庫(kù)時(shí),將首先進(jìn)行數(shù)據(jù)分布的處理工作;將一個(gè)表里的數(shù)據(jù)平均分布到每個(gè)節(jié)點(diǎn),并為每個(gè)表指定一個(gè)分發(fā)列(distribute Column),之后便根據(jù)Hash來(lái)分布數(shù)據(jù)。
基于Shared Nothing的原則,Greenplum這樣處理可以充分發(fā)揮每個(gè)節(jié)點(diǎn)處I/O的處理能力。在這一過(guò)程中,控制節(jié)點(diǎn)(Master Host)將不再承擔(dān)計(jì)算任務(wù),而只負(fù)責(zé)必要的邏輯控制和客戶端交互。
這是Greenplum的獨(dú)到之處。在多數(shù)集群的大規(guī)模數(shù)據(jù)處理系統(tǒng)中,都使用中心節(jié)點(diǎn)進(jìn)行大量的控制和計(jì)算,大量的數(shù)據(jù)交換過(guò)程中將造成中心節(jié)點(diǎn)的負(fù)載過(guò)大;多數(shù)情況下,數(shù)據(jù)庫(kù)的I/O瓶頸在這一位置(處理過(guò)程)形成病灶,進(jìn)而隨多核心CPU時(shí)序控制和處理響應(yīng)的時(shí)段等問(wèn)題開(kāi)始蔓延,最終致使系統(tǒng)中很多節(jié)點(diǎn)的I/O位置病入膏肓。
在Greenplum中,控制節(jié)點(diǎn)只負(fù)責(zé)必要的邏輯處理和客戶端交互,節(jié)點(diǎn)間的數(shù)據(jù)交互將直接在節(jié)點(diǎn)間完成,而不需要控制節(jié)點(diǎn);在一定的硬件資源支持下,高效I/O不再是DBA的夢(mèng)想。
并行計(jì)算能力
I/O瓶頸的解決為并行計(jì)算能力的提升創(chuàng)造了良好的環(huán)境。下面我們一起來(lái)看看Greenplum是如何進(jìn)行高性能的并行計(jì)算的。
在硬件方面,Greenplum可以使用標(biāo)準(zhǔn)的服務(wù)器并通過(guò)服務(wù)器間的高級(jí)通信連接,將多臺(tái)服務(wù)器組成一個(gè)強(qiáng)大的計(jì)算平臺(tái),實(shí)現(xiàn)快速的海量并行運(yùn)算。
在系統(tǒng)內(nèi)部,Greenplum通過(guò)自己的并行數(shù)據(jù)流引擎來(lái)實(shí)現(xiàn)更多計(jì)算需求的硬件資源調(diào)度。一般,多表JOIN操作是考驗(yàn)系統(tǒng)并行計(jì)算能力的經(jīng)典案例。在Greenplum中,這一過(guò)程是將一個(gè)表里的數(shù)據(jù)平均分布到每個(gè)節(jié)點(diǎn),并為每個(gè)表指定一個(gè)分發(fā)列,之后便根據(jù)Hash算法來(lái)分布數(shù)據(jù)。
這樣,每個(gè)節(jié)點(diǎn)的數(shù)據(jù)通過(guò)分發(fā)列即得知。如果對(duì)distribute Column做JOIN操作,只需要通過(guò)分發(fā)列得到數(shù)據(jù)的節(jié)點(diǎn)位置,并對(duì)相應(yīng)的節(jié)點(diǎn)進(jìn)行計(jì)算,最后合并結(jié)果就可完成。
當(dāng)然,這種幾個(gè)表規(guī)模的查詢還不能證明Greenplum在并行計(jì)算方面的能力。但重要的是,通過(guò)Greenplum的并行數(shù)據(jù)流引擎,我們可以在一個(gè)主機(jī)上同時(shí)啟動(dòng)多個(gè)PostgreSQL數(shù)據(jù)庫(kù)進(jìn)行更多表的關(guān)聯(lián)及更復(fù)雜的查詢操作。這就充分發(fā)揮了硬件資源的性能。

Greenplum高性能大數(shù)據(jù)數(shù)據(jù)查詢
在進(jìn)行數(shù)據(jù)裝載時(shí),不是常規(guī)的一個(gè)中心數(shù)據(jù)源將數(shù)據(jù)分發(fā)至各節(jié)點(diǎn),而是所有節(jié)點(diǎn)同時(shí)讀取數(shù)據(jù),然后根據(jù)Hash算法,將屬于自己的數(shù)據(jù)留下,將其他的節(jié)點(diǎn)的數(shù)據(jù)通過(guò)網(wǎng)絡(luò)直接傳送給需求方。這種多數(shù)據(jù)流的并行傳輸保證了高性能的數(shù)據(jù)裝載速度。
在進(jìn)行并發(fā)數(shù)據(jù)分析時(shí),Greenplum的另一個(gè)強(qiáng)大之處是支持對(duì)一個(gè)Segment節(jié)點(diǎn)的虛擬化,在載入數(shù)據(jù)后,我們可以對(duì)數(shù)據(jù)節(jié)點(diǎn)虛擬多個(gè)數(shù)據(jù)庫(kù)進(jìn)行并行分析操作,依舊源于Share nothing架構(gòu),Greenplum的一個(gè)Segment可支持2-10個(gè)虛擬數(shù)據(jù)庫(kù)(官方推薦為6個(gè)),可以最大限度發(fā)揮硬件設(shè)備,提高并行規(guī)模和查詢分析效率。
【編輯推薦】





























