標籤：

如何看待yandex開源clickhouse這個列式文檔資料庫?

01-01

作者：歐陽辰

鏈接：彪悍開源的分析資料庫-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的不完美：

  1. 不支持Transaction：想快就別想Transaction

  2. 聚合結果必須小於一台機器的內存大小：不是大問題

  3. 缺少完整的Update/Delete操作

  4. 支持有限操作系統

  5. 開源社區剛剛啟動，主要是俄語為主

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，核心想法來源於統計分析數據的一些特點，統計分析數據的每行數據量都不大，因此可以將多行數據聚合在一起作為處理單位，加快操作速度和系統的吞吐能力。

它有幾個特點：

  1. 數據通過小批量Batch存儲

  2. 支持高強度的寫操作（數千行寫入/每秒）

  3. 讀數據量非常小

  4. 讀數據操作中Primary Key 的數量有限（&<1百萬）

  5. 每一行的數據量很小

整個結構類似於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的源代碼，還沒有理清楚頭緒，下次搞清楚邏輯後再和大家介紹一下，這裡先紙上談兵，點到為止了。

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

上面說了好多優點，說下我從我自己應用的角度上看到的缺點。

可這東西實際上可能並不算是一個成熟的distributed系統。不支持transaction就算了，從應用角度來說很多類似資料庫例如druid也不支持。畢竟是開源的，vertica實在太貴了，幾個G的數據都要上萬美元。

第一，這貨replicate支持不是很好，發送給A之後，A會複製到B，中間A如果死了，數據就會丟失。並且這貨的多個replicate之間互相發送數據需要用到zookeeper，比較慢。就是說如果有replicate的話，insert會比較慢。他建議你每秒少於一個數據insert，或者batch insert。總之insert比較慢，insert成功後也可能會丟，建議做log，一旦有機器死了，就要檢查一下是否那段時間有數據丟了。。 這點druid+tranquility就做的比較好，冗餘性可以得到保證。

第二，一旦有機器死了，自動回復的場景有限，很多時候需要手工恢復，特別是有replicate的情況下。就是說，他的設計理念從一開始就是一個資料庫，而不是一個目前各種開源所支持的自動恢復，即一個機器死了，自動將該機器的所有東西分散到其他活著的機器上去。人工參與度比較高。

最後，他比其他資料庫快，看了下，是指select比較快。

這個回答下貌似玩過人很少，我拋磚引玉吧。

那些說事務的估計沒搞過大數據分析，解決的不是一個問題。

適合場景

ClickHouse的優勢是對結構化的數據，快速給出聚合/過濾結果。對比Spark+Hive，不是快，是巨快。

在餓了么我對銷售側商戶側業務做星形模型時，每天跑歷史60天的數據，先合成訂單寬表，在各個維度聚合數據。比較多的維度寫聚合腳本簡直是要死人，而且跑的很慢，要拆很多任務才能保證每天8～9點能把數據推到ES去。這個場景下，用ClickHouse基本上打到shop維度上，基本實時聚合即可。

性能測試

寫：

在Alpha環境拉了個機器，根據自己表結構造了2億rows的數據到文件裡面。從文件寫進ClickHouse峰值能達到50w QPS，平均30w QPS。

讀：

店鋪維度各種標籤篩選排序基本2s以下。

部署與使用

部署簡單，有Docker提供，改下時區就好。

語法也和SQL差不多，函數200多個。

分散式部署：

操作：ENGINE=Distributed($cluster_name, $database_name, $table_name, $func)

實質原理：通過節點轉發與聚合返回給用戶，proxy的方式實現的。

原理

寫：

  • MergeTree存儲結構類似LSM Tree
  • 沒memTable
  • 沒log
  • 按主鍵排序寫磁碟
  • 非同步merge
  • 不支持update/delete

讀：

稀疏索引，顆粒度8192，適合範圍查詢

關於分散式數據同步

部署部分講了點分散式，ClickHouse的ReplicatedMergeTree數據同步機制非常有借鑒意義。通過zookeeper實現了多源、多主、多向複製，餓了么的多活DRC（機房數據同步）工具也是相同做法。

關於分散式部署性能

因為是proxy方式搞的，讀寫基本隨分片數線性增長。

請問相同伺服器配置下 clickhouse druid kudu 性能表現和自己各自的優缺點是什麼？

無利益相關，聽過他們現場的技術報告而已。

----------------------------------------------分割線----------------------------------------------------------

只是覺得他們claim的速度並沒啥卵用。依然記得連他們的IT Manager都不能解釋清楚：

（1）為啥不用TPC-H跑分而選一個傳統DB Researcher都沒聽過的dataset和相關Query？

（2）為啥對比的不是各大開源工具最新的版本，而把老版本來比？

（3） 為啥不公開跑分平台的硬體配置，其他開源工具的編譯選項？

沒摸過 Vertica 的人根本沒資格討論這類 MPP 的列示數據倉庫。clickHouse 在 benchmark 上比 Vertica 做得好的確非常的 impressive，但是作為一個 Data Warehouse 的 Appliance，Vertica 和 clickHouse 並不是一個檔次的。

How Vertica Met Facebook』s 35TB/hour Ingest SLA

BTW:說 clickHouse 不支持 transaction 的恐怕根本沒見過 billion 條目起步的 OLAP 系統。

Distributed-table is actually a kind of "view" to local tables of ClickHouse cluster.

還不支持transaction。。。。

要命

你要知道用可寫view就馬上能搭建起來類似的，還支持transaction。。。。。

列式存儲也不是新鮮東西，甚至連sql2016都支持了

推薦閱讀：

※分析數據應用圖表進行可視化時，如何判斷使用哪些圖表能最有效地展現數據？
※數據分析，除了Excel數據透視表，還有什麼工具？
※在銀行的信息科技部門做數據治理是什麼體驗？
※大數據魔鏡的前途怎麼樣？
※完全沒有計算機基礎想要學sas,spss等數據建模分析軟體怎麼做？

TAG:資料庫 | 數據分析 | 開源 | 分散式 | 實時 |