面向列存的DBMS新的選擇

　　Hadoop從誕生已經(jīng)十三年了，Hadoop的供應(yīng)商爭先恐后的為Hadoop貢獻(xiàn)各種開源插件，發(fā)明各種的解決方案技術(shù)棧，一方面確實(shí)幫助很多用戶解決了問題，但另一方面因?yàn)榉彪s的技術(shù)棧與高昂的維護(hù)成本，Hadoop也漸漸地失去了原本屬于他的市場。對于用戶來說，一套高性能，簡單化，可擴(kuò)展的數(shù)據(jù)庫產(chǎn)品能夠幫助他們解決業(yè)務(wù)痛點(diǎn)問題。越來越多的人將目光鎖定在列存的分布式數(shù)據(jù)庫上。

　　ClickHouse簡介

　　ClickHouse是由俄羅斯的第一大搜索引擎Yandex公司開源的列存數(shù)據(jù)庫。令人驚喜的是，ClickHouse相較于很多商業(yè)MPP數(shù)據(jù)庫，比如Vertica，InfiniDB有著極大的性能提升。除了Yandex以外，越來越多的公司開始嘗試使用ClickHouse等列存數(shù)據(jù)庫。對于一般的分析業(yè)務(wù)，結(jié)構(gòu)性較強(qiáng)且數(shù)據(jù)變更不頻繁，可以考慮將需要進(jìn)行關(guān)聯(lián)的表打平成寬表，放入ClickHouse中。

　　相比傳統(tǒng)的大數(shù)據(jù)解決方案，ClickHouse有以下的優(yōu)點(diǎn)：

　　·配置豐富，只依賴與Zookeeper

　　·線性可擴(kuò)展性，可以通過添加服務(wù)器擴(kuò)展集群

　　·容錯(cuò)性高，不同分片間采用異步多主復(fù)制

　　·單表性能極佳，采用向量計(jì)算，支持采樣和近似計(jì)算等優(yōu)化手段

　　·功能強(qiáng)大支持多種表引擎

　　StarRocks簡介

　　StarRocks是一款極速全場景MPP企業(yè)級數(shù)據(jù)庫產(chǎn)品，具備水平在線擴(kuò)縮容，金融級高可用，兼容MySQL協(xié)議和MySQL生態(tài)，提供全面向量化引擎與多種數(shù)據(jù)源聯(lián)邦查詢等重要特性。StarRocks致力于在全場景OLAP業(yè)務(wù)上為用戶提供統(tǒng)一的解決方案，適用于對性能，實(shí)時(shí)性，并發(fā)能力和靈活性有較高要求的各類應(yīng)用場景。

　　相比于傳統(tǒng)的大數(shù)據(jù)解決方案，StarRocks有以下優(yōu)點(diǎn)：

　　·不依賴于大數(shù)據(jù)生態(tài)，同時(shí)外表的聯(lián)邦查詢可以兼容大數(shù)據(jù)生態(tài)

　　·提供多種不同的模型，支持不同維度的數(shù)據(jù)建模

　　·支持在線彈性擴(kuò)縮容，可以自動負(fù)載均衡

　　·支持高并發(fā)分析查詢

　　·實(shí)時(shí)性好，支持?jǐn)?shù)據(jù)秒級寫入

　　·兼容MySQL 5.7協(xié)議和MySQL生態(tài)

　　StarRocks與ClickHouse的功能對比

　　StarRocks與ClickHouse有很多相似之處，比如說兩者都可以提供極致的性能，也都不依賴于Hadoop生態(tài)，底層存儲分片都提供了主主的復(fù)制高可用機(jī)制。但功能、性能與使用場景上也有差異。ClickHouse在更適用與大寬表的場景，TP的數(shù)據(jù)通過CDC工具的，可以考慮在Flink中將需要關(guān)聯(lián)的表打平，以大寬表的形式寫入ClickHouse。StarRocks對于join的能力更強(qiáng)，可以建立星型或者雪花模型應(yīng)對維度數(shù)據(jù)的變更。

