Apache Kylin巨量資料分析平台的演化

標籤：

Apache Kylin巨量資料分析平台的演化

轉：http://mt.sohu.com/20160628/n456602429.shtml

我是來自Kyligence的李揚，是上海Kyligence的聯合創始人兼CTO。今天我主要來和大家分享一下來Apache Kylin 1.5的新功能和架構改變。

　　

　　Apache Kylin是什麼

　　

　　Kylin是最近兩年發展起來的開源項目，在國外的知名度不是很高，但是在中國廣為人知。Kylin的定位是Hadoop大資料平台上的多維分析工具，最早是由eBay在上海的研究實驗室孵化的，提供ANSI-SQL介面，支援非常大的資料集，未來期望能夠在秒層級返回查詢結果。Kylin於2014年10月開源，現在已經成為為數不多的全部由華人主導的Apache頂級項目。

　　1.SQL Interface

　　

　　大多數的Hadoop分析工具和SQL是友好的，所以Apache Kylin擁有SQL介面這一點就顯得尤為重要。Kylin的ANSI SQL可以替代HIVE的很大一部分工作，如果不使用HIVE本地方言的話，那麼Kylin和HIVE幾乎完全相容，也是SQL on Hadoop的一員。

　　Kylin和其它SQL ON Hadoop的主要區別是離線索引。使用者在使用之前先選擇一個HIVE Table的集合，然後在這個基礎上做一個離線的CUBE構建，CUBE構建完了之後就可以做SQL查詢了。SQL資料下的關係表模型和原本的HIVE Table的一模一樣，所以原來的HIVE查詢可以原封不動的遷移到Kylin上面直接運行。

　　用離線計算來代替線上計算，在離線過程當中把複雜的、計算量很大的工作做完，線上計算量就會變小，就可以更快的返回查詢結果。通過這種方式，Kylin可以有更少的計算量，更高的輸送量。

　　2.Big Data

　　2015年eBay公布Kylin已經有接近千億的資料規模，2016年肯定已經穩穩的超過千億了。但是這也可能不是Kylin的最大案例，因為根據我們在中國移動得到的資料，他們每天可能就有百億的增量資料要放到Kylin的系統裡面，可能十天就超過千億了。國內很多一線互連網企業也都在使用Kylin技術來進行多維資料分析。

　　

　　3.Low Latency

　　Kylin的查詢效能相當不錯，這也是當初它的設計目標。我們的目標是在秒層級能夠返回查詢結果，在實際生產系統裡面，Kylin 90%的查詢都可以在穩定的三秒內返回，而且這並不是一條兩條特別的SQL可以做到這個效能，而是在數萬條不一樣的、在各種複雜的查詢下的SQL都可以做到這樣。

　　

　　可以看到，在某一天Kylin的查詢延遲有一個山峰，所以不是說只要用了Kylin所有的查詢就一定快，但是經過調優大多數的查詢都會很快速。

　　4.BI工具的整合

　　Kylin提供了標準的ODBC和JDBC介面，能夠和傳統BI工具進行很好的整合。分析師們可以用他們最熟悉的工具來享受Kylin帶來的快速。

　　

　　5.Scalable Throughput

　　Kylin是用離線計算來代替線上計算，相比於其他的工具，線上計算量較小，能夠在固定的硬體設定上面擁有更高的吞吐率。

　　

　　這是在兩條比較複雜的查詢下查看Kylin的線性擴充能力的實驗。我們在一個比較簡單的機器上面增加Kylin的查詢引擎的個數，可以看出Kylin在從一個執行個體加到四個執行個體的過程中輸送量是呈線性上漲的，Kylin每秒可以支援大約250個查詢。當然，這個實驗還沒有探測到整個系統的瓶頸，根據理論，Kylin系統的瓶頸最後會落在他的儲存引擎上面。所以，在儲存有保障的前提下，我們可以通過擴充儲存引擎來擴充Kylin的輸送量。

　　Apache Kylin 1.5新特性

　　1.可擴充架構

　　

