大數據

干貨 | 每天十億級數據更新,秒出查詢結果,ClickHouse在攜程酒店的應用

本文轉自 | 攜程技術中心  作者 | 蔡岳毅

作者簡介

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

一、背景

1)攜程酒店每天有上千表,累計十多億數據更新,如何保證數據更新過程中生產應用高可用;

2)每天有將近百萬次數據查詢請求,用戶可以從粗粒度國家省份城市匯總不斷下鉆到酒店,房型粒度的數據,我們往往無法對海量的明細數據做進一步層次的預聚合,大量的關鍵業務數據都是好幾億數據關聯權限,關聯基礎信息,根據用戶場景獲取不同維度的匯總數據;

3)為了讓用戶無論在app端還是pc端查詢數據提供秒出的效果,我們需要不斷的探索,研究找到最合適的技術框架。

對此,我們嘗試過關系型數據庫,但千萬級表關聯數據庫基本上不太可能做到秒出,考慮過Sharding,但數據量大,各種成本都很高。熱數據存儲到ElasticSearch,但無法跨索引關聯,導致不得不做寬表,因為權限,酒店信息會變,所以每次要刷全量數據,不適用于大表更新,維護成本也很高。Redis鍵值對存儲無法做到實時匯總,也測試過Presto,GreenPlum,kylin,真正讓我們停下來深入研究,不斷的擴展使用場景的是ClickHouse。

二、ClickHouse介紹

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

主要優點有:

1)為了高效的使用CPU,數據不僅僅按列存儲,同時還按向量進行處理;

2)數據壓縮空間大,減少io;處理單查詢高吞吐量每臺服務器每秒最多數十億行;

3)索引非B樹結構,不需要滿足最左原則;只要過濾條件在索引列中包含即可;即使在使用的數據不在索引中,由于各種并行處理機制ClickHouse全表掃描的速度也很快;

4)寫入速度非常快,50-200M/s,對于大量的數據更新非常適用;

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

1)不支持事務,不支持真正的刪除/更新;

2)不支持高并發,官方建議qps為100,可以通過修改配置文件增加連接數,但是在服務器足夠好的情況下;

3)sql滿足日常使用80%以上的語法,join寫法比較特殊;最新版已支持類似sql的join,但性能不好;

4)盡量做1000條以上批量的寫入,避免逐行insert或小批量的insert,update,delete操作,因為ClickHouse底層會不斷的做異步的數據合并,會影響查詢性能,這個在做實時數據寫入的時候要盡量避開;

5)Clickhouse快是因為采用了并行處理機制,即使一個查詢,也會用服務器一半的cpu去執行,所以ClickHouse不能支持高并發的使用場景,默認單查詢使用cpu核數為服務器核數的一半,安裝時會自動識別服務器核數,可以通過配置文件修改該參數;

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

3.1 數據更新

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

1)Hive到MySql,再導入到ClickHouse

初期在DataX不支持hive到ClickHouse的數據導入,我們是通過DataX將數據先導入mysql,再通過ClickHouse原生api將數據從mysql導入到ClickHouse。

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

2)Hive到ClickHouse

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

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

3.1.1全量數據導入流程

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

3.1.2增量數據的導入過程

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

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

這種方式存在如下問題:一是在增量數據導入的過程中,數據的準確性是不可保證的,如果增量數據越多,數據不可用的時間就越長;二是ClickHouse刪除分區的動作,是在接收到刪除指令之后內異步執行,執行完成時間是未知的。如果增量數據導入后,刪除指令也還在異步執行中,會導致增量數據也會被刪除。最新版的更新日志說已修復這個問題。

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

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

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

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

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

3.3 服務器分布與運維

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

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

下半年計劃把每個集群的兩臺機器分散到不同的機房,可以繼續起到現有的主備,負載均衡的作用還能起到dr的作用。同時為了保障線上應用的高可用,我們會實現自動健康檢測機制,針對突發異常的服務器自動拉出我們的虛擬集群。

我們會監控每臺服務器每天的查詢量,每個語句的執行時間,服務器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,跟進最新的版本,同時也會繼續保持對外界更好的開源框架的研究,嘗試,尋找到更合適我們的技術框架。

我還沒有學會寫個人說明!

“What‘’s your problem?”李彥宏被潑冷水后問道

上一篇

五年磨一劍 中興GoldenDB數據庫出征

下一篇

你也可能喜歡

干貨 | 每天十億級數據更新,秒出查詢結果,ClickHouse在攜程酒店的應用

長按儲存圖像,分享給朋友

ITPUB 每周精要將以郵件的形式發放至您的郵箱


微信掃一掃

微信掃一掃
重庆百变王牌开奖结果