編者按

在大數(shù)據(jù)火遍IT界之前，大家對數(shù)據(jù)信息的挖掘通常聚焦在BI（Business Intelligence）之上。BI具有著明確的分析需求，清晰地知道需要處理哪些信息，并且如何最終獲得多維度的SQL類型數(shù)據(jù)，這種多維度的分析對應(yīng)的是OLAP處理技術(shù)。在實際商業(yè)分析應(yīng)用中，公司復(fù)雜信息模型、多樣化的分析需求會給數(shù)據(jù)庫帶來極大的技術(shù)挑戰(zhàn)。

對于阿里而言，實現(xiàn)OLAP、進行在線大規(guī)模并行處理，是一個無法規(guī)避的技術(shù)問題。為此，阿里云研發(fā)了HybridDB方案，它基于數(shù)據(jù)庫Greenplum的開源版本，并且吸收PostgreSQL精髓。那么為什么會有HybridDB的誕生？它經(jīng)歷了怎樣的研發(fā)歷程？它的應(yīng)用場景和情況是怎樣的？帶著這些問題，InfoQ對阿里云的數(shù)據(jù)庫專家兼Postgres中國社區(qū)/中國用戶會主席蕭少聰先生進行了采訪，以下文字整理自采訪文稿。

先來講講OLTP和OLAP

數(shù)據(jù)庫領(lǐng)域中大家經(jīng)常會看到兩個詞：OLTP及OLAP。

舉例說明，比如進行一次交易，資金從A帳戶轉(zhuǎn)帳到B帳戶，這整個過程就是一次交易事務(wù)。如果過程中有任何系統(tǒng)錯誤，交易會回滾A帳戶中的金額都回恢到操作前的狀態(tài)，這就是On-Line Transaction Processing聯(lián)機事務(wù)處理過程(OLTP)的操作。在OLTP場景中用戶并發(fā)操作量會很大，要求系統(tǒng)實時進行數(shù)據(jù)操作的響應(yīng)，在查詢時往往也是只會檢索一條或幾條明確的目標(biāo)數(shù)據(jù)，以實現(xiàn)用戶的業(yè)務(wù)交互。

OLAP意思是On-Line Analytical Processing聯(lián)機分析處理，顧名思義就是主要針對于數(shù)據(jù)的分析匯總操作。如我們的業(yè)務(wù)系統(tǒng)中每天都需要出銷售日報，這個操作需要對當(dāng)天所有數(shù)據(jù)進行匯總，并需要進行計算，以得到全天收入、產(chǎn)品銷售排名、分時段的銷售量，甚至與過去30天及去年當(dāng)天進行對比，這樣的操作都屬于OLAP。

業(yè)界早期使用數(shù)據(jù)時，尤其是OLTP場景下，通常選擇非分布式的關(guān)系型數(shù)據(jù)庫，如MySQL、SQLServer、Oracle、PostgreSQL即可滿足大部份的需求。

OLAP中主流數(shù)據(jù)庫遭遇瓶頸

從技術(shù)角度而言，OLAP場景，不僅涉及的數(shù)據(jù)量大而且要求分析的結(jié)果實時返回，對應(yīng)的SQL查詢十分復(fù)雜。如何做到技術(shù)性能和業(yè)務(wù)功能權(quán)衡，對于數(shù)據(jù)庫而言是一個重大考驗。

已有的兩個主流開源數(shù)據(jù)庫，MySQL和PostgreSQL都是針對OLTP環(huán)境的，在OLAP在線分析需求下它們的性能明顯不足。特別是MySQL在大規(guī)模分析操作時多表Join的性能是當(dāng)前互聯(lián)網(wǎng)用戶的一大痛點。

