ClickHouse简介

OLAP与ClickHouse的定位

OLAP的核心概念

OLTP：服务于高并发、低延迟的短事务操作（如银行转账、订单支付），强调数据的增删改查（CRUD）和事务一致性（ACID）。
OLAP：专注于大规模数据的复杂聚合分析（如统计报表多维分析），要求高吞吐/性能的批量查询，通常涉及全表扫描和多表关联。
OLAP的典型特征：
- 数据量大：TB/PB级数据存储。
- 查询复杂：涉及GROUP BY、JOIN、窗口函数等聚合操作。
- 读多写少：数据批量写入，极少单行更新。
- 高吞吐低延迟：即使数据量极大，仍需快速响应分析请求。

ClickHouse的定位

列式存储的极致优化
- 列式存储：数据按列而非行存储，同一列的数据类型相同，天然适合高压缩率（如LZ4、ZSTD算法），减少I/O和内存占用。
- 向量化查询：利用SIMD指令集（单指令多数据）对整列数据进行批量处理，大幅提升CPU利用率。
- 数据预聚合：通过MergeTree引擎的预排序（Primary Key）、跳数索引（Skipping Index）和物化视图（Materialized View）加速聚合查询。
分布式架构的天然支持
- 分片与副本：数据可水平分片（Sharding）存储，副本（Replication）机制通过ZooKeeper协调实现高可用。
- 分布式查询：支持跨节点并行执行查询，自动路由和合并结果，用户无需感知分片细节。
实时分析能力
- 高写入吞吐：通过类LSM-Tree（Log-Structured Merge-Tree）结构实现高效写入（如批量插入、后台合并）。
- 准实时查询：数据写入后通常在毫秒到秒级即可查询，适合实时报表和监控场景。
灵活性不足但性能优先
- 牺牲事务支持：不支持ACID事务，不适合需要强一致性的OLTP场景。
- 弱化单点更新：单行更新（UPDATE/DELETE）效率低，需通过ALTER TABLE实现批量更新。
- 复杂JOIN的局限：大表JOIN性能较差，建议通过预计算或宽表规避。

ClickHouse与其他OLAP技术的对比

技术/产品核心优势局限性适用场景

ClickHouse	极致查询性能、高压缩率、实时分析	JOIN能力弱、事务支持差	实时日志分析、用户行为分析
Apache Hive	生态完善、兼容Hadoop	延迟高（分钟级）、依赖MapReduce/Tez	离线批处理、数据仓库
Apache Druid	高并发低延迟、时间序列优化	架构复杂、存储成本高	实时监控、事件驱动分析
Elasticsearch	全文检索、近实时查询	聚合性能差、存储成本高	日志检索、文本分析
Snowflake	全托管、弹性扩展、多云支持	成本高昂、定制化能力弱	企业级云数仓

ClickHouse的诞生背景与核心优势

诞生背景

初衷是为了解决其内部海量数据分析的瓶颈。
核心业务（如搜索引擎、广告系统、用户行为分析）需要实时处理PB级数据。
传统数据库（如MySQL）和Hadoop生态工具（如Hive）无法满足低延迟、高吞吐的分析需求。

核心优势

列式存储与高效压缩：数据按列存储，同类型数据紧密排列，压缩率极高（节省存储和I/O），适合聚合查询（仅读取相关列）。
向量化查询引擎：利用CPU的SIMD指令并行处理整列数据，大幅提升计算效率（相比逐行处理）。
分布式架构：天然支持分片和副本，数据可水平扩展，查询自动并行化，轻松应对PB级数据。
实时写入与查询：写入吞吐高（百万级/秒），数据写入后毫秒级可查，支持实时分析场景（如监控、日志）。
高性能聚合计算：预排序、跳数索引、物化视图等机制，复杂聚合（GROUP BY、窗口函数）比传统数据库快10-100倍。
易用性与SQL兼容：支持标准SQL语法，学习成本低，且提供丰富扩展函数（如近似计算、地理数据处理）。
开源与社区生态：完全开源，社区活跃，支持与Kafka、Hadoop、Spark等工具无缝集成。

ClickHouse的适用场景与局限性

ClickHouse的适用场景

