前言
上文提到最近在搭建ClickHouse，基本上可以正常使用了，不过各项指标还得观察一段时间，毕竟硬盘资源虽然相对便宜用多了也扛不住，在选择将打点数据进行迁移的时候，主要有ClickHouse和Hive两个备选项，在查询各自的特点后选择了ClickHouse，碰巧得知自己最近刚接触的那个后台也是用的ClickHouse，看来自己选的还不赖，下面将一些对比信息进行展示，或许在你用到时有更好的判断，这里面涉及到一些专业词汇，我都是边读边查，尽量补充完整吧。
各项对比
一句话总结
- ClickHouse： 实时 / 近实时 OLAP 查询引擎，追求极致查询性能
- Hive：离线数仓（SQL on Hadoop），追求超大规模数据的批处理能力
OLAP 是 Online Analytical Processing 的缩写，中文一般叫 联机分析处理，主要用于：数据分析、报表统计、多维度聚合查询、决策支持（BI、数据仓库）等，读多写少，通常是批量导入，大量复杂 SELECT + GROUP BY，多数 OLAP 面向列存储，只读取需要的列，更适合聚合计算，更高压缩率。常见 OLAP 引擎如下：
| 系统 | 特点 |
|---|---|
| ClickHouse | 实时分析、列存、极快 |
| Hive | 基于 Hadoop，离线分析 |
| Impala | MPP，低延迟 SQL |
| Doris / StarRocks | 实时 OLAP |
| Greenplum | 传统 MPP OLAP |
| Snowflake | 云原生 OLAP |
一、整体定位对比
| 维度 | ClickHouse | Hive |
|---|---|---|
| 核心定位 | 实时 / 交互式分析 | 离线批处理数据仓库 |
| OLAP / OLTP | OLAP | OLAP（偏离线） |
| 查询延迟 | 毫秒 ~ 秒级 | 秒 ~ 分钟级 |
| 典型用途 | 实时报表、监控、用户行为分析 | 数仓建模、ETL、离线统计 |
OLTP 是 Online Transaction Processing 的缩写，主要是指业务交易，高频 INSERT / UPDATE，如 MySQL 订单表
二、架构设计
ClickHouse
- MPP 架构
- 自带执行引擎 + 存储引擎
- 无依赖 Hadoop 生态
- 常见形态：
- 单机
- 分片 + 副本（ZooKeeper / ClickHouse Keeper）
- 架构简单
- 查询路径短
- 极致性能
MPP 架构 是 Massively Parallel Processing（大规模并行处理） 的缩写，是一种通过多节点并行执行同一条查询来提升性能的数据库 / 数据仓库架构。
Hive
- SQL 抽象层
- 本身不执行计算
- 依赖底层引擎：
- MapReduce（最慢），基于“Map（映射）”和“Reduce（归约）”的批处理模型，依赖HDFS读写中间结果
- Tez，基于DAG（有向无环图）的计算框架，优化MapReduce任务链，减少中间I/O
- Spark（现在最常用），基于内存计算和DAG执行引擎的通用框架，支持批处理、流处理、SQL查询、机器学习等多种范式
- 存储依赖 HDFS / 对象存储
- 架构重
- 扩展性极强
- 查询启动成本高
Hive本身不存储基础数据，只存 元数据（Metadata），它不等于数据库，只是SQL 解析 + 元数据管理 + 任务调度的集合，存储和计算都依赖外部系统，Hive 是“数据的管理员 + 翻译官”，不是“仓库管理员”
三、查询性能
| 对比项 | ClickHouse | Hive |
|---|---|---|
| 单表扫描 | 非常快（列式+向量化） | 慢 |
| 聚合 / GROUP BY | 极快 | 中等 |
| Join | 快（内存 Join） | 较慢 |
| 并发能力 | 高（适合 BI） | 低（不适合高并发） |
| 启动开销 | 几乎没有 | 高（任务调度） |
- 实时查询：ClickHouse 完胜
- 超大离线计算：Hive 更稳
四、数据规模与扩展性
| 维度 | ClickHouse | Hive |
|---|---|---|
| 单表规模 | TB ~ PB | PB ~ EB |
| 横向扩展 | 可以 | 非常强 |
| 成本 | 偏高（机器） | 偏低（HDFS + 离线） |
Hive 更适合「便宜地存很多数据」
五、SQL 能力对比
| 维度 | ClickHouse | Hive |
|---|---|---|
| SQL 标准 | 非标准（偏定制） | 接近标准 SQL |
| 窗口函数 | 支持（但有限制） | 支持全面 |
| 子查询 | 支持 | 支持 |
| UDF | 有，但不如 Hive 灵活 | 非常成熟 |
| 事务 | 不支持（有限） | 不支持 |
Hive 更“SQL 化”，ClickHouse 更“性能化”
六、存储格式 & 数据组织
| 维度 | ClickHouse | Hive |
|---|---|---|
| 存储模型 | 列式 | 列式 / 行式 |
| 常见格式 | MergeTree 系列 | ORC / Parquet |
| 索引 | 稀疏索引、跳数索引 | 分区 + ORC 索引 |
| 数据更新 | 不擅长 | 不擅长 |
两者都不适合高频 UPDATE / DELETE
七、数据写入能力
| 维度 | ClickHouse | Hive |
|---|---|---|
| 实时写入 | 非常适合 | 不适合 |
| 批量导入 | 快 | 快 |
| 流式写入 | Kafka / HTTP | 一般 |
ClickHouse 非常适合 日志 / 埋点 / 实时数据
八、运维复杂度
| 维度 | ClickHouse | Hive |
|---|---|---|
| 部署 | 简单 | 复杂 |
| 依赖组件 | 少 | 多（HDFS/YARN/Metastore） |
| 成本 | 偏高 | 偏低 |
| 运维门槛 | 中 | 高 |
九、生态与集成
| 维度 | ClickHouse | Hive |
|---|---|---|
| Hadoop 生态 | 弱 | 强 |
| BI 工具 | 非常友好 | 一般 |
| 实时分析 | 强 | 弱 |
| 数仓体系 | 可做明细 / ADS | DWD / DWS / ADS |
十、典型应用场景
ClickHouse 适合
- 实时报表
- 用户行为分析
- 监控指标
- 日志分析
- BI 查询（高并发）
Hive 适合
- 离线数仓
- 数据清洗 / ETL
- 历史全量分析
- 低频、大规模统计
十一、是否可以一起用？（最佳实践）
非常推荐组合使用
典型架构：
数据采集 ↓ ODS（HDFS / Hive） ↓ 离线加工（Hive / Spark） ↓ 结果同步 ↓ ClickHouse（对外查询 / BI）Hive 做「数据工厂」
ClickHouse 做「查询引擎」
十二、选型建议（快速决策）
| 需求 | 选择 |
|---|---|
| 实时查询 | ClickHouse |
| 离线数仓 | Hive |
| BI 报表 | ClickHouse |
| 超大规模历史数据 | Hive |
| 高并发分析 | ClickHouse |
| 低成本存储 | Hive |
使用ClickHouse的一点小记录
配置文件
- 主配置文件：/etc/clickhouse-server/config.xml
- 用户与权限配置：/etc/clickhouse-server/users.xml
数据目录
/var/lib/clickhouse/ # ClickHouse 数据根目录（由 <path> 指定） ├── data/ # 逻辑数据目录（库/表路径，通常是到 store 的软链接） ├── metadata/ # 表、视图、数据库的元数据（.sql 建表语句） ├── metadata_dropped/ # 被 DROP 的表元数据暂存，用于延迟清理 ├── store/ # 实际数据存储目录（MergeTree 表的真实数据） ├── tmp/ # 查询/写入临时目录（排序、聚合、INSERT 中间文件） ├── user_files/ # file() 表函数、INTO OUTFILE 可访问的目录 ├── dictionaries_lib/ # 外部字典使用的动态库（.so 文件） └── access/ # RBAC 权限数据（用户、角色、权限定义）查询每个数据库占用的总空间
SELECTdatabase,formatReadableSize(sum(total_bytes))AStotal_sizeFROMsystem.tablesGROUPBYdatabaseORDERBYsum(total_bytes)DESC;更详细的占用（包含未压缩大小、索引大小等）
SELECTdatabase,formatReadableSize(sum(data_compressed_bytes))AScompressed_size,formatReadableSize(sum(data_uncompressed_bytes))ASuncompressed_size,formatReadableSize(sum(primary_key_bytes))ASprimary_key_sizeFROMsystem.partsGROUPBYdatabaseORDERBYsum(data_compressed_bytes)DESC;- data_compressed_bytes：真实磁盘占用
- data_uncompressed_bytes：未压缩大小
- primary_key_bytes：主键索引大小
确认是哪些表占用了大空间
SELECTdatabase,table,formatReadableSize(total_bytes)ASsizeFROMsystem.tablesWHEREdatabase='system'ORDERBYtotal_bytesDESC;最近发现批量导入数据后，system数据库比我的业务数据库都大，查询后显示trace_log表特别大，据说可以直接删TRUNCATE TABLE system.trace_log;，这一点我还在实践中
结论
- ClickHouse 是接近实时 OLAP 的查询引擎，追求极致查询性能
- Hive通常作为离线数仓（SQL on Hadoop），追求超大规模数据的批处理能力
- 选择合适的工具做合适的事，你就是一个巧匠，选择合适的人做合适的事，你就是一个领导
人生若只如初见，何事秋风悲画扇。等闲变却故人心，却道故人心易变。
