任明浩

摘要：在數(shù)據(jù)量日益增長的當(dāng)下，傳統(tǒng)數(shù)據(jù)庫的查詢性能已滿足不了業(yè)務(wù)需求。近年來大量開源架構(gòu)為探索流批一體實(shí)時(shí)數(shù)倉的大數(shù)據(jù)研發(fā)工程師提供了豐富的資源，同時(shí)也增加了工程師在學(xué)習(xí)成本、框架的多樣化和復(fù)雜度等方面選擇合適工具的難度。此情景下，整合開源框架、工具、庫、平臺(tái)勢在必行。該文引入Clickhouse數(shù)據(jù)庫管理系統(tǒng)，并在數(shù)字化油田構(gòu)建實(shí)時(shí)數(shù)倉的建設(shè)中構(gòu)想其應(yīng)用前景。

關(guān)鍵詞：OLAP;大數(shù)據(jù);Clickhouse

中圖分類號(hào)：TP3? ? ? ? 文獻(xiàn)標(biāo)識(shí)碼：A

文章編號(hào)：1009-3044（2022）21-0015-03

開放科學(xué)（資源服務(wù)）標(biāo)識(shí)碼（OSID）：

油田開發(fā)中后期，開采成本日益上升，為了降本增效以及提高整個(gè)企業(yè)的安全狀況，物聯(lián)網(wǎng)及數(shù)據(jù)工程師考慮依靠數(shù)據(jù)驅(qū)動(dòng)油田，將大數(shù)據(jù)技術(shù)用于監(jiān)控設(shè)備性能和環(huán)境條件。通過使用制造業(yè)和工程行業(yè)的先進(jìn)技術(shù)，架設(shè)于設(shè)備上的傳感器可以收集現(xiàn)場操作中的數(shù)據(jù)，并用于保障原油平穩(wěn)安全生產(chǎn)的可行性分析[1]。未來數(shù)字化建設(shè)考慮數(shù)據(jù)中臺(tái)，將原本存在各關(guān)系型數(shù)據(jù)庫、實(shí)時(shí)歷史數(shù)據(jù)庫、非結(jié)構(gòu)化數(shù)據(jù)庫等的數(shù)據(jù)實(shí)時(shí)接入數(shù)據(jù)區(qū)域湖，區(qū)域湖再將不同類型的數(shù)據(jù)模型進(jìn)行歸一化處理，并且在數(shù)據(jù)分析平臺(tái)提供統(tǒng)一的查詢?nèi)肟?，再由油藏、采油工程師找到?shù)據(jù)背后有價(jià)值的信息，在大數(shù)據(jù)中預(yù)測分析，指導(dǎo)生產(chǎn)。

而今，大量開源架構(gòu)為探索流批一體實(shí)時(shí)數(shù)倉的大數(shù)據(jù)研發(fā)工程師提供了豐富的資源，同時(shí)也增加了工程師選擇合適工具的難度，主要體現(xiàn)在學(xué)習(xí)成本、框架的多樣化和復(fù)雜度。如Kafka、HDFS、Spark、Hive等大數(shù)據(jù)生態(tài)技術(shù)經(jīng)過組合才能產(chǎn)生最后的分析結(jié)果。此情景下，整合開源框架、工具、庫、平臺(tái)勢在必行。

面向智慧油田的數(shù)據(jù)管控體系主要研究在“采”“存”“管”“用”四個(gè)方面。

“采”：數(shù)據(jù)變更抓取系統(tǒng)，解決多源異構(gòu)數(shù)據(jù)一致性的問題。相較于專注流程控制和中間處理過程靈活性但不追求性能的傳統(tǒng)數(shù)據(jù)提取轉(zhuǎn)換和加載系統(tǒng)而言，數(shù)據(jù)變更抓取系統(tǒng)對(duì)實(shí)時(shí)性要求比較高。

“存”“管”：數(shù)倉分層存儲(chǔ)和維度表管理均由數(shù)據(jù)湖承擔(dān)。

“用”：一個(gè)思路是將聚合分析計(jì)算由數(shù)據(jù)分析引擎承擔(dān)。相較于Flink、Spark或者Storm，它的優(yōu)點(diǎn)是自由度高，可以滿足實(shí)時(shí)分析需求，減輕實(shí)時(shí)計(jì)算部分的聚合處理壓力;缺點(diǎn)是必須要求消息隊(duì)列中保存存量數(shù)據(jù)，且因?yàn)槭菍⒂?jì)算部分的壓力轉(zhuǎn)移到了查詢層，對(duì)查詢引擎的吞吐和實(shí)時(shí)攝入性能要求較高。

