作者介紹

蔡岳毅，攜程酒店大數據高級研發經理，負責酒店數據智能平臺研發，大數據技術創新工作。喜歡探索研究大數據的開源技術框架。

一、背景

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

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

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

二、ClickHouse介紹

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

主要優點有：

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

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

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

三、ClickHouse在酒店數據智能平臺的實踐

1、數據更新

我們的主要數據源是Hive到ClickHouse，現在主要采用如下兩種方式：

① Hive到MySQL，再導入到ClickHouse

初期在DataX不支持Hive到ClickHouse的數據導入，我們是通過DataX將數據先導入MySQL，再通過ClickHouse原生API將數據從MySQL導入到ClickHouse。

為此我們設計了一套完整的數據導入流程，保證數據從Hive到MySQL再到ClickHouse能自動化，穩定的運行，并保證數據在同步過程中線上應用的高可用。

② Hive到ClickHouse

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

針對數據高可用，我們對數據更新機制做了如下設計：

1)全量數據導入流程

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

2)增量數據的導入過程

增量數據的導入過程，我們使用過兩個版本。

由于ClickHouse的delete操作過于沉重，所以最早是通過刪除指定分區，再把增量數據導入正式表的方式來實現的。

這種方式存在如下問題：一是在增量數據導入的過程中，數據的準確性是不可保證的，如果增量數據越多，數據不可用的時間就越長；

二是ClickHouse刪除分區的動作，是在接收到刪除指令之后內異步執行，執行完成時間是未知的。如果增量數據導入后，刪除指令也還在異步執行中，會導致增量數據也會被刪除。最新版的更新日志說已修復這個問題。

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

通過以上流程，基本可以保證用戶對數據的導入過程是無感知的。

2、數據導入過程的監控與預警

由于數據量大，數據同步的語句經常性超時。為保證數據同步的每一個過程都是可監控的，我們沒有使用ClickHouse提供的JDBC來執行數據同步語句，所有的數據同步語句都是通過調用ClickHouse的RestfulAPI來實現的。

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

3、服務器分布與運維

現在主要根據場景分國內，海外/供應商，實時數據，風控數據4個集群。每個集群對應的兩到三臺服務器，相互之間做主備，程序內部將查詢請求分散到不同的服務器上做負載均衡。

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

我們會監控每臺服務器每天的查詢量，每個語句的執行時間，服務器CPU，內存相關指標，以便于及時調整服務器上查詢量比較高的請求到其他服務器。

四、ClickHouse使用探索

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

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

通過查看服務器的各項指標，發現虛擬內存占用量異常。因為存在大量的物理內存和虛擬內存的數據交換，導致查詢速度十分緩慢。關閉虛擬內存，并重啟服務后，應用恢復正常。

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

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

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

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

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

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

8)服務器CPU一般在50%左右會出現查詢波動，CPU達到70%會出現大范圍的查詢超時，所以ClickHouse最關鍵的指標CPU要非常關注。我們內部對所有ClickHouse查詢都有監控，當出現查詢波動的時候會有郵件預警。

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

五、總結

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

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

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

更多大數據架構、實戰經驗，歡迎關注【大數據與機器學習】，期待與你一起成長！

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。