SunnyRivers

我们经常需要在本地用数组写一些测试数据，进行spark逻辑测试，需要借助StructType和StructField以及数组生成DataFrame，最终进行测试，这里就简单的用Java、Scala、Python三种语言实现用数组的数据创建DataFrame。

例如，当在表“t1”上使用BROADCAST提示时，即使表“t1”的统计大小超过了配置spark.sql.autoBroadcastJoinThreshold所建议的大小，Spark也会优先考虑使用“t1”作为构建侧的广播联接（取决于是否存在等联接键，可能是广播哈希联接或广播嵌套循环联接）。当联接的两边都指定了不同的联接策略提示时，Spark会优先考虑BROADCAST提示，其次是MERGE提示，然后是SHUFFLE_HASH提示，最后是SHUFFLE_REPLICATE_NL提示。

注意：在Spark中，当使用JDBC数据源进行分区读取时，如果指定了一个数值型的分区列（例如整数或浮点数），那么必须为lowerBound和upperBound提供可以转换为long类型的值。如果我们要对某个字符串作为分区列，那么可以计算分区列的hash值对分区数取模（说白了就是找个能把字符串转为数字的方法），这样就能把字符串转为数字。spark当然不可能只能用一个task读数据库，这样如果数据库数据量大了，效率将会非常低，官方提供了一些参数，可以控制并发读取数据库任务的数量。想了解所有的参数，请参考。

我们都知道join是根据某些条件把两行数据关联起来，而且也熟悉常用的一些join type，如inner、left、right等等，但是有些人可能对semi、anti或者一些语法的缩写和全写搞的不是很清楚，这篇博客就用简单明了的案例把这些都讲明白。

然而，如果您正在进行剧烈的coalesce，例如numPartitions=1，这可能会导致您的计算在比您预想的更少的节点上进行（例如，在numPartitions=1的情况下是一个节点）。传入的可选分区合并器必须是可序列化的。这导致了窄依赖，例如，如果从1000个分区到100个分区，将不会出现shuffle，而是100个新分区中的每一个都将占用当前分区的10个。通过结果可以直观的看出，reparation把所有分区的数据都进行打散并重新分区，如果有几十亿条数据，可想而知执行起来非常耗时。

Spark Schema定义了DataFrame的结构，可以通过对DataFrame对象调用printSchema()方法来获得该结构。Spark SQL提供了StructType和StructField类以编程方式指定架构。默认情况下，Spark从数据中推断schema，但有时我们可能需要定义自己的schema（列名和数据类型），尤其是在处理非结构化和半结构化数据时，本文通过示例解释了如何定义简单、嵌套和复杂的schema。

旁边的实习生一边敲着键盘一边很不开心的说：做数据开发真麻烦，数据bug排查太繁琐了，我今天数据跑的有问题，等我处理完问题重新跑了代码，发现报表的数据很多重复，准备全部删了重新跑。我：你的数据操作具备幂等性吗？实习生：啥事幂等性？数仓中的表还要考虑幂等性吗？

旁边的实习生说：我想要用spark代码中对hive库中的内部表和外部表进行删除（包括数据），咋感觉网上搜了一圈都找不到解决方案啊，spark这么鸡肋吗？我：你应该静下心来好好把spark基础知识进行全面学习。实习生：难道spark有这功能，而我没有学习过？咋弄啊？我：学习一下Spark Catalog。实习生：啥是Catalog啊？Spark Catalog是Spark SQL中的一个元数据管理组件，它提供了一个集中化的存储和查询表、视图和函数的位置。

数据序列化内存调优这两个方向都进行调优后，如果想进一步继续优化你的程序，可以参考下面的思路。

数据序列化内存调优上一篇博客已经详细介绍了数据序列化性能调优，本文主要针对内存调优进行讲解。说白了就是减少数据对内存的占用调整内存使用时有三个考虑因素：对象使用的内存量（您可能希望整个数据集都能容纳在内存中）、访问这些对象的成本以及垃圾收集的开销（如果您的对象周转率很高）。默认情况下，Java对象访问速度很快，但很容易消耗比其字段中的“原始”数据多2-5倍的空间。每个不同的Java对象都有一个“对象头”，大约有16个字节，包含指向其类的指针等信息。

在使用Spark进行数据开发的时候，避不开的一个问题就是性能调优。网上一搜一大堆所谓的调优策略很多作者自己都不知所云，导致读者看了后只会更加困惑。我们在研究一个技术的时候第一手资料永远都请参考官网，官网对性能优化不一定是最全甚至最优，但是可以解决大部分问题。数据序列化内存调优本文主要对数据序列化对性能影响进行全面性的总结。

