文章目錄

• OLAP
• • 什么是OLAP?
  • OLAP與OLTP
• 列式存儲(chǔ)
• • 列式存儲(chǔ)與行式存儲(chǔ)
  • 列式存儲(chǔ)與OLAP
  • 列式存儲(chǔ)與數(shù)據(jù)壓縮
• 核心特點(diǎn)
• • 完備的DBMS功能
  • 關(guān)系模型與SQL查詢
  • 向量化表引擎
  • 多樣化的表引擎
  • 多主架構(gòu)
  • 多線程與分布式
  • 分片與分布式查詢
• 應(yīng)用場(chǎng)景
• • 擅長(zhǎng)的場(chǎng)景
  • 不擅長(zhǎng)的場(chǎng)景
• Clickhouse為什么會(huì)這么快？
• 架構(gòu)

---

ClickHouse是一個(gè)用于聯(lián)機(jī)分析(OLAP)的列式數(shù)據(jù)庫管理系統(tǒng)(DBMS)。

OLAP

什么是OLAP?

OLAP名為聯(lián)機(jī)分析，又可以稱為多維分析，是由關(guān)系型數(shù)據(jù)庫之父埃德加·科德（EdgarFrank Codd）于1993年提出的概念。顧名思義，它指的是通過多種不同的維度審視數(shù)據(jù)，進(jìn)行深層次分析。

維度可以看作觀察數(shù)據(jù)的一種視角，例如人類能看到的世界是三維的，它包含長(zhǎng)、寬、高三個(gè)維度。直接一點(diǎn)理解，維度就好比是一張數(shù)據(jù)表的字段，而多維分析則是基于這些字段進(jìn)行聚合查詢。

多維分析的常見操作

如上圖，多維分析包含以下幾種操作：

• 下鉆：從高層次向低層次明細(xì)數(shù)據(jù)穿透，例如從省下鉆到市。
• 上卷：和下鉆相反，從低層次向高層次匯聚，例如從市匯聚成省。
• 切片：觀察立方體的一層，將一個(gè)或多個(gè)維度設(shè)為單個(gè)固定值，然后觀察剩余的維度，例如將商品維度固定為足球。
• 切塊：與切片類似，只是將單個(gè)固定值變成多個(gè)值。例如將商品維度固定成足球、籃球。
• 旋轉(zhuǎn)：旋轉(zhuǎn)立方體的一面，如果要將數(shù)據(jù)映射到一張二維表，那么就要進(jìn)行旋轉(zhuǎn)，這就等同于行列置換。

OLAP與OLTP

OLTP（on-line transaction processing）翻譯為聯(lián)機(jī)事務(wù)處理， OLAP（On-Line Analytical Processing）翻譯為聯(lián)機(jī)分析處理。

• 從字面上來看OLTP是做事務(wù)處理，OLAP是做分析處理。
• 從對(duì)數(shù)據(jù)庫操作來看，OLTP主要是對(duì)數(shù)據(jù)的增刪改，OLAP是對(duì)數(shù)據(jù)的查詢。
• 因?yàn)镺LTP所產(chǎn)生的業(yè)務(wù)數(shù)據(jù)分散在不同的業(yè)務(wù)系統(tǒng)中，而OLAP往往需要將不同的業(yè)務(wù)數(shù)據(jù)集中到一起進(jìn)行統(tǒng)一綜合的分析，這時(shí)候就需要根據(jù)業(yè)務(wù)分析需求做對(duì)應(yīng)的數(shù)據(jù)清洗后存儲(chǔ)在數(shù)據(jù)倉庫中，然后由數(shù)據(jù)倉庫來統(tǒng)一提供OLAP分析。
• OLTP是數(shù)據(jù)庫的應(yīng)用，OLAP是數(shù)據(jù)倉庫的應(yīng)用

下面用一張圖來簡(jiǎn)要對(duì)比。

OLTP與OLAP

列式存儲(chǔ)

