偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

新一代云原生數(shù)據(jù)倉庫 AnalyticDB「SQL 智能診斷」功能詳解

數(shù)據(jù)庫 云原生 數(shù)據(jù)倉庫
AnalyticDB For MySQL(新一代云原生實(shí)時(shí)數(shù)據(jù)倉庫,語法兼容MySQL,以下簡稱ADB)為用戶提供了高效、實(shí)時(shí)、功能豐富并且智能化的「SQL智能診斷」和「SQL智能調(diào)優(yōu)」功能,提供用戶SQL性能調(diào)優(yōu)的思路、方向和具體的方法,降低用戶使用成本,提高用戶使用ADB的效率。

SQL是一種簡單易用的業(yè)務(wù)邏輯表達(dá)語言,但隨著掃描數(shù)據(jù)量查詢復(fù)雜度的增加,查詢性能會(huì)變得越來越慢。想要對(duì)SQL進(jìn)行調(diào)優(yōu),往往需要關(guān)注以下幾個(gè)部分:

需要了解引擎架構(gòu):用戶往往需要對(duì)SQL引擎的架構(gòu)特點(diǎn)有一定的了解,才能和業(yè)務(wù)的數(shù)據(jù)分布特征以及業(yè)務(wù)場(chǎng)景特征完美結(jié)合,來進(jìn)行數(shù)據(jù)建模,從而設(shè)計(jì)出符合SQL引擎架構(gòu)特點(diǎn)的表結(jié)構(gòu)。

SQL特征差異較大:即席查詢的SQL往往變化較大,包括參與Join的表個(gè)數(shù)、Join條件、分組聚合的字段個(gè)數(shù)以及過濾條件等。

數(shù)據(jù)特征差異較大:用戶的數(shù)據(jù)分布特征是會(huì)隨著業(yè)務(wù)特征的變化而變化的,如果一直按照最初的建模方式和SQL語句,也是無法保障能發(fā)揮出SQL引擎的最大優(yōu)勢(shì),數(shù)據(jù)特征或者業(yè)務(wù)模型的變化,都會(huì)導(dǎo)致SQL性能回退。

基于此,AnalyticDB For MySQL(新一代云原生實(shí)時(shí)數(shù)據(jù)倉庫,語法兼容MySQL,以下簡稱ADB)為用戶提供了高效、實(shí)時(shí)、功能豐富并且智能化的「SQL智能診斷」「SQL智能調(diào)優(yōu)」功能,提供用戶SQL性能調(diào)優(yōu)的思路、方向和具體的方法,降低用戶使用成本,提高用戶使用ADB的效率。

下面我們通過「發(fā)現(xiàn)慢查詢」+「診斷慢查詢」兩個(gè)步驟,并結(jié)合一個(gè)場(chǎng)景Case,來介紹ADB新發(fā)布的「SQL智能診斷」功能。(PS:「SQL智能調(diào)優(yōu)」會(huì)在后續(xù)版本中發(fā)布)

一、發(fā)現(xiàn)慢查詢

用戶要定位慢查詢,首先需要找到慢查詢。ADB的用戶控制臺(tái)提供了多樣的方式來幫助用戶,例如「甘特圖」「查詢列表」等,都可以在多個(gè)維度進(jìn)行檢索,幫助用戶快速定位慢查詢,而且診斷工具確保用戶可以進(jìn)行最近兩周的全量查詢檢索和分析。

(一)甘特圖

用戶可以通過「集群控制臺(tái)」-「診斷與優(yōu)化」 - 「SQL診斷」進(jìn)入SQL智能診斷功能。

首先會(huì)看到一個(gè)甘特圖(也稱泳道圖,查詢從不同的泳道流過,這里的泳道并不是ADB的查詢隊(duì)列,只是為了區(qū)分開不同時(shí)間執(zhí)行的查詢),甘特圖以圖形化的方式形象的展示了查詢?cè)贏DB實(shí)例上的執(zhí)行順序,每個(gè)色塊表示了一條查詢,色塊左側(cè)為查詢的提交時(shí)間,色塊右側(cè)為查詢的結(jié)束時(shí)間,色塊的相對(duì)長度表示了某條查詢的執(zhí)行時(shí)間,色塊的顏色沒有特殊含義,只是為了區(qū)分不同的泳道。