　　大寬表vs星型模型

　　ClickHouse：通過拼寬表避免聚合操作

　　不同于以點(diǎn)查為主的TP業(yè)務(wù)，在AP業(yè)務(wù)中，事實(shí)表和維度表的關(guān)聯(lián)操作不可避免。ClickHouse與StarRocks最大的區(qū)別就在于對于join的處理上。ClickHouse雖然提供了join的語義，但使用上對大表關(guān)聯(lián)的能力支撐較弱，復(fù)雜的關(guān)聯(lián)查詢經(jīng)常會引起OOM。一般我們可以考慮在ETL的過程中就將事實(shí)表與維度表打平成寬表，避免在ClickHouse中進(jìn)行復(fù)雜的查詢。

　　目前有很多業(yè)務(wù)使用寬表來解決多遠(yuǎn)分析的問題，說明了寬表確有其獨(dú)到之處：

　　·在ETL的過程中處理好寬表的字段，分析師無需關(guān)心底層的邏輯就可以實(shí)現(xiàn)數(shù)據(jù)的分析

　　·寬表能夠包含更多的業(yè)務(wù)數(shù)據(jù)，看起來更直觀一些

　　·寬表相當(dāng)于單表查詢，避免了多表之間的數(shù)據(jù)關(guān)聯(lián)，性能更好

　　但同時(shí)，寬表在靈活性上也帶來了一些困擾：

　　·寬表中的數(shù)據(jù)可能會因?yàn)閖oin的過程中存在一對多的情況造成錯(cuò)誤數(shù)據(jù)冗余

　　·寬表的結(jié)構(gòu)維護(hù)麻煩，遇到維度數(shù)據(jù)變更的情況需要重跑寬表

　　·寬表需要根據(jù)業(yè)務(wù)預(yù)先定義，寬表可能無法滿足臨時(shí)新增的查詢業(yè)務(wù)

　　StarRocks：通過星型模型適應(yīng)維度變更

　　可以說，拼寬表的形式是以犧牲靈活性為代價(jià)，將join的操作前置，來加速業(yè)務(wù)的查詢。但在一些靈活度要求較高的場景，比如訂單的狀態(tài)需要頻繁改變，或者說業(yè)務(wù)人員的自助BI分析，寬表往往無法滿足我們的需求。此時(shí)我們還需要使用更為靈活的星型或者雪花模型進(jìn)行建模。對于星型/雪花模型的兼容度上，StarRocks的支撐要比ClickHouse好很多。　　

 

 

 

　　在StarRocks中提供了三種不同類型的join：

　　·當(dāng)小表與大表關(guān)聯(lián)時(shí)，可以使用boardcast join，小表會以廣播的形式加載到不同節(jié)點(diǎn)的內(nèi)存中

　　·當(dāng)大表與大表關(guān)聯(lián)式，可以使用shuffle join，兩張表值相同的數(shù)據(jù)會shuffle到相同的機(jī)器上

　　·為了避免shuffle帶來的網(wǎng)絡(luò)與I/O的開銷，也可以在創(chuàng)建表示就將需要關(guān)聯(lián)的數(shù)據(jù)存儲在同一個(gè)colocation group中，使用colocation join　

 

 

 

　　目前大部分的MPP架構(gòu)計(jì)算引擎，都采用基于規(guī)則的優(yōu)化器(RBO)。為了更好的選擇join的類型，StarRocks提供了基于代價(jià)的優(yōu)化器(CBO)。用戶在開發(fā)業(yè)務(wù)SQL的時(shí)候，不需要考慮驅(qū)動表與被驅(qū)動表的順序，也不需要考慮應(yīng)該使用哪一種join的類型，CBO會基于采集到的表的metric，自動的進(jìn)行查詢重寫，優(yōu)化join的順序與類型。