本文主要對(duì)基于數(shù)據(jù)分析引擎的云數(shù)據(jù)庫管理系統(tǒng)Clickhouse在“用”的方面即查詢分析方面做深入探討。

1 Clickhouse概述

1.1 Clickhouse發(fā)展迅猛

Yandex在2016年6月15日開源了一個(gè)數(shù)據(jù)分析的數(shù)據(jù)庫管理系統(tǒng)，即ClickHouse，它是分布式實(shí)時(shí)分析型列式存儲(chǔ)數(shù)據(jù)庫管理系統(tǒng)，主要用于數(shù)據(jù)分析領(lǐng)域。開源時(shí)間雖短，但是社區(qū)熱度高，跑分超過很多流行的商業(yè)數(shù)據(jù)庫軟件。各個(gè)大廠紛紛跟進(jìn)大規(guī)模使用。今日頭條內(nèi)部用ClickHouse來做用戶行為分析，內(nèi)部一共幾千個(gè)ClickHouse節(jié)點(diǎn)，單集群最大1200節(jié)點(diǎn)，總數(shù)據(jù)量幾十PB，日增原始數(shù)據(jù)300TB左右。騰訊內(nèi)部用ClickHouse做游戲數(shù)據(jù)分析，并且為之建立了一整套監(jiān)控運(yùn)維體系。攜程內(nèi)部從2018年7月開始接入試用，目前80%的業(yè)務(wù)都跑在ClickHouse上。每天數(shù)據(jù)增量十多億，近百萬次查詢請(qǐng)求?？焓謨?nèi)部也在使用ClickHouse，存儲(chǔ)總量大約10PB，每天新增200TB，90%查詢小于3秒[2]。

1.2 為什么需要ClickHouse

為何ClickHouse獲得了如此廣泛的關(guān)注，得到了社區(qū)的青睞，也得到了諸多廠商的應(yīng)用呢？

企業(yè)目前使用的傳統(tǒng)關(guān)系型數(shù)據(jù)庫在數(shù)據(jù)規(guī)模比較小、索引大小適合內(nèi)存、數(shù)據(jù)緩存命中率足夠高的情形下能正常提供服務(wù)。但殘酷的是，這種理想情形最終會(huì)隨著業(yè)務(wù)的增長走到盡頭，查詢會(huì)變得越來越慢。雖然可通過縱向擴(kuò)展數(shù)據(jù)庫來解決問題，通過增加更多的內(nèi)存或者訂購更快的磁盤等，但這只是拖延解決實(shí)質(zhì)問題。

在未來數(shù)字化油田的實(shí)時(shí)數(shù)倉工作中，日志量劇增，雖然經(jīng)過數(shù)倉的分層以及數(shù)據(jù)匯總層通用維度指標(biāo)可以進(jìn)行預(yù)計(jì)算，但有些個(gè)性化的分析場景還是需要直接編寫程序或數(shù)據(jù)庫查詢語句，這種情況下hive SQL、spark SQL的查詢性能也無法滿足需求[4]。

（1）數(shù)據(jù)時(shí)效性：傳統(tǒng)方案中只能拿到次天數(shù)據(jù)，但想要獲得及時(shí)的實(shí)時(shí)數(shù)據(jù)，復(fù)合指標(biāo)、多維度指標(biāo)生成需要整個(gè)數(shù)據(jù)鏈路提供實(shí)時(shí)數(shù)據(jù)。

（2）通用指標(biāo)體系：傳統(tǒng)方案中只能針對(duì)每個(gè)分析對(duì)象創(chuàng)建一個(gè)結(jié)果表，但想要獲得每個(gè)分析對(duì)象可支持所有指標(biāo)，需要更適合的數(shù)據(jù)模型支持更多的分析對(duì)象[5]。

（3）靈活的數(shù)據(jù)分析：傳統(tǒng)方案中只能“選擇”“連接”“分組”，但想要獲得無限制的交互式分析，獲得自定義維度，需要跨數(shù)據(jù)庫查詢能力。

