Quick BI“數據門戶”在企業數據中臺建設中的重要性
企業在數據中臺初步建設完成以后，怎樣讓客戶直觀感受到數據中臺的價值？企業決策者、各部門管理人員、業務運營人員如何通過統一的窗口，快速看到數據中臺提供的數據，并利用這些數據全方位的支持企業發展？
基于Quick BI構建的企業數據門戶，有效的解決了上述問題。
Quick BI“數據門戶”是數據中臺提供給業務人員使用的門戶和窗口，以場景化分析的方式，為企業各類人員和角色，提供統一的可視化服務。作為真正觸達用戶的可視化工具，Quick BI“數據門戶”在企業數據中臺建設中的重要性尤為突出。

為什么要對Quick BI進行優化？
企業數據中臺建設完成后，數據中臺作為企業統一數據的“供給方”，越來越多的部門和業務人員會成為“需求方”，希望通過數據中臺的數據支持業務。隨著“需求方”越來越多，并發要求越來越高，作為統一入口的Quick BI數據門戶的壓力隨之越來越大。因此，隨著數據中臺在企業內推廣和使用的逐步深入，需要對Quick BI進行全面優化，以滿足不斷增長的業務需要。

本文旨在說明的問題本篇文章基于實際客戶案例中Quick BI性能優化的實踐探索，總結提出數據中臺建設中的測試方法和性能優化解決方案，拋磚引玉，供其他類似項目參考。

典型的數據中臺技術架構

基于阿里云數據中臺整體解決方案，對數據中臺技術實現進行選型及設計，典型的數據中臺技術架構如下圖所示，整個技術架構選型包含五個層次：業務數據源存儲技術、數據源接入技術、數據中臺數據存儲與計算技術、數據服務及數據應用技術。

數據存儲計算，數據中臺中離線數據存儲和計算采用MaxCompute離線計算引擎；實時計算部分采用阿里云StreamCompute流式計算技術實現；數據研發與管理采用Dataphin智能數據構建與管理大數據研發平臺。

數據服務層，主要分API接口和數據庫服務兩種方式，一般普通查詢使用RDS，多維分析使用ADB，搜索服務使用ElasticSearch，在線接口使用OneService服務。

數據應用層，使用阿里云智能報表工具Quick BI實現各種定制數據報表分析需求；以及基于阿里云產品技術體系實現客戶個性化數據應用需求。其中基于Quick BI產品的數據中臺門戶如圖中橙色部分所示。

Quick BI壓測方法

1、壓測目標
Quick BI數據中臺門戶壓測目標主要圍繞著兩類發布變更和用戶體驗反饋，提前做好：性能卡點、性能調優工作，滿足日常客戶報表的極致體驗、以及性能特殊訴求。

兩個卡點：
1）壓測，保障上線內容無性能問題以及隱患
2）新的報表上線時，需要對新上線報表進行簡單壓測，避免單一報表導致整個系統性能出現瓶頸。

一個檢查點：
當客戶直觀使用感受數據中臺門戶報表顯示過慢時，對系統整體壓測，檢查性能瓶頸點進行優化。
從而保障數據中臺門戶滿足客戶日常報表可視化性能需求。

2、壓測策略

1）壓測環境
Quick BI數據中臺門戶通常在客戶現場只有正式環境，Quick BI門戶頁面壓測接口全為查詢類請求，壓測執行不會對線上數據造成污染。當然為了避免影響線上用戶，會在用戶低峰期如凌晨節點執行壓測。大部分項目數據門戶環境如下：

2）壓測實施

具體實施壓測時，主要流程如下：

