科普-clickhouse的一些基本知识

摘要

本文介绍clickhouse的名字来源，使用接口和对SQL的支持，同时辨析了它与传统数据库的区别，即弱化事务的特性。

问：clickhouse是不是一个点击统计的基础框架？

答：不是。这是一个非常常见的误解，主要源于名字的相似性。

ClickHouse 和 点击统计（Click Tracking） 没有直接的从属关系，它的名字来源于其早期的一个内部项目名称，但现在的定位完全不同。

以下是详细的解释：

1. ClickHouse 是什么？

ClickHouse 是一个开源的、列式存储的联机分析处理（OLAP）数据库管理系统。

• 核心功能：它用于存储海量数据（PB 级别），并能够以极快的速度（亚秒级）执行复杂的分析查询。
• 名字由来：它最初是由俄罗斯搜索引擎公司 Yandex 开发的，用于其网络分析服务 Yandex.Metrica。因为 Yandex.Metrica 需要处理大量的“点击”流数据，所以这个数据库项目早期被称为 "ClickHouse"（意为“点击的房子/仓库”）。
• 现状：虽然它起源于处理点击流数据，但它现在已经成为一个通用的分析型数据库，广泛应用于日志分析、用户行为分析、金融风控、物联网监控等任何需要大规模实时数据分析的场景，而不仅仅局限于“点击统计”。

2. “点击统计的基础框架”通常指什么？

如果你需要一个专门用于统计网站或广告点击的基础框架，通常会包含以下组件，而 ClickHouse 只是其中可能用到的存储和计算引擎之一：

• 数据采集：前端 JS SDK、Nginx 日志、后端埋点。
• 消息队列：Kafka、Pulsar（用于缓冲高并发点击流）。
• 流式计算：Flink、Spark Streaming（用于实时聚合）。
• 数据存储：ClickHouse、Doris、StarRocks、Elasticsearch 或 HBase。
• 可视化：Superset、Metabase、Grafana 或自研报表系统。

总结

• ClickHouse ≠ 点击统计框架。
• ClickHouse = 高性能分析型数据库。
• 关系：你可以使用 ClickHouse 作为底层数据库来构建一个点击统计系统，因为它非常擅长处理这种高频写入和实时聚合查询的场景，但它本身不是一个完整的“点击统计解决方案”或“框架”，它只是一个数据库软件。

打个比方：ClickHouse 就像是一台高性能的发动机。虽然它最早是为赛车（点击统计）设计的，但现在它可以装在卡车、轮船或发电机上（各种大数据分析场景）。你不能说发动机就是“赛车”，同理，ClickHouse 也不是“点击统计框架”。

问：它的应用接口是什么样的？

答：ClickHouse 的应用接口（API）设计非常灵活，主要面向数据分析和高吞吐写入场景。它不像传统的 Web 框架那样提供复杂的业务逻辑 API，而是提供了多种协议和客户端库，让应用程序能够高效地执行 SQL 查询和导入数据。

以下是 ClickHouse 主要的几种应用接口形式：

1. HTTP 接口 (最通用、最常用)

这是 ClickHouse 最核心的接口，几乎所有官方客户端和第三方工具底层都基于此。

• 特点：无状态、简单、支持流式传输。
• 使用方式：直接发送 HTTP POST 或 GET 请求，将 SQL 语句作为参数或请求体发送。
• 适用场景：跨语言调用、脚本集成、通过 curl 测试、自定义轻量级客户端。
• 示例：

  # 执行查询
  curl 'http://localhost:8123/?query=SELECT%20count()%20FROM%20visits'
  
  # 插入数据 (通过管道)
  echo "1, 'user_a', '2026-03-25'" | curl 'http://localhost:8123/?query=INSERT%20INTO%20clicks%20FORMAT%20CSV' --data-binary @-
  

• 返回格式：默认是纯文本（TSV），但也支持 JSON, JSONCompact, XML, CSV 等多种格式（通过 FORMAT 子句指定）。

