本文由阿裡雲開發者社群直播整理而來。
講師介紹：
姚延棟，pivotal中國研發中心副總經理，Greenplum中文社群發起人。
今天和大家分享的标題是《新一代PB級分布式HTAP資料庫》，我加了個副标題為：Greenplum能做什麼？過去，我們做的分享大多是從産品的角度，分享Greenplum有哪些特性。後來接到一些回報，很多聽衆都表示在聽到這些特性後，更希望知道将這些特性綜合起來可以對業務有哪些支撐。是以今天重點和大家分享Greenplum能做什麼，并引出背後需要什麼樣的技術支撐。
Greenplum是個關系型資料庫，支援完善的ACID，HTAP是這幾年比較流行的方向，是指Transaction和Analytics混合處理在一個系統裡。分布式是指一個叢集有很多節點，每個節點處理一部分的任務，進而實作速度更快更高可用的處理。PB級是指Greenplum可支援的資料量，我們已經有大量的客戶在生産叢集裡使用Greenplum支援PB級資料量。
在标題中，我使用了“新一代”的字樣。有人也許會提出疑問，Greenplum是MPP架構，這個架構從80年代就有人研究，為什麼會用新一代來形容。其實MPP隻是Greenplum的骨架特點之一，經過多年的發展，Greenplum加入很多的新技術， 可以處理HTAP場景，具有結構化資料、半結構化資料、Text、GIS的支援能力，可以實作資料庫内嵌的機器學習能力。
可以和大家交流一個關于列存（Column Storage）的故事：大資料處理使得列存非常流行，但是大家知道不知道誰最早做的列存？
實際上世界上第一款關系型資料庫 SystemR（上世紀70年代初開發）第一版本實作時，資料存儲就是現在我們說的列存。第一版做完後，總結了設計的一些缺陷，其中包括使用列存。如今列存成為了用來解決大資料的主流技術。很多時候，創新都會用一個已經被發明的老技術來解決新時代的問題。
數倉、OLAP、即席分析。這三個詞很多時候指的是一回事。細扣的話各自也有不同的側重。 1)數倉是一種資料庫類型，用來做BI和複雜查詢處理， 強調的是來自各種資料源的曆史資料的分析，産生商業智能（BI）。
2)OLAP是一組操作，例如pivot/slice/dice/drilling/cube 等。強調的是處理。
3)即席分析：強調的是查詢時ad-hoc的，不是預先設計好的 SQL 查詢，強調需求和解決問題的動态性，不是靜态需求 。
數倉、OLAP、即席分析，這三個詞有各自的側重點，但總體上都是指資料分析。一半以上Greenplum客戶在這種場景下使用Greenplum，解決的是數倉問題、線上分析問題和即席查詢問題。這個場景也是Greenplum創始團隊2004年前後創業時主攻的市場。經過15年的研發和打磨，Greenplum在該領域具備了極大的優勢，在全球範圍内有良好的口碑。
口碑和優勢并不是靠我們“王婆賣瓜自賣自誇”，而是來源于客戶對産品的信賴和支援。這是 Gartner 2019年釋出的報告。我們可以看到 Greenplum 在經典數倉領域排名第三，前兩名是Teradata和Oracle，他們都經過長達40多年的發展，相比之下，Greenplum還處于青少年時期，發展更為快速。 此外在實時數倉領域，并列排名第4。取得這樣的認可，需要很多方面的因素，除了技術，還有服務、支援、品牌等。但技術肯定是重要一環。接下來，我們來看看，從技術上，Greenplum是如何來解決數倉和 OLAP 問題的。
首先，我們來看一下 Greenplum 的核心架構。上圖是一張典型的部署拓撲圖。上面是Master，下面都是Segment，Master和Segment之間通過網絡進行高效通訊，我們稱為Interconnect。
1)Master：存儲使用者中繼資料，負責對整個叢集的排程、監控和管理控制。
2)Segment：存儲使用者資料，執行master配置設定的任務。
3)Interconnect：實作資料在各個節點間的傳輸。
整個架構可以做到線性拓展，這裡我們看到 Greenplum 的核心架構特色：MPP shared nothing。MPP 是大規模并行處理，shared nothing是無共享。
在這種架構下，資料要如何存儲呢。在 Greenplum 這種分布式資料庫中，資料根據各種政策分布到不同節點上。Greenplum提供了多種分布政策，包括哈希、随機、6.0也提供了複制表的技術。不管是哪種技術，最重要的政策和目标是做到資料的均勻分布。
DBA或者開發人員要選擇合适的分布鍵，使得每個節點分布1/n資料，避免出現短闆效應，如果找不到一個合适的分布鍵，也可以考慮使用随機分布。
這樣可以做到兩重加速：
1.每個節點隻有 1/n 資料，速度快。
2.N 個節點并行處理，速度快。
資料均勻分布考慮的是不同節點之間資料分布的問題。因為在每個節點上，Greenplum還支援分區技術，并支援多級分區。通過多級分區，可以将資料進一步在每個segment分開，底層會使用不同的檔案儲存不同的分區。核心目的還是盡量降低每次SQL處理要掃描的資料量。上圖的例子中的查詢，如果我們是按月做的分區，就可以隻讀2007年10月的資料，而不需要關心其他月份的資料。這樣的話，磁盤IO會大幅降低，處理速度、性能也會有很大的提升。
Greenplum支援多模存儲/多态存儲。Greenplum可以對同一張表的不同分區采用不同的存儲模式，常用的劃分标準是根據時間劃分分區。比如上圖的例子中，最老的資料，也就是不常通路的資料可以使用外部表的模式，中間的資料可以使用列存儲，頻繁更新或者通路的資料可以用行存儲。多态存儲對使用者透明。
資料有了分發和存儲，也得支援查詢。Greenplum研發團隊于2011年自研的優化器——ORCA，是Greenplum開源的子項目，也是Apache的頂級項目。ORCA是基于 Cascade 架構，基于 Cost 模型的優化器。ORCA的主要用途是解決一些OLAP中存在的複雜的查詢。ORCA可以很好的應對包括10+表join， 關聯子查詢， CTE， 分區動态裁剪等複雜查詢。在這些場景下，ORCA查詢速度比傳統的優化器有幾十倍到幾百倍的性能提升。
有了優化器，接下來就要談談查詢的執行。上圖中有兩張表：t1和t2，它們各有6條資料，分布鍵都是c1，如圖所示均勻分布在三個節點上。查詢 SELECT * FROM t1 JOIN t2 ON t1.c1 = t2.c1 的執行計劃如上圖右半部分所示，每個節點上單獨執行JOIN并将JOIN結果發送給master。這種場景是Greenplum最擅長的場景之一。
但并不是所有的查詢都容易處理，比如上圖的例子中，需要通過資料shuffle來實作資料在不同節點間的動态傳輸。Greenplum實際使用者有更多、更複雜的使用場景，Greenplum作為企業級資料庫都能很好的支援。
除了上面介紹的核心技術，Greenplum還有很多其他的技術，對資料庫的性能，穩定性、和高可用有很大的支撐，上圖列出了其中的一部分。
接下來，我們來介紹一個AP密集型的案例。某大型銀行，采用 Greenplum 作為資料處理的中樞，所有業務資料都經過 Greenplum 中樞叢集的處理，處理後的結果分發給不同的上遊叢集。中樞叢集資料量 PB 級，節點數達200個；上遊業務 Greenplum 叢集有二三十套。支撐了該銀行的大量核心業務。之前該銀行主流技術是 Teradata，現在使用了幾十套Greenplum叢集替換了之前的Teradata叢集。
随着資料量增大，一個痛點出現：傳統的 OLTP + OLAP + ETL 方式過于複雜，效率低，費用高。客戶對混合負載的需求越來越大。這裡混合負載和 HTAP 大體指一回事，但是也有些微差别：混合負載通常強調是大查詢+小查詢，通常隻讀為主；HTAP 則強調小查詢不隻是讀，而且有大量的 Insert、Update和Delete。Greenplum 早期版本主要為 OLAP 場景而優化，随着客戶需求越來越大，慢慢很多人開始使用 Greenplum 做混合負載。從客戶回報來看，大約有 30% 以上Greenplum使用者使用 Greenplum 處理混合負載，而且呈現逐年增長趨勢。從今年9月份釋出的 Greenplum 6 開始，Greenplum 對 OLTP 業務處理能力大幅提升。
上圖是我們在Greenplum6釋出時做的性能評測，Greenplum OLTP性能大幅提升。具體評測内容請檢視連結（
https://greenplum.cn/2019/05/14/greenplum-6-oltp-60x/）。 下面列出了常見TP查詢的tps，從這個資料看來很多TP業務完全可以使用Greenplum 6支撐。這個測試是Greenplum 6.0剛釋出時做的，用最新的 Greenplum 6.3跑測試，結果比這個資料還要好。
TPCB：4500 tps
SELECT：8萬
INSERT：1.8萬
Update：7000 tps
上圖是社群的一位小夥伴在社群的幫助下作的一個Greenplum6和MySQL的JDBC insert測評，在優化後得到的上圖的結果。Greenplum 6 可以承擔越來越多的TP業務。
Greenplum性能提升歸功于一系列OLTP優化技術，包括全局死鎖檢測、鎖優化、事務優化、複制表、多模存儲、靈活索引、OLTP友好的優化器、多個版本核心更新等。
由于有各種查詢的存在，就可能存在資源競争的情況。為了解決這個問題，我們引入了資源組，并在Greenplum 6中持續增強。資源組可以很好的進行資源管理，并具有上圖的各大功能特性。
接下來我們來講一個案例。很多企業會像上圖中采用很複雜、并且成本很高的架構：用TP系統來支援事務型業務，用AP系統支援AP業務，再用ETL将資料從TP系統中導入進AP系統中。而通過Greenplum 6這樣的HTAP資料庫，一套資料庫便可以同時支援AP和TP業務。Greenplum 從2019年9月份釋出至今，全球已有20多家客戶開始測試，并有數個客戶開始應用于生産系統。
5版本時，我們釋出了Greenplum Kafka Connector，在6版本中，也進行了大幅提升。GPKafka可以将使用者導入Kafka的資料高效并行的導入Greenplum中。
這是一個世界頂級證券交易所的案例。在做POC時，客戶要求每秒從Kafka導入100萬資料到Greenplum，每秒送出一次。最終結果是Greenplum可以做到每秒300萬條資料，資料量是9.8億，平均時延是170毫秒。
Greenplum可以處理各種資料類型，包括結構化、JSON、XML這種半結構化資料和Text這種非結構化資料，還有地理資訊資料等。除此之外，還可以做到in-databse 機器學習，圖計算等。
資料融合也稱資料虛拟化、資料聯邦，指不用移動資料，可以分析遠端資料源的資料。Greenplum的資料融合技術支援ORACLE、MySQL、PostgreSQL、Hadoop、HIVE、HBASE等。
Hackday 是Greenplum團隊的傳統活動：這一天可以“不幹活”，選擇你感興趣的一個問題組織一個小團隊搞一搞。上圖列出了一次Hackday的題目。在Greenplum中可以用下圖中的一條UDF來解決。
下圖是一個做國家安全的大型服務提供商的案例。使用者的地圖界面中可以做一些OLAP操作，包括下鑽、上卷等。在此案例中有文本資料、地理資訊資料、和結構化資料。每天 5億 資料，單表最大1000億，用了一個滿配的DCA一體機，單純文字索引達11TB。同時有 200+ 使用者通路，資料要求在1分鐘之内進入系統。
大資料分析最近幾年有一個新的發展趨勢， 進階分析下沉。之前的技術是拉資料到分析應用節點，需要抽樣和資料移動。為了解決這兩個問題，避免資料移動，提高模型精度，機器學習開始下沉到資料庫内實作。最早的工業實作之一是 Apache MADLib。MADLib是 Greenplum 2011年聯合加州大學伯克利分校、威斯康星大學、布朗大學等一起合作的項目，目前已經成為 Apache 的頂級開源項目。下圖是MADLib的架構。
下圖是MADLib支援的一些函數。
2019年年初，我們開始進行一個新的嘗試，用MADLib來支援AI 深度學習，在每個Segment上，通過MADLib架構支援Keras和TensorFlow，這樣就可以使用挂在節點上的GPU的資源實作深度學習。
采用Greenplum資料庫内分析方案後，性能上達到了十倍的提升。
最後我們簡單聊一下現代SQL vs 92年的SQL。下圖詳細說明了SQL特性、SQL标準和Greenplum對應的支援的版本。當把上面這些特性有效結合在一起的時候，可以實作的功能非常強大。
我們來看一個例子。
接着我們考慮一下以下多種因素。然後再考慮下你的方案是否可以很好的支援這些情況。
但是如果用成熟的資料庫，幾行SQL便可以實作。并且不需要考慮上面提到的各種問題帶來的挑戰。
綜上所述，Greenplum是一個成熟的、開源的企業級的HTAP資料庫，且支援Apache協定，為全球來自各行各業的大量大型客戶的生産系統支撐關鍵資料分析業務。數倉要求對大量資料進行處理，對應“Volume”；流資料要求對新産生的資料快速處理，對應“Velocity”；內建資料分析要求支援各種各樣的資料類型，對應“Variety”。這也是大資料的3V，Greenplum是新一代大資料處理技術。和傳統的Hadoop技術棧相比具有諸多優勢，譬如性能更好、更簡單易用、标準支援更好等。
目前很多資料中心将資料分析分為兩類：資料倉庫和大資料。數倉采用Greenplum已經非常流行，大資料部門也開始越來越多的采用Greenplum。這種新型的架構可以大大簡化資料分析的複雜度，提高資料分析速度和時效性，避免在各種資料産品間頻繁的搬動資料，降低運維人員的工作負載，提高知識共享度。節省成本且效率提升。