它接受一个本地 Python 解释器的路径，可以是 Python 执行文件的绝对路径，也可以是一个可以在驱动程序中执行的 Python 可执行文件的名称。参数指定了在分布式集群的每个执行器上使用的 Python 解释器路径。这个参数通常用于指定Python解释器的路径，以确保分布式运行时使用特定版本的Python和相关的库。然而，由于 Python 的内存管理机制的限制，以及 PySpark 中的一些兼容性问题，当使用 PySpark 编程时，可能需要单独配置 Executor 的内存使用情况，即使用。

Spark提供了一种机制，可以根据工作负载动态调整应用程序占用的资源。这意味着，如果不再使用资源，应用程序可能会将资源返还给集群，并在以后有需求时再次请求这些资源。如果Spark集群中有多个应用程序共享资源，则此功能特别有用。该功能在默认情况下被禁用，并且在所有粗粒度集群管理器上可用，即Standalone模式、YARN模式、Mesos粗粒度模式和K8s模式。注意。

本文以Mysql为例。Spark作为一种强大且广泛应用于大数据处理的分布式计算框架，有着出色的性能和可伸缩性。在使用Spark处理大规模数据时，往往需要与关系型数据库MySQL进行交互。然而，由于MySQL和Spark本身的特性之间存在一些差异，直接使用Spark读写MySQL的默认配置可能会导致性能瓶颈。因此，本篇博客将介绍一些优化技巧来加速Spark读写MySQL的过程。

旁边的实习生一脸困惑：我把一个dataset的数据往某个文件夹或hive表中写的时候可以用partitionBy对数据进行分区，可是repartition顾名思义也好像与分区有关，这两个究竟有啥区别？我该如何使用？