通過甘特圖,用戶可以非常直觀的看到當(dāng)前時(shí)間范圍內(nèi)執(zhí)行耗時(shí)較長的查詢,并且可以直觀的看到哪些查詢是在并行的執(zhí)行以及并行執(zhí)行的時(shí)間段,這可以幫助用戶判斷出哪些查詢是受到了某條Bad SQL的影響。色塊的密集度則可以用來直觀的判斷ADB實(shí)例壓力較大的時(shí)段是否和某些查詢的并發(fā)度較高相關(guān)。

(二)查詢列表

甘特圖能夠以直觀的方式體現(xiàn)出查詢之間的時(shí)間相關(guān)性,但是當(dāng)用戶選擇的時(shí)間范圍較大,甘特圖中的色塊會(huì)密集分布不容易分辨,而且甘特圖上的指標(biāo)較為有限,此時(shí)用戶可以使用診斷工具中的查詢列表功能。查詢列表提供了多大10余項(xiàng)查詢級(jí)別的重要指標(biāo),例如數(shù)據(jù)庫名、用戶名、客戶端段IP、耗時(shí)、消耗內(nèi)存以及掃描量等,這些信息和指標(biāo)可以幫助用戶進(jìn)一步判斷慢查詢的來源和資源消耗等。

高級(jí)檢索能力方面,診斷工具提供了三種類型的檢索方法:

1.模糊檢索和精確檢索:用戶可以根據(jù)SQL中的關(guān)鍵字進(jìn)行模糊匹配,精確檢索功能則幫助用戶在確定查詢ID的情況下,精確的檢索到這條查詢;
2.字符串類型的檢索條件:檢索工具會(huì)自動(dòng)識(shí)別出用戶所選時(shí)間范圍內(nèi)使用的數(shù)據(jù)名、用戶名、客戶端IP以及資源組等,提供下拉框的形式供用戶選擇,提高用戶檢索效率;
3.數(shù)值類型的檢索條件:用戶可以自由選擇檢索的指標(biāo)單位,例如KB、MB、GB等,不需要進(jìn)行手動(dòng)的換算。

同時(shí),用戶在使用診斷工具時(shí),往往有對(duì)慢查詢的下載需求,下載后的慢查詢可以在例如Excel等工具中進(jìn)行更多自定義的慢查詢治理和分析,所以我們也提供了查詢列表的下載功能。

二、診斷慢查詢

(一)查詢?cè)贏DB中的執(zhí)行流程

在介紹ADB執(zhí)行流程前需要簡單介紹一下三個(gè)相關(guān)的基本概念:

Stage

在執(zhí)行階段,ADB中的查詢會(huì)首先根據(jù)是否產(chǎn)生Shuffle被切分為多個(gè)Stage來執(zhí)行,一個(gè)Stage就是執(zhí)行計(jì)劃中某一部分的物理實(shí)體。Stage的數(shù)據(jù)來源可以是底層存儲(chǔ)系統(tǒng)中的數(shù)據(jù)或者網(wǎng)絡(luò)中傳輸?shù)臄?shù)據(jù),一個(gè)Stage由分布在不同計(jì)算節(jié)點(diǎn)上相同類型的Task組成,多個(gè)Task會(huì)并行處理數(shù)據(jù)。

Task

Task是一個(gè)Stage在某個(gè)Executor節(jié)點(diǎn)上的執(zhí)行實(shí)體,多個(gè)同類型的Task組成一個(gè)Stage,在集群內(nèi)部并行處理數(shù)據(jù)。

Operator

Operator(算子)是ADB的最小數(shù)據(jù)處理單元。ADB會(huì)根據(jù)算子所表達(dá)的語義或算子間的依賴關(guān)系,決定使用并行還是串行執(zhí)行來處理數(shù)據(jù)。

下面以一個(gè)典型的分局聚合查詢?yōu)槔齺砹私釧DB中查詢的執(zhí)行流程,SQL語句如下:

  1. SELECT COUNT(*), SUM(salary) 
  2.  
  3. FROM emplayee 
  4.  
  5. WHERE age>30 ADN age<32 
  6.  
  7. GROUP BY sex 

