HashData實戰(zhàn)案例：使用Alluxio構(gòu)建云原生分析型MPP數(shù)據(jù)庫

1、HashData實戰(zhàn)案例：使Alluxio構(gòu)建云原分析型MPP數(shù)據(jù)庫本將介紹北京家初創(chuàng)企業(yè)構(gòu)建基于云原的MPP平臺的過程。該企業(yè)利對象存儲作為數(shù)據(jù)持久層，Alluxio作為云中的數(shù)據(jù)編排層，最終構(gòu)建了個原云性能MPP共享的體系架構(gòu)。HashData是由群來Pivotal、Teradata、IBM、Yahoo!等開源數(shù)據(jù)資深于2016年創(chuàng)的。它的旗艦產(chǎn)品HashDataWareHouse(HDW)，是為云環(huán)境構(gòu)建的數(shù)據(jù)倉庫服務，具有完全兼容的分析接。HDW獨特的多集群共享數(shù)據(jù)庫體系架構(gòu)，在性能、并發(fā)性、靈活性和易性取得了很突破。和許多傳統(tǒng)MPP系統(tǒng)采的共享體系架構(gòu)（計算與存儲緊耦合）不同，HDW

2、采了具有解耦和獨對象存儲的共享體系架構(gòu)。這種體系架構(gòu)的主要挑戰(zhàn)在于性能。與傳統(tǒng)的塊存儲相，對象存儲通常性能較低。在本中，我們將進步分析HDW如何利Alluxio作為數(shù)據(jù)編排層，以消除對象存儲帶來的性能損失，同時受益于對象存儲的可伸縮性和成本效應。為什么使對象存儲服務如今，對象存儲服務（OSS）在原云架構(gòu)中直很重要。正如所提出的，它提供了更的可性、彈性和耐久性，且成本更低。越來越多的產(chǎn)品和服務持OSS作為他們的持久件系統(tǒng)。節(jié)省成本根據(jù)我們的觀察，對于許多擁有100 TB+數(shù)據(jù)的戶來說，他們的成本主要來存儲成本，不是計算成本。個主要原因是計算完全隨需應變，存儲容量在刪除數(shù)據(jù)之前法回收。因此，當客戶

3、考慮各種數(shù)據(jù)分析選項時，存儲成本是個重要因素。下表為中國全棧ICT服務及解決案（包括公共云服務）供應商QingCloud在PEK3區(qū)域的塊存儲和對象存儲的價格對。OSS的成本約是單副本塊存儲的1/4，多副本塊存儲的1/5。彈性也會影響存儲成本。雖然塊存儲持在線擴展，但是彈性計算機（即將擴展的塊存儲卷連接到它）在擴展期間會導致HDW集群短暫停機。因此，客戶通常會保留額外的塊存儲容量，以避免在短時間內(nèi)再次擴展，從導致成本更?？傊贠SS的數(shù)據(jù)倉庫解決案的存儲成本約是使傳統(tǒng)塊存儲成本的1/10。- 系統(tǒng)靈活性讓我們來看個典型的數(shù)據(jù)分析場景，尤其是在物聯(lián)和電信業(yè)：隨著時間的推移，越來越多的數(shù)據(jù)成并

4、被導到數(shù)據(jù)倉庫系統(tǒng)中。通常，由于應程序需求或管理策略的原因，這些數(shù)據(jù)需要保存18或36個。此外，所有數(shù)據(jù)必須隨時可查詢，例如在線分析；另，多數(shù)單個查詢（如果不是全部的話）只涉及整個數(shù)據(jù)存儲的部分（例如，最近周或最近個，或2016年92016年10之間成的數(shù)據(jù)）。換句話說，計算資源的需求是穩(wěn)定的，存儲資源的需求則在不斷增長。在傳統(tǒng)的共享架構(gòu)下，為了解決這個問題，我們需要對集群進擴展（例如增加更多的worker節(jié)點），因為掛載到彈性計算機上的塊存儲的容量有上限。在這種擴展場景中，新增的計算資源完全是浪費，更不說集群擴展是個容易出錯且耗時的過程。與傳統(tǒng)MPP解決案的剛性相反，HDW的數(shù)據(jù)存儲容量乎是

5、限的。存儲層擴展對于計算層是完全透明的。實際上，從HDW戶的度來看，沒有存儲擴展概念。戶可以繼續(xù)將數(shù)據(jù)導到HDW集群中，并處理標數(shù)據(jù)來持他們的業(yè)務決策。內(nèi)置表如上所述，HDW繼承了Greenplum數(shù)據(jù)庫豐富的數(shù)據(jù)分析功能。其中個驚的功能是通過訪問對象存儲中的原數(shù)據(jù)。雖然外部表有定的特點，但是與外部表相，HDW基于OSS的內(nèi)置表還進步具有以下優(yōu)勢：內(nèi)置表持更新/刪除和索引操作。最重要的是，內(nèi)置表完全持ACID事務。這些特征外部表都不持。內(nèi)置表可以實現(xiàn)更好的數(shù)據(jù)壓縮。前，外部表持三種常見的數(shù)據(jù)格式：TXT、CSV和ORC。根據(jù)我們的觀察，為了簡單起見，與ORC相，客戶通常更喜歡帶有ZIP壓縮算法

