wordpress账号分享如何做网站关键字优化

当前位置： 首页 > news >正文

wordpress账号分享,如何做网站关键字优化,公司企业文化墙制作,晋中网站设计1 Map端优化 1.1 Map端聚合 map-side预聚合#xff0c;就是在每个节点本地对相同的key进行一次聚合操作#xff0c;类似于MapReduce中的本地combiner。map-side预聚合之后#xff0c;每个节点本地就只会有一条相同的key#xff0c;因为多条相同的key都被聚合起来了。其他节… 1 Map端优化 1.1 Map端聚合 map-side预聚合就是在每个节点本地对相同的key进行一次聚合操作类似于MapReduce中的本地combiner。map-side预聚合之后每个节点本地就只会有一条相同的key因为多条相同的key都被聚合起来了。其他节点在拉取所有节点上的相同key时就会大大减少需要拉取的数据数量从而也就减少了磁盘IO以及网络传输开销。 RDD的话建议使用reduceByKey或者aggregateByKey算子来替代掉groupByKey算子。因为reduceByKey和aggregateByKey算子都会使用用户自定义的函数对每个节点本地的相同key进行预聚合。而groupByKey算子是不会进行预聚合的全量的数据会在集群的各个节点之间分发和传输性能相对来说比较差。 SparkSQL本身的HashAggregte就会实现本地预聚合全局聚合。 1.2 读取小文件优化 读取的数据源有很多小文件会造成查询性能的损耗大量的数据分片信息以及对应产生的Task元信息也会给Spark Driver的内存造成压力带来单点问题。 设置参数 spark.sql.files.maxPartitionBytes128MB   默认128m spark.files.openCostInBytes4194304     默认4m 参数单位都是bytes maxPartitionBytes一个分区最大字节数。openCostInBytes打开一个文件的开销。 spark-submit –master yarn –deploy-mode client –driver-memory 1g –num-executors 3 –executor-cores 2 –executor-memory 6g –class com.atguigu.sparktuning.map.MapSmallFileTuning spark-tuning-1.0-SNAPSHOT-jar-with-dependencies.jar 源码理解 DataSourceScanExec.createNonBucketedReadRDD() FilePartition. getFilePartitions() 1切片大小 Math.min(defaultMaxSplitBytes, Math.max(openCostInBytes, bytesPerCore)) 计算totalBytes的时候每个文件都要加上一个open开销 defaultParallelism就是RDD的并行度 2当文件1大小 openCostInBytes文件2大小 openCostInBytes…文件n-1大小 openCostInBytes 文件n  maxPartitionBytes时n个文件可以读入同一个分区即满足 N个小文件总大小  N-1*openCostInBytes   maxPartitionBytes的话。 1.3 增大map溢写时输出流buffer 1map端Shuffle Write有一个缓冲区初始阈值5m超过会尝试增加到2*当前使用内存。如果申请不到内存则进行溢写。这个参数是internal指定无效见下方源码。也就是说资源足够会自动扩容所以不需要我们去设置。 2溢写时使用输出流缓冲区默认32k这些缓冲区减少了磁盘搜索和系统调用次数适当提高可以提升溢写效率。 3Shuffle文件涉及到序列化是采取批的方式读写默认按照每批次1万条去读写。设置得太低会导致在序列化时过度复制因为一些序列化器通过增长和复制的方式来翻倍内部数据结构。这个参数是internal指定无效见下方源码。 综合以上分析我们可以调整的就是输出缓冲区的大小。 spark-submit –master yarn –deploy-mode client –driver-memory 1g –num-executors 3 –executor-cores 2 –executor-memory 6g  –class com.atguigu.sparktuning.map.MapFileBufferTuning spark-tuning-1.0-SNAPSHOT-jar-with-dependencies.jar 源码理解 2 Reduce端优化 2.1 合理设置Reduce数 过多的cpu资源出现空转浪费过少影响任务性能。关于并行度、并发度的相关参数介绍在2.2.1中已经介绍过。 2.2 输出产生小文件优化 1、Join后的结果插入新表 join结果插入新表生成的文件数等于shuffle并行度默认就是200份文件插入到hdfs上。 解决方式 1可以在插入表数据前进行缩小分区操作来解决小文件过多问题如coalesce、repartition算子。 2调整shuffle并行度。根据2.2.2的原则来设置。 2、动态分区插入数据 1没有Shuffle的情况下。最差的情况下每个Task中都有表各个分区的记录那文件数最终文件数将达到  Task数量 * 表分区数。这种情况下是极易产生小文件的。 INSERT overwrite table A partition ( aa )  SELECT * FROM B; 2有Shuffle的情况下上面的Task数量 就变成了spark.sql.shuffle.partitions默认值200。那么最差情况就会有 spark.sql.shuffle.partitions  表分区数。 当spark.sql.shuffle.partitions设置过大时小文件问题就产生了当spark.sql.shuffle.partitions设置过小时任务的并行度就下降了性能随之受到影响。 最理想的情况是根据分区字段进行shuffle在上面的sql中加上distribute by aa。把同一分区的记录都哈希到同一个分区中去由一个Spark的Task进行写入这样的话只会产生N个文件, 但是这种情况下也容易出现数据倾斜的问题。 解决思路 结合第4章解决倾斜的思路在确定哪个分区键倾斜的情况下将倾斜的分区键单独拎出来 将入库的SQL拆成where 分区 ! 倾斜分区键 和 where 分区  倾斜分区键 几个部分非倾斜分区键的部分正常distribute by 分区字段倾斜分区键的部分 distribute by随机数sql如下 //1.非倾斜键部分 INSERT overwrite table A partition ( aa )  SELECT  FROM B where aa ! 大key distribute by aa; //2.倾斜键部分 INSERT overwrite table A partition ( aa )  SELECT * FROM B where aa  大key distribute by cast(rand() * 5 as int); 案例实操 spark-submit –master yarn –deploy-mode client –driver-memory 1g –num-executors 3 –executor-cores 2 –executor-memory 6g  –class com.atguigu.sparktuning.reduce.DynamicPartitionSmallFileTuning spark-tuning-1.0-SNAPSHOT-jar-with-dependencies.jar 2.3 增大reduce缓冲区减少拉取次数 Spark Shuffle过程中shuffle reduce task的buffer缓冲区大小决定了reduce task每次能够缓冲的数据量也就是每次能够拉取的数据量如果内存资源较为充足适当增加拉取数据缓冲区的大小可以减少拉取数据的次数也就可以减少网络传输的次数进而提升性能。 reduce端数据拉取缓冲区的大小可以通过spark.reducer.maxSizeInFlight参数进行设置默认为48MB。 源码BlockStoreShuffleReader.read() 2.4 调节reduce端拉取数据重试次数 Spark Shuffle过程中reduce task拉取属于自己的数据时如果因为网络异常等原因导致失败会自动进行重试。对于那些包含了特别耗时的shuffle操作的作业建议增加重试最大次数比如60次以避免由于JVM的full gc或者网络不稳定等因素导致的数据拉取失败。在实践中发现对于针对超大数据量数十亿~上百亿的shuffle过程调节该参数可以大幅度提升稳定性。 reduce端拉取数据重试次数可以通过spark.shuffle.io.maxRetries参数进行设置该参数就代表了可以重试的最大次数。如果在指定次数之内拉取还是没有成功就可能会导致作业执行失败默认为3 2.5 调节reduce端拉取数据等待间隔 Spark Shuffle过程中reduce task拉取属于自己的数据时如果因为网络异常等原因导致失败会自动进行重试在一次失败后会等待一定的时间间隔再进行重试可以通过加大间隔时长比如60s以增加shuffle操作的稳定性。 reduce端拉取数据等待间隔可以通过spark.shuffle.io.retryWait参数进行设置默认值为5s。 综合2.3、2.4、2.5案例实操 spark-submit –master yarn –deploy-mode client –driver-memory 1g –num-executors 3 –executor-cores 2 –executor-memory 6g  –class com.atguigu.sparktuning.reduce.ReduceShuffleTuning spark-tuning-1.0-SNAPSHOT-jar-with-dependencies.jar 2.6 合理利用bypass 当ShuffleManager为SortShuffleManager时如果shuffle read task的数量小于这个阈值默认是200且不需要map端进行合并操作则shuffle write过程中不会进行排序操作使用BypassMergeSortShuffleWriter去写数据但是最后会将每个task产生的所有临时磁盘文件都合并成一个文件并会创建单独的索引文件。 当你使用SortShuffleManager时如果确实不需要排序操作那么建议将这个参数调大一些大于shuffle read task的数量。那么此时就会自动启用bypass机制map-side就不会进行排序了减少了排序的性能开销。但是这种方式下依然会产生大量的磁盘文件因此shuffle write性能有待提高。 源码分析SortShuffleManager.registerShuffle() SortShuffleManager.getWriter() spark-submit –master yarn –deploy-mode client –driver-memory 1g –num-executors 3 –executor-cores 2 –executor-memory 6g  –class com.atguigu.sparktuning.reduce.BypassTuning spark-tuning-1.0-SNAPSHOT-jar-with-dependencies.jar 3 整体优化 3.1 调节数据本地化等待时长 在 Spark 项目开发阶段可以使用 client 模式对程序进行测试此时可以在本地看到比较全的日志信息日志信息中有明确的 Task 数据本地化的级别如果大部分都是 PROCESS_LOCAL、NODE_LOCAL那么就无需进行调节但是如果发现很多的级别都是 RACK_LOCAL、ANY那么需要对本地化的等待时长进行调节应该是反复调节每次调节完以后再来运行观察日志看看大部分的task的本地化级别有没有提升看看整个spark作业的运行时间有没有缩短。 注意过犹不及不要将本地化等待时长延长地过长导致因为大量的等待时长使得 Spark 作业的运行时间反而增加了。 下面几个参数默认都是3s可以改成如下 spark.locality.wait //建议6s、10s spark.locality.wait.process //建议60s spark.locality.wait.node //建议30s spark.locality.wait.rack //建议20s spark-submit –master yarn –deploy-mode client –driver-memory 1g –num-executors 3 –executor-cores 2 –executor-memory 6g  –class com.atguigu.sparktuning.job.LocalityWaitTuning spark-tuning-1.0-SNAPSHOT-jar-with-dependencies.jar 3.2 使用堆外内存 1、堆外内存参数 讲到堆外内存就必须去提一个东西那就是去yarn申请资源的单位容器。Spark  on yarn模式一个容器到底申请多少内存资源。 一个容器最多可以申请多大资源是由yarn参数yarn.scheduler.maximum-allocation-mb决定 需要满足 spark.executor.memoryOverhead spark.executor.memory spark.memory.offHeap.size ≤ yarn.scheduler.maximum-allocation-mb 参数解释 spark.executor.memory提交任务时指定的堆内内存。spark.executor.memoryOverhead堆外内存参数内存额外开销。 默认开启默认值为spark.executor.memory*0.1并且会与最小值384mb做对比取最大值。所以spark on yarn任务堆内内存申请1个g而实际去yarn申请的内存大于1个g的原因。 spark.memory.offHeap.size堆外内存参数spark中默认关闭需要将spark.memory.enable.offheap.enable参数设置为true。 注意很多网上资料说spark.executor.memoryOverhead包含spark.memory.offHeap.size这是由版本区别的仅限于spark3.0之前的版本。3.0之后就发生改变实际去yarn申请的内存资源由三个参数相加。 测试申请容器上限 yarn.scheduler.maximum-allocation-mb修改为7G将三个参数设为如下大于7G会报错 spark-submit –master yarn –deploy-mode client –driver-memory 1g  –num-executors 3 –executor-cores 4 –conf  spark.memory.offHeap.enabledtrue –conf spark.memory.offHeap.size2g  –executor-memory 5g  –class com.atguigu.sparktuning.join.SMBJoinTuning spark-tuning-1.0-SNAPSHOT-jar-with-dependencies.jar 将spark.memory.offHeap.size修改为1g后再次提交 spark-submit –master yarn –deploy-mode client –driver-memory 1g  –num-executors 3 –executor-cores 4 –conf  spark.memory.offHeap.enabledtrue –conf spark.memory.offHeap.size1g  –executor-memory 5g  –class com.atguigu.sparktuning.join.SMBJoinTuning spark-tuning-1.0-SNAPSHOT-jar-with-dependencies.jar 2、使用堆外缓存 使用堆外内存可以减轻垃圾回收的工作也加快了复制的速度。 当需要缓存非常大的数据量时虚拟机将承受非常大的GC压力因为虚拟机必须检查每个对象是否可以收集并必须访问所有内存页。本地缓存是最快的但会给虚拟机带来GC压力所以当你需要处理非常多GB的数据量时可以考虑使用堆外内存来进行优化因为这不会给Java垃圾收集器带来任何压力。让JAVA GC为应用程序完成工作缓存操作交给堆外。 spark-submit –master yarn –deploy-mode client –driver-memory 1g  –num-executors 3 –executor-cores 4 –conf  spark.memory.offHeap.enabledtrue –conf spark.memory.offHeap.size1g  –executor-memory 5g  –class com.atguigu.sparktuning.job.OFFHeapCache spark-tuning-1.0-SNAPSHOT-jar-with-dependencies.jar 3.3 调节连接等待时长 在Spark作业运行过程中Executor优先从自己本地关联的BlockManager中获取某份数据如果本地BlockManager没有的话会通过TransferService远程连接其他节点上Executor的BlockManager来获取数据。 如果task在运行过程中创建大量对象或者创建的对象较大会占用大量的内存这回导致频繁的垃圾回收但是垃圾回收会导致工作现场全部停止也就是说垃圾回收一旦执行Spark的Executor进程就会停止工作无法提供相应此时由于没有响应无法建立网络连接会导致网络连接超时。 在生产环境下有时会遇到file not found、file lost这类错误在这种情况下很有可能是Executor的BlockManager在拉取数据的时候无法建立连接然后超过默认的连接等待时长120s后宣告数据拉取失败如果反复尝试都拉取不到数据可能会导致Spark作业的崩溃。这种情况也可能会导致DAGScheduler反复提交几次stageTaskScheduler反复提交几次task大大延长了我们的Spark作业的运行时间。 为了避免长时间暂停(如GC)导致的超时可以考虑调节连接的超时时长连接等待时长需要在spark-submit脚本中进行设置设置方式可以在提交时指定 –conf spark.core.connection.ack.wait.timeout300s 调节连接等待时长后通常可以避免部分的XX文件拉取失败、XX文件lost等报错。 spark-submit –master yarn –deploy-mode client –driver-memory 1g –num-executors 3 –executor-cores 2 –executor-memory 1g –conf spark.core.connection.ack.wait.timeout300s –class com.atguigu.sparktuning.job.AckWaitTuning spark-tuning-1.0-SNAPSHOT-jar-with-dependencies.jar