在ADB內(nèi)部,首先由前端的Controller節(jié)點(diǎn)接收SQL語句請(qǐng)求,并對(duì)SQL語句進(jìn)行語句解析語法分析(Parser),最后使用優(yōu)化器(Optimizer)生成最終的執(zhí)行計(jì)劃,整體執(zhí)行計(jì)劃會(huì)根據(jù)Stage的劃分原則被切分為子計(jì)劃,如圖中的Plan0、Plan1和Plan2,分別被下發(fā)到對(duì)應(yīng)的節(jié)點(diǎn)上。

其中子計(jì)劃Plan2會(huì)并行的在4個(gè)計(jì)算節(jié)點(diǎn)上以Task實(shí)例的形式處理數(shù)據(jù),首先執(zhí)行數(shù)據(jù)的掃描和過濾,然后執(zhí)行數(shù)據(jù)的局部聚合,處理完之后的數(shù)據(jù)會(huì)根據(jù)sex字段Repartition到下游的計(jì)算節(jié)點(diǎn),即Stage1的節(jié)點(diǎn),按照子計(jì)劃Plan1的要求執(zhí)行數(shù)據(jù)的最終聚合。最后,數(shù)據(jù)由Stage0的節(jié)點(diǎn)匯總并返回到客戶端。

和典型的數(shù)據(jù)倉庫一樣,ADB的執(zhí)行計(jì)劃一般分為「邏輯執(zhí)行計(jì)劃」和「物理執(zhí)行計(jì)劃」:

邏輯執(zhí)行計(jì)劃:宏觀層面了解查詢的處理流程

邏輯執(zhí)行計(jì)劃在較高的層面展示查詢的處理邏輯,基于規(guī)則的執(zhí)行計(jì)劃(RBO)會(huì)判斷過濾條件是否可以下推,而基于代價(jià)的執(zhí)行計(jì)劃(CBO)會(huì)判斷出多表關(guān)聯(lián)時(shí)的順序等。所以邏輯執(zhí)行計(jì)劃并不關(guān)注在物理執(zhí)行時(shí)的具體處理方式,例如是否在執(zhí)行時(shí)需要對(duì)多個(gè)算子進(jìn)行融合以減少函數(shù)調(diào)用,或者自動(dòng)生成代碼的粒度,這些邏輯執(zhí)行計(jì)劃并不關(guān)注,這也就導(dǎo)致了邏輯執(zhí)行計(jì)劃往往只包含了Stage級(jí)別的執(zhí)行統(tǒng)計(jì)信息。但是用戶調(diào)優(yōu)時(shí)往往是需要精確到算子級(jí)別的統(tǒng)計(jì)信息。

物理執(zhí)行計(jì)劃:微觀層面了解每個(gè)算子的處理性能

相對(duì)于邏輯執(zhí)行計(jì)劃,物理執(zhí)行計(jì)劃包含了算子間的數(shù)據(jù)處理流圖,也包含了算子的執(zhí)行統(tǒng)計(jì)信息,可以精確的看到某個(gè)Join算子或者聚合算子占用的內(nèi)存,也可以看到過濾算子過濾前后的數(shù)據(jù)量。但是并不是所有的算子用戶都需要能正確理解其含義,特別是有些物理算子和用戶的SQL語句找不到關(guān)聯(lián)之處,這也會(huì)給用戶單獨(dú)使用物理執(zhí)行計(jì)劃定位問題帶來較大的疑惑。

ADB的「SQL智能診斷」功能,提供給了用戶一個(gè)邏輯執(zhí)行計(jì)劃和物理執(zhí)行計(jì)劃的融合視圖,用戶使用融合的執(zhí)行計(jì)劃即可以從宏觀層面了解查詢的處理流程,也可以從微觀層面了解每個(gè)算子的處理性能,從而可以更加準(zhǔn)確快速的幫助用戶定位查詢的性能瓶頸點(diǎn)。

(二)SQL自診斷功能