在OLAP發(fā)展的早期，其操作并沒有專門的數(shù)據(jù)庫支撐，直接就與OLTP業(yè)務(wù)放在同一個數(shù)據(jù)庫中完成。但隨著業(yè)務(wù)量的增加，OLAP每次要分析的數(shù)據(jù)量越來越大，這樣的分析操作執(zhí)行時就會導(dǎo)致數(shù)據(jù)庫的業(yè)務(wù)交易下降。因此業(yè)界開始將OLTP、OLAP拆分成兩套不同的數(shù)據(jù)庫進行處理，OLTP數(shù)據(jù)庫中的數(shù)據(jù)通過ETL軟件持續(xù)或定期抽取到OLAP數(shù)據(jù)庫，讓業(yè)務(wù)交易與報表分析進行分離。

而新的問題很快又到來了，聯(lián)互網(wǎng)爆發(fā)后數(shù)據(jù)量也激增，OLTP的業(yè)務(wù)庫可以保存比較少的數(shù)據(jù)量如3個月到半年，但OLAP的數(shù)據(jù)量將可能要保存幾年甚至更多。單臺服務(wù)服務(wù)的性能上限已經(jīng)無法滿足OLAP分析數(shù)據(jù)持續(xù)增加所帶來的壓力，因此催生出如阿里HybridDB這樣的大規(guī)模并行處理（Massive Parallel Processing，MPP）分布式OLAP數(shù)據(jù)庫。

新的分布式OLAP數(shù)據(jù)庫

在提供HybridDB方案之前，我們會給用戶提供如分庫分表等處理方案，但這樣的方案對于SQL查詢內(nèi)容不確定的OLAP業(yè)務(wù)并不友好。當(dāng)用戶需要進行多個數(shù)據(jù)表的組合操作時，由于數(shù)據(jù)需要跨服務(wù)器進行大規(guī)模的聚合，性能十分低下。這個問題在HybridDB中也同樣會出現(xiàn)，所幸的是，Greenplum Database開源項目中借助平行的數(shù)據(jù)擴展技術(shù)及interconnect的專用協(xié)議，通過自定義的網(wǎng)絡(luò)協(xié)議有效地解決了網(wǎng)絡(luò)瓶頸的問題。這也是我們選擇基于Greenplum Database開源項目的原因之一。

簡單來說，MPP是一種平衡的性能擴張模型。以HybridDB的模型為列，每個節(jié)點可存放的數(shù)據(jù)量及計算能力為1Core / 8GB Mem / 80GB SSD（即將開放500GB HDD版本），如果用戶80GB以內(nèi)的數(shù)據(jù)在這樣的計算單元中，可以在毫秒內(nèi)查詢出結(jié)果，那將數(shù)據(jù)計算能力及容量平衡擴展到上百TB甚至PB時，用戶查詢“等比”數(shù)據(jù)量時依然可以達到毫秒級別。

MPP分布式OLAP數(shù)據(jù)庫系統(tǒng)架構(gòu)已經(jīng)發(fā)展了有10多年之久，十分成熟，當(dāng)前使用這類系統(tǒng)的企業(yè)都是中大型公司。OLAP是一個很大的市場，有別于如同EMR(Hadoop)的大數(shù)據(jù)分析市場，它要求海量數(shù)據(jù)的SQL查詢在幾分鐘、幾秒，甚至毫秒級返回結(jié)果，因此對于服務(wù)器、網(wǎng)絡(luò)及數(shù)據(jù)庫軟件本身的架構(gòu)都提出了很高的要求。

技術(shù)攻堅之路

阿里一直都在使用并研究OLAP，實際上在2009年左右開始使用Greenplum，如果沒有記錯，那個時候的規(guī)模應(yīng)該是國內(nèi)甚至全亞洲最大的GPDB集群。

研發(fā)之路并不是一帆風(fēng)順，甚至一度突圍失敗。一方面，彼時Greenplum還處在萌芽期，只發(fā)布了4年。另一方面，Greenplum沒有開源，既無法掌握更為深入的資料，又不得不考慮價格因素。你可以想象阿里所在行業(yè)對于數(shù)據(jù)可靠性的要求以及規(guī)模量，使得對于數(shù)據(jù)庫的選擇會有多個維度的考慮。

