-更多關于數智化轉型、資料中台内容請加入 阿裡雲資料中台交流群—數智俱樂部 和關注官方微信公總号（文末掃描二維碼或 點此加入 ）
-阿裡雲資料中台官網 https://dp.alibaba.com/index
寫在前面
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強大的自研索引的性能，需要進行全量資料的掃描。是以，我們需要根據業務和資料的特性，盡可能多的添加過濾條件。
資料中台是企業數智化的必經之路，阿裡巴巴認為資料中台是集方法論、工具、組織于一體的，“快”、“準”、“全”、“統”、“通”的智能大資料體系。
目前正通過阿裡雲對外輸出系列解決方案，包括
通用資料中台解決方案、
零售資料中台解決方案 金融資料中台解決方案 網際網路資料中台解決方案 政務資料中台解決方案等細分場景。
其中阿裡雲資料中台産品矩陣是以Dataphin為基座，以Quick系列為業務場景化切入，包括：
- - Dataphin，一站式、智能化的資料建構及管理平台 ；
- - Quick BI，随時随地 智能決策
- - Quick Audience，全方位洞察、全域營銷、智能增長
- - Quick A+， 跨多端全域應用體驗分析及洞察的一站式資料化營運平台
- - Quick Stock， 智能貨品營運平台
- - Quick Decision，智能決策平台
官方站點：
資料中台官網
https://dp.alibaba.com釘釘溝通群和微信公衆号