生成大表数据优化建议 - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
zer0fire
V2EX    Java

生成大表数据优化建议

  •  
  •   zer0fire 2022 年 3 月 31 日 3243 次点击
    这是一个创建于 1389 天前的主题,其中的信息可能已经有所发展或是发生改变。

    问下大佬, 要用 java 通过逻辑运算生成一张表格(数据量大概 10 亿), 后面需要对该表格做统计分析, 有没有好的建议

    配置: 系统: windows10 内存: 20G cpu: i710 代 硬盘: 5900rpm 写入 10m/s

    目前的做法是如下:

    1. 生成期间尽可能不查询数据库在内存中做过滤等处理(有 5 个 for 循环, 还是不可避免调用了 4 次数据库查询 + 1 次数据库插入), 在存到 mysql
    2. 使用并行开了 128 个线程去处理
    3. mysql 连接数设置到 150
    p>目前情况:

    1. cpu 使用 10%不到
    2. 内存使用不到 3G
    3. 硬盘平均写入 3m/s

    由于数据后期需要做很多类似 count, sum 之类的运算 es, map reduce 可能不适合,

    能想到的优化方案:

    1. 考虑 mysql 放到 ssd 盘中
    2. 增加线程数
    19 条回复    2022-03-31 23:45:41 +08:00
    ihehe
        1
    ihehe  
       2022 年 3 月 31 日 via iPhone
    把这 10 亿数据生成 parquet 格式,丢到本地文件大概 10g 以内, 找个 mmp 工具,单机版的就够用,10g 内存 sql 撸几次就可以了,结果存文件,这不就随便唆嘛
    ihehe
        2
    ihehe  
       2022 年 3 月 31 日 via iPhone
    更正:mmp --> mpp
    Itoktsnhc
        3
    Itoktsnhc  
       2022 年 3 月 31 日
    这个场景 clickhouse 不是挺好
    zer0fire
        4
    zer0fire  
    OP
       2022 年 3 月 31 日
    @ihehe 原先 mysql 要查询的数据表就有 1 亿多条记录, 如何转成 parquet 格式(mysqsl->Hadoop), 内存 sql, 是让我使用内存数据库吗?
    zer0fire
        5
    zer0fire  
    OP
       2022 年 3 月 31 日
    @Itoktsnhc clickhouse 这个只有 Linux 系统的版本, windows 系统要使用得用 docker
    ihehe
        6
    ihehe  
       2022 年 3 月 31 日 via iPhone
    写个程序把 mysql 数据读出来,生成 parquet 格式,就 1 亿条,上面的方案看错了,看成 10 亿,1 亿 条转成 prquet 大概 1g 大小以内;那就不用那么麻烦,你这单机丢到 duckdb 里去, 然后撸 sql 把
    zer0fire
        7
    zer0fire  
    OP
       2022 年 3 月 31 日
    @ihehe 这里面的优化思路是在把数据全放到内存中, 在内存中做 sql 查询对吧?
    ihehe
        8
    ihehe  
       2022 年 3 月 31 日 via iPhone
    @zer0fire 可以这么理解吧,前提是转好格式,提升几十倍的扫描速度,减少 10 多倍的数据大小,你可以试试单机的 spark/ flink/drill/presto 都可以直接扫文件,不用先导成表
    F281M6Dh8DXpD1g2
        9
    F281M6Dh8DXpD1g2  
       2022 年 3 月 31 日
    生成文件 load 完事
    另外为啥你要用 java 生成...随便找个 spark 都快得很好吧
    zer0fire
        10
    zer0fire  
    OP
       2022 年 3 月 31 日
    @ihehe mysql 支持 memory 引擎, 我把表换成用这个引擎, 是不是也能到达同样的效果(确实可以不考虑事务方面的问题)
    zer0fire
        11
    zer0fire  
    OP
       2022 年 3 月 31 日
    @liprais 因为数据是从一张表取出来做逻辑处理, 在存到另一张表的
    zmal
        12
    zmal  
       2022 年 3 月 31 日
    mysql 的使用不太对吧,并行写入同一张表对写入性能不会有提升,线程开那么多也没啥用啊。可以考虑不用 mysql ,数据放 kafka 。
    看起来这个场景用大数据工具解决会简单很多,spark/flink 之类的。
    zer0fire
        13
    zer0fire  
    OP
       2022 年 3 月 31 日
    @ihehe 那我还要搞个 linux 虚拟机环境?
    X0ray
        14
    X0ray  
       2022 年 3 月 31 日
    先定位瓶颈呗,看着像是读数据慢?
    还有 count sum 这类的聚合运算,为啥 es, map reduce 就不适合了?
    ihehe
        15
    ihehe  
       2022 年 3 月 31 日 via iPhone   1
    @zer0fire mysql 的 memory 引擎对这 1 亿处理应该没啥问题,如果 10 亿百亿的你就没这么多 memory 给它用了;
    上面的那些组件都是 java 的,win 上应该是可以跑的,不用再虚拟一层 linux ;(不过我没有在 win 上用过它们)
    BeijingBaby
        16
    BeijingBaby  
       2022 年 3 月 31 日
    推荐 clickhouse ,轻松处理。
    clf
        17
    clf  
       2022 年 3 月 31 日
    drill 可以看看这个。
    encro
        18
    encro  
       2022 年 3 月 31 日
    你以为 mysql memory table 的 sum,cout 就快了吗?

    mysql 就是只能作 oltp 业务,作 olap 还是不行的。
    akira
        19
    akira  
       2022 年 3 月 31 日
    不管是啥,无脑上 固态 总是对的
    关于     帮助文档     自助推广系统     博客     API     FAQ     Solana     1049 人在线   最高记录 6679       Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 31ms UTC 18:03 PVG 02:03 LAX 10:03 JFK 13:03
    Do have faith in what you're doing.
    ubao msn snddm index pchome yahoo rakuten mypaper meadowduck bidyahoo youbao zxmzxm asda bnvcg cvbfg dfscv mmhjk xxddc yybgb zznbn ccubao uaitu acv GXCV ET GDG YH FG BCVB FJFH CBRE CBC GDG ET54 WRWR RWER WREW WRWER RWER SDG EW SF DSFSF fbbs ubao fhd dfg ewr dg df ewwr ewwr et ruyut utut dfg fgd gdfgt etg dfgt dfgd ert4 gd fgg wr 235 wer3 we vsdf sdf gdf ert xcv sdf rwer hfd dfg cvb rwf afb dfh jgh bmn lgh rty gfds cxv xcv xcs vdas fdf fgd cv sdf tert sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf shasha9178 shasha9178 shasha9178 shasha9178 shasha9178 liflif2 liflif2 liflif2 liflif2 liflif2 liblib3 liblib3 liblib3 liblib3 liblib3 zhazha444 zhazha444 zhazha444 zhazha444 zhazha444 dende5 dende denden denden2 denden21 fenfen9 fenf619 fen619 fenfe9 fe619 sdf sdf sdf sdf sdf zhazh90 zhazh0 zhaa50 zha90 zh590 zho zhoz zhozh zhozho zhozho2 lislis lls95 lili95 lils5 liss9 sdf0ty987 sdft876 sdft9876 sdf09876 sd0t9876 sdf0ty98 sdf0976 sdf0ty986 sdf0ty96 sdf0t76 sdf0876 df0ty98 sf0t876 sd0ty76 sdy76 sdf76 sdf0t76 sdf0ty9 sdf0ty98 sdf0ty987 sdf0ty98 sdf6676 sdf876 sd876 sd876 sdf6 sdf6 sdf9876 sdf0t sdf06 sdf0ty9776 sdf0ty9776 sdf0ty76 sdf8876 sdf0t sd6 sdf06 s688876 sd688 sdf86