6、的TXT/CSV。使內(nèi)置表，我們可以使更復雜的編碼策略（例如字典編碼和變長編碼）和壓縮算法（例如zstd）。內(nèi)置表具有更好的查詢性能。內(nèi)置表的數(shù)據(jù)布局樣式（論是存儲在內(nèi)存中還是在磁盤上），都為HDW的執(zhí)引擎進了度優(yōu)化。使Alluxio加速OSS訪問盡管對象存儲為數(shù)據(jù)系統(tǒng)提供了很多好處，但是與塊存儲相，它具有更低的I/O性能。，雖然隨著對象存儲技術的不斷發(fā)展，前多數(shù)對象存儲服務只能夠為每個HTTP連接提供100MB/s左右的GET吞吐量和40MB/s的PUT吞吐量。當啟多線程GET、多線程上傳和數(shù)據(jù)壓縮時，總體I/O吞吐量可以匹配數(shù)據(jù)庫執(zhí)器的處理吞吐量。另，OSS本不是瓶頸的時候，在個公有云環(huán)境

7、中，HDW集群所在軟件定義絡（SDN）的總帶寬通常存在個上限，這會在HDW集群訪問對象存儲中的數(shù)據(jù)時限制I/O性能。其次，客戶需要為每個OSS HTTP請求付費。第三，HDW持各種索引算法，包括B樹、位圖和GiST?？蛻艨梢岳@些索引算法，通過掃描索引來加速查詢，并在數(shù)萬億元組上實現(xiàn)亞秒級查詢時間。另個查詢場景是查詢低維度表。對于這些情況，OSS的吞吐量雖然不是性能瓶頸，但是其訪問延遲確是個很的瓶頸問題。為了解決上述問題，我們選擇了Alluxio作為智能緩存層來加速I/O性能。Alluxio，原名Tachyon，是世界上第個于云計算分析和智能的數(shù)據(jù)編排技術。它連接了計算框架和存儲系統(tǒng)，使存儲層

8、的數(shù)據(jù)更接近計算框架，允許應程序通過公共接連接到多個存儲系統(tǒng)，使得數(shù)據(jù)更易于訪問。Alluxio的內(nèi)存第的分層架構(gòu)使得它能夠現(xiàn)有解決案快個數(shù)量級的速度訪問數(shù)據(jù)。結(jié)合使HDW和Alluxio，緩存數(shù)據(jù)被平均分區(qū)到每個worker節(jié)點上。每個HDW段都將數(shù)據(jù)緩存到它的本地Alluxio worker中。Alluxio主節(jié)點與HDW主節(jié)點被部署在起。所有戶都是通過Alluxio接操作數(shù)據(jù)。HDW的層存儲架構(gòu)如下圖所。Alluxio在數(shù)據(jù)態(tài)系統(tǒng)中扮演者重要的。它與許多開源數(shù)據(jù)系統(tǒng)共享類似的技術棧，包括基于Java或JVM的輕量級事務模型，這使得Alluxio與它們完美匹配。然，仍然有許多分布式系統(tǒng)采完

9、全不同的構(gòu)建理念。在接下來的部分中，我們將分享在利Alluxio構(gòu)建原云MPP數(shù)據(jù)庫時學到的經(jīng)驗。C/C+原客戶端Alluxio提供種編程語綁定，包括Java、Go和Python，還通過HTTP代理持所有其它語的REST接。雖然開源項通過使JNI調(diào)原Java客戶端能夠提供C/C+ Alluxio接，但是前還沒有官的C/C+原客戶端。為了提系統(tǒng)性能、穩(wěn)定性、靈活性和易維護性，我們決定為Alluxio實現(xiàn)個原C/C+客戶端，不是直接使liballuxio。在HashData中，我們構(gòu)建了個C/C+客戶端liballuxio2，它通過RPC調(diào)來和Alluxio服務器交互。在Alluxio不同組件之間

