项目是 GPS 业务,每天有约 2w+台车传数据到我们这里储存。每天数据量大概在 1 亿左右。
数据主要用于做报表,查询历史轨迹(查询频率高,基本上每次查出过万的数据)
没做过这么大数据量的业务场景,想问下这场景应该怎么做?感谢
1
tanranran 2020-05-27 09:18:17 +08:00
如果查询条件复杂,且有文本查询,那就 Hbase + ElasticSearch ;如果用云产品,那就是阿里云的 OTS + OpenSearch
|
2
cominghome 2020-05-27 09:24:33 +08:00
没做过这种业务,不过可以说下看法。
2w 台车,数据量一亿,那看来单位是请求数? 给你往大了说,一个请求按 10 KB 算, 算下来一天也就 1T 左右,正常的大数据仓库都能 hold 住的吧 |
3
shadowyue 2020-05-27 09:32:12 +08:00
有接触过相关业务,量应该没你这么大,5k-1w 量车,mongodb 就 hold 住
|
4
xman99 2020-05-27 09:33:26 +08:00
考虑下 新的分布式数据库? tidb 、hbase 等超大型分布式数据库吧
|
5
daozhihun 2020-05-27 09:34:15 +08:00
你这个很适合 hbase
|
6
HEROic 2020-05-27 09:34:37 +08:00 via Android 1
hbase+es 吧,hbase 用时间年月划分 region,es 按天建索引
|
7
HEROic 2020-05-27 09:36:45 +08:00 via Android
单纯的过车数据大概就 2KB 左右,一天就 200G
|
8
tolerance 2020-05-27 09:42:53 +08:00
时序数据库考虑一下
|
9
micean 2020-05-27 09:44:00 +08:00
没做过大数据业务的话就按一般情况考虑吧
每台车每天发 5 千条,平均不到 1 秒一条。 不代表每条都要存储吧,地图上也不需要展示这么精细 可以 15 秒以上存一次,这样数量级就降到百万级以下了 |
10
rockyou12 2020-05-27 09:52:47 +08:00
你这该用各种时序数据库,hbase 不是特别好。优先考虑 influxdb 这类的吧
|
11
lianglianglee 2020-05-27 09:54:08 +08:00 via Android
这种场景多适合时序数据库啊
|
12
ychost 2020-05-27 09:59:58 +08:00
时序数据库 InfluxDB +1,特别适合做 IOT 数据存储,再配合 grafana 美滋滋,谁用谁知道
|
13
rrfeng 2020-05-27 10:00:14 +08:00
看数据结构,只说数据量就是耍流氓啊。
|
14
wellsc 2020-05-27 10:03:28 +08:00
时序数据库+1
|
15
irockman 2020-05-27 10:43:25 +08:00
传统数据库 mysql:一台车一张表,按 gps 每十秒上报一条数据,一年数据量 6*60*24*365=3153600 条数据,单表查询压力不大。或者选择时序数据库 influxdb,不过集群方案收费。
|
16
alienx717 2020-05-27 11:40:04 +08:00
大众的车联网项目自己都用的 HBASE
你可以参考以下。 另外,非得每 10 秒钟一条么,我记得 15 秒一条也可以吧,应该能少不少数据 |
17
WhoMercy 2020-05-27 12:44:00 +08:00
冷热分离,多级缓存,数据预聚合,Data Partition/Sharding,DDB ( Distributed DB )...
具体怎么实施看情况而定,一方面看已有痛点在哪,一方面估计会有的瓶颈,一方面平衡开发的复杂度 |
18
soulzz 2020-05-27 15:18:51 +08:00 3
同行啊 😂我这公司有好几个同类型平台,我待的这个平台设备量 30W+
用的 MongoDb 轻轻松松 一天设备上报的报文一亿多条,设备实时状态一定不要存数据库,放缓存中间件,不然后期真的改不动 轨迹的话按天分表,超过几个月的轨迹定期移到另一个空间大的冷存储(机械盘之类 原始报文只保存几天,接收上报的模块一定不要有存库操作,数据库挂掉会导致大量 TCP CLOSE_WAIT 建议接收上报的模块把原始报文发 kafka ,再由消费者存到另一个原始报文库 只要解耦解的好,并不需要用到时序数据库 用时序数据库会存在的问题在于设备可能定位漂移,或者突然报了一个有问题的包,这个时候再去时序数据库里修改它就非常困难了,这也是我们这没有采用时序数据库的原因 |
19
jwdstefani 2020-05-27 16:11:33 +08:00
我们之前的车贷 GPS 监控系统,一台车接了 3 个厂商的 GPS,也是用的 MongoDB,数据只保留一个月的,数据量也是大的一批,就是轨迹查询的时候吃内存
|
20
tolbkni 2020-05-27 16:18:24 +08:00
结构化数据只新增不更新的场景可以用 ClickHouse 数据库
|
21
dkerss 2020-05-27 16:29:05 +08:00
推荐 ClickHouse 神器!
|
24
Magic347 2020-05-27 17:46:56 +08:00
hive?
|
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/
|
27
yjhatfdu2 2020-05-27 17:52:51 +08:00
顺便,现在如果是少量数据的 update,clickhouse 可以使用 mutations 完美完成,如果量大的话,可以用 collaspemergetree 引擎,变相实现标记删除并且不影响查询结果
|
28
ahmcsxcc 2020-05-27 17:55:39 +08:00
同 clickhouse
|
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 希望对楼主有帮助 |
30
gainsurier 2020-05-27 22:48:47 +08:00 via Android
歪个楼问下,为啥车每天要传那么对数据回来
|
31
calpiswater 2020-05-27 22:54:18 +08:00 via iPhone
可以考虑下清华的 IoTDB
|
32
likuku 2020-05-27 23:08:12 +08:00
aws s3,还有啥存不了的?
直接进大数据服务 EMR,要么数据湖,简单查询,直接来 Athena 查 s3 也没问题啊 实时处理分析? aws 有 kinesis 啊,各种并行实时处理,本来就是很适合搭配 IoT / GPS 业务场景的 非实时分析,还有 redshift 数据仓库服务可以用,更可以联合查询,操作型关系数据库。 跨一个或多个 Amazon RDS 和 Aurora PostgreSQL 数据库查询实时数据,支持大规模并行数据处理。 有兴趣欢迎继续交流~ |
33
wd 2020-05-28 07:43:00 +08:00 via iPhone
@gainsurier #30 一般都会认为,数据就是钱呀,越多的数据越多的钱。每天几亿出去和投资人好吹牛逼。
|
34
rapperx2 OP @yjhatfdu2 非常感谢大佬这么上心帮我,太感谢了,连性能测试都给我举例出来了。我现在还需要学习下 clickhouse 。从来没用过。
感觉这个方案不错,先参考你这个方案吧 |
35
rapperx2 OP @gainsurier 因为我们需要对车进行实时监控和历史轨迹回放。还要做一些报表之类的。
|
37
rockcat 2020-05-28 09:29:58 +08:00
ClickHouse 或者 Green Plum 。
|
40
yjhatfdu2 2020-05-28 10:09:30 +08:00
@rapperx2 对了,时间戳精度要求不高的话,可以用不需要用 DateTime64,可以 DateTime (精确到秒),经度维度可以用 UInt32 CODEC(DoubleDelta),方向不需要的话可以不存,这样估计还能小一倍,也能快一些。
|
42
caotian 2020-05-28 12:46:32 +08:00
TDEngine
|
43
chinvo 2020-05-28 12:53:34 +08:00 via iPhone
TimescalaDB
|
44
rapperx2 OP @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.) 这个查询时间属于正常的吗? |
46
yjhatfdu2 2020-05-29 11:42:14 +08:00
@rapperx2 渐变语句要加上 oder by(车牌,时间),我怀疑你这边是直接按照日期排序了,这样找一辆车的数据也要扫全表,然后数据类型建议也再看一下车牌最好用个足够小的 int 作为,再建一张表用来存车牌和 ID 的映射,查询时使用 join,这样能显著减少查询的数据量( 2300w 行就 2.17GB 太大了),数据结构越高效性能越高
|
51
raywong 2023-03-01 16:12:11 +08:00
楼主后续选了什么方案,遇到相似的场景,方便加个 qq 么。base64: MTU1MjkzNzAwMA==
|