雖然我們提供了融合的和分層的執(zhí)行計(jì)劃來幫助用戶分析查詢的性能問題,但是我們發(fā)現(xiàn)在兩類場(chǎng)景中用戶使用融合執(zhí)行計(jì)劃會(huì)遇到困難:

ADB的初級(jí)使用者

ADB為了減少M(fèi)ySQL用戶的學(xué)習(xí)和遷移成本,做到了絕大多數(shù)語法和MySQL兼容,但是ADB的后臺(tái)并非MySQL內(nèi)核,而是獨(dú)立自研的一套分布式數(shù)據(jù)存儲(chǔ)和分布式計(jì)算系統(tǒng),面對(duì)ADB的執(zhí)行計(jì)劃,ADB的初級(jí)使用者往往不知道優(yōu)化的重點(diǎn)在哪里,無從下手。

ADB中的復(fù)雜SQL

對(duì)于復(fù)雜的SQL,往往涉及幾百張表的連接操作,Stage個(gè)數(shù)會(huì)達(dá)到幾百個(gè)以上,算子個(gè)數(shù)更是會(huì)達(dá)到上千,執(zhí)行計(jì)劃圖非常大,即使是ADB的高級(jí)使用者,面對(duì)這樣復(fù)雜的執(zhí)行計(jì)劃,往往也無從下手,如下圖是個(gè)196個(gè)Stage的執(zhí)行計(jì)劃圖:

針對(duì)以上問題,我們?cè)趫?zhí)行計(jì)劃圖中加入了SQL自診斷能力,SQL自診斷能力會(huì)將專家經(jīng)驗(yàn)以規(guī)則的形式體現(xiàn)在執(zhí)行計(jì)劃中,對(duì)于ADB的初次接觸者,即可以根據(jù)診斷結(jié)果確定查詢執(zhí)行過程中的性能瓶頸點(diǎn),也可以根據(jù)診斷結(jié)果學(xué)習(xí)到ADB執(zhí)行計(jì)劃中需要關(guān)注的重點(diǎn)算子。針對(duì)復(fù)雜執(zhí)行計(jì)劃,SQL自診斷可以幫助用戶快速定位到執(zhí)行計(jì)劃中需要調(diào)優(yōu)的位置,并提供了調(diào)優(yōu)的相關(guān)方法和文檔,讓用戶在調(diào)優(yōu)過程中更有針對(duì)性。

SQL自診斷能力通過「Query級(jí)別診斷結(jié)果」、「Stage級(jí)別診斷結(jié)果」、「算子級(jí)別診斷結(jié)果」這三層來展示診斷結(jié)果和優(yōu)化建議。

我們以一個(gè)線上的復(fù)雜SQL為例來介紹使用執(zhí)行計(jì)劃和SQL自診斷工具來進(jìn)行性能問題定位的例子。首先我們通過慢查詢檢索工具搜索到一個(gè)內(nèi)存消耗較大的查詢,點(diǎn)擊「診斷」打開該查詢的診斷頁面,切換到「執(zhí)行計(jì)劃」頁簽,我們會(huì)看到查詢級(jí)別診斷結(jié)果已經(jīng)判斷出當(dāng)前查詢數(shù)據(jù)一個(gè)內(nèi)存消耗較大的查詢,如下圖中的1所示:

這時(shí),我們需要定位內(nèi)存效果較大的原因,我們點(diǎn)擊按內(nèi)存排序,可以看到在右側(cè),會(huì)根據(jù)Stage消耗的內(nèi)存百分比進(jìn)行了倒敘排序,可以非常明顯的看出,Stage[1]占用的當(dāng)前查詢87%以上的內(nèi)存比例,我們點(diǎn)擊Stage[1],診斷工具會(huì)自動(dòng)聚焦到執(zhí)行計(jì)劃樹的Stage[1]的位置,點(diǎn)擊Stage[1],我們可以看到Stage[1]的執(zhí)行統(tǒng)計(jì)信息,同時(shí),我們可以看到在5的位置,提示我們當(dāng)前Stage1內(nèi)部有個(gè)算子占用內(nèi)存較大,但是并沒有詳細(xì)信息,所以接下來,我們需要進(jìn)入到Stage[1]的內(nèi)部,看看Stage[1]具體是哪個(gè)算子占用了較多內(nèi)存。