实习生带着一脸坚毅的神情，斩钉截铁的告诉我：我：你怎么创建的？实习生：就下面一个简单的sql语句啊id int,""")我：你需要对Spark和Hive的基础知识进行巩固。

随着Spark版本的不断迭代，SparkSQL底层使用了各种优化技术，无论方便性、性能都已经超越了RDD。因此SparkSQL已经是最常用的Spark开发方式，因此，这里把常用的SparkSQL性能优化技术进行汇总。

该想法的原因：Shuffle的时候把Key的数据可以分到不同的Task里。但是，现在的倾斜的Key非常多，成千上万，所以如果说采样找出倾斜的Key的话，并不是一个非常好的想法。需要考虑当前程序能够使用的Core的数目，扩容的问题是来解决从程序运行不了的问题，从无法运行到能运行的结果。该方案更多的是缓解数据倾斜，而不是彻底避免数据倾斜，而且需要对整个RDD进行扩容，对内存资源要求很高。同时对另外一个正常的RDD进行扩容，将每条数据都扩容成n条数据，扩容出来的每条数据都依次打上一个0~n的前缀。

对倾斜的Keys采样进行单独的Join操作步骤有点复杂：首先对RDD1进行采样，例如RDD1进行Sample抽样（15%）可以计算出一个结果，其是一个RDD，采样之后进行Map操作，通过reduceBykey操作计数，然后对Key和Value进行置换，通过SortByKey进行排序，再进行Map置换操作，从而找出哪一个Key值倾斜比较严重，对其进行过滤，提取到RDD11中，剩下的提取到RDD12中。避免了占用过多内存。如果倾斜的Key特别多，如50多个倾斜的Key，我们可以一个一个地对Key进行过滤处理。

为什么要在Mapper端Join解决数据倾斜有一个技巧：把Reducer端的操作变成Mapper端的Reduce，通过这种方式不需要发生Shuffle。如果把Reducer端的操作放在Mapper端，就避免了Shuffle。避免了Shuffle，在很大程度上就化解掉了数据倾斜的问题。Spark是RDD的链式操作，DAGScheduler根据RDD的不同类型的依赖关系划分成不同的Stage，所谓不同类型的依赖关系，就是宽依赖、窄依赖。当发生宽依赖的时候，把Stage划分成更小的Stage。划分的依据就是宽依

随机Key双重聚合是指Spark分布式计算对RDD调用reduceByKey等聚合类Shuffle算子进行计算，使用对Key值随机数前缀的处理技巧，对Key值进行二次聚合。第一次聚合（局部聚合）：对每个Key值加上一个随机数，执行第一次reduceByKey聚合操作。第二次聚合（双重聚合）：去掉Key值的前缀随机数，执行第二次reduceByKey聚合，最终得到全局聚合的结果。

提高reducer端并行度操作起来并不难，这里把它当做一个单独的方案，原因是：现在的spark程序，我们一般刚开始主要考虑的业务，对于代码写的是否忽略的性能的问题很多时候可能并不是项目一开始要考虑的事情。只有当代码经过测试的时候，可能才发现由于数据倾斜造成某个task运行缓慢，此时，我们不会一上来就做一些比如给key加随机前缀和扩容处理，而往往第一步想到的就是提高Reducer端并行度。

为什么把源数据预处理和过滤掉倾斜的key两种处理倾斜的方式写到一起？因为这两种方式在实际的项目中场景较少而且单一，对于数据源预处理，比如原本要在spark中进行聚合或join的操作，提前到hive中去做，这种方式虽然解决了spark中数据倾斜的问题，但是hive中依然也会存在；而过滤倾斜的key的场景就更加少了。不过虽然少见，也需要有这样的解决问题思维。

并行处理数据集的某个task处理的数据明显多于其他task。

实习生：我只是想用pyspark用local模式本地测试一下读写mysql数据库，咋一直报找不到驱动的错啊？我：你代码中引入驱动jar包了吗？实习生： …呃…，可是我用scala或者java用local模式也没有引入驱动jar包啊我：你用scala如何用local模式读写到mysql数据的？

实习生：怎么知道我的spark代码中哪些是在driver端运行，哪些是在executor端运行？我：算子中的部分就在executor，其它的在driver实习生：…呃…你能证明你说的是对的吗？

又来了一个面试者…我：spark有哪些部署模式，他们有什么区别面试者：我们是用yarn来进行资源管理，部署spark有两种模式client和cluster，client用于测试，cluster用于生产我：还有呢面试者：…呃…client会造成网卡流量激增我：怎么理解网卡流量激增？client模式为什么会造成网卡流量激增面试者：…我：还有哪些区别呢？面试者：…在Spark中，driver程序是指驱动整个应用程序的主进程，它运行在应用程序的主机上。

百度百科对DAG无回路有向图。Spark的DAG（有向无环图）是一个基本概念，在Spark执行模型中起着至关重要的作用。DAG是“定向的”，因为操作是按特定顺序执行的，而“非循环的”是因为执行计划中没有循环或循环。这意味着每个阶段都取决于前一阶段的完成情况，并且一个阶段中的每个任务都可以独立运行。在高层，DAG表示Spark作业的逻辑执行计划。提交Spark应用程序时，Spark会将应用程序代码中指定的高级操作（如transformation和action）转换为stage和task的DAG。

之前写过一篇如果大概评估一个DataSet大小的博客。这一篇将更加方便地来计算出一个RDD或DataFrame的大小。

今天面试一个大数据开发工程师，spark相关的知识感觉都能懂一点，但是连基础的RDD稍微一问深一点就不知所云，这种情况基本上是无法通过面试的，今天想用通俗的话把RDD说明白。弹性分布式数据集）是Spark中最基本的数据抽象，代表不可变、可分区、可并行计算的集合。RDD允许将计算结构缓存到内存中，这样当后续计算需要这些数据时，就能快速从内存中加载它们，这样不但提高数据的复用性，还提高了数据的计算效率。RDD主要特点包括并行计算自动容错数据本地性调用等。

我：什么是RDD？面试者：RDD是被分区的，由一系列分区组成…我：你怎么理解分区？面试者：…我：Spark中有哪些可以实现分区的方法？分别使用的场景是什么？面试者…我：Spark默认分区数是多少？如何保证一个分区对应一个文件？面试者…Spark分区是将大型数据集划分为较小的数据块，每个数据块称为分区，分区是一个逻辑数据块，对应相应的物理块Block。每个分区都可以在集群中的不同节点上并行处理，这样可以提高Spark的并行性和性能。

Spark应用程序是粗粒度的，也就是说在提交的时候就得规划好需要多少资源，设定了不合适的资源也会影响整体性能。yarn.nodemanager.resource.memory-mb 每个nodemanager分配的内存，也就是该节点上YARN可使用的物理内存总量。官方。

如果一大一小两个Dataset进行join，每个woker的内存足够存放小的Dataset，此时最好的处理方式就是将小的Dataset进行广播，有关广播的知识可以参考这篇文章。

先说一下为什么Spark会引入广播变量？我们在driver端定义了一个变量，如果要在executor端使用，spark会为把这个变量以task的形式给每个executor发送，也就是有多少个task，每个executor中就会有多少个变量，如果该变量是个集合，而且比较大，甚至会导致内存溢出。因此，引入了广播变量来解决这种问题。下面会用实际案例进行详细描述。

众所周知，collect算子会把所有数据拉到driver端，如果数据量太大，直接会造成内存溢出。但是该算子在很多实际场景中会经常用到，这个时候就需要采取一定地方优化措施了。