spark

在Spark性能优化方面, 数据结构是重点之一。一个合理的数据结构设计不仅能够降低内存消耗，同时也能节约运行时间。下面主要针对Long与String数据类型做分析，看一面两个例子对比 1. 在RDD数据类型中，使用Long的情况 package com.haizhi.aidp import java.util.Date import com.haizhi.aidp.bigdata.SparkHelper import com.haizhi.aidp.common.base.BaseTool._ import org.apache.log4j.{Level, Logger} /** * Hello world! * */ object TestJoin { def main(args: Array[String]): Unit = { Logger.getLogger("org").setLevel(Level.ERROR) val spark = SparkHelper.getSparkContext() val rdd1 = spark.makeRDD(1 to 30000000) .flatMap(i => (0 to i % 13).map(j => (i+j, j))) .map(x => { val src = md5ToLong(md5(x._1.toString))

本期内容 exactly once 输入不重复 输出不重复 exactly once ：有且仅被执行一次。（不多，不少，一次刚好） 首先和大家聊下概念： 事务是恢复和 并发控制 的基本单位。 事务应该具有4个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为 ACID特性 。 原子性（atomicity）。一个事务是一个不可分割的工作单位，事务中包括的诸操作要么都做，要么都不做。 一致性（consistency）。事务必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与原子性是密切相关的。 隔离性（isolation）。一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。 持久性（durability）。持久性也称永久性（permanence），指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其有任何影响。 简单记忆法则(一持原隔) 如：银行转账，A向B转账500元，这个步骤可以分为A扣500元，B加500元 两部分。 如果 A减500元成功后，在B加500元的时候失败了，那么A减掉的500就不生效。也就是说。要么两个操作都成功，要么两个操作都失败。 先了解下SparkStreaming的数据流转流程 数据一致性的要求： 数据源可靠。数据源产生出来后

今天在用spark-shell测试的时候，发现报了这个错误，怎么也没想明白是什么原因。 可能是spark默认使用的压缩方式是lz4的，但是jar包又不缺，所以没有弄懂，后续弄懂了再来修改博客 目前的解决方案： 将压缩方式改成snappy，这样就不报错了，暂时能用 ./spark-shell --master local[2] --conf spark.io.compression.codec=snappy 来源： CSDN 作者： Piggy-George 链接： https://blog.csdn.net/zhc74110/article/details/104780630

大数据处理系统可以分为批式(batch)大数据和流式(streaming)大数据两类。其中，批式大数据又被称为历史大数据，流式大数据又被称为实时大数据。 目前主流的三大分布式计算系统Hadoop、Storm、Spark被广泛运用于大数据领域。 批处理大数据系统代表：Hadoop 注：这类系统虽然可对完整大数据集实现高效的即席查询，但无法查询到最新的实时数据，存在数据迟滞高等问题 流处理大数据系统代表：Spark Streaming、Storm（计算系统） 注：此类系统可以对最新实时数据实现高效预设分析处理模型的查询，数据迟滞低 1、分布式计算架构Hadoop Hadoop作为分布式系统的基础架构，数据处理工作在硬盘层面，借助HDFS(分布式文件系统)，可以将架构下每一台电脑中的硬盘资源聚集起来，不论是存储计算还是调用都可以视为一块硬盘使用。之后使用集群管理和调度软件YARN，相当于Windows操作系统，最后利用Map/Reduce计算框架就可以在这上面进行计算编程。从而大幅降低了整体计算平台的硬件投入成本。 2、流数据处理Spark和Storm 由于Hadoop的计算过程放在硬盘，受制于硬件条件限制，数据的吞吐和处理速度明显不如使用内存来的快。于是Spark和Storm开始登上舞台。 Spark和Storm两者最大的区别在于实时性：Spark是准实时

主要问题 处理流式数据的两种方法 静态数据的几种格式 要介绍流式数据的处理，首先要介绍spark的几种静态的数据结构：RDD、dataset和dataframe。 简单来讲，RDD是spark最基础的数据，可以看出一行行独立的数据，每一行内部是封闭的黑箱，在MapReduce之前不知道是啥（MapReduce是hadoop的一种计算模型，浅显一点理解就是做筛选统计之类的活的，就是下图紫色的过程）。 图出自https://blog.csdn.net/MrZhangBaby/article/details/88840635，看不清可以点进去看 Dataset是整理过的RDD，同样可以理解为一行行的数据，只是里面更有序（有了固定的结构schema） Dataframe就是Python和R里的那种dataframe，也就是最常见的带表头的表，是Dataset的特例，链接里的图就很形象 https://blog.csdn.net/weixin_42702831/article/details/82492421 RDD Dataframe Dataset 或者是 流式数据的2种处理方式 从文件里读数据，读一次就产生一个静态数据，而像日志之类的记录这种不断增长的数据，可以看做是一个瀑布流，源源不断的增长。针对这种流式数据（data stream）的处理，要么用flink

spark streaming作为当下依然火热的流计算引擎，对于kafka和elasticsearch都有很好的api支持，以下是笔者在实际生产环境中的一个数据从kafka到es案例。 首先说一下几个重点： kafka消费offset使用mysql保存 ，一开始使用了 ScalikeJDBC 这个包来实现对数据库的访问，后来感觉用起来不太灵活，所以就写了原生的mysql JDBC工具类，也有不少好处，比如事务控制更加灵活，不再需要导入ScalikeJDBC的那好几个jar包 数据库获取offset后，会与kafka最早的offset做一个校验 ，因为机器资源紧张，kafka里数据只保存一天，如果spark streaming任务因为故障或是其他原因停了一段时间，这时再开启任务从mysql获取的offset有可能会超出kafka里offset的范围，这时就要把当前的offset进行替换。如果对数据处理速度有要求的话这一步可以注释掉，等需要的时候再开启。 第一步 Maven配置 这里相关工具的版本： scala:2.11.8 spark:2.3.4 kafka:0.10.1.0 elasticsearch:7.0.0 maven配置如下： < properties > < scala.version > 2.11.8 </ scala.version > < spark.version

park性能调优的第一步，就是为任务分配更多的资源，在一定范围内，增加资源的分配与性能的提升是成正比的，实现了最优的资源配置后，在此基础上再考虑进行后面论述的性能调优策略。 指定脚本： /usr/opt/modules/spark/bin/spark-submit –class com.atguigu.spark.Analysis –num-executors 80 –driver-memory 6g –executor-memory 6g –executor-cores 3 /usr/opt/modules/spark/jar/spark.jar 第一种情况：standalone模式，第二种情况：Yarn 使用原则：你能使用的资源有多大，就尽量去调节到最大的大小（executor的数量：几十个到上百个不等；executor的 内存；exector的cpu个数） 来源： CSDN 作者： shally2759 链接： https://blog.csdn.net/shally2759/article/details/104749490

spark性能优化点 一、分配更多的资源 它是性能优化调优的王道，就是增加和分配更多的资源，这对于性能和速度上的提升是显而易见的， 基本上，在一定范围之内，增加资源与性能的提升，是成正比的；写完了一个复杂的spark作业之后，进行性能调 优的时候，首先第一步，就是要来调节优的资源配置；在这个基础之上，如果说你的spark作业，能够分配的资源达到 了你的能力范围的顶端之后，无法再分配更多的资源了，公司资源有限；那么才是考虑去做后面的这些性能调优的点。 1、分配哪些资源 executor-memory、executor-cores、driver-memory 2、在哪里设置 在实际的生产环境中，提交spark任务时，使用spark‐submit shell脚本，在里面调整对应的参数。 提交任务的脚本: spark‐submit \ ‐‐master spark://node1:7077 \ ‐‐class cn.itcast.WordCount \ ‐‐num‐executors 3 \ 配置executor的数量 ‐‐driver‐memory 1g \ 配置driver的内存（影响不大） ‐‐executor‐memory 1g \ 配置每一个executor的内存大小 ‐‐executor‐cores 3 \ 配置每一个executor的cpu个数 /export/servers

累加器 累加器用来对信息进行聚合，通常在向 Spark传递函数时，比如使用 map() 函数或者用 filter() 传条件时，可以使用驱动器程序中定义的变量，但是集群中运行的每个任务都会得到这些变量的一份新的副本，更新这些副本的值也不会影响驱动器中的对应变量。如果想实现所有分片处理时更新共享变量的功能，那么累加器可以实现想要的效果。 系统累加器 针对一个输入的文件，如果我们想计算文件中所有空行的数量，编写以下程序： scala > val notice = sc . textFile ( "/hyk/spark/words.txt" ) notice : org . apache . spark . rdd . RDD [ String ] = / hyk / spark / words . txt MapPartitionsRDD [ 1 ] at textFile at < console > : 24 scala > val blanklines = sc . longAccumulator ( "MyAccumulator" ) blanklines : org . apache . spark . util . LongAccumulator = LongAccumulator ( id : 0 , name : Some ( MyAccumulator ) ,

准备工作 import pyspark from pyspark import SparkContext from pyspark import SparkConf conf=SparkConf().setAppName("lg").setMaster('local[4]') sc=SparkContext.getOrCreate(conf) 1. aggregateByKey aggregateByKey中前一个函数是在各分区内计算的函数，后一个函数是聚合个分区结果的函数 其中zeroVal是对每个元素进行计算时的初始值，和分区无关。 rdd = sc.parallelize([('B',1),('B',2),('A',3),('A',4),('A',5)]) zeroVal = 1 mergeVal = (lambda aggregated,el:aggregated+el) #aggregated即zeroVal mergeComb = (lambda agg1,agg2:agg1+agg2) result = rdd.aggregateByKey(zeroVal,mergeVal,mergeComb) print(rdd.glom().collect()) print(result.collect()) [[('B', 1)], [('B', 2)], [('A', 3)]