邁向更靈活，貝殼 OLAP 平臺架構演進

1、貝殼業務背景介紹

貝殼找房的定位是科技驅動的新居住平臺，提供涵蓋二手房、新房、租賃、裝修和社區服務多元化居住服務。貝殼找房聚合居住垂直品類服務商，提供全方位的品質居住服務，有三億家庭用戶，被認爲是房產類的淘寶，不少品牌和開發商都入住了貝殼找房的平臺。

貝殼找房推進了房產服務這個傳統行業轉向互聯網化的過程，一方面要求業務運營日趨精益化，另外一方面數據驅動角色的需求也不斷加強。
貝殼找房的業務模式比較複雜，涉及到二手房、新房、裝修、租賃等不一樣方向。這也給整個 OLAP 平臺數據分析方面帶來了不少挑戰，好比如何更好的支持不一樣複雜業務場景下的需求。

2、OLAP 平臺架構演化歷程

OLAP 平臺的架構發展大體能夠分爲三個階段，第一個階段是 2015 年到 2016 年鏈家網的時代，它是初期從無到有的階段。第二個階段是從 2016 年到 2019 年初，這個階段是基於 Apache Kylin 構建的 OLAP 平臺建設階段。從 2019 年初到如今，邁入的是第三個階段，靈活支持各類 OLAP 引擎的 OLAP 平臺建設階段，這個階段結合了 OLAP 平臺和 Kylin 平臺的能力。            

1. 第0階段—Hive 2 MySQL 初期階段

Hive 2 MySQL 之因此稱之爲 0 階段，是由於尚未造成平臺化，數據處理流程很簡單。
數據通過Sqoop離線批量或 Kafka 實時進入大數據平臺，處理後再經過經常使用的大數據調度系統天天定時寫到關係型數據庫 MySQL 中去，以此爲基礎構建各類報表。           
這是從無到有的過程，不少公司最開始的階段也是這樣的方式，這種方式很是的簡單很容易落地，把平臺搭建起來就能夠跑起來了。
可是其中的問題也很明顯，受限於 MySQL 能力沒法進行大數據量的快速存儲和查詢，對數據量百萬、千萬級別的系統很難支持，這種方式也缺少共性能力的沉澱，整個需求定製的開發週期比較長。
由於這個階段還稱不上平臺化，因此稱之爲 0 階段。                      初期階段創建起來以後，隨着用戶去需求的增多，問題也逐漸暴露出來，這就須要對整個架構進行改造。
改造的目標很清晰，一是系統不支持快速查詢和大量數據存儲，須要平臺針對這一點進行改進。二是平臺化不夠，這個階段須要沉澱一些共性能力，可以建設公司級的 OLAP 平臺。針對這兩個問題，咱們選擇的是可以支持大數據量的 OLAP 引擎 Kylin。
對於平臺化不夠的問題，引入了中間層做爲 OLAP 平臺與用戶統一的接口，因而有了第一階段的 OLAP 平臺架構。

2. 第 1 階段—基於 Kylin 的 OLAP 平臺架構

基於 Kylin 的 OLAP 平臺架構共分爲三層，首先是最底層的 OLAP 層，這一層是圍繞 Apache Kylin 構建的 OLAP 平臺，因此只有  Apache Kylin 這個引擎。
在此基礎上引入指標平臺層，它的主要做用是：一是它對外提供統一的 API；二是提供指標統一的定義和管理口徑；三是實現指標查詢。指
標平臺層能夠認爲是應用層和 OLAP 引擎層之間的一個抽象，應用統一經過指標平臺API來訪問獲取數據，而不直接訪問OLAP引擎，並不暴露給上層業務而是經過主要平臺API暴露給引擎。


指標平臺引入抽象層究竟是爲了解決什麼問題呢？
一是指標的定義，指標平臺能夠定義整個指標。首先明確什麼是指標，不少公司談到本身指標體系建設時候說，指標是業務單元細化和量化的度量層，使業務目標可描述可拆解，是量化項目的重要依據。
簡單的說，數倉是經過維度建模包括新型和雪花型建模，裏面會定義不少維度和度量。指標是對維度（星型）建模的抽象，把指標的維度和度量與新型模型對應，暴露給用戶，用戶能夠根據某個指標就知道這個指標從哪些維度、哪些角度查詢，知道有哪些度量。
             
