clickhouse 实时数据更新方案求助

[KJH]

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

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

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

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

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

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

之前考虑个几种方案

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

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

在此拜谢

[hongye]

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

[skymei]

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

[KJH]

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

[KJH]

@skymei 我看看

[hongye]

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

[KJH]

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

[ranxy]

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

[suixn]

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

[xiaolongorigino]

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

[Desdemor]

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

[KJH]

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

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

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

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

[jon202107]

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

[JRay]

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

[vacuitym]

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

[glacer]

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

[NotLongNil]

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

[KJH]

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


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

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

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

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

[v2day]

看场景有 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]

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

[nedqqcc]

doris 或者试试 pinot ，目前在用 pinot
之前调研过，胆子大的话可以看看 time-plus ，就是一套 realtime db+clickhouse