本文根據(jù)dbaplus社群第199期線上分享整理而成，文末還有直播回放~

王海勝

趣頭條數(shù)據(jù)中心大數(shù)據(jù)開發(fā)工程師

• 8年互聯(lián)網(wǎng)工作經(jīng)驗(yàn)，曾在eBay、唯品會(huì)、趣頭條等公司從事大數(shù)據(jù)開發(fā)相關(guān)工作，有豐富的大數(shù)據(jù)落地經(jīng)驗(yàn)。

業(yè)務(wù)背景

隨著公司規(guī)模越來(lái)越大，業(yè)務(wù)線越來(lái)越多，公司的指標(biāo)規(guī)模也在急速增長(zhǎng)，現(xiàn)有的基于storm實(shí)時(shí)計(jì)算的指標(biāo)計(jì)算架構(gòu)的缺點(diǎn)越來(lái)越凸顯，所以我們急需對(duì)現(xiàn)有的架構(gòu)進(jìn)行調(diào)整。

1、基于storm的指標(biāo)平臺(tái)存在的問題

• 指標(biāo)口徑不夠直觀

• 數(shù)據(jù)無(wú)法回溯

• 穩(wěn)定性不夠

2、什么是我們需要的?

我們需要一個(gè)穩(wěn)定的、基于SQL、方便進(jìn)行數(shù)據(jù)回溯、并且要足夠快速的引擎，支持我們的實(shí)時(shí)指標(biāo)平臺(tái)。

1）穩(wěn)定性是最主要的，基于storm的架構(gòu)數(shù)據(jù)都是存儲(chǔ)在內(nèi)存中的，如果指標(biāo)配置有問題，很容易導(dǎo)致OOM，需要清理全部的數(shù)據(jù)才能夠恢復(fù)。

2）基于SQL是避免像storm架構(gòu)下離線SQL到storm topology轉(zhuǎn)換的尷尬經(jīng)歷。

3）方便回溯是數(shù)據(jù)出現(xiàn)問題以后，我們可以簡(jiǎn)單的從新刷一下就可以恢復(fù)正常，在storm架構(gòu)下有些場(chǎng)景無(wú)法完成。

4）快速那是必須的，指標(biāo)數(shù)越來(lái)越多，如果不能再5分鐘周期內(nèi)完成所有的指標(biāo)計(jì)算是不能接受的。

clickhouse

1、為什么選擇clickhouse?

足夠快，在選擇clickhouse以前我們也有調(diào)研過(guò)presto、druid等方案，presto的速度不夠快，無(wú)法在5分鐘內(nèi)完成這么多次的查詢。

druid的預(yù)計(jì)算挺好的，但是維度固定，我們的指標(biāo)的維度下鉆都是很靈活的，并且druid的角色太多維護(hù)成本也太高，所以也被pass了。

最終我們選擇了clickhouse，在我們使用之前，部門內(nèi)部其實(shí)已經(jīng)有使用單機(jī)版對(duì)離線數(shù)據(jù)的查詢進(jìn)行加速了，所以選擇clickhouse也算是順理成章。

2、clickhouse和presto查詢速度比較

clickhouse集群現(xiàn)狀：32核128G內(nèi)存機(jī)器60臺(tái)，使用ReplicatedMergeTree引擎，每個(gè)shard有兩個(gè)replica。

presto集群的現(xiàn)狀：32核128G內(nèi)存機(jī)器100臺(tái)。

1）最簡(jiǎn)單的count()的case

從上圖可以看到clickhouse在count一個(gè)1100億數(shù)據(jù)表只需要2s不到的時(shí)間, 由于數(shù)據(jù)冗余存儲(chǔ)的關(guān)系，clickhouse實(shí)際響應(yīng)該次查詢的機(jī)器數(shù)只有30臺(tái)(60 / 2)，presto在count一個(gè)400億的數(shù)據(jù)表耗時(shí)80秒左右的時(shí)候，100臺(tái)機(jī)器同時(shí)在處理這個(gè)count的查詢。

2）常規(guī)指標(biāo)維度下鉆計(jì)算count() + group by + order by + limit

同樣在1100億數(shù)據(jù)表中clickhouse在該case上面的執(zhí)行時(shí)間也是非常不錯(cuò)的耗時(shí)5s左右，presto在400億的數(shù)據(jù)集上完成該查詢需要100s左右的時(shí)間。