不過早期的經(jīng)歷還是給我們留下了寶貴的經(jīng)驗。當(dāng)年的很多運維經(jīng)驗我們都進行了收集，并在現(xiàn)有平臺中變成了我們的監(jiān)控項，通過自動化運維的手段進行資源調(diào)配及故障預(yù)警，這對我們平臺的穩(wěn)定性提供了很重要的經(jīng)驗。同時針對以前遇到的很多讓我們技術(shù)同學(xué)不理解的原理性問題，通過Greenplum Database的源代碼我們進行了重點分析，并找到了問題的答案。有很多之前遇到過的問題，通過源碼可以明確發(fā)現(xiàn)已經(jīng)由廠商進行了修復(fù)，而有一些問題可能與我們的業(yè)務(wù)場景有關(guān)，結(jié)合源碼我們也進行了內(nèi)核的優(yōu)化。

2015年10月Greenplum Database由Pivotal開源后，阿里云PostgreSQL內(nèi)核團隊便開始進行深度的調(diào)研，于2016年開始進行產(chǎn)品的研發(fā)工作，到今年7月份我們對用戶開放了公測邀請并準(zhǔn)備正式商業(yè)化的工作。

為什么選擇基于Greenplum？主要有三點考慮：

揭秘HybridDB方案

HybridDB基于開源Greenplum Database(內(nèi)核實際上就是PostgreSQL)項目的MPP分布式數(shù)據(jù)倉庫，與PostgreSQL不同，HybridDB可以實現(xiàn)橫向擴展，提供用戶需要的百GB到百TB的高性能分析能力。

接下來結(jié)合項目說明實際應(yīng)用。

我們有一個廣告行業(yè)的用戶，他們給用戶提供線上的數(shù)據(jù)分析業(yè)務(wù)，同時也會將他們的產(chǎn)品進行線下私有環(huán)境的軟件售賣。每天他們都需要進行過億數(shù)據(jù)的匯總分析，增量數(shù)據(jù)也都在千萬級別，當(dāng)前通過使用HybridDB進行他們線上業(yè)務(wù)的支持。一些單表的查詢在毫秒級別就可以輸出結(jié)果，而很多需要多表Join的復(fù)雜查詢也在數(shù)秒內(nèi)就會有結(jié)果返回。同時這個用戶給 HybridDB 提出 HyperLogLog 的功能需求后，我們在2周內(nèi)就給予了這個功能的支持，使得用戶在進行數(shù)據(jù)預(yù)估分析的操作性能提高幾十倍。與此同時用戶線上使用 HybridDB 開發(fā)的產(chǎn)品，也可以十分便捷地運行在線下的開源或商業(yè)版本的 Greenplum 上，避免了在不同數(shù)據(jù)庫平臺上需要重新開發(fā)應(yīng)用系統(tǒng)的工作量。

在阿里云官網(wǎng)上，HybridDB 歸結(jié)在 “數(shù)據(jù)庫” 和 “分析” 兩個類目。阿里內(nèi)部已經(jīng)有業(yè)務(wù)開始使用 HybridDB ，主要是看重它對SQL的豐富支持，同時可以支持GIS數(shù)據(jù)類型及基于事務(wù)一致性的存儲過程。

　　HybridDB最大的三個特色：

支持多種混合數(shù)據(jù)類型（多達23種）的SQL統(tǒng)一查詢，包括：

傳統(tǒng)數(shù)據(jù)類型：字符、數(shù)字、浮點、日期等；

非結(jié)構(gòu)化數(shù)據(jù)：JSON、XML；

特殊功能數(shù)據(jù)類型：GIS地理信息數(shù)據(jù)、IPv4/v6網(wǎng)絡(luò)數(shù)據(jù)、HyperLogLog預(yù)估分析數(shù)據(jù)。

那么，HybridDB在OLAP讀取中都做了哪些優(yōu)化？

優(yōu)化方面從引擎底層我們針對阿里云的硬件及網(wǎng)絡(luò)特點，進行的源碼級別的深度優(yōu)化，特別是在網(wǎng)絡(luò)調(diào)度上進行了針對性的處理，提高跨網(wǎng)絡(luò)數(shù)據(jù)節(jié)點的吞吐能力。同時在用戶業(yè)務(wù)層中對特殊數(shù)據(jù)類型進行擴展，如果物聯(lián)網(wǎng)中的JSON數(shù)據(jù)類型是Greenplum Database所不支持的，HybridDB通過直接支持這一數(shù)據(jù)類型，避免用戶自行進行非結(jié)果化的解析，同時提供基于函數(shù)的JSON屬性級索引，提高數(shù)據(jù)庫處理JSON的檢索性能。