例如，做爲一家房產公司，咱們定義的一個指標是「帶看量」，這個指標支持不少個維度，能夠查看不一樣運營管理大區的帶看量。咱們公司全部指標的定義管理都是在指標平臺上進行的，不會存在歧義和口徑不統一的問題。
各個業務方使用 OLAP 平臺也是經過指標平臺進行的，數據開發人員在 OLAP 平臺上建指標，而後開放給業務方使用，來實現多維數據分析。
指標的第一個功能是統一的口徑管理，第二是指標的查詢，業務人員能夠經過指標調用參數對指標的不一樣維度進行過濾。好比起始日期，指標平臺根據調用參數自動轉換成 Kylin 查詢 SQL，對 Kylin 發起查詢得到數據，並根據需求做進一步處理，例如同環比計算、指標間運算等。
  指標平臺的第三個功能是指標 API 應用，經過指標 API 對外暴露指標。指標API上層應用可以經過指標API來調用指標，好比公司的可視化平臺，能夠在裏面配一個報表，可能不少公司也有這方面的可視化的工具，好比騰訊雲也有可視化分析的工具。
選擇指標後，對應的維度和度量也就明確了能夠從哪些維度看，作哪些篩選，公司內部人員能夠根據指標配置報表。
           另外一方面，也能夠根據有些數據產品，好比貝殼爲提升經紀人做業效率提供的店面管理、賣房狀況等指標，這些數據產品能夠經過API 調用指標得到指標數據，這就是指標API的應用。
爲何要選擇 Kylin？
Apache Kylin 是由 eBay 開發者貢獻到 Apache 開源社區的，能夠知足較高併發的訴求，可以支持大規模數據查詢，可以處理 TB 乃至 PB 級別的分析任務。
           Kylin 的核心思想是預計算，對多維分析可能用到的度量進行預計算，將計算好的結果保存成 Cube，供以後查詢。這樣會縮短響應時間，也能夠支持相對較高的併發。
Kylin 架構首先要求業務線定義一個「Cube」，須要用戶指定有哪些維度和度量，以後就能夠進行預計算了。Cube 構建完成後數據準備好就能夠對外提供給用戶查詢了。
           Kylin 的原理並不複雜，不少其餘基於 OLAP 的引擎也是這麼作的，只是以前沒有應用大數據的基礎設施，Kylin 是基於大數據平臺構建的，能夠支持更大的維度、數據量，之前的 OLAP 引擎有些計算是有限的。
Kylin 的預計算模式最大的問題是維度爆炸的問題，簡單說就維度太多了，計算不過來了，Kylin 也提供了不少的技術來緩解這個問題。
在基於 Kylin 的 OLAP平臺裏面，對外統一的輸出方式是指標。建指標的流程是數倉建模，肯定業務過程生成任務表後建立 Cube，而後建立指標，在構建 Cube，最後進行指標的調用。
  對已有的指標加以業務限定，也能夠作複合指標，對於幾個指標作四則運算能夠獲得新的指標。從整個流程上說，這個階段基於Kylin的 OLAP 平臺跟Cube是嚴格綁定的，整個過程 是在Kylin 上建立 Cube，而後在指標平臺上建立指標。
這一套下來以後，在 2016 到 2019 年整個平臺在公司內進行推廣應用，指標也得到了普遍的應用，也創建起來整個公司指標體系，覆蓋公司幾乎全部的業務線。
如今整個公司有六千以上的指標，以前更多，最近進行了一些優化把一些不用的指標去除了，日均調用有兩三千萬。
           平臺構建完後在公司得到了普遍的應用，咱們圍繞 Kylin 作了不少工做，包括幾個方面。
一是 Kylin 監控管理平臺建設，Kylin 承載着綜合指標，其中不少是關鍵指標，一出問題會影響整個做業，須要把監控管理構建好，及時看到各類問題能夠解決。二是優化和定製服務；三是和整個公司大數據應用、公司大數據系統、原數據、調用系統進行整合。
主要是這三方面工做。Kylin 在貝殼有很大的應用量，高峯期整個企業有 800 多個 Cube，300 TB 以上的存儲量、1600 億行的數據，Cube 最大有 60 多億，日均查詢有兩千萬。

圍繞 Kylin 構建的平臺解決了公司的需求，可是並非很完美，隨着系統整個的應用推廣業務要求也愈來愈高，也提出了不少問題。簡單總結爲如下幾個方面：
首先是能力方面的問題，底層基於 Kylin 的預計算原理致使維度多、基數高，Kylin 的計算量就會指數型膨脹，它支持維度並不能太多，官方最可能是80個，實際上20個以上就要深度優化了，支持維度也有限，咱們的業務裏面不少指標也有須要有三四十個維度，集團帶看量就有20個維度。
業務變化很快，也須要快速創建指標，快速對指標維度進行變動，這對 Kylin 以預計算爲核心原理的引擎來講是比較麻煩的事。
由於從新構建整個 Cube 耗時很長，維度多、數據量大。維度變也要把整個指標全部的 Cube 所有從新預計算一遍，一個維度變動幾天、幾周、上月也有的，沒法知足快速業務迭代的需求。

