最近我的團(tuán)隊將報表計算引擎從阿里的OLAP分析中間價遷移到了kylin上，解決了非常多的問題，將一些我們的解決方案分享出來，希望對讀者或者在用kylin的人有所幫助。

一、 之前現(xiàn)狀和問題

之前我們系統(tǒng)的報表都是基于阿里云的相關(guān)組件開發(fā)的，業(yè)務(wù)系統(tǒng)在業(yè)務(wù)代碼中將數(shù)據(jù)同步到消息隊列中，然后阿里OLAP分析中間件再從消息隊列同步數(shù)據(jù)，再基于OLAP分析中間價提供的api開發(fā)查詢邏輯，前端還要開發(fā)報表展示的代碼。這種方式上線以后，隨著數(shù)據(jù)量的不斷增長暴露出了很多缺陷。

1. 經(jīng)常會出現(xiàn)消息丟失的情況，或者系統(tǒng)變慢的情況。

2. 由于購買的阿里云的服務(wù)，相關(guān)中間件對我們來說一直是一個黑盒，問題很不好定位和解決，而且很多問題的解決依賴于阿里云，響應(yīng)時效不是很及時，長此以來積累了大量的報表問題，客戶抱怨聲不斷。

3. 開發(fā)工作量龐大，產(chǎn)品人員設(shè)計好一張報表以后，要上線要苦等一個多月的開發(fā)時間，而且遇到問題還無法上線。

基于以上問題我們覺得再繼續(xù)用阿里的OLAP中間件作為我們的報表計算引擎，后續(xù)問題會越來越多。因此我們嘗試使用新的報表引擎，這個報表引擎對我們一定不是一個黑盒。

二、 報表計算引擎的選擇(kylin)

基于以上幾個問題，在對tidb，druid，kylin，mdrill等各種開源系統(tǒng)進(jìn)行調(diào)研以后，最終選擇了kylin作為我們的報表計算引擎，一方面是sql支持度相對來說比其他系統(tǒng)好比如精確distinct功能，一方面是和hadoop的幾個組件集成得非常好，tidb和已有hadoop組件集成得不大好，需要重新搭建集群代價很大。還有就是基于java開發(fā)很符合團(tuán)隊的技能特點(diǎn)，可以根據(jù)業(yè)務(wù)特點(diǎn)定制我們自己的版本。

三、 數(shù)據(jù)分鐘級延遲問題解決(canal+flume+kafka)

選好了kylin這個報表計算引擎后，還需要解決的就是我們報表計算的數(shù)據(jù)延遲最大也要到分鐘級別，這個可以通過kylin的kafka數(shù)據(jù)源來實現(xiàn)，配置方式見下面的鏈接。

http://kylin.apache.org/cn/docs/tutorial/cube_streaming.html

但是使用kafka還有一個問題就是業(yè)務(wù)系統(tǒng)的數(shù)據(jù)怎么實時的傳輸?shù)絢afka呢，之前都是在業(yè)務(wù)系統(tǒng)中編寫數(shù)據(jù)發(fā)送邏輯到消息隊列中，這種方式和業(yè)務(wù)系統(tǒng)耦合非常大，隨便改點(diǎn)邏輯都需要依賴于業(yè)務(wù)系統(tǒng)上版本周期很長，溝通成本很大。因此我們采取了用阿里巴巴開源的canal抓取mysql binlog的方式，實時的去抓取mysql的增刪改查數(shù)據(jù)，這種方式要開啟mysql的binlog。Canal項目的主頁：

https://github.com/alibaba/canal

有了canal抓取并解析binlog以后，還有一個問題要解決的是怎么讓canal抓取到的數(shù)據(jù)可靠的傳輸?shù)絢afka中，基于canal和kafka的api自己開發(fā)的方式，成本很大，而且要考慮高可用，容錯，擴(kuò)展性等問題，再者我們的時間和開發(fā)資源也非常有限，因此我們基于flume的接口開發(fā)了一個canal source，充分利用flume的靈活性，擴(kuò)展性，高可用，負(fù)載均衡和容錯等特性，同時也可以和已有的source，channel和sink組件隨意組合。

這樣通過canal+flume+kafka和kylin的streaming cube特性，我們就很好的解決了數(shù)據(jù)分鐘級別的延遲問題。

四、 數(shù)據(jù)實時更新和刪除問題

下一個要解決的問題就是數(shù)據(jù)的更新和刪除的問題，這個我們是基于業(yè)務(wù)邏輯來解決的，當(dāng)然我們在實現(xiàn)上會考慮好業(yè)務(wù)場景的通用性，每次更新和刪除數(shù)據(jù)我們都不會去修改原來的數(shù)據(jù)，而是往kafka中插入新的數(shù)據(jù)并標(biāo)記這條數(shù)據(jù)是刪除，還是更新，并記錄前后值的變化，同時在接入層面盡可能對數(shù)據(jù)進(jìn)行去重處理，降低后續(xù)cube構(gòu)建和sql編寫的難度。

由于我們在數(shù)據(jù)層面和原來的變化了，因此我們還需要在sql層面進(jìn)行改寫，當(dāng)然改寫后的sql肯定要利用上kylin的預(yù)計算特性，否則查詢速度很慢。