除此之外，HybridDB還有哪些新意？

HybridDB是云上的數(shù)據(jù)倉庫，用戶如果在自己的私有環(huán)境中進行類似架構(gòu)的部署，將需要富有經(jīng)驗的架構(gòu)師進行完整的規(guī)劃，同時還要聘用高水平的技術(shù)團隊進行持續(xù)管理。因為如果系統(tǒng)出現(xiàn)故障無法提供服務(wù)，將很可能影響到企業(yè)的決策分析，對于以數(shù)據(jù)分析的基礎(chǔ)的企業(yè)甚至?xí)?dǎo)致業(yè)務(wù)中斷，通過使用云數(shù)據(jù)庫HybridDB將免除這些煩惱。

將MySQL和PostgreSQL數(shù)據(jù)導(dǎo)入到HybridDB的這個流程實際上并沒有很深的數(shù)據(jù)難度，因為MySQL和PostgreSQL都支持基于的邏輯日志，我們只需要進行解析并入庫就可以了。在數(shù)據(jù)導(dǎo)入方面，我們借助OSS分布式數(shù)據(jù)存儲的能力，實現(xiàn)了多計算節(jié)點的并行導(dǎo)入，每個計算單元（1Core/8GBMem為一個計算單元）可以達到接近20MB/s的數(shù)據(jù)導(dǎo)入，如果用戶構(gòu)建出一個64節(jié)點的 HybridDB 集群將可以達到1GB/s的數(shù)據(jù)導(dǎo)入能力。在我們的實際用戶使用中，已經(jīng)有用戶通過這個方法在4分鐘內(nèi)導(dǎo)入了4億條數(shù)據(jù)。

另一方面HybridDB還支持將數(shù)據(jù)存放到OSS云存儲，實現(xiàn)廉價的數(shù)據(jù)存儲方案，為用戶節(jié)省更多成本。

數(shù)據(jù)存儲

1、本地存儲

HybridDB的本地存儲分為行儲存和列存儲兩種方式。行存儲和列存儲各有長處。行存適合于近線數(shù)據(jù)的分析，特別是要求查詢結(jié)果返回表中某幾跳符合條件記錄的所有字段的情況。列存適合用于數(shù)據(jù)的統(tǒng)計分析。

那么兩者的適用情況是怎樣的呢？舉例說明：在行存的情況下，如果一個用于存放用戶的表中有20個字段，但我們只要統(tǒng)計用戶年齡的平均值，這時數(shù)據(jù)庫要對用戶表進行全表掃描，遍歷所有行的所有數(shù)據(jù)；但如果使用列存，數(shù)據(jù)庫只要定位到這一列，然后只掃描這一列的數(shù)據(jù)就可以得到所有的結(jié)果，性能上相比列存理論上就會直接快20倍，加上HybridDB將數(shù)據(jù)分布式存儲到多個計算節(jié)點，性能將再次提高幾倍，達到100倍性能提升是十分常見。

HybridDB是混合兩者搭配使用的。用戶可以配搭進行使用，定義不同的表使用不同的存儲方式，讓用戶適應(yīng)不同的業(yè)務(wù)場景，并進行數(shù)據(jù)生態(tài)周期的管理。如6個月內(nèi)的數(shù)據(jù)可能要經(jīng)常獲取全行數(shù)據(jù)，因此使用行存儲，6個月后的數(shù)據(jù)通過列存儲進行保存提高分析匯總操作的查詢性能。

2、外部存儲