從上面兩個(gè)常規(guī)的case的執(zhí)行時(shí)間我們可以看出，clickhouse的查詢速度比presto的查詢速度還是要快非常多的。

3、clickhouse為什么如此快

1）優(yōu)秀的代碼，對(duì)性能的極致追求

clickhouse是CPP編寫的，代碼中大量使用了CPP最新的特性來(lái)對(duì)查詢進(jìn)行加速。

2）優(yōu)秀的執(zhí)行引擎以及存儲(chǔ)引擎

clickhouse是基于列式存儲(chǔ)的，使用了向量化的執(zhí)行引擎，利用SIMD指令進(jìn)行處理加速，同時(shí)使用LLVM加快函數(shù)編譯執(zhí)行，當(dāng)然了Presto也大量的使用了這樣的特性。

3）稀疏索引

相比于傳統(tǒng)基于HDFS的OLAP引擎，clickhouse不僅有基于分區(qū)的過(guò)濾，還有基于列級(jí)別的稀疏索引，這樣在進(jìn)行條件查詢的時(shí)候可以過(guò)濾到很多不需要掃描的塊，這樣對(duì)提升查詢速度是很有幫助的。

4）存儲(chǔ)執(zhí)行耦合

存儲(chǔ)和執(zhí)行分離是一個(gè)趨勢(shì)，但是存儲(chǔ)和執(zhí)行耦合也是有優(yōu)勢(shì)的，避免了網(wǎng)絡(luò)的開銷，CPU的極致壓榨加上SSD的加持，每秒的數(shù)據(jù)傳輸對(duì)于網(wǎng)絡(luò)帶寬的壓力是非常大的，耦合部署可以避免該問題。

5）數(shù)據(jù)存儲(chǔ)在SSD，極高的iops。

4、clickhouse的insert和select

1）clickhouse如何完成一次完整的select

這里有個(gè)概念需要澄清一下，clickhouse的表分為兩種，一種是本地表另一種是分布式表。本地表是實(shí)際存儲(chǔ)數(shù)據(jù)的而分布式表是一個(gè)邏輯上的表，不存儲(chǔ)數(shù)據(jù)的只是做一個(gè)路由使用，一般在查詢的時(shí)候都是直接使用分布式表，分布式表引擎會(huì)將我們的查詢請(qǐng)求路由本地表進(jìn)行查詢，然后進(jìn)行匯總最終返回給用戶。

2）索引在查詢中的使用

索引是clickhouse查詢速度比較快的一個(gè)重要原因，正是因?yàn)橛兴饕梢员苊獠槐匾臄?shù)據(jù)的掃描和處理。傳統(tǒng)基于hdfs的olap引擎都是不支持索引的，基本的數(shù)據(jù)過(guò)濾只能支持分區(qū)進(jìn)行過(guò)濾，這樣會(huì)掃描處理很多不必要的數(shù)據(jù)。

clickhouse不僅支持分區(qū)的過(guò)濾也支持列級(jí)別的稀疏索引。clickhouse的基礎(chǔ)索引是使用了和kafka一樣的稀疏索引，索引粒度默認(rèn)是8192，即每8192條數(shù)據(jù)進(jìn)行一次記錄，這樣對(duì)于1億的數(shù)據(jù)只需要記錄12207條記錄，這樣可以很好的節(jié)約空間。

二分查找+遍歷也可以快速的索引到指定的數(shù)據(jù)，當(dāng)然相對(duì)于稠密索引，肯定會(huì)有一定的性能損失，但是在大數(shù)據(jù)量的場(chǎng)景下，使用稠密索引對(duì)存儲(chǔ)也是有壓力的。

下面我們通過(guò)舉例看下索引在clickhouse的一次select中的應(yīng)用，該表的排序情況為order by CounterID, Date 第一排序字段為CounterID，第二排序字段為Date，即先按照CounterID進(jìn)行排序，如果CounterID相同再按照Date進(jìn)行排序。

• 場(chǎng)景1 where CounterId=’a’

CounterID是第一索引列，可以直接定位到CounterId=’a’的數(shù)據(jù)是在[0,3]數(shù)據(jù)塊中。

• 場(chǎng)景2 where Date=’3’

Date為第二索引列，索引起來(lái)有點(diǎn)費(fèi)勁，過(guò)濾效果還不是特別的好，Date=’3’的數(shù)據(jù)定位在[2,10]數(shù)據(jù)塊中。