　　高并發(fā)支撐

　　ClickHouse對高并發(fā)的支撐

　　為了更深維度的挖掘數(shù)據(jù)的價(jià)值，就需要引入更多的分析師從不同的維度進(jìn)行數(shù)據(jù)勘察。更多的使用者同時(shí)也帶來了更高的QPS要求。對于互聯(lián)網(wǎng)，金融等行業(yè)，幾萬員工，幾十萬員工很常見，高峰時(shí)期并發(fā)量在幾千也并不少見。隨著互聯(lián)網(wǎng)化和場景化的趨勢，業(yè)務(wù)逐漸向以用戶為中心轉(zhuǎn)型，分析的重點(diǎn)也從原有的宏觀分析變成了用戶維度的細(xì)粒度分析。傳統(tǒng)的MPP數(shù)據(jù)庫由于所有的節(jié)點(diǎn)都要參與運(yùn)算，所以一個(gè)集群的并發(fā)能力與一個(gè)節(jié)點(diǎn)的并發(fā)能力相差無幾。如果一定要提高并發(fā)量，可以考慮增加副本數(shù)的方式，但同時(shí)也增加了RPC的交互，對性能和物理成本的影響巨大。

　　在ClickHouse中，我們一般不建議做高并發(fā)的業(yè)務(wù)查詢，對于三副本的集群，通常會將QPS控制在100以下。ClickHouse對高并發(fā)的業(yè)務(wù)并不友好，即使一個(gè)查詢，也會用服務(wù)器一半的CPU去查詢。一般來說，沒有什么有效的手段可以直接提高ClickHouse的并發(fā)量，只能考慮通過將結(jié)果集寫入MySQL中增加查詢的并發(fā)度。

　　StarRocks對高并發(fā)的支撐

　　相較于ClickHouse，StarRocks可以支撐數(shù)千用戶同時(shí)進(jìn)行分析查詢，在部分場景下，高并發(fā)能力能夠達(dá)到萬級。StarRocks在數(shù)據(jù)存儲層，采用先分區(qū)再分桶的策略，增加了數(shù)據(jù)的指向性，利用前綴索引可以快讀對數(shù)據(jù)進(jìn)行過濾和查找，減少磁盤的I/O操作，提升查詢性能。

 

　　在建表的時(shí)候，分區(qū)分桶應(yīng)該盡可能的覆蓋到所帶的查詢語句，這樣可以有效的利用分區(qū)分桶剪裁的功能，盡可能的減少數(shù)據(jù)的掃描量。此外，StarRocks也提供了MOLAP庫的預(yù)聚合能力。對于一些復(fù)雜的分析類查詢，可以通過創(chuàng)建物化視圖進(jìn)行預(yù)先聚合，原有幾十億的基表，可以通過預(yù)聚合RollUp操作變成幾百或者幾千行的表，查詢時(shí)延遲會有顯著下降，并發(fā)也會有顯著提升。

　　數(shù)據(jù)的高頻變更

　　ClickHouse中的數(shù)據(jù)更新

　　在OLAP數(shù)據(jù)庫中，可變數(shù)據(jù)(Mutable data)通常是不受歡迎的。ClickHouse也是如此。早期的版本中并不支持UPDATE和DELETE操作。在1.15版本后，Clickhouse提供了MUTATION操作(通過ALTER TABLE語句)來實(shí)現(xiàn)數(shù)據(jù)的更新、刪除，但這是一種“較重”的操作，它與標(biāo)準(zhǔn)SQL語法中的UPDATE、DELETE不同，是異步執(zhí)行的，對于批量數(shù)據(jù)不頻繁的更新或刪除比較有用。除了MUTATION操作，Clickhouse還可以通過CollapsingMergeTree、VersionedCollapsingMergeTree、ReplacingMergeTree結(jié)合具體業(yè)務(wù)數(shù)據(jù)結(jié)構(gòu)來實(shí)現(xiàn)數(shù)據(jù)的更新、刪除，這三種方式都通過INSERT語句插入最新的數(shù)據(jù)，新數(shù)據(jù)會“抵消”或“替換”掉老數(shù)據(jù)，但是“抵消”或“替換”都是發(fā)生在數(shù)據(jù)文件后臺Merge時(shí)，也就是說，在Merge之前，新數(shù)據(jù)和老數(shù)據(jù)會同時(shí)存在。