高性能的數(shù)據(jù)分析是在本地存儲完成的。OSS作為外部存儲，HybridDB可以將OSS中的CSV格式化文本作為外部表進行數(shù)據(jù)查詢，同時還可以對這些外部表進行寫入操作。寫入到OSS的數(shù)據(jù)可以提供給RDS for PostgreSQL或EMR等云數(shù)據(jù)庫服務(wù)進行讀取及處理，因此也同時實現(xiàn)了數(shù)據(jù)的無縫打通。

同時我們也將支持“存儲計算分析”的模型，在這樣模型上我們平時甚至可以只通過OSS進行數(shù)據(jù)的存儲，當(dāng)需要進行計算時再開啟足夠的計算節(jié)點進行數(shù)據(jù)分析處理，計算處理結(jié)束后關(guān)閉計算節(jié)點資源以節(jié)省使用成本。

　　HybridDB的幕后故事

1、扎根社區(qū)

當(dāng)前我們基于開源版本的Greenplum Database，同時我們也會進行一些功能的添加及性能穩(wěn)定性上的優(yōu)化工作，我們也會逐步進行對開源社區(qū)的更多的貢獻，如當(dāng)前我們就已經(jīng)開源了支持Greenplum、PostgreSQL及HybridDB的數(shù)據(jù)同步工具dbsync(https://github.com/aliyun/rds_dbsync)，有興趣的讀者可以下載測試及使用。

在Greenplum Database的開源社區(qū)我們會有很多的合作，甚至我們已經(jīng)在向開源社區(qū)提交新功能及patch。同時Greenplum也是PostgreSQL開源數(shù)據(jù)庫生態(tài)重要的力量，我個人同時作為PostgreSQL中國社區(qū)及用戶會的主席也當(dāng)然會進行更多線上線下活動的支持。

2、商業(yè)合作

Greenplum背后的公司是Pivotal。所以同時也與Pivotal有更多的商業(yè)合作。阿里也會與Pivotal方面進行持續(xù)的接觸，相信我們會有機會碰出絢麗的火花。

寫在最后

長期以來國外開源社區(qū)都認(rèn)為中國用戶僅僅使用開源軟件，但是貢獻甚少。不過，隨著阿里的發(fā)展，我們已經(jīng)開始反哺開源社區(qū)并共同建立生態(tài)。幾個月前，AliSQL的開源說明了阿里對開源業(yè)界的支持。HybridDB同樣如此，雖然我們的版本才剛剛發(fā)布，但在版本研發(fā)的過程中已經(jīng)開始向社區(qū)共享代碼。

阿里云當(dāng)前支持云數(shù)據(jù)庫HybridDB，暫時沒有計劃去支持私有環(huán)境的Greenplum數(shù)據(jù)庫。不過我們團隊的大神德哥，會繼續(xù)貢獻他在使用Greenplum的經(jīng)驗心得。希望對大家有所幫助。

用戶在線下可以使用Greenplum的開源數(shù)據(jù)庫版本或商業(yè)版本，據(jù)我所了解也已經(jīng)有很多數(shù)據(jù)庫服務(wù)商開始提供Greenplum的技術(shù)支持，使用這個數(shù)據(jù)庫的用戶不需要再擔(dān)心未來上云遷移的問題。同時，我們也會在未來結(jié)合PostgreSQL及HybridDB提供一系列的使用教學(xué)視頻，讓用戶更快速地掌握產(chǎn)品的正確使用場景及方法。

作者簡介

蕭少聰，Postgres中國社區(qū)/中國用戶會主席，阿里云計算有限公司 ApsaraDB云數(shù)據(jù)庫產(chǎn)品專家。紅帽認(rèn)證RHCA架構(gòu)師/EDB認(rèn)證PostgreSQL數(shù)據(jù)庫專家，參與的著作有《Linux系統(tǒng)案例精解》、《深入理解大數(shù)據(jù)》。在阿里主要負(fù)責(zé)PostgreSQL數(shù)據(jù)庫產(chǎn)品線。擁有多年開發(fā)、架構(gòu)設(shè)計及項目管理經(jīng)驗，專注于開源Linux系統(tǒng)管理及Postgres數(shù)據(jù)庫、優(yōu)化、集群系統(tǒng)、云架構(gòu)設(shè)計。