（1）獲取客戶需求，如客戶需求的可能是要支持100個并發，返回時間不超過3s、日常峰值用戶多少PV等。
（2）根據客戶需求結合線上PV訪問量預估，計算出經驗qps和極限qps。
（3）前期準備，需要跟客戶溝通壓測時間點以及壓測方案，同時壓測期間協調產品方跟進，觀察產品在壓測時是否觸發異常。
（4）壓測工具準備
（5）壓測數據準備
QuickBI門戶涉及多個頁面，一個頁面包括多個接口請求，如果通過手工抓接口錄API入參的方式工作量極大，而且接口入參數據時效不高、容易出錯。因此需要一種實時頁面錄制請求的方式實現壓測數據快速準備。

3、壓測方式
通常數據中臺Quick BI門戶的性能瓶頸是在提供數據服務的數據庫，因此在進行壓測時，我們主要通過區分不同數據源類型的報表頁面，進行壓測，如下表所示:
下表所示:

（1）摸高測試
以最初始的qps開始施加壓力，觀察系統個性指標和業務指標，穩定沒問題后就往上調高qps并發數，依次循環，最后達到目標qps甚至超過目標qps，穩定一段時間，記錄目標qps下的系統各項關鍵指標及業務指標；
（2）恒定壓力測試
一般在小于目標qps穩定壓力，持續試壓至少2min，觀察系統表現，沒問題后，調整到目標qps，持續施壓2min或者更長，觀察系統表現，記錄系統各項關鍵指標及業務成功率。
（3）混合壓測
指的是多場景同時壓測，這種情況往往需要充分評估好多個場景總的流量對模塊甚至產品的影響。
各模塊混合壓測時，需要評估好各自qps對模塊及對下游模塊可能造成的影響。

某客戶Quick BI性能優化實踐

1、Quick BI數據門戶壓測與調優
在實際客戶案例中，為了從根本上解決Quick BI數據門戶性能問題，采用如下方案進行整體的優化與壓測驗證：

首先優化分為任務優化和產品優化：

任務優化
（1）第一輪壓測：首先對Quick BI進行一輪壓測，記錄當前系統性能數據。
（2）查找優化對象：ADB產品根據top10耗時SQL，針對性的探查性能瓶頸，Quick BI產品側通過查找元倉，找到自定義SQL數據集，并篩選非傳參且耗時高的數據集。
（3）優化：
ADB以優化表DDL為主和規格評估為主，通過在ADB庫中查詢INFORMATION_SCHEMA.PARTITIONS，獲得各表組分區如下：

為了使數據分布均勻，避免長尾問題，根據產品建議，通過重命名原表->創建新表->數據回寫的方式，將ADB中非128分區的表進行DDL改造，分區調整為128分區。

Quick BI通過將自定義SQL數據集固化成結果表的方式，降低使用此類數據集時每次查詢復雜SQL的性能消耗。通過元倉查詢到的此類數據集如下，其中有兩個數據集不是傳參類型自定義SQL數據集，并且SQL非常復雜，對ADB系統性能影響非常大，針對這兩個數據集進行優化調整，將處理邏輯下沉在Dataphin的ads層，并將結果表同步至ADB，供Quick BI的報表直接訪問。

（4）第二輪壓測：對Quick BI各場景頁面進行第二輪壓測，驗證優化效果。

產品優化：
（1）Quick BI產品：后續升級為3.6.1版本后，支持數據緩存功能，可以將各場景默認展示頁的數據進行緩存，降低對后端數據庫的性能消耗。

（2）ADB：優化完成后，可視情況進行限流，從而在資源緊張情況下保障絕大部分用戶的正常使用。后續從2.0版本升級為3.0版本，寫入效率預計提升50%，讀取效率預計提升40%，并且ADB 3.0版本支持存儲計算分離。

另外在Quick BI獨立部署正式上線期間，GTS側進行現場重保，各相關產品側在遠程進行重保，進而保障客戶數據門戶環境平穩運行。

與此同時，因ADB資源不足，對ADB規格進行評估，聯合商務側臨時使用代金券，將ADB資源由進行臨時擴容，優先保障客戶上線，根據上線后實際客戶使用情況決定是否保持擴容規格。

