更多技術交流、求職機會、試用福利，歡迎關注位元組跳動資料平臺微信公眾號，回復【1】進入官方交流群
近年來，OLAP產品的競爭日漸激烈，目前企業間流行的既有Impala、Greenplum等上一代較為成熟的資料分析產品，也有ClickHouse、Kylin、Druid、Doris、StarRocks等在不同場景各具特色的新一代分析引擎，這些產品各有勝場，用戶在進行選擇時需要對各產品有全面的了解，并且要求產品知識緊跟最新版本，才能準確的選出適合自己公司的產品，
位元組跳動旗下抖音、今日頭條等產品的成長速度很快，需要分析處理的資料也隨之指數級的快速增長，這對分析的實時性有極高的要求，在選擇OLAP引擎時，位元組也嘗試過Kylin、Druid、Spark等，并且其他產品也做了廣泛的調研，經過不斷嘗試和思考，位元組從性能、穩定、可復用等角度考量，最終選擇了ClickHouse作為主分析引擎，承載位元組跳動廣泛的業務增長分析作業，當前，位元組跳動內部的ClickHouse節點總數已經超過 18000 個，管理總資料量超過 700PB，最大的集群規模在 2400 余個節點，是全國乃至于全世界最大的ClickHouse用戶之一，
位元組跳動的OLAP演進
起初時，最大需求的是“快”，所以位元組團隊嘗試了Kylin，它的優點是能夠提供毫秒級別的查詢延時，但同時Kylin也存在需要預聚合、需要提前定義資料模型和無法進行互動式分析等問題，隨著資料量變大反而會導致回傳結果慢，隨后團隊又希望用Spark來解決問題，但Spark同樣存在不少問題困擾著團隊，比如查詢速度不夠快、資源使用率高、穩定性不夠好，以及無法支持更長時間的資料等，
經過認真思考，位元組決定從以下角度來選擇OLAP分析引擎：
一是對 OLAP 非常樸素又簡單的要求：高可用和強性能，不論給 OLAP 加上多少復用、賦予多少身份，最核心且首要的訴求是能存盤足夠多的資料、足夠穩定，并且可以非常快地查到資料，這是第一個要求——要好用，即滿足海量資料下互動式分析的性能要求，達到秒級回應，
二是復用，在好用的基礎上，團隊希望能盡量用一套技術堆疊解決大部分問題甚至是所有問題，這就需要引擎是可定制的，能讓開發人員在這套技術堆疊上搭建各種面向場景化的應用，
三是易用，能讓用戶更加自主地把產品使用起來，
最終，經過對當時市面上已有的多款開源引擎的調研和測驗，團隊最終選擇采用 ClickHouse 作為 OLAP 查詢引擎，并開始基于此不斷迭代，
ClickHouse簡介
ClickHouse是一個用于聯機分析(OLAP)的列式資料庫管理系統(DBMS)，于2016年開源，以性能強悍著稱，其具備列式存盤、向量化執行引擎、高壓縮比、多核并行計算等特性，
1. 性能強
號稱最快的OLAP引擎，在1億資料量級相同服務器的性能對比如下：
2. 功能豐富
ClickHouse支持資料統計分析各種場景：
-
支持類SQL查詢；
-
支持繁多庫函式（例如IP轉化，URL分析等，預估計算/HyperLoglog等）；
-
支持陣列(Array)和嵌套資料結構(Nested Data Structure)；
-
支持資料庫異地復制部署，
3. 資料匯入速度快
ClickHouse使用大規模并行計算框架，超高吞吐的實時寫入能力，每秒在50-200M量級，
ClickHouse采用類LSM Tree的結構，資料寫入后定期在后臺Compaction，通過類 LSM tree的結構， ClickHouse在資料匯入時全部是順序append寫，寫入后資料段不可更改，在后臺compaction時也是多個段merge sort后順序寫回磁盤，順序寫的特性，充分利用了磁盤的吞吐能力，
4. 發展前景好
自2016年開源以來，ClickHouse憑借其數倍于其他頂尖互動式分析資料庫的極致性能，發展速度非常迅猛，目前，ClickHouse已在Github上獲得24.2K Star，1000+的Contributors，
ClickHouse的缺點
沒有任何一個資料引擎是完美無缺的，在大量使用程序中，位元組也發現了ClickHouse的一些缺點：
1. 關聯查詢能力差
ClickHouse的優勢在單表查詢性能，但是在一些要求靈活查詢的場景，ClickHouse多表關聯能力的不足就暴露了出來，難以滿足這類場景，
2. 依賴Zookeeper
Zookeeper在ClickHouse中主要用于副本表資料的同步（ReplicatedMergeTree引擎）以及分布式表（Distributed）的操作上，但是對Zookeeper的不當使用很容易引起ClickHouse集群的不穩定，
3. 不支持upsert
ClickHouse僅支持批量洗掉或修改資料，ReplacingMergeTree需要依賴merge異步去重，
4. 運維復雜
ClickHouse擴縮容時需要創建新表重新導資料，十分不方便，ClickHouse集群不能自動感知集群拓撲變化，也不能自動balance資料，當集群資料量較大，復制表和分布式表過多時、想做到表維度、或者集群之間的資料平衡會導致運維成本很高，
立即跳轉火山引擎ByteHouse官網了解詳情！歡迎下載《從ClickHouse到ByteHouse》白皮書了解更多~
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/499164.html
標籤：其它