吟啸徐行

val df = (1 to 100000).toSeq.toDF("id")val orderDF = df.orderBy("id").rdd.zipWithIndex()orderDF.filter(t=>t._1.getAs[Int]("id")==100).take(5) // 获取低排名为100的行（从0开始排名）查询结果： Array[(org.apache.spark.sql.Row, Long)] = Array(([100],99))...

1：轻易不要shuffle，例如20万个小文件（文件大小100MB，spark一个文件一个分区）的想要进行缩减5-8万的分区轻易不要repartition，而是coalase 进行分区合并

SQL1:SELECT lower(trim(user_log_acct)) as user_log_acct, after_prefr_amount_1, sale_qtty, free_goods_sale_qtty, parent_sale_ord_id, ord_flag, shop_id, main_sku_id, item_id

Spark中的事件循环处理器EventLoop实现原理并不难，虽然自己实现一个大概也不会差太多，但是感觉自己的实现在拓展性方便肯定不如Spark的EventLoop好，所以写一篇博客记录一下。事件循环处理器，顾名思义就是为了处理事件。在Spark中有DAGSchedulerEventProcessLoop事件处理器和JobGenerator的内部匿名实现的事件处理器。该事件循环处理

Spark RPC在2.0之后是完全基于Netty实现的RPC，主要核心组件有: RpcEnv、RpcEnvFactory、RpcEndpoint、RpcEndPointRef(对应到Netty的实现就是NettyRpcEnv、NettyRpcEnvFactory、NettyRpcEndpoint、NettyRpcEndPointRef)。当然还有一些其他组件，我们这里不涉及了，关于底层传输后期在

上一篇博文讲解了一下Spark RpcEnv的启动过程，参见：http://blog.youkuaiyun.com/dax1n/article/details/73699592。这次分析一下Master(Worker同理)的初始化以及OnStart、receive、receiveAndReply、OnStop方法是如何调用完成初始化的！由上一节我们已经知道Master的注册过程，最终调用org.a

如下图展示了Stage和Task逻辑上的关系Spark划分Stage准则：Shuffle依赖Stage：Stage是由一些算子组成的集合，Spark中Stage有ShuffleMapStage和ResultStageTask：Task是Worker执行单元，Task是Stage中算子的封装Task数量：由于每一个Task处理一个HDFS上的数据块，因此Task数

Spark集群中涉及分布式节点之间的通信，例如Worker启动注册信息到Master，这个过程就有消息的传输，接下来将要分一下一下消息的传输过程。首先Worker的启动还是从main方法开始，之后运行期初始化OnStart方法调用registerWithMaster完成Worker向Master的注册，registerWithMaster经过一系列调用最后调用org.apache.spark.de

1： RpcEnv是一个更宏观的Env，是Spark集群Rpc通信的基础服务环境。 每一个RpcEndPoint都有自己的RpcEnv。因此在集群启动时候，所有的节点(无论Master还是Worker)都会创建一个RpcEnv，然后将该节点注册到RpcEnv中。RpcEnv在Spark2.x版本之后就只有Netty的实现了，因此看一下RpcEnv和NettyRpcEnv的声明：

SparkContext是提交作业到集群的切入点，所以接下来讲解一下SparkContext的初始化过程。当我们使用spark-submit脚本提交一个作业之后，流程如下：提交作业之后(省略SparkSubmit的分析不走) -> 反射创建mainClass  -> 初始化SparkContext -> 使用sparkContext创建RDD -> 执行count算子run

