订单数据实时汇总技术选型

ppppppp123 · 17 小时 32 分钟前 · 3202 次点击

公司正在开发订单数据看板，要求对数个月或者单天的订单数据按照单店面和多店面维度进行汇总展示，另外还要根据上面时间和店面两个维度汇总展示这些订单里面最受欢迎的商品信息（每个订单对应一个商品），近乎实时汇总，求大神推荐此类场景的实现技术，有代码或者教程的更佳。

第 1 条附言 · 16 小时 25 分钟前

补充一下，原始的数据都是存储在 mysql 里面的。

第 2 条附言 · 15 小时 20 分钟前

每天大概 10 万单数据

58 条回复 • 2023-02-02 23:26:45 +08:00

BBCCBB 17 小时 28 分钟前

flink?

hpu423 17 小时 27 分钟前

flink+clickhouse

Jface 17 小时 26 分钟前 via iPhone

对性能跟实时性有要求就 flink
没有要求用 spark 做实时也行

corcre 17 小时 25 分钟前

前端选型吗? power bi?

ppppppp123 17 小时 24 分钟前

@corcre 前后端都做的，前端是一个 vue admin board 类似的。后端需要自己实现。

ppppppp123 17 小时 23 分钟前

@BBCCBB @hpu423 @Jface 谢谢三位亲，如果有开源的例子就好了。

1996wang 17 小时 10 分钟前

flink + doris + 帆软 bi 看板.
简单可拓展性强.后面做下数据分层就是个数仓了

FYFX 17 小时 7 分钟前

我觉得你应该先说一下你们的开发资源，还有数据的量级，毕竟要上大数据的话维护的成本还是挺高的

ppppppp123 16 小时 42 分钟前

@FYFX 后面我再回复你，你的 comment 非常有价值。
@1996wang 非常谢谢！

Morii 16 小时 34 分钟前

flink + Click house 的累计计算引擎

话说订单量多大啊

ppppppp123 16 小时 24 分钟前

@Morii flink 和 ck 各自的作用是什么？公司所有的订单数据都是存储在 mysql 里的，我在担心实时性的问题。

sss15 16 小时 12 分钟前

你不说数据量，没办法技术选型啊，如果一天就几百单，直接 mysql 里 sum 就行了何必上组件。

淘宝的双 11 的实时订单统计，各排行榜都是用 flink 做的，所以楼上那么多推荐 flink 的。

flink 可以去 b 站看视频，硅上谷的视频做的不错，版本也新
https://www.bilibili.com/video/BV133411s7Sa/?spm_id_from=333.337.search-card.all.click

OpenSea 16 小时 7 分钟前

clickhouse 做实时的并发会成瓶颈吧

SilenceLL 16 小时 3 分钟前

flink cdc + doris

lry 15 小时 49 分钟前

手动打点，数据写入到 InfluxDB / Prometheus, 再配置 Grafana 面板。

xieren58 15 小时 47 分钟前

看数据量, 数据量少的话, 简单搞个定时任务就行啦.

datoujiejie221 15 小时 44 分钟前

canal 监控 mysql 的订单数据扔到 kafka
消费 kafka 的数据做实时计算，每日的结果落库，数据量大的话考虑用 flink

bjfane 15 小时 15 分钟前

确实，是场景不是很清楚，不过既然 mysql 能放的下说明应该不会巨大，没有人说 mysql 从库 sql 一把梭么？
一把梭不了，就从库定时执行缓存一下。

上 flink 是不是有点过分了。。。

liprais 15 小时 11 分钟前

十万单 mysql 搞个从库随便玩了

ppppppp123 15 小时 10 分钟前

@bjfane 选个 3 个月区间的查询就要汇总 100w 条订单数据，mysql 是不是吃不消了。

ppppppp123 15 小时 9 分钟前

@liprais 可以选一个时间区间，比如 3 个月进行汇总和取 top 。

hexpop 15 小时 9 分钟前

100W 也很轻松啊，千万级别的我都 MySQL 一把梭

ppppppp123 15 小时 7 分钟前

@hexpop 厉害！它这个需求要及时反馈，界面上点击查询就要出结果，时间上能不能保证啊？

jamosLi 15 小时 0 分钟前

@ppppppp123 21 再塞 es ？

VincentYe123 14 小时 52 分钟前

订阅 mysql 消息，扔队列实时计算结果落库

Morii 14 小时 44 分钟前

@ppppppp123 #11 流处理 + OLAP 数据库

securityCoding 14 小时 43 分钟前

这点数据 flink 过分了，汇总到 clickhouse 随便查

zeonll 14 小时 37 分钟前

这点数据量，没必要建仓了，你甚至可以 canal + mysql

ppppppp123 14 小时 22 分钟前