列式存儲(chǔ)與行式存儲(chǔ)

在傳統(tǒng)的行式數(shù)據(jù)庫系統(tǒng)中，處于同一行中的數(shù)據(jù)總是被物理的存儲(chǔ)在一起，存儲(chǔ)方式如下圖

行式存儲(chǔ)

在列式數(shù)據(jù)庫系統(tǒng)中，來自不同列的值被單獨(dú)存儲(chǔ)，來自同一列的數(shù)據(jù)被存儲(chǔ)在一起，數(shù)據(jù)按如下的順序存儲(chǔ)：

列式存儲(chǔ)

按行存儲(chǔ)與按列存儲(chǔ)的區(qū)別

不同的數(shù)據(jù)存儲(chǔ)方式適用不同的業(yè)務(wù)場(chǎng)景，而對(duì)于OLAP來說，列式存儲(chǔ)是最適合的選擇。

列式存儲(chǔ)與OLAP

為什么列式數(shù)據(jù)庫更適合于OLAP場(chǎng)景呢？下面這兩張圖就可以給你答案

• 行式數(shù)據(jù)庫
• 列式數(shù)據(jù)庫

下面分別從兩個(gè)I/O和CPU兩個(gè)角度來分析為什么他們有如此之大的差別

• I/O
  • 針對(duì)分析類查詢，通常只需要讀取表的一小部分列。在列式數(shù)據(jù)庫中你可以只讀取你需要的數(shù)據(jù)。
  • 由于數(shù)據(jù)總是打包成批量讀取的，所以壓縮是非常容易的。同時(shí)數(shù)據(jù)按列分別存儲(chǔ)這也更容易壓縮。這進(jìn)一步降低了I/O的體積。
  • 由于I/O的降低，這將幫助更多的數(shù)據(jù)被系統(tǒng)緩存,進(jìn)一步降低了數(shù)據(jù)傳輸?shù)某杀尽?/li>
• CPU
  • 由于執(zhí)行一個(gè)查詢需要處理大量的行，因此在整個(gè)向量上執(zhí)行所有操作將比在每一行上執(zhí)行所有操作更加高效。同時(shí)這將有助于實(shí)現(xiàn)一個(gè)幾乎沒有調(diào)用成本的查詢引擎。如果你不這樣做，使用任何一個(gè)機(jī)械硬盤，查詢引擎都不可避免的停止CPU進(jìn)行等待。所以，在數(shù)據(jù)按列存儲(chǔ)并且按列執(zhí)行是很有意義的。

列式存儲(chǔ)與數(shù)據(jù)壓縮

如果你想讓查詢變得更快，最簡(jiǎn)單且有效的方法是減少數(shù)據(jù)掃描范圍和數(shù)據(jù)傳輸時(shí)的大小，而列式存儲(chǔ)和數(shù)據(jù)壓縮就可以幫助我們實(shí)現(xiàn)上述兩點(diǎn)。

列式存儲(chǔ)和數(shù)據(jù)壓縮通常是伴生的。數(shù)據(jù)按列存儲(chǔ)。而具體到每個(gè)列字段，數(shù)據(jù)也是獨(dú)立存儲(chǔ)的，每個(gè)列字段都擁有一個(gè)與之對(duì)應(yīng)的.bin數(shù)據(jù)文件，相同類型的數(shù)據(jù)放在同一個(gè)文件中，對(duì)壓縮更加友好。數(shù)據(jù)默認(rèn)使用LZ4算法壓縮，在Yandex.Metrica的生產(chǎn)環(huán)境中，數(shù)據(jù)總體的壓縮比可以達(dá)到8:1（未壓縮前17PB，壓縮后2PB）。

核心特點(diǎn)

完備的DBMS功能

ClickHouse擁有完備的管理功能，所以它稱得上是一個(gè)DBMS（Database Management System，數(shù)據(jù)庫管理系統(tǒng)），而不僅是一個(gè)數(shù)據(jù)庫。作為一個(gè)DBMS，它具備了一些基本功能，

