彪悍開源的分析資料庫-ClickHouse

01-25

今天介紹一個來自俄羅斯的兇猛彪悍的分析資料庫：ClickHouse，它是今年6月開源，俄語社區為主，好酒不怕巷子深。

本文內容較長，分為三個部分：走馬觀花，死而後生，遙指杏花村；第一章，走馬觀花，初步了解一下基本特性；第二章，死而後生，介紹ClickHouse的技術架構演化的今生前世；第三章，遙指杏花村，介紹一些參考資料，包括一些俄文資料。

第一章，走馬觀花

俄羅斯的『百度』叫做Yandex，覆蓋了俄語搜索超過68%的市場，有俄語的地方就有Yandex；有中文的地方，就有百度么？好像不一定。

Yandex在2016年6月15日開源了一個數據分析的資料庫，名字叫做ClickHouse，這對保守俄羅斯人來說是個特大事。更讓人驚訝的是，這個列式存儲資料庫的跑分要超過很多流行的商業MPP資料庫軟體，例如Vertica。如果你沒有聽過Vertica，那你一定聽過 Michael Stonebraker，2014年圖靈獎的獲得者，PostgreSQL和Ingres發明者（Sybase和SQL Server都是繼承 Ingres而來的）, Paradigm4和SciDB的創辦者。Michael Stonebraker於2005年創辦Vertica公司，後來該公司被HP收購，HP Vertica成為MPP列式存儲商業資料庫的高性能代表，Facebook就購買了Vertica數據用於用戶行為分析。

簡單的說，ClickHouse作為分析型資料庫，有三大特點：一是跑分快，二是功能多，三是文藝范

1. 跑分快： ClickHouse跑分是Vertica的5倍快：

ClickHouse性能超過了市面上大部分的列式存儲資料庫，相比傳統的數據ClickHouse要快100-1000X，ClickHouse還是有非常大的優勢：

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生態，走自己的路

誰在用ClickHouse?

