作者介紹

蔡岳毅，攜程酒店大數(shù)據(jù)高級研發(fā)經(jīng)理，負(fù)責(zé)酒店數(shù)據(jù)智能平臺研發(fā)，大數(shù)據(jù)技術(shù)創(chuàng)新工作。喜歡探索研究大數(shù)據(jù)的開源技術(shù)框架。

一、背景

• 攜程酒店每天有上千表，累計十多億數(shù)據(jù)更新，如何保證數(shù)據(jù)更新過程中生產(chǎn)應(yīng)用高可用；
• 每天有將近百萬次數(shù)據(jù)查詢請求，用戶可以從粗粒度國家省份城市匯總不斷下鉆到酒店，房型粒度的數(shù)據(jù)，我們往往無法對海量的明細(xì)數(shù)據(jù)做進(jìn)一步層次的預(yù)聚合，大量的關(guān)鍵業(yè)務(wù)數(shù)據(jù)都是好幾億數(shù)據(jù)關(guān)聯(lián)權(quán)限，關(guān)聯(lián)基礎(chǔ)信息，根據(jù)用戶場景獲取不同維度的匯總數(shù)據(jù)；
• 為了讓用戶無論在app端還是pc端查詢數(shù)據(jù)提供秒出的效果，我們需要不斷的探索，研究找到最合適的技術(shù)框架。

對此，我們嘗試過關(guān)系型數(shù)據(jù)庫，但千萬級表關(guān)聯(lián)數(shù)據(jù)庫基本上不太可能做到秒出；考慮過Sharding，但數(shù)據(jù)量大，各種成本都很高；熱數(shù)據(jù)存儲到ElasticSearch，但無法跨索引關(guān)聯(lián)，導(dǎo)致不得不做寬表，因為權(quán)限，酒店信息會變，所以每次要刷全量數(shù)據(jù)，不適用于大表更新，維護(hù)成本也很高；Redis鍵值對存儲無法做到實時匯總；也測試過Presto、GreenPlum、Kylin......

真正讓我們停下來深入研究，不斷擴(kuò)展使用場景的，是ClickHouse。

二、ClickHouse介紹

ClickHouse是一款用于大數(shù)據(jù)實時分析的列式數(shù)據(jù)庫管理系統(tǒng)，而非數(shù)據(jù)庫。通過向量化執(zhí)行以及對CPU底層指令集(SIMD)的使用，它可以對海量數(shù)據(jù)進(jìn)行并行處理，從而加快數(shù)據(jù)的處理速度。

主要優(yōu)點有：

• 為了高效的使用CPU，數(shù)據(jù)不僅僅按列存儲，同時還按向量進(jìn)行處理；
• 數(shù)據(jù)壓縮空間大，減少IO；處理單查詢高吞吐量每臺服務(wù)器每秒最多數(shù)十億行；
• 索引非B樹結(jié)構(gòu)，不需要滿足最左原則；只要過濾條件在索引列中包含即可；即使在使用的數(shù)據(jù)不在索引中，由于各種并行處理機(jī)制ClickHouse全表掃描的速度也很快；
• 寫入速度非?？?#xff0c;50-200M/s，對于大量的數(shù)據(jù)更新非常適用。

ClickHouse并非萬能的，正因為ClickHouse處理速度快，所以也是需要為“快”付出代價。選擇ClickHouse需要有下面注意以下幾點：

• 不支持事務(wù)，不支持真正的刪除/更新；
• 不支持高并發(fā)，官方建議qps為100，可以通過修改配置文件增加連接數(shù)，但是在服務(wù)器足夠好的情況下；
• SQL滿足日常使用80%以上的語法，join寫法比較特殊；最新版已支持類似SQL的join，但性能不好；
• 盡量做1000條以上批量的寫入，避免逐行insert或小批量的insert，update，delete操作，因為ClickHouse底層會不斷的做異步的數(shù)據(jù)合并，會影響查詢性能，這個在做實時數(shù)據(jù)寫入的時候要盡量避開；
• Clickhouse快是因為采用了并行處理機(jī)制，即使一個查詢，也會用服務(wù)器一半的CPU去執(zhí)行，所以ClickHouse不能支持高并發(fā)的使用場景，默認(rèn)單查詢使用CPU核數(shù)為服務(wù)器核數(shù)的一半，安裝時會自動識別服務(wù)器核數(shù)，可以通過配置文件修改該參數(shù)。

三、ClickHouse在酒店數(shù)據(jù)智能平臺的實踐

1、數(shù)據(jù)更新

我們的主要數(shù)據(jù)源是Hive到ClickHouse，現(xiàn)在主要采用如下兩種方式：

① Hive到MySQL，再導(dǎo)入到ClickHouse

初期在DataX不支持Hive到ClickHouse的數(shù)據(jù)導(dǎo)入，我們是通過DataX將數(shù)據(jù)先導(dǎo)入MySQL，再通過ClickHouse原生API將數(shù)據(jù)從MySQL導(dǎo)入到ClickHouse。