• 場(chǎng)景3 where CounterId=’a’ and Date=’3’

第一索引 + 第二索引同時(shí)過(guò)濾，[0,3] 和 [2,10]的交集，所以為[2,3]數(shù)據(jù)塊中。

• 場(chǎng)景4 where noIndexColumn=’xxx’

對(duì)于這樣沒有索引字段的查詢就需要直接掃描全部的數(shù)據(jù)塊[0,10]。

3）clickhouse如何完成一次插入

clickhouse的插入是基于Batch的，它不能夠像傳統(tǒng)的mysql那樣頻繁的單條記錄插入，批次的大小從幾千到幾十萬(wàn)不等，需要和列的數(shù)量以及數(shù)據(jù)的特性一起考慮，clickhouse的寫入和Hbase的寫入有點(diǎn)”像”(類LSM-Tree)，主要區(qū)別有：

• 沒有內(nèi)存表；

• 不進(jìn)行日志的記錄。

clickhouse寫入的時(shí)候是直接落盤的, 在落盤之前會(huì)對(duì)數(shù)據(jù)進(jìn)行排序以及必要的拆分(如不同分區(qū)的數(shù)據(jù)會(huì)拆分成多個(gè)文件夾)，如果使用的是ReplicatedMergeTree引擎還需要與zookeeper進(jìn)行交互，最終會(huì)有線程在后臺(tái)把數(shù)據(jù)(文件夾)進(jìn)行合并(merge)，將小文件夾合并生成大文件夾方便查詢的時(shí)候進(jìn)行讀取(小文件會(huì)影響查詢性能)。

5、關(guān)于集群的搭建

1）單副本

缺點(diǎn)：

• 集群中任何一臺(tái)機(jī)器出現(xiàn)故障集群不可用；

• 如果磁盤出現(xiàn)問題不可恢復(fù)數(shù)據(jù)永久丟失；

• 集群升級(jí)期間不可用(clickhouse版本更新快)。

2）多副本

多副本可以完美的解決單副本的所有的問題，多副本有2個(gè)解決方案：

• RAID磁盤陣列；

• 使用ReplicatedMergeTree引擎，clickhouse原生支持同步的引擎(基于zookeeper)。

兩種方案的優(yōu)缺點(diǎn)：

• 基于RAID磁盤陣列的解決方案，在版本升級(jí)，機(jī)器down機(jī)的情況下無(wú)法解決單副本的缺陷；

• 基于zookeeper的同步，需要雙倍的機(jī)器(費(fèi)錢)，同時(shí)對(duì)zookeeper依賴太重，zookeeper會(huì)成為集群的瓶頸，當(dāng)zookeeper有問題的時(shí)候集群不可寫入(ready only mode)；

• 副本不僅僅讓數(shù)據(jù)更安全，查詢的請(qǐng)求也可以路由到副本所在的機(jī)器，這樣對(duì)查詢并發(fā)度的提升也是有幫助的，如果查詢性能跟不上添加副本的數(shù)量也是一個(gè)解決方案。

6、常見的引擎(MergeTree家族)

1）(Replicated)MergeTree

該引擎為最簡(jiǎn)單的引擎，存儲(chǔ)最原始數(shù)據(jù)不做任何的預(yù)計(jì)算，任何在該引擎上的select語(yǔ)句都是在原始數(shù)據(jù)上進(jìn)行操作的，常規(guī)場(chǎng)景使用最為廣泛，其他引擎都是該引擎的一個(gè)變種。

2）(Replicated)SummingMergeTree

該引擎擁有“預(yù)計(jì)算(加法)”的功能。

實(shí)現(xiàn)原理：在merge階段把數(shù)據(jù)加起來(lái)(對(duì)于需要加的列需要在建表的時(shí)候進(jìn)行指定)，對(duì)于不可加的列，會(huì)取一個(gè)最先出現(xiàn)的值。

3）(Replicated)ReplacingMergeTree

該引擎擁有“處理重復(fù)數(shù)據(jù)”的功能。

使用場(chǎng)景：“最新值”，“實(shí)時(shí)數(shù)據(jù)”。

4）(Replicated)AggregatingMergeTree

該引擎擁有“預(yù)聚合”的功能。