點(diǎn)擊「查看Stage執(zhí)行計(jì)劃」,進(jìn)入到Stage[1]內(nèi)部,首先,我們依然根據(jù)內(nèi)存排序,可以看到,其中的Join[317]這個(gè)算子占用了整個(gè)Stage 99%以上的內(nèi)存,點(diǎn)擊該算子,算子執(zhí)行計(jì)劃樹自動(dòng)定位到當(dāng)前算子,這時(shí)我們就可以看到算子診斷結(jié)果的詳細(xì)信息了,信息提示我們,在構(gòu)建Hash表用戶Left Join時(shí),占用了較大的內(nèi)存,診斷結(jié)果還提供了官方的調(diào)優(yōu)文檔鏈接,根據(jù)文檔中給出的調(diào)優(yōu)方法,我們就可以減少該算子的內(nèi)存占用。

以上的例子通過「查詢級(jí)別診斷結(jié)果」「算子級(jí)別診斷結(jié)果」進(jìn)行SQL性能問題定位的方法,我們?cè)賮砜匆粋€(gè)「Stage級(jí)別診斷結(jié)果」的例子。

如下圖所示,我們可以看到根據(jù)耗時(shí)排序后,Stage[10]的耗時(shí)比例最大,點(diǎn)擊執(zhí)行計(jì)劃圖中的Stage[10],可以在診斷結(jié)果欄看到兩類診斷結(jié)果,一類是“Stage診斷”,一類是“算子診斷”,其中的Stage診斷告訴我們當(dāng)前Stage的輸出數(shù)據(jù)有傾斜,并且告訴我們傾斜的字段是哪些(數(shù)據(jù)傾斜是分布式系統(tǒng)中嚴(yán)重影響性能的問題,Stage輸出數(shù)據(jù)傾斜不但會(huì)當(dāng)時(shí)當(dāng)前Stage處理數(shù)據(jù)在時(shí)間上存在長尾,而且會(huì)導(dǎo)致下游的數(shù)據(jù)處理存在長尾),同時(shí)可以看到有一個(gè)算子診斷結(jié)果,提示我們表掃描存在傾斜,那么我們可以初步判斷當(dāng)前Stage輸出數(shù)據(jù)傾斜是因?yàn)閽呙枇艘粋€(gè)數(shù)據(jù)傾斜的表導(dǎo)致的。接下來我們進(jìn)入到Stage[0]內(nèi)部進(jìn)行定位和分析。

進(jìn)入到Stage內(nèi)存,我們根據(jù)耗時(shí)排序,可以看到TableScan算子耗時(shí)最大,這時(shí)我們點(diǎn)擊TableScan算子,可以看到在診斷結(jié)果里,有關(guān)于該表數(shù)據(jù)傾斜的詳細(xì)診斷結(jié)果信息,這張表由于數(shù)據(jù)分布字段選擇的不合適,存在嚴(yán)重的數(shù)據(jù)傾斜問題,同時(shí)可以看到有相關(guān)的官方調(diào)優(yōu)文檔,我們根據(jù)調(diào)優(yōu)文檔,就可以調(diào)整為合適的分布字段,減少表數(shù)據(jù)傾斜對(duì)查詢性能的影響。

通過以上的兩個(gè)例子,我們可以看到,融合執(zhí)行計(jì)劃和SQL自診斷功能,可以快速的幫我們定位到查詢的性能問題,并給出一定的調(diào)優(yōu)建議,減少大量不必要的時(shí)間和精力的浪費(fèi),降低了初級(jí)使用者使用ADB的門檻。關(guān)于SQL自診斷更多的診斷結(jié)果可以參考官網(wǎng)文檔:SQL自診斷,目前已經(jīng)有20+診斷規(guī)則上線,涉及查詢相關(guān)的內(nèi)存消耗、耗時(shí)、數(shù)據(jù)傾斜、磁盤IO以及執(zhí)行計(jì)劃等多個(gè)方面,后續(xù)還有更多診斷規(guī)則陸續(xù)上線。

三、 后續(xù)規(guī)劃

