背景
Clickhouse是一個用於聯機分析(OLAP)的列式資料庫管理系統(DBMS)
。能夠使用SQL查詢實時生成分析資料報告。它同樣擁有優秀的資料儲存能力。
Apache Kudu是Cloudera Manager公司16年釋出的新型分散式儲存系統，結合CDH和Impala使用可以同時解決隨機讀寫和sql化資料分析的問題
。分別彌補HDFS靜態儲存和Hbase Nosql的不足。本文將對比一下Kudu與clickhost 區別
Apache Kudu
介紹
Kudu是cloudera開源的執行在hadoop平臺上的列式儲存系統,擁有Hadoop生態系統應用的常見技術特性，執行在一般的商用硬體上，支援水平擴充套件,高可用，目前是Apache Hadoop生態圈的新成員之一
。Kudu的設計與眾不同，它定位於應對快速變化資料的快速分析型資料倉庫，希望靠系統自身能力，支撐起同時需要高吞吐率的順序和隨機讀寫的應用場景，提供一個介於HDFS和HBase的效能特點之間的一個系統，在隨機讀寫和批次掃描之間找到一個平衡點，並保障穩定可預測的響應延遲。
可與MapReduce, Spark和其它hadoop生態系統整合
。
特點
Kudu的主要特點:
提供快速全量資料的分析與實時處理功能
結構化的資料模型，支援標準SQL語法，支援資料的更新操作。
整合Impala，利用Imapla SQL語法可操作Kudu資料。
與mapreduce、spark以及其它hadoop生態系統整合。
利用Cloudera Manager，方便管理和維護。
高可用。Tablet Servers and Masters利用Raft Consensus Algorithm。確保只要有一半的副本可用，則tablet可用（可讀寫）。
對資料順序掃描（scan）和隨機訪問（random access）同時具有高效能，簡化使用者複雜的混合架構。
PS：但是Kudu只有在與CDH、Impala結合使用的時候，它才能發揮最大的優勢，單獨摘出來在Apache叢集中部署使用的時候，優勢會降低很多。
概念
Columnar Data Store：
Kudu是列式儲存系統，列式儲存以強型別的columns來儲存資料。
Read Efficiency：
對於分析型查詢，可能會查詢某一列的部分資料，而忽悠其它列，這意味著，Kudu能儘可能的訪問最少的塊來獲取所需要的資料。使用行儲存，即使需要返回部分columns，也可能會掃描所有的row。
Table：
table就是你在Kudu裡儲存資料的地方，一個Table擁有一個schema。
Tablet：
Tablet是儲存的最小單位，是Kudu的水平分割槽，類似HDFS的block，HBase的region。每個Tablet儲存著一定連續的表的segment，一張表所有的Tablet包含了該表key的所有空間。一個Tablet在Tablet servers裡面是多副本持久化，任何tablet都是讀寫一致的
Tablet Server：
tablet server上存了多個Tablets，每個Tablet有多個副本存放在不同的Table Server上，每個Tablet副本同時只有一個Leader，Leader對使用者提供寫操作，然後同步給其它follower，其它follower只提供讀服務，不提供寫服務
Master：
類似HDFS的NameNode， Master負責管理元資料。這些元資料包括talbet的基本資訊，位置資訊
Catalog Table：
Catalog table儲存著Tables and Tablets的元資料資訊，不能直接的對Catalog table進行讀寫，而只能透過Client API操作
架構
Kudu使用單個Master節點管理叢集和元資料，使用任意數量的Table Server節點來儲存實際資料，可以部署多個Master節點來提高容錯。
Kudu架構中分為Master Server，Tablet Server，Table，Tablet。
架構特點如下：
1。 Kudu 使用Raft 共識演算法來保證保證Tablets、元資料的容錯和一致性，從一個 tablet 的多個副本中選出一個leader，它負責接受和複製寫入到follower副本。一旦寫入成功副本數大於（N - 1）/2 （N副本（通常為 3 或 5 個）），它就會向客戶端確認。
2。 Kudu 複製操作採用邏輯複製而非物理複製，Kudu並是不是在硬碟資料上做複製的，而是採取了邏輯複製的辦法，這有以下一些好處：
儘管insert和update需要透過網路對資料做transmit，但是delete操作不需要移動任何資料。Delete操作的請求會發送到每一個tablet server上，在本地做刪除操作。
普通的物理操作，比如資料壓縮，並不需要透過網路做資料transmit，但不同於HDFS，每個請求都需要透過網路把請求傳送到各個備份節點上來滿足操作需要。
每個備份不需要同時進行操作，降低寫入壓力，避免高延時。
3。 在記憶體中每個tablet分割槽維護一個MemRowSet來管理最新更新的資料，當大於一定大小之後會flush到磁碟上形成DiskRowSet，多個DiskRowSet會在適當的時候做歸併操作。 這些被flush到磁碟的DiskRowSet資料分為兩種，一種是Base資料，按列式儲存格式存在，一旦生成不再修改，另一種是Delta檔案，儲存Base中有更新的資料，一個Base檔案可以對應多個Delta檔案，Delta檔案的存在使得檢索過程需要額外的開銷，這些Delta檔案是根據被更新的行在Base檔案中的位移來檢索的，而且做合併時也是有選擇的進行。
4。 因為master上快取了叢集的元資料，所以client讀寫資料的時候，肯定是要透過master才能獲取到tablet的位置等資訊。但是如果每次讀寫都要透過master節點的話，那master就會變成這個叢集的效能瓶頸，所以client會在本地快取一份它需要訪問的tablet的位置資訊，這樣就不用每次讀寫都從master中獲取。 因為tablet的位置可能也會發生變化（比如某個tablet server節點crash掉了），所以當tablet的位置發生變化的時候，client會收到相應的通知，然後再去master上獲取一份新的元資料資訊。
5。 Kudu為使用者提供了兩種一致性模型。預設的一致性模型是snapshot consistency。這種一致性模型保證使用者每次讀取出來的都是一個可用的快照，但這種一致性模型只能保證單個client可以看到最新的資料，但不能保證多個client每次取出的都是最新的資料。另一種一致性模型external consistency可以在多個client之間保證每次取到的都是最新資料，但是Kudu沒有提供預設的實現，需要使用者做一些額外工作。
應用場景
Kudu的應用場景很廣泛，比如可以進行實時的資料分析，用於資料可能會存在變化的時序資料應用等
，甚至還有人探討過使用Kudu替代Kafka的可行性，不過Kudu最有名和最成功的應用案例，還是國內的小米。小米公司不僅使用Kudu，還深度參與了Kudu的開發。Kudu專案在2012年10月由Cloudera公司發起，2015年10月對外公佈，2015年12月進入Apache孵化器，但是小米公司早在2014年9月就加入到Kudu的開發中了。
適用場景如下：
適用於那些既有隨機訪問，也批次資料掃描的複合場景
高計算量的場景
實時更新的應用。剛剛到達的資料就馬上要被終端使用者使用訪問到。
時間序列相關的應用，需要同時支援：根據海量歷史資料查詢；必須非常快地返回關於單個實體的細粒度查詢。
實時預測模型的應用，支援根據所有歷史資料週期地更新模型。
ClickHouse
介紹
ClickHouse是一個面向聯機分析處理(OLAP)的開源的面向列式儲存的DBMS，簡稱CK, 與Hadoop, Spark相比，ClickHouse很輕量級,由俄羅斯第一大搜索引擎Yandex於2016年6月釋出, 開發語言為C++
在2016年開源後，在計算引擎裡算是一個後起之秀，在記憶體資料庫領域號稱是最快的。由於它有幾倍於GreenPlum等引擎的效能優勢，所以不少人都選擇將其安裝雲伺服器中使用。ClickHouse是一個列導向資料庫，是原生的向量化執行引擎。它在大資料領域沒有走Hadoop生態，而是採用Local attached storage作為儲存，這樣整個IO可能就沒有Hadoop那一套的侷限。它的系統在生產環境中可以應用到比較大的規模，因為它的線性擴充套件能力和可靠性保障能夠原生支援shard+replication這種解決方案。它還提供了一些SQL直接介面，有比較豐富的原生client。
效能方面比Vertica快5倍，比Hive快279倍，比MySQL快800倍,其可處理的資料級別已達到10億級別
特點
ClickHouse的主要特點
面向列的DBMS：
一個真正的列式儲存的資料庫管理系統中，除了資料本身之外不應該存在其他額外的資料
資料壓縮：
一些面向列的DBMS（InfiniDB CE和MonetDB）不使用資料壓縮。但是，資料壓縮確實提高了效能
並行處理：
多核多節點並行化大型查詢，佔用當前伺服器上可用的所有必要資源
分散式查詢：
在 ClickHouse 中，資料可以駐留在不同的分片上。每個分片可以是一組用於容錯的副本。所有分片都用於並行執行查詢
SQL支援：
ClickHouse 支援基於 SQL的宣告式查詢語言，支援的查詢包括GROUP BY、ORDER BY、FROM 中的子查詢、JOIN子句、IN運算子、視窗函式和標量子查詢
向量引擎：
資料不僅按列儲存，而且透過向量（列的部分）進行處理，這樣可以實現高 CPU 效率
實時更新：
ClcikHouse 資料是以增量的方式有序的儲存在 MergeTree 中。因此，資料可以持續不斷高效的寫入到表中，並且寫入的過程中不會存在任何加鎖的行為。
支援索引:
ClickHouse支援一二級索引，帶有主鍵可以在特定的時間範圍內為特定客戶端（Metrica計數器）抽取資料，並且延遲時間小於幾十毫秒
近似計算：
ClickHouse 提供各種各樣在允許犧牲精度的情況下對查詢進行加速的方法，例如用於近似計算的各類聚合函式、基於資料的部分樣本進行近似查詢、不使用全部的聚合條件，透過隨機選擇有限個數據聚合條件進行聚合
資料容錯：
使用非同步多主複製。寫入任何可用的副本後，資料將分發到所有剩餘的副本。系統在不同的副本上保持相同的資料。資料在失敗後自動恢復
PS：需要注意的是， 由於clickHouse不支援事務操作, 所以不能作為傳統資料庫來使用(OLTP),以及高請求率的鍵值訪問，Blob或文件儲存，超標準化資料；缺乏以高速率和低延遲修改或刪除已插入資料的能力；稀疏索引使得 ClickHouse 對於透過鍵檢索單行的點查詢效率不高
概念
列式儲存：
開源的列儲存資料庫管理系統，支援線性擴充套件，簡單方便，高可靠性
向量化：
clickhouse實現了向量引擎（vectorized execution engine），對記憶體中的列式資料，一個batch呼叫一次SIMD指令（而非每一行呼叫一次），不僅減少了函式呼叫次數、降低了cache miss，而且可以充分發揮SIMD指令的並行能力，大幅縮短了計算耗時。
表：
clickhouse也一樣，具有資料庫，資料表的概念，和MySQL一樣。
分割槽：
支援PARTITION BY子句，在建表時可以指定按照任意合法表示式進行資料分割槽操作，比如透過toYYYYMM（）將資料按月進行分割槽、toMonday（）將資料按照周幾進行分割槽、對Enum型別的列直接每種取值作為一個分割槽等，類似於hive中的分割槽表
分片：
clickhouse叢集由分片shard組成，每個分片又可以透過副本replication組成
副本：
資料儲存副本，一般是為了資料安全而設計，在大資料儲存框架中比較常見
引擎：
顧名思義，就是資料庫中使用的引擎，不過clickhouse不一樣，可以針對資料庫和資料表選擇引擎。傳統如mysql也是可以針對資料表選擇引擎如InnoDB MyISam等
架構
HDFS、Spark、HBase和Elasticsearch這類分散式系統，都採用了Master-Slave主從架構，由一個管控節點作為Leader統籌全域性。而
ClickHouse則採用Multi-Master多主架構
，叢集中的每個節點角色對等，客戶端訪問任意一個節點都能得到相同的效果。這種多主的架構有許多優勢，例如對等的角色使系統架構變得更加簡單，不用再區分主控節點、資料節點和計算節點，叢集中的所有節點功能相同。
所以它天然規避了單點故障的問題，非常適合用於多資料中心、異地多活的場景。
應用場景
自從ClickHouse2016年6月15日開源後，ClickHouse中文社群隨後成立。中文開源組開始以易觀，海康威視，美團，新浪，京東，58，騰訊，酷狗音樂和俄羅斯開源社群等人員組成，
隨著開源社群的不斷活躍，陸續有神州數碼，青雲，PingCAP，中軟國際等公司成員加入以及其他公司成員加入
。初始在群裡討論技術後續有一些大型公司陸續運用到專案中，介於分享不方便問題解決，建立了相應的論壇。
適用場景如下：
電信行業用於儲存資料和統計資料使用。
新浪微博用於使用者行為資料記錄和分析工作。
用於廣告網路和RTB,電子商務的使用者行為分析。
資訊保安裡面的日誌分析。
檢測和遙感資訊的挖掘。
商業智慧。
網路遊戲以及物聯網的資料處理和價值資料分析。
最大的應用來自於Yandex的統計分析服務Yandex.Metrica，類似於谷歌Analytics(GA)，或友盟統計，小米統計，幫助網站或移動應用進行資料分析和精細化運營工具，據稱Yandex.Metrica為世界上第二大的網站分析平臺。ClickHouse在這個應用中，部署了近四百臺機器，每天支援200億的事件和歷史總記錄超過13萬億條記錄，這些記錄都存有原始資料（非聚合資料），隨時可以使用SQL查詢和分析，生成使用者報告。
總結
clickhouse
kudu
併發qps
100qps/s
100w/s
join支援
join寫法比較特殊；最新版已支援類似SQL的join，但效能不好；無論是Left Join 、Right Join還是Inner Join永遠都是拿著右表中的每一條記錄到左表中查詢該記錄是否存在，所以右表必須是小表
與impala或sparksql整合後支援標準sql
小批次寫入對效能的影響
儘量做1000條以上批次的寫入，避免逐行insert或小批次的insert，update，delete操作，因為ClickHouse底層會不斷的做非同步的資料合併，會影響查詢效能，這個在做實時資料寫入的時候要儘量避開
無影響
cpu
Clickhouse快是因為採用了並行處理機制，即使一個查詢，也會用伺服器一半的CPU去執行，所以ClickHouse不能支援高併發的使用場景，預設單查詢使用CPU核數為伺服器核數的一半，安裝時會自動識別伺服器核數，可以透過配置檔案修改該引數
低
查詢效能
count： 千萬級別，500毫秒，1億 800毫秒 2億 900毫秒 3億 1。1秒
group： 百萬級別 200毫米，千萬 1秒，1億 10秒，2億 20秒，3億 30秒
join：千萬-10萬 600 毫秒， 千萬 -百萬：10秒，千萬-千萬 150秒
高
使用場景
不適合分析場景，聚合排序
既有隨機（hbase擅長）又有批次掃描（hdfs順序讀寫）
優點
1、高效使用cpu
2、順序IO，因此對磁碟沒有要求
3、索引不使用B樹，不受最左原則限制，只要欄位在索引中就可以
4、寫入速度非常快，50-200M/s，對於大量的資料更新非常適用。
1、可以解決流式計算結果的更新；2、
缺點
1、不支援事務
2、不支援高併發，官方建議100qps/s3、耗cpu
1、只有主鍵可以設定range分割槽，且只能有一個主鍵；2、pyspark連線kudu時不支援呼叫kudu本地庫，scala spark支援，支援kudu的各種語法（哪些語法？）3、shell不能查詢到表的schema，可透過impala和spark的dataframe獲取4、時間格式是utc格式的，差8個小時
總結
可作為dws寬表層使用，減少join查詢
tserver不要超過100臺，單個tserver支援100個tablet，單個tablet支援10G資料，單表最多使用100個tablet；因此：1、不適用pb級資料；2、每臺tserver支援1T資料3、單表最大1T資料