2. 原生 TCP 接口 (性能最高)

这是 ClickHouse 自有的二进制协议。

• 特点：比 HTTP 更快，压缩率更高，支持更复杂的功能（如异步插入、查询进度回调）。
• 使用方式：不建议直接手写二进制包，而是通过官方提供的各类语言客户端库来使用。
• 端口：默认 9000。

3. 多语言官方客户端库 (开发首选)

为了方便开发者，ClickHouse 官方维护了多种语言的客户端，它们封装了底层的 TCP 或 HTTP 协议，提供了类似 JDBC/ODBC 的体验。

• Java: clickhouse-jdbc (兼容 JDBC 标准，可配合 Hibernate, Spark, Flink 等使用) 或 clickhouse-client (原生高性能驱动)。
• Python: clickhouse-driver (原生 TCP) 或 clickhouse-connect (HTTP/SQLAlchemy 集成)。

  from clickhouse_driver import Client
  client = Client('localhost')
  result = client.execute('SELECT count() FROM clicks WHERE date = today()')
  

• Go: clickhouse-go (社区非常活跃，支持 database/sql 接口)。
• Node.js: @clickhouse/client。
• C++: 官方提供的原生 C++ 客户端库。
• PHP, Ruby, Perl, R, Rust 等均有官方或社区成熟驱动。

4. 标准协议兼容接口 (生态集成)

为了让现有的大数据生态工具能无缝连接，ClickHouse 提供了标准协议支持：

• MySQL 协议:
  • 你可以使用任何 MySQL 客户端（如 mysql 命令行, DBeaver, Navicat, Python pymysql）连接 ClickHouse。
  • 端口：默认 9004。
  • 注意：仅支持基本的 SQL 查询和部分写入，不支持 MySQL 特有的存储过程或复杂事务特性。
• PostgreSQL 协议:
  • 允许使用 PostgreSQL 客户端连接。
  • 端口：默认 9005。
• ODBC / JDBC:
  • 提供标准的驱动程序，用于连接 Tableau, PowerBI, Excel, Superset 等 BI 工具。

5. 数据导入接口 (针对高吞吐写入)

对于“点击统计”这种需要每秒写入数万甚至百万条数据的场景，ClickHouse 提供了特殊的写入接口模式：

• HTTP Stream Insert: 通过 HTTP POST 持续发送数据流（如上文的 curl 示例），这是最常用的批量导入方式。
• Kafka 引擎表: 这不是一个外部 API，而是一个内部机制。你在 ClickHouse 中建一张特殊的表，它直接“挂载”到 Kafka Topic 上，自动消费数据并写入主表。这是构建实时点击流系统的最推荐架构。
• File Table Engine: 直接查询本地文件系统中的文件（如 CSV, Parquet），像查数据库表一样查文件。

6. 管理与监控接口

• System 表: ClickHouse 将自身的元数据、运行状态、日志、慢查询记录等都暴露在以 system. 开头的表中。你可以通过标准 SQL 查询这些表来监控集群状态。

  SELECT * FROM system.clusters;
  SELECT * FROM system.query_log WHERE query_duration_ms > 1000;
  

• Prometheus Metrics: ClickHouse 内置了一个 HTTP 端点（默认 :9363），直接输出 Prometheus 格式的监控指标，方便接入 Grafana。

总结：在点击统计系统中如何使用？

如果你要构建一个点击统计系统，典型的接口调用流程是：

1. 数据采集层：前端/后端收集点击事件 -> 发送到 Kafka。
2. 数据入库层：ClickHouse 通过 Kafka 引擎表 (内部接口) 自动从 Kafka 拉取数据，无需编写额外的插入代码。
3. 数据查询层：
   • 后端服务 (Java/Go/Python)：使用 官方客户端库 (TCP/HTTP) 执行聚合查询（例如：“过去1小时每个广告的点击数”）。
   • 运营后台/大屏：使用 BI 工具 (通过 JDBC/MySQL 协议) 连接 ClickHouse 进行可视化展示。
   • 即时调试：运维人员使用 HTTP 接口 (curl) 或 MySQL 客户端 快速抽查数据。

