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

[ppppppp123]

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

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

每天大概 10 万单数据

[BBCCBB]

flink?

[hpu423]

flink+clickhouse

[Jface]

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

[corcre]

前端选型吗? power bi?

[ppppppp123]

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

[ppppppp123]

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

[1996wang]

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

[FYFX]

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

[ppppppp123]

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

[Morii]

flink + Click house 的 累计计算引擎

话说订单量多大啊

[ppppppp123]

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

[sss15]

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

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

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

[OpenSea]

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

[SilenceLL]

flink cdc + doris

[lry]

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

[xieren58]

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

[datoujiejie221]

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

[ppppppp123]

@Morii @sss15 @xieren58 @datoujiejie221 @SilenceLL
每天 10w 单数据

[bjfane]

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

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

[liprais]

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

[ppppppp123]

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

[ppppppp123]

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

[hexpop]

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

[ppppppp123]

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

[jamosLi]

@ppppppp123 21 再塞 es ？

[VincentYe123]

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

[Morii]

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

[securityCoding]

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

[zeonll]

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

[ppppppp123]

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

[ppppppp123]

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

[XyIsMy]

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

[XyIsMy]

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

[MaxFang]

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

[iwdmb]

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

[b1ghawk]

我想先 mark 一下

[dashan333]

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

[yibo2018]

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

[OpenSea]

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

[ppppppp123]

@OpenSea 后面是怎么改进的？

[ppppppp123]

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

[Xusually]

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

[OpenSea]

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

[OpenSea]

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

[BQsummer]

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

[goodryb]

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

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

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

[1996wang]

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

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

[NoString]

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

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

[shinession]

插个眼, flink 第一次听说, 了解先

[securityCoding]

@ppppppp123 汇总一张宽表，管理员看板没啥并发 ck 随便查的

[zoharSoul]

对内 flink/ clickhouse

对外 es

[shenqi]

有没有考虑 mysql -> hive +kylin -> superset 一条龙梭哈，都不用怎么写代码，只写 sql 和模型。

但是没那么实时，当然这点数据量，做成实时同时压力不大，模型计算你都实时了，kylin 也会没啥压力。

[jeesk]

10w ,java stream 都能搞.

[aw2350]

如果每天 10w 的数据，写 sum 窗口函数 group by 之类的查询，单日的数据查询结果应该永不了 3s 吧？或者在业务层面 分库分表，每个业务大类一个库，那样子压力就更小了

[aw2350]

对了，还不能因为看板的查询操作阻塞主业务的进行，上主从吧，看板的查询数据走从库，减轻主库的压力

[netnr]

我会使用中间表 一张按天汇总 一张按小时汇总(只存储当天)，根据具体情况还可以加按月 年汇总的中间表

每个小时跑一次汇总任务

查询根据时间段拆分查询

也就是空间换时间

[akira]

直接 mysql sum 一把梭， 有 性能问题 先考虑 sql 优化 次之升级 mysql ，最后才是考虑上别的东西

[acerphoenix]

业务上没必要考虑并发，这种数据才几个能人看？
这点数据量，设计方向是简单成本低，别想啥响应啊性能啊，没必要；实时只是相对每天一统计而言。
但是为了保证线上业务，不能用生产库直接搞，太无脑了，怎么也得同步出一份数据来，我们直接直接 java 内存数据库跑都挺好，也不用持久化，计算灵活方便。

[Pantheoon]

这种数据量用不上 flink,场景是 olap,查询语句固定就那些,没有并发,es,clickhouse,配置高点的 mysql 都比较合适