　　Kylin採用的是一個可擴充的架構。使用者的資料首先是落在HIVE裡面，然後根據META DATA定義的CUBE描述，進行離線CUBE構建，構建完成的CUBE結果存放在HBase裡面。當查詢從頂部過來的時候，不管是SQL介面或者是Rest API介面，查詢引擎都會把這個查詢引導到構建好的CUBE當中去返回結果，不需要再去查原本的HIVE資料，這種方式大大的提高了系統效能。

　　

　　所謂可擴充的架構是指把Kylin三個依賴的介面抽象出來，從而在一定程度上替換它們。Kylin的三大依賴分別是HIVE Source、MapReduce分散式運算引擎以及儲存引擎HBase，它們都是通過原資料來驅動的，即需要在CUBE原資料上聲明資料來源、構建引擎和儲存系統。通過工廠類初始化三個依賴，它們之間是沒有關聯的，彼此不能夠瞭解對方的存在，所以也不能一起工作。後面用個適配器的模式，想象下面MapReduce Engine作為一個主板，它有一個輸入槽和一個輸出槽，分別用來串連左側DataSource和右側的Storage。從HIVE和HBase分別產生構造出一個適配器組件，把它們插在主板上以後，這三個組件就聯通了，資料就可以從左側流到右側，完成實現整個CUBE構建的過程。

　　

　　有了上述的基礎，我們就可以在Kylin系統上面來嘗試不一樣的構建引擎、資料來源以及儲存引擎。我們曾經嘗試將Spark作為Kylin CUBE的構建引擎，但是從實驗結果來看，Spark引擎暫時並沒有帶來特別高的效能提升。目前，資料來源除了HIVE以外，現在也可以串連Spark和Kafka。儲存引擎是大家最為關注的，一開始，選用HBase作為Kylin的儲存引擎時，大家都很不解，也有很多人表示為什麼不試一下Kudu或者其他的儲存引擎呢，有了這個可擴充架構，大家可以親自來嘗試不同的儲存引擎。

　　

　　整個可擴充架構帶來了很多好處，首先就是自由度，之前Kylin等於是綁死在Hadoop平台上面，依賴HIVE，MapReduce和HBase。有了這個架構以後，就可以嘗試一些不一樣的替代技術。其次是可擴充性，系統可以接受各種資料來源，例如Kafka，也可以接受更好的分散式運算引擎Spark等。第三是靈活度，不一樣的構建演算法適合不一樣的資料集。有了靈活度以後，就可以在整個系統中同時存在很多種不一樣的CUBE構建演算法，使用者可以根據自己資料集的特性來指定當中的某一個。

　　2.Layered Cubing

　　

　　MRv1是一個比較老的CUBE的引擎，採用的是一個非常質樸的CUBE構建演算法。所示是一個分層的CUBE構建的過程，先Group by A、B、C、D四個維度，算完了這個四級維度一層以後，再用四級維度結果來算三級維度一層，依此類推，分別算出二級和一級維度結果。

　　這種分層模式可以利用MapReduce的 shuffling 和 merge sort 做完了很多Aggregation，從而減少開發量。但同時也帶來了一些問題，因為Aggregation都發生在Reduce端，Map端是直接把原資料給扔在網路上，然後靠MapReduce的shuffling讓資料匯總到Reduce端，所以這就帶來了很大的網路開銷，而網路又偏偏是大多數Hadoop系統的瓶頸。相關資料顯示了這樣的Layered Cubing給網路的壓力相當於一百個CUBE的大小，也就是說如果CUBE有10T的話，那麼網路的壓力可能就是一千個T。

　　3.Fast Cubing

　　

　　如何解決這個瓶頸問題，下面為大家分享一個新演算法Fast Cubing，它是逆向思考，既然資料在Reduce端做彙總會有很多網路壓力，那麼可不可以把彙總放到Map端來做，然後把彙總完的結果通過網路進行傳輸，在Reduce端做最終的彙總，這樣的話，Reduce端收到的資料就會變少，網路壓力就會變輕。目前比較經典的多維分析多是用記憶體來做多維計算，我們採用類似的技術在Map端分配比較大的記憶體，用比較多的CPU做In-mem cubing，這樣做的效果類似於Layered發生在Map端。這些過程完成之後得到的是已經彙總過的資料，再通過網路分發到Reduce端做最終的彙總。這種方式的缺點是演算法較為複雜，開發和維護比較困難，但是可以減輕網路壓力。