（4）大寬表：傳統(tǒng)方案中窄表嚴(yán)格按照數(shù)據(jù)庫設(shè)計(jì)三范式。這么設(shè)計(jì)為的是盡量減少數(shù)據(jù)冗余，但是缺點(diǎn)是修改一個(gè)數(shù)據(jù)可能需要修改多張表。為了查詢性能的提高與便捷，在業(yè)務(wù)、數(shù)據(jù)提取轉(zhuǎn)換和加載、指標(biāo)屬性、數(shù)據(jù)來源等角度來看，讓高度內(nèi)聚的屬性、描述、度量放在一張邏輯上的數(shù)據(jù)庫表中，這對(duì)于刷新效率、容錯(cuò)能力、擴(kuò)展能力都是一個(gè)很大的挑戰(zhàn)。以空間換時(shí)間，便于訓(xùn)練迭代、減少表關(guān)聯(lián)數(shù)量，修改少量數(shù)據(jù)時(shí)不需要改多張表[6-7]。

在即將到來的大數(shù)據(jù)時(shí)代，面臨的難題有三：計(jì)算和存儲(chǔ)的成本、流水線式工作流程、高峰每秒查詢率、95%的查詢時(shí)間[5]。如果需求是解決怎樣方便快捷地查詢出結(jié)果，需要一個(gè)數(shù)據(jù)分析引擎。

1.3 ClickHouse建設(shè)架構(gòu)

快是Clickhouse的最大優(yōu)勢，還有集群的擴(kuò)展能力，相比hadoop套件也更容易部署，其核心都是圍繞如何在數(shù)據(jù)分析場景下做到極致的快，在存儲(chǔ)結(jié)構(gòu)和計(jì)算并行上都有巧妙的設(shè)計(jì)[8]。

1.3.1 OLAP場景的特點(diǎn)

讀多于寫：

不同于事務(wù)處理場景，在原地進(jìn)行大量增加、刪除、修改操作，數(shù)據(jù)分析場景通常更加關(guān)注寫入吞吐，要求海量數(shù)據(jù)能夠盡快導(dǎo)入完成。一旦導(dǎo)入完成，歷史數(shù)據(jù)往往作為存檔，不會(huì)再做更新、刪除操作。將數(shù)據(jù)批量導(dǎo)入后，再進(jìn)行任意維度的靈活探索、制作報(bào)表等。

數(shù)據(jù)一次性寫入后，業(yè)務(wù)人員需要嘗試從各個(gè)角度對(duì)數(shù)據(jù)進(jìn)行分析，發(fā)現(xiàn)業(yè)務(wù)變化的趨勢。在反復(fù)試錯(cuò)、不斷調(diào)整、持續(xù)優(yōu)化的過程中，數(shù)據(jù)的讀取次數(shù)多于寫入次數(shù)。這就要求底層數(shù)據(jù)庫為這個(gè)特點(diǎn)做專門設(shè)計(jì)，而不是盲目采用傳統(tǒng)數(shù)據(jù)庫的技術(shù)架構(gòu)。

在數(shù)據(jù)分析場景中，通常存在一張或是幾張多列的寬表（例如M科室做產(chǎn)能區(qū)塊投產(chǎn)效果查詢庫，需要連續(xù)多年跟蹤月產(chǎn)量，X科室做數(shù)據(jù)回遷視圖時(shí)需要多表聯(lián)合查詢）。對(duì)數(shù)據(jù)分析處理時(shí)，選擇其中的少數(shù)幾列作為維度列、其他少數(shù)幾列作為指標(biāo)列，然后對(duì)全表或某一個(gè)較大范圍內(nèi)的數(shù)據(jù)做聚合計(jì)算。這個(gè)過程會(huì)掃描大量的行數(shù)據(jù)，但是只用到了其中的少數(shù)列，而聚合計(jì)算的結(jié)果集小得多。

1.3.2 ClickHouse存儲(chǔ)層

ClickHouse從數(shù)據(jù)分析場景需求出發(fā)，定制開發(fā)了一套全新的高效列式存儲(chǔ)引擎，并且實(shí)現(xiàn)了數(shù)據(jù)有序存儲(chǔ)、主鍵索引、稀疏索引、數(shù)據(jù)分享、數(shù)據(jù)劃片、數(shù)據(jù)生存時(shí)間、主備復(fù)制等豐富功能。以上功能共同為ClickHouse極速的分析性能奠定了基礎(chǔ)。

1）列式存儲(chǔ)