系統調優的目的在于滿足客戶對數據中臺數據門戶性能的需求，那么對數據門戶的壓測必不可少，經過分析，20個qps即可滿足當前客戶的使用需求，在實際進行壓測是，針對數據門戶場景分別進行壓測，壓測方式如下：

2、事后監控
在擴容和調優完成后，我們還需要對系統的使用情況進行監控，監控指標如下：

通過監控指標項發現，擴容和優化后：

（1）每日1：30~8：30左右，數據中臺數據寫入ADB庫，CPU等資源會占用較高，使用率可以達到90%+，但因是非業務使用時間，所以對業務使用無影響。

（2）工作時間CPU使用平均40%左右
業務人員在日間使用期間，系統當前配置在理論上可以支持100用戶并發（20qps）的使用，而且客戶側在短期內會進行數據中臺門戶系統推廣，因此保留當前系統配置，應對后續推廣的用戶涌入。

Quick BI性能優化建議

1、Quick BI開發規范
總結上述性能測試和性能優化的結果，開發人員在使用Quick BI進行可視化開發的過程中，應遵循一定的開發規范，以保證在前期就規避一些性能風險，提升整體平臺的性能。

自定義SQL建模

使用Quick BI進行數據可視化開發，其中的大部分SQL都是Quick BI的SQL引擎自動生成的，此處不需要開發人員關注。而在Quick BI專業版中支持的“即席分析SQL”功能（如上圖）中，允許開發人員通過自定義的SQL創建數據集，此處需要開發人員遵循以下原則進行SQL開發：

