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

為什么要對(duì)Quick BI進(jìn)行優(yōu)化？
企業(yè)數(shù)據(jù)中臺(tái)建設(shè)完成后，數(shù)據(jù)中臺(tái)作為企業(yè)統(tǒng)一數(shù)據(jù)的“供給方”，越來越多的部門和業(yè)務(wù)人員會(huì)成為“需求方”，希望通過數(shù)據(jù)中臺(tái)的數(shù)據(jù)支持業(yè)務(wù)。隨著“需求方”越來越多，并發(fā)要求越來越高，作為統(tǒng)一入口的Quick BI數(shù)據(jù)門戶的壓力隨之越來越大。因此，隨著數(shù)據(jù)中臺(tái)在企業(yè)內(nèi)推廣和使用的逐步深入，需要對(duì)Quick BI進(jìn)行全面優(yōu)化，以滿足不斷增長(zhǎng)的業(yè)務(wù)需要。

本文旨在說明的問題本篇文章基于實(shí)際客戶案例中Quick BI性能優(yōu)化的實(shí)踐探索，總結(jié)提出數(shù)據(jù)中臺(tái)建設(shè)中的測(cè)試方法和性能優(yōu)化解決方案，拋磚引玉，供其他類似項(xiàng)目參考。

典型的數(shù)據(jù)中臺(tái)技術(shù)架構(gòu)

基于阿里云數(shù)據(jù)中臺(tái)整體解決方案，對(duì)數(shù)據(jù)中臺(tái)技術(shù)實(shí)現(xiàn)進(jìn)行選型及設(shè)計(jì)，典型的數(shù)據(jù)中臺(tái)技術(shù)架構(gòu)如下圖所示，整個(gè)技術(shù)架構(gòu)選型包含五個(gè)層次：業(yè)務(wù)數(shù)據(jù)源存儲(chǔ)技術(shù)、數(shù)據(jù)源接入技術(shù)、數(shù)據(jù)中臺(tái)數(shù)據(jù)存儲(chǔ)與計(jì)算技術(shù)、數(shù)據(jù)服務(wù)及數(shù)據(jù)應(yīng)用技術(shù)。

數(shù)據(jù)存儲(chǔ)計(jì)算，數(shù)據(jù)中臺(tái)中離線數(shù)據(jù)存儲(chǔ)和計(jì)算采用MaxCompute離線計(jì)算引擎；實(shí)時(shí)計(jì)算部分采用阿里云StreamCompute流式計(jì)算技術(shù)實(shí)現(xiàn)；數(shù)據(jù)研發(fā)與管理采用Dataphin智能數(shù)據(jù)構(gòu)建與管理大數(shù)據(jù)研發(fā)平臺(tái)。

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

數(shù)據(jù)應(yīng)用層，使用阿里云智能報(bào)表工具Quick BI實(shí)現(xiàn)各種定制數(shù)據(jù)報(bào)表分析需求；以及基于阿里云產(chǎn)品技術(shù)體系實(shí)現(xiàn)客戶個(gè)性化數(shù)據(jù)應(yīng)用需求。其中基于Quick BI產(chǎn)品的數(shù)據(jù)中臺(tái)門戶如圖中橙色部分所示。

Quick BI壓測(cè)方法

1、壓測(cè)目標(biāo)
Quick BI數(shù)據(jù)中臺(tái)門戶壓測(cè)目標(biāo)主要圍繞著兩類發(fā)布變更和用戶體驗(yàn)反饋，提前做好：性能卡點(diǎn)、性能調(diào)優(yōu)工作，滿足日常客戶報(bào)表的極致體驗(yàn)、以及性能特殊訴求。

兩個(gè)卡點(diǎn)：
1）壓測(cè)，保障上線內(nèi)容無性能問題以及隱患
2）新的報(bào)表上線時(shí)，需要對(duì)新上線報(bào)表進(jìn)行簡(jiǎn)單壓測(cè)，避免單一報(bào)表導(dǎo)致整個(gè)系統(tǒng)性能出現(xiàn)瓶頸。

一個(gè)檢查點(diǎn)：
當(dāng)客戶直觀使用感受數(shù)據(jù)中臺(tái)門戶報(bào)表顯示過慢時(shí)，對(duì)系統(tǒng)整體壓測(cè)，檢查性能瓶頸點(diǎn)進(jìn)行優(yōu)化。
從而保障數(shù)據(jù)中臺(tái)門戶滿足客戶日常報(bào)表可視化性能需求。