與行存將每一行的數(shù)據(jù)連續(xù)存儲(chǔ)不同，列存將每一列的數(shù)據(jù)連續(xù)存儲(chǔ)。相比于行式存儲(chǔ)，列式存儲(chǔ)在分析場景下有著許多優(yōu)良的特性。

（1）在行存模式下，數(shù)據(jù)按行連續(xù)存儲(chǔ)，所有列的數(shù)據(jù)都存儲(chǔ)在一個(gè)數(shù)據(jù)塊中，不參與計(jì)算的列在輸入輸出時(shí)也要全部讀出，讀取操作被嚴(yán)重放大。而列存模式下，只需要讀取參與計(jì)算的列即可，極大地減低了輸入輸出消耗，加速了查詢。

（2）同一列中的數(shù)據(jù)屬于同一類型，壓縮效果顯著。列存往往有著高達(dá)十倍甚至更高的壓縮比，節(jié)省了大量的存儲(chǔ)空間，降低了存儲(chǔ)成本。更高的壓縮比意味著更小的數(shù)據(jù)規(guī)模，從磁盤中讀取相應(yīng)數(shù)據(jù)耗時(shí)更短。高壓縮比意味著同等大小的內(nèi)存能夠存放更多數(shù)據(jù)，系統(tǒng)緩存效果更好。

官方數(shù)據(jù)顯示，通過使用列存，在某些分析場景下，能夠獲得100倍甚至更高的加速效應(yīng)。

2）主鍵索引

ClickHouse支持主鍵索引，它將每列數(shù)據(jù)按照索引粒度（默認(rèn)8192行）進(jìn)行劃分，每個(gè)索引粒度的開頭第一行被稱為一個(gè)標(biāo)記行。主鍵索引存儲(chǔ)該標(biāo)記行對(duì)應(yīng)的主鍵的值。

對(duì)于where條件中含有主鍵的查詢，通過對(duì)主鍵索引進(jìn)行二分查找，直接定位到對(duì)應(yīng)的索引粒度，避免了全表掃描從而加速查詢。

但是值得注意的是：ClickHouse的主鍵索引與MySQL等數(shù)據(jù)庫不同，它并不用于去重，即便主鍵相同的行也可以同時(shí)存在于數(shù)據(jù)庫中。要想實(shí)現(xiàn)去重效果，需要結(jié)合具體的表引擎ReplacingMergeTree、CollapsingMergeTree、VersionedCollapsingMergeTree實(shí)現(xiàn)。

3）數(shù)據(jù)TTL

在數(shù)據(jù)分析場景中，數(shù)據(jù)的價(jià)值隨著時(shí)間流逝而不斷降低，多數(shù)業(yè)務(wù)出于成本考慮只會(huì)保留最近幾個(gè)月的數(shù)據(jù)，ClickHouse通過TTL提供了數(shù)據(jù)生命周期管理的能力。

1.3.3 ClickHouse計(jì)算層

ClickHouse在計(jì)算層做了非常細(xì)致的工作，竭盡所能榨干硬件能力，提升查詢速度。它實(shí)現(xiàn)了單機(jī)多核并行、分布式計(jì)算、向量化執(zhí)行與SIMD指令集、代碼生成等多種重要技術(shù)。

1）多核并行

ClickHouse將數(shù)據(jù)劃分為多個(gè)分片，每個(gè)分片再進(jìn)一步劃分為多個(gè)索引粒度，然后通過多個(gè)CPU核心分別處理其中的一部分來實(shí)現(xiàn)并行數(shù)據(jù)處理。在這種設(shè)計(jì)下，單條查詢就能利用整機(jī)所有CPU。極致的并行處理能力極大地降低了查詢延時(shí)。

2）分布式計(jì)算

除了優(yōu)秀的單機(jī)并行處理能力，ClickHouse還提供了可線性拓展的分布式計(jì)算能力。ClickHouse會(huì)自動(dòng)將查詢拆解為多個(gè)任務(wù)下發(fā)到集群中，進(jìn)行多機(jī)并行處理，最后匯聚結(jié)果。

3）向量化執(zhí)行與SIMD指令集