由於項目今年6月才開源，因此外部商業應用並不多件，但是開發社區的討論還是保持熱度(主要用俄語）
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操作
支持有限操作系統
開源社區剛剛啟動，主要是俄語為主

ClickHouse和一些技術的比較

1.商業OLAP資料庫

例如：HP Vertica, Actian the Vector,

區別：ClickHouse是開源而且免費的

2.雲解決方案

例如：亞馬遜RedShift和谷歌的BigQuery

區別：ClickHouse可以使用自己機器部署，無需為雲付費

3.Hadoop生態軟體

例如：Cloudera Impala, Spark SQL, Facebook Presto , Apache Drill

區別：

-ClickHouse支持實時的高並發系統

-ClckHouse不依賴於Hadoop生態軟體和基礎

-ClickHouse支持分散式機房的部署

4.開源OLAP資料庫

例如：InfiniDB, MonetDB, LucidDB

區別：這些項目的應用的規模較小，並沒有應用在大型的互聯網服務當中，相比之下，ClickHouse的成熟度和穩定性遠遠超過這些軟體。

5.開源分析，非關係型資料庫

例如：Druid , Apache Kylin

區別：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結構，葉子節點保持著數據文件的OffSet; 通過Index文件找到數據範圍，然後進行數據文件讀取；早期的實現是將Index文件裝在內存中，數據文件在磁碟當中，或則SSD等。當時7200RPM的硬碟，每秒進行100-200次隨機讀；SSD硬碟可以支持30000次隨機讀/每秒。

除了考察MyISAM之外，InnoDB也被考察過。MyISAM的索引和數據是分開的，並且索引是有壓縮的，這種方式可以提高內存的使用率。載入更多索引到內存中，而Innodb是索引和數據是緊密捆綁的，沒有使用壓縮的情況下，InnoDb的大小會比MyISAM體積大很多。當然，InnoDB支持的Transaction也是非常誘人的。

階段二: Metrage (從2010-現在)

為了解決MyISAM的一些問題，Yandex決定開發Metrage，核心想法來源於統計分析數據的一些特點，統計分析數據的每行數據量都不大，因此可以將多行數據聚合在一起作為處理單位，加快操作速度和系統的吞吐能力。

它有幾個特點：

數據通過小批量Batch存儲
支持高強度的寫操作（數千行寫入/每秒）
讀數據量非常小
讀數據操作中Primary Key 的數量有限（<1百萬）
每一行的數據量很小

整個結構類似於MyISAM的索引，但是數據塊中也聚合了一些小粒度的數據，索引放在內存中，數據被整理成塊放在磁碟中，並且進行壓縮。

該數據結構的優點：

- 數據被壓縮成塊。由於存儲有序，壓縮足夠強大，其中使用了快速壓縮演算法（在2010年使用QuickLZ ，自2011年使用LZ4 ）。

- 採用稀疏索引：稀疏索引 - 主鍵值排序後放置於若干個組中，可以節省大量索引空間。這個索引始終放在內存中。

Metrage在數據量最大的時候，39*2台伺服器中存儲了大約3萬億行數據，每天機器處理大約為1千億的數據。

這個系統有個缺點，數據查詢只能進行基於固定的查詢模式（否則性能將受到很大影響），因此在設計數據Schema的時候，需要考慮數據查詢的性能問題，缺少足夠的靈活型。因此這個項目使用了5年後，統計分析的數據都開始遷移到其他的平台系統中了（那時候LevelDB，還沒有出現，否則可以使用LevelDB作為Mertage的核心模塊）。

階段三 OLAPServer (2009-2013)

隨著Yandex.Metrike的數據量越來越大，數據查詢的速度越來越慢，查詢相應事件長，系統的CPU和IO資源佔用大，因此公司內部嘗試了不同的解決方案，其中一個原型方案是OLAPServer。設計思路就是根據「星型結構」設計一些維度和事實列，通過預先部分聚合數據加快訪問的速度，這一套技術用於支持各種報告的生成。

基本的場景如下：

支持一個Fact表，包括維度列(Dimension)和指標列（Metrics)，維度有上百個
讀取大量行的數據，但是一次查詢往往只關注某些列
寫多讀少的場景，報表查詢請求量並不大
大部分簡單查詢不超過50毫秒響應時間
列的值數據量非常小，通常為整數或者不超過60位元組的URL
它需要高帶寬，同時處理單個請求（高達十億每秒的行的單個伺服器上）
查詢結果的數據量非常小，通常是數據聚合的結果
無需支持事務，數據更新極少，通知只有添加操作

這些場景下，使用列式資料庫是非常有效的，從兩個方面可以理解

1. 磁碟I/O的優化

- 作為列式存儲，查詢只需要訪問所關心的列數據

- 列數據放在一起，數據格式類似，非常容易壓縮，因此減少I/O數據量

- 輸入輸出的減少，內存可以騰出更多地方作為Cache

2. CPU

由於數量行數特別大，數據的解壓縮和計算將耗費非常多的CPU資源，為了提高CPU的效率，行業中通常是將數據轉換成Vector的計算。例如行業比較流行的VectorWise方法。

下面是VectorWise的高層架構示意圖，其基本想法就是將壓縮的列數據整理成現代CPU容易處理的Vector模式，利用現代CPU的多線程，SIMD(Single Instruction,Multiple Data)，每次處理都是一批Vector數據，極大的提高了處理效率。

市場有非常多的的列式分析型資料庫，例如HP Vertica, ParAccel Actian the Matrix, Google PowerDrill , Amazon的RedShift , MetaMarkets Druid等等，這些產品有很多不同的優化實踐，有些是專於數據壓縮，有些是專於數據聚合，有些是專於擴展性等。

OLAPServer在具體實現過程中，實際上採用的是比較保守的方法，實現的功能也比較有限，但是完全滿足當時分析報表的支持。例如，OLAPServer數據類型只支持1-8位元組的數據類型，查詢只支持固定的模式：

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，我們能夠可以實時看到一些預先聚合的數據，但是對於一些聚合前的詳細數據是無法查詢的，隨著業務的深入發展，精細化運營對於統計服務提出了更高的要求，後期有大量需求是關於直接查詢聚合前的數據。

總體來說，雖然數據聚合帶來一些好處，但是也存在以下一些問題。

