Spark查詢太慢?試試這款 Mpp 數據庫吧!
一、Greenplum數據庫架構
Greenplum數據庫是典型的主從架構,一個Greenplum集群通常由一個Master節點、一個Standby Master節點以及多個Segment實例組成,節點之間通過高速網絡互連,如下圖所示。Standby Master節點為Master節點提供高可用支持,Mirror Segment實例為Segment實例提供高可用支持。當Master節點出現故障時,數據庫管理系統可以快速切換到Standby Master節點繼續提供服務。
從軟件的角度看,Greenplum數據庫由Master節點、Segment實例和Interconnect組件三部分組成,各個功能模塊在系統中承載不同的角色。
Master節點是Greenplum數據庫的主節點,也是數據庫的入口,主要負責接收用戶的SQL請求,將其生成并行查詢計劃并優化,然后將查詢計劃分配給所有的Segment實例進行處理,協調集群的各個Segment實例按照查詢計劃一步一步地并行處理,最后獲取Segment實例的計算結果并匯總后返回給客戶端。
從用戶的角度看Greenplum集群,看到的只是Master節點,無須關心集群內部機制,所有的并行處理都是在Master節點控制下自動完成的。Master節點一般只存儲系統數據,不存儲用戶數據。為了提高系統可用性,我們通常會在Greenplum集群的最后一個數據節點上增加一個Standby Master節點。
Segment是Greenplum實際存儲數據和進行數據讀取計算的節點,每個Segment都可以視為一個獨立的PostgreSQL實例,上面存放著一部分用戶數據,同時參與SQL執行工作。Greenplum Datanode通常是指Segment實例所在的主機,用戶可以根據Datanode的CPU數、內存大小、網絡寬帶等來確定其上面的Segment實例個數。官方建議一個Datanode上面部署2~8個Segment實例。Segment實例越多,單個實例上面的數據越少(平均分配的情況下),單個Datanode的資源使用越充分,查詢執行速度就越快。Datanode服務器的數量根據集群的數據量來確定,最大可以支持上千臺。另外,為了提高數據的安全性,我們有時候會在生產環境中創建Mirror Segment實例作為備份鏡像。
Interconnect是Master節點與Segment實例、Segment實例與Segment實例之間進行數據傳輸的組件,它基于千兆交換機或者萬兆交換機實現數據在節點之間的高速傳輸。默認情況下,Interconnect組件使用UDP在集群網絡節點之間傳輸數據,因為UDP無法保證服務質量,所以Interconnect組件在應用層實現了數據包驗證功能,從而達到和TCP一樣的可靠性。
Greenplum執行查詢語句的過程如下:當GP Server收到用戶發起的查詢語句時,會對查詢語句進行編譯、優化等操作,生成并行執行計劃,分發給Segment實例執行;Segment實例通過Interconnect組件和Master節點、其他Segment實例交換數據,然后執行查詢語句,執行完畢后,會將數據發回給Master節點,最后Master節點匯總返回的數據并將其反饋給查詢終端。
二、Greenplum的優勢
首先,與傳統數據庫相比,Greenplum作為分布式數據庫,本身具有高性能優勢。對各行各業來說,OLTP系統最重要的是在保證ACID事務管理屬性的前提下滿足業務的并發需求,對于大多數非核心應用場景,MySQL、SQL Server、DB2、Oracle都可以滿足系統要求,并且隨著MySQL性能的優化和云原生數據庫的發展,基于MySQL或者PostgreSQL商業化的數據庫會越來越普及。數據中臺的定位是一個OLAP系統,上述數據庫就很難滿足海量數據并發查詢的要求了。上述數據庫的橫向擴展能力有限,并且軟硬件成本高昂,不適合作為OLAP系統的數據庫。Greenplum作為一款基于MPP架構的數據庫,具有開源、易于擴展、高查詢性能的特點,性價比碾壓DB2、Oracle、Teradata等傳統數據庫。
其次,Greenplum作為分布式數據庫,和同為分布式數據庫的Hive相比,優勢也非常明顯。早期Hadoop的無模式數據已經讓開發者飽受痛苦,后面興起的Hive、Presto、Spark SQL雖然支持簡單的SQL,但是查詢性能仍然是分鐘級別的,很難滿足OLAP的實時分析需求。后期雖有Impala+Kudu,但是查詢性能仍然弱于同為MPP架構的Greenplum。除此之外,Hadoop生態圈非常復雜,安裝和維護的工作量都很大,沒有專業的運維團隊很難支撐系統運行。而Greenplum支持的SQL標準最全面,查詢性能在毫秒級,不僅能很好地支持數據ETL處理和OLAP查詢,還支持增刪改等操作,是一款綜合實力非常強的數據庫。相對于Hadoop多個組件組成的龐大系統,Greenplum數據庫在易用性、可靠性、穩定性、開發效率等方面都有非常明顯的優勢。
最后,Greenplum作為MPP數據庫中的一員,相對于其他MPP架構數據庫,也具有非常明顯的優勢。Greenplum研發歷史長、應用范圍廣、開源穩定、生態系統完善。生態系統完善是指Greenplum的工具箱非常多:GPload可滿足高速加載需求,PXF可滿足外置表和文件存儲需求,MADlib可滿足數據挖掘需求,GPCC可滿足系統監控運維需求。相對于TiDB、TBase、GaussDB等新興數據庫來說,Greenplum的應用案例最多,生態系統最完善,并且Bug更少。同時,TiDB、TBase、GaussDB等數據庫都定位于優先滿足OLTP的同時提高OLAP的性能,而Greenplum是以OLAP優先的。雖然前者也有優勢,但是將OLAP和OLTP合并實現起來存在以下困難:數據分布在不同的系統已經是行業現實,沒有辦法將數據集中到同一個數據庫;數據中臺天然就是一個OLAP系統,沒有辦法按照OLTP模式設計。綜上,作為分布式關系型數據庫,Greenplum是搭建數據中臺的首選數據庫。
如下圖是阿里巴巴大數據平臺進化歷程。2010年前后,阿里巴巴曾經使用Greenplum來替換Oracle集群,將其作為數據分析平臺。從數量上說,Greenplum在2010年實現了Oracle 10倍數據量的管理,即1000TB。但Oracle的架構這些年沒有太大變化,而Greenplum數據庫已有翻天覆地的革新。在阿里巴巴應用的時代,Greenplum還是EMC旗下的商用數據庫,平臺尚在發育期,功能也不太完善。而如今的Greenplum已經是社區開源的產品,內核PostgreSQL也已完成了多個版本的升級迭代,現在更是輕輕松松支持上千臺服務器的集群,因此承載PB級的數據自不在話下。
對于大多數有構建數據中臺需求的企業,1000TB已經是一個無法企及的高度。大多數據企業的數據都在數TB到100TB的范圍內,這個規模的數據正是Greenplum的主要戰場。100TB以下規模的數據倉庫或者數據中臺,Hive發揮不了架構上的優勢,反而影響開發速度和運維工作,實在是得不償失。
在查詢性能方面,Greenplum自然不是第一,雖然業界尚無定論,但是據筆者了解,目前ClickHouse是當之無愧的OLAP冠軍。相對于ClickHouse,Greenplum勝在高性能的GPload插件、強大的ETL功能、不算太弱的增刪改性能。目前,數據中臺在穩步向實時流處理邁進,由于不擅長單條更新和刪除,因此ClickHouse只適合執行離線數據查詢任務,可以作為超大規模數據中臺的OLAP查詢引擎。
綜上所述,雖然Greenplum某些方面不是最優秀的,但仍是最適合搭建數據中臺的分布式數據平臺,并且以Greenplum現有的性能和管理的數據規模,可以滿足絕大多數中小企業的數據中臺需求。
三、Greenplum性能測試
gpcheckperf是Greenplum數據庫自帶的性能測試工具,在指定的主機上啟動會話并進行以下性能測試。
1)磁盤I/O測試(dd測試):測試邏輯磁盤或文件系統的順序吞吐性能,該工具使用dd命令。dd命令是一個標準的UNIX工具,記錄了在磁盤上讀寫一個大文件需要花費的時間,以MB/s為單位計算磁盤I/O性能。默認情況下,用于測試的文件尺寸按照主機上隨機訪問內存(RAM)的兩倍計算。這樣確保了測試是真正地測試磁盤I/O而不是使用內存緩存。
2)內存帶寬測試:為了測試內存帶寬,該工具使用STREAM基準程序來測量可持續的內存帶寬(以MB/s為單位)。本項測試內容是檢驗操作系統在不涉及CPU計算性能的情況下是否受系統內存帶寬的限制。在數據集較大的應用程序中(如在Greenplum數據庫中),低內存帶寬是一個主要的性能問題。如果內存帶寬明顯低于CPU的理論帶寬,則會導致CPU花費大量的時間等待數據從系統內存傳遞過來。
3)網絡性能測試:為了測試網絡性能以及Greenplum數據庫Interconnect組件的性能,該工具運行一種網絡基準測試程序,該程序在當前主機連續發送5s的數據流到測試包含的每臺遠程主機上。數據被并行傳輸到每臺遠程主機,并以MB/s為單位,分別報告最小、最大、平均和中位網絡傳輸速率。如果匯總的傳輸速率比預期慢(小于100MB/s),可以使用-r N選項串行運行該網絡測試以獲取每臺主機的結果。要運行全矩陣帶寬測試,用戶可以指定-r M選項,這將導致每臺主機都發送和接收來自指定的其他主機的數據。該測試適用于驗證交換結構是否可以承受全矩陣負載。
gpcheckperf命令應用舉例如下。
- #使用/data1和/data2作為測試目錄在文件host_file中的所有主機上運行磁盤I/O和內存帶寬測試
- gpcheckperf -f hostfile_gpcheckperf -d /data1 -d /data2 -r ds
- #在名為sdw1和sdw2的主機上只使用測試目錄/data1運行磁盤I/O測試。顯示單個主機結果并以詳細模式運行
- gpcheckperf -h sdw1 -h sdw2 -d /data1 -r d -D -v
- #使用測試目錄/tmp運行并行網絡測試,其中hostfile_gpcheck_ic*指定同一Interconnect子網內的所有網絡接口的主機地址名稱
- gpcheckperf -f hostfile_gpchecknet_ic1 -r N -d /tmp
- gpcheckperf -f hostfile_gpchecknet_ic2 -r N -d /tmp
性能測試時間通常較長,為了進行完整的測試,我一般會創建如下測試腳本,在后臺執行性能測試任務。
- #創建如下shell腳本
- [gpadmin@gp-master ~]$ cat gpcheckperf-test.sh
- #!bin/bash
- echo "--------- start ----------- "
- a=`date +"%Y-%m-%d %H:%M:%S"`
- echo $a
- gpcheckperf -f /data/greenplum/greenplum-db/all_hosts -d /data/greenplum/ -v
- echo "------------- end ----------"
- b=`date +"%Y-%m-%d %H:%M:%S"`
- echo $b
性能測試后臺執行nohup sh gpcheckperf-test.sh &命令后,查看nohup.out的輸出結果,如下圖所示(每臺服務器采用10塊普通硬盤通過軟件組成Raid 5)。
關于作者:王春波,資深架構師和數據倉庫專家,現任上海啟高信息科技有限公司大數據架構師,Apache Doris和openGauss貢獻者,Greenplum中文社區參與者。 公眾號“數據中臺研習社”運營者。
本文摘編于《高效使用Greenplum:入門、進階與數據中臺》,經出版方授權發布。(書號:9787111696490)轉載請保留文章來源。