本文由阿里雲開發者社區直播整理而來。
講師介紹：
姚延棟，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。這種新型的架構可以大大簡化數據分析的複雜度，提高數據分析速度和時效性，避免在各種數據產品間頻繁的搬動數據，降低運維人員的工作負載，提高知識共享度。節省成本且效率提升。