ClickHose和Hive的对比与选择

前言

上文提到最近在搭建ClickHouse，基本上可以正常使用了，不过各项指标还得观察一段时间，毕竟硬盘资源虽然相对便宜用多了也扛不住，在选择将打点数据进行迁移的时候，主要有ClickHouse和Hive两个备选项，在查询各自的特点后选择了ClickHouse，碰巧得知自己最近刚接触的那个后台也是用的ClickHouse，看来自己选的还不赖，下面将一些对比信息进行展示，或许在你用到时有更好的判断，这里面涉及到一些专业词汇，我都是边读边查，尽量补充完整吧。

各项对比

一句话总结

• ClickHouse： 实时 / 近实时 OLAP 查询引擎，追求极致查询性能
• Hive：离线数仓（SQL on Hadoop），追求超大规模数据的批处理能力

OLAP 是 Online Analytical Processing 的缩写，中文一般叫 联机分析处理，主要用于：数据分析、报表统计、多维度聚合查询、决策支持（BI、数据仓库）等，读多写少，通常是批量导入，大量复杂 SELECT + GROUP BY，多数 OLAP 面向列存储，只读取需要的列，更适合聚合计算，更高压缩率。常见 OLAP 引擎如下：

一、整体定位对比

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 更稳

四、数据规模与扩展性

Hive 更适合「便宜地存很多数据」

五、SQL 能力对比

Hive 更“SQL 化”，ClickHouse 更“性能化”

六、存储格式 & 数据组织

两者都不适合高频 UPDATE / DELETE

七、数据写入能力

ClickHouse 非常适合 日志 / 埋点 / 实时数据

八、运维复杂度

九、生态与集成

十、典型应用场景

ClickHouse 适合

• 实时报表
• 用户行为分析
• 监控指标
• 日志分析
• BI 查询（高并发）

Hive 适合

• 离线数仓
• 数据清洗 / ETL
• 历史全量分析
• 低频、大规模统计

十一、是否可以一起用？（最佳实践）

非常推荐组合使用

典型架构：

数据采集 ↓ ODS（HDFS / Hive） ↓ 离线加工（Hive / Spark） ↓ 结果同步 ↓ ClickHouse（对外查询 / BI）

Hive 做「数据工厂」
ClickHouse 做「查询引擎」

十二、选型建议（快速决策）

使用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），追求超大规模数据的批处理能力
• 选择合适的工具做合适的事，你就是一个巧匠，选择合适的人做合适的事，你就是一个领导

人生若只如初见，何事秋风悲画扇。等闲变却故人心，却道故人心易变。