如下所示。

• DDL（數(shù)據(jù)定義語言）：可以動(dòng)態(tài)地創(chuàng)建、修改或刪除數(shù)據(jù)庫、表和視圖，而無須重啟服務(wù)。
• DML（數(shù)據(jù)操作語言）：可以動(dòng)態(tài)查詢、插入、修改或刪除數(shù)據(jù)。
• 權(quán)限控制：可以按照用戶粒度設(shè)置數(shù)據(jù)庫或者表的操作權(quán)限，保障數(shù)據(jù)的安全性。
• 數(shù)據(jù)備份與恢復(fù)：提供了數(shù)據(jù)備份導(dǎo)出與導(dǎo)入恢復(fù)機(jī)制，滿足生產(chǎn)環(huán)境的要求。
• 分布式管理：提供集群模式，能夠自動(dòng)管理多個(gè)數(shù)據(jù)庫節(jié)點(diǎn)。

關(guān)系模型與SQL查詢

相比HBase和Redis這類NoSQL數(shù)據(jù)庫，ClickHouse使用關(guān)系模型描述數(shù)據(jù)并提供了傳統(tǒng)數(shù)據(jù)庫的概念（數(shù)據(jù)庫、表、視圖和函數(shù)等）。與此同時(shí)，ClickHouse完全使用SQL作為查詢語言（支持GROUP BY、ORDER BY、JOIN、IN等大部分標(biāo)準(zhǔn)SQL），這使得它平易近人，容易理解和學(xué)習(xí)。

向量化表引擎

向量化執(zhí)行，可以簡(jiǎn)單地看作從硬件的角度上消除程序中循環(huán)的優(yōu)化。

為了實(shí)現(xiàn)向量化執(zhí)行，需要利用CPU的SIMD指令。SIMD的全稱是Single Instruction MultipleData，即用單條指令操作多條數(shù)據(jù)。現(xiàn)代計(jì)算機(jī)系統(tǒng)概念中，它是通過數(shù)據(jù)并行以提高性能的一種實(shí)現(xiàn)方式，它的原理是在CPU寄存器層面實(shí)現(xiàn)數(shù)據(jù)的并行操作。例如有8個(gè)32位整形數(shù)據(jù)都需要進(jìn)行移位運(yùn)行，則由一條對(duì)32位整形數(shù)據(jù)進(jìn)行移位的指令重復(fù)執(zhí)行8次完成。SIMD引入了一組大容量的寄存器，一個(gè)寄存器包含8 * 32位，可以將這8個(gè)數(shù)據(jù)按次序同時(shí)放到一個(gè)寄存器。同時(shí)，CPU新增了處理這種8 * 32位寄存器的指令，可以在一個(gè)指令周期內(nèi)完成8個(gè)數(shù)據(jù)的位移運(yùn)算。（本質(zhì)就是將每次處理的數(shù)據(jù)從一條變?yōu)橐慌?#xff09;

多樣化的表引擎

與MySQL類似，ClickHouse也將存儲(chǔ)部分進(jìn)行了抽象，把存儲(chǔ)引擎作為一層獨(dú)立的接口。ClickHouse共擁有合并樹、內(nèi)存、文件、接口和其他6大類20多種表引擎。其中每一種表引擎都有著各自的特點(diǎn)，用戶可以根據(jù)實(shí)際業(yè)務(wù)場(chǎng)景的要求，選擇合適的表引擎使用。

多主架構(gòu)

ClickHouse則采用Multi-Master多主架構(gòu)，集群中的每個(gè)節(jié)點(diǎn)角色對(duì)等，客戶端訪問任意一個(gè)節(jié)點(diǎn)都能得到相同的效果。這種多主的架構(gòu)有許多優(yōu)勢(shì)，例如對(duì)等的角色使系統(tǒng)架構(gòu)變得更加簡(jiǎn)單，不用再區(qū)分主控節(jié)點(diǎn)、數(shù)據(jù)節(jié)點(diǎn)和計(jì)算節(jié)點(diǎn)，集群中的所有節(jié)點(diǎn)功能相同。所以它天然規(guī)避了單點(diǎn)故障的問題，非常適合用于多數(shù)據(jù)中心、異地多活的場(chǎng)景。

