[業界方案] ClickHouse業界解決方案學習筆記
0x00 摘要
本文通過分析總結幾篇文章來看目前工業界可能偏好的解決方案。學習目的是：大致知道其應用領域，技術特點和未來方向，看看目前工作中是否可以用到，或者當以后選型時候能夠做到心里有數。
0x01 簡介
ClickHouse是近年來備受關注的開源列式數據庫，主要用於數據分析（OLAP）領域。
目前國內社區火熱，各個大廠紛紛跟進大規模使用：
- 今日頭條用ClickHouse來做用戶行為分析，一共幾千個ClickHouse節點，單集群最大1200節點，總數據量幾十PB，日增原始數據300TB左右。
- 騰訊內部用ClickHouse做游戲數據分析，並且為之建立了一整套監控運維體系。
- 攜程目前80%的業務都跑在ClickHouse上。每天數據增量十多億，近百萬次查詢請求。
- 快手內部也在使用ClickHouse，存儲總量大約10PB， 每天新增200TB， 90%查詢小於3S。
- 在國外，Yandex內部有數百節點用於做用戶點擊行為分析，CloudFlare、Spotify等頭部公司也在使用。
0x02 OLAP場景的特點
- 讀多於寫，需要嘗試從各個角度對數據做挖掘、分析。需要反復試錯、不斷調整、持續優化，其中數據的讀取次數遠多於寫入次數。要求底層數據庫為這個特點做專門設計。
- 大寬表，讀大量行但是少量列，結果集較小
- 數據批量寫入，且數據不更新或少更新
- 無需事務，數據一致性要求低
- 靈活多變，不適合預先建模
0x03 選型原因
攜程選型原因
- 嘗試過關系型數據庫，但千萬級表關聯數據庫基本上不太可能做到秒出
- 考慮過Sharding，但數據量大，各種成本都很高。
- 熱數據存儲到ElasticSearch，但無法跨索引關聯，導致不得不做寬表，因為權限，酒店信息會變，所以每次要刷全量數據，不適用於大表更新，維護成本也很高。
- Redis鍵值對存儲無法做到實時匯總，
- 也測試過Presto，GreenPlum，kylin，真正讓我們停下來深入研究，不斷的擴展使用場景的是ClickHouse。
頭條選型原因
-
產品需求
-
- 交互式分析能力（in seconds）
- 查詢模式多變
- 以大寬表為主
- 數據量大
-
開源MPP OLAP引擎 - （性能、特點、優質）
0x04 技術特點
ClickHouse從OLAP場景需求出發，定制開發了一套全新的高效列式存儲引擎，並且實現了數據有序存儲、主鍵索引、稀疏索引、數據Sharding、數據Partitioning、TTL、主備復制等豐富功能。以上功能共同為ClickHouse極速的分析性能奠定了基礎。
從用戶角度來說 ，ClickHouse就是實現了“多快好省，獨立”。
- 快：提供了極致的查詢性能
- 多：支持分布式集群模式，支持高吞吐寫入能力
- 省：以極低的成本存儲海量數據
- 好：提供完善SQL支持，上手十分簡單；提供json、map、array等靈活數據類型適配業務快速變化；同時支持近似計算、概率數據結構等應對海量數據處理。
- 獨立：獨立於Hadoop技術棧
下面我們逐一介紹。
0x05 多
“多”這個特點具體是由如下具體技術實現來完成的。
數據Sharding
ClickHouse支持單機模式，也支持分布式集群模式。在分布式模式下，ClickHouse會將數據分為多個分片，並且分布到不同節點上。不同的分片策略在應對不同的SQL Pattern時，各有優勢。ClickHouse提供了豐富的sharding策略，讓業務可以根據實際需求選用。
sharding機制使得ClickHouse可以橫向線性拓展，構建大規模分布式集群，從而具備處理海量數據的能力。
數據Partitioning
ClickHouse支持PARTITION BY子句，在建表時可以指定按照任意合法表達式進行數據分區操作。
- 在partition key上進行分區裁剪，只查詢必要的數據。
- 對partition進行TTL管理，淘汰過期的分區數據。
高吞吐寫入能力
ClickHouse采用類LSM Tree的結構，數據寫入后定期在后台Compaction。通過類LSM tree的結構，ClickHouse在數據導入時全部是順序append寫，寫入后數據段不可更改，在后台compaction時也是多個段merge sort后順序寫回磁盤。順序寫的特性，充分利用了磁盤的吞吐能力，即便在HDD上也有着優異的寫入性能。
支持數據復制和數據完整性
ClickHouse 使用異步的多主復制技術。當數據被寫入到任何一個可用副本后，系統在后台將數據分發給其他副本。
0x06 快
“ 快”這個特點具體是由如下具體技術實現來完成的。
列式存儲
- 而列存模式下，只需要讀取參與計算的列即可，極大的減低了IO cost，加速了查詢。
- 同一列中的數據屬於同一類型，壓縮效果顯著。列存往往有着高達十倍甚至更高的壓縮比，更高的壓縮比意味着更小的data size，從磁盤中讀取相應數據耗時更短。
主鍵索引
ClickHouse支持主鍵索引。通過對主鍵索引進行二分查找，能夠直接定位到對應的index granularity，避免了全表掃描從而加速查詢。ClickHouse的主鍵索引並不用於去重，即便primary key相同的行，也可以同時存在於數據庫中。
稀疏索引
ClickHouse支持對任意列創建任意數量的稀疏索引。之所以叫稀疏索引，是因為它本質上是對一個完整index granularity（默認8192行）的統計信息，並不會具體記錄每一行在文件中的位置。
實時數據更新
ClcikHouse 數據是以增量的方式有序的存儲在 MergeTree 中。因此，數據可以持續不斷高效的寫入到表中，並且寫入的過程中不會存在任何加鎖的行為。
支持近似計算
ClickHouse 提供各種各樣在允許犧牲精度的情況下對查詢進行加速的方法
- 用於近似計算的各類聚合函數，比如，近似估算distinct values、中位數，分位數等多種聚合函數；
- 基於數據的部分樣本進行近似查詢，比如，建表DDL支持SAMPLE BY子句，支持對於數據進行抽樣處理；
- 不使用全部的聚合條件，通過隨機選擇有限個數據聚合條件進行聚合。
多核並行
ClickHouse將數據划分為多個partition，每個partition再進一步划分為多個index granularity，然后通過多個CPU核心分別處理其中的一部分來實現並行數據處理。在這種設計下，單條Query就能利用整機所有CPU。極致的並行處理能力，極大的降低了查詢延時。
向量化執行與SIMD
ClickHouse不僅將數據按列存儲，而且按列進行計算。ClickHouse實現了向量執行引擎（Vectorized execution engine），對內存中的列式數據，一個batch調用一次SIMD指令（而非每一行調用一次），不僅減少了函數調用次數、降低了cache miss，而且可以充分發揮SIMD指令的並行能力，大幅縮短了計算耗時。向量執行引擎，通常能夠帶來數倍的性能提升。
分布式計算
除了優秀的單機並行處理能力，ClickHouse還提供了可線性拓展的分布式計算能力。ClickHouse會自動將查詢拆解為多個task下發到集群中，然后進行多機並行處理，最后把結果匯聚到一起。
數據Sharding
數據分片，讓ClickHouse可以充分利用整個集群的大規模並行計算能力，快速返回查詢結果。
0x07 好
“ 好”這個特點具體是由如下具體技術實現來完成的。
復雜數據類型支持
ClickHouse還提供了array、json、tuple、set等復合數據類型，支持業務schema的靈活變更。
主備同步
ClickHouse通過主備復制提供了高可用能力，主備架構下支持無縫升級等運維操作。而且相比於其他系統它的實現有着自己的特色：
1）默認配置下，任何副本都處於active模式，可以對外提供查詢服務；
2）可以任意配置副本個數，副本數量可以從0個到任意多個；
3）不同shard可以配置不提供副本個數，用於解決單個shard的查詢熱點問題；
支持數據復制和數據完整性
ClickHouse 使用異步的多住復制技術。當數據被寫入到任何一個可用副本后，系統在后台將數據分發給其他副本。
功能多
- 支持類SQL查詢，比ES的DSL更加簡單，學習成本更低。
- 支持繁多庫函數（例如IP轉化，URL分析等，預估計算/HyperLoglog等）
- 支持數據庫異地復制部署
穩定性更高，運維成本更低
相比ES，ClickHouse穩定性更高，運維成本更低。
- ES中不同的Group負載不均衡，有的Group負載高，會導致寫Rejected等問題，需要人工遷移索引；在ClickHouse中通過集群和Shard策略，采用輪詢寫的方法，可以讓數據比較均衡的分布到所有節點。
- ES中一個大查詢可能導致OOM的問題；ClickHouse通過預設的查詢限制，會查詢失敗，不影響整體的穩定性。
- ES需要進行冷熱數據分離，每天200T的數據搬遷，稍有不慎就會導致搬遷過程發生問題，一旦搬遷失敗，熱節點可能很快就會被撐爆，導致一大堆人工維護恢復的工作；ClickHouse按天分partition，一般不需要考慮冷熱分離，特殊場景用戶確實需要冷熱分離的，數據量也會小很多，ClickHouse自帶的冷熱分離機制就可以很好的解決。
0x08 省
“ 省”這個特點具體是由如下具體技術實現來完成的。
列式存儲
- 而列存模式下，同一列中的數據屬於同一類型，壓縮效果顯著。列存往往有着高達十倍甚至更高的壓縮比，節省了大量的存儲空間，降低了存儲成本。
- 高壓縮比，意味着同等大小的內存能夠存放更多數據，系統cache效果更好。
數據TTL
在分析場景中，數據的價值隨着時間流逝而不斷降低，多數業務出於成本考慮只會保留最近幾個月的數據，ClickHouse通過TTL提供了數據生命周期管理的能力。
有限支持delete、update
在分析場景中，刪除、更新操作並不是核心需求。ClickHouse沒有直接支持delete、update操作，而是變相支持了mutation操作。目前主要限制為刪除、更新操作為異步操作，需要后台compation之后才能生效。
動態代碼生成Runtime Codegen
ClickHouse實現了Expression級別的runtime codegen，動態地根據當前SQL直接生成代碼，然后編譯執行。不僅消除了大量的虛函數調用（即圖中多個function pointer的調用），而且由於在運行時表達式的參數類型、個數等都是已知的，也消除了不必要的if-else分支判斷。
0x09 獨立
基於Hadoop而衍生的Hive、Pig、Spark、Presto、Impala等一系列組件共同構成了Hadoop生態體系。Hadoop生態為今天的大數據領域提供着穩定可靠的數據服務。
Hadoop生態體系解決了大數據界的大部分問題，當然其也存在缺點。Hadoop體系的最大短板在於數據處理時效性。基於Hadoop生態的數據處理場景大部分對時效要求不高，按照傳統的做法一般是 T + 1 的數據時效。即 Trade + 1，數據產出在交易日 + 1 天。
ClickHouse的產生就是為了解決大數據量處理的時效性。完全獨立於Hadoop生態。
0x10 ClickHouse 的缺點
- 沒有完整的事務支持
- 缺少高頻率、低延遲的修改或刪除已存在數據的能力，僅能用於批量刪除或修改數據。
- 不支持Transaction：想快就別想Transaction
- 聚合結果必須小於一台機器的內存大小：不是大問題
- 缺少完整的Update/Delete操作
- 支持有限操作系統
- 不支持高並發，官方建議qps為100
0x11 下一步發展
ClickHouse會向兩個方向發展。
1 雲計算數據庫：
Yandex希望通過ClickHouse促進公司雲計算數據庫的發展，包括用戶可以通過雲服務的方式，使用ClickHouse，開源是走向市場的第一步。
2. 加強SQL兼容性。
為了支持更多的企業用戶，目前的查詢雖然采用非常近似的SQL語言，但是還有很多地方需要改進，包括和一些商業軟件（例如Tableau,Pentaho）的集成無縫使用。
0xFF 參考
最快開源 OLAP 引擎！ ClickHouse 在頭條的技術演進