簡介：在規劃中，Quick BI制定了產品競爭力建設的三大方向，包括Quick（快）能力、移動端能力和集成能力。針對其中的產品“報表查看打開慢”“報表開發數據同步慢”等性問題開展專項戰役——Quick戰役，以實現展現快、計算快，為使用者提供順滑體驗為目標。

“Quick”是產品始終追求的目標

Quick BI數據可視化分析平臺，在2021年二次入選了Gartner ABI魔力象限，這是對產品本身能力強有力的認證。在不斷夯實B I的可視化體驗和權限管控能力之外，推進Quick BI的全場景數據消費能力，讓數據在企業內最大限度的流轉起來。

在規劃中，Quick BI制定了產品競爭力建設的三大方向，包括Quick（快）能力、移動端能力和集成能力。針對其中的產品“報表查看打開慢”“報表開發數據同步慢”等性問題開展專項戰役——Quick戰役，以實現展現快、計算快，為使用者提供順滑體驗為目標。

雙引擎成就Quick全新體驗

無論是開發者還是閱覽者，若想要在使用Quick BI的過程中獲得流暢快速的體驗，可能在這兩個方面進行優化：

在數據報表開發的過程中，大量級數據需要在一定范圍的時間內響應，即計算要快；

面對報表的查看者，首屏打開和下拉加載的時間需要在一定范圍內完成，即展現要快。

Quick BI推出計算引擎和渲染引擎，以雙引擎的方式為產品全力加速。

1、計算引擎（Quick引擎）

包含原有直連模式，新增加速模式、抽取模式、智能緩存模式，用戶按照不同場景的不同需求，通過配置開關進行模式的選擇。在數據集開發和數據作品制作的過程中獲得加速體驗，可以有效提升用戶報表的數據查詢速度，減少用戶的數據庫查詢壓力。

實時加速

基于 MPP 內存計算引擎，查詢中實時從數據庫（調/讀）取數據，并在計算引擎的內存中進行計算，有效提升用戶數據計算的性能，適用于對數據時效有高要求的情況。

抽取模式

把數據庫或數倉的數據抽取到Quick引擎的高性能列式存儲引擎中，支持全量模式和增量模式，分析計算負載直接在Quick BI引擎中進行，充分利用Quick引擎性能的同時，降低用戶數倉的負擔，適用于沒有獨立數倉或數倉負載過重的情況。

智能緩存

提供的2種緩存模式都可以直接返回結果，提升用戶查詢速度，減少數據庫訪問次數。

數據集緩存

將用戶已經查詢過的結果緩存在 Quick BI 高速緩存組件內，一段時間內完全一致的查詢可以直接返回查詢結果。

智能預計算

算法根據用戶的歷史查詢記錄，對數據集的查詢進行預聚合，提前計算出用戶所需的結果，保存在高性能存儲中。一旦用戶查詢命中，則直接返回結果。

2、渲染引擎

負責取得肉眼可見頁面的內容，包括圖像、圖表等，并進行數據信息整理，以及計算網頁的顯示方式，然后輸出并展現。由于BI場景的報表（儀表板、電子表格、門戶等）內容相當復雜，渲染引擎的加速可以非常直接的影響Quick BI報表的打開速度，優化用戶的報表閱覽體驗。渲染引擎的加速動作無需進行任何配置，無聲地服務整個分析流程。

渲染引擎進行了如下整體升級：

• 資源（js/css/ajax等）加載優化：包括預加載、按需加載、任務調度、TreeShaking等
• 前端計算&執行優化：數據流節流、懶數據策略、mutable改造、深克隆等計算優化等
• 可視化升級：底層可視化統一，桑基圖等大數據量下解析優化、渲染次數收斂等
• 移動端升級：包體積優化（壓縮前20.6M減少至5.6M）、圖表預加載、資源本地化緩存等
• 查詢鏈路優化：支持 MaxCompute 加速查詢、登錄層優化、防止配置查詢緩存穿透、緩存優化等
• 性能工具升級：SQL診斷支持 MaxCompute 數據源，并支持 SQL 診斷工具的國際化等

利用五種機制整體提升渲染引擎作業效果

任務調度機制

支持在各段加載和執行流程中利用組件或函數控制CPU時間和網絡占用優先級，從而將首屏內容的展示時間點縮短至少了30%。

截流渲染機制

支持Redux類數據流體系，以配置化方式控制單位時間組件渲染次數，組件平均渲染次數減少90%以上。

按需計算機制

按需加載和執行JS邏輯組件及其資源，利用LazyObject思路（即：使用時初始化執行，而非定義時）進行按需調用，LazyCache思路（即：命中時計算和緩存，而非實時）進行數據流模型計算，節省約30%的CPU時間以及40%的網絡占用。

