如何估算spark运行的资源数量 spark数据量大处理方法

转载

mob64ca13fd9f8e 2024-02-03 10:19:07

文章标签 如何估算spark运行的资源数量数据 spark 性能分析 文章分类 Spark 大数据

临时方案：

备份数据，然后提供最近一段时间的数据查询，满足用户查询近期数据的需求，而较久远的历史数据，由产品或分析师手动提供查询，当然这只是临时方案，不可长期存在。

方案比较：

接入spark：

优势：
该方案操作简单，只要将数据导入到hive表，然后通过spark jdbc的方式连接即可
可扩展性好，可存储上T的数据。
不足：
对资源的依赖相对较重，目前大数据这边有10台服务器，1台master,9台slave,对于当前的调度任务来说，资源略显紧张，数据分析师和大数据这表均存在使用，而接入spark大概占据百分之二十的集群资源，导致分析师，调度任务无法再规定时间完成，若需要强行接入spark需要申请新的机器。
spark优化较难。
性能分析：
经过测试查询两亿数据量，查询速度在10s左右，由于数据对时间有分区，业务查询除了比较极端的需求之外，不会全表扫描。
查询最近一段时间的数据，查询时间维持在1s以下。
经过调试查询速度可维持到100ms左右。

数据库分库分表：

优势：
将大表分割为多个小表，大幅度查询的行数，从而提高查询效率。
相比于分区，对于单个小表可建立索引，进一步提高查询速度。
不足：
数据量若大幅增长，分表表数不够，需要重新分表，移数据略显麻烦。
将数据导入多个表中，对于查询该表所有数据的统计不大好统。
数据表建的太多，看起来凌乱，而且导入历史数据略显麻烦。
增加列不大方便，浪费存储空间。
性能分析：
6千万数据分给为16个表，每个表数据量大概在40w数据左右,查询时间可达200ms以内。

数据库分区：

优势：
和数据库分库分表的思想接近,属于物理存储层面的分库分表，数据量过大（索引查过cpu内存比如4G）时，删除索引查询速度可显著提高。
数量若增大，查询速度减慢时，可直接通过语句增加分区个数，提高查询速度。
不足：
单表数据量过大，对于分区建立索引会降低查询速度。
数据库迁移数据困难。
多表连接查询效率明显降低。
数据插入较慢，不适用于插入频繁操作。
浪费存储空间。
最新版mysql数据库分区有限制8192。
性能分析：
单个分区数据量大概在40w,查询速度可在200ms左右。
若分区数据量小，查询速度可更快。

接入hbase 接口：