clickhouse 應用總結調研：
概述:
clickhouse 是俄羅斯的“百度”Yandex公司在2016年開源的，一款針對大數據實時分析的高性能分佈式數據庫，與之對應的有hadoop生態hive，Vertica和百度出品的palo。
其作爲分析型數據庫，有三大特點：一是跑分快，二是功能多，三是文藝範。
背景：
Hadoop 生態體系解決了大數據界的大部分問題，當然其也存在缺點。Hadoop 體系的最大短板在於數據處理時效性。基於 Hadoop 生態的數據處理場景大部分對時效要求不高，按照傳統的做法一般是 T + 1 的數據時效進行數據分析
ClickHouse 的產生就是爲了解決大數據量處理的時效性。獨立於Hadoop生態圈
特性：
（1）採用列式存儲
（2）數據壓縮
（3）CPU 利用率高，在計算時會使用機器上的所有 CPU 資源
（4）支持分片，並且同一個計算任務會在不同分片上並行執行，計算完成後會將結果彙總
（5）支持SQL，SQL 幾乎成了大數據的標準工具，使用門檻較低
（6）支持聯表查詢
（7）支持實時更新
（8）自動多副本同步
（9）支持索引
（10）分佈式存儲查詢
優劣總結：
優點
1、性能高，列存壓縮比高，通過索引實現秒級響應
2、實時性強，支持kafka導入
3、處理方式簡單，無需預處理，保存明細數據
4、數據壓縮、多核並行處理
5、支持數據複製和數據完整性
shard分片
replica副本
6、多服務器分佈式處理。其他列式數據庫管理系統中，幾乎沒有一個支持分佈式的查詢處理（但 沒有完整的事務支持。）
7、支持sql 大部分情況下是與SQL標準兼容的。 支持的查詢包括 GROUP BY，ORDER BY，IN，JOIN以及非相關子查詢。 不支持窗口函數和相關子查詢。（但易用性較弱，SQL語法不標準，不支持窗口函數等；維護成本高）
8、向量引擎、實時數據插入
9、稀疏索引、適合在線查詢
缺點
1、數據規模一般
2、靈活性差，不支持任意的adhoc查詢，join的支持不好。
3、缺少高頻率，低延遲的修改或刪除已存在數據的能力。僅能用於批量刪除或修改數據，但這符合 GDPR。
稀疏索引使得ClickHouse不適合通過其鍵檢索單行的點查詢。
druid 實時數據分析（olap）
背景：
大數據時代，從海量數據中提取有價值的信息，業內出現了衆多優秀的開源項目，其中最有名的當屬Apache Hadoop生態圈。時至今日，Hadoop已經成爲了大數據的“標準”解決方案，其作爲海量歷史數據保存、冷數據分析，確實是一個優秀的通用解決方案，但是，人們在享受Hadoop便捷數據分析的同時，也必須要忍受Hadoop在設計上的許多“痛點”
（1）、何時能進行數據查詢？對於Hadoop使用的Map/Reduce批處理框架，數據何時能夠查詢沒有性能時間保證。
（2）、隨機IO問題。Map/Reduce批處理框架所處理的數據需要存儲在HDFS上，而HDFS是一個以集羣硬盤作爲存儲資源池的分佈式文件系統，那麼在海量數據的處理過程中，必然會引起大量的讀寫操作，此時隨機IO就成爲了高併發場景下的性能瓶頸。
（3）、數據可視化問題。HDFS是一個優秀的分佈式文件系統，但是對於數據分析以及數據的即席查詢，HDFS並不是最優的選擇
爲了保證高併發環境下海量數據的查詢分析性能，以及如何實現海量實時數據的查詢分析與可視化，MetaMarket開源了druid實時分析數據存儲。
druid 原理圖：
特性：
1.列式存儲格式 Druid使用面向列的存儲，這意味着它只需要加載特定查詢所需的精確列。這爲僅查看幾列的查詢提供了巨大的速度提升。此外，每列都針對其特定數據類型進行了優化，支持快速掃描和聚合。
2.高可用性與高可拓展性 Druid採用分佈式、SN(share-nothing)架構，管理類節點可配置HA，工作節點功能單一，不相互依賴，這些特性都使得Druid集羣在管理、容錯、災備、擴容等方面變得十分簡單。Druid通常部署在數十到數百臺服務器的集羣中，並且可以提供數百萬條記錄/秒的攝取率，保留數萬億條記錄，以及亞秒級到幾秒鐘的查詢延遲。
3.大規模並行處理 Druid可以在整個集羣中並行處理查詢。
**4.實時或批量攝取 實時流數據分析。**區別於傳統分析型數據庫採用的批量導入數據進行分析的方式，Druid提供了實時流數據分析，採用LSM(Long structure-merge)-Tree結構使Druid擁有極高的實時寫入性能；同時實現了實時數據在亞秒級內的可視化。
5.自愈，自平衡，易於操作 要將羣集擴展或縮小，只需添加或刪除服務器，羣集將在後臺自動重新平衡，無需任何停機時間。如果任何Druid服務器發生故障，系統將自動路由損壞，直到可以更換這些服務器。Druid旨在全天候運行，無需任何原因計劃停機，包括配置更改和軟件更新。
**6.雲原生，容錯的架構，不會丟失數據 一旦Druid攝取了您的數據，**副本就會安全地存儲在深層存儲（通常是雲存儲，HDFS或共享文件系統）中。即使每個Druid服務器都出現故障，您的數據也可以從深層存儲中恢復。對於僅影響少數Druid服務器的更有限的故障，複製可確保在系統恢復時仍可進行查詢。
7.亞秒級的OLAP查詢分析 Druid採用了列式存儲、倒排索引、位圖索引等關鍵技術，能夠在亞秒級別內完成海量數據的過濾、聚合以及多維分析等操作。
8.近似算法 Druid包括用於近似計數 - 不同，近似排序以及近似直方圖和分位數的計算的算法。這些算法提供有限的內存使用，並且通常比精確計算快得多。對於精確度比速度更重要的情況，Druid還提供精確計數 - 不同且精確的排名。
9.豐富的數據分析功能針對不同用戶羣體，Druid提供了友好的可視化界面、類SQL查詢語言以及REST 查詢接口。
**10、Druid則是輕量級的提前聚合(roll-up)，**同時根據倒排索引以及bitmap提高查詢效率的時間序列數據和存儲引擎。
11、**druid 原生狀態是不支持精確去重功能的，**但是可以採用一些外部方案去實行，具體參考：https://www.infoq.cn/article/YdPlYzWCCQ5sPR_iKtVz
druid 索引構建（位圖索引倒排索引）
Druid數據實時寫入節點採用LSM結構保證數據的寫入性能。數據先寫入內存，每隔10min（可配）會將內存中的數據persist到本地硬盤形成文件，然後會有一個線程再每隔1h（可配）將本地硬盤的多個文件合併成一個segment。
ClickHouse Druid/Pinot
具備C++經驗的組織 具備Java經驗的組織
小型集羣 大型集羣
少量表 大量表
單一數據集 多個不相關的數據集（多租戶）
表和數據集永久駐留在集羣中 表和數據集定期出現並從羣集中退出
表格大小（以及它們的查詢強度）在時間上是穩定的 表格隨時間熱度降低
查詢的同質性（其類型，大小，按時間分佈等） 異質性
存在可以用於分區的維度，且經過該維度分區後，幾乎不會觸發跨分區的數據查詢 沒有這樣的維度，查詢經常觸及整個集羣中的數據
不使用雲，集羣部署在特定的物理服務器上 羣集部署在雲中
無需依賴現有的Hadoop或Spark集羣 Hadoop或Spark的集羣已經存在並且可以使用
優缺點：
優點：
1、支持的數據規模大(本地存儲+DeepStorage–HDFS)
2、性能高，列存壓縮，預聚合加上倒排索引以及位圖索引，秒級查詢
3、實時性高，可以通過kafka實時導入數據
缺點：
1、靈活性適中，雖然維度之間隨意組合，但不支持adhoc查詢，不能自由組合查詢，且丟失了明細數據（不採用roll-up情況下可以進行明細查詢）
2、易用性較差，不支持join，不支持更新，sql支持很弱(有些插件類似於pinot的PQL語言)，只能JSON格式查詢；對於去重操作不能精準去重。
3、處理方式複雜，需要流處理引擎將數據join成寬表，維護相對複雜；對內存要求較高。
三、不同應用場景分析：
參考文章：olap引擎分析
https://snappydata-cn.github.io/2018/04/04/SnappyData%E4%B8%8EPresto-Druid-Kylin-ES%E7%9A%84%E5%AF%B9%E6%AF%94-2/