实时日志分析：Nginx访问日志、应用错误日志的实时聚合统计（PV/UV、错误率）。
用户行为分析：用户点击流分析、漏斗转化计算、留存率统计。
时序数据存储与监控：物联网（IoT）设备指标、服务器性能监控（Prometheus长期存储替代）。
大数据实时报表：电商实时销售额看板、广告点击效果分析（支持TB级数据秒级响应）。
联机分析处理（OLAP） ：复杂聚合查询（GROUP BY、窗口函数）、多维数据分析。

ClickHouse的局限性

不适用于OLTP场景：不支持事务（ACID）、高并发单行更新/删除效率极低。
不适合频繁单行更新/删除：数据更新需通过批量ALTER TABLE实现，延迟高。
JOIN性能较弱：大表JOIN容易成为性能瓶颈，建议预计算宽表或使用非规范化设计。
高并发点查询支持有限：默认设计面向高吞吐分析查询，单点查询（如按主键查单行）性能不如MySQL/Redis。
存储成本与数据冷热分离：全量数据存储成本较高，需自行管理冷热数据分层（如结合S3）。

数据类型与表引擎简介

数据类型

基础类型

类别类型示例描述

整数	`Int8`, `UInt32`	有符号/无符号整数（位数可选8/16/32/64），如`UInt32`表示0~4294967295。
浮点数	`Float32`, `Float64`	单精度（32位）和双精度（64位）浮点数。
字符串	`String`, `FixedString(N)`	`String`存储任意长度文本，`FixedString(N)`定长字符串（适合枚举值，如国家代码）。
日期时间	`Date`, `DateTime`	`Date`精确到天（如`2023-10-01`），`DateTime`精确到秒（如`2023-10-01 10:00:00`）。
布尔值	`Bool`	实际存储为`UInt8`（0或1），但支持`true`/`false`语法。
枚举	`Enum8`, `Enum16`	预定义值的字符串映射（如`Enum8('success' = 1, 'fail' = 2)`），节省存储空间。

复合类型

类型描述

Array(T)	同类型元素数组（如`Array(String)`存储多个字符串）。
Tuple(T1, T2)	异构元素的元组（如`Tuple(String, UInt32)`存储名称和年龄）。
Nested	嵌套表结构（类似子表），需与`Array`结合使用（如`Nested(tag String, value Float64)`）。

特殊类型

类型描述

LowCardinality	低基数优化类型（如重复值多的字符串字段），自动压缩存储（类似字典编码）。
Decimal(P, S)	高精度浮点数（如`Decimal(18, 4)`表示小数点后4位，适合金融金额）。
UUID	128位全局唯一标识符（如`UUID`类型存储设备ID）。
IPv4/IPv6	优化存储IP地址（`IPv4`用`UInt32`，`IPv6`用`FixedString(16)`）。

表引擎

基础引擎

引擎特点

TinyLog	无索引，数据不压缩，适用于小表或临时测试（写入后不可修改）。
Log	按列存储，支持并行查询，适合中等规模静态数据（写入后不可修改）。
Memory	数据仅存储在内存中，重启后丢失，适合高速缓存或中间结果暂存。

MergeTree引擎家族

引擎特点

MergeTree	基础引擎，支持主键索引、数据分区（PARTITION BY）和后台合并（Merge）。
ReplacingMergeTree	在MergeTree基础上，自动去重相同排序键的数据（保留最后写入版本）。
SummingMergeTree	自动合并时对数值列求和（如统计相同维度的指标累加）。
AggregatingMergeTree	合并时预聚合数据，需配合`AggregateFunction`类型使用，适合实时OLAP。
CollapsingMergeTree	通过标记字段（`sign`）合并时折叠数据（如删除旧版本记录）。
VersionedCollapsingMergeTree	在折叠基础上支持版本控制（如按时间戳保留最新状态）。

集成引擎

引擎特点

Kafka	从Kafka主题消费数据（需指定Broker、Topic和格式），实时写入ClickHouse。
MySQL	映射MySQL表到ClickHouse（类似外部表），支持读写操作（但性能不如原生表）。
HDFS	直接读取HDFS文件（如Parquet/ORC格式），适合离线分析。
JDBC/ODBC	通过JDBC或ODBC协议连接外部数据库（如PostgreSQL）。