使用場(chǎng)景：配合”物化視圖”來(lái)一起使用，擁有毫秒級(jí)計(jì)算UV和PV的能力。

5）(Replicated)CollapsingMergeTree

該引擎和ReplacingMergeTree的功能有點(diǎn)類似，就是通過(guò)一個(gè)sign位去除重復(fù)數(shù)據(jù)的。

需要注意的是，上述所有擁有"預(yù)聚合"能力的引擎都在"Merge"過(guò)程中實(shí)現(xiàn)的，所以在表上進(jìn)行查詢的時(shí)候SQL是需要進(jìn)行特殊處理的。

如SummingMergeTree引擎需要自己sum(), ReplacingMergeTree引擎需要使用時(shí)間+版本進(jìn)行order by + limit來(lái)取到最新的值，由于數(shù)據(jù)做了預(yù)處理，數(shù)據(jù)量已經(jīng)減少了很多，所以查詢速度相對(duì)會(huì)快非常多。

7、最佳實(shí)踐

1）實(shí)時(shí)寫入使用本地表，不要使用分布式表

分布式表引擎會(huì)幫我們將數(shù)據(jù)自動(dòng)路由到健康的數(shù)據(jù)表進(jìn)行數(shù)據(jù)的存儲(chǔ)，所以使用分布式表相對(duì)來(lái)說(shuō)比較簡(jiǎn)單，對(duì)于Producer不需要有太多的考慮，但是分布式表有些致命的缺點(diǎn)。

• 數(shù)據(jù)的一致性問題，先在分布式表所在的機(jī)器進(jìn)行落盤，然后異步的發(fā)送到本地表所在機(jī)器進(jìn)行存儲(chǔ)，中間沒有一致性的校驗(yàn)，而且在分布式表所在機(jī)器時(shí)如果機(jī)器出現(xiàn)down機(jī)，會(huì)存在數(shù)據(jù)丟失風(fēng)險(xiǎn)；

• 據(jù)說(shuō)對(duì)zookeeper的壓力比較大(待驗(yàn)證)。

2）推薦使用(*)MergeTree引擎，該引擎是clickhouse最核心的組件，也是社區(qū)優(yōu)化的重點(diǎn)

數(shù)據(jù)有保障，查詢有保障，升級(jí)無(wú)感知。

3）謹(jǐn)慎使用on cluster的SQL

使用該類型SQL hang住的案例不少，我們也有遇到，可以直接寫個(gè)腳本直接操作集群的每臺(tái)進(jìn)行處理。

8、常見參數(shù)配置推薦

1）max_concurrent_queries

最大并發(fā)處理的請(qǐng)求數(shù)(包含select,insert等)，默認(rèn)值100，推薦150(不夠再加)，在我們的集群中出現(xiàn)過(guò)”max concurrent queries”的問題。

2）max_bytes_before_external_sort

當(dāng)order by已使用max_bytes_before_external_sort內(nèi)存就進(jìn)行溢寫磁盤(基于磁盤排序)，如果不設(shè)置該值，那么當(dāng)內(nèi)存不夠時(shí)直接拋錯(cuò)，設(shè)置了該值order by可以正常完成，但是速度相對(duì)存內(nèi)存來(lái)說(shuō)肯定要慢點(diǎn)(實(shí)測(cè)慢的非常多，無(wú)法接受)。

3）background_pool_size

后臺(tái)線程池的大小，merge線程就是在該線程池中執(zhí)行，當(dāng)然該線程池不僅僅是給merge線程用的，默認(rèn)值16，推薦32提升merge的速度(CPU允許的前提下)。

4）max_memory_usage

單個(gè)SQL在單臺(tái)機(jī)器最大內(nèi)存使用量，該值可以設(shè)置的比較大，這樣可以提升集群查詢的上限。

5）max_memory_usage_for_all_queries

單機(jī)最大的內(nèi)存使用量可以設(shè)置略小于機(jī)器的物理內(nèi)存(留一點(diǎn)內(nèi)操作系統(tǒng))。

6）max_bytes_before_external_group_by

在進(jìn)行g(shù)roup by的時(shí)候，內(nèi)存使用量已經(jīng)達(dá)到了max_bytes_before_external_group_by的時(shí)候就進(jìn)行寫磁盤(基于磁盤的group by相對(duì)于基于磁盤的order by性能損耗要好很多的)，一般max_bytes_before_external_group_by設(shè)置為max_memory_usage / 2，原因是在clickhouse中聚合分兩個(gè)階段：

