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）。

引擎选择

• 默认选择 ：优先使用MergeTree系列引擎（90%场景适用）。
• 实时聚合 ：AggregatingMergeTree + 物化视图实现预计算。
• 外部数据 ：临时分析使用MySQL或HDFS引擎，长期存储建议导入本地表。
• 日志场景 ：高吞吐写入选择MergeTree，小数据量测试用TinyLog。