从基础到实践ClickHouse之1 - 初识ClickHouse

谈起ClickHouse，应该很多人都会很陌生。一来它是一个新生事物，听过的使用过的人非常少；二来可能没有hadoop生态那么完善和健壮，所以稳定性和功能还有所欠缺。但这些都不影响其迅速获得的良好的口碑和开挂的性能，作为特定领域的数据库，极其看好ClickHouse。

1. 什么是ClickHouse？

这里引用官网的一段话：

ClickHouse is a column-oriented database management system (DBMS) for online analytical processing of queries (OLAP).

上面这段话我划重点如下：

• ClickHouse是一个数据库管理系统
• 它是列式的
• 它为联机处理分析而生

什么是DBMS呢？就是说它是一个成体系的东西，对于数据的读写、存储、查询、修改、复制、事务、效率等等方方面面都有自己的架构方法论，换句话来说，它是庞大的，完善的。说到DBMS，联想到MYSQL就对了。但是，但是，相对于hadoop的笨重，ClickHouse可以说是一个小清新了。

什么是column-oriented呢？column-oriented是相对于row-oriented来讲的。典型的行式数据库，比如mysql。相对于行式数据库，列式数据库是一列数据存储为一个小单元，需要用多少列就读取多少列的数据，那么减少了IO的数据量，自然提升了效率。

什么是OLAP呢？联机分析处理是相对于联机事务处理而言的。联机事务处理面向的是数据修订、状态改变，比如业务数据的查询、订正、变更、写入等等。联机分析处理面向的是数据分析/挖掘，需要提供多维度、灵活的、高效的检索和查阅服务，一个比较典型的应用是BI平台。

ClickHouse是俄罗斯的百度——yandex公司开发的。yandex公司在处理自己公司日常数据业务中，开发了一套数据管理系统，随后进行了开源分享。因为脱胎于实践，来源于业务+技术沉淀，因此在使用过程中会有非常多暖心的、别的数据库不具备的特点（后面会一步步介绍）。另外，搞数据效率是永恒的命题，数学和计算机这两个东西缺一不可，恰恰俄罗斯就是盛产数学家的地方，而且之前看过一个由github统计的数据显示，俄罗斯的程序员在算法方面的活跃度排名世界第一，我们有理由相信ClickHouse前途光明。

2. ClickHouse有哪些优点/特点？

• 变态快
  • 列式存储+数据压缩带来的效率
  • 单服务器每秒能处理亿级到十亿行级别数据
  • 进行简单查询时峰值处理性能可达到单服务器每秒2TB
• 线性可扩展
  • 不需要对数据库进行更改直接扩容服务器（懒人福利）
  • 横向和纵向均有良好的可扩展性
    • 横向上讲，既可以部署在小小的虚拟机上，也可以部署在有成百上千个节点（机器）的集群上
    • 纵向上讲，单个节点可容纳万亿行数据或超过100TB数据
• 高效的硬件利用（从硬件层面进行了优化）
  • 在数据吞吐量相同的情况下，ClickHouse在处理一般性分析类查询时比传统行式数据库快2-3个数量级；列式存储方式使其可以装载更多热数据（什么是热数据？）在内存中，因而响应时间更短
  • ClickHouse最小化了范围查询（语句）所要查找的次数（可以理解为一种查询优化），这提升了旋转式磁盘驱动的使用效率，维护了持久化存储的数据的位置引用（翻译成人话就是说，范围数据是存储在磁盘的不同位置的，你要执行范围查找查询那你肯定要旋转磁盘指针去到不同的磁盘位置索引数据，如果我优化了查找方式，那么你的旋转式磁盘驱动是不是就可以使用得更少了，对于存储有很多本地数据的磁盘来讲，数据引用效率是不是就更高了）
  • ClickHouse是在CPU层面高效的，因为它的向量化查询执行方式夹杂了与之相关的处理器指令和运行时代码产生（翻译成人话就是ClickHouse在CPU层面进行了优化，特别是intel的CPU，因此二者配合得是相当的默契）
  • 针对大多数的查询语句或SQL语法模式，ClickHouse对数据传输量进行了最小化优化（不必要的数据传输统统省了）。这使得使用方在管理数据和制作数据报告的时候，不必刻意配置旨在高效数据计算的专属网络