多線程與分布式

在各服務(wù)器之間，通過網(wǎng)絡(luò)傳輸數(shù)據(jù)的成本是高昂的，所以相比移動(dòng)數(shù)據(jù)，更為聰明的做法是預(yù)先將數(shù)據(jù)分布到各臺(tái)服務(wù)器，將數(shù)據(jù)的計(jì)算查詢直接下推到數(shù)據(jù)所在的服務(wù)器。ClickHouse在數(shù)據(jù)存取方面，既支持分區(qū)（縱向擴(kuò)展，利用多線程原理），也支持分片（橫向擴(kuò)展，利用分布式原理），可以說是將多線程和分布式的技術(shù)應(yīng)用到了極致。

分片與分布式查詢

數(shù)據(jù)分片是將數(shù)據(jù)進(jìn)行橫向切分，這是一種在面對(duì)海量數(shù)據(jù)的場(chǎng)景下，解決存儲(chǔ)和查詢瓶頸的有效手段，是一種分治思想的體現(xiàn)。ClickHouse支持分片，而分片則依賴集群。每個(gè)集群由1到多個(gè)分片組成，而每個(gè)分片則對(duì)應(yīng)了ClickHouse的1個(gè)服務(wù)節(jié)點(diǎn)。分片的數(shù)量上限取決于節(jié)點(diǎn)數(shù)量（1個(gè)分片只能對(duì)應(yīng)1個(gè)服務(wù)節(jié)點(diǎn)）。

ClickHouse并不像其他分布式系統(tǒng)那樣，擁有高度自動(dòng)化的分片功能。ClickHouse提供了** 本地表（Local Table）** 與 **分布式表（Distributed Table）**的概念。一張本地表等同于一份數(shù)據(jù)的分片，而分布式表本身不存儲(chǔ)任何數(shù)據(jù)，它是本地表的訪問代理，其作用類似分庫中間件。借助分布式表，能夠代理訪問多個(gè)數(shù)據(jù)分片，從而實(shí)現(xiàn)分布式查詢。

應(yīng)用場(chǎng)景

擅長(zhǎng)的場(chǎng)景

• 絕大多數(shù)是讀請(qǐng)求
• 數(shù)據(jù)以相當(dāng)大的批次(> 1000行)更新，而不是單行更新;或者根本沒有更新。
• 已添加到數(shù)據(jù)庫的數(shù)據(jù)不能修改。
• 對(duì)于讀取，從數(shù)據(jù)庫中提取相當(dāng)多的行，但只提取列的一小部分。
• 寬表，即每個(gè)表包含著大量的列
• 查詢相對(duì)較少(通常每臺(tái)服務(wù)器每秒查詢數(shù)百次或更少)
• 對(duì)于簡(jiǎn)單查詢，允許延遲大約50毫秒
• 列中的數(shù)據(jù)相對(duì)較小：數(shù)字和短字符串(例如，每個(gè)URL 60個(gè)字節(jié))
• 處理單個(gè)查詢時(shí)需要高吞吐量(每臺(tái)服務(wù)器每秒可達(dá)數(shù)十億行)
• 事務(wù)不是必須的
• 對(duì)數(shù)據(jù)一致性要求低
• 每個(gè)查詢有一個(gè)大表。除了他以外，其他的都很小。
• 查詢結(jié)果明顯小于源數(shù)據(jù)。換句話說，數(shù)據(jù)經(jīng)過過濾或聚合，因此結(jié)果適合于單個(gè)服務(wù)器的RAM中

不擅長(zhǎng)的場(chǎng)景