為此我們設(shè)計了一套完整的數(shù)據(jù)導(dǎo)入流程，保證數(shù)據(jù)從Hive到MySQL再到ClickHouse能自動化，穩(wěn)定的運行，并保證數(shù)據(jù)在同步過程中線上應(yīng)用的高可用。

② Hive到ClickHouse

DataX現(xiàn)在支持Hive到ClickHouse，我們部分?jǐn)?shù)據(jù)是通過DataX直接導(dǎo)入ClickHouse。但DataX暫時只支持導(dǎo)入，因為要保證線上的高可用，所以僅僅導(dǎo)入是不夠的，還需要繼續(xù)依賴我們上面的一套流程來做ReName，增量數(shù)據(jù)更新等操作。

針對數(shù)據(jù)高可用，我們對數(shù)據(jù)更新機(jī)制做了如下設(shè)計：

1)全量數(shù)據(jù)導(dǎo)入流程

全量數(shù)據(jù)的導(dǎo)入過程比較簡單，僅需要將數(shù)據(jù)先導(dǎo)入到臨時表中，導(dǎo)入完成之后，再通過對正式表和臨時表進(jìn)行ReName操作，將對數(shù)據(jù)的讀取從老數(shù)據(jù)切換到新數(shù)據(jù)上來。

2)增量數(shù)據(jù)的導(dǎo)入過程

增量數(shù)據(jù)的導(dǎo)入過程，我們使用過兩個版本。

由于ClickHouse的delete操作過于沉重，所以最早是通過刪除指定分區(qū)，再把增量數(shù)據(jù)導(dǎo)入正式表的方式來實現(xiàn)的。

這種方式存在如下問題：一是在增量數(shù)據(jù)導(dǎo)入的過程中，數(shù)據(jù)的準(zhǔn)確性是不可保證的，如果增量數(shù)據(jù)越多，數(shù)據(jù)不可用的時間就越長；

二是ClickHouse刪除分區(qū)的動作，是在接收到刪除指令之后內(nèi)異步執(zhí)行，執(zhí)行完成時間是未知的。如果增量數(shù)據(jù)導(dǎo)入后，刪除指令也還在異步執(zhí)行中，會導(dǎo)致增量數(shù)據(jù)也會被刪除。最新版的更新日志說已修復(fù)這個問題。

針對以上情況，我們修改了增量數(shù)據(jù)的同步方案。在增量數(shù)據(jù)從Hive同步到ClickHouse的臨時表之后，將正式表中數(shù)據(jù)反寫到臨時表中，然后通過ReName方法切換正式表和臨時表。

通過以上流程，基本可以保證用戶對數(shù)據(jù)的導(dǎo)入過程是無感知的。

2、數(shù)據(jù)導(dǎo)入過程的監(jiān)控與預(yù)警

由于數(shù)據(jù)量大，數(shù)據(jù)同步的語句經(jīng)常性超時。為保證數(shù)據(jù)同步的每一個過程都是可監(jiān)控的，我們沒有使用ClickHouse提供的JDBC來執(zhí)行數(shù)據(jù)同步語句，所有的數(shù)據(jù)同步語句都是通過調(diào)用ClickHouse的RestfulAPI來實現(xiàn)的。

調(diào)用RestfulAPI的時候，可以指定本次查詢的QueryID。在數(shù)據(jù)同步語句超時的情況下，通過輪詢來獲得某QueryID的執(zhí)行進(jìn)度。這樣保證了整個查詢過程的有序運行。在輪詢的過程中，會對異常情況進(jìn)行記錄，如果異常情況出現(xiàn)的頻次超過閾值，JOB會通過短信給相關(guān)人員發(fā)出預(yù)警短信。

3、服務(wù)器分布與運維

現(xiàn)在主要根據(jù)場景分國內(nèi)，海外/供應(yīng)商，實時數(shù)據(jù)，風(fēng)控數(shù)據(jù)4個集群。每個集群對應(yīng)的兩到三臺服務(wù)器，相互之間做主備，程序內(nèi)部將查詢請求分散到不同的服務(wù)器上做負(fù)載均衡。

假如某一臺服務(wù)器出現(xiàn)故障，通過配置界面修改某個集群的服務(wù)器節(jié)點，該集群的請求就不會落到有故障的服務(wù)器上。如果在某個時間段某個特定的數(shù)據(jù)查詢量比較大，組建虛擬集群，將所有的請求分散到其他資源富于的物理集群上。

我們會監(jiān)控每臺服務(wù)器每天的查詢量，每個語句的執(zhí)行時間，服務(wù)器CPU，內(nèi)存相關(guān)指標(biāo)，以便于及時調(diào)整服務(wù)器上查詢量比較高的請求到其他服務(wù)器。

四、ClickHouse使用探索

我們在使用ClickHouse的過程中遇到過各種各樣的問題，總結(jié)出來供大家參考：

1)關(guān)閉Linux虛擬內(nèi)存。在一次ClickHouse服務(wù)器內(nèi)存耗盡的情況下，我們Kill掉占用內(nèi)存最多的Query之后發(fā)現(xiàn)，這臺ClickHouse服務(wù)器并沒有如預(yù)期的那樣恢復(fù)正常，所有的查詢依然運行的十分緩慢。