通過以上的闡述和例子分析,可以看到當(dāng)前的診斷調(diào)優(yōu)工具已經(jīng)可以幫助用戶進(jìn)行多方面的SQL性能問題排查,但是我們?cè)趯?shí)際的線上問題處理和值班時(shí)仍然發(fā)現(xiàn)總結(jié)了多個(gè)用戶在分析實(shí)例性能問題時(shí)的需求:

我應(yīng)該調(diào)優(yōu)哪些SQL?

用戶在打開診斷調(diào)優(yōu)頁面時(shí),面對(duì)實(shí)例上運(yùn)行的上萬甚至上千萬條SQL,雖然可以通過耗時(shí)、內(nèi)存消耗或者掃描量等進(jìn)行排序來初步篩選出需要調(diào)優(yōu)的SQL,但是其實(shí)其實(shí)用戶欠缺了一個(gè)特定診斷結(jié)果的視角,例如:

哪些SQL是數(shù)據(jù)掃描傾斜的?
哪些SQL是索引過濾不高效的?
哪些SQL是Stage輸出傾斜的?
哪些SQL是分區(qū)選擇不合理的?
用戶在針對(duì)某一個(gè)SQL的特定診斷結(jié)果調(diào)優(yōu)完成后,其實(shí)需要知道有哪些類似的SQL都需要調(diào)優(yōu)的,所以我們后續(xù)會(huì)提供給用戶一個(gè)從特定診斷結(jié)果維度進(jìn)行分析的工具,一次性地解決某個(gè)特定問題。

我的SQL有問題,和建表方式不優(yōu)有關(guān)嗎?

ADB后臺(tái)是一個(gè)分布式的數(shù)據(jù)存儲(chǔ)和分布式的執(zhí)行框架,依賴數(shù)據(jù)均勻的分布到各個(gè)后臺(tái)節(jié)點(diǎn)上,同時(shí)ADB針對(duì)不同的業(yè)務(wù)場(chǎng)景設(shè)計(jì)了不同的表類型,例如分區(qū)表、復(fù)制表,有些表字段在存儲(chǔ)時(shí)進(jìn)行聚集存儲(chǔ),也會(huì)提升查詢性能,但是用戶往往不知道建表方式不優(yōu)到底影響了哪些查詢。后續(xù)我們會(huì)把「數(shù)據(jù)建模診斷結(jié)果」和「查詢?cè)\斷結(jié)果」關(guān)聯(lián),用戶通過數(shù)據(jù)建模的診斷結(jié)果即可快速知道不良的表結(jié)構(gòu)影響了哪些SQL,同時(shí)反過來也可以通過某條SQL的診斷結(jié)果知道哪些表需要優(yōu)化。兩類診斷結(jié)果聯(lián)動(dòng)調(diào)優(yōu),可以從根源上解決實(shí)例的查詢性能問題。

 

責(zé)任編輯:梁菲 來源: 阿里云云棲號(hào)
相關(guān)推薦

2024-05-06 07:39:30

CubeFS云原生存儲(chǔ)平臺(tái)

2021-06-10 09:00:00

數(shù)據(jù)湖架構(gòu)數(shù)據(jù)平臺(tái)

2018-10-24 16:31:24

華為云

2013-07-03 09:49:21

云計(jì)算數(shù)據(jù)中心

2022-07-27 09:43:51

AnalyticDB數(shù)據(jù)倉庫云原生

2018-03-29 15:50:48

華為

2023-03-09 22:00:25

2018-04-26 18:23:37

華為

2023-03-16 07:20:15

大數(shù)據(jù)平臺(tái)云數(shù)據(jù)

2009-07-09 18:03:54

開源云計(jì)算開發(fā)

2013-02-28 14:34:22

Win Server

2023-01-12 15:32:46

云原生Loggie

2018-07-10 11:02:48

數(shù)據(jù)倉庫AI分析型數(shù)據(jù)庫

2022-06-24 22:33:36

Qlik數(shù)據(jù)主動(dòng)智能

2024-07-11 08:13:32

2012-05-18 10:41:07

windows8系統(tǒng)

2012-05-22 19:15:41

微軟私有云SystemCente

2020-05-14 16:11:20

阿里云
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)