　　針對與不同的業(yè)務(wù)場景，ClickHouse提供了不同的業(yè)務(wù)引擎來進(jìn)行數(shù)據(jù)變更。

　　對于離線業(yè)務(wù)，可以考慮增量和全量兩種方案：

　　增量同步方案中，使用ReplacingMergeTree引擎，先用Spark將上游數(shù)據(jù)同步到Hive，再由Spark消費(fèi)Hive中的增量數(shù)據(jù)寫入到ClickHouse中。由于只同步增量數(shù)據(jù)，對下游的壓力較小。需要確保維度數(shù)據(jù)基本不變。

　　全量同步方案中，使用MergeTree引擎，通過Spark將上游數(shù)據(jù)定時(shí)同步到Hive中，truncate ClickHouse中的表，隨后使用Spark消費(fèi)Hive近幾天的數(shù)據(jù)一起寫入到ClickHouse中。由于是全量數(shù)據(jù)導(dǎo)入，對下游壓力較大，但無需考慮維度變化的問題。

　　對于實(shí)時(shí)業(yè)務(wù)，可以采用VersionedCollapsingMergeTree和ReplacingMergeTree兩種引擎：

　　使用VersionedCollapsingMergeTree引擎，先通過Spark將上游數(shù)據(jù)一次性同步到ClickHouse中，在通過Kafka消費(fèi)增量數(shù)據(jù)，實(shí)時(shí)同步到ClickHouse中。但因?yàn)橐肓薓Q，需要保證exectly once語義，實(shí)時(shí)和離線數(shù)據(jù)連接點(diǎn)存在無法折疊現(xiàn)象。

　　使用ReplacingMergeTree引擎替換VersionedCollapsingMergeTree引擎，先通過Spark將上游存量數(shù)據(jù)一次性同步到ClickHouse中，在通過MQ將實(shí)時(shí)數(shù)據(jù)同步到ReplacingMergeTree引擎中，相比VersionedCollapsingMergeTree要更簡單，且離線和實(shí)時(shí)數(shù)據(jù)連接點(diǎn)不存在異常。但此種方案無法保重沒有重復(fù)數(shù)據(jù)。

　　StarRocks中的數(shù)據(jù)更新

　　相較于ClickHouse，StarRocks對于數(shù)據(jù)更新的操作更加簡單。

　　StarRocks中提供了多種模型適配了更新操作，明細(xì)召回操作，聚合操作等業(yè)務(wù)需求。更新模型可以按照主鍵進(jìn)行UPDATE/DELETE操作，通過存儲和索引的優(yōu)化可以在并發(fā)更新的同時(shí)高效的查詢。在某些電商場景中，訂單的狀態(tài)需要頻繁的更新，每天更新的訂單量可能上億。通過更新模型，可以很好的適配實(shí)時(shí)更新的需求。

 

　　StarRocks 1.19版本之前，可以使用Unique模型進(jìn)行按主鍵的更新操作，Unique模型使用的是Merge-on-Read策略，即在數(shù)據(jù)入庫的時(shí)候會給每一個(gè)批次導(dǎo)入數(shù)據(jù)分配一個(gè)版本號，同一主鍵的數(shù)據(jù)可能有多個(gè)版本號，在查詢的時(shí)候StarRocks會先做merge操作，返回一個(gè)版本號最新的數(shù)據(jù)。