10、的交互過程是基于thrift/protobuf/netty。liballuxio2作為個原客戶端，采了thrift/protobuf提供的Alluixo統(tǒng)數(shù)據(jù)交換格式。前,liballuxio2持Alluxio-1.5.0版本。統(tǒng)對象存儲SDKAlluxio作為底層件系統(tǒng)（UFS）持各種對象存儲服務，包括S3、Azure Blob Store、GCS等，并提供了個框架，戶可以通過該框架輕松地擴展它來持新的對象存儲。但是，我們采了不同的法，理由如下：1. 不同的對象存儲服務持不同的訪問優(yōu)化策略，以獲得更的讀寫性能，包括多線程上傳和流線下載。構(gòu)建個C/C+原OSS庫是利這些優(yōu)化機會的更好法。2.

11、作為家初創(chuàng)企業(yè)，HashData希望持本地公共云提供商提供的各種對象存儲服務，不僅僅是上述的跨國巨頭。統(tǒng)的C/C+OSS客戶端庫可以減少研發(fā)作，使得開發(fā)員不必擔異構(gòu)對象存儲服務的復雜性。3. Alluxio客戶端可以使委托/委托模式來控制UFS操作的處理位置。在委托模式下，Alluxio C/C+原客戶端負責OSS讀寫操作。Alluxio服務器只需要維護元數(shù)據(jù)和基于緩存I/O流的塊。我們已經(jīng)構(gòu)建了個統(tǒng)C/C+原庫來持本地和全球頂級云平臺的對象存儲服務，并且將它集成到liballuxio2庫中。戶仍然可以選擇委托模式來保留Alluxio服務器執(zhí)的OSS操作。分層存儲Alluxio持分層存儲，以便

12、管理除內(nèi)存以外的其它存儲類型。前，Alluxio持三種存儲類型/層，包括MEM（內(nèi)存）、SDD（固態(tài)驅(qū)動器）和HDD（硬盤驅(qū)動器）。在開始時，我們保持默認的分層設置，例如數(shù)據(jù)先緩存到MEM層，并在上層填滿后遷移到SSD/HDD。但是，當我們開始使量數(shù)據(jù)進壓測試時，如果MEM層中的所有件都是打開的，那么緩存的數(shù)據(jù)就不能被刪除。對于典型的HDW作負載，MEM層的容量（為了節(jié)省成本，我們通常不會為EC機器分配太多內(nèi)存）不以緩存標數(shù)據(jù)。因此，我們將默認的寫層更改為SSD。更關鍵的是，在數(shù)據(jù)超出本地磁盤容量的情況下，HDW數(shù)據(jù)庫內(nèi)核會告訴C/C+原Alluxio客戶端liballuxio2不要緩存哪些運

13、查詢的數(shù)據(jù)。許多復雜的Alluxio讀/寫/緩存策略都是由HDW數(shù)據(jù)庫內(nèi)核動態(tài)決定的。事務提交作為關系數(shù)據(jù)庫管理系統(tǒng)（RDBMS），HDW完全持ACID分布式事務。與許多基于HDFS的數(shù)據(jù)分析系統(tǒng)（原寫是利HDFS原重命名特性實現(xiàn)的）不同的是，HDW對事務的持是建在數(shù)據(jù)庫內(nèi)核的。只有當所有打開供寫的件都成功地持久化在對象存儲上時，事務才成功提交；否則事務將中，并清除所有開放可寫的件（包括數(shù)據(jù)）。為了保證數(shù)據(jù)持久性，所有的Alluxio寫操作都直接寫到對象存儲中，不需要緩存?；鶞蕼y試我們使TPC基準（TPC-H）測試來評估我們的解決案。TPC-H是個決策持基準測試集，由組向業(yè)務的即時查詢和并發(fā)數(shù)

14、據(jù)修改組成。查詢和填充數(shù)據(jù)庫的數(shù)據(jù)具有泛的業(yè)相關性。這個基準測試的的不是顯HDW對TPC-H查詢的運速度有多快，是顯Alluxio提升I/O性能的有效性。因此，在接下來的基準測試中，我們將HDW的執(zhí)引擎設置為與開源Greenplum引擎完全相同，不是私有的。此外，這項評估約是在年前進的，使的是基于Alluxio的HDW的第個穩(wěn)定版本，它具有與Greenplum-5.0版本相同的數(shù)據(jù)庫內(nèi)核版本。配置1. 數(shù)據(jù)集：100GB2. 集群：1個主節(jié)點，8個（計算）節(jié)點3. 主節(jié)點：QingCloud超性能實體，2個CPU，4GB內(nèi)存4. 節(jié)點：QingCloud超性能實體，4個CPU，8GB內(nèi)存5. Alluxio：1.5.0版本，每個作節(jié)點內(nèi)存為2GB場景1. Greenplum 5.0：我們選擇這個版本的開源Greenplum作為基準。2. HashData：HDW讀取的標數(shù)據(jù)是從遠程對象存儲緩存到Alluxio層的。結(jié)果根據(jù)我們的觀察，OSS的I/O吞吐量少本