V2EX › KJH 的所有回复 › 第 9 页 / 共 17 页

V2EX = way to explore

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

For Existing Member Sign In

1 2 3 4 5 6 7 8 9 10 ... 17

❮

❯

2025 年 4 月 9 日

回复了 KJH 创建的主题 › 程序员 › clickhouse 实时数据更新方案求助

@haimianbihdata 感觉这个方法可以哦，我尝试尝试，感谢感谢，

2025 年 4 月 8 日

回复了 KJH 创建的主题 › 程序员 › clickhouse 实时数据更新方案求助

@NoString 是有考虑过轻量级删除，但是后面想要长久的稳定运行，总觉得不是最终方案，可以作为临时方案过度一下，我们也考虑考虑

@bitmin 那还挺新的

@ForMrFang 阿里可选择的东西确实比较多

@1996wang 哈哈正在写方案了，后面就测试下性能

@ChenKeLiang 我了解下

@haimianbihdata 我们 flink 只对接了数据仓库，想要再对接其他的涉及到服务器成本和开发成本，现在都在降本增效 T.T

2025 年 4 月 7 日

回复了 KJH 创建的主题 › 程序员 › clickhouse 实时数据更新方案求助

@NotLongNil ok 我们也考虑试试，谢谢

@bitmin 你的 doris 是哪个版本呀

2025 年 4 月 7 日

回复了 KJH 创建的主题 › 程序员 › clickhouse 实时数据更新方案求助

@nedqqcc @yh7gdiaYW 好的，目前在尝试 doris

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

2025 年 4 月 7 日

回复了 KJH 创建的主题 › 程序员 › clickhouse 实时数据更新方案求助

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

2025 年 4 月 7 日

回复了 KJH 创建的主题 › 程序员 › clickhouse 实时数据更新方案求助

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

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

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

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

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

2025 年 4 月 7 日

回复了 KJH 创建的主题 › 程序员 › clickhouse 实时数据更新方案求助

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

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

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

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

2025 年 4 月 7 日

回复了 KJH 创建的主题 › 程序员 › clickhouse 实时数据更新方案求助

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

2025 年 4 月 7 日

回复了 KJH 创建的主题 › 程序员 › clickhouse 实时数据更新方案求助

@skymei 我看看

2025 年 4 月 7 日

回复了 KJH 创建的主题 › 程序员 › clickhouse 实时数据更新方案求助

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

2025 年 3 月 31 日

回复了 ybby 创建的主题 › 情感问题 › 情感问题紧急求助！

@vanityfairn #47 以后就是 op 一个人养他们一家子