@zeonll cannal 和 mysql 我看了下耦合蛮紧的
@securityCoding 感觉你这个方案可以！直接用 clickhouse 作为 mysql 的备份库，然后利用 ck 来汇总查询

ppppppp123 14 小时 20 分钟前

@securityCoding 上面 @OpenSea 说 ck 不适合实时的并发，这个是管理员端的数据看板，其实并发不太大。不知道 ck 可以近乎实时不？

XyIsMy 13 小时 35 分钟前

@ppppppp123
如果大表各种 join 实时查询，ck 会弱些。如果数据已经进行了预聚合，单表查询，ck 查询还是可以的。
至于并发，你可以预估下，并发多少，低于 100 且没有大聚合查询，问题不大
数据延迟问题，这个避免不了，数据同步本来就存在延迟，而且需要看同步的策略。例如：内网环境，canal 1 秒同步一次，理论延迟会在 2 秒内。业务方接受 2 秒的延迟，那就没问题了

XyIsMy 13 小时 32 分钟前

@ppppppp123 如果不想折腾。直接用 mysql 也可以。把数据进行一层预处理就好。写个脚本，清洗统计数据，存到数据表内，直接查统计表数据即可

MaxFang 13 小时 30 分钟前

这个级别的数据量应该可以直接 mysql 查出来吧，近乎实时也可以做脚本每分钟汇总一次。
并且看目前要统计的需求，都是可以做到增量更新的吧。之前的数据归档存储+部分更新。

iwdmb 13 小时 25 分钟前

每天 10 万单用不到 Flink 吧 ...
100000/(12*60)=138
用业务时段去估每分钟也才 138 张单

b1ghawk 13 小时 19 分钟前 via Android

我想先 mark 一下

dashan333 12 小时 40 分钟前

监控 MySQL binlog , 使用工具同步到 clickhouse 。这个数据量，不用预聚合，不用使用 ck 的 summing ，直接 merge ，筛选条件都可以自定义

yibo2018 12 小时 37 分钟前

如果条件允许的话，其实可以玩玩 flink 的

OpenSea 12 小时 22 分钟前

@ppppppp123 我们遇到的场景，购买的某云低配 ck ，列表显示聚合订单实时数据，并发到 100 就撑不住了。最后优化掉了 ck

ppppppp123 12 小时 21 分钟前

@OpenSea 后面是怎么改进的？

ppppppp123 12 小时 20 分钟前

复杂的场景怕到时候坑多，越简单处理越好。

Xusually 12 小时 19 分钟前 via iPhone

就这数据量 mysql 搞个从库专门查就行了，复杂组件都不用上

OpenSea 12 小时 17 分钟前

@ppppppp123 大概流程是监听 binlog ，每日初始化后做增量计算，结果存储到 redis 读取。我们展示的数据有数仓计算的历史数据和业务操作的实时数据。我们有个前提是 ck 费用不低但是满足不了要求（可能业务结合的不好）

OpenSea 12 小时 14 分钟前

@OpenSea 最终结果是去掉了 ck ，同时成本不增反降，响应时间用了缓存也提高了不少

BQsummer 12 小时 11 分钟前

doris, 同步可以用 flink cdc / canal / 自己写也行

goodryb 12 小时 2 分钟前

业务场景还是要定义清楚，是 BI 报表，还是聚合查询

报表类业务通常都是 T+1 处理，结果数据单独存放，每次请求直接查结果数据；如果是实时报表，那就得上实时计算

如果是聚合查询，那这个就看量大小了，不复杂的话通过数据库也行，如果规模较大就得上数仓

1996wang 11 小时 22 分钟前

可以看看 doris 的外表功能: https://doris.apache.org/zh-CN/docs/dev/lakehouse/external-table/jdbc?_highlight=mysql#mysql

好处是不用考虑数据导入的事情,近实时应该没问题.
导入的话就用 flink-cdc.
对比 ck,单机性能没有 ck 强.但是运维简单,文档中文.
还有个优点,doris 可以直接对接很多 bi 看板(当作 mysql),后面看板开发就很省功夫.

NoString 10 小时 54 分钟前

clickhouse 巨吃配置，并发的场景并不理想，每日 10w 单，三个月千万的数据，mysql 应该就能抗，针对这个需求要毫秒级响应就上 Redis 维护一份 Topk 的数据，一个 Redis 维护几十万店面的各种数据 key 下来成本还是很低的。

但是如果要做各种复杂纬度的看板，还是老老实实建数仓，Clickhouse ，Doris 都可以，考虑聚合场景多机器预算高就 Clickhouse ，报表中间加层 Redis 缓存，实时并发性能也不会差（具体可以参考腾讯音乐的方案，之前在 CK 的分享上他们就是这种模式）