　　我們把兩個演算法放到實際的生產環境當中去比較，發現其實並不總是Fast Cubing會更快。我們期望Map端的預先彙總可以減少網路shuffling，但其實不一定是這樣,因為這取決於資料分布。例如我們的期望結果是李揚在十月一號一共買了多少東西，消費總金額是多少，那麼這取決於消費記錄是只出現在一個data splits裡面還是出現在所有的Map的data splits裡面。如果記錄只出現在一個Map上，那麼彙總完的結果不需要去和其他的Map做第二次的彙總，網路分發比較快。但是如果不幸，交易記錄被均勻分散到了所有的Map上，那麼還是要通過網路分發很多次，然後在Reduce再做第二次的彙總，這樣的話相比前面的Layered Cubing沒有多少的改進。

　　如果Map的data splits是比較獨特，每個Map會產生不同的CUBE資料，然後分發也不會重複，那麼Fast Cubing確實會減少網路的傳輸。但是反過來，如果每個Map的資料都有雷同，那麼就還是會造成網路的壓力，所以在MRv2裡面最後搭載的是一個混合演算法。先對資料做採樣，根據資料樣本來判斷這個資料集在Map上面的分配是獨特的還是有重複，然後根據這樣的特性來選擇採用Layered Cubing 還是Fast Cubing。我們通過在500個不一樣的生產環境中的測試發現這種混合演算法要比原來的MRv1快1.5倍。

　　4.Parallel Scan

　　

　　並行掃描是一個十分直觀的改進。在之前的Kylin版本裡面資料彙總完以後密度非常高，而且因為資料彙總過，返回集很小，不需要掃描太大的資料集就能夠返回SQL查詢的結果。但是對於一些比較複雜或者本身比較慢的查詢，儘管經過了彙總，但是資料還是有百萬、千萬條，那麼在運行時候還是要掃描很多資料，這時候簡單的串列掃描顯然就不適合了。如果調整一下資料的儲存結構，做一些分區。通過掃描物化視圖來產生查詢結果，把存在一個結點上的物化視圖均勻的分散在多個結點上，那麼串列掃描就變成了並行掃描。

　　這個改進可以使慢的查詢速度提升五到十倍左右，不過從實際情況來看提升並沒有那麼多，因為原本大多數Kylin的查詢已經比較快了，掃描資料本來就不多。通過對一萬條左右生產狀態查詢結果的比較，我們發現，引入並行掃描的技術之後，速度大概會提升兩倍左右。

　　5.近即時

　　

　　Apache Kylin 1.5的另一個特性就是近即時的構建，它是延續之前的增量構建。Kylin和很多大資料系統一樣，在對資料做預先處理的時候，會對資料做一個增量的預先處理，即不是把過去所有的資料每天都算一遍，而是每天只計算今天的資料，再去和曆史資料做匹配。所以首先要把整個資料集按照時間軸來做分割，時間距離最遠的資料會比較大塊，可能是按年的，中間的可能是按月，最小的一個資料集是今天的。如果要做到近即時的話，只需要把每天增量構建的時間力度進一步的切小，可以從天縮小到小時，小時縮小到分鐘，按照這個思路就可以很順暢的完成近即時的CUBE構建。

　　

　　這是我們在1.5裡面嘗試的一個案例，其中資料來源來自Kafka的Source，演算法使用Fast Cubing 。這樣的搭配看起來很完美，其實不然，它會產生很多的CUBE片段，例如今天的五分鐘就是一個獨立的資料集，它會產生一個獨立的CUBE片段。當這個片段越來越多的時候，查詢效能就會下降，一個查詢命令需要命中很多個片段，每一個都要執行儲存層的一次Scan的操作。

　　

