Apache Spark

在实际使用 spark + parquet 的时候, 遇到了两个不解的地方: 我们只有一个 parquet 文件(小于 hdfs block size), 但是 spark 在某个 stage 生成了4个 tasks 来处理. 4个 tasks 中只有一个 task 处理了所有数据, 其他几个都没有处理数据. 这两个问题牵涉到对于 parquet spark 是如何来进行切分 partitions, 以及每个 partition 要处理哪部分数据的. 先说结论 , spark 中, parquet 是 splitable 的, 代码见 ParquetFileFormat#isSplitable . 那会不会把数据切碎? 答案是不会, 因为是以 spark row group 为最小单位切分 parquet 的, 这也会导致一些 partitions 会没有数据, 极端情况下, 只有一个 row group 的话, partitions 再多, 也只会一个有数据. 接下来开始我们的源码之旅: 处理流程 1. 根据 parquet 按文件大小切块生成 partitions: 在 FileSourceScanExec#createNonBucketedReadRDD 中, 如果文件是 splitable 的, 会按照 maxSplitBytes 把文件切分, 最后生成的数量, 就是

腾讯开源再次迎来重磅项目，14日，腾讯正式宣布开源高性能图计算框架Plato，这是在短短一周之内，开源的第五个重大项目。 相对于目前全球范围内其它的图计算框架，Plato可满足十亿级节点的超大规模图计算需求，将算法计算时间从天级缩短到分钟级，性能全面领先领先于其它主流分布式图计算框架，并且 打破了原本 动辄 需要数百台服 务 器的 资 源瓶 颈 ， 现 在，最少只需要十台服 务 器即可完成 计 算 。 腾讯Plato团队负责人于东海表示：“Plato已经支持腾讯内部包括微信在内的众多核心业务，尤其是为腾讯超大规模社交网络图数据的各类计算提供支撑，解决了现有其他计算框架无法在有限资源和有限时间内完成计算的难点。Plato不仅为腾讯创造了巨大的业务价值，开源后还将持续推动图计算技术和行业的协同发展，加速创新。” 实际上，图计算的“图”并不是指普通的图像和照片，而是用于表示对象之间关联关系的一种抽象数据结构，图计算就是以图作为数据模型来表达问题并予以解决的过程。图计算可以将不同来源、不同类型的数据融合到同一个图里进行分析，得到原本独立分析难以发现的结果，因此成为社交网络、推荐系统、网络安全、文本检索和生物医疗等领域至关重要的数据分析和挖掘工具。 Plato是腾讯内部图计算TGraph团队整合内部资源自主研发的一款高性能图计算框架，取名Plato是为了致敬伟大的数学家柏拉图

背景：有时候我们需要定义一个外部数据源，然后用spark sql的方式来处理。这样的好处有2点： （1）定义了外部数据源后，用起来很简洁，软件架构清晰，通过sql方式直接使用。 （2）容易分层分模块，一层层往上搭建，容易屏蔽实现细节。 这时候就需要用到定义外部数据源的方式，spark中使用起来也很简单的，所谓会者不难。 首先指定个package名，所有的类在统一的package下。比如com.example.hou。 然后定义两个东西，一个是DefaultSource，一个是BaseRelation with TableScan的子类。 DefaultSource的代码很简单，直接看代码不解释： package com.example.hou import org.apache.spark.sql.{DataFrame, SQLContext, SaveMode} import org.apache.spark.sql.sources.{BaseRelation, CreatableRelationProvider, SchemaRelationProvider} import org.apache.spark.sql.types.StructType class DefaultSource extends CreatableRelationProvider with

