kryo

Spark调优主要分为开发调优、资源调优、数据倾斜调优、shuffle调优几个部分。开发调优和资源调优是所有Spark作业都需要注意和遵循的一些基本原则，是高性能Spark作业的基础；数据倾斜调优，主要讲解了一套完整的用来解决Spark作业数据倾斜的解决方案；shuffle调优，面向的是对Spark的原理有较深层次掌握和研究的同学，主要讲解了如何对Spark作业的shuffle运行过程以及细节进行调优。 本文作为Spark性能优化指南的基础篇，主要讲解开发调优以及资源调优。 一 开发调优 调优概述 Spark性能优化的第一步，就是要在开发Spark作业的过程中注意和应用一些性能优化的基本原则。开发调优，就是要让大家了解以下一些Spark基本开发原则，包括：RDD lineage设计、算子的合理使用、特殊操作的优化等。在开发过程中，时时刻刻都应该注意以上原则，并将这些原则根据具体的业务以及实际的应用场景，灵活地运用到自己的Spark作业中。 1 避免创建重复的RDD 通常来说，我们在开发一个Spark作业时，首先是基于某个数据源（比如Hive表或HDFS文件）创建一个初始的RDD；接着对这个RDD执行某个算子操作，然后得到下一个RDD；以此类推，循环往复，直到计算出最终我们需要的结果。在这个过程中，多个RDD会通过不同的算子操作（比如map、reduce等）串起来，这个“RDD串”

第一章 Spark 性能调优 1.1 常规性能调优 1.1.1 常规性能调优一：最优资源配置 Spark性能调优的第一步，就是为任务分配更多的资源，在一定范围内，增加资源的分配与性能的提升是成正比的，实现了最优的资源配置后，在此基础上再考虑进行后面论述的性能调优策略。 资源的分配在使用脚本提交 Spark任务时进行指定，标准的Spark任务提交脚本如代码清单2-1所示： 代码清单 2-1 标准 Spark 提交脚本 /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 \ 可以进行分配的资源如表 2-1所示： 表 2-1 可分配资源表 名称 说明 --num-executors 配置Executor的数量 --driver-memory 配置Driver内存（影响不大） --executor-memory 配置每个Executor的内存大小 --executor-cores 配置每个Executor的CPU core数量 调节原则

搭建集群： SPARK_WORKER-CORES : 当计算机是32核双线程的时候，需要指定SPARK_WORKER_CORES的个数为64个 SPARK_WORKER_MEMORY : 任务提交： ./spark-submit --master node:port --executor-cores --class ..jar xxx --executor-cores: 指定每个executor使用的core 的数量 --executor-memory: 指定每个executor最多使用的内存 --total-executor-cores: standalone 集群中 spark application 所使用的总的core --num-executor ： 在yarn 中为 spark application 启动的executor --Driver-cores: driver使用的core --Driver-memory： driver使用的内存 以上的参数是在spark-submit 提交任务的时候指定的，也可以在spark-defaults.xml中进行配置 spark 并行度调优： (一般在做测试的时候使用) sc.textFile(xx,minnum) sc.parallelize(seq,num) sc.makeRDD(seq,num) sc

一、前述 Spark中调优大致分为以下几种 ， 代码调优，数据本地化，内存调优，SparkShuffle调优，调节 Executor的堆外内存。 二、具体 1、代码调优 1、避免创建重复的RDD，尽量使用同一个RDD 2、对多次使用的 RDD进行持久化 如何选择一种最合适的持久化策略？ 默认情况下，性能最高的当然是 MEMORY_ONLY，但前提是你的内存必须足够足够大，可以绰绰有余地存放下整个RDD的所有数据。因为不进行序列化与反序列化操作，就避免了这部分的性能开销；对这个RDD的后续算子操作，都是基于纯内存中的数据的操作，不需要从磁盘文件中读取数据，性能也很高；而且不需要复制一份数据副本，并远程传送到其他节点上。但是这里必须要注意的是，在实际的生产环境中，恐怕能够直接用这种策略的场景还是有限的，如果RDD中数据比较多时（比如几十亿），直接用这种持久化级别，会导致JVM的OOM内存溢出异常。 如果使用 MEMORY_ONLY级别时发生了内存溢出，那么建议尝试使用MEMORY_ONLY_SER级别。 该级别会将RDD数据序列化后再保存在内存中，此时每个partition仅仅是一个字节数组而已，大大减少了对象数量，并降低了内存占用。这种级别比MEMORY_ONLY多出来的性能开销，主要就是序列化与反序列化的开销。但是后续算子可以基于纯内存进行操作，因此性能总体还是比较高的。此外