2、壓測(cè)策略

1）壓測(cè)環(huán)境
Quick BI數(shù)據(jù)中臺(tái)門戶通常在客戶現(xiàn)場(chǎng)只有正式環(huán)境，Quick BI門戶頁(yè)面壓測(cè)接口全為查詢類請(qǐng)求，壓測(cè)執(zhí)行不會(huì)對(duì)線上數(shù)據(jù)造成污染。當(dāng)然為了避免影響線上用戶，會(huì)在用戶低峰期如凌晨節(jié)點(diǎn)執(zhí)行壓測(cè)。大部分項(xiàng)目數(shù)據(jù)門戶環(huán)境如下：

2）壓測(cè)實(shí)施

具體實(shí)施壓測(cè)時(shí)，主要流程如下：

（1）獲取客戶需求，如客戶需求的可能是要支持100個(gè)并發(fā)，返回時(shí)間不超過3s、日常峰值用戶多少PV等。
（2）根據(jù)客戶需求結(jié)合線上PV訪問量預(yù)估，計(jì)算出經(jīng)驗(yàn)qps和極限qps。
（3）前期準(zhǔn)備，需要跟客戶溝通壓測(cè)時(shí)間點(diǎn)以及壓測(cè)方案，同時(shí)壓測(cè)期間協(xié)調(diào)產(chǎn)品方跟進(jìn)，觀察產(chǎn)品在壓測(cè)時(shí)是否觸發(fā)異常。
（4）壓測(cè)工具準(zhǔn)備
（5）壓測(cè)數(shù)據(jù)準(zhǔn)備
QuickBI門戶涉及多個(gè)頁(yè)面，一個(gè)頁(yè)面包括多個(gè)接口請(qǐng)求，如果通過手工抓接口錄API入?yún)⒌姆绞焦ぷ髁繕O大，而且接口入?yún)?shù)據(jù)時(shí)效不高、容易出錯(cuò)。因此需要一種實(shí)時(shí)頁(yè)面錄制請(qǐng)求的方式實(shí)現(xiàn)壓測(cè)數(shù)據(jù)快速準(zhǔn)備。

3、壓測(cè)方式
通常數(shù)據(jù)中臺(tái)Quick BI門戶的性能瓶頸是在提供數(shù)據(jù)服務(wù)的數(shù)據(jù)庫(kù)，因此在進(jìn)行壓測(cè)時(shí)，我們主要通過區(qū)分不同數(shù)據(jù)源類型的報(bào)表頁(yè)面，進(jìn)行壓測(cè)，如下表所示:
下表所示:

（1）摸高測(cè)試
以最初始的qps開始施加壓力，觀察系統(tǒng)個(gè)性指標(biāo)和業(yè)務(wù)指標(biāo)，穩(wěn)定沒問題后就往上調(diào)高qps并發(fā)數(shù)，依次循環(huán)，最后達(dá)到目標(biāo)qps甚至超過目標(biāo)qps，穩(wěn)定一段時(shí)間，記錄目標(biāo)qps下的系統(tǒng)各項(xiàng)關(guān)鍵指標(biāo)及業(yè)務(wù)指標(biāo)；
（2）恒定壓力測(cè)試
一般在小于目標(biāo)qps穩(wěn)定壓力，持續(xù)試壓至少2min，觀察系統(tǒng)表現(xiàn)，沒問題后，調(diào)整到目標(biāo)qps，持續(xù)施壓2min或者更長(zhǎng)，觀察系統(tǒng)表現(xiàn)，記錄系統(tǒng)各項(xiàng)關(guān)鍵指標(biāo)及業(yè)務(wù)成功率。
（3）混合壓測(cè)
指的是多場(chǎng)景同時(shí)壓測(cè)，這種情況往往需要充分評(píng)估好多個(gè)場(chǎng)景總的流量對(duì)模塊甚至產(chǎn)品的影響。
各模塊混合壓測(cè)時(shí)，需要評(píng)估好各自qps對(duì)模塊及對(duì)下游模塊可能造成的影響。

某客戶Quick BI性能優(yōu)化實(shí)踐

1、Quick BI數(shù)據(jù)門戶壓測(cè)與調(diào)優(yōu)
在實(shí)際客戶案例中，為了從根本上解決Quick BI數(shù)據(jù)門戶性能問題，采用如下方案進(jìn)行整體的優(yōu)化與壓測(cè)驗(yàn)證：

首先優(yōu)化分為任務(wù)優(yōu)化和產(chǎn)品優(yōu)化：

