????????在迭代速度較快業(yè)務(wù)中，為了擴(kuò)展性，有很多情況下數(shù)倉會(huì)直接交付明細(xì)表，這時(shí)就需要查詢時(shí)進(jìn)行聚合，而COUNTD無疑是最耗時(shí)的常用聚合方式。

????????我們知道ClickHouse是一個(gè)分布式數(shù)據(jù)庫，由若干個(gè)分片組成。而我們進(jìn)行去重計(jì)算時(shí)，最終會(huì)將數(shù)據(jù)聚合到某個(gè)節(jié)點(diǎn)進(jìn)行計(jì)算，這會(huì)產(chǎn)生兩個(gè)問題。一個(gè)是負(fù)載均衡問題，一個(gè)是網(wǎng)絡(luò)傳輸問題，在分片數(shù)較少時(shí)問題不大(在前司時(shí)，看到很多私有化部署環(huán)境只有1/2個(gè)分片)，而在分片數(shù)較多時(shí)會(huì)消耗大量時(shí)間。在數(shù)據(jù)準(zhǔn)確性不敏感的情況下，一般會(huì)使用非精確去重比如uniqCombined 等，而在數(shù)據(jù)比較敏感的情況下，我們會(huì)不得不使用count distinct。有沒有什么辦法能讓我們的countd性能與直接使用uniqCombined接近甚至超過呢？這就需要在建表以及查詢時(shí)進(jìn)行一些處理。

????????假如我們?cè)诓橐粡埫骷?xì)表，比如一個(gè)uv字段，我們需要計(jì)算count(distinct userId),表中有包含userid的明細(xì)數(shù)據(jù)。這時(shí)我們可以在建CK表時(shí)，選擇userId為分片鍵，進(jìn)行建表。在查詢時(shí)，我們將該count(distinct userId)進(jìn)行下推，在local表中進(jìn)行去重，去重后相加。不同公司的CK引擎都有自己的團(tuán)隊(duì)(比如字節(jié)跳動(dòng)有4個(gè)CK團(tuán)隊(duì)，互不兼容)，這個(gè)下推SQL的具體格式不確定，大概會(huì)長(zhǎng)這樣 select sum(innerM1)?from cluster(default,view(select count(distinct userId) as innerM1 from table_local)) 。對(duì)應(yīng)之前提到過countd性能差的原因，現(xiàn)在我們不需要跨分片去重，減少了大量數(shù)據(jù)傳輸?shù)臅r(shí)間，也不需要集中在某一臺(tái)機(jī)器中進(jìn)行大量數(shù)據(jù)的去重，減少了負(fù)載均衡帶來的問題。在我當(dāng)前的業(yè)務(wù)場(chǎng)景中，120個(gè)分片，這個(gè)優(yōu)化會(huì)提升查詢速度近百倍。

????在應(yīng)用該方法時(shí)需要注意，在查詢多個(gè)分區(qū)數(shù)據(jù)時(shí)，是存在不同分片持有不同分區(qū)數(shù)據(jù)的情況的，因此使用該優(yōu)化時(shí)我們需要指定分區(qū)(對(duì)應(yīng)全量表)或者對(duì)按分區(qū)進(jìn)行聚合(對(duì)應(yīng)業(yè)務(wù)中按天聚合)，萬幸是實(shí)際使用中正常的PM只會(huì)提出這兩種類型的需求。

????常見問題：

????1. 假如有兩個(gè)字段都需要countd怎么辦？

??????????????答：建兩張表

? ? 2. 假如一定需要對(duì)某字段跨分區(qū)去重怎么辦？

??????????????答：讓數(shù)倉建聚合表/說服PM

? ? 3.?假如一定一定需要對(duì)某字段跨分區(qū)去重怎么辦？、

????????????? 答: 下推后group by userId然后聚合，盡量減少負(fù)載均衡的問題。