ClickHouse不僅將數(shù)據(jù)按列存儲(chǔ)，而且按列進(jìn)行計(jì)算。傳統(tǒng)事務(wù)分析數(shù)據(jù)庫通常采用按行計(jì)算，原因是事務(wù)處理中以單元點(diǎn)查詢?yōu)橹?，?shù)據(jù)庫查詢語句計(jì)算量小，實(shí)現(xiàn)這些技術(shù)的收益不夠明顯。但在數(shù)據(jù)分析場景下，單個(gè)查詢語句所涉及計(jì)算量可能極大，將每行作為一個(gè)基本單元處理會(huì)帶來嚴(yán)重的性能損耗。

1.3.4 ClickHouse建設(shè)

依據(jù)數(shù)據(jù)的流向?qū)lickHouse的應(yīng)用架構(gòu)劃分為4個(gè)層級(jí)：

1）數(shù)據(jù)接入層

提供了數(shù)據(jù)導(dǎo)入相關(guān)的服務(wù)及功能，按照數(shù)據(jù)的量級(jí)和特性抽象出三種ClickHouse導(dǎo)入數(shù)據(jù)的方式。

方式一：數(shù)倉應(yīng)用層小表導(dǎo)入

這類數(shù)據(jù)量級(jí)相對(duì)較小，且分布在不同的數(shù)據(jù)源如hdfs、es、hbase等，這時(shí)提供基于DataX自研的TaskPlus數(shù)據(jù)流轉(zhuǎn)+調(diào)度平臺(tái)導(dǎo)入數(shù)據(jù)，單分區(qū)數(shù)據(jù)無并發(fā)寫入，多分區(qū)數(shù)據(jù)小并發(fā)寫入，且能和線上任務(wù)形成依賴關(guān)系，確保導(dǎo)入程序的可靠性。

方式二：離線多維明細(xì)寬表導(dǎo)入

這類數(shù)據(jù)一般是匯總層的明細(xì)數(shù)據(jù)或者是用戶基于Hadoop生產(chǎn)的大量級(jí)數(shù)據(jù)，基于Spark開發(fā)了一個(gè)導(dǎo)入工具包，用戶可以根據(jù)配置直接拉取hdfs或者h(yuǎn)ive上的數(shù)據(jù)到ClickHouse，同時(shí)還能基于配置查詢語句對(duì)數(shù)據(jù)進(jìn)行提取轉(zhuǎn)換和加載處理，工具包會(huì)根據(jù)配置集群的節(jié)點(diǎn)數(shù)以及ClickHouse集群負(fù)載情況對(duì)本地表進(jìn)行高并發(fā)的寫入，達(dá)到快速導(dǎo)數(shù)的目的。

方式三：實(shí)時(shí)多維明細(xì)寬表導(dǎo)入

實(shí)時(shí)數(shù)據(jù)接入場景比較固定，封裝了通用的ClickHouseSink，將每日百億級(jí)的數(shù)據(jù)通過Flink接入ClickHouse，ClickHouseSink也提供了“單次導(dǎo)入數(shù)據(jù)量”及“單次導(dǎo)入時(shí)間間隔”供用戶選擇。

2）數(shù)據(jù)存儲(chǔ)層

數(shù)據(jù)存儲(chǔ)層采用雙副本機(jī)制來保證數(shù)據(jù)的高可靠，同時(shí)用代理集群，通過域名的方式進(jìn)行讀寫操作，實(shí)現(xiàn)了數(shù)據(jù)均衡及高可靠寫入，且對(duì)于域名的響應(yīng)時(shí)間及流量有對(duì)應(yīng)的實(shí)時(shí)監(jiān)控，一旦響應(yīng)速度出現(xiàn)波動(dòng)或異常能在第一時(shí)間收到報(bào)警通知。

3）數(shù)據(jù)服務(wù)層

對(duì)外：將集群查詢統(tǒng)一封裝為scf服務(wù)，供外部調(diào)用。

對(duì)內(nèi)：提供了客戶端工具直接供工程師及研發(fā)人員使用。

4）數(shù)據(jù)應(yīng)用層

埋點(diǎn)系統(tǒng)：對(duì)接實(shí)時(shí)集群，提供秒級(jí)別的數(shù)據(jù)分析查詢功能。

用戶分析平臺(tái)：通過標(biāo)簽篩選的方式，從用戶訪問總集合中根據(jù)特定的用戶行為捕獲所需用戶集。

商業(yè)智能：提供數(shù)據(jù)應(yīng)用層的可視化展示，對(duì)接單分片多副本集群，可橫向擴(kuò)展。

2 結(jié)論