核心优势：它的接口设计极度偏向SQL和流式数据，没有复杂的 ORM 映射或业务逻辑封装，这使得它在处理海量数据分析时非常轻量和高效。

兼容SQL的设计

可以看出来，它的设计兼容了SQL语法，其实它的核心接口就是SQL语句。

ClickHouse 的核心设计哲学就是：“一切皆 SQL”。

虽然它底层有复杂的列式存储、向量化执行引擎和分布式协议，但暴露给用户的唯一核心接口就是标准 SQL（及其扩展）。这与传统的 Key-Value 数据库（如 Redis）、文档数据库（如 MongoDB）或宽列数据库（如 HBase/Cassandra）有着本质的区别。

以下是这一设计理念的具体体现和优势：

1. 为什么“核心接口是 SQL”如此重要？

• 零学习成本（对于分析师/开发）： 任何会写 SELECT, GROUP BY, JOIN 的人，上手 ClickHouse 几乎不需要学习新语言。你不需要学习特定的 API 调用方法（比如 db.get('key') 或 collection.find({...})），只需要写 SQL。
• 生态无缝集成： 因为它是 SQL，所以整个大数据和 BI 生态都能直接用它：
  • BI 工具：Tableau, PowerBI, Superset, Metabase 直接通过 JDBC/ODBC 连接就能画图。
  • 数据处理：Spark, Flink, Airflow 可以直接通过 SQL 读写 ClickHouse。
  • ORM 框架：Java 的 Hibernate, Python 的 SQLAlchemy, Go 的 Gorm 都能直接支持。
• 声明式编程： 你只需要告诉数据库“我要什么数据”（例如：SELECT count() FROM clicks WHERE date = today()），而不需要告诉它“怎么去找数据”（不需要写循环、索引扫描逻辑）。ClickHouse 的优化器会自动决定如何利用跳过索引、数据分片并行计算等底层特性。

2. 不仅仅是“标准 SQL”，而是“超级 SQL”

虽然核心是 SQL，但为了适应海量数据分析和实时性，ClickHouse 对 SQL 进行了大量的扩展。这些扩展是其高性能的关键，也是它区别于 MySQL/PostgreSQL 的地方：

A. 特有的函数库 (Functions)

ClickHouse 内置了数百个针对分析场景优化的函数，这是普通 SQL 数据库没有的：

• 数组操作：arrayJoin, hasAny, groupArray（直接在 SQL 里处理数组，无需代码层循环）。
• 时间序列处理：toStartOfHour, timeSeriesGroupSum（专门用于监控和趋势分析）。
• 状态聚合函数：uniqState, quantileTiming（用于计算去重数和分位数，支持跨分片合并状态）。
• 地理信息：内置高效的 GeoHash 和坐标计算函数。

B. 特有的表引擎语法 (Table Engines)

在 ClickHouse 中，建表语句 (CREATE TABLE) 必须指定 Engine，这是其架构的核心：

-- 这里的 "MergeTree" 就是核心配置，决定了数据如何存储、排序和合并
CREATE TABLE clicks (
    user_id UInt64,
    event_time DateTime,
    url String
) ENGINE = MergeTree()
ORDER BY (event_time, user_id); 

这种通过 SQL 语法直接控制底层存储策略（如倒序存储、数据采样、TTL 自动过期）的能力，是其他数据库很少见的。

C. 物化视图 (Materialized Views)

ClickHouse 的物化视图不仅仅是缓存，它是一个触发器。当你向源表插入数据时，物化视图会自动执行预定义的 SQL 查询并将结果写入另一张表。