• 查詢并且建立中間數(shù)據(jù)；

• 合并中間數(shù)據(jù) 寫磁盤在第一個(gè)階段，如果無(wú)須寫磁盤，clickhouse在第一個(gè)和第二個(gè)階段需要使用相同的內(nèi)存。

這些內(nèi)存參數(shù)強(qiáng)烈推薦配置上，增強(qiáng)集群的穩(wěn)定性避免在使用過(guò)程中出現(xiàn)莫名其妙的異常。

9、那些年我們遇到過(guò)的問題

1）Too many parts(304). Merges are processing significantly slower than inserts

相信很多同學(xué)在剛開始使用clickhouse的時(shí)候都有遇到過(guò)該異常，出現(xiàn)異常的原因是因?yàn)镸ergeTree的merge的速度跟不上目錄生成的速度, 數(shù)據(jù)目錄越來(lái)越多就會(huì)拋出這個(gè)異常, 所以一般情況下遇到這個(gè)異常，降低一下插入頻次就ok了，單純調(diào)整background_pool_size的大小是治標(biāo)不治本的。

我們的場(chǎng)景：

我們的插入速度是嚴(yán)格按照官方文檔上面的推薦”每秒不超過(guò)1次的insert request”，但是有個(gè)插入程序在運(yùn)行一段時(shí)間以后拋出了該異常，很奇怪。

問題排查：

排查發(fā)現(xiàn)失敗的這個(gè)表的數(shù)據(jù)有一個(gè)特性，它雖然是實(shí)時(shí)數(shù)據(jù)但是數(shù)據(jù)的eventTime是最近一周內(nèi)的任何時(shí)間點(diǎn)，我們的表又是按照day + hour組合分區(qū)的那么在極限情況下，我們的一個(gè)插入請(qǐng)求會(huì)涉及7*24分區(qū)的數(shù)據(jù)，也就是我們一次插入會(huì)在磁盤上生成168個(gè)數(shù)據(jù)目錄(文件夾)，文件夾的生成速度太快，merge速度跟不上了，所以官方文檔的上每秒不超過(guò)1個(gè)插入請(qǐng)求，更準(zhǔn)確的說(shuō)是每秒不超過(guò)1個(gè)數(shù)據(jù)目錄。

case study：

分區(qū)字段的設(shè)置要慎重考慮，如果每次插入涉及的分區(qū)太多，那么不僅容易出現(xiàn)上面的異常，同時(shí)在插入的時(shí)候也比較耗時(shí)，原因是每個(gè)數(shù)據(jù)目錄都需要和zookeeper進(jìn)行交互。

2）DB::NetException: Connection reset by peer, while reading from socket xxx

查詢過(guò)程中clickhouse-server進(jìn)程掛掉。

問題排查：

排查發(fā)現(xiàn)在這個(gè)異常拋出的時(shí)間點(diǎn)有出現(xiàn)clickhouse-server的重啟，通過(guò)監(jiān)控系統(tǒng)看到機(jī)器的內(nèi)存使用在該時(shí)間點(diǎn)出現(xiàn)高峰，在初期集群"裸奔"的時(shí)期，很多內(nèi)存參數(shù)都沒有進(jìn)行限制，導(dǎo)致clickhouse-server內(nèi)存使用量太高被OS KILL掉。

case study：

上面推薦的內(nèi)存參數(shù)強(qiáng)烈推薦全部加上，max_memory_usage_for_all_queries該參數(shù)沒有正確設(shè)置是導(dǎo)致該case觸發(fā)的主要原因。

3）Memory limit (for query) exceeded:would use 9.37 GiB (attempt to allocate chunk of 301989888 bytes), maximum: 9.31 GiB

該異常很直接，就是我們限制了SQL的查詢內(nèi)存(max_memory_usage)使用的上線，當(dāng)內(nèi)存使用量大于該值的時(shí)候，查詢被強(qiáng)制KILL。

對(duì)于常規(guī)的如下簡(jiǎn)單的SQL, 查詢的空間復(fù)雜度為O(1) 。

select count(1) from table where condition1 and condition2?

select c1, c2 from table where condition1 and condition2

對(duì)于group by, order by , count distinct，join這樣的復(fù)雜的SQL，查詢的空間復(fù)雜度就不是O(1)了，需要使用大量的內(nèi)存。

