V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
ppppppp123
V2EX  ›  程序员

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

  •  
  •   ppppppp123 · 2023-02-02 09:00:08 +08:00 · 5709 次点击
    这是一个创建于 439 天前的主题,其中的信息可能已经有所发展或是发生改变。
    公司正在开发订单数据看板,要求对数个月或者单天的订单数据按照单店面和多店面维度进行汇总展示,另外还要根据上面时间和店面两个维度汇总展示这些订单里面最受欢迎的商品信息(每个订单对应一个商品),近乎实时汇总,求大神推荐此类场景的实现技术,有代码或者教程的更佳。
    第 1 条附言  ·  2023-02-02 10:07:36 +08:00
    补充一下,原始的数据都是存储在 mysql 里面的。
    第 2 条附言  ·  2023-02-02 11:12:09 +08:00
    每天大概 10 万单数据
    59 条回复    2023-02-03 10:43:02 +08:00
    BBCCBB
        1
    BBCCBB  
       2023-02-02 09:04:36 +08:00
    flink?
    hpu423
        2
    hpu423  
       2023-02-02 09:05:16 +08:00
    flink+clickhouse
    Jface
        3
    Jface  
       2023-02-02 09:06:06 +08:00 via iPhone
    对性能跟实时性有要求就 flink
    没有要求用 spark 做实时也行
    corcre
        4
    corcre  
       2023-02-02 09:07:50 +08:00
    前端选型吗? power bi?
    ppppppp123
        5
    ppppppp123  
    OP
       2023-02-02 09:08:42 +08:00
    @corcre 前后端都做的,前端是一个 vue admin board 类似的。后端需要自己实现。
    ppppppp123
        6
    ppppppp123  
    OP
       2023-02-02 09:10:01 +08:00
    @BBCCBB @hpu423 @Jface 谢谢三位亲,如果有开源的例子就好了。
    1996wang
        7
    1996wang  
       2023-02-02 09:22:17 +08:00
    flink + doris + 帆软 bi 看板.
    简单可拓展性强.后面做下数据分层就是个数仓了
    FYFX
        8
    FYFX  
       2023-02-02 09:25:08 +08:00
    我觉得你应该先说一下你们的开发资源,还有数据的量级,毕竟要上大数据的话维护的成本还是挺高的
    ppppppp123
        9
    ppppppp123  
    OP
       2023-02-02 09:51:02 +08:00
    @FYFX 后面我再回复你,你的 comment 非常有价值。
    @1996wang 非常谢谢!
    Morii
        10
    Morii  
       2023-02-02 09:58:11 +08:00
    flink + Click house 的 累计计算引擎

    话说订单量多大啊
    ppppppp123
        11
    ppppppp123  
    OP
       2023-02-02 10:08:36 +08:00
    @Morii flink 和 ck 各自的作用是什么?公司所有的订单数据都是存储在 mysql 里的,我在担心实时性的问题。
    sss15
        12
    sss15  
       2023-02-02 10:20:32 +08:00
    你不说数据量,没办法技术选型啊,如果一天就几百单,直接 mysql 里 sum 就行了何必上组件。

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

    flink 可以去 b 站看视频,硅上谷的视频做的不错,版本也新
    https://www.bilibili.com/video/BV133411s7Sa/?spm_id_from=333.337.search-card.all.click
    OpenSea
        13
    OpenSea  
       2023-02-02 10:25:12 +08:00
    clickhouse 做实时的并发会成瓶颈吧
    SilenceLL
        14
    SilenceLL  
       2023-02-02 10:29:19 +08:00
    flink cdc + doris
    lry
        15
    lry  
       2023-02-02 10:43:49 +08:00
    手动打点,数据写入到 InfluxDB / Prometheus, 再配置 Grafana 面板。
    xieren58
        16
    xieren58  
       2023-02-02 10:45:47 +08:00
    看数据量, 数据量少的话, 简单搞个定时任务就行啦.
    datoujiejie221
        17
    datoujiejie221  
       2023-02-02 10:48:14 +08:00
    canal 监控 mysql 的订单数据扔到 kafka
    消费 kafka 的数据做实时计算,每日的结果落库,数据量大的话考虑用 flink
    ppppppp123
        18
    ppppppp123  
    OP
       2023-02-02 11:13:16 +08:00
    @Morii @sss15 @xieren58 @datoujiejie221 @SilenceLL
    每天 10w 单数据
    bjfane
        19
    bjfane  
       2023-02-02 11:17:05 +08:00
    确实,是场景不是很清楚,不过既然 mysql 能放的下 说明应该不会巨大, 没有人说 mysql 从库 sql 一把梭么?
    一把梭不了,就从库定时执行缓存一下。

    上 flink 是不是有点过分了。。。
    liprais
        20
    liprais  
       2023-02-02 11:21:13 +08:00
    十万单 mysql 搞个从库随便玩了
    ppppppp123
        21
    ppppppp123  
    OP
       2023-02-02 11:22:23 +08:00
    @bjfane 选个 3 个月区间的查询就要汇总 100w 条订单数据,mysql 是不是吃不消了。
    ppppppp123
        22
    ppppppp123  
    OP
       2023-02-02 11:24:00 +08:00
    @liprais 可以选一个时间区间,比如 3 个月进行汇总和取 top 。
    hexpop
        23
    hexpop  
       2023-02-02 11:24:02 +08:00
    100W 也很轻松啊,千万级别的我都 MySQL 一把梭
    ppppppp123
        24
    ppppppp123  
    OP
       2023-02-02 11:25:58 +08:00
    @hexpop 厉害!它这个需求要及时反馈,界面上点击查询就要出结果,时间上能不能保证啊?
    jamosLi
        25
    jamosLi  
       2023-02-02 11:32:41 +08:00
    @ppppppp123 21 再塞 es ?
    VincentYe123
        26
    VincentYe123  
       2023-02-02 11:41:01 +08:00
    订阅 mysql 消息,扔队列实时计算结果落库
    Morii
        27
    Morii  
       2023-02-02 11:48:54 +08:00
    @ppppppp123 #11 流处理 + OLAP 数据库
    securityCoding
        28
    securityCoding  
       2023-02-02 11:49:23 +08:00
    这点数据 flink 过分了,汇总到 clickhouse 随便查
    zeonll
        29
    zeonll  
       2023-02-02 11:55:14 +08:00
    这点数据量,没必要建仓了,你甚至可以 canal + mysql
    ppppppp123
        30
    ppppppp123  
    OP
       2023-02-02 12:10:57 +08:00
    @zeonll cannal 和 mysql 我看了下耦合蛮紧的
    @securityCoding 感觉你这个方案可以!直接用 clickhouse 作为 mysql 的备份库,然后利用 ck 来汇总查询
    ppppppp123
        31
    ppppppp123  
    OP
       2023-02-02 12:12:57 +08:00
    @securityCoding 上面 @OpenSea 说 ck 不适合实时的并发,这个是管理员端的数据看板,其实并发不太大。不知道 ck 可以近乎实时不?
    XyIsMy
        32
    XyIsMy  
       2023-02-02 12:57:28 +08:00
    @ppppppp123
    如果大表各种 join 实时查询,ck 会弱些。如果数据已经进行了预聚合,单表查询,ck 查询还是可以的。
    至于并发,你可以预估下,并发多少,低于 100 且没有 大聚合查询,问题不大
    数据延迟问题,这个避免不了,数据同步本来就存在延迟,而且需要看同步的策略。例如:内网环境,canal 1 秒同步一次,理论延迟会在 2 秒内。业务方接受 2 秒的延迟,那就没问题了
    XyIsMy
        33
    XyIsMy  
       2023-02-02 13:00:44 +08:00
    @ppppppp123 如果不想折腾。直接用 mysql 也可以。把数据进行一层预处理就好。写个脚本,清洗统计数据,存到数据表内,直接查 统计表 数据即可
    MaxFang
        34
    MaxFang  
       2023-02-02 13:02:27 +08:00
    这个级别的数据量应该可以直接 mysql 查出来吧,近乎实时也可以做脚本每分钟汇总一次。
    并且看目前要统计的需求,都是可以做到增量更新的吧。之前的数据归档存储+部分更新。
    iwdmb
        35
    iwdmb  
       2023-02-02 13:07:50 +08:00
    每天 10 万单用不到 Flink 吧 ...
    100000/(12*60)=138
    用业务时段去估每分钟也才 138 张单
    b1ghawk
        36
    b1ghawk  
       2023-02-02 13:13:33 +08:00 via Android
    我想先 mark 一下
    dashan333
        37
    dashan333  
       2023-02-02 13:52:09 +08:00
    监控 MySQL binlog , 使用工具同步到 clickhouse 。这个数据量,不用预聚合,不用使用 ck 的 summing ,直接 merge ,筛选条件都可以自定义
    yibo2018
        38
    yibo2018  
       2023-02-02 13:55:33 +08:00
    如果条件允许的话,其实可以玩玩 flink 的
    OpenSea
        39
    OpenSea  
       2023-02-02 14:10:43 +08:00
    @ppppppp123 我们遇到的场景,购买的某云低配 ck ,列表显示聚合订单实时数据,并发到 100 就撑不住了。最后优化掉了 ck
    ppppppp123
        40
    ppppppp123  
    OP
       2023-02-02 14:11:55 +08:00
    @OpenSea 后面是怎么改进的?
    ppppppp123
        41
    ppppppp123  
    OP
       2023-02-02 14:12:43 +08:00
    复杂的场景怕到时候坑多,越简单处理越好。
    Xusually
        42
    Xusually  
       2023-02-02 14:13:11 +08:00 via iPhone
    就这数据量 mysql 搞个从库专门查就行了,复杂组件都不用上
    OpenSea
        43
    OpenSea  
       2023-02-02 14:16:00 +08:00
    @ppppppp123 大概流程是监听 binlog ,每日初始化后做增量计算,结果存储到 redis 读取。我们展示的数据有数仓计算的历史数据和业务操作的实时数据。我们有个前提是 ck 费用不低但是满足不了要求(可能业务结合的不好)
    OpenSea
        44
    OpenSea  
       2023-02-02 14:18:48 +08:00
    @OpenSea 最终结果是去掉了 ck ,同时成本不增反降,响应时间用了缓存也提高了不少
    BQsummer
        45
    BQsummer  
       2023-02-02 14:21:30 +08:00
    doris, 同步可以用 flink cdc / canal / 自己写也行
    goodryb
        46
    goodryb  
       2023-02-02 14:30:12 +08:00
    业务场景还是要定义清楚,是 BI 报表,还是聚合查询

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

    如果是聚合查询,那这个就看量大小了,不复杂的话通过数据库也行,如果规模较大就得上数仓
    1996wang
        47
    1996wang  
       2023-02-02 15:10:17 +08:00
    可以看看 doris 的外表功能: https://doris.apache.org/zh-CN/docs/dev/lakehouse/external-table/jdbc?_highlight=mysql#mysql

    好处是不用考虑数据导入的事情,近实时应该没问题.
    导入的话就用 flink-cdc.
    对比 ck,单机性能没有 ck 强.但是运维简单,文档中文.
    还有个优点,doris 可以直接对接很多 bi 看板(当作 mysql),后面看板开发就很省功夫.
    NoString
        48
    NoString  
       2023-02-02 15:38:05 +08:00
    clickhouse 巨吃配置,并发的场景并不理想,每日 10w 单,三个月千万的数据,mysql 应该就能抗,针对这个需求要毫秒级响应就上 Redis 维护一份 Topk 的数据,一个 Redis 维护几十万店面的各种数据 key 下来成本还是很低的。

    但是如果要做各种复杂纬度的看板,还是老老实实建数仓,Clickhouse ,Doris 都可以,考虑聚合场景多机器预算高就 Clickhouse ,报表中间加层 Redis 缓存,实时并发性能也不会差(具体可以参考腾讯音乐的方案,之前在 CK 的分享上他们就是这种模式)
    shinession
        49
    shinession  
       2023-02-02 16:13:04 +08:00
    插个眼, flink 第一次听说, 了解先
    securityCoding
        50
    securityCoding  
       2023-02-02 16:26:57 +08:00
    @ppppppp123 汇总一张宽表,管理员看板没啥并发 ck 随便查的
    zoharSoul
        51
    zoharSoul  
       2023-02-02 16:31:17 +08:00
    对内 flink/ clickhouse

    对外 es
    shenqi
        52
    shenqi  
       2023-02-02 18:00:46 +08:00
    有没有考虑 mysql -> hive +kylin -> superset 一条龙梭哈,都不用怎么写代码,只写 sql 和模型。

    但是没那么实时,当然这点数据量,做成实时同时压力不大,模型计算你都实时了,kylin 也会没啥压力。
    jeesk
        53
    jeesk  
       2023-02-02 18:07:31 +08:00
    10w ,java stream 都能搞.
    aw2350
        54
    aw2350  
       2023-02-02 18:09:58 +08:00
    如果每天 10w 的数据,写 sum 窗口函数 group by 之类的查询,单日的数据查询结果应该永不了 3s 吧?或者在业务层面 分库分表,每个业务大类一个库,那样子压力就更小了
    aw2350
        55
    aw2350  
       2023-02-02 18:12:28 +08:00
    对了,还不能因为看板的查询操作阻塞主业务的进行,上主从吧,看板的查询数据走从库,减轻主库的压力
    netnr
        56
    netnr  
       2023-02-02 18:26:48 +08:00 via Android
    我会使用中间表 一张按天汇总 一张按小时汇总(只存储当天),根据具体情况还可以加按月 年汇总的中间表

    每个小时跑一次汇总任务

    查询根据时间段拆分查询

    也就是空间换时间
    akira
        57
    akira  
       2023-02-02 22:18:13 +08:00
    直接 mysql sum 一把梭, 有 性能问题 先考虑 sql 优化 次之升级 mysql ,最后才是考虑上别的东西
    acerphoenix
        58
    acerphoenix  
       2023-02-02 23:26:45 +08:00
    业务上没必要考虑并发,这种数据才几个能人看?
    这点数据量,设计方向是简单成本低,别想啥响应啊性能啊,没必要;实时只是相对每天一统计而言。
    但是为了保证线上业务,不能用生产库直接搞,太无脑了,怎么也得同步出一份数据来,我们直接直接 java 内存数据库跑都挺好,也不用持久化,计算灵活方便。
    Pantheoon
        59
    Pantheoon  
       2023-02-03 10:43:02 +08:00
    这种数据量用不上 flink,场景是 olap,查询语句固定就那些,没有并发,es,clickhouse,配置高点的 mysql 都比较合适
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3794 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 40ms · UTC 00:15 · PVG 08:15 · LAX 17:15 · JFK 20:15
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.