對於基數大的列，聚合的意義不大，例如URL等
過多的維度組合會導致組合爆炸
用戶常常只關心聚合後的數據中的非常一一小部分數據，因此大量聚合預計算是得不償失的。
聚合後的數據，數據修改會非常困難，很難保證存儲的邏輯完整性

如果不預先聚合數據，如何保證響應時間是一個大挑戰。這意味著，資料庫需要支持秒級處理數十億的行。

近年來，市面上也出現很多列式存儲的開源DBMS，包括Cloudera Impala, Spark SQL, Presto, Apache Drill，這些系統雖然都能完成查詢的功能，但是速度卻無法滿足數據統計分析的需求，即使聚合後的性能能夠滿足，但也缺少靈活度。

因此，Yandex開發了自己的列式分析資料庫 ClickHouse，初期主要是滿足Yandex.Metrike的統計分析需求，主角要上場了。

ClickHouse實際上來源於內部的幾個項目的整合，項目起源起源於2011年左，

到2013年的時候，ClickHouse的性能就和Vertica大致相同；2015年12月，ClickHouse的數量已經達到11萬億行，數據表有200多列，主集群的伺服器數量也從初期的60台到394台；

整個系統的部署是支持水平擴展的，並且支持多機房部署和備份。雖然它是能夠在大型集群操作，它可以被安裝在同一伺服器上，甚至在虛擬機上。

在最新的性能評測中，ClickHouse比Vertica快約5倍。現在Yandex公司內部有十幾個應用系統在使用ClickHouse，場景包括數據存儲，查詢分析，報表製作等。

ClickHouse的藍圖

關於ClickHouse的下一步發展，公司並沒有給出太多規劃，因為多數信息還是屬於不公開狀態，但是從一些公開的信息，我們可以了解到，ClickHouse會向兩個方向發展。

1 雲計算資料庫：　

Yandex希望通過ClickHouse促進公司雲計算資料庫的發展，包括用戶可以通過雲服務的方式，使用ClickHouse，開源是走向市場的第一步。

2. 加強SQL兼容性。

為了支持更多的企業用戶，目前的查詢雖然採用非常近似的SQL語言，但是還有很多地方需要改進，包括和一些商業軟體（例如Tableau,Pentaho）的集成無縫使用。

第三部分：遙指杏花村

這一部分包括了一些ClickHouse的一些基本信息，幫助大家進入ClickHouse的世界。為了深度了解ClickHouse社區，不僅僅需要翻牆，也需要谷歌或者必應的翻譯器，俄文翻譯的效果不錯。

１主頁：　https://clickhouse.yandex

２.代碼：　GitHub - yandex/ClickHouse: ClickHouse is a free analytic DBMS for big data.

３參考文章：

Yandex.Metrike的架構演化：

Эволюция структур данных в Яндекс.Метрике / Блог компании Яндекс / Хабрахабр（俄文）很棒的文章

MPP資料庫基礎架構：

http://vldb.org/pvldb/vol5/p1790_andrewlamb_vldb2012.pdf

http://www.cs.yale.edu/homes/dna/talks/Column_Store_Tutorial_VLDB09.pdf

４關於Yandex的

Yandex的（納斯達克股票代碼：YNDX）是互聯網公司在俄羅斯主導，經營該國最流行的搜索引擎和訪問量最大的網站。Yandex的還經營在烏克蘭，哈薩克，白俄羅斯和土耳其。Yandex的的使命是回答任何互聯網用戶的任何問題（Answer any question Internet users may have)。

最近在學習一些ClickHouse的源代碼，還沒有理清楚頭緒，下次搞清楚邏輯後再和大家介紹一下，這裡先紙上談兵，點到為止了。

---------------------完------------------------------

作者簡介：

歐陽辰，互聯網廣告技術老兵，小米廣告架構師/主管，負責廣告平台架構和大數據，曾負責微軟移動Contexual Ads廣告平台，參與Bing搜索引擎IndexServe的核心模塊研發，有空也會在個人微信公眾號「互聯居」中，分享一些互聯網技術心得，訂閱「互聯居」公眾號，與作者直接交流。