• OLTP事務(wù)性操作（不支持事務(wù)，不支持真正的更新/刪除）
• 不擅長(zhǎng)根據(jù)主鍵按行粒度進(jìn)行查詢（如select * from table where user_id in (xxx, xxx, xxx, …)）
• 不擅長(zhǎng)存儲(chǔ)和查詢 blob 或者大量文本類數(shù)據(jù)（按列存儲(chǔ)）
• 不擅長(zhǎng)執(zhí)行有大量join的查詢（Distributed引擎局限）
• 不支持高并發(fā)，官方建議QPS <= 100

Clickhouse為什么會(huì)這么快？

首先亮出官方的測(cè)試報(bào)告

Clickhouse性能對(duì)比報(bào)告

所有用于對(duì)比的數(shù)據(jù)庫都使用了相同配置的服務(wù)器，在單個(gè)節(jié)點(diǎn)的情況下，對(duì)一張擁有133個(gè)字段的數(shù)據(jù)表分別在1000萬、1億和10億三種數(shù)據(jù)體量下執(zhí)行基準(zhǔn)測(cè)試，基準(zhǔn)測(cè)試的范圍涵蓋43項(xiàng)SQL查詢。

各個(gè)存儲(chǔ)中間件在一億數(shù)據(jù)下的OLAP查詢性能對(duì)比

市面上有很多與Clickhouse采用了同樣技術(shù)(如列式存儲(chǔ)、向量化引擎等)的數(shù)據(jù)庫，但為什么ClickHouse的性能能夠?qū)⑵渌麛?shù)據(jù)庫遠(yuǎn)遠(yuǎn)甩在身后呢？這主要依賴于下面幾個(gè)方面

ClickHouse為什么那么快？

• 著眼硬件，先想后做
  • ClickHouse會(huì)在內(nèi)存中進(jìn)行GROUP BY，并且使用HashTable裝載數(shù)據(jù)。
  • ClickHouse非常在意CPU L3級(jí)別的緩存，因?yàn)橐淮蜭3的緩存失效會(huì)帶來70～100ns的延遲。這意味著在單核CPU上，它會(huì)浪費(fèi)4000萬次/秒的運(yùn)算；而在一個(gè)32線程的CPU上，則可能會(huì)浪費(fèi)5億次/秒的運(yùn)算。
• 算法在前，抽象在后
  • 對(duì)于常量，使用Volnitsky算法；
  • 對(duì)于非常量，使用CPU的向量化執(zhí)行SIMD（用于文本轉(zhuǎn)換、數(shù)據(jù)過濾、數(shù)據(jù)解壓和JSON轉(zhuǎn)換等），暴力優(yōu)化；
  • 正則匹配使用re2和hyperscan算法。性能是算法選擇的首要考量指標(biāo)。
• 勇于嘗鮮，不行就換
  • 除了字符串之外，其余的場(chǎng)景也與它類似，ClickHouse會(huì)使用最合適、最快的算法。如果世面上出現(xiàn)了號(hào)稱性能強(qiáng)大的新算法，ClickHouse團(tuán)隊(duì)會(huì)立即將其納入并進(jìn)行驗(yàn)證。如果效果不錯(cuò)，就保留使用；如果性能不盡人意，就將其拋棄。
• 特定場(chǎng)景，特殊優(yōu)化
  • 針對(duì)同一個(gè)場(chǎng)景的不同狀況，選擇使用不同的實(shí)現(xiàn)方式，盡可能將性能最大化。
  • 例如去重計(jì)數(shù)uniqCombined函數(shù)，會(huì)根據(jù)數(shù)據(jù)量的不同選擇不同的算法：當(dāng)數(shù)據(jù)量較小的時(shí)候，會(huì)選擇Array保存；當(dāng)數(shù)據(jù)量中等的時(shí)候，會(huì)選擇HashSet；而當(dāng)數(shù)據(jù)量很大的時(shí)候，則使用HyperLogLog算法。
  • 針對(duì)不同的場(chǎng)景，Clickhouse提供了MergeTree引擎家族，如MergeTree、ReplacingMergeTree、SummingMergeTree、AggregatingMergeTree、CollapsingMergeTree和VersionedCollapsingMergeTree等。