通過查看服務(wù)器的各項指標(biāo)，發(fā)現(xiàn)虛擬內(nèi)存占用量異常。因為存在大量的物理內(nèi)存和虛擬內(nèi)存的數(shù)據(jù)交換，導(dǎo)致查詢速度十分緩慢。關(guān)閉虛擬內(nèi)存，并重啟服務(wù)后，應(yīng)用恢復(fù)正常。

2)為每一個賬戶添加join_use_nulls配置。ClickHouse的SQL語法是非標(biāo)準(zhǔn)的，默認(rèn)情況下，以Left Join為例，如果左表中的一條記錄在右表中不存在，右表的相應(yīng)字段會返回該字段相應(yīng)數(shù)據(jù)類型的默認(rèn)值，而不是標(biāo)準(zhǔn)SQL中的Null值。對于習(xí)慣了標(biāo)準(zhǔn)SQL的我們來說，這種返回值經(jīng)常會造成困擾。

3)JOIN操作時一定要把數(shù)據(jù)量小的表放在右邊，ClickHouse中無論是Left Join 、Right Join還是Inner Join永遠(yuǎn)都是拿著右表中的每一條記錄到左表中查找該記錄是否存在，所以右表必須是小表。

4)通過ClickHouse官方的JDBC向ClickHouse中批量寫入數(shù)據(jù)時，必須控制每個批次的數(shù)據(jù)中涉及到的分區(qū)的數(shù)量，在寫入之前最好通過Order By語句對需要導(dǎo)入的數(shù)據(jù)進(jìn)行排序。無序的數(shù)據(jù)或者數(shù)據(jù)中涉及的分區(qū)太多，會導(dǎo)致ClickHouse無法及時的對新導(dǎo)入的數(shù)據(jù)進(jìn)行合并，從而影響查詢性能。

5)盡量減少JOIN時的左右表的數(shù)據(jù)量，必要時可以提前對某張表進(jìn)行聚合操作，減少數(shù)據(jù)條數(shù)。有些時候，先GROUP BY再JOIN比先JOIN再GROUP BY查詢時間更短。

6)ClickHouse版本迭代很快，建議用去年的穩(wěn)定版，不能太激進(jìn)，新版本我們在使用過程中遇到過一些bug，內(nèi)存泄漏，語法不兼容但也不報錯，配置文件并發(fā)數(shù)修改后無法生效等問題。

7)避免使用分布式表，ClickHouse的分布式表性能上性價比不如物理表高，建表分區(qū)字段值不宜過多，太多的分區(qū)數(shù)據(jù)導(dǎo)入過程磁盤可能會被打滿。

8)服務(wù)器CPU一般在50%左右會出現(xiàn)查詢波動，CPU達(dá)到70%會出現(xiàn)大范圍的查詢超時，所以ClickHouse最關(guān)鍵的指標(biāo)CPU要非常關(guān)注。我們內(nèi)部對所有ClickHouse查詢都有監(jiān)控，當(dāng)出現(xiàn)查詢波動的時候會有郵件預(yù)警。

9)查詢測試Case有：6000W數(shù)據(jù)關(guān)聯(lián)1000W數(shù)據(jù)再關(guān)聯(lián)2000W數(shù)據(jù)sum一個月間夜量返回結(jié)果：190ms；2.4億數(shù)據(jù)關(guān)聯(lián)2000W的數(shù)據(jù)group by一個月的數(shù)據(jù)大概390ms。但ClickHouse并非無所不能，查詢語句需要不斷的調(diào)優(yōu)，可能與查詢條件有關(guān)，不同的查詢條件表是左join還是右join也是很有講究的。

五、總結(jié)

酒店數(shù)據(jù)智能平臺從去年7月份試點，到現(xiàn)在80%以上的業(yè)務(wù)都已接入ClickHouse。滿足每天十多億的數(shù)據(jù)更新和近百萬次的數(shù)據(jù)查詢，支撐app性能98.3%在1秒內(nèi)返回結(jié)果，pc端98.5%在3秒內(nèi)返回結(jié)果。

從使用的角度，查詢性能不是數(shù)據(jù)庫能相比的，從成本上也是遠(yuǎn)低于關(guān)系型數(shù)據(jù)庫成本的，單機(jī)支撐40億以上的數(shù)據(jù)查詢毫無壓力。與ElasticSearch、Redis相比ClickHouse可以滿足我們大部分使用場景。

我們會繼續(xù)更深入研究ClickHouse，跟進(jìn)最新的版本，同時也會繼續(xù)保持對外界更好的開源框架的研究，嘗試，尋找到更合適我們的技術(shù)框架。

更多大數(shù)據(jù)架構(gòu)、實戰(zhàn)經(jīng)驗，歡迎關(guān)注【大數(shù)據(jù)與機(jī)器學(xué)習(xí)】，期待與你一起成長！

總結(jié)

以上是生活随笔為你收集整理的clickhouse集群表删除_携程用ClickHouse轻松玩转每天十亿级数据更新的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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