• 应用场景：在写入阶段就完成“点击统计”的预聚合，查询时直接查聚合表，速度提升几个数量级。
• 语法：完全是 SQL 定义的。

  CREATE MATERIALIZED VIEW mv_daily_clicks TO daily_stats AS
  SELECT toDate(event_time) as day, count() as total_clicks
  FROM clicks
  GROUP BY day;
  

3. 与其他类型数据库的对比

| 特性 | ClickHouse | Redis / KV 存储 | MongoDB / 文档库 | Elasticsearch | | :--- | :--- | :--- | :--- :--- | | 核心接口 | SQL | 专用命令 (GET, SET) | JSON Query API | RESTful JSON DSL | | 主要用途 | 复杂分析、聚合统计 | 缓存、简单读写 | 灵活文档存储 | 全文检索、日志分析 | | 学习曲线 | 低 (懂 SQL 即可) | 中 (需记特定命令) | 中 (需记特定语法) | 高 (DSL 较复杂) | | 灵活性 | 高 (任意维度组合查询) | 低 (通常只能按 Key 查) | 高 | 中 (擅长文本，弱于数值聚合) |

4. 总结：对于“点击统计”意味着什么？

既然核心接口是 SQL，构建点击统计系统就变得异常简单和直观：

1. 定义模型：用 CREATE TABLE 定义点击流结构。
2. 定义聚合：用 CREATE MATERIALIZED VIEW 写好“按小时统计”、“按广告位统计”的 SQL。
3. 写入数据：程序只需执行 INSERT INTO ... VALUES ... (或者通过 Kafka 自动插入)。
4. 获取报表：后端代码只需执行 SELECT ... GROUP BY ...。

结论： ClickHouse 本质上就是一个将极致的性能封装在标准 SQL 接口之下的分析型数据库。它让开发者可以用最通用、最简单的语言（SQL），去解决最困难的大规模数据统计问题。这也是它能迅速取代许多定制化统计框架的原因。

没有事务的MySQL

问：那它能兼容当数据库用吗？它没有事务吧?

这是一个非常关键的问题。简短的回答是：

1. 它能当数据库用吗？

   • 能，但只能作为分析型数据库 (OLAP) 使用。
   • 不能作为业务交易型数据库 (OLTP) 使用（即不能替代 MySQL、PostgreSQL 来支撑你的核心业务系统，如用户注册、订单支付、库存扣减等）。

2. 它没有事务吧？

   • 基本正确。它不支持传统关系型数据库那种完整的 ACID 事务（特别是原子性、隔离性和多语句事务块）。
   • 它只支持单条语句的原子性（要么整条语句成功，要么整条语句失败），但不支持跨多条语句的 BEGIN ... COMMIT 事务块，也不支持行级锁和回滚（Rollback）。

---

详细解析：为什么不能把它当成“通用数据库”？

1. 事务能力的缺失 (The Lack of Transactions)

这是 ClickHouse 与 MySQL/PostgreSQL 最大的区别。

• 没有多语句事务： 你无法执行以下操作：

  BEGIN;
  UPDATE accounts SET balance = balance - 100 WHERE id = 1;
  UPDATE accounts SET balance = balance + 100 WHERE id = 2;
  -- 如果这里报错，上面两条语句无法自动回滚
  COMMIT;
  

  在 ClickHouse 中，BEGIN 和 COMMIT 是被忽略或不支持的。每条 INSERT、UPDATE、DELETE 都是独立执行的。

• 没有行级锁 (Row-Level Locking)： ClickHouse 是为高并发读取和高吞吐写入设计的，而不是为高并发更新设计的。它不使用行锁来保证隔离性。如果你尝试同时修改同一行数据，结果可能是不可预测的（通常后写入的会覆盖先写入的，或者产生版本冲突，具体取决于引擎配置）。

• 不支持回滚 (No Rollback)： 一旦一条 INSERT 语句执行完成，数据就持久化了（经过后台合并后）。你无法像在传统数据库中那样因为后续步骤失败而“撤销”这条插入。