fold算子签名：  def fold(zeroValue: T)(op: (T, T) => T): T ,算子其实就是先对rdd分区的每一个分区进行使用op函数，在调用op函数过程中将zeroValue参与计算，最后在对每一个分区的结果调用op函数，同理此处zeroValue再次参与计算！此处op函数为： val add = (x: Int, y: Int) => {

aggregate算子签名： def aggregate[U: ClassTag](zeroValue: U)(seqOp: (U, T) => U, combOp: (U, U) => U): U = withScope zeroValue是一个初始值，seqOp对每一个分区操作的函数，combOp对每一个分区结果进行操作的函数。zeroValue在seqOp的每一次调用中都会

RDD排序算子有sortBy和sortByKey两个算作，sortBy算子可以自定义排序规则，而sortByKey只能对Key使用Scala或Spark默认支持的排序规则，如果Scala或Spark不支持排序规则的话，需要使用sortBy自己实现排序规则！sortByKey的核心实现代码：class OrderedRDDFunctions extends Logging wit

Spark History Server：在运行Spark Application的时候，Spark会提供一个WEBUI列出应用程序的运行时信息；但该WEBUI随着Application的完成(成功/失败)而关闭，也就是说，Spark Application运行完(成功/失败)后，将无法查看Application的历史记录。        Spark history Serve

OverviewSpark为计算任务提供资源调度，Spark App运行在独立的一组Executor线程之上，Spark调度器可以提供应用之间的资源调度。其次，在Spark App中，会有多个Job(spark action)并发运行,这是普遍存在的通过网络请求资源，spark在SparkContext内提供资源的公平调度。Scheduling Across A

Apache Flink is an open source platform for distributed stream and batch data processing. Flink’score is a streaming dataflow engine that provides data distribution, communication, and fault toler

首先使用脚本spark-submit将作业提交，这个过程实际上就是使用shell脚本调用java命令运行的SparkSubmit类的main方法，所以我们接下来需要看一下SparkSubmit的main方法做了什么？ /** * 提交作业 * @param args */ def main(args: Array[String]): Unit = { v

尊重作者，转载至：https://www.iteblog.com/archives/1704.html　     我们在使用Spark的时候有时候需要将一些数据分发到计算节点中。一种方法是将这些文件上传到HDFS上，然后计算节点从HDFS上获取这些数据。当然我们也可以使用addFile函数来分发这些文件。 addFileaddFile方法可以接收

尊重作者，标明出处：http://www.jianshu.com/p/ebfabfbb8c0eBroadcast 就是将数据从一个节点发送到其他各个节点上去。Spark有两种方式：一种是HttpBroadcast(Spark2.1.0已经移除)，另一种是TorrentBroadcast。Driver 端：Driver 先把 data 序列化到 byteArray，然后切割成 B

之前学习过Spark Core源码，接下来一段时间研究一下Spark Streaming相关的内容！下面就从最简单的Streaming程序开始作为入口点(Receiver模式)，程序代码如下：import org.apache.spark.{SparkContext, SparkConf}import org.apache.spark.streaming.{Seconds, Streamin

Spark Streaming源码初探 (2)

本节分析一下Spark Streaming生成RDD的过程(也是生成Job的过程)，DStream是Spark Streaming的抽象数据表示，底层是RDD实现。由于RDD是为了满足Job需要的，所以触发生成RDD的职责应该是由JobGenerator负责。换句话说：RDD的生成是在Job生成过程中生成的，所以查看Job生成过程也就是RDD的生成过程。通过翻阅JobGenerator源码，J

今天同事反应他的广播不生效，看了一下代码，它的代码样子如下： def main(args: Array[String]): Unit = { val spark = SparkSession.builder().appName("BroadCastJoinLLocalDebug").master("local[*]").getOrCreate() val sc = spar...

大数据计算通常会存在大表join小表的情况，如果相对较小的表允许广播到各个executor的话，可以使用广播方式mapjoin，这样还可以避免数据倾斜。平时看文档记着有个参数是：spark.sql.autoBroadcastJoinThreshold 10485760 (10 MB) Configures the maximum size in bytes for a tabl...

Spark作业提交方式一般有两种，一种是使用spark-submit脚本进行提交作业，另一种方式是使用rest api方式，但是有时候由于集群的安全原因可能无法使用rest api方式进行提交作业，但是由于业务需要的话我们可以直接调用SparkSubmit.main方法进行api方式提交作业。（当然也可以使用ProcessBuilder执行shell脚本提交）。除了通常两种情况，Spark其实还提...

可以通过对SparkContext添加监听器实现监听作业的AppId信息： val conf = new SparkConf().setAppName("wc")//.setMaster("local[*]") //.setMaster("local[*]") val sc = new SparkContext(conf) val listener = n

困惑1：Spark Streaming微批次，Flink真正流处理系统差别在哪里？是因为消费Kafka数据的逻辑不同吗？（本文以Kafka为数据源举例）Spark Streaming微批次很容易理解，一次处理一个微批次的数据。而Flink代表的真正的流处理是一次处理一条数据。那么消费Kafka数据逻辑中，是不是在微批次中一次消费一个批次的数据，而真正流处理一次消费一个记录呢？答案是否定的。这两

Handling Late Data and Watermarking部分

毕业设计遇到的一个场景，场景如下： 基于Spark Streaming对DStream底层的RDD中的每一个数据进行在线机器学习预测，由于每一个数据都是一个用户的行为数据，需要对该用户的数据进行模型预测并将结果实时返回给用户。由于识别时候用户Id不是特征属性需要去掉，不包含在矩阵中。但是识别出来的每一个结果又需要将其和该用户Id对应起来返回给用户，这一场景需要将用户Id和结果准确绑定在一起

Spark On Yarn：在Spark On Yarn模式下部署Spark Streaming 时候，我们需要使用StreamingContext.getOrCreate方法创建StreamingContext实例，指定我们自己的checkpoint目录，用作存储checkpoint数据。容错1：当我们使用spark-submit成功提交一个程序之后，我们可以使用jps能够查看到Co

使用Java 随机数类随机生成0到Integer.MAX_VALUE之间的10GB文件，然后使用Spark计算框架进行全局排序。实现思路：可以局部排序(局部数据是全局数据的某一个范围)最后合并到全同一个文件，保证全局有序，这样可以设置一个reduce任务实现，但是对于更大量的数据容易出现OOM。如果不合并到同一个文件的话，可以将每一个分区有序的数据输出到磁盘。最后借鉴Kafka的数据管理方式建

当初搭建Spark On Yarn时候 配置yarn端获取spark运行的jar包时候，配置如下：spark.yarn.jars           hdfs:///sparkrunjar/提交程序：spark-submit --class org.apache.spark.examples.SparkPi --master yarn --deploy-mode client

org.apache.spark.SparkContext#runJob方法： /** * * @param rdd 待计算的rdd * @param func 在rdd上运行的函数(不是我们Spark具体的计算逻辑),该函数一般是Driver用来收集结果的 * @tparam T * @tparam U * @return 返回func在rd

作业提交流程：提交作业之后(省略SparkSubmit的分析不走) -> 反射创建mainClass  -> 初始化SparkContext -> 使用sparkContext创建RDD -> 执行count算子runJob(runJob是SparkContext中的)方法触发作业->调用sparkContext中dagScheduler的runJob方法->调用dagScheduler的su

在Spark Streaming中，数据抽象是DStream(离散数据流)。底层是靠封装RDD实现，而Spark Mllib是早期的机器学习库，主要也是基于RDD抽象数据集实现的算法。因此在Spark Streaming上想要使用Spark Mllib首先就要获取到DStream对应的RDD，而DStream中可以获取到RDD的方法有如下： def foreachRDD(foreachFunc

博文写的有些乱，进行一下总结吧！首先，之前凭借自己的错觉以为使用官网提供好的安装包之后就可以，后来各种实验各种问题。最后下决心进行自己编译源码进行安装。经过两天的摸索最终还是成功了！！功夫还是不负有心人的，以后要多多有耐心，细心做事。接下来言归正传，正如hive官网说的hive on spark，hive的版本要without hadoop，所以需要自行编译spark。此处没有想象

The high-level scheduling layer that implements stage-oriented scheduling. It computes a DAG of  stages for each job, keeps track of which RDDs and stage outputs are materialized, and finds a  min

转至：http://www.mamicode.com/info-detail-1655205.html译自:http://blog.cloudera.com/blog/2015/03/exactly-once-spark-streaming-from-apache-kafka/查资料时发现上面这篇文章不错，虽然是1.3的老版本的知识,但是还是有借鉴的地方，业余时间按照自己的理解翻译

Zeppelin安装参见：http://blog.youkuaiyun.com/dax1n/article/details/57079534异常信如下： WARN [2017-03-01 19:27:25,416] ({pool-2-thread-2} Hive.java[]:168) - Failed to access metastore. This class should not ac

在运行./schematool -dbType MySQL -initSchema 报错如下：File /home/daxin/bigdata/hive/scripts/metastore/upgrade/MySQL/upgrade.order.MySQLnot found 很蒙圈。去看文件也在，就是大小有区别，后来./schematool -dbType mysql -initSch