彪悍開源的分析數據庫-ClickHouse
今天介紹一個來自俄羅斯的兇猛彪悍的分析數據庫：ClickHouse，它是今年6月開源，俄語社區(qū)為主，好酒不怕巷子深。
本文內容較長，分為三個部分：走馬觀花，死而后生，遙指杏花村;第一章，走馬觀花，初步了解一下基本特性;第二章，死而后生，介紹ClickHouse的技術架構演化的今生前世;第三章，遙指杏花村，介紹一些參考資料，包括一些俄文資料。
第一章，走馬觀花
俄羅斯的‘百度’叫做Yandex，覆蓋了俄語搜索超過68%的市場，有俄語的地方就有Yandex;有中文的地方，就有百度么?好像不一定 :) 。
Yandex在2016年6月15日開源了一個數據分析的數據庫，名字叫做ClickHouse，這對保守俄羅斯人來說是個特大事。更讓人驚訝的是，這個列式存儲數據庫的跑分要超過很多流行的商業(yè)MPP數據庫軟件，例如Vertica。如果你沒有聽過Vertica，那你一定聽過 Michael Stonebraker，2014年圖靈獎的獲得者，PostgreSQL和Ingres發(fā)明者(Sybase和SQL Server都是繼承 Ingres而來的), Paradigm4和SciDB的創(chuàng)辦者。Michael Stonebraker于2005年創(chuàng)辦Vertica公司，后來該公司被HP收購，HP Vertica成為MPP列式存儲商業(yè)數據庫的高性能代表，Facebook就購買了Vertica數據用于用戶行為分析。
簡單的說，ClickHouse作為分析型數據庫，有三大特點：一是跑分快， 二是功能多 ，三是文藝范
1. 跑分快： ClickHouse跑分是Vertica的5倍快：
ClickHouse性能超過了市面上大部分的列式存儲數據庫，相比傳統的數據ClickHouse要快100-1000X，ClickHouse還是有非常大的優(yōu)勢：
- 100Million 數據集:
ClickHouse比Vertica約快5倍，比Hive快279倍，比My SQL快801倍
- 1Billion 數據集:
ClickHouse比Vertica約快5倍，MySQL和Hive已經無法完成任務了
2. 功能多：ClickHouse支持數據統計分析各種場景
- 支持類SQL查詢，
- 支持繁多庫函數(例如IP轉化，URL分析等，預估計算/HyperLoglog等)
- 支持數組(Array)和嵌套數據結構(Nested Data Structure)
- 支持數據庫異地復制部署
3.文藝范：目前ClickHouse的限制很多，生來就是為小資服務的
- 目前只支持Ubuntu系統
- 不提供設計和架構文檔，設計很神秘的樣子，只有開源的C++源碼
- 不理睬Hadoop生態(tài)，走自己的路
誰在用ClickHouse?
- 由于項目今年6月才開源，因此外部商業(yè)應用并不多件，但是開發(fā)社區(qū)的討論還是保持熱度(主要用俄語)
- Yandex有十幾個項目在用使用ClickHouse，它們包括：Yandex數據分析，電子郵件，廣告數據分析，用戶行為分析等等
- 2012年，歐洲核子研究中心使用ClickHouse保存粒子對撞機產生的大量實驗數據，每年的數據存儲量都是PB級別，并支持統計分析查詢
ClickHouse最大應用：
最大的應用來自于Yandex的統計分析服務Yandex.Metrica，類似于谷歌Analytics(GA)，或友盟統計，小米統計，幫助網站或移動應用進行數據分析和精細化運營工具，據稱Yandex.Metrica為世界上第二大的網站分析平臺。ClickHouse在這個應用中，部署了近四百臺機器，每天支持200億的事件和歷史總記錄超過13萬億條記錄，這些記錄都存有原始數據(非聚合數據)，隨時可以使用SQL查詢和分析，生成用戶報告。
ClickHouse就是快：比Veritca快約5倍
下面是100M數據集的跑分結果：ClickHouse 比Vertia快約5倍，比Hive快279倍，比My SQL 快801倍;雖然對不同的SQL查詢，結果不完全一樣，但是基本趨勢是一致的。ClickHouse跑分有多塊? 舉個例子：ClickHouse 1秒，Vertica 5.42秒，Hive 279秒;
ClickHouse是什么，適合什么場景?
到底什么是ClickHouse數據庫，場景應用是什么，參考下面說明：
ClickHouse的不完美：
- 不支持Transaction：想快就別想Transaction
- 聚合結果必須小于一臺機器的內存大?。翰皇谴髥栴}
- 缺少完整的Update/Delete操作
- 支持有限操作系統
- 開源社區(qū)剛剛啟動，主要是俄語為主
ClickHouse和一些技術的比較
1.商業(yè)OLAP數據庫
例如：HP Vertica, Actian the Vector,
區(qū)別：ClickHouse是開源而且免費的
2.云解決方案
例如：亞馬遜RedShift和谷歌的BigQuery
區(qū)別：ClickHouse可以使用自己機器部署，無需為云付費
3.Hadoop生態(tài)軟件
例如：Cloudera Impala, Spark SQL, Facebook Presto , Apache Drill
區(qū)別：
-ClickHouse支持實時的高并發(fā)系統
-ClckHouse不依賴于Hadoop生態(tài)軟件和基礎
-ClickHouse支持分布式機房的部署
4.開源OLAP數據庫
例如：InfiniDB, MonetDB, LucidDB
區(qū)別：這些項目的應用的規(guī)模較小，并沒有應用在大型的互聯網服務當中，相比之下，ClickHouse的成熟度和穩(wěn)定性遠遠超過這些軟件。
5.開源分析，非關系型數據庫
例如：Druid , Apache Kylin
區(qū)別：ClickHouse可以支持從原始數據的直接查詢，ClickHouse支持類SQL語言，提供了傳統關系型數據的便利。
第二章，死而后生
ClickHouse設計之初就是為Yandex.Metrika而生，先一起看看Yandex.Metrika數據分析系統的演化過程吧，ClickHouse是第四代的解決方案，經過三次死亡后的產物，涅槃重生的巨獸!
第一階段：MyISAM (LSM-Tree) (2008-2011)
Yandex.Metrika產品成立于2008年，最開始使用了MyISAM作為存儲引擎。熟悉MySQL的同學都知道，這是MySQL的重要存儲引擎之一(另外一個是InnoDB)。MyISAM中的實現也是使用LSM-Tree的設計，基本思路就是將對數據的更改hold在內存中，達到指定的threadhold后將該批更改批量寫入到磁盤，在批量寫入的過程中跟已經存在的數據做rolling merge。
使用MyISAM的方法，剛開始數據量不大，訪問請求也不大的時候，這個方法非常有效，特別是對于一些固定的報告生成，效率非常高，系統能夠保持很好的系統寫能力。
數據格式也是傳統的索引結構：一個數據文件+一個索引結構; 索引結構是一個B-Tree結構，葉子節(jié)點保持著數據文件的OffSet; 通過Index文件找到數據范圍，然后進行數據文件讀取;早期的實現是將Index文件裝在內存中，數據文件在磁盤當中，或則SSD等。當時7200RPM的硬盤，每秒進行100-200次隨機讀;SSD硬盤可以支持30000次隨機讀/每秒。
除了考察MyISAM之外，InnoDB也被考察過。MyISAM的索引和數據是分開的，并且索引是有壓縮的，這種方式可以提高內存的使用率。加載更多索引到內存中，而Innodb是索引和數據是緊密捆綁的，沒有使用壓縮的情況下，InnoDb的大小會比MyISAM體積大很多。當然，InnoDB支持的Transaction也是非常誘人的。
階段二: Metrage (從2010-現在)
為了解決MyISAM的一些問題，Yandex決定開發(fā)Metrage，核心想法來源于統計分析數據的一些特點，統計分析數據的每行數據量都不大，因此可以將多行數據聚合在一起作為處理單位，加快操作速度和系統的吞吐能力。
它有幾個特點：
- 數據通過小批量Batch存儲
- 支持高強度的寫操作(數千行寫入/每秒)
- 讀數據量非常小
- 讀數據操作中Primary Key 的數量有限(<1百萬)
- 每一行的數據量很小
整個結構類似于MyISAM的索引，但是數據塊中也聚合了一些小粒度的數據，索引放在內存中，數據被整理成塊放在磁盤中，并且進行壓縮。
該數據結構的優(yōu)點：
- 數據被壓縮成塊。 由于存儲有序，壓縮足夠強大，其中使用了快速壓縮算法(在2010年使用QuickLZ ，自2011年使用LZ4 )。
- 采用稀疏索引： 稀疏索引 - 主鍵值排序后放置于若干個組中，可以節(jié)省大量索引空間。 這個索引始終放在內存中。
Metrage在數據量最大的時候，39*2臺服務器中存儲了大約3萬億行數據，每天機器處理大約為1千億的數據。
這個系統有個缺點，數據查詢只能進行基于固定的查詢模式(否則性能將受到很大影響)，因此在設計數據Schema的時候，需要考慮數據查詢的性能問題，缺少足夠的靈活型。因此這個項目使用了5年后，統計分析的數據都開始遷移到其他的平臺系統中了(那時候LevelDB，還沒有出現，否則可以使用LevelDB作為Mertage的核心模塊)。
階段三 OLAPServer (2009-2013)
隨著Yandex.Metrike的數據量越來越大，數據查詢的速度越來越慢，查詢相應事件長，系統的CPU和IO資源占用大，因此公司內部嘗試了不同的解決方案，其中一個原型方案是OLAPServer。 設計思路就是根據“星型結構”設計一些維度和事實列，通過預先部分聚合數據加快訪問的速度，這一套技術用于支持各種報告的生成。
基本的場景如下：
- 支持一個Fact表，包括維度列(Dimension)和指標列(Metrics)，維度有上百個
- 讀取大量行的數據，但是一次查詢往往只關注某些列
- 寫多讀少的場景，報表查詢請求量并不大
- 大部分簡單查詢不超過50毫秒響應時間
- 列的值數據量非常小，通常為整數或者不超過60字節(jié)的URL
- 它需要高帶寬，同時處理單個請求(高達十億每秒的行的單個服務器上)
- 查詢結果的數據量非常小，通常是數據聚合的結果
- 無需支持事務，數據更新極少，通知只有添加操作
這些場景下，使用列式數據庫是非常有效的，從兩個方面可以理解
1. 磁盤I/O的優(yōu)化
- 作為列式存儲，查詢只需要訪問所關心的列數據
- 列數據放在一起，數據格式類似，非常容易壓縮，因此減少I/O數據量
- 輸入輸出的減少，內存可以騰出更多地方作為Cache
2. CPU
由于數量行數特別大，數據的解壓縮和計算將耗費非常多的CPU資源，為了提高CPU的效率，行業(yè)中通常是將數據轉換成Vector的計算。例如行業(yè)比較流行的VectorWise方法。
下面是VectorWise的高層架構示意圖，其基本想法就是將壓縮的列數據整理成現代CPU容易處理的Vector模式，利用現代CPU的多線程，SIMD(Single Instruction,Multiple Data)，每次處理都是一批Vector數據，極大的提高了處理效率。
市場有非常多的的列式分析型數據庫，例如HP Vertica, ParAccel Actian the Matrix, Google PowerDrill , Amazon的RedShift , MetaMarkets Druid等等，這些產品有很多不同的優(yōu)化實踐，有些是專于數據壓縮，有些是專于數據聚合，有些是專于擴展性等。
OLAPServer在具體實現過程中，實際上采用的是比較保守的方法，實現的功能也比較有限，但是完全滿足當時分析報表的支持。例如，OLAPServer數據類型只支持1-8字節(jié)的數據類型，查詢只支持固定的模式：
Select keys ,aggregate(columns) from table where condition1 and condition2 .... Group by keys order by columns 。
盡管功能有限，OLAPServer還是滿足了當時的分析報表功能，并且性能非常出色。由于設計之處的限制比較多，因此后期的改進過程中成本非常高，例如為了增加更長URL的數據類型，系統改動非常大。在2013年，OLAPServer存儲了7280億行數據，目前這些數據都遷移到ClickHouse了。
第四階段 ClickHouse(2011-現在)
使用OLAPServer，我們能夠可以實時看到一些預先聚合的數據，但是對于一些聚合前的詳細數據是無法查詢的，隨著業(yè)務的深入發(fā)展，精細化運營對于統計服務提出了更高的要求，后期有大量需求是關于直接查詢聚合前的數據。
總體來說，雖然數據聚合帶來一些好處，但是也存在以下一些問題。
- 對于基數大的列，聚合的意義不大，例如URL等
- 過多的維度組合會導致組合爆炸
- 用戶常常只關心聚合后的數據中的非常一一小部分數據，因此大量聚合預計算是得不償失的。
- 聚合后的數據，數據修改會非常困難，很難保證存儲的邏輯完整性
如果不預先聚合數據，如何保證響應時間是一個大挑戰(zhàn)。這意味著，數據庫需要支持秒級處理數十億的行。
近年來，市面上也出現很多列式存儲的開源DBMS，包括Cloudera Impala, Spark SQL, Presto, Apache Drill，這些系統雖然都能完成查詢的功能，但是速度卻無法滿足數據統計分析的需求，即使聚合后的性能能夠滿足，但也缺少靈活度。
因此，Yandex開發(fā)了自己的列式分析數據庫 ClickHouse，初期主要是滿足Yandex.Metrike的統計分析需求，主角要上場了。
ClickHouse實際上來源于內部的幾個項目的整合，項目起源起源于2011年左，
到2013年的時候，ClickHouse的性能就和Vertica大致相同;2015年12月，ClickHouse的數量已經達到11萬億行，數據表有200多列，主集群的服務器數量也從初期的60臺到394臺;
整個系統的部署是支持水平擴展的，并且支持多機房部署和備份。雖然它是能夠在大型集群操作，它可以被安裝在同一服務器上，甚至在虛擬機上。
在最新的性能評測中，ClickHouse比Vertica快約5倍?，F在Yandex公司內部有十幾個應用系統在使用ClickHouse，場景包括數據存儲，查詢分析，報表制作等。
ClickHouse的藍圖
關于ClickHouse的下一步發(fā)展，公司并沒有給出太多規(guī)劃，因為多數信息還是屬于不公開狀態(tài)，但是從一些公開的信息，我們可以了解到，ClickHouse會向兩個方向發(fā)展。
1 云計算數據庫：
Yandex希望通過ClickHouse促進公司云計算數據庫的發(fā)展，包括用戶可以通過云服務的方式，使用ClickHouse，開源是走向市場的第一步。
2. 加強SQL兼容性。
為了支持更多的企業(yè)用戶，目前的查詢雖然采用非常近似的SQL語言，但是還有很多地方需要改進，包括和一些商業(yè)軟件(例如Tableau,Pentaho)的集成無縫使用。
第三部分：遙指杏花村
這一部分包括了一些ClickHouse的一些基本信息，幫助大家進入ClickHouse的世界。為了深度了解ClickHouse社區(qū)，不僅僅需要翻墻，也需要谷歌或者必應的翻譯器，俄文翻譯的效果不錯。
1主頁： https://clickhouse.yandex
2.代碼： https://github.com/yandex/ClickHouse
3參考文章：
Yandex.Metrike的架構演化：
https://habrahabr.ru/company/yandex/blog/273305/(俄文)很棒的文章
MPP數據庫基礎架構：
http://vldb.org/pvldb/vol5/p1790_andrewlamb_vldb2012.pdf
http://www.cs.yale.edu/homes/dna/talks/Column_Store_Tutorial_VLDB09.pdf
4關于Yandex的
Yandex的(納斯達克股票代碼：YNDX)是互聯網公司在俄羅斯主導，經營該國最流行的搜索引擎和訪問量最大的網站。Yandex的還經營在烏克蘭，哈薩克斯坦，白俄羅斯和土耳其。Yandex的的使命是回答任何互聯網用戶的任何問題(Answer any question Internet users may have)。
最近在學習一些ClickHouse的源代碼，還沒有理清楚頭緒，下次搞清楚邏輯后再和大家介紹一下，這里先紙上談兵，點到為止了。
【本文為51CTO專欄作者“歐陽辰”的原創(chuàng)稿件，轉載請聯系作者本人獲取授權】