简介： 在我的CDH5.13集群中，默认安装的spark是1.6版本，这里需要将其升级为spark2.x版本。经查阅官方文档，发现spark1.6和2.x是可以并行安装的，也就是说可以不用删除默认的1.6版本，可以直接安装2.x版本，它们各自用的端口也是不一样的。这里做一下安装spark2.3版本的步骤记录。 一. 安装准备 csd包： http://archive.cloudera.com/spark2/csd/ parcel包： http://archive.cloudera.com/spark2/parcels/2.3.0.cloudera2/ 注意，下载对应版本的包，我的CentOS7，所以下载el7的包，若是CentOS6，就要下el6的包。 特别注意 ，如果你安装spark2.3，按照上面下载就是了，注意一下操作系统的版本；如果你不打算安装spark2.3，想安装其他版本，比如2.0，那么一定要注意下面的事项： 如果你仔细浏览过这些路径，会发现下图中，csd和parcel包会有.clouderal1和.clouderal2之分，和2.0与2.1版本之分，那么在下载parcel时也要注意，下载对应的包。即如果下载到的是.clouderal1的csd包，下载parcel包也要下载文件名中是.clouderal1的包，不能下载.clouderal2的包，同时csd2

　Apache Spark 1.3.0引入了Direct API，利用 Kafka 的低层次API从 Kafka 集群中读取数据，并且在 Spark Streaming系统里面维护偏移量相关的信息，并且通过这种方式去实现零数据丢失(zero data loss)相比使用基于Receiver的方法要高效。但是因为是Spark Streaming系统自己维护 Kafka 的读偏移量，而Spark Streaming系统并没有将这个消费的偏移量发送到Zookeeper中，这将导致那些基于偏移量的Kafka集群监控软件（比如： Apache Kafka监控之Kafka Web Console 、 Apache Kafka监控之KafkaOffsetMonitor 等）失效。本文就是基于为了解决这个问题，使得我们编写的Spark Streaming程序能够在每次接收到数据之后自动地更新Zookeeper中Kafka的偏移量。 　　我们从Spark的官方文档可以知道，维护Spark内部维护Kafka便宜了信息是存储在 HasOffsetRanges 类的 offsetRanges 中，我们可以在Spark Streaming程序里面获取这些信息： val offsetsList = rdd.asInstanceOf[HasOffsetRanges].offsetRanges

Spark的应用分为任务调度和任务执行两个部分，所有的Spark应用程序都离不开SparkContext和Executor两部分，Executor负责执行任务，运行Executor的机器称为Worker节点，SparkContext由用户程序启动，通过资源调度模块和Executor通信。 具体来说，以SparkContext为程序运行的总入口，在SparkContext的初始化过程中，Spark会分别创建DAGScheduler作业调度和TaskScheduler任务调度两级调度模块。 其中DAGScheduler是基于任务阶段的高层调度模块，它为每个Spark作业计算具有依赖关系的多个调度阶段（通常根据shuffle来划分），然后为每个阶段构建出一组具体的任务（通常会考虑数据的本地性等），然后以TaskSets（任务组）的形式提交给TaskScheduler来具体执行。而TaskScheduler则负责具体启动任务、监控和汇报任务运行情况 （1） 在Driver端初始化SparkContext。 任何spark的应用程序都包含Driver代码和Executor代码。Spark应用程序首先在Driver初始化SparkContext。因为SparkCotext是Spark应用程序通往集群的唯一路径

此文是从思维导图中导出稍作调整后生成的，思维脑图对代码浏览支持不是很好，为了更好阅读体验，文中涉及到的源码都是删除掉不必要的代码后的伪代码，如需获取更好阅读体验可下载脑图配合阅读： 此博文共分为四个部分： DAG定义 Job动态生成 数据的产生与导入 容错 ​ 策略 优点 缺点 (1) 热备 无 recover time 需要占用双倍资源 (2) 冷备 十分可靠 存在 recover time (3) 重放 不占用额外资源 存在 recover time (4) 忽略 无 recover time 准确性有损失 1. driver端容错 2. executor端容错 2.1. 热备 Receiver 收到的数据，通过 ReceiverSupervisorImpl，将数据交给 BlockManager 存储；而 BlockManager 本身支持将数据 replicate() 到另外的 executor 上，这样就完成了 Receiver 源头数据的热备过程。 而在计算时，计算任务首先将获取需要的块数据，这时如果一个 executor 失效导致一份数据丢失，那么计算任务将转而向另一个 executor 上的同一份数据获取数据。因为另一份块数据是现成的、不需要像冷备那样重新读取的，所以这里不会有 recovery time。 2.1.1. 备份 备份流程： ​ 先保存此block块

