各位大佬架构师们，紧急求助
我们有个报表类的需求，目前架构设计如下
数据量：1TB 左右
数据流转流程
业务数据->（ kafka 、flink ）->数据仓库（ MySQL)->通过 ETL 抽取->Clickhouse->报表呈现
由于我们报表对实时性要求比较高，而且在生成报表的时候涉及到的表多、逻辑也复杂，不得已我们将数据仓库的数据原封不动的同步到了 clickhouse ，后面在进行报表生成计算的时候，全部查 clickhouse 的数据最后生成大宽表。
我知道 clickhouse 是列式存储，对数据得删除和更新都是重量级操作，而我们的数据都是业务数据，更新比较频繁，所以我们采用了先删后插的策略，alter table delete (同步删非异步）。
这就导致我们的数据更新周期最低也要 1 个小时
之前考虑个几种方案

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

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

谢谢各位架构师大佬

总结一下

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

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

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

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

再次拜谢各位大佬

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

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

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

我看看

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   我有个跟你类似的需求，用的是 Starrocks ，sr 使用聚合索引表，需要经常更新的值设置成 replace 聚合，每次新插入就更新了。

目前 4T+数据

StarRocks 感觉使用场景很多啊，用过的人都说好。。

doris 或 starrocks ，这俩本质上差不多，没有二次开发能力不要碰 clickhouse

好的，目前在尝试 doris

云服务商不支持 starrocks [捂脸] 只能考试 doris 了

＃17 如果使用轻量删除，控制好时间和每次删除的数量，性能还是很可观的

我数据量还很少，买的阿里云的 selectdb ，也就是 doris ，自己布了个 Apache SeaTunnel 在同步数据，希望你们多用用帮我多踩踩坑

ok 我们也考虑试试 ，谢谢

你的 doris 是哪个版本呀

如果必须是 Ck 我可以提供一个思路，就是分区 REPLACE ，每次更新就建一个复制表 写入之后就 REPLACE 分区，这样基本都是平滑且是 O1 ，然后更新频次就看写入速度了

可以小小参考一下： kelovp.tech/nostring/blog/1712/

selectdb 内核版本 4.0.4 。合入了 Apache Doris v3.0.3 版本的所有功能、改进优化和问题修复。

同碰到这个问题,但使用 final 跟用 mysql 差别也不太(指性能很慢). 用 argmax 有拿不准的时候, 最后用了阿里的 ADB.

doris 和 sr 已经开始有功能上的差异了,更推荐 doris.
比如加列,doris 快速加列功能很好用.而 sr 加列很慢
如果是阿里云,推荐阿里云的 hologres

hologres 不错。