在解決數(shù)據(jù)實時更新和刪除問題上，耗費(fèi)了我們大量的時間，前后也討論過很多種方案，而且實現(xiàn)起來需要對kylin的預(yù)計算特性有深入的了解，對維度設(shè)計要利用kylin的特性充分的進(jìn)行精簡，否則會走彎路。

下面是我們的model和cube界面：

五、 并發(fā)查詢問題

接下來就是并發(fā)查詢的問題了，由于kylin本身就帶有cache特性，負(fù)載均衡而且采用的是預(yù)計算模式，因此應(yīng)付并發(fā)上很好辦，負(fù)載均衡這一塊開始準(zhǔn)備用nginx做負(fù)載均衡，后來覺得自己維護(hù)還是很麻煩，而且我們其他系統(tǒng)已經(jīng)在使用阿里的SLB做負(fù)載均衡了，因此最終我們還是用SLB來做負(fù)載均衡。

六、 使用superset報表開發(fā)方式

最后要解決的一個問題就是開發(fā)效率的問題了，之前我們的報表開發(fā)后臺首先要手工編寫大量的sql，然后使用spring和mybatis編寫大量的業(yè)務(wù)邏輯，并通過微服務(wù)的方式暴露接口，然后前端再根據(jù)接口，編寫前端展示代碼，而且移動端，電腦端都要寫一套。

這種方式開發(fā)周期長，耗費(fèi)人力大，而且工作挑戰(zhàn)不大也比較枯燥，大家都很痛苦，產(chǎn)品等得痛苦，開發(fā)開發(fā)得痛苦。

因此我們調(diào)研了幾個前端的工具，后來發(fā)現(xiàn)了airbnb開源的superset這個好東西，操作簡單，圖表美觀，而且單表不支持的情況可以通過自定義sql來支持。最關(guān)鍵的是kylin對它進(jìn)行了很好的集成，鏈接如下：

http://kylin.apache.org/blog/2018/01/01/kylin-and-superset/

還有一個關(guān)鍵點(diǎn)是superset的圖表可以通過iframe嵌入到網(wǎng)頁中數(shù)據(jù)不是靜態(tài)的而是隨時更新的，還支持在電腦端和手機(jī)端展示，對數(shù)據(jù)和圖表的權(quán)限控制也做得非常到位。基本滿足了自助開發(fā)，然后嵌入到頁面中展示的要求，可以大大節(jié)省我們的報表開發(fā)周期和開發(fā)工作量，甚至可以做到讓產(chǎn)品自助拖拽式開發(fā)。

Superset Kylin數(shù)據(jù)源配置：

圖表開發(fā)：

Iframe嵌入：

七、 最終的架構(gòu)

八、 一些實現(xiàn)細(xì)節(jié)

1. canal主備切換的時候數(shù)據(jù)會重復(fù)，這個問題需要在接入層面或者在canal層面注意，我們是在接入層面監(jiān)測到切換后對最近數(shù)據(jù)進(jìn)行實時去重（自己編寫flume source帶去重邏輯，會緩存一個可配置時間段的數(shù)據(jù)，因為canal切換很快所以不需要緩存很長時間，而且用storm里面的timecachmap不會影響到性能）。

2. kylin不支持hadoop和habse的高版本，之前我嘗試把我們的集群升級到了hdp3.0版本（hive3.1，hadoop3.0，hbase2.1），也嘗試修改kylin源碼來適配高版本，但是改到后面發(fā)現(xiàn)工作量非常大，時間來不及只好又把集群回退到了hdp2.6.4版本，后面把kylin修改好以后再升級集群。

3. 查詢一定要利用kylin的預(yù)計算特性否則時間會很長，尤其是子查詢很可能會導(dǎo)致利用不上預(yù)計算特性。

4. 設(shè)計cube的時候維度一定要盡量精簡。

5. Kylin的distinct有精確distinct和非精確的，精確的計算要占用非常大的內(nèi)存。

6. steaming表是不能和lookup表進(jìn)行join的。

7. superset支持iframe嵌入要修改一些配置權(quán)限配置和跨站訪問配置，否則不能展示或者要登錄。

跨站訪問修改這個配置：

HTTP_HEADERS = {'X-Frame-Options': ' '}

免登錄訪問加入以下配置：

PUBLIC_ROLE_LIKE_GAMMA = True

Public 角色的permissions里把以下三個加上

can explore on Superset
can explore json on Superset
all database access on all_database_access

。

8.負(fù)載均衡模式下，kylinserver session要共享，安全驗證用默認(rèn)的會有多線程更新沖突，要修改。

九、 寫在后面

時間倉促，整體方案寫出來了，具體細(xì)節(jié)和遇到的問題寫得不夠詳細(xì)有需要進(jìn)一步了解的可以留言交流。后續(xù)報表這一塊我們會進(jìn)一步做到自定義報表到時的維度挑戰(zhàn)是一個更大的問題，肯定需要進(jìn)一步的優(yōu)化當(dāng)前方案。

總結(jié)

以上是生活随笔為你收集整理的锐浪报表数据源access_kylin+SuperSet实现实时大数据报表的快速开发的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。