任務(wù)優(yōu)化
（1）第一輪壓測(cè)：首先對(duì)Quick BI進(jìn)行一輪壓測(cè)，記錄當(dāng)前系統(tǒng)性能數(shù)據(jù)。
（2）查找優(yōu)化對(duì)象：ADB產(chǎn)品根據(jù)top10耗時(shí)SQL，針對(duì)性的探查性能瓶頸，Quick BI產(chǎn)品側(cè)通過查找元倉(cāng)，找到自定義SQL數(shù)據(jù)集，并篩選非傳參且耗時(shí)高的數(shù)據(jù)集。
（3）優(yōu)化：
ADB以優(yōu)化表DDL為主和規(guī)格評(píng)估為主，通過在ADB庫(kù)中查詢INFORMATION_SCHEMA.PARTITIONS，獲得各表組分區(qū)如下：

為了使數(shù)據(jù)分布均勻，避免長(zhǎng)尾問題，根據(jù)產(chǎn)品建議，通過重命名原表->創(chuàng)建新表->數(shù)據(jù)回寫的方式，將ADB中非128分區(qū)的表進(jìn)行DDL改造，分區(qū)調(diào)整為128分區(qū)。

Quick BI通過將自定義SQL數(shù)據(jù)集固化成結(jié)果表的方式，降低使用此類數(shù)據(jù)集時(shí)每次查詢復(fù)雜SQL的性能消耗。通過元倉(cāng)查詢到的此類數(shù)據(jù)集如下，其中有兩個(gè)數(shù)據(jù)集不是傳參類型自定義SQL數(shù)據(jù)集，并且SQL非常復(fù)雜，對(duì)ADB系統(tǒng)性能影響非常大，針對(duì)這兩個(gè)數(shù)據(jù)集進(jìn)行優(yōu)化調(diào)整，將處理邏輯下沉在Dataphin的ads層，并將結(jié)果表同步至ADB，供Quick BI的報(bào)表直接訪問。

（4）第二輪壓測(cè)：對(duì)Quick BI各場(chǎng)景頁(yè)面進(jìn)行第二輪壓測(cè)，驗(yàn)證優(yōu)化效果。

產(chǎn)品優(yōu)化：
（1）Quick BI產(chǎn)品：后續(xù)升級(jí)為3.6.1版本后，支持?jǐn)?shù)據(jù)緩存功能，可以將各場(chǎng)景默認(rèn)展示頁(yè)的數(shù)據(jù)進(jìn)行緩存，降低對(duì)后端數(shù)據(jù)庫(kù)的性能消耗。

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

另外在Quick BI獨(dú)立部署正式上線期間，GTS側(cè)進(jìn)行現(xiàn)場(chǎng)重保，各相關(guān)產(chǎn)品側(cè)在遠(yuǎn)程進(jìn)行重保，進(jìn)而保障客戶數(shù)據(jù)門戶環(huán)境平穩(wěn)運(yùn)行。

與此同時(shí)，因ADB資源不足，對(duì)ADB規(guī)格進(jìn)行評(píng)估，聯(lián)合商務(wù)側(cè)臨時(shí)使用代金券，將ADB資源由進(jìn)行臨時(shí)擴(kuò)容，優(yōu)先保障客戶上線，根據(jù)上線后實(shí)際客戶使用情況決定是否保持?jǐn)U容規(guī)格。

系統(tǒng)調(diào)優(yōu)的目的在于滿足客戶對(duì)數(shù)據(jù)中臺(tái)數(shù)據(jù)門戶性能的需求，那么對(duì)數(shù)據(jù)門戶的壓測(cè)必不可少，經(jīng)過分析，20個(gè)qps即可滿足當(dāng)前客戶的使用需求，在實(shí)際進(jìn)行壓測(cè)是，針對(duì)數(shù)據(jù)門戶場(chǎng)景分別進(jìn)行壓測(cè)，壓測(cè)方式如下：

2、事后監(jiān)控
在擴(kuò)容和調(diào)優(yōu)完成后，我們還需要對(duì)系統(tǒng)的使用情況進(jìn)行監(jiān)控，監(jiān)控指標(biāo)如下：

通過監(jiān)控指標(biāo)項(xiàng)發(fā)現(xiàn)，擴(kuò)容和優(yōu)化后：

（1）每日1：30~8：30左右，數(shù)據(jù)中臺(tái)數(shù)據(jù)寫入ADB庫(kù)，CPU等資源會(huì)占用較高，使用率可以達(dá)到90%+，但因是非業(yè)務(wù)使用時(shí)間，所以對(duì)業(yè)務(wù)使用無影響。