性能调优相关的原理讲解、经验总结； 掌握一整套Spark企业级性能调优解决方案；而不只是简单的一些性能调优技巧。 针对写好的spark作业，实施一整套数据倾斜解决方案：实际经验中积累的数据倾斜现象的表现，以及处理后的效果总结。 调优前首先要对spark的作业流程清楚： Driver到Executor的结构； Master: Driver |-- Worker: Executor |-- job |-- stage |-- Task Task 一个Stage内， 最终的RDD有多少个partition，就会产生多少个task ，一个task处理一个partition的数据； 作业划分为task分到Executor上，然后一个cpu core执行一个task； BlockManager负责Executor，task的数据管理，task来它这里拿数据； 1.1 资源分配 性能调优的王道：分配更多资源。 分配哪些资源？ executor、cpu per executor、memory per executor、driver memory 在哪里分配这些资源？ 在我们在生产环境中，提交spark作业时，用的spark-submit shell脚本，里面调整对应的参数 /usr/local/spark/bin/spark-submit \ --class cn.spark.sparktest

  众所周知，这几年微服务、云原生提得很火热。2017年，当时公司的领导刘巍，敏锐得提出公司转型微服务。那时，提到微服务大家一头雾水，经过两年的实践，逐渐有了一些心得。但有个问题始终萦绕在微服务开发者的头上，分布式事务到底如何解决，有没有比较完美的方案？二阶段提交、柔性事务、最终一致性？   2019 年，我注意到阿里巴巴的同学在社区调研分布式事务需求，立即加入了社区群。在 seata 0.2 版本的时候，当时还不叫 seata，叫 fescar，我看到 seata 代码仓库里只有 dubbo 结合 seata 的 sample，随即在博客园写了一篇 spring boot 如何结合 seata 的博文 Spring Boot微服务如何集成seata解决分布式事务问题？ ，这篇文章后来被收录到 seata wiki 里面，收获到了 18000+ 的阅读量，是我阅读量最高的一篇博客。   后来，由于工作比较忙，屡次想参与 seata 贡献，发现了几个 bug，本来想修改来着，结果看社区里边已经有人在做了😂。   由于接触微服务，自然而然接触到 k8s 技术，接触到云原生，接触到 golang。个人对 golang 比较感兴趣，比较看好它的未来。看到社区里面也有关于 seata go client 的呼声，遂萌生了打造 golang 版 seata 的想法。   有人问：喂，同学

1.概述 　　Spark Streaming的主要应用方向是实时计算.这代表一个Spark Streaming应用必然是对执行性能和运行稳定性( 7 x 24 )有一定要求的 2.性能 　　在性能方面,主要是合理的利用的集群资源,设置正确的批处理大小( 提升并行度 )和减少每个批次的处理时间( 计算逻辑优化 ).以让数据流处理的能像接受一样快 　　 2.1 调整Spark配置参数 　　　　 　　 2.2 数据接收优化 　　　　一个Spark Streaming 应用的开端便是数据接收,那么性能调优的第一步就是保证:数据不会在数据接收器端产生积压. 　　　　 2.2.2 及时的处理数据以防止数据积压 　　　　　　如果批处理时间( batch processing time )超过批次间隔( batchinterval ), 那么显然数据会不断的积压( receiver 的内存将会开始填满 ) , 最终会抛出 exceptions( 最可能是 BlockNotFoundException ). 　　　　　　考虑提升并行度等方法,以加快批次处理速度. 　　　　　　适度加大批次间隔,如果这样能及时在下个批次触发之前将数据处理完 　　　　 使用 SparkConf 配置 spark.streaming.receiver.maxRate ,可以限制receiver的接受速率 　　　　 2.2

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 本文主要梳理 Kryo 序列化基本实现。重点剖析 Kryo # writeClassAndObject、Kryo # readClassAndObject 方法。 1、源码分析Kryo#writeClassAndObject public void writeClassAndObject (Output output, Object object) { if (output == null) throw new IllegalArgumentException("output cannot be null."); beginObject(); // @1 try { if (object == null) { writeClass(output, null); // @2 return; } Registration registration = writeClass(output, object.getClass()); // @3 if (references && writeReferenceOrNull(output, object, false)) { // @4 registration.getSerializer().setGenerics(this, null)

摘自： https://www.cnblogs.com/wukenaihe/p/3732141.html 1. Kerberos简介 1.1. 功能 一个安全认证协议 用tickets验证 避免本地保存密码和在互联网上传输密码 包含一个可信任的第三方 使用对称加密 客户端与服务器（非KDC）之间能够相互验证 Kerberos只提供一种功能——在网络上安全的完成用户的身份验证。它并不提供授权功能或者审计功能。 1.2. 概念 首次请求，三次通信方 the Authentication Server the Ticket Granting Server the Service or host machine that you’re wanting access to. 图 1‑1 角色 其他知识点 每次通信，消息包含两部分，一部分可解码，一部分不可解码 服务端不会直接有KDC通信 KDC保存所有机器的账户名和密码 KDC本身具有一个密码 2. 3次通信 　　我们这里已获取服务器中的一张表（数据）的服务以为，为一个http服务。 2.1. 你和验证服务 　　如果想要获取http服务，你首先要向KDC表名你自己的身份。这个过程可以在你的程序启动时进行。Kerberos可以通过kinit获取。介绍自己通过未加密的信息发送至KDC获取Ticket Granting Ticket (TGT)。

1、前言 在大数据计算领域，Spark已经成为了越来越流行、越来越受欢迎的计算平台之一。Spark的功能涵盖了大数据领域的离线批处理、SQL类处理、流式/实时计算、机器学习、图计算等各种不同类型的计算操作，应用范围与前景非常广泛。在美团•大众点评，已经有很多同学在各种项目中尝试使用Spark。大多数同学（包括笔者在内），最初开始尝试使用Spark的原因很简单，主要就是为了让大数据计算作业的执行速度更快、性能更高。 然而，通过Spark开发出高性能的大数据计算作业，并不是那么简单的。如果没有对Spark作业进行合理的调优，Spark作业的执行速度可能会很慢，这样就完全体现不出Spark作为一种快速大数据计算引擎的优势来。因此，想要用好Spark，就必须对其进行合理的性能优化。 Spark的性能调优实际上是由很多部分组成的，不是调节几个参数就可以立竿见影提升作业性能的。我们需要根据不同的业务场景以及数据情况，对Spark作业进行综合性的分析，然后进行多个方面的调节和优化，才能获得最佳性能。 笔者根据之前的Spark作业开发经验以及实践积累，总结出了一套Spark作业的性能优化方案。整套方案主要分为开发调优、资源调优、数据倾斜调优、shuffle调优几个部分。开发调优和资源调优是所有Spark作业都需要注意和遵循的一些基本原则，是高性能Spark作业的基础；数据倾斜调优