1.ClickHouse是什么
ClickHouse联机分析的数据库管理系统
2.列式存储和行式存储的区别
列式存储的优点是同一列存放在一起，由于数据类型相同，可以进行很好的压缩，排序更加方便，查询时不需要读取一整行数据
行式存储的优点是支持事务处理，更好的支持一致性
3.MergeTree是什么
mergetree有俩层含义：合并树表引擎家族或者是最基本的MergeTree表引擎
3.1MergeTree独有的两项技能TTL和存储策略
TTL
TTL有行级和表级，表示数据的存活周期，具体运行原理如果一张mergeTree被设置了TTL表达式，那么在写入数据时，会以数据分区为单位，在每个分区目录下生成一个TTL.txt文件，txt文件通过一串json保存了ttl的相关信息，column用于保存列级别，table用于保存表级别，max和min分别表示了ttl在该分区内指定日期最大值和最小值与interval计算后的时间戳
存储策略
数据片段写入，数据片段不可改变，定期合并相同的数据片段
多路径存储策略：根据配置策略的不同，目前有三类存储策略：
- 默认策略：默认存储在config.xml配置的path目录下
- JBOD策略：类似于raid0,每产生一次merge或者insert所产生的分区会轮询的写入磁盘
- HOT/COLD策略：是有HOT和COLD两块区域，HOT区域主要使用SSD高性能存储媒介，COLD区域主要使用HDD高容量存储媒介。
当时据写入mergetree之初会在HOT分区创建分区便于写入数据，当数据达到阈值会移动到COLD区
1
2
3
4
5
6
3.2MergeTree有俩种索引，一级索引和二级索引。
索引主要是帮助查询时减少扫描范围
一级索引
MergeTree主键使用PRIMARY KEY定义，依据index_granularity间隔，为数据表生成一级索引并保存在primary.idx文件内，索引文件按照primarykey排序；primary.idx文件内的索引采用稀疏索引，稀疏索引的好处在于少量 的索引标记就能记录大量的区间位置信息
二级索引（跳数索引）
四种类型：minmax、set、布隆过滤器
索引的查询过程：MargeTee按照index_granularity的间隔粒度,将一段完整的数据划分为markrange(间隔数据段)
具体的查询过程
1. 生成查询条件区间，首先将查询条件转换为条件区间，即便是单个值的查询条件也会被转换为条件区间
2. 递归交集判断：以递归的形式依次对条件区间和数值区间做交集判断，如果条件区间和数值区间没有交集，就会通过剪枝算法优化整段的MarkRange,
如果有交集，且MarkRange步数大于8，继续递归，如果有交集，MarkRange不可再分，记录MarkRange并返回
3. 合并MarkRange
1
2
3
4
5
6
7
8
4.ReplicatedMergeTree
4.1ReplicatedMergeTree是什么
ReplicatedMargeTree是以去重为目的设计的，它在合并分区时删除重复的数据
处理逻辑
①ReplicatedMergeTree是以OrdeBy排序键作为重复数据的唯一键
②只有在合并区间的时候才会触发删除重复数据，且同一分区的重复数据会被删除，不同分区的重复数据不会被删除
③在去重时，已经OrderBy进行排序能够找到相邻的的重复数据
④去重有俩种策略，如果没有ver版本号，保留同一组数据中的最后一行，如果有ver版本号，保留ver字段最大的一行
ReplicatedMergeTree有一些显著特点：
在进行INSERT和ALTER时需要借助Zookeeper的分布式协同能力，且采用多主架构，这些操作会借助zookeeper协同能力被分发至每个副本以本地形式执行，查询时不需要zookeeper
4.2分片和副本
俩种区分方法
从数据层面，例如ClickHouse集群有N个节点，各个节点有一张相同的数据表Y,如果N1和N2的Y的数据完全相同，则它们互为副本，如果完全不同则互为分片
从功能层面，使用副本的只要目的是防止数据丢失，增加数据存储的冗余；使用分片的目的是实现数据的水平切分
5.AggregatingMergeTree
在GroupBy明确的状态下，如果使用MergeTree存储数据，然后通过GROUP BY聚合查询，并利用SUM聚合函数汇总结果，会产生额外的查询开销和存储开销
AggregatingMergeTree是什么
使用是以二进制的形式存储中间状态结果，在写入数据时，需要调用state函数，在查询数据时则需要调用相应的merge函数。
使用OrderBy排序键作为聚合数据的依据 在合并分区时会发生数据聚合，且数据只发生在同分区内
在聚合数据时，相同聚合key的多行数据会合并成一行，对于非主键、非聚合方法类型字段，则会取第一行数据
物化视图是什么
与普通视图的不同，普通视图不保存数据，保存的仅仅是查询语句;物化视图是把查询结果根据相应的引擎存入到磁盘或内存中。引擎一般使用AggregatedMargeTree，与普通mergeTree搭配使用。优点在于查询速度快，因为进行预计算；缺点在于消耗很多的机器资源，由于存放的是历史数据，对历史数据的去重不好用
基本语法
物化视图创建好之后，若源表被写入新数据，则物化视图也会同步更新；不支持同步删除，源表数据被删除，物化视图不会被删除。
6.Distributed引擎是
Distributed引擎是什么
Distributed表引擎是分布式表的代名词，自身不存储任何数据，而是作为数据分片的透明代理，能够自动路由数据至集群的各个节点，distributed表引擎与其他数据表引擎协同工作
本地表（Local Table） 与 分布式表
本地表：通常以_local为后缀进行命名。本地表是承接数据的载体，可以使用非distributed的任意表引擎，一张本地表对应了一个数据分片
分布式表：通常以_all为后缀进行命名。分布式表只能使用distributed表引擎，他与本地表形成一对多的映射关系，日后将通过分布式表代理操作多张本地表
分布式写入流程
在向集群内的分片写入数据时，通常有两种思路
借助外部计算系统，事先将数据均匀分片，再借助计算机系统直接将数据写入clickhouse集群的各个本地表
通过Distributed表引擎代理写入分片数据
第二种思路：
1.在第一个分片节点写入本地分片数据，根据分片规则划分数据，第一个分片建立远端连接，准备发送远端分片数据，将远程分片数据写入临时数据文件，接着，会尝试与远端分片节点建立连接
2.像远端数据发送数据，数据在传输之前会被压缩
3.远端连接写入本地表，直至所有的数据发送完毕
问题：可能会造成单点瓶颈
解决方法：与ReplicatedMergeTree表引擎结合使用，
使用ReplicatedMergeTree作为本地表引擎，则在该分片内，多个副本之间的数据复制会交给ReplicatedMergeTree自己处理，不再由Distributed负责，从而减负
1、简单介绍一下ClickHouse
ClickHouse是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)。主要用于WEB流量分析。ClickHouse的全称是Click Stream,Data WareHouse，简称ClickHouse。
ClickHouse非常适用于商业智能领域，除此之外，它也能够被广泛应用于广告流量、Web、App流量、电信、金融、电子商务、信息安全、网络游戏、物联网等众多其他领域。
2、ClickHouse具有哪些特点
-
支持完备的SQL操作
-
列式存储与数据压缩
-
向量化执行引擎
-
关系型模型(与传统数据库类似)
-
丰富的表引擎
-
并行处理
-
在线查询
-
数据分片
3、ClickHouse作为一款高性能OLAP数据库，存在哪些不足
-
不支持事务。
-
不擅长根据主键按行粒度进行查询（虽然支持），故不应该把ClickHouse当作Key-Value数据库使用。
-
不擅长按行删除数据（虽然支持）
4、ClickHouse有哪些表引擎
- MergeTree系列
- Log系列
- Integration Engines
- Special Engines
5、介绍下Log系列表引擎
应用场景
Log系列表引擎功能相对简单，主要用于快速写入小表(1百万行左右的表)，然后全部读出的场景。即一次写入多次查询。
Log系列表引擎的特点
共性特点
- 数据存储在磁盘上
- 当写数据时，将数据追加到文件的末尾
不支持
- 并发读写，当向表中写入数据时，针对这张表的查询会被阻塞，直至写入动作结束
- 不支持索引
- 不支持原子写：如果某些操作(异常的服务器关闭)中断了写操作，则可能会获得带有损坏数据的表
- 不支持ALTER操作(这些操作会修改表设置或数据，比如delete、update等等)
6、 简单介绍下MergeTree系列引擎
在所有的表引擎中，最为核心的当属MergeTree系列表引擎，这些表引擎拥有最为强大的性能和最广泛的使用场合。对于非MergeTree系列的其他引擎而言，主要用于特殊用途，场景相对有限。而MergeTree系列表引擎是官方主推的存储引擎，支持几乎所有ClickHouse核心功能。
- MergeTree表引擎
MergeTree在写入一批数据时，数据总会以数据片段的形式写入磁盘，且数据片段不可修改。为了避免片段过多，ClickHouse会通过后台线程，定期合并这些数据片段，属于相同分区的数据片段会被合成一个新的片段。这种数据片段往复合并的特点，也正是合并树名称的由来。
MergeTree作为家族系列最基础的表引擎，主要有以下特点：- 存储的数据按照主键排序：允许创建稀疏索引，从而加快数据查询速度
- 支持分区，可以通过PRIMARY KEY语句指定分区字段。
- 支持数据副本
- 支持数据采样
7、简单介绍下外部集成表引擎
ClickHouse提供了许多与外部系统集成的方法，包括一些表引擎。这些表引擎与其他类型的表引擎类似，可以用于将外部数据导入到ClickHouse中，或者在ClickHouse中直接操作外部数据源。
例如直接读取HDFS的文件或者MySQL数据库的表。这些表引擎只负责元数据管理和数据查询，而它们自身通常并不负责数据的写入，数据文件直接由外部系统提供。目前ClickHouse提供了下面的外部集成表引擎：
ODBC
通过指定odbc连接读取数据源
JDBC
通过指定jdbc连接读取数据源；
MySQL
将MySQL作为数据存储，直接查询其数据
HDFS
直接读取HDFS上的特定格式的数据文件；
Kafka
将Kafka数据导入ClickHouse
RabbitMQ
与Kafka类似
8、ClickHouse有哪些数据类型
数值类型
固定长度的整数类型又包括有符号和无符号的整数类型。
- 浮点类型Decimal类型
- 单精度浮点数
- 双精度浮点数
有符号的定点数，可在加、减和乘法运算过程中保持精度。ClickHouse提供了Decimal32、Decimal64和Decimal128三种精度的定点数
字符串类型
- String
字符串可以是任意长度的。它可以包含任意的字节集，包含空字节。因此，字符串类型可以代替其他 DBMSs 中的VARCHAR、BLOB、CLOB 等类型。 - FixedString
固定长度的N字节字符串，一般在在一些明确字符串长度的场景下使用。
UUID
UUID是一种数据库常见的主键类型，在ClickHouse中直接把它作为一种数据类型。UUID共有32位，它的格式为8-4-4-4-12
日期类型
时间类型分为DateTime、DateTime64和Date三类。需要注意的是ClickHouse目前没有时间戳类型，也就是说，时间类型最高的精度是秒，所以如果需要处理毫秒、微秒精度的时间，则只能借助UInt类型实现。
- Date类型
用两个字节存储，表示从 1970-01-01 (无符号) 到当前的日期值。日期中没有存储时区信息。
- DateTime类型
用四个字节（无符号的）存储 Unix 时间戳。允许存储与日期类型相同的范围内的值。最小值为 0000-00-00 00:00:00。时间戳类型值精确到秒（没有闰秒）。时区使用启动客户端或服务器时的系统时区。
布尔类型
ClickHouse没有单独的类型来存储布尔值。可以使用UInt8 类型，取值限制为0或 1。
数组类型
Array(T)，由 T 类型元素组成的数组。T 可以是任意类型，包含数组类型。但不推荐使用多维数组，ClickHouse对多维数组的支持有限。例如，不能在MergeTree表中存储多维数组。
枚举类型
枚举类型通常在定义常量时使用，ClickHouse提供了Enum8和Enum16两种枚举类型。
Tuple类型
Tuple(T1, T2, …)，元组，与Array不同的是，Tuple中每个元素都有单独的类型，不能在表中存储元组（除了内存表）。它们可以用于临时列分组。在查询中，IN表达式和带特定参数的 lambda 函数可以来对临时列进行分组。
特殊数据类型
- Nullable
Nullable类型表示某个基础数据类型可以是Null值。其具体用法如下所示： - Domain
Domain类型是特定实现的类型：
IPv4是与UInt32类型保持二进制兼容的Domain类型，用于存储IPv4地址的值。它提供了更为紧凑的二进制存储的同时支持识别可读性更加友好的输入输出格式。
IPv6是与FixedString(16)类型保持二进制兼容的Domain类型，用于存储IPv6地址的值。它提供了更为紧凑的二进制存储的同时支持识别可读性更加友好的输入输出格式。
9、ClickHouse为何如此之快
-
将硬件性能发挥到极致
基于将硬件功效最大化的目的，ClickHouse会在内存中进行GROUP BY，并且使用HashTable装载数据。 -
算法方面精益求精
在ClickHouse的底层实现中，经常会面对一些重复的场景，例如字符串子串查询、数组排序、使用HashTable等。对于不同的场景会用不同的算法。 -
勇于尝鲜，不行就换
除了字符串之外，其余的场景也与它类似，ClickHouse会使用最合适、最快的算法。如果世面上出现了号称性能强大的新算法，ClickHouse团队会立即将其纳入并进行验证。如果效果不错，就保留使用；如果性能不尽人意，就将其抛弃。 -
特定场景，特殊优化
针对同一个场景的不同状况，选择使用不同的实现方式，尽可能将性能最大化。关于这一点，其实在前面介绍字符串查询时，针对不同场景选择不同算法的思路就有体现了。类似的例子还有很多，例如去重计数uniqCombined函数，会根据数据量的不同选择不同的算法：当数据量较小的时候，会选择Array保存；当数据量中等的时候，会选择HashSet；而当数据量很大的时候，则使用HyperLogLog算法。
对于数据结构比较清晰的场景，会通过代码生成技术实现循环展开，以减少循环次数。接着就是大家熟知的大杀器—向量化执行了。SIMD被广泛地应用于文本转换、数据过滤、数据解压和JSON转换等场景。相较于单纯地使用CPU，利用寄存器暴力优化也算是一种降维打击了。 -
持续测试，持续改进
如果只是单纯地在上述细节上下功夫，还不足以构建出如此强大的ClickHouse，还需要拥有一个能够持续验证、持续改进的机制。由于Yandex的天然优势，ClickHouse经常会使用真实的数据进行测试，这一点很好地保证了测试场景的真实性。与此同时，ClickHouse也是我见过的发版速度最快的开源软件了，差不多每个月都能发布一个版本。没有一个可靠的持续集成环境，这一点是做不到的。正因为拥有这样的发版频率，ClickHouse才能够快速迭代、快速改进。 -
行存储和列存储
分析场景中，我们一般会读大量的行而取少量的列，在列式存储结构下，我们只需要取对应的列数据就可以，不参与计算的列完全不会被扫描到，这会极大的降低磁盘 IO 的消耗。 -
数据压缩
基于列式存储的结构，同一列中的数据属于同一类型，压缩效果会更加显著。列存储往有着高达十倍甚至更高的压缩比，节省了大量的存储空间，降低了存储成本。 -
向量化执行引擎
SIMD（Single Instruction Multiple Data）即单条指令操作多条数据，它是通过数据并行以提高性能的一种方式，可以简单理解为在寄存器层面对程序中的数据做并行处理，Clickhouse 在能够提升计算效率的地方大量使用了 SIMD，通过使用 SIMD，基本上能带来几倍的性能提升，像阿里云的 PolarDB-X 也引入了向量化执行引擎，为表达式计算带来了几十倍的性能提升。 -
多线程与分布式
分布式领域存在一条定律，计算移动比数据移动更加划算，这也是其核心所在，将数据的计算直接发放到数据所在的服务器，多机并行处理，再把最终的结果汇集在一起；另外 Clickhouse 也通过线程级别并行的方式为效率进一步提速，极致去利用服务器的资源。 -
多样化的表引擎
10、ClickHouse 常见的问题有哪些
1.重启 ClickHouse 服务的时间会比较长：主要是由于该节点数据分片过多导致加载缓慢，耐心等待即可。
2.数据插入报错 too many parts exception：主要是由于数据插入过于频繁，导致数据分片在后台 merge 缓慢，ClickHouse 启动自我保护机制，拒绝数据继续插入。此时可尝试增大插入数据的 batch_size (10 万) 并降低数据插入的频率（每秒 1 次）以缓解该问题。
3.复制表变为只读：主要是由于 ClickHouse 无法连接 ZooKeeper 集群或 ZooKeeper 上该复制表的元数据丢失导致的，此时新数据无法插入该表。若要解决该问题，首先要检查 ZooKeeper 的连接状况，如果连接失败，则需进一步检查网络状态以及 ZooKeeper 的状态，连接恢复后，复制表就可以继续插入数据了。如果连接正常而元数据丢失，此时可以将复制表转为非复制表然后再进行数据插入操作。
4.执行 JOIN 操作时内存超限：可能是由于 JOIN 前后的两个子查询中没有添加明确的过滤条件导致的，也有可能是由于 JOIN 的数据本身就很大，无法全部加载到内存。此时可以尝试增加过滤条件以减小数据量，或者适当修改配置文件中的内存限制，以装载更多的数据。
11、ClickHouse 的问题排查方法
1.检查 ClickHouse 运行状态，确保服务正常运行。
2.检查 ClickHouse 错误日志文件，寻找问题根源。
3.检查系统日志文件 (/var/log/messages) 中与 ClickHouse 相关的记录，查看是否是系统操作导致 ClickHouse 异常。
4.对于未知问题或 BUG，可以到官方 GitHub 仓库的 issue 下寻求帮助，需提供完整的问题描述和错误日志信息。
1、介绍
开源的列式存储数据库(DBMS)，由C++编写，用于在线分析处理查询(OLAP)
可以通过SQL查询实时生成分析数据报告
解释：
DBMS：数据库管理系统
常见的列式存储数据库：Hbase、ClickHouse、Druid
OLAP：On-Line Analytical Processing，联机分析处理，做数据统计和分析的平台
OLTP：On-Line Transaction Processing，联机事务处理，业务数据处理的平台
2、特点
列式存储适用于聚合统计操作、便于压缩和缓存
兼容SQL语法和DBMS的功能
可以根据需求选择多种引擎
顺序写+压缩，保证了高吞吐写入能力
划多个分区及索引粒度，可以实现并行处理，可以充分利用CPU，但不适用于多条查询
3、常见的数据类型
整形：(U)Int8-64
浮点型：Float32-64，存在误差，适用于精度要求不高场景
×布尔型：无专门类型，常用UInt8表示，取值0/1
Decimal类型(可保持精度的有符号浮点类型)：Decimal32(s)-128
字符串类型：任意长/定长字符串FixString(N)
枚举类型：Enum8/16，例如x Enum8('hello' = 1, 'world' = 2)，插入是VALUES(‘hello’),(‘world’)，或转换整形查询CAST(x,’Int8’)
时间类型：Date、Datetime、Datetime64
数组类型：array(1, 2) AS x或[1, 2] AS x
4、常见的表引擎
表引擎介绍：显式声明、决定存储方式和位置、并发索引多线程
TinyLog：保存到磁盘，无索引和并发控制，仅用于测试少量数据
Memory：存至内存，无索引，查询性能高，小数据量
MergeTree-合并树：可设置分区(不同文件、写入合并)、主键(非唯一约束，默认间隔8192)和排序字段(前缀字段必须为主键)、可设置表级别和列级别TTL生命周期
ReplacingMergeTree：去重合并树，避免了无唯一约束，重复数据保留版本字段大(参数， 常为时间)
SummingMergeTree：适用于根据维度进行汇总聚合，参数传递汇总列
5、常见操作
(1)插入
(2)更新/删除：
重操作，会改变分区(建议做批量变更)
语法：alter table t_order_smt delete/update
执行：先为新数据新建分区，把旧分区打失效标记，通过分区合并的触发，删除旧数据(3)查询
支持子查询、CTE(Common Table Expression 公用表表达式/临时结果集，例如with a as xxx)、join、group by的各种小计操作：
with rollup：自右至左去掉维度小计
with cube：先自右至左，再自左至右进行小计
with totals: 计算合计
(4)修改字段操作
增删改字段
alter table tableName add / modify / drop column
(5)数据导出操作
clickhouse-client --query "select * from t_order_mt where create_time='2020-06-01 12:00:00'" --format CSVWithNames > /opt/module/data/rs1.csv1
6、副本-高可用性
写入流程：写入数据后将写入日志提交到zk，副本收到zk的写入日志后从主节点下载新数据
配置步骤：同步xml配置文件，分别建表，引擎采用ReplicatedMergeTree
参数传递：engine =ReplicatedMergeTree('/clickhouse0225/table/01/t_order_rep','rep_102')
7、分片集群
(1)解决问题：横向扩容、水平切分
(2)操作：不同分片在不同节点，使用Distributed 表引擎实现数据拼接
(3)读取流程：选择error count小的副本进行数据的读取
、什么是 ClickHouse？
ClickHouse 是近年来备受关注的开源列式数据库管理系统，主要用于数据分析（OLAP）领域。通过向量化执行以及对 cpu 底层指令集（SIMD）的使用，它可以对海量数据进行并行处理，从而加快数据的处理速度。ClickHouse 从 OLAP场景需求出发，定制开发了一套全新的高效列式存储引擎，并且实现了数据有序存储、主键索引、稀疏索引、数据 Sharding、数据 Partitioning、TTL、主备复制等丰富功能。
2、ClickHouse 有哪些应用场景？
绝大多数请求都是用于读访问的；
数据需要以大批次（大于 1000 行）进行更新，而不是单行更新；
数据只是添加到数据库，没有必要修改；
读取数据时，会从数据库中提取出大量的行，但只用到一小部分列；
表很“宽”，即表中包含大量的列；
查询频率相对较低（通常每台服务器每秒查询数百次或更少）；
对于简单查询，允许大约 50 毫秒的延迟；
列的值是比较小的数值和短字符串（例如，每个 URL 只有 60 个字节）；
在处理单个查询时需要高吞吐量（每台服务器每秒高达数十亿行）；
不需要事务；
数据一致性要求较低；
每次查询中只会查询一个大表。除了一个大表，其余都是小表；
查询结果显著小于数据源。即数据有过滤或聚合。返回结果不超过单个服务器内存。
3、ClickHouse 列式存储的优点有哪些？
当分析场景中往往需要读大量行但是少数几个列时，在行存模式下，数据按 行连续存储，所有列的数据都存储在一个 block中，不参与计算的列在 IO 时也要全部读出，读取操作被严重放大。而列存模式下，只需要读取参与计 算的列即可，极大的减低了 IOcost，加速了查询。
同一列中的数据属于同一类型，压缩效果显著。列存往往有着高达十倍甚至 更高的压缩比，节省了大量的存储空间，降低了存储成本。
更高的压缩比意味着更小的 data size，从磁盘中读取相应数据耗时更短。
自由的压缩算法选择。不同列的数据具有不同的数据类型，适用的压缩算法 也就不尽相同。可以针对不同列类型，选择最合适的压缩算法。
高压缩比，意味着同等大小的内存能够存放更多数据，系统 cache 效果更好。
4、ClickHouse 的缺点是是什么？
不支持事务，不支持真正的删除/更新；
不支持二级索引；
join 实现与众不同；
不支持窗口功能；
元数据管理需要人为干预。
5、ClickHouse 的架构是怎样的？
ClickHouse 采用典型的分组式的分布式架构，其中：
Shard。集群内划分为多个分片或分组（Shard 0 … Shard N），通过 Shard的线性扩展能力，支持海量数据的分布式存储计算。
Node。每个 Shard 内包含一定数量的节点（Node，即进程），同一 Shard
内的节点互为副本，保障数据可靠。ClickHouse 中副本数可按需建设，且逻 辑上不同 Shard 内的副本数可不同。
ZooKeeper Service。集群所有节点对等，节点间通过 ZooKeeper 服务进 行分布式协调。