V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
rapperx2
V2EX  ›  问与答

求友们帮助,每天亿级数据怎么储存

  •  2
     
  •   rapperx2 · 2020-05-27 09:06:19 +08:00 · 7524 次点击
    这是一个创建于 1402 天前的主题,其中的信息可能已经有所发展或是发生改变。

    项目是 GPS 业务,每天有约 2w+台车传数据到我们这里储存。每天数据量大概在 1 亿左右。

    数据主要用于做报表,查询历史轨迹(查询频率高,基本上每次查出过万的数据)

    没做过这么大数据量的业务场景,想问下这场景应该怎么做?感谢

    51 条回复    2023-03-01 16:12:11 +08:00
    tanranran
        1
    tanranran  
       2020-05-27 09:18:17 +08:00
    如果查询条件复杂,且有文本查询,那就 Hbase + ElasticSearch ;如果用云产品,那就是阿里云的 OTS + OpenSearch
    cominghome
        2
    cominghome  
       2020-05-27 09:24:33 +08:00
    没做过这种业务,不过可以说下看法。

    2w 台车,数据量一亿,那看来单位是请求数? 给你往大了说,一个请求按 10 KB 算, 算下来一天也就 1T 左右,正常的大数据仓库都能 hold 住的吧
    shadowyue
        3
    shadowyue  
       2020-05-27 09:32:12 +08:00
    有接触过相关业务,量应该没你这么大,5k-1w 量车,mongodb 就 hold 住
    xman99
        4
    xman99  
       2020-05-27 09:33:26 +08:00
    考虑下 新的分布式数据库? tidb 、hbase 等超大型分布式数据库吧
    daozhihun
        5
    daozhihun  
       2020-05-27 09:34:15 +08:00
    你这个很适合 hbase
    HEROic
        6
    HEROic  
       2020-05-27 09:34:37 +08:00 via Android   ❤️ 1
    hbase+es 吧,hbase 用时间年月划分 region,es 按天建索引
    HEROic
        7
    HEROic  
       2020-05-27 09:36:45 +08:00 via Android
    单纯的过车数据大概就 2KB 左右,一天就 200G
    tolerance
        8
    tolerance  
       2020-05-27 09:42:53 +08:00
    时序数据库考虑一下
    micean
        9
    micean  
       2020-05-27 09:44:00 +08:00
    没做过大数据业务的话就按一般情况考虑吧
    每台车每天发 5 千条,平均不到 1 秒一条。
    不代表每条都要存储吧,地图上也不需要展示这么精细
    可以 15 秒以上存一次,这样数量级就降到百万级以下了
    rockyou12
        10
    rockyou12  
       2020-05-27 09:52:47 +08:00
    你这该用各种时序数据库,hbase 不是特别好。优先考虑 influxdb 这类的吧
    lianglianglee
        11
    lianglianglee  
       2020-05-27 09:54:08 +08:00 via Android
    这种场景多适合时序数据库啊
    ychost
        12
    ychost  
       2020-05-27 09:59:58 +08:00
    时序数据库 InfluxDB +1,特别适合做 IOT 数据存储,再配合 grafana 美滋滋,谁用谁知道
    rrfeng
        13
    rrfeng  
       2020-05-27 10:00:14 +08:00
    看数据结构,只说数据量就是耍流氓啊。
    wellsc
        14
    wellsc  
       2020-05-27 10:03:28 +08:00
    时序数据库+1
    irockman
        15
    irockman  
       2020-05-27 10:43:25 +08:00
    传统数据库 mysql:一台车一张表,按 gps 每十秒上报一条数据,一年数据量 6*60*24*365=3153600 条数据,单表查询压力不大。或者选择时序数据库 influxdb,不过集群方案收费。
    alienx717
        16
    alienx717  
       2020-05-27 11:40:04 +08:00
    大众的车联网项目自己都用的 HBASE
    你可以参考以下。
    另外,非得每 10 秒钟一条么,我记得 15 秒一条也可以吧,应该能少不少数据
    WhoMercy
        17
    WhoMercy  
       2020-05-27 12:44:00 +08:00
    冷热分离,多级缓存,数据预聚合,Data Partition/Sharding,DDB ( Distributed DB )...

    具体怎么实施看情况而定,一方面看已有痛点在哪,一方面估计会有的瓶颈,一方面平衡开发的复杂度
    soulzz
        18
    soulzz  
       2020-05-27 15:18:51 +08:00   ❤️ 3
    同行啊 😂我这公司有好几个同类型平台,我待的这个平台设备量 30W+
    用的 MongoDb 轻轻松松
    一天设备上报的报文一亿多条,设备实时状态一定不要存数据库,放缓存中间件,不然后期真的改不动
    轨迹的话按天分表,超过几个月的轨迹定期移到另一个空间大的冷存储(机械盘之类
    原始报文只保存几天,接收上报的模块一定不要有存库操作,数据库挂掉会导致大量 TCP CLOSE_WAIT
    建议接收上报的模块把原始报文发 kafka ,再由消费者存到另一个原始报文库
    只要解耦解的好,并不需要用到时序数据库
    用时序数据库会存在的问题在于设备可能定位漂移,或者突然报了一个有问题的包,这个时候再去时序数据库里修改它就非常困难了,这也是我们这没有采用时序数据库的原因
    jwdstefani
        19
    jwdstefani  
       2020-05-27 16:11:33 +08:00
    我们之前的车贷 GPS 监控系统,一台车接了 3 个厂商的 GPS,也是用的 MongoDB,数据只保留一个月的,数据量也是大的一批,就是轨迹查询的时候吃内存
    tolbkni
        20
    tolbkni  
       2020-05-27 16:18:24 +08:00
    结构化数据只新增不更新的场景可以用 ClickHouse 数据库
    dkerss
        21
    dkerss  
       2020-05-27 16:29:05 +08:00
    推荐 ClickHouse 神器!
    rapperx2
        22
    rapperx2  
    OP
       2020-05-27 16:42:05 +08:00
    @soulzz 大佬啊。哈哈,能加个 V 交流学习下吗?
    soulzz
        23
    soulzz  
       2020-05-27 17:44:18 +08:00
    @rapperx2 不是大佬,架子别人搭的,我在这天天修修补补
    Magic347
        24
    Magic347  
       2020-05-27 17:46:56 +08:00
    hive?
    yjhatfdu2
        25
    yjhatfdu2  
       2020-05-27 17:48:54 +08:00   ❤️ 1
    这个场景,clickhouse 使用 mergetree 引擎,根据日期做分区,车辆 ID,timestamp 排序,clickhouse 对于 float 类型时序数据也有类似时序数据库的 Gorilla codec,有效压缩时序浮点数据。clickhouse 本身的话,支持分布式、高可用,支持 SQL (部分),可以用 http 接口直接访问,使用难度很低。性能的话,我们做过一些测试,单节点 64 核 epyc2+256G 内存,单表 15 亿行 20 多列的纽约出租车数据,单个全表级的 group by+sum 大概 200ms 左右,多个维度的 group by+多个聚合能在 700ms 内完成,基本上是现在分析库的上限了。https://clickhouse.tech/docs/en/getting-started/example-datasets/nyc-taxi/
    yjhatfdu2
        26
    yjhatfdu2  
       2020-05-27 17:50:30 +08:00
    @yjhatfdu2 比 hive 或者 HBase+mr/spark 之类的的方案大概也就快几百倍把
    yjhatfdu2
        27
    yjhatfdu2  
       2020-05-27 17:52:51 +08:00
    顺便,现在如果是少量数据的 update,clickhouse 可以使用 mutations 完美完成,如果量大的话,可以用 collaspemergetree 引擎,变相实现标记删除并且不影响查询结果
    ahmcsxcc
        28
    ahmcsxcc  
       2020-05-27 17:55:39 +08:00
    同 clickhouse
    yjhatfdu2
        29
    yjhatfdu2  
       2020-05-27 20:06:48 +08:00   ❤️ 1
    @rapperx2 我还真造了点数据来测试一下 clickhouse 。
    表结构:
    create table ts_test
    (
    ts DateTime64 CODEC(DoubleDelta),
    car_id Int32,
    lat Float32 CODEC(Gorilla),
    log Float32 CODEC(Gorilla),
    dir Float32 CODEC(Gorilla)
    ) engine MergeTree() order by (car_id, ts) partition by toDate(ts);
    其中,方向 dir 平均 100s 随机刷新,速度 0-100 之间随机,ts 的间隔 1s±100ms 并加入随机抖动,20000 辆车,每辆车起始位置随机,然后模拟每辆车运动,生成 csv 数据导入 clickhouse 。共使用了 20 分钟导入了 983725233(9.8 亿)行数据,占用硬盘空间 9.45 GiB,大概每 1 亿行 1G 。
    然后测试了一些简单的查询。
    Q1: 查询某个车的完整轨迹: select * from ts_test where car_id=1;
    行数和耗时:49187 rows in set. Elapsed: 0.041 sec.
    Q2: 查询表总行数: select count(*) from ts_test;
    行数和耗时:1 rows in set. Elapsed: 0.001 sec. (估计缓存了)
    Q3: 查询每辆车的数据点数量: select car_id,count(*) from ts_test group by car_id;
    行数和耗时:20000 rows in set. Elapsed: 0.129 sec.
    Q4: 查询每辆车的活动范围(矩形):select car_id,min(lat),max(lat),min(log),max(log) from ts_test group by car_id;
    行数和耗时:20000 rows in set. Elapsed: 0.568 sec.
    Q5: 查询一辆车的活动范围(矩形):select min(lat),max(lat),min(log),max(log) from ts_test where car_id=100;
    行数和耗时:1 rows in set. Elapsed: 0.003 sec.
    Q6: 查询每小时的数据点(每小时约 7200w )数量: select count(*),toYYYYMMDD(ts)+toHour(ts) as hour from ts_test group by hour;
    行数和耗时:14 rows in set. Elapsed: 0.347 sec.

    测试硬件:单机 AMD EPYC 7702P 64-Core Processor 64 核,256G 内存,SSD
    希望对楼主有帮助
    gainsurier
        30
    gainsurier  
       2020-05-27 22:48:47 +08:00 via Android
    歪个楼问下,为啥车每天要传那么对数据回来
    calpiswater
        31
    calpiswater  
       2020-05-27 22:54:18 +08:00 via iPhone
    可以考虑下清华的 IoTDB
    likuku
        32
    likuku  
       2020-05-27 23:08:12 +08:00
    aws s3,还有啥存不了的?

    直接进大数据服务 EMR,要么数据湖,简单查询,直接来 Athena 查 s3 也没问题啊

    实时处理分析? aws 有 kinesis 啊,各种并行实时处理,本来就是很适合搭配 IoT / GPS 业务场景的

    非实时分析,还有 redshift 数据仓库服务可以用,更可以联合查询,操作型关系数据库。
    跨一个或多个 Amazon RDS 和 Aurora PostgreSQL 数据库查询实时数据,支持大规模并行数据处理。

    有兴趣欢迎继续交流~
    wd
        33
    wd  
       2020-05-28 07:43:00 +08:00 via iPhone
    @gainsurier #30 一般都会认为,数据就是钱呀,越多的数据越多的钱。每天几亿出去和投资人好吹牛逼。
    rapperx2
        34
    rapperx2  
    OP
       2020-05-28 08:39:08 +08:00
    @yjhatfdu2 非常感谢大佬这么上心帮我,太感谢了,连性能测试都给我举例出来了。我现在还需要学习下 clickhouse 。从来没用过。
    感觉这个方案不错,先参考你这个方案吧
    rapperx2
        35
    rapperx2  
    OP
       2020-05-28 08:40:57 +08:00
    @gainsurier 因为我们需要对车进行实时监控和历史轨迹回放。还要做一些报表之类的。
    cqdx02
        36
    cqdx02  
       2020-05-28 08:53:55 +08:00
    @yjhatfdu2 能否进行数据聚合呢,比如按分钟级,15 分钟级统计数据
    rockcat
        37
    rockcat  
       2020-05-28 09:29:58 +08:00
    ClickHouse 或者 Green Plum 。
    0987363
        38
    0987363  
       2020-05-28 09:35:27 +08:00 via Android
    @soulzz 状态不存数据库的话,那要用状态排序岂不是凉😅
    yjhatfdu2
        39
    yjhatfdu2  
       2020-05-28 10:05:43 +08:00
    @cqdx02 当然可以,group by 就可以,看上面的 Q6,使用对应的函数对时间进行处理就行
    yjhatfdu2
        40
    yjhatfdu2  
       2020-05-28 10:09:30 +08:00
    @rapperx2 对了,时间戳精度要求不高的话,可以用不需要用 DateTime64,可以 DateTime (精确到秒),经度维度可以用 UInt32 CODEC(DoubleDelta),方向不需要的话可以不存,这样估计还能小一倍,也能快一些。
    soulzz
        41
    soulzz  
       2020-05-28 10:13:02 +08:00
    @0987363 这个要看应用场景,实时状态存库的话数据库压力非常高
    caotian
        42
    caotian  
       2020-05-28 12:46:32 +08:00
    TDEngine
    chinvo
        43
    chinvo  
       2020-05-28 12:53:34 +08:00 via iPhone
    TimescalaDB
    rapperx2
        44
    rapperx2  
    OP
       2020-05-29 11:14:27 +08:00
    @yjhatfdu2 我根据车牌 查询时间范围一个月的数据

    58516 rows in set. Elapsed: 19.415 sec. Processed 23.93 million rows, 2.17 GB (1.23 million rows/s., 111.70 MB/s.)

    这个查询时间属于正常的吗?
    yjhatfdu2
        45
    yjhatfdu2  
       2020-05-29 11:38:16 +08:00
    @rapperx2 不正常,方便看一下表定义和查询嘛?
    yjhatfdu2
        46
    yjhatfdu2  
       2020-05-29 11:42:14 +08:00
    @rapperx2 渐变语句要加上 oder by(车牌,时间),我怀疑你这边是直接按照日期排序了,这样找一辆车的数据也要扫全表,然后数据类型建议也再看一下车牌最好用个足够小的 int 作为,再建一张表用来存车牌和 ID 的映射,查询时使用 join,这样能显著减少查询的数据量( 2300w 行就 2.17GB 太大了),数据结构越高效性能越高
    rapperx2
        47
    rapperx2  
    OP
       2020-05-29 11:50:57 +08:00
    @yjhatfdu2 能方便加个 V 吗?
    yjhatfdu2
        48
    yjhatfdu2  
       2020-05-29 12:03:26 +08:00
    @rapperx2 qq 吧,base64:MjUxNjUwMjky
    Huayx9
        49
    Huayx9  
       2021-01-15 16:34:19 +08:00
    @rapperx2 请问最后你选用了什么技术方案,方便加个 v 么,我的 vx 是 base64:Zm9yX215Xzc3
    rapperx2
        50
    rapperx2  
    OP
       2021-01-18 09:01:27 +08:00
    @Huayx9 加你了
    raywong
        51
    raywong  
       2023-03-01 16:12:11 +08:00
    楼主后续选了什么方案,遇到相似的场景,方便加个 qq 么。base64: MTU1MjkzNzAwMA==
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2770 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 42ms · UTC 12:17 · PVG 20:17 · LAX 05:17 · JFK 08:17
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.