預加載機制

通過將原本串行依賴的流程邏輯按不同時機并行（如：當頁面拉取JS資源時同時拉取后端數據，在空閑時預加載下一屏內容），根據歷史使用習慣預先加載后續可能訪問的內容，達到瞬時查看的效果。

資源本地化緩存機制

將js等資源本地化的形式，加上根據不同設備（移動端等）的資源管理策略，有效解決系統內存釋放導致的緩存失效，弱網環境導致的資源加載緩慢等問題。

經過一系列核心能力的升級和特定場景的針對性優化，操作平均FPS（每秒傳輸幀數）可達55左右，較復雜報表下，首屏加載時間也從最初18秒降至3秒以內（中等簡單報表2秒內），結合Quick引擎，還可以支持10億級數據量的報表3秒內展現。

典型場景下的性能體驗全面提升

1、數據開發視角的場景方案

（1）報表展示的數據在一定時間內固定不變

有些客戶對數據需要每天進行一次匯總，并通過 Quick BI 的可視化圖表以日報形式展示出來。這些展示的數據在下一次匯總之前都不會發生變化，同時這些匯總數據比較固定，不需要閱覽報表的人主動更改查詢條件。

如是場景，推薦開啟數據集上的緩存功能。用戶可以自行設置緩存的有效期，在有效期內，相同的查詢會命中緩存，直接將該周期內第一次查詢的結果毫秒級返回。以上述場景為例，用戶可以開啟 12 小時的緩存，這樣日報只會在第一次打開時進行數據查詢，之后一整天的時間，一旦客戶點擊打開，報表就會立刻展現。

（2）報表數據存在較多變化，對非實時數據進行分析

以大促為例，商家在活動結束后，對大促期間的銷量、營業額以及營銷投放效果進行復盤。數據分析包含很多維度，比如類目、地區、部門等等。商家的分析師或者決策者在查看報表時，往往會對維度進行調整、變更、鉆取，來獲得更加深入的洞察。這個場景下用戶數據查詢的動作多變，上述的緩存策略往往很難命中。

此時，可以在數據集的 Quick 引擎中開啟抽取加速。抽取加速默認全表加速，允許用戶同步T-1 的數據到 Quick 引擎高性能存儲及分析模塊中，后續的查詢和計算會直接在 Quick 引擎中進行，減少用戶數據庫的性能壓力。抽取加速可以做到億級數據，亞秒級響應。

與此同時還可以開啟智能預計算模式， 會對用戶的查詢歷史進行分析， 提前對可能的查詢進行預聚合。用戶的查詢如果命中，則會直接返回聚合結果。

（3）用戶數據源查詢慢，但對數據實時性有要求

有的用戶，數倉里的數據每天都在實時變化。以倉儲管理為例，倉庫里每天貨物的進出是動態的，這些數據會實時落到數據庫里，而客戶希望能夠通過 Quick BI 的報表，對這些動態數據進行分析。顯然，上面提到的緩存方案以及抽取加速都無法達成這個目的。

對于這類用戶來說，他們可以在數據集的 Quick 引擎里開啟實時加速， 通過引擎內置的 MPP 內存計算引擎，對數據進行實時的內存計算，從而達到加速的目的。

開啟了 Quick 引擎的實時加速，可以做到億級數據，秒級響應。

（4）用戶查詢依賴維度值的獲取

企業如果需要以產品類目為維度，對銷售記錄進行分析。這個時候，就會用到 Quick BI 的查詢控件，以下拉列表的方式對“類目”這個維度的值進行展示和選擇。

以服裝公司為例，共有100 個產品類目，銷售記錄上千萬條。這個時候從完整的銷售記錄里獲取類目值，效率太低。可以使用 Quick BI 提供的維值加速方案， 將類目的維度表配置進維值加速功能，此時100 個類目僅對應 100 行數據，而不再是原來的上千萬條。

再獲取類目下拉列表時，就會直接從維度表中讀取，大大提升下拉列表里維度值的獲取效率。

2、Quick BI閱覽者視角的加速效果

（1）即席分析表格

500W單元格，秒級渲染完畢（60 FPS），操作流暢：

（2）報表首屏打開

基于雙引擎，在1億行數據，20個圖表組件，常規聚合類查詢下進行標準測試，一個標準復雜報表可在2秒內展現：

原文鏈接

本文為阿里云原創內容，未經允許不得轉載。?

總結

以上是生活随笔為你收集整理的双引擎驱动Quick BI十亿数据0.3秒分析，首屏展示时间缩短30%的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。