　　自StarRocks 1.19版本之后發(fā)布了主鍵模型，能夠通過主鍵進(jìn)行更新和刪除的操作，更友好的支持實(shí)時(shí)/頻繁更新的需求。相較于Unique模型中Merge-on-Read的模式，主鍵模型中使用的是Delete-and-Insert的更新策略，性能會有三倍左右的提升。對于前端的TP庫通過CDC實(shí)時(shí)同步到StarRocks的場景，建議使用主鍵模型。

　　集群的維護(hù)

　　相比于單實(shí)例的數(shù)據(jù)庫，任何一款分布式數(shù)據(jù)庫維護(hù)的成本都要成倍的增長。一方面是節(jié)點(diǎn)增多，發(fā)生故障的幾率變高。對于這種情況，我們需要一套良好的自動failover機(jī)制。另一方便隨著數(shù)據(jù)量的增長，要能做到在線彈性擴(kuò)縮容，保證集群的穩(wěn)定性與可用性。

　　ClickHouse中的節(jié)點(diǎn)擴(kuò)容與重分布

　　與一般的分布式數(shù)據(jù)庫或者Hadoop生態(tài)不同，HDFS可以根據(jù)集群節(jié)點(diǎn)的增減自動的通過balance來調(diào)節(jié)數(shù)據(jù)均衡。但是ClickHouse集群不能自動感知集群拓?fù)涞淖兓跃筒荒茏詣觔alance數(shù)據(jù)。當(dāng)集群數(shù)據(jù)較大時(shí)，新增集群節(jié)點(diǎn)可能會給數(shù)據(jù)負(fù)載均衡帶來極大的運(yùn)維成本。

　　一般來說，新增集群節(jié)點(diǎn)我們通常有三種方案：

　　·如果業(yè)務(wù)允許，可以給集群中的表設(shè)置TTL，長時(shí)間保留的數(shù)據(jù)會逐漸被清理到，新增的數(shù)據(jù)會自動選擇新節(jié)點(diǎn)，最后會達(dá)到負(fù)載均衡。

　　·在集群中建立臨時(shí)表，將原表中的數(shù)據(jù)復(fù)制到臨時(shí)表，再刪除原表。當(dāng)數(shù)據(jù)量較大時(shí)，或者表的數(shù)量過多時(shí)，維護(hù)成本較高。同時(shí)無法應(yīng)對實(shí)時(shí)數(shù)據(jù)變更。

　　·通過配置權(quán)重的方式，將新寫入的數(shù)據(jù)引導(dǎo)到新的節(jié)點(diǎn)。權(quán)重維護(hù)成本較高。

　　無論上述的哪一種方案，從時(shí)間成本，硬件資源，實(shí)時(shí)性等方面考慮，ClickHouse都不是非常適合在線做節(jié)點(diǎn)擴(kuò)縮容及數(shù)據(jù)充分布。同時(shí)，由于ClickHouse中無法做到自動探測節(jié)點(diǎn)拓?fù)渥兓?，我們可能需要再CMDB中寫入一套數(shù)據(jù)重分布的邏輯。所以我們需要盡可能的提前預(yù)估好數(shù)據(jù)量及節(jié)點(diǎn)的數(shù)量。

　　StarRocks中的在線彈性擴(kuò)縮容

　　與HDFS一樣，當(dāng)StarRocks集群感知到集群拓?fù)浒l(fā)生變化的時(shí)候，可以做到在線的彈性擴(kuò)縮容。避免了增加節(jié)點(diǎn)對業(yè)務(wù)的侵入。

