Prime_DSC_MentionCalcSpark性能调优

Prime_DSC_MentionCalcSpark系统简介

实现功能 : 根据条件(siteId, startTime, endTime, campaignId, folder)从HBase数据源中读取文本数据作为输入,把提交的关键词作为条件,输出在文本中关键词提及的次数

存在问题 : 对于大数据量的计算时间较长.

解决思路 :

  1. 把HBase结果反射成TweetBean修改成TweetBean的setXXX的方式构造TweetBean

    1. 当有5W条数据,通过反射转成TweetBean需要60s,通过TweetBean的setXX的方法需要20s
  2. 把读取HBase的所有字段改成读取HBase的需要的字段
    1. 当有5W条数据,读取所有字段时需要60s,读取需要的字段需要25s
  3. 从UC取DC数据时,不使用map函数,替换成mapPartition函数,这样使用可以从HBase批量取数据,仅需要一次HBase连接即可
  4. 存储计算结果,使用foreachPartition函数. 当遍历Iterator时不是每次在循环里面都存储计算结果,而是在循环外面维护队列,批量存储结果
  5. 根据Spark集群资源,合理利用Spark集群的资源,如资源越多,集群计算能力越强.而比较合理的机器资源和任务并行度的关系是 : 任务数 = 机器CPU核数 * (2 或者 3), 所以设置RDD的分区数为集群CPU核数 * 2
  6. 从HBase读取数据的并行度跟表的region数相关.默认情况下,建表时只有一个region,而当region越来越大时,需要split成两个region,region越多split的阈值越大,导致很多数据都存在一个region中.此时如果需要查询一张表,假设该表有5个region,则会有5个线程同时查询5个region的数据,但是如果其中一个region很大,是其他region的10倍,则该region的读取是其他region读取性能的10倍,导致整个任务的delay. 解决该问题的方法可以先通过预分区和对rowkey使用hash/MD5等算法使数据均匀的分布在各个region,这样在读取数据时可以根据数据均匀分配而更好的并发读取数据.
时间： 2024-11-05 06:08:55

Prime_DSC_MentionCalcSpark性能调优的相关文章

iOS应用性能调优的25个建议和技巧

目录 我要给出的建议将分为三个不同的等级: 入门级. 中级和进阶级: 入门级(这是些你一定会经常用在你app开发中的建议) 1. 用ARC管理内存 2. 在正确的地方使用reuseIdentifier 3. 尽可能使Views透明 4. 避免庞大的XIB 5. 不要block主线程 6. 在Image Views中调整图片大小 7. 选择正确的Collection 8. 打开gzip压缩 中级(这些是你可能在一些相对复杂情况下可能用到的) 9. 重用和延迟加载Views 10. Cache, C

Android性能调优篇之Hierarchy Viewer工具的使用

详细内容请查看我的简书地址:Android性能调优篇之Hierarchy Viewer工具的使用 或者我的个人博客地址:Android性能调优篇之Hierarchy Viewer工具的使用

性能调优攻略

关于性能优化这是一个比较大的话题,在<由12306.cn谈谈网站性能技术>中我从业务和设计上说过一些可用的技术以及那些技术的优缺点,今天,想从一些技术细节上谈谈性能优化,主要是一些代码级别的技术和方法.本文的东西是我的一些经验和知识,并不一定全对,希望大家指正和补充. 在开始这篇文章之前,大家可以移步去看一下酷壳以前发表的<代码优化概要>,这篇文章基本上告诉你--要进行优化,先得找到性能瓶颈! 但是在讲如何定位系统性能瓶劲之前,请让我讲一下系统性能的定义和测试,因为没有这两件事,后

性能调优之：缓存

在执行任何查询时,SQL Server都会将数据读取到内存,数据使用之后,不会立即释放,而是会缓存在内存Buffer中,当再次执行相同的查询时,如果所需数据全部缓存在内存中,那么SQL Server不会产生Disk IO操作,立即返回查询结果,这是SQL Server的性能优化机制. 一,主要的内存消费者(Memory Consumer) 1,数据缓存(Data Cache) Data Cache是存储数据页(Data Page)的缓冲区,当SQL Server需要读取数据文件(File)中的数

SQL 语句性能调优

经常听到有做应用的朋友抱怨数据库的性能问题,比如非常低的并发,令人崩溃的响应时间,长时间的锁等待,锁升级 , 甚至是死锁,等等.在解决这些问题的过程中,DBA 经常发现应用开发人员对数据库的"误用".包括 , 返回过多不必要的数据 , 不必要和不适当加锁,对隔离级别的误用和对存储过程的误用等等.但是,面对浩如烟海的数据库知识 , 要求完全掌握 , 对应用开发人员来说也确实枯燥艰深 . 因此,笔者特别提炼对应用开发人员有帮助的 SQL 书写部分,以期望能对数据库开发人员有所帮助. &qu

JVM性能调优

一.JVM性能调优策略 二.性能调优 1.Java线程池(java.util.concurrent.ThreadPoolExecutor) 大多数JVM6上的应用采用的线程池都是JDK自带的线程池,之所以把成熟的Java线程池进行罗嗦说明,是因为该线程池的行为与我们想象的有点出入.Java线程池有几个重要的配置参数: corePoolSize:核心线程数(最新线程数) maximumPoolSize:最大线程数,超过这个数量的任务会被拒绝,用户可以通过RejectedExecutionHandl

性能调优

性能调优 1.设计调优 宏观层面质的优化 2.代码调优 熟悉相关API,并在合适的场景中正确使用相关API或类库,同时,对算法.数据结构的灵活运用也是代码优化的重要内容 3.JVM调优 代码和JVM属于系统微观层面量的优化 4.数据库调优 使用preparestatement代替statement提高查询效率 Select,使用要查询的具体的列名,避免使用*号, 合理地使用冗余字段 Oracle的分区表 根据不同的数据,以Oracle为例,设置合理大小的共享池.缓存缓冲区或者PGA 5.操作系统

Java性能调优笔记

Java性能调优笔记 调优步骤:衡量系统现状.设定调优目标.寻找性能瓶颈.性能调优.衡量是否到达目标(如果未到达目标,需重新寻找性能瓶颈).性能调优结束. 寻找性能瓶颈 性能瓶颈的表象:资源消耗过多.外部处理系统的性能不足.资源消耗不多但程序的响应速度却仍达不到要求. 资源消耗:CPU.文件IO.网络IO.内存. 外部处理系统的性能不足:所调用的其他系统提供的功能或数据库操作的响应速度不够. 资源消耗不多但程序的响应速度却仍达不到要求:程序代码运行效率不够高.未充分使用资源.程序结构不合理. C

Spark&amp;Spark性能调优实战

Spark特别适用于多次操作特定的数据,分mem-only和mem & disk.其中mem-only:效率高,但占用大量的内存,成本很高;mem & disk:内存用完后,会自动向磁盘迁移,解决了内存不足的问题,却带来了数据的置换的消费.Spark常见的调优工具有nman.Jmeter和Jprofile,以下是Spark调优的一个实例分析: 1.场景:精确客户群 对一个容量为300g的客户信息表在spark上进行查询优化,该大宽表有1800多列,有效使用的有20列. 2.优化达到的效果: