簡介: 隨着數字化進程的深入,數據應用的價值被越來越多的企業所重視。基於數據進行決策分析是應用價值體現的重要場景,不同行業和體量的公司廣泛依賴BI產品制作報表、儀表板和數據門戶,以此進行決策分析。
在利用BI產品進行數據分析過程中,數據處理“慢”會為業務帶來很多的困擾,可以想象一下:
- 給老板看的報表加載展示非常慢,有的時候還會崩掉,本想做好向上匯報,但卻給老板帶來了糟糕的體驗~
- 分析師或業務同學,做數據探索式分析,拖拽一個指標需要幾分鍾才能看到結果,嚴重影響工作效率,打斷分析思路~
“慢”雖然只是一種難以精確定義的體感,但想要解決以上問題,就需要BI產品擁有很強的大數據處理架構和能力,可以橫向擴展支持不斷增長的數據量和計算任務。
Quick BI:阿里雲飛天操作系統上的雲BI
Quick BI產品是在阿里雲飛天操作系統上打造的雲BI軟件,支持SAAS模式和私有化部署,定位多場景、多端、多行業的消費式BI,本篇為大家詳細介紹產品內核Quick引擎。
Quick BI構建了自己的計算內核Quick引擎,托管在阿里雲上的SAAS服務實測數據十億級數據在0.5秒以內完成聚合分析,另外由於依托阿里雲,計算資源支持橫向擴展,通過增加服務器還可以提供更強大的數據分析計算能力。
Quick引擎:多模式BI計算引擎
Quick引擎作為Quick BI的計算底座,是一個多模式的BI計算引擎,支持數據庫直接連接、抽取加速、實時加速、查詢緩存、維值加速等多種計算模式,為不同用戶提供最適合自身場景的高效計算方案。
Quick引擎架構在數據源和數據集之間,用來處理上層數據作品發送到數據集最終下放到數據源上的查詢,在技術實現上Quick引擎分為三條鏈路,數據庫直連、數據庫實時加速、數據庫抽取,在這三條鏈路進行了技術層抽象。
從用戶使用視角來看,我們提供如下5種計算模式:
(1)直連模式:計算負載直接跑在連接到BI產品的數據庫或數倉上,支持幾十種數據源,所有版本用戶都可使用,非常適用於底層計算資源滿足查詢負載的場景;
(2)抽取加速:把客戶數據庫或數倉的數據抽取到Quick引擎的高性能列式存儲引擎中,支持全量模式和增量模式,分析計算負載直接跑在Quick BI引擎中,充分利用Quick引擎性能的同時,減少客戶數倉的負擔,專業版客戶可用,非常適用於企業沒有獨立數倉或數倉負載過重的情況;
(3)實時加速:基於阿里雲DLA(Data Lake Analysis)內存計算引擎,查詢時實時從客戶數據庫取數據,中間用DLA內存引擎加速計算,專業版客戶可用,目前支持阿里雲Max Compute數倉,非常適合Max Compute數倉實時分析,更多數據庫支持開通中;
(4)查詢緩存:所有版本用戶可用,應用端報表、儀表板在訪問時臨時查詢結果被緩存下來,在配置的緩存有效時間內,接下來其他用戶相同的查詢直接取緩存結果,加快返回速度同時避免重復計算的資源消耗,非常適合應用端是重復查詢較多的場景,比如可視化展示類;
(5)維值加速:所有版本用戶可用,基於直連模式和維表配置實現,通過配置維值加速使得高頻且耗時的維度字段查詢計算直接在數據庫維表上進行,而不是在原始的明細表上進行,比如即席分析和查詢控件的維值查詢,在這類場景下相比不進行維值加速可快速返回結果且節省計算資源;
Quick引擎 - 使用指南
在正式開始介紹每種引擎具體用法時,先結合每種引擎特點給出一個場景使用指南,方便用戶在不同場景下選擇最合適的引擎。
(1)數據集默認采用直連模式,如果查詢性能良好,則可不進行額外配置,如果無法滿足要求,則進行以下判斷
(2)數據集主要被用在儀表板、報表中,偏固定數據展示類的,沒有被很多查詢控件控制
- 實效性要求不是非常高,很適合配緩存,基本可以解決問題了(可能80%以上可以解決)
- 實效性要求不是非常高,如果配了緩存還不行,比如某個數據集被做了很多報表,第一次緩存查詢就吃不消,MySQL類非OLAP數據庫建議用抽取加速,ADB類的OLAP數據庫,建議首先優化下數據建模(比如是不是大表join大表),其次建議采用抽取加速分擔些負載
- 實效性要求很高,每次看,都想看最新數據,ODPS數據源可以用DLA實時加速
(3)數據集主要被用在即席分析、電子表格分析這類偏個性分析查詢中,或者有非常多查詢控件的儀表板報表中,配緩存意義不是很大(有點作用),建議:
- 底層數據庫不是OLAP,比如MySQL,運行很慢,首先建議采用抽取加速,其次建議優化數據建模
- 底層數據庫是OLAP,比如ADB,運行很慢,建議首先優化下數據建模(比如是不是大表join大表),其次建議采用抽取加速分擔些負載
- 底層數據庫是ODPS,運行很慢,如果實效性要求高,建議DLA實時加速,實效性要求不高,建議抽取加速
(4)數據集維度字段被頻繁用於查詢控件或即席分析,推薦為該字段配置維值加速
Quick引擎 - 直連模式
直連模式是Quick引擎查詢的默認模式,所有的查詢會發送給底層數據庫或數倉執行,Quick BI直連模式支持幾十種雲和自建數據庫。
在數據集頁面點擊“新建數據集”,選擇已配置的數據源,左側面板會展示該數據源里的所有表,拖入一張或多張表到面板中,即可在數據預覽區域進行字段配置,配置完成后保存數據集,方可進行后續分析。數據集保存后,后續所建的分析查詢默認直連模式。
Quick引擎 - 抽取加速
當直連模式查詢過多或者數據量過大時,會導致底層數據庫負載過重查詢變慢,上層儀表表展示和分析就會變慢,出現文章開頭所講的困擾,此時可以考慮Quick引擎的抽取加速。
抽取加速是專業版特有功能,目前覆蓋MySQL、ADB for MySQL和MaxCompute三種數據源,支持全量抽取和增量抽取數據到Quick引擎的高性能列式存儲分析型數據庫中,抽取后的數據查詢直接在列式分析數據庫中完成而無需發到客戶數據庫上,提升數據查詢性能,同時減少客戶數據庫負載。
點擊數據集菜單,選擇“加速配置”,在第一個 “Quick引擎”Tab點擊開啟引擎,選擇抽取加速:
- 加速時間可選“手動觸發”和“定時加速”,定時加速設置時間后定期觸發抽取任務
- 智能聚合抽取支持“全表加速”、“預計算”、“全表計算+預計算”三種模式,其中全表加速抽取全表數據,預計算基於歷史查詢智能預計算查詢結果,節省抽取空間
- 勾選按日期加速,可以選擇日期字段,每日根據日期字段增量抽取
配置完成后,點擊保存,抽取任務即會自動觸發,抽取完成后,之后的數據查詢將在抽取引擎數據庫中完成。
數據量 |
sum聚合 |
count聚合 |
avg聚合 |
median聚合 |
1億 |
0.043 s |
0.044 s |
0.040 s |
0.061 s |
10億 |
0.3 s |
0.21 s |
0.25 s |
0.35 s |
同時由於Quick BI是依托於阿里雲飛天底座的產品架構,具備橫向擴展的能力,Quick引擎隨着機器數量的增加數據處理能力會不斷增強,理論上具有無限擴展的能力。
Quick引擎 - 實時加速
當直連模式出現性能問題,同時對數據的實效性要求較高,天粒度更新無法滿足要求,而需要小時或分鍾粒度數據更新,由於抽取加速是天粒度數據更新而無法采用,此時可以考慮另一種選擇,采用實時加速來進行高實效數據的查詢加速。
與抽取加速一樣,實時加速也是專業版特有功能,目前支持MaxCompute數據源,基於阿里雲DLA(Data Lake Analysis)內存計算引擎,查詢時把數據實時加載到DLA中進行計算,提升查詢性能,可以把離線型數倉MaxCompute通過實時加速變成在線分析型數倉。
在數據集加速配置頁面,開啟Quick引擎,切換到實時加速,保存即可開啟數據集實時加速模式。
Quick引擎 - 查詢緩存
查詢緩存的原理是應用端報表、儀表板在訪問時臨時查詢結果被緩存下來,在配置的緩存有效時間內,接下來其他用戶相同的查詢直接取緩存結果,命中緩存的查詢可以立即返回結果,沒有命中緩存的查詢會被發到底層數據庫進行查詢,查詢返回后該查詢也會被緩存下來供接下來使用。
結果緩存是一種應用范圍很廣且非常有效的數據查詢加速方式,它適用於所有數據源,對不同版本用戶都可用,對一定時間內存在重復查詢的數據集都可以配置查詢緩存,特別是重復查詢較多的場景,比如儀表板展示類,可以大幅提升查詢性能。
在加速配置頁面,開啟查詢結果緩存,可配置不同緩存時間,表示緩存生效的有效期,如果數據是非小時粒度實效性,建議選擇12小時。
Quick引擎 - 維值加速
在直連查詢中,關於維度值的查詢是比較耗時的,比如商品名稱、客戶名稱、城市名稱等,因為這類查詢在直連模式下需要去底層數據庫做去重聚合操作,要掃描全表數據,所以比較耗時。而在某些場景下,這類查詢操作可能會非常頻繁的出現,比如即席分析的維度值分析和查詢控件的維度值查詢,在這類場景下可以通過配置維值加速提升查詢性能。
在加速配置頁面,開啟維值加速,該數據集是一張訂單明細表,在前端儀表板頁面經常需要基於客戶名稱和產品名稱查詢成交情況,因此把這兩個字段配置維值加速,分別對應上底層數據庫兩張用戶和商品維表的字段,之后維度值的查詢將直接從這兩張維表中取,而無需去明細表做聚合,從而提升查詢速度。
原文鏈接
本文為阿里雲原創內容,未經允許不得轉載。