• 容错性
  • ClickHouse支持多主线异步复制并且能部署在多个数据中心上
  • 单节点或者整个数据中心宕机不会影响系统读写的可靠性
  • 分布式读取模式，自动（将吞吐压力）均衡于各可用的备份节点上从而避免高时延
  • 宕机恢复后备份间数据自动同步或半自动同步
• 丰富的特征
  • 对用户友好的SQL查询句法，丰富的内置分析统计函数/组件，比如基数、百分位数计算；日期、时间、时区数据函数；URL和IP地址处理函数
  • 数据组织和存储格式丰富，比如存储复杂数据的arrays, array joins, tuples and nested data structures，这些数据结构都做了读写和计算优化，因此用来处理和查询非结构化数据（也可以叫半结构化）也是非常高效率的
  • 支持本地join和分布式join，支持额外定义的字典、从外部导入的维度表，通过简单的语法句子就能无缝join数据
  • 支持近似查询处理，提高获得结果的速度，特别是在处理TB/PB级别数据的时候（比如抽样部分数据计算一个结果然后推广到总体）
  • 支持按条件汇总函数，可以用非常简单的句法查询极值和汇总数据查询
• 高可靠性（高可用）
  • 软件或硬件配置失误不会导致数据丢失
  • 所有数据在读写时均会做校验和（checksummed）检验
  • 对于查询语句的复杂度和资源使用限制控制比较灵活
• 使用简单易上手
  • 流水线式的数据处理流程，数据一旦进入系统，那么立即处于可以使用的状态，边读（查询）边写没有任 何压力
  • 任何时候随时可以给表添加字段、属性、维度，不会拖慢或影响集群运行速度
  • 开箱即用（works out-of-the-box）, 没有任何开发背景的人都可以安装和部署ClickHouse集群

3. ClickHouse有什么缺点呢？

喷子喷的比较多的一般无非两点。

一是ClickHouse没法进行事务操作。首先，ClickHouse是可以进行事务操作的，只不过没有像mysql那种批量删除更改的那种操作。其次喷子应该搞清楚什么是OLAP再喷，一个面向查询和应用的数据你还想着批量更改删除可见你的业务能力有多糟糕。（回去先了解下ETL再来喷？）永远记住，用途不同！！！！喷也要专业！！！！

二是ClickHouse为啥不使用MapReduce那一套。MapReduce以可靠性著称，但是过分强调容错和中间数据的读写，导致其时延非常非常高，不适合作为web前端的后端。你愿意查个数据等半天吗？ClickHouse的精髓是最大限度榨干CPU和内存，在内存里面计算，所想即所得，快得冒泡。

我可以说ClickHouse没有缺点吗？

4. 哪些场景比较适合使用ClickHouse呢？

ClickHouse比较适合分析结构化的、干净的、不可变的流式数据，比如打点日志分析啦，行为分析啦。强烈建议将源源不断的流式数据和提前已经定义好的维度表组合起来，并塞到一个基于事实的大宽表中去（ a single wide fact table，一张宽大的事实表，是不是很有亲切感？）。

• ClickHouse比较适用于以下行业/场景：
  • 网页端和客户端产品的数据分析
  • 广告系统和实时竞价广告
  • 电信行业
  • 电商和金融行业
  • 信息安全
  • 实时监控和遥感测量
  • 时间序列
  • 商业智能
  • 在线游戏
  • 所有的互联网场景
• ClickHouse不适合的场景：
  • 联机事物处理（上面提到过的，小黑板敲起来，mysql这种比较适合）
  • 键值对数据高效率访问请求（想到redis了嘛？）
  • 二进制数据或文件存储（想到mongDB了嘛？）
  • 过度标准化的数据（有很多人好奇了，开什么玩笑，数据按说应该是越标准化越好啊？这个问题应该这样理解，那些过于简单直接、没啥维度和灵活度需求的数据，咋能体现ClickHouse的优势呢，你用啥数据库都能做得很6啊）