專家視野 | 牟宇航：百度OLAP數據庫——Palo

https://mp.weixin.qq.com/s/q8_kdDPdCPwIjI2BCETPZw

3月28日，在工業和信息化部的指導下，為期兩天的“2017大數據產業峰會”在北京國際會議中心召開。本次會議由中國信息通信研究院和中國通信標準化協會共同主辦，數據中心聯盟大數據發展促進委員會承辦。

百度研發經理牟宇航在29日上午大數據產品和應用創新論壇上發表了題為《百度OLAP數據庫——Palo》的演講。

以下是內容實錄：

大家好，我叫牟宇航，來自百度大數據部?，F在負責百度大數據部在線系統的研發管理，在線系統簡單來說就是大家用的數據庫。今天來這里給大家分享一個在云上售賣了一年，而且準備開源的數據庫。

在講數據庫之前先給大家講一下我們面向的場景，第一個是百度統計，是為其他第三方站長提供流量分析的工具。它的形式是提供一個腳本，其他的站長嵌入到自己的網站代碼里面，最后百度會通過這個腳本獲取第三方網站的用戶行為，然后出第三方網站的分析報表。這個產品量非常大，首先有450W網站站長去使用它，它的查詢頻率非常大，基本上峰值OPS會到2000以上。數據量也非常大，我們初步統計了一下每天結構化的數據會到1-2T。

這種場景是在線報表場景，可以看到左側欄是主題，右側欄包括了指標列和過濾條件，比如說可以根據時間過濾，可以根據其他方式過濾，每個主題是不一樣的。

第二個場景是我們經常在業務上會出現的一個場景，就是數據集市。數據集市一般面向業務為主題，這里舉例是百度糯米的數據集市，它是集運營、業務分析、訂單管理、會員管理、客戶關系、管理等一體的綜合數據平臺。這種數據集市場景多樣化，一方面剛剛提到的在線報表，比如說渠道人員想看一下幾個渠道的運維情況，這有一個報表。再有產品經理想多維分析下產品傳單的情況。比如說新上線一個活動，運維人員想看一下新上線活動的情況，它的查詢非常靈活。

在這種數據集市里面除了場景比較復雜，另外使用它的角色很多，所以這個里面涉及到多租戶的管理。

這里拿了另外一個多維分析系統，初步看它的樣子跟在線報表比較像，如果仔細看會不一樣。它的左側欄是個維度，包括像操作系統、時間瀏覽器維度，這些維度可以下展很多級別。右邊這些欄首先是查詢指標，另外是過濾維度的條件。

這種場景是典型的在線多維分析場景，以上三種場景就是今天要講的數據庫Palo的主要場景，在線報表、多維分析、機器查詢。這個名字很好記，當時想這個名字就是面向多維分析的數據庫，用一句話形容Palo就是A：MPP-based Interactive Data Analysis SQL DB。面向數據量是百TB到PB級別。

講了這么多的OLAP，OLAP概念分為兩個維度，第一個是中間的A，A相當于Transactional Processing。第二個維度是Online相當于Offline，下面列了一張圖但凡所有的大數據應用和面向C端B端的架構都是這樣的架構，首先前端是客戶端，后面是服務端。

App Client加上App Server再加上Transaction，在大數據時代產生了很多數據，我們希望把這些數據提取出來，挖掘其中的價值，這就是AP角色的事情，它可以做很多的事情，可以做轉換，可以做數據挖掘，這都是廣義的概念。在大數據時代，AP變得越來越重要，變得越來越龐大。TP核心價值在于業務邏輯，AP核心邏輯在數據本身，我們要從數據本身挖掘更多的價值。OLAP是面向AP的，這個里面也提了在線概念。拿購物舉例，離線像倉庫的概念，在線像小超市的概念。離線面向數據開發人員和數據建設者，在線面向數據消費者，比如說產品經理、管理者、營銷人員、運維人員，可能他不太懂數據怎么玩，但是用了這個系統就會玩了。我們看到在大數據時代越來越多人使用數據，在線這一部分的重要性變得越來越重要。

這個里面詳細列舉了一下OLAP和OLTP的區別，OLAP的場景比如說分析一個全量的歷史數據，這個歷史數據可能涉及一年可能涉及很多，它的數據量會非常大，數據量大也就導致很多不一樣，比如說導入方式、側重點，我們評估OLAP性能的方式不太一樣。最后是數據組織，一般來講OLTP是完全遵循三范式的，而OLAP就不一樣，它是五范式的。