　　解決的方法也很簡單，那就是合并CUBE片段，但是這個合并是自動的常態，不需人為手工來觸發。新版本裡使用者可以配置自動合并，把五分鐘的片段合并成半小時，半小時合并到四小時，四小時合并到一天，天合并到周，周合并到月。

　　

　　如果五分鐘的近即時仍然不滿足需求的話，可以把他近化成一個Lambda架構，即在CUBE的儲存之外再配上一個即時的記憶體儲存系統來記錄最後五分鐘的資料。CUBE五分鐘近即時離真正的即時就差五分鐘的資料，把這些資料放在記憶體裡面，用一個混合的查詢介面來同時擊中記憶體引擎和CUBE儲存，那麼匯總的結果就是一個真實實施的結果集了。但是，遺憾的是目前這個想法還未實現。

　　

　　在eBay公布的使用案例裡面有一個Kylin新版本近即時CUBE構建的案例——SEO Dashboard，它是對查詢引擎匯入的使用者流量進行監控。即時監控從Google或者雅虎進來的消費者的記錄，即時監控流量起伏，一旦發現使用者流量在五分鐘內有抖動的話，立即採取相應的措施，從而保證eBay的交易量營收的穩定。

　　6.使用者自訂彙總類型

　　

　　1.5的另外一個新功能是User Defined Aggregation Types，即使用者自訂彙總類型，以前Kylin有HyperLogLog(近似的Count Distinct演算法)。在這個基礎上面，新版本又加入了TopN以及社區貢獻的基於Big Map的精確Count Distinct和儲存最底層未經處理資料的記錄Raw Records。使用者可以實現抽象介面擴充自己想要的彙總函式。例如，通過它來彙總很多使用者的事件，提取出使用者的訪問模型，或者做一個很多點樣本的一個聚類，也可以把他預計算好，存成一個彙總的資料類型，所以這個自訂的函數可以擴充到很多領域。

　　

　　TopN用的是一個很經典的演算法，叫SpaceSaving，在很多的串流裡面都有用到。我們把TopN介入到Kylin裡面，定義成一個自訂的彙總函式。一般的SpaceSaving是一個單線程的演算法，但是Kylin採用的是並行演算法。

　　使用者TopN的查詢，例如抓取100個資料，寫成SQL語句如所示。而Kylin會自動適配這樣的SQL來直接使用預彙總好的結果，所以在運行時候Kylin只是把預先算好的一千個，一萬個item直接返回就好了，這當中幾乎就沒有線上計算，速度就會很快。

　　7.分析工具的整合

　　

　　在新版本裡面Kylin也增加了ODBC的一些介面，主要是實現了對Tableau 9的整合，以及和MS Excel、MS Power BI的整合。

　　

　　Zeppelin 的整合模組也已經共用在Zeppelin 開源社區，大家可以在Zeppelin 最新的發布版裡面找到，另外，直接從Zeppelin 裡面也可以調用Kylin的資料。

　　總結

　　

　　總的來說，Apache Kylin 1.5有以下幾個新亮點：1.可擴充的架構，這個新的架構等於是開啟了Kylin對於其他的可替換技術的一個大門，我們可以選擇除了MapReduce之外的其他並行計算引擎，比如Spark，也可以選擇不一樣的資料來源，甚至不一樣的storage。這樣可以保證Kylin可以和其他的並行計算、大資料技術一起來演化而不是鎖死在某個平台上面。2.新的CUBE引擎，因為引入了一個新的Fast Cubing的演算法，速度提升大概達到原來的1.5倍左右，3.並行掃描，儲存結構的改良使查詢的速度提升了大約兩倍。4.近即時分析，儘管還在產品測試的階段，但是，大家可以來社區使用，發現問題可以和我們及時溝通。5.使用者自訂彙總類型，這個部分在未來應該有很大的發展空間。6.整合了更多的分析工具。

　　以上就是我想和大家分享的內容，Kylin是個開源產品，所以歡迎大家有興趣的來使用，並且跟我們在社區上面互動，有任何問題我們社區都是很樂意來協助大家解決。

Apache Kylin巨量資料分析平台的演化