• 持續(xù)測(cè)試，持續(xù)改進(jìn)
  • 由于Yandex的天然優(yōu)勢(shì)，ClickHouse經(jīng)常會(huì)使用真實(shí)的數(shù)據(jù)進(jìn)行測(cè)試，這一點(diǎn)很好地保證了測(cè)試場(chǎng)景的真實(shí)性。
  • ClickHouse差不多每個(gè)月都能發(fā)布一個(gè)版本，正因?yàn)閾碛羞@樣的發(fā)版頻率，ClickHouse才能夠快速迭代、快速改進(jìn)。

架構(gòu)

目前ClickHouse公開的資料相對(duì)匱乏，比如在架構(gòu)設(shè)計(jì)層面就很難找到完整的資料，甚至連一張整體的架構(gòu)圖都沒有，根據(jù)官網(wǎng)提供的信息，我們能夠得出一個(gè)大概的架構(gòu)，如下圖

• Parser：Parser分析器可以將一條SQL語句以遞歸下降的方法解析成AST語法樹的形式。不同的SQL語句，會(huì)經(jīng)由不同的Parser實(shí)現(xiàn)類解析。

• Interpreter：Interpreter解釋器的作用就像Service服務(wù)層一樣，起到串聯(lián)整個(gè)查詢過程的作用，它會(huì)根據(jù)解釋器的類型，聚合它所需要的資源。首先它會(huì)解析AST對(duì)象；然后執(zhí)行“業(yè)務(wù)邏輯”（例如分支判斷、設(shè)置參數(shù)、調(diào)用接口等）；最終返回IBlock對(duì)象，以線程的形式建立起一個(gè)查詢執(zhí)行管道。

• Tables：Tables由 IStorage 接口表示。該接口的不同實(shí)現(xiàn)對(duì)應(yīng)不同的表引擎。比如 StorageMergeTree、StorageMemory 等。這些類的實(shí)例就是表。

  • IStorage接口定義了DDL（如ALTER、RENAME、OPTIMIZE和DROP等）、read和write方法，它們分別負(fù)責(zé)數(shù)據(jù)的定義、查詢與寫入。在數(shù)據(jù)查詢時(shí)，IStorage負(fù)責(zé)根據(jù)AST查詢語句的指示要求，返回指定列的原始數(shù)據(jù)。
  • 后續(xù)對(duì)數(shù)據(jù)的進(jìn)一步加工、計(jì)算和過濾，則會(huì)統(tǒng)一交由Interpreter解釋器對(duì)象處理。對(duì)Table發(fā)起的一次操作通常都會(huì)經(jīng)歷這樣的過程，接收AST查詢語句，根據(jù)AST返回指定列的數(shù)據(jù)，之后再將數(shù)據(jù)交由Interpreter做進(jìn)一步處理。