在數(shù)據(jù)量日益增長的當(dāng)下，傳統(tǒng)數(shù)據(jù)庫的查詢性能已滿足不了業(yè)務(wù)需求。在不遠(yuǎn)的將來，隨著油田數(shù)字化進(jìn)程日益加深，在大數(shù)據(jù)分析領(lǐng)域中，傳統(tǒng)的大數(shù)據(jù)分析也需要不同框架和技術(shù)組合才能達(dá)到最終的效果，大數(shù)據(jù)分析在人力成本、技術(shù)能力和硬件成本上以及維護(hù)成本上變成了昂貴的事情。

而ClickHouse在數(shù)據(jù)分析領(lǐng)域的快速崛起引起了的注意，由于ClickHouse正是以不依賴Hadoop生態(tài)、安裝和維護(hù)簡單、查詢速度快、可以支持SQL等特點(diǎn)在大數(shù)據(jù)分析領(lǐng)域越走越遠(yuǎn)。當(dāng)前社區(qū)仍舊在迅猛發(fā)展中，相信后續(xù)會(huì)有越來越多好用的功能出現(xiàn)。如果引入ClickHouse提供高可用集群環(huán)境，結(jié)合大數(shù)據(jù)生態(tài)定制一套完善的數(shù)據(jù)分析方案，打造完備的運(yùn)維管理平臺(tái)以降低維護(hù)成本，將極大地助力油田數(shù)字化建設(shè)快捷迅猛發(fā)展。

參考文獻(xiàn)：

[1] Bernard Marr.大數(shù)據(jù)實(shí)踐[M].北京：電子工業(yè)出版社，2020：19-22.

[2] liuzx32.簡書：ClickHouse概述[EB].（2018-12-29）[2021-07-21].https：//www.jianshu.com/p/350b59e8ea68.

[3] Wping_1c08.簡書：Flink+Clickhouse在廣投集團(tuán)實(shí)時(shí)數(shù)倉的最佳實(shí)踐[EB].（2021-05-07）[2021-07-21].https：//www.jianshu.com/p/4d521a62d534.

[4] 過往記憶.CSDN：Clickhouse的實(shí)踐之路[EB].（2021-12-17）[2021-07-21].https：//iteblog.blog.csdn.net/article/details/111 351075.

[5] iteye_4537.CSDN：解耦寬表體系[EB].（2012-03-09）[2021-07-21].https：//blog.csdn.net/iteye_4537/article/details/82296002？ops_request_misc=%257B%2522request%255Fid%252 2%253A%2522165726550216781685339704%2522%252C%2522scm%2522%253A%252220140713.130102334..%252 2%257D&request_id=165726550216781685339704&biz_id=

0&utm_medium=distribute.pc_search_result.none-task-blog-?? ?2～blog～sobaiduend～default-1-82296002-null-null.185^v2^control&utm_term=%E8%A7%A3%E8%80%A6%E5%AE%BD%E8%A1%A8%E4%BD%93%E7%B3%BB&spm=1018.2226.30

01.4450.

[6] SmartShylyBoy.CSDN：一個(gè)例子搞懂寬表和窄表的區(qū)別[EB].（2018-11-13）[2021-07-21].https：//blog.csdn.net/SmartShylyBoy/article/details/84026074？ops_request_misc=%257B%2522

request%255Fid%2522%253A%252216572655581678166786

8016%2522%252C%2522scm%2522%253A%252220140713.

130102334..%2522%257D&request_id=1657265558167816678

68016&biz_id=0&utm_medium=distribute.pc_ search_result.none-task-blog-2～all～sobaiduend～default-1-84026074-null-null.142^v32^down_rank，185^v2^control&utm_term=%E4%B8%

80%E4%B8%AA%E4%BE%8B%E5%AD%90%E6%90%9E%E6%87%82%E5%AE%BD%E8%A1%A8%E5%92%8C%E7%AA%84%E8%A1%A8%E7%9A%84%E5%8C%BA%E5%88%AB&spm=1018.2226.3001.4187.

[7] 老茶葉館.51CTO博客：認(rèn)識(shí)clickhouse[EB].（2020-12-06）[2021-07-21].https：//blog.51cto.com/imysql/3171455.

[8] 阿里云云棲號(hào).知乎：ClickHouse深度揭秘[EB].（2019-12-19）[2021-07-21].https：//zhuanlan.zhihu.com/p/98135840.

【通聯(lián)編輯：代影】