Join是关系型数据库系统的重要操作之一，一般关系型数据库中包含的常用Join：内联接、外联接和交叉联接等。如果我们想在两个或以上的表获取其中从一个表中的行与另一个表中的行匹配的数据，这时我们应该考虑使用Join，本文将通过可视化图表介绍SQL中的各种常用Join特性、原理和使用场景： 1、INNER JOIN && OUTER JOIN 2、CROSS JOIN 3、韦恩图 JOIN 全解 create table table_1 ( `id` INT (11) NOT NULL, user_name varchar(20) NOT NULL ) create table table_2 ( `id` INT (11) NOT NULL, user_name varchar(20) NOT NULL ) set sql_safe_updates=0; insert into table_1 values (1,"zhangsan_1_1"),(2,"lisi_1_1"),(3,"wangmazi_1"),(1,"zhangsan_1_2"),(2,"lisi_1_2"); select * from table_1 -- DELETE from table_1 insert into table_2 values (4,"zhaoliu_2_1"),(2,"lisi_2_1"),

一、Spark Stream、Kafka Stream、Storm等存在的问题 在设计一个低延迟、exactly once、流和批统一的，能够支撑足够大体量的复杂计算的引擎时，Spark Stream等的劣势就显现出来。Spark Streaming的本质还是一个基于microbatch计算的引擎。这种引擎一个天生的缺点就是每个microbatch的调度开销比较大，当我们要求的延迟越低，额外的开销就越大。这就导致了Spark Streaming实际上不是特别适合于做秒级甚至亚秒级的计算。 Kafka Streaming是从一个日志系统做起来的，它的设计目标是足够轻量，足够简洁易用。这一点很难满足我们对大体量的复杂计算的需求。 Storm是一个没有批处理能力的数据流处理器，除此之外Storm只提供了非常底层的API，用户需要自己实现很多复杂的逻辑。 二、Flink的优势 （1）不同于Spark，Flink是一个真正意义上的流计算引擎，和Storm类似，Flink是通过流水线数据传输实现低延迟的流处理； （2）Flink使用了经典的Chandy-Lamport算法，能够在满足低延迟和低failover开销的基础之上，完美地解决exactly once的目标； （3）如果用一套引擎来统一流处理和批处理，那就必须以流处理引擎为基础。Flink还提供了SQL/tableAPI这两个API

1.Flink架构及特性分析 Flink是个相当早的项目，开始于2008年，但只在最近才得到注意。Flink是原生的流处理系统，提供high level的API。Flink也提供 API来像Spark一样进行批处理，但两者处理的基础是完全不同的。Flink把批处理当作流处理中的一种特殊情况。在Flink中，所有 的数据都看作流，是一种很好的抽象，因为这更接近于现实世界。 1.1 基本架构 下面我们介绍下Flink的基本架构，Flink系统的架构与Spark类似，是一个基于Master-Slave风格的架构。 当 Flink 集群启动后，首先会启动一个 JobManger 和一个或多个的 TaskManager。由 Client 提交任务给 JobManager， JobManager 再调度任务到各个 TaskManager 去执行，然后 TaskManager 将心跳和统计信息汇报给 JobManager。 TaskManager 之间以流的形式进行数据的传输。上述三者均为独立的 JVM 进程。 Client 为提交 Job 的客户端，可以是运行在任何机器上（与 JobManager 环境连通即可）。提交 Job 后，Client 可以结束进程 （Streaming的任务），也可以不结束并等待结果返回。 JobManager 主要负责调度 Job 并协调 Task 做