• Block與Block Streams：ClickHouse內(nèi)部的數(shù)據(jù)操作是面向Block對(duì)象進(jìn)行的，并且采用了流的形式。

  • Block：雖然Column和Filed組成了數(shù)據(jù)的基本映射單元，但對(duì)應(yīng)到實(shí)際操作，它們還缺少了一些必要的信息，比如數(shù)據(jù)的類型及列的名稱。于是ClickHouse設(shè)計(jì)了Block對(duì)象，Block對(duì)象可以看作數(shù)據(jù)表的子集。Block對(duì)象的本質(zhì)是由數(shù)據(jù)對(duì)象、數(shù)據(jù)類型和列名稱組成的三元組，即Column、DataType及列名稱字符串。Column提供了數(shù)據(jù)的讀取能力，而DataType知道如何正反序列化，所以Block在這些對(duì)象的基礎(chǔ)之上實(shí)現(xiàn)了進(jìn)一步的抽象和封裝，從而簡(jiǎn)化了整個(gè)使用的過程，僅通過Block對(duì)象就能完成一系列的數(shù)據(jù)操作。在具體的實(shí)現(xiàn)過程中，Block并沒有直接聚合Column和DataType對(duì)象，而是通過ColumnWithTypeAndName對(duì)象進(jìn)行間接引用。
  • Block Streams：Block Streams用于處理數(shù)據(jù)。我們可以使用Block Streams從某個(gè)地方讀取數(shù)據(jù)，執(zhí)行數(shù)據(jù)轉(zhuǎn)換，或?qū)?shù)據(jù)寫到某個(gè)地方。IBlockInputStream 具有 read 方法，其能夠在數(shù)據(jù)可用時(shí)獲取下一個(gè)塊。IBlockOutputStream 具有 write 方法，其能夠?qū)K寫到某處。

• Functions：ClickHouse主要提供兩類函數(shù)——普通函數(shù)和聚合函數(shù)。

  • Function：普通函數(shù)由IFunction接口定義，其是沒有狀態(tài)的，函數(shù)效果作用于每行數(shù)據(jù)之上。當(dāng)然，在函數(shù)具體執(zhí)行的過程中，并不會(huì)一行一行地運(yùn)算，而是采用向量化的方式直接作用于一整列數(shù)據(jù)。
  • AggregateFunction：聚合函數(shù)由IAggregateFunction接口定義，相比無狀態(tài)的普通函數(shù)，聚合函數(shù)是有狀態(tài)的，并且聚合函數(shù)的狀態(tài)支持序列化與反序列化，所以能夠在分布式節(jié)點(diǎn)之間進(jìn)行傳輸，以實(shí)現(xiàn)增量計(jì)算。

• DataType：數(shù)據(jù)的序列化和反序列化工作由DataType負(fù)責(zé)。根據(jù)不同的數(shù)據(jù)類型，IDataType接口會(huì)有不同的實(shí)現(xiàn)類。DataType雖然會(huì)對(duì)數(shù)據(jù)進(jìn)行正反序列化，但是它不會(huì)直接和內(nèi)存或者磁盤做交互，而是轉(zhuǎn)交給Column和Filed處理。

• Column與Field：Column和Field是ClickHouse數(shù)據(jù)最基礎(chǔ)的映射單元。

  • Column：內(nèi)存中的一列數(shù)據(jù)由一個(gè)Column對(duì)象表示。Column對(duì)象分為接口和實(shí)現(xiàn)兩個(gè)部分，在IColumn接口對(duì)象中，定義了對(duì)數(shù)據(jù)進(jìn)行各種關(guān)系運(yùn)算的方法，例如插入數(shù)據(jù)的insertRangeFrom和insertFrom方法、用于分頁的cut，以及用于過濾的filter方法等。而這些方法的具體實(shí)現(xiàn)對(duì)象則根據(jù)數(shù)據(jù)類型的不同，由相應(yīng)的對(duì)象實(shí)現(xiàn)。
  • Field：在大多數(shù)場(chǎng)合，ClickHouse都會(huì)以整列的方式操作數(shù)據(jù)，但凡事也有例外。如果需要操作單個(gè)具體的數(shù)值（也就是單列中的一行數(shù)據(jù)），則需要使用Field對(duì)象，Field對(duì)象代表一個(gè)單值。與Column對(duì)象的泛化設(shè)計(jì)思路不同，Field對(duì)象使用了聚合的設(shè)計(jì)模式。在Field對(duì)象內(nèi)部聚合了Null、UInt64、String和Array等13種數(shù)據(jù)類型及相應(yīng)的處理邏輯。

總結(jié)

以上是生活随笔為你收集整理的战斗民族开源神器。ClickHouse为什么能够征服各个大厂？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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