http://www.infoq.com/cn/news/2016/12/MySQL-PostgreSQL-Greenplumgit
編者按github
在大數據火遍IT界以前,你們對數據信息的挖掘一般聚焦在BI(Business Intelligence)之上。BI具備着明確的分析需求,清晰地知道須要處理哪些信息,而且如何最終得到多維度的SQL類型數據,這種多維度的分析對應的是OLAP處理技術。在實際商業分析應用中,公司複雜信息模型、多樣化的分析需求會給數據庫帶來極大的技術挑戰。數據庫
對於阿里而言,實現OLAP、進行在線大規模並行處理,是一個沒法規避的技術問題。爲此,阿里雲研發了HybridDB方案,它基於數據庫Greenplum的開源版本,而且吸取PostgreSQL精髓。那麼爲何會有HybridDB的誕生?它經歷了怎樣的研發歷程?它的應用場景和狀況是怎樣的?帶着這些問題,InfoQ對阿里雲的數據庫專家兼Postgres中國社區/中國用戶會主席蕭少聰先生進行了採訪,如下文字整理自採訪文稿。編程
先來說講OLTP和OLAP服務器
數據庫領域中你們常常會看到兩個詞:OLTP及OLAP。網絡
舉例說明,好比進行一次交易,資金從A賬戶轉賬到B賬戶,這整個過程就是一次交易事務。若是過程當中有任何系統錯誤,交易會回滾A賬戶中的金額都回恢到操做前的狀態,這就是On-Line Transaction Processing聯機事務處理過程(OLTP)的操做。在OLTP場景中用戶併發操做量會很大,要求系統實時進行數據操做的響應,在查詢時每每也是隻會檢索一條或幾條明確的目標數據,以實現用戶的業務交互。架構
OLAP意思是On-Line Analytical Processing聯機分析處理,顧名思義就是主要針對於數據的分析彙總操做。如咱們的業務系統中天天都須要出銷售日報,這個操做須要對當天全部數據進行彙總,並須要進行計算,以獲得全天收入、產品銷售排名、分時段的銷售量,甚至與過去30天及去年當天進行對比,這樣的操做都屬於OLAP。併發
業界早期使用數據時,尤爲是OLTP場景下,一般選擇非分佈式的關係型數據庫,如MySQL、SQLServer、Oracle、PostgreSQL便可知足大部份的需求。運維
OLAP中主流數據庫遭遇瓶頸分佈式
從技術角度而言,OLAP場景,不只涉及的數據量大並且要求分析的結果實時返回,對應的SQL查詢十分複雜。如何作到技術性能和業務功能權衡,對於數據庫而言是一個重大考驗。
已有的兩個主流開源數據庫,MySQL和PostgreSQL都是針對OLTP環境的,在OLAP在線分析需求下它們的性能明顯不足。特別是MySQL在大規模分析操做時多表Join的性能是當前互聯網用戶的一大痛點。
在OLAP發展的早期,其操做並無專門的數據庫支撐,直接就與OLTP業務放在同一個數據庫中完成。但隨着業務量的增長,OLAP每次要分析的數據量愈來愈大,這樣的分析操做執行時就會致使數據庫的業務交易降低。所以業界開始將OLTP、OLAP拆分紅兩套不一樣的數據庫進行處理,OLTP數據庫中的數據經過ETL軟件持續或按期抽取到OLAP數據庫,讓業務交易與報表分析進行分離。
而新的問題很快又到來了,聯互網爆發後數據量也激增,OLTP的業務庫能夠保存比較少的數據量如3個月到半年,但OLAP的數據量將可能要保存幾年甚至更多。單臺服務服務的性能上限已經沒法知足OLAP分析數據持續增長所帶來的壓力,所以催生出如阿里HybridDB這樣的大規模並行處理(Massive Parallel Processing,MPP)分佈式OLAP數據庫。
新的分佈式OLAP數據庫
在提供HybridDB方案以前,咱們會給用戶提供如分庫分表等處理方案,但這樣的方案對於SQL查詢內容不肯定的OLAP業務並不友好。當用戶須要進行多個數據表的組合操做時,因爲數據須要跨服務器進行大規模的聚合,性能十分低下。這個問題在HybridDB中也一樣會出現,所幸的是,Greenplum Database開源項目中藉助平行的數據擴展技術及interconnect的專用協議,經過自定義的網絡協議有效地解決了網絡瓶頸的問題。這也是咱們選擇基於Greenplum Database開源項目的緣由之一。
簡單來講,MPP是一種平衡的性能擴張模型。以HybridDB的模型爲列,每一個節點可存放的數據量及計算能力爲1Core / 8GB Mem / 80GB SSD(即將開放500GB HDD版本),若是用戶80GB之內的數據在這樣的計算單元中,能夠在毫秒內查詢出結果,那將數據計算能力及容量平衡擴展到上百TB甚至PB時,用戶查詢「等比」數據量時依然能夠達到毫秒級別。
MPP分佈式OLAP數據庫系統架構已經發展了有10多年之久,十分紅熟,當前使用這類系統的企業都是中大型公司。OLAP是一個很大的市場,有別於如同EMR(Hadoop)的大數據分析市場,它要求海量數據的SQL查詢在幾分鐘、幾秒,甚至毫秒級返回結果,所以對於服務器、網絡及數據庫軟件自己的架構都提出了很高的要求。
技術攻堅之路
阿里一直都在使用並研究OLAP,實際上在2009年左右開始使用Greenplum,若是沒有記錯,那個時候的規模應該是國內甚至全亞洲最大的GPDB集羣。
研發之路並非一路順風,甚至一度突圍失敗。一方面,彼時Greenplum還處在萌芽期,只發布了4年。另外一方面,Greenplum沒有開源,既沒法掌握更爲深刻的資料,又不得不考慮價格因素。你能夠想象阿里所在行業對於數據可靠性的要求以及規模量,使得對於數據庫的選擇會有多個維度的考慮。
不過早期的經歷仍是給咱們留下了寶貴的經驗。當年的不少運維經驗咱們都進行了收集,並在現有平臺中變成了咱們的監控項,經過自動化運維的手段進行資源調配及故障預警,這對咱們平臺的穩定性提供了很重要的經驗。同時針對之前遇到的不少讓咱們技術同窗不理解的原理性問題,經過Greenplum Database的源代碼咱們進行了重點分析,並找到了問題的答案。有不少以前遇到過的問題,經過源碼能夠明確發現已經由廠商進行了修復,而有一些問題可能與咱們的業務場景有關,結合源碼咱們也進行了內核的優化。
2015年10月Greenplum Database由Pivotal開源後,阿里雲PostgreSQL內核團隊便開始進行深度的調研,於2016年開始進行產品的研發工做,到今年7月份咱們對用戶開放了公測邀請並準備正式商業化的工做。
爲何選擇基於Greenplum?主要有三點考慮:
揭祕HybridDB方案
HybridDB基於開源Greenplum Database(內核實際上就是PostgreSQL)項目的MPP分佈式數據倉庫,與PostgreSQL不一樣,HybridDB能夠實現橫向擴展,提供用戶須要的百GB到百TB的高性能分析能力。
接下來結合項目說明實際應用。
咱們有一個廣告行業的用戶,他們給用戶提供線上的數據分析業務,同時也會將他們的產品進行線下私有環境的軟件售賣。天天他們都須要進行過億數據的彙總分析,增量數據也都在千萬級別,當前經過使用HybridDB進行他們線上業務的支持。一些單表的查詢在毫秒級別就能夠輸出結果,而不少須要多表Join的複雜查詢也在數秒內就會有結果返回。同時這個用戶給 HybridDB 提出 HyperLogLog 的功能需求後,咱們在2周內就給予了這個功能的支持,使得用戶在進行數據預估分析的操做性能提升幾十倍。與此同時用戶線上使用 HybridDB 開發的產品,也能夠十分便捷地運行在線下的開源或商業版本的 Greenplum 上,避免了在不一樣數據庫平臺上須要從新開發應用系統的工做量。
在阿里雲官網上,HybridDB 歸結在 「數據庫」 和 「分析」 兩個類目。阿里內部已經有業務開始使用 HybridDB ,主要是看重它對SQL的豐富支持,同時能夠支持GIS數據類型及基於事務一致性的存儲過程。
HybridDB最大的三個特點:
支持多種混合數據類型(多達23種)的SQL統一查詢,包括:
傳統數據類型:字符、數字、浮點、日期等;
非結構化數據:JSON、XML;
特殊功能數據類型:GIS地理信息數據、IPv4/v6網絡數據、HyperLogLog預估分析數據。
那麼,HybridDB在OLAP讀取中都作了哪些優化?
優化方面從引擎底層咱們針對阿里雲的硬件及網絡特色,進行的源碼級別的深度優化,特別是在網絡調度上進行了針對性的處理,提升跨網絡數據節點的吞吐能力。同時在用戶業務層中對特殊數據類型進行擴展,若是物聯網中的JSON數據類型是Greenplum Database所不支持的,HybridDB經過直接支持這一數據類型,避免用戶自行進行非結果化的解析,同時提供基於函數的JSON屬性級索引,提升數據庫處理JSON的檢索性能。
除此以外,HybridDB還有哪些新意?
HybridDB是雲上的數據倉庫,用戶若是在本身的私有環境中進行相似架構的部署,將須要富有經驗的架構師進行完整的規劃,同時還要聘用高水平的技術團隊進行持續管理。由於若是系統出現故障沒法提供服務,將極可能影響到企業的決策分析,對於以數據分析的基礎的企業甚至會致使業務中斷,經過使用雲數據庫HybridDB將免除這些煩惱。
將MySQL和PostgreSQL數據導入到HybridDB的這個流程實際上並無很深的數據難度,由於MySQL和PostgreSQL都支持基於的邏輯日誌,咱們只須要進行解析併入庫就能夠了。在數據導入方面,咱們藉助OSS分佈式數據存儲的能力,實現了多計算節點的並行導入,每一個計算單元(1Core/8GBMem爲一個計算單元)能夠達到接近20MB/s的數據導入,若是用戶構建出一個64節點的 HybridDB 集羣將能夠達到1GB/s的數據導入能力。在咱們的實際用戶使用中,已經有用戶經過這個方法在4分鐘內導入了4億條數據。
另外一方面HybridDB還支持將數據存放到OSS雲存儲,實現廉價的數據存儲方案,爲用戶節省更多成本。
數據存儲
一、本地存儲
HybridDB的本地存儲分爲行儲存和列存儲兩種方式。行存儲和列存儲各有長處。行存適合於近線數據的分析,特別是要求查詢結果返回表中某幾跳符合條件記錄的全部字段的狀況。列存適合用於數據的統計分析。
那麼二者的適用狀況是怎樣的呢?舉例說明:在行存的狀況下,若是一個用於存放用戶的表中有20個字段,但咱們只要統計用戶年齡的平均值,這時數據庫要對用戶表進行全表掃描,遍歷全部行的全部數據;但若是使用列存,數據庫只要定位到這一列,而後只掃描這一列的數據就能夠獲得全部的結果,性能上相比列存理論上就會直接快20倍,加上HybridDB將數據分佈式存儲到多個計算節點,性能將再次提升幾倍,達到100倍性能提高是十分常見。
HybridDB是混合二者搭配使用的。用戶能夠配搭進行使用,定義不一樣的表使用不一樣的存儲方式,讓用戶適應不一樣的業務場景,並進行數據生態週期的管理。如6個月內的數據可能要常常獲取全行數據,所以使用行存儲,6個月後的數據經過列存儲進行保存提升分析彙總操做的查詢性能。
二、外部存儲
高性能的數據分析是在本地存儲完成的。OSS做爲外部存儲,HybridDB能夠將OSS中的CSV格式化文本做爲外部表進行數據查詢,同時還能夠對這些外部表進行寫入操做。寫入到OSS的數據能夠提供給RDS for PostgreSQL或EMR等雲數據庫服務進行讀取及處理,所以也同時實現了數據的無縫打通。
同時咱們也將支持「存儲計算分析」的模型,在這樣模型上咱們平時甚至能夠只經過OSS進行數據的存儲,當須要進行計算時再開啓足夠的計算節點進行數據分析處理,計算處理結束後關閉計算節點資源以節省使用成本。
HybridDB的幕後故事
一、紮根社區
當前咱們基於開源版本的Greenplum Database,同時咱們也會進行一些功能的添加及性能穩定性上的優化工做,咱們也會逐步進行對開源社區的更多的貢獻,如當前咱們就已經開源了支持Greenplum、PostgreSQL及HybridDB的數據同步工具dbsync(https://github.com/aliyun/rds_dbsync),有興趣的讀者能夠下載測試及使用。
在Greenplum Database的開源社區咱們會有不少的合做,甚至咱們已經在向開源社區提交新功能及patch。同時Greenplum也是PostgreSQL開源數據庫生態重要的力量,我我的同時做爲PostgreSQL中國社區及用戶會的主席也固然會進行更多線上線下活動的支持。
二、商業合做
Greenplum背後的公司是Pivotal。因此同時也與Pivotal有更多的商業合做。阿里也會與Pivotal方面進行持續的接觸,相信咱們會有機會碰出絢麗的火花。
寫在最後
長期以來國外開源社區都認爲中國用戶僅僅使用開源軟件,可是貢獻甚少。不過,隨着阿里的發展,咱們已經開始反哺開源社區並共同創建生態。幾個月前,AliSQL的開源說明了阿里對開源業界的支持。HybridDB一樣如此,雖然咱們的版本纔剛剛發佈,但在版本研發的過程當中已經開始向社區共享代碼。
阿里雲當前支持雲數據庫HybridDB,暫時沒有計劃去支持私有環境的Greenplum數據庫。不過咱們團隊的大神德哥,會繼續貢獻他在使用Greenplum的經驗心得。但願對你們有所幫助。
用戶在線下可使用Greenplum的開源數據庫版本或商業版本,據我所瞭解也已經有不少數據庫服務商開始提供Greenplum的技術支持,使用這個數據庫的用戶不須要再擔憂將來上雲遷移的問題。同時,咱們也會在將來結合PostgreSQL及HybridDB提供一系列的使用教學視頻,讓用戶更快速地掌握產品的正確使用場景及方法。