導讀：2019年 Pivotal 中國研發中心副總經理兼 Greenplum 中文社區發起人姚延棟受阿里雲開發者社區邀請於釘釘進行技術直播演講《基於 PostgreSQL 的 PB 級開源企業級分佈式 HTAP 數據庫》。本文由演講內容整理而成。
直播回顧視頻鏈接：
今天和大家分享的標題是《新一代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年代初開發 ）第一版本實現時，數據存儲就是現在我們說的列存。第一版做完後，總結了設計的一些缺陷，其中包括使用列存。如今列存成為了用來解決大數據的主流技術。很多時候，創新都會用一個已經被髮明的老技術來解決新時代的問題。
接下來和大家主要講一講 Greenplum 能做什麼。首先是數倉、OLAP、即席分析。這三個詞很多時候指的是一回事。細摳的話各自也有不同的側重。
數倉是一種數據庫類型，用來做 BI 和複雜查詢處理，強調的是來自各種數據源的歷史數據的分析，產生商業智能（ BI ）；OLAP 是一組操作，例如 pivot/slice/dice/drilling/cube 等。（ https://stackoverflow.com/questions/18916682/data-warehouse-vs-olap-cube ）強調的是處理；即席分析：強調的是查詢時 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。
Master：存儲用戶元數據，負責對整個集群的調度、監控和管理控制Segment：存儲用戶數據，執行master分配的任務Interconnect：實現數據在各個節點間的傳輸整個架構可以做到線性拓展，這裡我們看到 Greenplum 的核心架構特色：MPP shared nothing。 MPP 是大規模並行處理，shared nothing 是無共享。
在這種架構下，數據要如何存儲呢。在 Greenplum 這種分佈式數據庫中，數據根據各種策略分佈到不同節點上。Greenplum 提供了多種分佈策略，包括哈希、隨機，6.0 還提供了複製表的技術。 不管是哪種技術，最重要的策略和目標是做到數據的均勻分佈。DBA 或者開發人員要選擇合適的分佈鍵，使得每個節點分佈 1/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，如圖所示均勻分佈在三個節點上。查詢
但並不是所有的查詢都容易處理，比如上圖的例子中，需要通過數據 shuffle 來實現數據在不同節點間的動態傳輸。Greenplum 實際用戶有更多、更復雜的使用場景，Greenplum 作為企業級數據庫都能很好的支持。
除了上面介紹的核心技術，Greenplum 還有很多其他的技術，對數據庫的性能，穩定性、和高可用有很大的支撐，上圖列出了其中的一部分。
接下來，我們來介紹一個 AP 密集型的案例。 某大型銀行，採用 Greenplum 作為數據處理的中樞，所有業務數據都經過 Greenplum 中樞集群的處理，處理後的結果分發給不同的上游集群。 中樞集群數據量 PB 級，節點數達 200 個；上游業務 Greenplum 集群有二三十套。支撐了該銀行的大量核心業務。之前該銀行主流技術是 Teradata，現在使用了幾十套 Greenplum 集群替換了之前的 Teradata 集群。
隨著數據量增大，一個痛點出現：傳統的 OLTP + OLAP + ETL 方式過於複雜，效率低，費用高。客戶對混合負載的需求越來越大。這裡混合負載和 HTAP 大體指一回事，但是也有些微差別：
上圖是我們在 Greenplum 6 發佈時做的性能評測，Greenplum OLTP 性能大幅提升。具體評測內容請查看鏈接（ ）。下面列出了常見 TP 查詢的 tps，從這個數據看來很多 TP 業務完全可以使用 Greenplum 6 支撐。這個測試是 Greenplum 6.0 剛發佈時做的，用最新的 Greenplum 6.3 跑測試，結果比這個數據還要好。
上圖是社區的一位小夥伴在社區的幫助下作的一個 Greenplum 6 和 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。這種新型的架構可以大大簡化數據分析的複雜度，提高數據分析速度和時效性，避免在各種數據產品間頻繁的搬動數據，降低運維人員的工作負載，提高知識共享度。節省成本且效率提升。
End～