（2）工作時(shí)間CPU使用平均40%左右
業(yè)務(wù)人員在日間使用期間，系統(tǒng)當(dāng)前配置在理論上可以支持100用戶并發(fā)（20qps）的使用，而且客戶側(cè)在短期內(nèi)會(huì)進(jìn)行數(shù)據(jù)中臺(tái)門戶系統(tǒng)推廣，因此保留當(dāng)前系統(tǒng)配置，應(yīng)對(duì)后續(xù)推廣的用戶涌入。

Quick BI性能優(yōu)化建議

1、Quick BI開發(fā)規(guī)范
總結(jié)上述性能測(cè)試和性能優(yōu)化的結(jié)果，開發(fā)人員在使用Quick BI進(jìn)行可視化開發(fā)的過程中，應(yīng)遵循一定的開發(fā)規(guī)范，以保證在前期就規(guī)避一些性能風(fēng)險(xiǎn)，提升整體平臺(tái)的性能。

自定義SQL建模

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

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

數(shù)據(jù)集表關(guān)聯(lián)
Quick BI在數(shù)據(jù)集管理頁(yè)面，支持通過數(shù)據(jù)表的關(guān)聯(lián)建立數(shù)據(jù)集

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

數(shù)據(jù)集緩存
Quick BI在數(shù)據(jù)集頁(yè)面，支持對(duì)數(shù)據(jù)集進(jìn)行緩存配置，如下圖：

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

2、 AnalyticDB for MySQL表設(shè)計(jì)規(guī)范

ADB數(shù)據(jù)模型：
ADB是MPP分布式架構(gòu)，其數(shù)據(jù)模型如下：

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

分區(qū)鍵（二級(jí)分區(qū)鍵）
再每一個(gè)一級(jí)分區(qū)下，再根據(jù) List Value，將數(shù)據(jù)分配多個(gè)分塊。

分區(qū)鍵通常基于“日期”，并根據(jù)二級(jí)分區(qū)數(shù)的定義，按照分區(qū)鍵值的大小進(jìn)行排序，保留最大的N個(gè)二級(jí)分區(qū)。這樣就賦予數(shù)據(jù)“生命周期”的特性。

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

為了確保主鍵的性能，通常要選擇“數(shù)值型”的列作為主鍵，并嚴(yán)格控制主鍵的個(gè)數(shù)，通常控制在4個(gè)列以內(nèi)。

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

3、AnalyticDB for MySQL開發(fā)規(guī)范
AnalyticDB for MySQL擁有強(qiáng)大的自研存儲(chǔ)、MPP計(jì)算引擎和先進(jìn)的優(yōu)化器，通常客戶無需過于關(guān)注SQL是否規(guī)范。但是，以下的基本原則可以充分利用ADB的特點(diǎn)，已達(dá)到最佳的性能：

盡量避免列上嵌套函數(shù)
如下，如果在列上嵌套函數(shù)，會(huì)導(dǎo)致該列上的索引失效，從而需要掃描全表數(shù)據(jù)，增加系統(tǒng)資源消耗的同時(shí)還會(huì)影響查詢的性能。

因此，我們?cè)诰帉慡QL時(shí)要盡量避免在列上嵌套函數(shù)，上面的SQL可以做如下修改：

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

在SQL執(zhí)行時(shí)就需要對(duì)order表shuffle數(shù)據(jù)，這樣會(huì)增加系統(tǒng)的資源消耗，包括內(nèi)存、網(wǎng)絡(luò)、CPU等，查詢響應(yīng)時(shí)間也會(huì)增加

因此，我們需要修改 Order 表的分布鍵為 UserID，這樣上面的SQL在執(zhí)行時(shí)會(huì)在單個(gè)ECU本地內(nèi)完成計(jì)算，從而提升性能，如下：

盡量多的添加過濾條件
默認(rèn)情況下，客戶無需關(guān)心哪些列需要?jiǎng)?chuàng)建索引，ADB會(huì)在所有的列上創(chuàng)建索引。但是如果過濾條件的過濾性不佳，甚至是缺失，則無法發(fā)揮ADB強(qiáng)大的自研索引的性能，需要進(jìn)行全量數(shù)據(jù)的掃描。因此，我們需要根據(jù)業(yè)務(wù)和數(shù)據(jù)的特性，盡可能多的添加過濾條件。

?

?

原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

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

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