Doris2.0的Analyze功能，能讓查詢變快不？

就在我寫完上一篇，Doris升級到2.0.2之後跟之前Doris1.2.3的查詢效率對比文章後。

估計是對我這個新舊版本的對比結果不太滿意，有社群的小夥伴私信告訴問我，測試2.0.2的時候，是否有用 ANALYZE 功能，並告訴我，它是2.0新最佳化器很重要的一個模組，目的就是加速查詢用的。

然後扔給我一個相關的連結，我順著這個連結點開一看，確實是一片陌生的內容，它位於官方文件的「查詢加速」模組下，相比於我之前看到的1.2版本的文件，新的2.0又多了幾個新花招。

1.2版本的加速功能

2.0新版本的加速功能

對比一下，從文件結構描述來看，2.0一下子多了4個新的查詢加速功能，我們後續考慮一個個來測測看。

但今天，我們先把目光聚焦在這個統計資訊，也就是對錶的 ANALYZE 功能，看到底是怎麼玩的？

0. 先看文件

既然是一項新功能，自然第一步就是看官方文件是怎麼描述這玩意的。

這個推薦我去看的，表最佳化查詢(查詢加速)功能叫「統計資訊」，開啟文件一看呢，內容還挺多的，裡面包含的資訊量有些大。

老實說，這個文件內容雖然詳盡，篇幅很長，但並沒有到做到結構清晰、言簡意賅(我個人認為)，估計會讓很多第一次閱讀的同學沒有耐心全部讀完，我通讀了兩遍，現把我對這部分「統計資訊」內容的理解，總結如下：

1，從文件結構中的命名來看，「統計資訊」顧名思義就是對錶中的資料進行各種基礎資訊、和共性屬性的統計，因為Doris是列式資料庫，所以這個統計，會對比如每一列資料的總條數、基數、最大值、最小值、空值情況等進行各種彙總；

2，這個統計，跟所有對資料庫的查詢進行最佳化的思想一樣，本質就是預計算，將一些不需要跟業務規則強繫結的共性計算，提前給做了，為後續的業務查詢儘可能提供加速便利；

3，這個所謂的統計資訊，可以在後續基於業務的複雜查詢時，為資料庫的查詢最佳化器，提供最佳化依據，生成最優查詢計劃。

那到底，這個所謂的「統計資訊」是怎麼玩的？以及它到底能不能真正實現我們的業務查詢加速，我們還是老規矩，測試一下便知。

1. 先看怎麼玩的

從文件的描述，以及結合我的實踐來看，這個針對表的統計(ANALYZE)，在新的版本里，必須要透過手動觸發才可以，雖然文件的最後說這個full auto analyze功能是預設開啟的。

但我透過在新的2.0叢集中新建了一張表之後，並沒有發現這個analyze有啟動的跡象(我等了幾個小時都沒有啟動，那這肯定不是自動的)。

對新建的表灌入資料後，並沒有對其analyze

是我的姿勢不對嗎？還是確實不能這麼玩？

此外呢，從文件描述中來看，說它還可以透過額外對錶設定AUTO的方式，讓其自動對錶的資料進行統計(ANALYZE)，設定方式如下：

可以看到，對應確實產生了一個後臺的job id(截圖部分沒有顯示出來)，很快這個analyze就完成了。

看一眼這個analyze的統計結果：

表粒度的analyze結果

列粒度的analyze結果

但是，當我繼續往這表裡再寫入一些資料時，按理說，既然這個 analyze 被設定為 auto 模式了，那我後續寫資料進去，這個對於的統計結果應該要更新才對。

可是，它不，當我再次往裡寫入2w條記錄資料時，這個統計結果依舊巋然不動。

往裡再寫2w條記錄

多次執行，統計結果沒有變化

嘗試了幾次，沒招了。(PS:後續我又嘗試用 period 和 incremental的配置方式，還是不行)

只能再次手動執行analyze命令，這才正常。

注意，這裡之所以總數量少於3w(1w + 2w)，原因在於後面寫進去的2w資料跟之前的存在少量重複，而該表是個去重表模型導致。

但是，即便是這樣，這個統計的結果依然存在槽點。

槽點1：

說好的，針對表粒度的統計結果，應該有6個欄位的統計資訊，但我這查詢出來的，卻只有3個。

官方文件給出的統計資訊是這樣的：