剛才提到AP在大數據時代變得越來越重要，在2000年之后整個業界在AP領域涌現出來了知名的數據廠商和數據產業。

在開源界大概在2010年左右發力，這里介紹了Palo的區別和定位。首先，最顯著的區別是Palo的成本比較低，那些看到的開源產品基本是在百萬美元的量級，一套產品就這么貴。而Palo用的是普通的X86服務器，百度統計的業務也不過用了60臺，大家可以算一下這個成本很大的。

第二個是Palo的高可用和異用性，還有高性能，這是我們和其他競品最核心的區別。

在講Palo之前，我們先看Palo是怎么用的？長什么樣子？首先我們在MySQL 的選擇上語句不同，包括會增加一些在MySQL 比較有用的語句。這些增加的語句怎么用呢？我們通過直接輸入XP就能看到語句包括參數怎么使用。上面是Palo，因為兼容MySQL協議。

言歸正傳，看一下Palo的架構。首先說一下Palo的設計理念，Palo的設計理念強調要優雅、簡潔，這個里面大家看我們的架構很簡單，每個顏色代表一個進程，藍色是客戶端，不是Palo內部的東西。在這里面我們部署時前端和后端是分離的，在部署時一臺機器上只需要部屬一個進程就可以了，部署非常簡單。前端首先負責源數據的管理，前端還可以負責接收產品請求，包括建表、建數據庫，包括數據導入、管理，包括復本管理，數據請求。包括查詢界定都是在前端完成的。比方說，前端是Palo的大腦，后端是Palo的軀干，可以干活。一般來講前端節點稍微少一點，后端節點比較多。

為什么前端節點有3-10個呢？為什么不是10個呢？相當于元數據的架構，這個里面列了元數據的管理架構。

第一個是中心架構，最典型的代表最近開源很火的，它的優點：第一，實現很簡單，這是中心架構。跟它對應的是對稱架構，它的優點是可靠性比較好，缺點是當元數據更新頻率高的話，如果Palo采用這種數據元數據更新比較高時，網絡容易成為瓶頸。

Palo的元數據管理分三類，一個是Leader，一個是Follower，一個是Observer，Leader和Follower會參與主節點的競選。參與選舉，讓大家去選，這會帶來一個問題，在元數據更新時要求大量的元數據同時更新，當你元數據很多時，性能會出現瓶頸，所以我們增加了Observer，它只負責接受元數據更新，這種方式可以最大程度節省元數據更新所帶來的網絡瓶頸。這種結合了高可靠，高QPS和可動態的擴縮容，支持頻繁的元數據屏障。

業界有些數據庫元數據直接存在類似于MySQL系統里面，為了對元數據的查詢和保證。但是對于Palo來講這種方案不太適合，在Palo第一版本時也是這種方案。但是在百度整個的數據量比較大前提下，整個的元數據訪問比較復雜，而且我們對比了一些復雜工具之后，會有變態的情況出現。比如說一個查詢語句、一個點擊查詢，會翻譯成成千上萬的語句。如果一下翻譯出來成千上萬語句時，你把它都執行完，可能訪問性會存在瓶頸。

我們的內存如果BUG掉怎么辦？Checkpoint保證說如果內存掛掉的話，還可以同步進其他的內存，這樣保證了元數據的可靠性。數據可靠性和元數據可靠性大同小異，在這里Palo也支持做副本，也可以自動修復。之前發現了一個用戶在導入數據時只測了一部分，他想導入更快一點，占用存儲機更小一點，等他把數據都導進去時，他擴展成了三個副本，這都是利用Palo修復的功能，把單副本擴展成三個副本。

這個是MPP，它是把查詢計劃與查詢執行物理分離。我要說一下Palo的MPP架構和OLTP MPP是不一樣的，我們為了保證整個的查詢執行不影響查詢計劃，所以把物理分離了。

很多同學會問我Palo底層用什么實現？Palo是一個高度集成系統，是查詢與存儲一體的數據庫系統。在這里里面，它比較易于實現一致性保證。在一致性提到兩個維度，一個是單調一致性，還有Consistent View，它是高性能的，最后是易部署，易調試。像Palo去部署的話一天就部署好了，像一些大的開源系統依賴的環境和條件比較多，一旦花了幾個月做好，容易出問題，出了問題去定位比較復雜。

