clickhouse 实时数据更新方案求助

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

各位大佬架构师们，紧急求助

我们有个报表类的需求，目前架构设计如下

数据量：1TB 左右数据流转流程业务数据->（ kafka 、flink ）->数据仓库（ MySQL)->通过 ETL 抽取->Clickhouse->报表呈现

由于我们报表对实时性要求比较高，而且在生成报表的时候涉及到的表多、逻辑也复杂，不得已我们将数据仓库的数据原封不动的同步到了 clickhouse ，后面在进行报表生成计算的时候，全部查 clickhouse 的数据最后生成大宽表。

我知道 clickhouse 是列式存储，对数据得删除和更新都是重量级操作，而我们的数据都是业务数据，更新比较频繁，所以我们采用了先删后插的策略，alter table delete (同步删非异步）。

这就导致我们的数据更新周期最低也要 1 个小时

之前考虑个几种方案

使用 ReplacingMergeTree 引擎，只追加数据，不删除，然后查询通过 final 或这 argMax 取最新数据，但是这有两个问题，一：final 没办法进行表关联查询，二：argMax 对我们改动太大太大，表字段页表字段也比非常多（ 100+)
对于实时性要求高的报表不再去查 clickhouse ，直接查数据仓库

我比较中意第二种，因为我是在想不出更好的方案了，想请教下各位架构师们有没有比较好的方案

在此拜谢

第 1 条附言 · 20 小时 35 分钟前

谢谢各位架构师大佬

总结一下

clickhouse 不是和数据频繁更新的场景，所以针对我的这个场景需求，就不用再去折腾 clickhouse ，无论是表分区还是更改表引擎，终究满足不了实时或接近实时的效果。如果是那种日志、埋点类的数据使用 clickhouse 还是非常不错的

针对数据频繁更新的场景，大佬们推荐使用 doris 和 starrocks

我也简单的了解了下，这两个库确实对数据频繁更新的场景比较友好，而且我只需要设置主键，然后不断的往里插数据就行了，还不用写 update 语句，很符合我们的业务场景。

接下来我尝试测试 doris 库，没问题就正常应用了。

再次拜谢各位大佬

clickhouse

ReplacingMergeTree

实时性

34 条回复 • 2025-04-08 07:54:14 +08:00

hongye

1 天前

可以看下物化视图是不是能够解决，我们当时是通过物化视图生成聚合表。

skymei

1 天前

最近再调研数据库，原先也准备用 clickhouse ，后面发现 doris 更适合，数据更新上支持也更好

KJH

1 天前

@hongye 之前了解过物化视图，只能监听到源表新增的数据，如果数据变更是不会触发物化视图的，不太适合我们的场景 T.T

KJH

1 天前

@skymei 我看看

hongye

1 天前

@KJH #3 如果实时性要求没那么高，可以手动触发

KJH

1 天前

@hongye 我们对实时性要求很高，想数据发生变化后立刻就能看到报表的变化，最少也得 5-10 分，但这个数据量要同步更新到 clickhouse 以及跑宽表，这么短时间确实不太好做到

ranxy

1 天前 via iPhone

1T 数据不多啊，可以试试把 mysql-etl-clickhouse 换成 tidb+tiflash 看看？

suixn

1 天前

换 starrocks 或者 doris, clickhouse 不适合这个场景

xiaolongorigino

1 天前

简单，打宽放到计算引擎去做，状态过大就把维表数据放 Hbase ，CK 提供对外查询。这点数据，优化都不用做，建好主键随便查

Desdemor

1 天前

我们是用 final 查出来然后在代码里处理的，clickhouse 并发好像不太行的

KJH

1 天前

@ranxy 我们比较依赖云服务商，他们没 tidb 这个产品 [捂脸]

@suixn 好，刚刚有位大佬也让我看了看 doris ，我看了下这两个确实比较适合数据频繁更新的场景，我再深入研究研究

@xiaolongorigino 宽表确实是在计算引擎中生成的，报表查询的时候通过 ck 查宽表，hbase 我了解下

@Desdemor 确实，我们更新的时候，并发一多，处理的任务就堆积下来了

jon202107

1 天前

数据加上版本号，再有一个地方记录最新的版本号，查询时带上版本号，这样感觉可行

JRay

1 天前

之前我们也遇到需要实时更新的，几种方案试过之后放弃了，换成了 doris

vacuitym

1 天前

有实时的建议不要用 ck ，或者每次查询用 final 做个强制同步（很占 cpu 和内存）

glacer

1 天前

跟我前司架构比较像（物联网行业）。我们当时的架构方案：
使用 VersionedCollapsingMergeTree ，可以在表数据只追加的情况下，通过查询取得最新状态的数据。然后定时 optimize 表就行。

NotLongNil

1 天前

ReplacingMergeTree 在查询时会降低性能，物化视图也有严重的性能问题。如果你们的 clickhouse 版本比较新，可以试试一个轻量删除（ https://clickhouse.com/docs/zh/guides/developer/lightweight-delete ）的特性。doris 的资源占用和性能，没有 clickhouse 那么优秀，相等的查询速度需要的资源至少是 clickhouse 的三四倍。没有万金油，如果你们的数据频繁更新其实不大适合 clickhouse

KJH

1 天前

@jon202107 这个方案我们也考虑过，查询的时候带版本号意味着也要做去重的那种操作，我们改动比较大，所以后面放弃了

@JRay 我上午了解了下，StarRocks 或者 doris 确实是比较合适的方案，我再深入研究研究

@vacuitym final 相当于合并了，而且没办法表关联查，后来我们就 pass 掉这个方案了

@glacer 通过查询指的还是 final 或者 argMax 这些近些处理吧

@NotLongNil 是的，有考虑个轻量级删除，不过还没实际测试，我想的是如果每 5 分钟删一次，会不会有其他潜在问题，后面我测试下

v2day

1 天前

看场景有 2 个问题，需要在新方案上注意下（之前遇见过
1. 实时性要求比较高，这是要从 1 小时缩短到小于 5 分钟么？
- 这个在上述提到的软件上都能搞；业务新鲜度延迟取决 op 提到的数仓时效性了
2. OLTP 数据 ETL 同步到 OLAP ，原文说更新比较频繁；这部分包含 add/drop/ 么？
- 如果只是 DML 的 insert / update / delete ，用 starrocks 这类 Primary key 这种表能实现原地更新和删除；目前公司环境很稳定； DDL 的话需要根据 case by case 设计了
3. ETL （同步、加工）
- 「数据源 / MySQL 」 --> Flink -- > StarRocks PK table ；直接 ods 1:1 复制到底层，方便做数据质量校验；避免业务组说 ETL 后数据对不上的现象
- 数仓加工（ dwd dws ）都在 starrocks 上跑；配合 bi 产品目前无计算压力（聚合/metrics ）

KJH

22 小时 50 分钟前

@v2day 看来只能是从 StarRocks 和 doris 这里面入手了，整体架构还得在调整下，但我们目前已经有了 MYSQL 做数据仓，不太可能替换为 StarRocks ,只能考虑数据仓到 StarRocks 这步。