• 更新的代价极高： ClickHouse 的底层存储结构（MergeTree）是针对追加写 (Append-Only) 优化的。

  • INSERT：非常快。
  • UPDATE / DELETE：非常慢。它们实际上是“标记删除”或“重写数据部分”，会触发沉重的后台合并过程。严禁在 ClickHouse 中频繁执行单行更新操作。

2. 适用场景对比：OLAP vs OLTP

特性	ClickHouse (OLAP)	MySQL/PostgreSQL (OLTP)
核心用途	数据分析、报表、日志统计	业务交易、用户状态、订单管理
写入模式	批量写入、流式追加 (高吞吐)	单行随机写入、频繁更新
读取模式	扫描大量数据、复杂聚合查询	根据主键/索引快速查找单条记录
事务支持	无 (仅单语句原子性)	完整 ACID 支持
数据一致性	最终一致性 (数据写入后需短暂时间合并可见)	强一致性 (实时可见)
典型操作	SELECT count(*) FROM logs WHERE ...	SELECT * FROM users WHERE id = 123
能否做主库	不能 (会导致数据不一致或性能崩塌)	能

3. 那么，它在架构中扮演什么角色？

在现代数据架构中，ClickHouse 通常作为从库或专用分析库存在，与事务型数据库配合使用：

• 架构模式：
  1. 业务层 (OLTP)：用户下单、点击、注册等操作，首先写入 MySQL/PostgreSQL (保证事务安全和数据强一致)。
  2. 同步层 (CDC/ETL)：通过 Canal, Debezium, Flink CDC 等工具，实时捕获 MySQL 的变更日志 (Binlog)。
  3. 分析层 (OLAP)：将数据同步流入 ClickHouse。
  4. 查询层：
     • “我的订单状态是什么？” -> 查 MySQL。
     • “过去一小时全平台的订单总额是多少？” -> 查 ClickHouse。

4. 特殊情况：它有哪些“类事务”特性？

虽然不支持标准事务，但 ClickHouse 提供了一些机制来保证数据的可靠性：

• 单语句原子性：INSERT INTO table VALUES (...), (...), (...) 这一条语句中的所有行，要么全部写入成功，要么全部失败。不会出现写了一半的情况。
• 幂等性设计：在设计数据模型时，通常通过 ReplacingMergeTree 引擎配合唯一的业务主键，来解决数据重复插入的问题（在后台合并时去重），这在一定程度上模拟了“更新”的效果，但不是实时的。
• 轻量级删除：可以使用 ALTER TABLE ... DELETE WHERE ...，但这依然是异步的重操作，不适合高频调用。

总结建议

• 如果你想做一个“点击统计系统”：ClickHouse 是完美的选择。因为点击数据通常是“只写一次，多次读取分析”，不需要更新，也不需要事务回滚。
• 如果你想做一个“电商交易系统”或“银行账本”：绝对不要只用 ClickHouse。你必须使用 MySQL 或 PostgreSQL 来处理核心交易逻辑，然后将数据同步到 ClickHouse 做报表分析。

一句话结论：ClickHouse 是一个强大的分析引擎，但不是一个通用的业务数据库。它用放弃事务能力（ACID）的代价，换来了极致的查询速度和海量数据处理能力。

补丁

关于事务（更新版）

• 基本正确。它不支持传统关系型数据库那种完整的 ACID 事务。
• 最新进展：截至 2026 年，ClickHouse 正在实验性支持有限的单机事务功能，但生产环境仍不建议依赖事务特性。
• 它只支持单条语句的原子性，但不支持跨多条语句的 BEGIN ... COMMIT 事务块。

HTTP 接口

• 端口：默认 8123
• 注意：官方 JDBC 驱动默认使用此端口（没错，官方支持的jdbc协议实现使用http协议），而原生 TCP 驱动使用 9000 端口