其次是性能方面的問題，Cube 構建的時候就要指定一個HBase的RowKey，若是通常的數據開發人員、業務開發人員不瞭解HBase，就會致使他創建的 Cube 性能差，就須要 OLAP 的維護人員去幫助進行優化。
還有一些其餘的問題，好比在數倉裏面碰到的一些經典問題，維度的緩慢變化、多值維度(例如一個CA管理多個店，一個店被多個CA管理，多對多關係）。
究其緣由，不少都是因爲 Kylin 自己的原理致使了這些問題，單一 OLAP 引擎(Kylin)是沒法知足公司各類場景需求的，爲了讓針對不一樣的業務場景的用戶方使用不一樣的 OLAP 引擎，OLAP 平臺也要作出相應的改動。

3. 第 2 階段—支持多種 OLAP 引擎的 OLAP 平臺

新的架構底下一層是 OLAP 引擎，這一層除了 Kylin 之外也能夠引入其餘引擎。在 OLAP 引擎之上是一個查詢引擎 QE，對指標平臺統一架構上提供查詢接口，承擔屏蔽底層 OLAP 引擎查詢語句差別的工做，讓指標平臺的架構更加清晰。

以前基於 Kylin 構建的 OLAP 平臺，應用層不直接依賴於底層引擎Kylin，而是經過指標API來調用，這樣底下的引擎可的變化能夠作到用戶是無感知的，這就是提供抽象層的好處。
接口不變用戶上層應用不須要改變，底層的改變是OLAP平臺內部的事情。這種方式能夠支持多種OLAP引擎，應用接口也保持一致，不須要用戶作改動。
指標平臺層最大的改變是 Cube 管理，再也不依賴於Kylin。若是指標要映射到 Kylin中，會轉變成 Kylin 的 Cube。整個 Cube 的定義也參考了 Kylin，Cube 至關於在指標平臺層和底層 OLAP 引擎之間又引入了一個抽象層。須要查詢的時候能夠將 Cube 和 OLAP 進行動態綁定。
查詢引擎層主要是用於屏蔽，向上提供統一的數據查詢接口，用來屏蔽底層 OLAP 引擎的差別，實現統一查詢請求到對應 OLAP 引擎的轉換。
這種架構引擎下，標準化開發流程的步驟沒有太大差異，仍是數倉建模、建立 Cube、建立指標、構建 Cube、調用指標，可是全部動做都是在指標平臺上完成。可是不少動做語義發生了變化，構建 Cube 是對 Druid/CK/Doris 完成數據的導入。

3、OLAP 引擎選型與實踐

1. OLAP 選型要關注什麼？

OLAP 選型通常關注三個方面，一是是它支持的數據量是怎樣的，好比 TB 級甚至更大。二是性能，性能有兩方面，一是響應時間快不快，二是支持併發度，在高 QBS 的狀況下整個查詢的性能怎麼樣。
第三是靈活性，靈活性是沒有標準的，根據應用的需求定義靈活性，常見的 OLAP 引擎是否支持實時導入、實時更新、實時動態變動等等，這些都是靈活性的體現，具體須要哪些是根據本身的應用需求來定義的。
           瞭解這些標準以後咱們看一下常見的開源 OLAP 引擎，開源 OLAP 引擎有十幾二十種，沒有一個引擎能把它們都統一了。咱們對它們進行了一個大概的分類，分類原則一是看它的原理是怎樣的，第二看是否有自定義的存儲格式，能管理本身的數據。

2. OLAP 引擎有哪幾種？

OLAP 引擎大概能夠分爲三類，首先是 SQL on Hadoop，特色是數據量大、容錯性好、靈活性高，有完備的 SQL 語句支持，但性能上要達到亞秒級響應是比較困難的。
第二類基於 MPP 的，特色是不本身管理存儲，使用通用的存儲格式，在併發量大的時候性能降低也是比較快的。第三類有本身的存儲格式，好比典型的 Druid、CK，通常這種類型的引擎支持的數據量相對較大，靈活性上各個引擎的差別性比較大。

3. OLAP 引擎的比較

從咱們本身的工做需求來講，須要有亞秒級的響應、比較高的併發和QBS，對咱們來講在指標平臺是隻能選擇第三類的。咱們如今如今使用的是 Kylin，基於這個原則咱們考察了三種引擎，Druid、CK 和 Doris。           
咱們首先關注的是數據支持量和查詢性能，這幾個數據都是不錯的，能夠知足公司 TB 級的需求，併發量相對高，其餘關注的幾個是實時數據導入和更新等等，目前 Doris 支持的比較好一點，ClickHouse雖然也支持實時更新，但比較弱。
另外對 Online 的支持就須要 Schema 靈活的變動。Druid 咱們如今的應用的仍是比較多，承擔了 20%-30% 的量。

4. Apache Druid 

Apache Druid 是 MetaMarket 公司開發的，而後貢獻給 Apache，它有如下幾個特色：

• 支持海量數據；

• 亞秒級查詢響應：列式存儲；

• 高可用性、可伸縮；

• 並行處理：Scatter&Gather 模式；

• 支持實時導入；

• 靈活數據模式 Schema-less。

從它的架構來看，有三個節點，查詢節點、數據節點和 Master 節點。查詢節點用來查詢請求，查詢請求到了 Broker 上後找到對應的 Historical，對應以後傳給客戶端。數據節點用來存放數據， 經過 Deep storage 進行深度存儲，本身不作同步副本的事情。           
Apache Druid 在數據格式上分紅三個部分：

• Timestamp：時間戳信息；

• Dimension：維度信息；

• Metrics：通常是數值型。

Apache Druid 對數據模型有強要求，首先是時間戳，這是用來作分區的；二是維度，Dimension 來過濾條件，也能夠作聚合。
它的原理是根據時間來分區，每一個區叫作一個 Chunk，而後根據數據量的大小又能夠分紅一個或多個 Ssegment 文件。Ssegment 是自定義的列式存儲格式，對查詢比較優化，對 OLAP 引擎是比較友好的。
           目前 Druid 主要用於離線指標，實時指標還在測試，大概承擔了平臺 30% 的流量，性能還不錯，3s 的返回大概在 99.7%。

Kylin Cube 構建和 Druid 數據導入時長比較：
咱們使用 Druid 是爲了解決 Cube 構建時間太長的問題。
咱們構建一個 Cube 須要 220 分鐘，但咱們導入 Druid 只須要 22 分鐘，也就是說若是 OLAP 表大概早上六點好的話，構建 Cube 要等到九點才能查詢指標，而 Druid 大概六點半就能夠查了。一樣，若是我要回刷一年的數據，用 Kylin 可能要好久，用 Cube 可能就很快。
Kylin 與 Druid 相較源數據的膨脹率：
Druid 通常數據量比較小，Kylin 根據維度和基數密切相關，最大的數據膨脹率達到了 139%。

Druid 相關工做：
（1）Druid 監控管理平臺建設（2）Druid 優化與定製改造

• Druid 精確去重功能支持
• Druid 大查詢監控與處理
• Druid 數據導入優化
• 查詢優化

（3）Druid 與公司內部大數據系統的整合

5. Clickhouse/Apache Doris 

CK 和 Doris 就不過多介紹了，都是基於 MPP 的，有自定義的存儲格式。目前主要用於實時指標和明細數據查詢，承擔了小部分流量，在 1%-2% 左右，如今還在進一步深度測試中。
           

4、將來工做規劃

如今咱們整個平臺的基本架構已經肯定了，引入了不少引擎，正在把各個引擎推廣應用，根據以後推廣應用的狀況會收縮到一兩種引擎作比較深度的定製。
第二就是但願可以在多個 OLAP 引擎之間作自動的路由，性能比較差的時候自動路由到另外一個引擎。
另外就是須要與 Adhoc 平臺的融合，還有實時指標的優化，目前實時指標只是基本上把整個流程走通了，引入這個引擎後如何更好的支持實時指標這是後續須要作的工做。

5、Q&A

Q：維度變化大家經常使用的方案是什麼，拉鍊表嗎？ A： 對，咱們如今是用拉鍊表，可是像 Kylin 這些維度變化咱們事先用大寬表把維度打進去，查的時候會把拉鍊表對應的信息查出來加到裏面去。
Q：對查詢引擎感興趣，能介紹下如何屏蔽 SQL 方面的差別嗎？ A： 咱們對外統必定義結構化場景語言，指標平臺只要經過統一的語句過來，內部會分析更多引擎的差別，看怎麼把統一的語句轉換成對應的引擎差別，這個事情是在 QE 查詢引擎裏面作的。
Q：實時性差的問題如何處理？ A： 實時指標的實時性並不會差，像 Druid 和 Doris 是能夠從  Kafka 實時接入數據，若是實時數據生產流程沒有延時的話它的實時性是能夠保證的。
Q：OLAP 查詢平臺的併發量？ A： 併發量最高的 QPS 在兩三千吧。
Q：不一樣 OLAP 引擎查詢速度差距大如何保證性能? A： 須要分析查詢比較差的那個指標更適合哪一個引擎，好比在 Druid 上查詢比較差是什麼緣由，是否是更適合另一種引擎，那就把它遷移到另外一種引擎上，就是但願找到更適合的場景。
Q：有沒有用 Cassandra 作底層存儲平臺？ A： 它和 HBase 相似，若是用來作底層存儲還須要作一些工做，在 OLAP 裏面用的還很少。像 HBase ，它是在 Kylin 底層用來作 Cube 存儲，Kylin 4.0 也在剝離對 HBase 的依賴，由於它並非列式存儲的方式。