統計結果有6個欄位

而我執行的統計資訊，是這樣的：

統計結果只有3個欄位

誰能告訴我為什麼？莫非我升級了個假的 2.0。

槽點2：

既然是統計(analyze)，那我們是不是要統計準確一點？

那為毛用這種方式統計出來的一些結果，跟我直接用查詢語句查出來的還不一樣呢？

比如對於上面這張表來說，authority_record 這個欄位的ndv值，也就是 count distinct 值為6291，但是我用SQL語句查出來，居然是6321。

不止這個欄位，其他欄位的這個ndv統計也都基本一個鳥樣，就很迷。

疑點：

那既然這個analyze功能，只能透過每次需要時，去手動去觸發(目前我看到是的)，那它存在的意義有用多大呢？

莫非需要我額外再去寫個指令碼，去定期執行？而且它這個統計的資訊很多都不準，我不知道到底能給這個查詢最佳化器加多少速。

另外，以上還只是這個analyze功能，基於列的普通統計。

新版本的Doris說還支援對列的「直方圖統計」，但是在我的這個叢集裡，卻這麼著都實現不了。

官方文件給的示例：

我叢集的執行情況：

這又是啥情況呢？明明升級成功了呀。

2. 能真的對查詢加速嗎

既然說這個對錶的 analyze，可以加速我們的業務查詢，那我們來就來實際測試看看，到底是不是真的？

由於在實際的查詢過程中，對於同一個查詢SQL，即便排除任何外界因素影響下，其查詢耗時也會有所波動，所以對於查詢效率對比，只要差別不大，我們就暫且認為沒有變化。

(PS：為了不讓文章顯得過於冗長，以下查詢效率的截圖就先不放了，直接給結論)

2.1  找出target_ip為空時(實際資料為雙引號)，此時每個不同domain的個數(要求domain統一小寫)

查詢SQL為：

select 
domain, 
count(domain) as count 
from 
(
select 
lower(domain) as domain 
from 
logs_from_spark01 
where target_ip='""'
)t  
group by 
t.domain;

開啟analyze前後，幾乎沒有變化。

2.2 查詢上網次數最多的前100個client_ip，以及他們分別的歸屬地是哪裡

查詢SQL如下：

select 
t1.client_ip,
t2.nature,
t2.province,
t2.city,
t1.count
from
(
select 
client_ip,
count(client_ip) as count 
from 
logs_from_spark01 
group by 
client_ip 
order by 
count desc 
limit 100
)t1
inner join 
logs_from_spark01 t2
on 
t1.client_ip=t2.client_ip
group by 
client_ip,
nature,
province,
city,
count

開啟analyze前後，幾乎沒有變化。

2.3 count distinct的效率對比

查詢SQL：

select
client_ip,
max(row_num2) as max
from
(
select 
client_ip,
row_num2,
date_min
from
(
select
client_ip,
sub_date,
row_number() over (partition by client_ip,sub_date) as row_num2,
date_min
from
(
select 
client_ip,
date_min,
row_number() over (partition by client_ip order by date_min) as row_num,
minutes_sub(to_date(date_min), row_num) as sub_date
from
(
select client_ip,
date_min,
row_number() over (partition by client_ip,date_min order by date_min) as row_num
from
(
select 
client_ip, 
minute_floor(time) AS date_min
from 
logs_from_spark01 
where  
length(time)=14 
and 
time like '20220730%' 
)t
) A
where A.row_num=1
) B
) C
)D
group by 
D.client_ip
order by max desc
limit 100

開啟analyze前後，查詢效率沒有變化。

2.5 查詢出 client_ip 中包含的所有國家、省份、城市，以及運營商

查詢SQL：

select 
nature,
province,
city,
operator 
from 
logs_from_spark01 
group by 
nature,
province,
city,
operator;

開啟analyze前後，查詢效率幾乎沒有變化。

2.6 查詢表中不重複資料的資料總條數

查詢SQL：

SELECT 
count(*) 
FROM 
( 
SELECT  
*, 
row_number() over (partition by client_ip, nature, province, city, operator, domain, time, target_ip, rcode, query_type, authority_record, add_msg, dns_ip) as row_num 
FROM 
logs_from_spark01 
)t 
WHERE t.row_num =1;

開啟analyze前後，查詢效率幾乎沒有變化(甚至慢了一丟丟)。