面向列存的DBMS新的選擇
Hadoop從誕生已經(jīng)十三年了，Hadoop的供應(yīng)商爭先恐后的為Hadoop貢獻各種開源插件，發(fā)明各種的解決方案技術(shù)棧，一方面確實幫助很多用戶解決了問題，但另一方面因為繁雜的技術(shù)棧與高昂的維護成本，Hadoop也漸漸地失去了原本屬于他的市場。對于用戶來說，一套高性能，簡單化，可擴展的數(shù)據(jù)庫產(chǎn)品能夠幫助他們解決業(yè)務(wù)痛點問題。越來越多的人將目光鎖定在列存的分布式數(shù)據(jù)庫上。
ClickHouse簡介
ClickHouse是由俄羅斯的第一大搜索引擎Yandex公司開源的列存數(shù)據(jù)庫。令人驚喜的是，ClickHouse相較于很多商業(yè)MPP數(shù)據(jù)庫，比如Vertica，InfiniDB有著極大的性能提升。除了Yandex以外，越來越多的公司開始嘗試使用ClickHouse等列存數(shù)據(jù)庫。對于一般的分析業(yè)務(wù)，結(jié)構(gòu)性較強且數(shù)據(jù)變更不頻繁，可以考慮將需要進行關(guān)聯(lián)的表打平成寬表，放入ClickHouse中。
相比傳統(tǒng)的大數(shù)據(jù)解決方案，ClickHouse有以下的優(yōu)點：
·配置豐富，只依賴與Zookeeper
·線性可擴展性，可以通過添加服務(wù)器擴展集群
·容錯性高，不同分片間采用異步多主復(fù)制
·單表性能極佳，采用向量計算，支持采樣和近似計算等優(yōu)化手段
·功能強大支持多種表引擎
StarRocks簡介
StarRocks是一款極速全場景MPP企業(yè)級數(shù)據(jù)庫產(chǎn)品，具備水平在線擴縮容，金融級高可用，兼容MySQL協(xié)議和MySQL生態(tài)，提供全面向量化引擎與多種數(shù)據(jù)源聯(lián)邦查詢等重要特性。StarRocks致力于在全場景OLAP業(yè)務(wù)上為用戶提供統(tǒng)一的解決方案，適用于對性能，實時性，并發(fā)能力和靈活性有較高要求的各類應(yīng)用場景。
相比于傳統(tǒng)的大數(shù)據(jù)解決方案，StarRocks有以下優(yōu)點：
·不依賴于大數(shù)據(jù)生態(tài)，同時外表的聯(lián)邦查詢可以兼容大數(shù)據(jù)生態(tài)
·提供多種不同的模型，支持不同維度的數(shù)據(jù)建模
·支持在線彈性擴縮容，可以自動負載均衡
·支持高并發(fā)分析查詢
·實時性好，支持數(shù)據(jù)秒級寫入
·兼容MySQL 5.7協(xié)議和MySQL生態(tài)
StarRocks與ClickHouse的功能對比
StarRocks與ClickHouse有很多相似之處，比如說兩者都可以提供極致的性能，也都不依賴于Hadoop生態(tài)，底層存儲分片都提供了主主的復(fù)制高可用機制。但功能、性能與使用場景上也有差異。ClickHouse在更適用與大寬表的場景，TP的數(shù)據(jù)通過CDC工具的，可以考慮在Flink中將需要關(guān)聯(lián)的表打平，以大寬表的形式寫入ClickHouse。StarRocks對于join的能力更強，可以建立星型或者雪花模型應(yīng)對維度數(shù)據(jù)的變更。
大寬表vs星型模型
ClickHouse：通過拼寬表避免聚合操作
不同于以點查為主的TP業(yè)務(wù)，在AP業(yè)務(wù)中，事實表和維度表的關(guān)聯(lián)操作不可避免。ClickHouse與StarRocks最大的區(qū)別就在于對于join的處理上。ClickHouse雖然提供了join的語義，但使用上對大表關(guān)聯(lián)的能力支撐較弱，復(fù)雜的關(guān)聯(lián)查詢經(jīng)常會引起OOM。一般我們可以考慮在ETL的過程中就將事實表與維度表打平成寬表，避免在ClickHouse中進行復(fù)雜的查詢。
目前有很多業(yè)務(wù)使用寬表來解決多遠分析的問題，說明了寬表確有其獨到之處：
·在ETL的過程中處理好寬表的字段，分析師無需關(guān)心底層的邏輯就可以實現(xiàn)數(shù)據(jù)的分析
·寬表能夠包含更多的業(yè)務(wù)數(shù)據(jù)，看起來更直觀一些
·寬表相當于單表查詢，避免了多表之間的數(shù)據(jù)關(guān)聯(lián)，性能更好
但同時，寬表在靈活性上也帶來了一些困擾：
·寬表中的數(shù)據(jù)可能會因為join的過程中存在一對多的情況造成錯誤數(shù)據(jù)冗余
·寬表的結(jié)構(gòu)維護麻煩，遇到維度數(shù)據(jù)變更的情況需要重跑寬表
·寬表需要根據(jù)業(yè)務(wù)預(yù)先定義，寬表可能無法滿足臨時新增的查詢業(yè)務(wù)
StarRocks：通過星型模型適應(yīng)維度變更
可以說，拼寬表的形式是以犧牲靈活性為代價，將join的操作前置，來加速業(yè)務(wù)的查詢。但在一些靈活度要求較高的場景，比如訂單的狀態(tài)需要頻繁改變，或者說業(yè)務(wù)人員的自助BI分析，寬表往往無法滿足我們的需求。此時我們還需要使用更為靈活的星型或者雪花模型進行建模。對于星型/雪花模型的兼容度上，StarRocks的支撐要比ClickHouse好很多。
在StarRocks中提供了三種不同類型的join：
·當小表與大表關(guān)聯(lián)時，可以使用boardcast join，小表會以廣播的形式加載到不同節(jié)點的內(nèi)存中
·當大表與大表關(guān)聯(lián)式，可以使用shuffle join，兩張表值相同的數(shù)據(jù)會shuffle到相同的機器上
·為了避免shuffle帶來的網(wǎng)絡(luò)與I/O的開銷，也可以在創(chuàng)建表示就將需要關(guān)聯(lián)的數(shù)據(jù)存儲在同一個colocation group中，使用colocation join
目前大部分的MPP架構(gòu)計算引擎，都采用基于規(guī)則的優(yōu)化器(RBO)。為了更好的選擇join的類型，StarRocks提供了基于代價的優(yōu)化器(CBO)。用戶在開發(fā)業(yè)務(wù)SQL的時候，不需要考慮驅(qū)動表與被驅(qū)動表的順序，也不需要考慮應(yīng)該使用哪一種join的類型，CBO會基于采集到的表的metric，自動的進行查詢重寫，優(yōu)化join的順序與類型。
高并發(fā)支撐
ClickHouse對高并發(fā)的支撐
為了更深維度的挖掘數(shù)據(jù)的價值，就需要引入更多的分析師從不同的維度進行數(shù)據(jù)勘察。更多的使用者同時也帶來了更高的QPS要求。對于互聯(lián)網(wǎng)，金融等行業(yè)，幾萬員工，幾十萬員工很常見，高峰時期并發(fā)量在幾千也并不少見。隨著互聯(lián)網(wǎng)化和場景化的趨勢，業(yè)務(wù)逐漸向以用戶為中心轉(zhuǎn)型，分析的重點也從原有的宏觀分析變成了用戶維度的細粒度分析。傳統(tǒng)的MPP數(shù)據(jù)庫由于所有的節(jié)點都要參與運算，所以一個集群的并發(fā)能力與一個節(jié)點的并發(fā)能力相差無幾。如果一定要提高并發(fā)量，可以考慮增加副本數(shù)的方式，但同時也增加了RPC的交互，對性能和物理成本的影響巨大。
在ClickHouse中，我們一般不建議做高并發(fā)的業(yè)務(wù)查詢，對于三副本的集群，通常會將QPS控制在100以下。ClickHouse對高并發(fā)的業(yè)務(wù)并不友好，即使一個查詢，也會用服務(wù)器一半的CPU去查詢。一般來說，沒有什么有效的手段可以直接提高ClickHouse的并發(fā)量，只能考慮通過將結(jié)果集寫入MySQL中增加查詢的并發(fā)度。
StarRocks對高并發(fā)的支撐
相較于ClickHouse，StarRocks可以支撐數(shù)千用戶同時進行分析查詢，在部分場景下，高并發(fā)能力能夠達到萬級。StarRocks在數(shù)據(jù)存儲層，采用先分區(qū)再分桶的策略，增加了數(shù)據(jù)的指向性，利用前綴索引可以快讀對數(shù)據(jù)進行過濾和查找，減少磁盤的I/O操作，提升查詢性能。
在建表的時候，分區(qū)分桶應(yīng)該盡可能的覆蓋到所帶的查詢語句，這樣可以有效的利用分區(qū)分桶剪裁的功能，盡可能的減少數(shù)據(jù)的掃描量。此外，StarRocks也提供了MOLAP庫的預(yù)聚合能力。對于一些復(fù)雜的分析類查詢，可以通過創(chuàng)建物化視圖進行預(yù)先聚合，原有幾十億的基表，可以通過預(yù)聚合RollUp操作變成幾百或者幾千行的表，查詢時延遲會有顯著下降，并發(fā)也會有顯著提升。
數(shù)據(jù)的高頻變更
ClickHouse中的數(shù)據(jù)更新
在OLAP數(shù)據(jù)庫中，可變數(shù)據(jù)(Mutable data)通常是不受歡迎的。ClickHouse也是如此。早期的版本中并不支持UPDATE和DELETE操作。在1.15版本后，Clickhouse提供了MUTATION操作(通過ALTER TABLE語句)來實現(xiàn)數(shù)據(jù)的更新、刪除，但這是一種“較重”的操作，它與標準SQL語法中的UPDATE、DELETE不同，是異步執(zhí)行的，對于批量數(shù)據(jù)不頻繁的更新或刪除比較有用。除了MUTATION操作，Clickhouse還可以通過CollapsingMergeTree、VersionedCollapsingMergeTree、ReplacingMergeTree結(jié)合具體業(yè)務(wù)數(shù)據(jù)結(jié)構(gòu)來實現(xiàn)數(shù)據(jù)的更新、刪除，這三種方式都通過INSERT語句插入最新的數(shù)據(jù)，新數(shù)據(jù)會“抵消”或“替換”掉老數(shù)據(jù)，但是“抵消”或“替換”都是發(fā)生在數(shù)據(jù)文件后臺Merge時，也就是說，在Merge之前，新數(shù)據(jù)和老數(shù)據(jù)會同時存在。
針對與不同的業(yè)務(wù)場景，ClickHouse提供了不同的業(yè)務(wù)引擎來進行數(shù)據(jù)變更。
對于離線業(yè)務(wù)，可以考慮增量和全量兩種方案：
增量同步方案中，使用ReplacingMergeTree引擎，先用Spark將上游數(shù)據(jù)同步到Hive，再由Spark消費Hive中的增量數(shù)據(jù)寫入到ClickHouse中。由于只同步增量數(shù)據(jù)，對下游的壓力較小。需要確保維度數(shù)據(jù)基本不變。
全量同步方案中，使用MergeTree引擎，通過Spark將上游數(shù)據(jù)定時同步到Hive中，truncate ClickHouse中的表，隨后使用Spark消費Hive近幾天的數(shù)據(jù)一起寫入到ClickHouse中。由于是全量數(shù)據(jù)導(dǎo)入，對下游壓力較大，但無需考慮維度變化的問題。
對于實時業(yè)務(wù)，可以采用VersionedCollapsingMergeTree和ReplacingMergeTree兩種引擎：
使用VersionedCollapsingMergeTree引擎，先通過Spark將上游數(shù)據(jù)一次性同步到ClickHouse中，在通過Kafka消費增量數(shù)據(jù)，實時同步到ClickHouse中。但因為引入了MQ，需要保證exectly once語義，實時和離線數(shù)據(jù)連接點存在無法折疊現(xiàn)象。
使用ReplacingMergeTree引擎替換VersionedCollapsingMergeTree引擎，先通過Spark將上游存量數(shù)據(jù)一次性同步到ClickHouse中，在通過MQ將實時數(shù)據(jù)同步到ReplacingMergeTree引擎中，相比VersionedCollapsingMergeTree要更簡單，且離線和實時數(shù)據(jù)連接點不存在異常。但此種方案無法保重沒有重復(fù)數(shù)據(jù)。
StarRocks中的數(shù)據(jù)更新
相較于ClickHouse，StarRocks對于數(shù)據(jù)更新的操作更加簡單。
StarRocks中提供了多種模型適配了更新操作，明細召回操作，聚合操作等業(yè)務(wù)需求。更新模型可以按照主鍵進行UPDATE/DELETE操作，通過存儲和索引的優(yōu)化可以在并發(fā)更新的同時高效的查詢。在某些電商場景中，訂單的狀態(tài)需要頻繁的更新，每天更新的訂單量可能上億。通過更新模型，可以很好的適配實時更新的需求。
StarRocks 1.19版本之前，可以使用Unique模型進行按主鍵的更新操作，Unique模型使用的是Merge-on-Read策略，即在數(shù)據(jù)入庫的時候會給每一個批次導(dǎo)入數(shù)據(jù)分配一個版本號，同一主鍵的數(shù)據(jù)可能有多個版本號，在查詢的時候StarRocks會先做merge操作，返回一個版本號最新的數(shù)據(jù)。
自StarRocks 1.19版本之后發(fā)布了主鍵模型，能夠通過主鍵進行更新和刪除的操作，更友好的支持實時/頻繁更新的需求。相較于Unique模型中Merge-on-Read的模式，主鍵模型中使用的是Delete-and-Insert的更新策略，性能會有三倍左右的提升。對于前端的TP庫通過CDC實時同步到StarRocks的場景，建議使用主鍵模型。
集群的維護
相比于單實例的數(shù)據(jù)庫，任何一款分布式數(shù)據(jù)庫維護的成本都要成倍的增長。一方面是節(jié)點增多，發(fā)生故障的幾率變高。對于這種情況，我們需要一套良好的自動failover機制。另一方便隨著數(shù)據(jù)量的增長，要能做到在線彈性擴縮容，保證集群的穩(wěn)定性與可用性。
ClickHouse中的節(jié)點擴容與重分布
與一般的分布式數(shù)據(jù)庫或者Hadoop生態(tài)不同，HDFS可以根據(jù)集群節(jié)點的增減自動的通過balance來調(diào)節(jié)數(shù)據(jù)均衡。但是ClickHouse集群不能自動感知集群拓撲的變化，所以就不能自動balance數(shù)據(jù)。當集群數(shù)據(jù)較大時，新增集群節(jié)點可能會給數(shù)據(jù)負載均衡帶來極大的運維成本。
一般來說，新增集群節(jié)點我們通常有三種方案：
·如果業(yè)務(wù)允許，可以給集群中的表設(shè)置TTL，長時間保留的數(shù)據(jù)會逐漸被清理到，新增的數(shù)據(jù)會自動選擇新節(jié)點，最后會達到負載均衡。
·在集群中建立臨時表，將原表中的數(shù)據(jù)復(fù)制到臨時表，再刪除原表。當數(shù)據(jù)量較大時，或者表的數(shù)量過多時，維護成本較高。同時無法應(yīng)對實時數(shù)據(jù)變更。
·通過配置權(quán)重的方式，將新寫入的數(shù)據(jù)引導(dǎo)到新的節(jié)點。權(quán)重維護成本較高。
無論上述的哪一種方案，從時間成本，硬件資源，實時性等方面考慮，ClickHouse都不是非常適合在線做節(jié)點擴縮容及數(shù)據(jù)充分布。同時，由于ClickHouse中無法做到自動探測節(jié)點拓撲變化，我們可能需要再CMDB中寫入一套數(shù)據(jù)重分布的邏輯。所以我們需要盡可能的提前預(yù)估好數(shù)據(jù)量及節(jié)點的數(shù)量。
StarRocks中的在線彈性擴縮容
與HDFS一樣，當StarRocks集群感知到集群拓撲發(fā)生變化的時候，可以做到在線的彈性擴縮容。避免了增加節(jié)點對業(yè)務(wù)的侵入。
StarRocks中的數(shù)據(jù)采用先分區(qū)再分桶的機制進行存儲。數(shù)據(jù)分桶后，會根據(jù)分桶鍵做hash運算，結(jié)果一致的數(shù)據(jù)被劃分到同一數(shù)據(jù)分片中，我們稱之為tablet。Tablet是StarRocks中數(shù)據(jù)冗余的最小單位，通常我們會默認數(shù)據(jù)以三副本的形式存儲，節(jié)點中通過Quorum協(xié)議進行復(fù)制。當某個節(jié)點發(fā)生宕機時，在其他可用的節(jié)點上會自動補齊丟失的tablet，做到無感知的failover。
在新增節(jié)點時，也會有FE自動的進行調(diào)度，將已有節(jié)點中的tablet自動的調(diào)度到擴容的節(jié)點上，做到自動的數(shù)據(jù)片均衡。為了避免tablet遷移時對業(yè)務(wù)的性能影響，可以盡量選擇在業(yè)務(wù)低峰期進行節(jié)點的擴縮容，或者可以動態(tài)調(diào)整調(diào)度參數(shù)，通過參數(shù)控制tablet調(diào)度的速度，盡可能的減少對業(yè)務(wù)的影響。
ClickHouse與StarRocks的性能對比
單表SSB性能測試
由于ClickHouse join能力有限，無法完成TPCH的測試，這里使用SSB 100G的單表進行測試。
測試環(huán)境
#FormatImgID_4#
測試數(shù)據(jù)
#FormatImgID_5#
測試結(jié)果
從測試結(jié)果中可以看出來，14個測試中，有9個SQL，StarRocks在性能上要超過ClickHouse。
多表TPCH性能測試
ClickHouse不擅長多表關(guān)聯(lián)的場景，對于TPCH測試機，很多查詢無法跑出，或者OOM，目前只進行了StarRocks的TPCH測試。
測試環(huán)境
#FormatImgID_7#
測試數(shù)據(jù)
選用TPCH 100G測試集。
測試結(jié)果
#FormatImgID_9#
導(dǎo)入性能測試
無論是ClickHouse還是StarRocks，我們都可以使用DataX進行全量數(shù)據(jù)的導(dǎo)入，增量部分通過CDC工具寫入到MQ中在經(jīng)過下游數(shù)據(jù)庫消費即可。
數(shù)據(jù)集
導(dǎo)入測試選取了ClickHouse Native Format數(shù)據(jù)集。1個xz格式壓縮文件大概85GB左右，解壓后原始文件1.4T，31億條數(shù)據(jù)，文件格式為CSV
導(dǎo)入方式
ClickHouse中采用的HDFS外表的形式。ClickHouse中分布式表只能選擇一個integer列作為Sharding Key，觀察數(shù)據(jù)發(fā)現(xiàn)技術(shù)都很低，因此使用rand()分布形式。
HDFS外表定義如下：
導(dǎo)入結(jié)果
可以看出，在使用github數(shù)據(jù)集進行導(dǎo)入的時候，基本上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)勢。
