ClickHouse学习笔记一ClickHouse简介

关于ClickHouse

1. 设计目的及名称含义：

   ClickHouse背后的研发团队是来自俄罗斯的Yandex公司。是现今世界上最大的俄语搜索引擎。Google是它的直接竞争对手。产品从诞生发展至现在，共经历过4个大的阶段，它的初始设计目标是服务自己公司的一款名叫Yandex.Metrica的产品。在线搜索引擎的营收来源非常依赖流量和在线广告业务。所以，通常搜索引擎公司为了更好地帮助自身及用户分析网络流量，都会推出自家的在线流量分析产品，例如Google的GoogleAnalytics、百度的百度统计。Yandex也不例外，Yandex.Metrica就是这样一款用于在线流量分析的产品，基于前方探针采集行为数据，然后进行一系列的数据分析，类似数据仓库的OLAP分析。而在采集数据的过程中，一次页面click（点击），会产生一个event（事件）。至此，整个系统的逻辑就十分清晰了，那就是基于页面的点击事件流，面向数据仓库进行OLAP分析。所以ClickHouse的全称是ClickStream，DataWareHouse，简称ClickHouse。

2. 适用场景：

   ClickHouse具备了人们对一款高性能OLAP数据库的美好向往，所以它基本能够胜任各种数据分析类的场景，并且随着数据体量的增大，它的优势也会变得越为明显。ClickHouse非常适用于商业智能领域（也就是我们所说的BI领域），除此之外，它也能够被广泛应用于广告流量、Web、App流量、电信、金融、电子商务、信息安全、网络游戏、物联网等众多其他领域。换句话说，90%目前现有的大数据场景都可以替换成ClickHouse生态，且速度更快。

3. 不适用场景：

   • 所有依赖事务的查询场景，事务的概念通常在传统关系型数据库中体现，而目前主流的大数据库本身存在的意义也并不是为了取代传统关系型数据库。
   • 不擅长根据主键按行粒度进行查询（虽然支持），因此不应该把ClickHouse当作KeyValue数据库使用，即使它足够快，甚至还有内存类型的数据引擎，它也不能取代redis和MemcacheDB。
   • 不擅长按行删除数据（虽然支持）。没有大数据系统擅长做这个事，大数据的目的就不是删除数据。

ClickHouse设计

1. 核心特性：

   是如果刚从Hadoop生态转向ClickHouse的时候，会有不适应，因为它和我们往常使用的技术“性格”迥然不同。如果把数据库比作汽车，那么ClickHouse就是一辆手动挡的赛车。它在很多方面不像其他系统那样高度自动化。ClickHouse的一些概念也与我们通常的理解有所不同，特别是在分片和副本方面，有些时候数据的分片甚至需要手动完成。它有哪些特性，简单罗列一下：

   • 完备的DBMS功能，包含DDl，DML，权限控制，数据备份恢复，分布式管理等等。
   • 列式存储和数据压缩
   • 向量化执行引擎
   • 关系模型与sql查询
   • 多样化的表引擎
   • 多线程与分布式
   • 多主构架
   • 在线查询
   • 数据分片与分布式查询

2. 构架设计：

   这个地方先不延伸，我也没有很好的理解，先暂时列出以下几个方面吧，随着学习的深入，慢慢补充填入——

   • Column与Field
   • DataType
   • Block和Block流
   • Table
   • Parser与Interpreter
   • Functions与AggregateFunctions
   • Cluster与Replication

3. 为何快？

   这个地方，我分析了几点，除了是列式存储数据库，用了向量化引擎之外，但其实目前很多大数据数据库都在用这些，但还是没有ClickHouse快，那只有一点能解释，设计原则。

   这里问各位一个问题，做一个软件构架，或者说产品构架的时候，设计的原则应该是自上而下还是自下而上呢？

   其实在传统产品布局中，产品是根据客户需求走的，自然是自顶向下的设计，有了顶层设计，搭起框架，再向下扩展，选择合适技术，适用语言，敏捷组件，最优底层等，但我发现ClickHouse不是这样的，上面说到了ClickHouse设计之初是为了支撑公司产品服务的是没错，但当时这并非是一个硬性的紧要需求，Yandex只是嫌弃之前的Metrica不够快，但不是不能用，因此ClickHouse从诞生之初，就是一个想布局以后从根源上解决问题的产品，因此ClickHouse的设计，也是从下而上的着手设计，这是个什么意思的，我形象点的解释，首先开发者先了解现在的硬件发展到了什么水平，像常见的cpu主频，内存粒度，硬盘转速等等，那么在目前这个水平的硬件条件上，我们要实现一个什么性能，延迟多少，吞吐多少才匹配目前的硬件，估算了以上值，再选择以什么的数据结构，以什么方式跑在硬件上，做个不恰当但是能表达这个设计原则的例子，就比如科学家根据人的身体机能的平均值，计算出潜水运动下潜的最大深度，然后根据这个值，进行各种辅助设备的研发和制造，以不断的产品迭代实现无限接近于理论值甚至超过理论值。这就是ClickHouse的设计原则，我再有一个理论值的基础上，所有的技术方向的把握全都要趋于符合这个理论值，实际上你看ClickHouse的产品版本迭代这么快的原因，就是在不断的废弃和选用的过程，当然还有一点就是硬件在不断发展，理论理想值也在随之调整。这样讲大家应该就能明白了。

   稍微深入一点技术层面的解释，再遵循了设计原则基础上，然后就是动手实现的过程了，基于将硬件功效最大化的目的，ClickHouse会在内存中进行GROUP BY，并且使用HashTable装载数据。与此同时，他们非常在意CPUL3级别的缓存，因为一次L3的缓存失效会带来70～100ns的延迟。这意味着在单核CPU上，它会浪费4000万次/秒的运算；而在一个32线程的CPU上，则可能会浪费5亿次/秒的运算。所以别小看这些细节，一点一滴地将它们累加起来，数据是非常可观的。正因为注意了这些细节，所以ClickHouse在基准查询中能做到1.75亿次/秒的数据扫描性能。

   这里基本就可以稍微理解一下ClickHouse快的一些原因，当然，肯定不止这么片面，做一个大的总结就是

   • 着眼硬件，先想后做
   • 算法在前，抽象在后
   • 勇敢尝鲜，不行就换
   • 特定场景，特殊优化
   • 持续测试，持续改进