• 如果是group by內(nèi)存不夠，推薦配置上max_bytes_before_external_group_by參數(shù)，當(dāng)使用內(nèi)存到達(dá)該閾值，進(jìn)行磁盤group by

• 如果是order by內(nèi)存不夠，推薦配置上max_bytes_before_external_sort參數(shù)，當(dāng)使用內(nèi)存到達(dá)該閾值，進(jìn)行磁盤order by

• 如果是count distinct內(nèi)存不夠，推薦使用一些預(yù)估函數(shù)(如果業(yè)務(wù)場(chǎng)景允許)，這樣不僅可以減少內(nèi)存的使用同時(shí)還會(huì)提示查詢速度

• 對(duì)于JOIN場(chǎng)景，我們需要注意的是clickhouse在進(jìn)行JOIN的時(shí)候都是將"右表"進(jìn)行多節(jié)點(diǎn)的傳輸?shù)?右表廣播)，如果你已經(jīng)遵循了該原則還是無(wú)法跑出來(lái)，那么好像也沒有什么好辦法了

4）zookeeper的snapshot文件太大，follower從leader同步文件時(shí)超時(shí)

上面有說(shuō)過(guò)clickhouse對(duì)zookeeper的依賴非常的重，表的元數(shù)據(jù)信息，每個(gè)數(shù)據(jù)塊的信息，每次插入的時(shí)候，數(shù)據(jù)同步的時(shí)候，都需要和zookeeper進(jìn)行交互，上面存儲(chǔ)的數(shù)據(jù)非常的多。

就拿我們自己的集群舉例，我們集群有60臺(tái)機(jī)器30張左右的表，數(shù)據(jù)一般只存儲(chǔ)2天，我們zookeeper集群的壓力 已經(jīng)非常的大了，zookeeper的節(jié)點(diǎn)數(shù)據(jù)已經(jīng)到達(dá)500w左右，一個(gè)snapshot文件已經(jīng)有2G+左右的大小了，zookeeper節(jié)點(diǎn)之間的數(shù)據(jù)同步已經(jīng)經(jīng)常性的出現(xiàn)超時(shí)。?

問題解決：

• zookeeper的snapshot文件存儲(chǔ)盤不低于1T，注意清理策略，不然磁盤報(bào)警報(bào)到你懷疑人生，如果磁盤爆了那集群就處于“殘廢”狀態(tài)；?

• zookeeper集群的znode最好能在400w以下；?

• 建表的時(shí)候添加use_minimalistic_part_header_in_zookeeper參數(shù)，對(duì)元數(shù)據(jù)進(jìn)行壓縮存儲(chǔ)，對(duì)于高版本的clickhouse可以直接在原表上面修改該setting信息，注意修改完了以后無(wú)法再回滾的。

5）zookeeper壓力太大，clickhouse表處于”read only mode”，插入失敗

• zookeeper機(jī)器的snapshot文件和log文件最好分盤存儲(chǔ)(推薦SSD)提高ZK的響應(yīng)；

• 做好zookeeper集群和clickhouse集群的規(guī)劃，可以多套zookeeper集群服務(wù)一套clickhouse集群。

>>>>

直播回放

• https://m.qlchat.com/topic/details?pro_cl=link&ch_r=shareR1&userSourceId=71afe6749b850&shareSourceId=oeh5hk16f54e3143c&topicId=2000006223835755

>>>>

活動(dòng)推薦

2020年4月17日，北京，Gdevops全球敏捷運(yùn)維峰會(huì)將開啟年度首站！重點(diǎn)圍繞數(shù)據(jù)庫(kù)、智慧運(yùn)維、Fintech金融科技領(lǐng)域，攜手阿里、騰訊、螞蟻金服、中國(guó)銀行、平安銀行、中郵消費(fèi)金融、中國(guó)農(nóng)業(yè)銀行、中國(guó)民生銀行、中國(guó)聯(lián)通大數(shù)據(jù)、浙江移動(dòng)、新炬網(wǎng)絡(luò)等技術(shù)代表，展望云時(shí)代下數(shù)據(jù)庫(kù)發(fā)展趨勢(shì)、破解運(yùn)維轉(zhuǎn)型困局。

總結(jié)

以上是生活随笔為你收集整理的趣头条基于ClickHouse玩转每天1000亿数据量的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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