大家好，短視頻軟件，快手現在風頭正盛，面對如此大的用戶量，今天帶來 《Clickhouse在快手的架構和技術內幕》
先說下Clickhouse - 越來越多的新型OLAP數據庫涌現，無論是 Clickhouse還是Apache Doris都在逐漸變得流行。其背后一定是有原因的。
Hadoop那套組件眾多，運維壓力越來越大，因此新型OLAP相對不依賴hadoop生態，簡介的架構的特性就很吸引人。
ClickHouse 是俄羅斯Yandex在2016年開源的性能分析型SQL數據庫，主要面向OLAP場景。開源之后，憑借優異的查詢性能，受到業界的青睞。
官網風格清新
直觀感受有多快：
如圖一，clickhouse官網做了很多壓測，比較了 MySQL、hive、greenplum、vertica、clickhouse
clickhouse 比 hive 快百倍（這個很正常，大家都想得到），而比 vertica 快幾倍，比 greenplum 20倍左右。
快的一騎絕塵
Clickhouse的快速主要是因為 存儲和計算都快，這里有一些關鍵特性。
圖二：存儲快速的原因： 主鍵存儲、列式、塊索引、數據分區、本機存儲、多重索引
圖三：計算快速的原因： 分布式、多線程、向量化、LLVM、RuntimeCodegen
快手使用Clickhouse的規模，截至2019年底。 （圖四）
- 存儲了 10PB數據；
- 每天新增200TB數據；
- 每天查詢 50w；
- 查詢的時延（P90) < 3s
快手使用Clickhouse的場景：
這個都比較常見，無非是 BI系統、報表系統、監控系統、ABTEST和用戶分析系統
（小編注：
- 報表系統一般指的是傳統的、類似Excel的多表頭復雜中國式報表，一般每一個單元格都是有單獨計算邏輯；
- BI一般是在數據倉庫建設完成后，可以通過BI軟件自助分析的圖表；
- 監控系統一般是一個酷炫的大屏）
圖五，快手Clickhouse的部署架構；
多集群是必須的，通過一個路由進行分流，做一些類似“切面”“網關”做的工作。
數據則是通過 mapreduce（無論是 hive、sparksql 還是其他） 和 flink 進入clickhouse。
Clickhouse在單表的情況下性能比多表join好很多，快手因此總結了一些最佳實踐。見圖六。
如果是普通企業，到此也差不多了，快手由于業務量大，仍遇到了一些問題難以解決，針對問題，快手提出了Clickhouse on Hdfs 的方案，即存儲和計算分離，存儲使用hadoop hdfs。自己基于接口重寫了 HdfsMergeTree實現。
架構示意
自研HdfsMergeTree 存儲引擎
具體涉及的優化點很多，細節相對有深度，這里就不多說了，看一下圖九的總結。
歡迎 點贊、轉發 ！
您的支持是我更新的動力！