整體的架構是這樣的，下面我講一下后端節點存儲結構是什么樣的？

首先是列存，這個概念大家都很熟悉，我不會講太多。只講一點OLTP都是行存的，OLAP可能是對全量數據的某幾列進行分析，所以把它一列存在一起更好一點。列存的優點很方便做壓縮很方便做索引。

這里著重講Palo很特色的地方，它可以支持很多的數據模型。數據模型建表時會考慮很多的列式，比如說多少列。在Palo建表時首先考慮一個問題，我的哪些列是指標列，哪些是維度列。維度列是Time、Id、Country，而指標列是Clids、Cost。我們的數據庫首先存在序列，然后進行排序，Palo會做一個事情保證全局唯一。

首先已經有這樣一份數據存在Palo里面，一共有三行，T是這樣的。又新來一份數據，新來的數據第一行它的T列跟之前T列不一樣，它是20140101，1、US。存到T列之后首先把T列不一樣的單獨存一條，T列相同的把Value列進行合并。

如果T列重復類很大，使用Palo之后其實存的數據量非常小。

查詢時會進行很多的具體操作，這一部分操作在存儲過程中已經做完了，也就是說這個數據模型可以極大提升做指標維度列的表查詢。除了這個具體數據模型之外，我們也當然支持非具體模型。

第二個是物化視圖，它有兩種優化方式和優化思路。第一個是物化視圖把這些表按照某些T進行存儲。一個原始表可以對應很多的物化視圖，查詢過程中具體應用哪個物化視圖，這個是Palo進行選擇的。物化視圖本身概念是時間換空間的技術，然后講一下查詢的優化。

第一個是向量化執行，一個是LLVM。向量執行是行式執行引擎問題。但是LLVM有一個問題，它在編譯時有一個固定的編譯開銷，這個大概在百毫秒左右。

下面講一下存儲的小技巧，所有的分布式系統都會分片存儲，這樣有可能會導致某些分片會很大，無論是用哪個方式進行分片，可能每個分片都很大。另外，做分片分列優化時又會很麻煩，Palo用兩級分片解決的。通常出現用戶第一級分區是用一個月分區，第二級分區是用SATA進行分區。在兩級分區基礎上，我們為了高效利用硬件性能，我們知道SSD數據非常好。

再講一下數據導入，剛才提到的OLTP和OLAP的區別，OLTP有一個很關鍵的指標是每秒數據量。OLAP是講數據吞吐量。鑒于此Palo有兩種導入方式，一個是批量導入，一種是小批量導入。批量導入是利用Hadoop的系統，先把批量梳理好再進行導入。第二種是不批量導入，利用查詢執行框架進行導入，它的好處做的頻率好一點，多導入事務提交。具體的運行方式也和MySQL不一樣，這兩個命令都是異步的命令，因為批量導入不可能馬上完成，異步命令有一個生效問題，因為Palo在業務過程中有很多沒有對一致性要求，我們在一致性上做了很多改進。比如說每一批導入都附上版本號，MySQL是不用的。再比方說我們導入的一個批次數據，怎么往主版本里面去合？

這里面就給出了導入一個批次怎么往主版本合的？這里面列出了0-60，61、62都是導入的版本號。先假設主版本里面存的是0-60數據，如果往主版本合的時候，首先想一下把主版本的數據讀出來，然后再寫進去。通過版本合并可以極大減少數據量，但是版本合并的原則就是不能影響線路查詢。

最后是資源隔離，剛才提到Palo在百度內部也應用了200多個業務，我們不可能建200多個集群。我們的大多數業務都是在一個共享集群里面，資源隔離有兩層概念。第一層是用戶之間建立的資源隔離，不同用戶不能相互影響。第二，同用戶之內設資源優先級隔離，可能我的分析類查詢要優于Udhome查詢。

這是Palo的發布，Palo2013年10月份發布了第一個版本。2014年發布百度云OLAP引擎。2015年進行了拍賣，實際上已經面向上市了。

這是在云上的部署方式，類AWS redshift，

on-demand provisioning。這是在云上的一個界面，瀏覽器去進行集群管理，增添的界面，很簡單，一共沒有幾步。

這里再說一下未來的Palo Road map，我們希望在這基礎上開源，希望有更多對數據庫感興趣的同學能夠跟我們一起開發，一起活躍這個產品。