(1） 只有必須使用即席查詢SQL中的“參數”傳遞功能，以滿足特殊場景需要的時候，才使用“即席分析SQL”的方式創建數據集。其他場景下，都要求將此數據查詢的過程前置到數據計算過程里面，即使用Dataphin等工具將所需加工的數據提前計算好，形成專門的數據表，Quick BI直接使用該數據結果，而不是在Quick BI中，創建數據集的時候進行比較復雜的SQL數據加工。
(2） 自定義SQL，不建議使用超過3個以上的union 類型的操作。不建議使用超過5個字段以上的group by 操作。不滿足的情況，均建議采用上面1）中的方式，前置到數據計算環境，將數據處理好，再在Quick BI中使用數據。
(3） SQL的編寫規范，需要嚴格遵循《數據中臺模型設計&數據開發規范》的要求編寫。
4） 可通過簡單的性能測試衡量在即席分析SQL中編寫SQL腳本是否可行，在該過程編寫的SQL，頁面執行后，返回結果的時間建議不要超過1s的時間，否則相應的頁面查詢很可能無法滿足客戶對相應時間的要求。

數據集表關聯
Quick BI在數據集管理頁面，支持通過數據表的關聯建立數據集

此處也比較可能產生性能問題。開發過程中需循序以下規范：
（1） 應盡可能減少使用數據表關聯的功能，如果能夠在Dataphin等數據加工工具提前將關聯加工好，則要求此關聯過程前置到計算層。
（2） 如前面的1）條無法滿足，則需要盡可能的使用相同數據源的數據進行關聯。
（3） 如果前面1）2）都無法滿足，應盡量使用RDS或ADB數據庫中的數據集進行關聯。盡量避免使用ODPS的數據源進行關聯訪問。
（4） 盡量避免兩個表全關聯，或者笛卡爾積的方式進行關聯，這樣可能造成數據集數據量極大膨脹，產生性能問題。
（5） 可通過簡單的性能測試衡量在數據集中進行數據表關聯操作是否可行，在數據集中進行關聯，頁面刷新預覽數據時，返回結果的時間建議不要超過1s的時間，否則相應的頁面查詢很可能無法滿足客戶對相應時間的要求。

數據集緩存
Quick BI在數據集頁面，支持對數據集進行緩存配置，如下圖：

Quick BI的3.6.1版本以后支持對ODPS和ADB數據源的數據集進行緩存配置，技術上會將開啟了緩存的數據集數據緩存到Quick BI安裝部署時配置的Redis上面，以減輕對來源數據庫的頻繁訪問，加速查詢性能。使用該功能，需要注意：
（1） Redis數據緩存按小時進行更新，因此開啟了緩存的數據集數據不會實時與數據源進行同步，如源數據發生變化，查詢結果不會實時響應，只會根據Redis的更新才會識別到最新的數據變化。
（2） Redis的空間有限（具體示安裝部署時的配置而定），因此也不建議所有的數據集都開放該緩存功能，而應選擇并發查詢度較高，性能較差的數據集，有重點的開放該功能。

2、 AnalyticDB for MySQL表設計規范

ADB數據模型：
ADB是MPP分布式架構，其數據模型如下：

用戶在設計表的時候，需要重點關注以下四點：
分布鍵（一級分區鍵）
分布鍵（也成為一級分區鍵）根據分布鍵的Hash值，將表數據打散到各個數據分片。
所以，在選擇分布鍵時，一定要盡量確保數據分布均勻，避免數據傾斜。這是重中之重！
同時，盡量選擇多表join時的關聯鍵，避免數據shuffle。
針對一些數據量少且很少更新的碼表，可以選擇創建為“維度表”，來避免數據shuffle，提升性能。

分區鍵（二級分區鍵）
再每一個一級分區下，再根據 List Value，將數據分配多個分塊。

分區鍵通常基于“日期”，并根據二級分區數的定義，按照分區鍵值的大小進行排序，保留最大的N個二級分區。這樣就賦予數據“生命周期”的特性。

主鍵（Primary Key）
通過主鍵進行記錄的唯一性判斷，且分布鍵和分區鍵必須包含在主鍵中。

為了確保主鍵的性能，通常要選擇“數值型”的列作為主鍵，并嚴格控制主鍵的個數，通常控制在4個列以內。

聚集列（Clustered Key）
通過將相同的數據物理排序在一起，可以達到降低IO并提升查詢性能的效果。通常聚集列選擇那些有一定重復數據量、且常常作為查詢過濾條件的列，例如商品類型、人員部門等。

3、AnalyticDB for MySQL開發規范
AnalyticDB for MySQL擁有強大的自研存儲、MPP計算引擎和先進的優化器，通常客戶無需過于關注SQL是否規范。但是，以下的基本原則可以充分利用ADB的特點，已達到最佳的性能：

盡量避免列上嵌套函數
如下，如果在列上嵌套函數，會導致該列上的索引失效，從而需要掃描全表數據，增加系統資源消耗的同時還會影響查詢的性能。

因此，我們在編寫SQL時要盡量避免在列上嵌套函數，上面的SQL可以做如下修改：

盡量確保join時基于分布鍵：
如果兩表Join是不是基于分布鍵，則需要進行大量的數據shuffle，如下：
例如：
表 customer 的分布鍵是 UserId
表 order 的分布鍵是 OrderId
SQL:
Select * from customer c join order o on c.userId=o.userID

在SQL執行時就需要對order表shuffle數據，這樣會增加系統的資源消耗，包括內存、網絡、CPU等，查詢響應時間也會增加

因此，我們需要修改 Order 表的分布鍵為 UserID，這樣上面的SQL在執行時會在單個ECU本地內完成計算，從而提升性能，如下：

盡量多的添加過濾條件
默認情況下，客戶無需關心哪些列需要創建索引，ADB會在所有的列上創建索引。但是如果過濾條件的過濾性不佳，甚至是缺失，則無法發揮ADB強大的自研索引的性能，需要進行全量數據的掃描。因此，我們需要根據業務和數據的特性，盡可能多的添加過濾條件。

?

?

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

總結

以上是生活随笔為你收集整理的让数据中台飞起来—— Quick BI性能优化解决方案及实践的全部內容，希望文章能夠幫你解決所遇到的問題。

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