　　StarRocks中的數(shù)據(jù)采用先分區(qū)再分桶的機(jī)制進(jìn)行存儲。數(shù)據(jù)分桶后，會根據(jù)分桶鍵做hash運(yùn)算，結(jié)果一致的數(shù)據(jù)被劃分到同一數(shù)據(jù)分片中，我們稱之為tablet。Tablet是StarRocks中數(shù)據(jù)冗余的最小單位，通常我們會默認(rèn)數(shù)據(jù)以三副本的形式存儲，節(jié)點(diǎn)中通過Quorum協(xié)議進(jìn)行復(fù)制。當(dāng)某個(gè)節(jié)點(diǎn)發(fā)生宕機(jī)時(shí)，在其他可用的節(jié)點(diǎn)上會自動補(bǔ)齊丟失的tablet，做到無感知的failover。

　　在新增節(jié)點(diǎn)時(shí)，也會有FE自動的進(jìn)行調(diào)度，將已有節(jié)點(diǎn)中的tablet自動的調(diào)度到擴(kuò)容的節(jié)點(diǎn)上，做到自動的數(shù)據(jù)片均衡。為了避免tablet遷移時(shí)對業(yè)務(wù)的性能影響，可以盡量選擇在業(yè)務(wù)低峰期進(jìn)行節(jié)點(diǎn)的擴(kuò)縮容，或者可以動態(tài)調(diào)整調(diào)度參數(shù)，通過參數(shù)控制tablet調(diào)度的速度，盡可能的減少對業(yè)務(wù)的影響。

　　ClickHouse與StarRocks的性能對比

　　單表SSB性能測試

　　由于ClickHouse join能力有限，無法完成TPCH的測試，這里使用SSB 100G的單表進(jìn)行測試。

　　測試環(huán)境

 

　　測試數(shù)據(jù)

 

　　測試結(jié)果

　　從測試結(jié)果中可以看出來，14個(gè)測試中，有9個(gè)SQL，StarRocks在性能上要超過ClickHouse。

 

　　多表TPCH性能測試

　　ClickHouse不擅長多表關(guān)聯(lián)的場景，對于TPCH測試機(jī)，很多查詢無法跑出，或者OOM，目前只進(jìn)行了StarRocks的TPCH測試。

　　測試環(huán)境

 

　　測試數(shù)據(jù)

　　選用TPCH 100G測試集。

　　

 

　　測試結(jié)果

　　

 

　　導(dǎo)入性能測試

　　無論是ClickHouse還是StarRocks，我們都可以使用DataX進(jìn)行全量數(shù)據(jù)的導(dǎo)入，增量部分通過CDC工具寫入到MQ中在經(jīng)過下游數(shù)據(jù)庫消費(fèi)即可。

　　數(shù)據(jù)集

　　導(dǎo)入測試選取了ClickHouse Native Format數(shù)據(jù)集。1個(gè)xz格式壓縮文件大概85GB左右，解壓后原始文件1.4T，31億條數(shù)據(jù)，文件格式為CSV

　　導(dǎo)入方式

　　ClickHouse中采用的HDFS外表的形式。ClickHouse中分布式表只能選擇一個(gè)integer列作為Sharding Key，觀察數(shù)據(jù)發(fā)現(xiàn)技術(shù)都很低，因此使用rand()分布形式。

　　

 

　　HDFS外表定義如下：

　　

 

　　導(dǎo)入結(jié)果

　　可以看出，在使用github數(shù)據(jù)集進(jìn)行導(dǎo)入的時(shí)候，基本上StarRocks和ClickHouse導(dǎo)入的性能相差不多。

　　

 

　　

 

　　結(jié)論

　　ClickHouse與StarRocks都是很優(yōu)秀的關(guān)系新OLAP數(shù)據(jù)庫。兩者有著很多的相似之處，對于分析類查詢都提供了極致的性能，都不依賴于Hadoop生態(tài)圈。從本次的選型對比中，可以看出在一些場景下，StarRocks相較于ClickHouse有更好的表現(xiàn)。一般來說，ClickHouse適合于維度變化較少的拼寬表的場景，StarRocks不僅在單表的測試中有著更出色的表現(xiàn)，在多表關(guān)聯(lián)的場景具有更大的優(yōu)勢。