张包峰的博客

背景测试了一个case，用GraphX 1.6跑标准的LPA算法，使用的是内置的LabelPropagation算法包。数据集是Google web graph，(忽略可能这个数据集不是很合适)，资源情况是standalone模式，18个worker，每个worker起一个executor，50g内存，32核，数据加载成18个分区。case里执行200轮迭代，代码:import org.apache

本文主要介绍了Spark SQL里目前的CLI实现，代码之后肯定会有不少变动，所以我关注的是比较核心的逻辑。主要是对比了Hive CLI的实现方式，比较Spark SQL在哪块地方做了修改，哪些地方与Hive CLI是保持一致的。基本上Spark SQL在CLI这块的实现很靠近Hive Service项目里的CLI模块，主要类继承体系、执行逻辑差不多都一样。Spark SQL修改的关键逻辑在CLIService内的SessionManager内的OperationManager里，将非元数据查询操作的q

这是前段时间在看spark的python支持的时候，简单过了一下pyspark里的python代码，整理了一个大致流程。虽然几乎不会python，但基本上能看懂pyspark是怎么让不同虚拟机之间传输数据的、如何在python环境调用java类的、pyspark SDK的丰富程度取决于什么、需要做些什么流程和封装等。我看了下，应该只有Pyspark Internals这篇wiki里介绍了pyspark的实现机制，大体是下面这张图就可以表示

本文介绍了spark对hadoop sequencefile的读写支持，实现方式以及简单的使用方法。sequencefile和textfile类似，在上下文里有直接提供读取方法，但最终走的还是hadoopFile方法。

Catalyst定位其他系统如果想基于Spark做一些类sql、标准sql甚至其他查询语言的查询，需要基于Catalyst提供的解析器、执行计划树结构、逻辑执行计划的处理规则体系等类体系来实现执行计划的解析、生成、优化、映射工作。对应上图中，主要是左侧的TreeNodelib及中间三次转化过程中涉及到的类结构都是Catalyst提供的。至于右侧物理执行计划映射生成过程，物理执行计划基于成本的优化模型，具体物理算子的执行都由系统自己实现。 Catalyst现状在解析器方面提供的是一个简单的scala

转自：http://blog.csdn.net/idontwantobe/article/details/25938511原文：http://highlyscalable.wordpress.com/2013/08/20/in-stream-big-data-processing/作者：Ilya Katsov相当长一段时间以来，大数据社区已经普遍认识到了批量数据处理的不足。

我在自己的github上建了个flare-spark项目，本身是Apache Spark项目Master分支的镜像。在Spark的基础上，增加了flare子项目。预计大多数改动都会增量添加到flare子项目里，尽量不改变Spark本身的代码。新增的代码都会在线下机器上编译、运行成功之后再提交上来。目前的flare项目里增加了ORCFile的读取，代码方面加入了OrcfileRDD和一个FlareContext。ORCFile可以提供列裁剪和适当的过滤谓词下推。目前对于flare-spark项

介绍Spork是Pig on Spark的highly experimental版本，依赖的版本也比较久，如之前文章里所说，目前我把Spork维护在自己的github上：flare-spork。本文分析的是Spork的实现方式和具体内容。Spark Launcher在hadoop executionengine包路径下，写了一个Spark启动器，同MapReduceLauncher类似，会在launchPig的时候，把传入的物理执行计划进行翻译。MR启动器翻译的是MR的操作，以及进一步的MR

一个Spark的Job分为多个stage，最后一个stage会包括一个或多个ResultTask，前面的stages会包括一个或多个ShuffleMapTasks。ResultTask执行并将结果返回给driver application。ShuffleMapTask将task的output根据task的partition分离到多个buckets里。一个ShuffleMapTask对应一个ShuffleDependency的partition，而总partition数同并行度、reduce数目是一致的。

本文尝试从源码层面梳理Spark在任务调度与资源分配上的做法。

背景Mesos粗粒度Mesos细粒度背景顺着昨天spark standalone实现那篇文章继续扯淡，看看Mesos Scheduler的两种实现的异同。 对我来说，回过头再仔细看Spark在这一层的实现，思路又清晰了许多。Mesos粗粒度CoarseMesosSchedulerBackend，是mesos的粗粒度scheduler backend实现。简单说一下mesos的Scheduler

背景本文给出了一个简单的计算图中每个点的N度关系点集合的算法，也就是N跳关系。之前通过官方文档学习和理解了一下GraphX的计算接口。N度关系实现思路： 1. 准备好边数据集，即”1 3”, “4, 1” 这样的点关系。使用GraphLoader 的接口load成Graph 2. 初始化每个Vertice的属性为空Map 3. 使用aggregateMessages把VerticeID和

背景Apache Zeppelin提供了web版的类似ipython的notebook，用于做数据分析和可视化。背后可以接入不同的数据处理引擎，包括spark, hive, tajo等，原生支持scala, java, shell, markdown等。它的整体展现和使用形式和Databricks Cloud是一样的，就是来自于当时的demo。Mac OS上安装目前github上，zeppelin版

RDD[T]Transformations rdd api 备注 persist/cache map(f: T => U) keyBy(f: T => K) 特殊的map，提key flatMap(f: T => Iterable[U]) map的一种，类似UDTF filter(f: T => Boolean) map的一种 distinct(

执行流程数据的接收StreamingContext实例化的时候，需要传入一个SparkContext，然后指定要连接的spark matser url，即连接一个spark engine，用于获得executor。实例化之后，首先，要指定一个接收数据的方式，如val lines = ssc.socketTextStream("localhost", 9999)这样从socket接收文本数据。这个步骤

Spark Runtime里的主要层次分析，梳理Runtime组件和执行流程，DAGSchedulerJob=多个stage，Stage=多个同种task, Task分为ShuffleMapTask和ResultTask，Dependency分为ShuffleDependency和NarrowDependency面向stage的切分，切分依据为宽依赖维护waiting jobs和active job

spark在这一块的设计是优秀的。图中，app内的SchedulerBackend是可以针对不同资源管理系统实现的，包括没有画出来的ExecutorBackend。这俩兄弟是典型的面向资源的层次上的抽象。另一方面，app内的TaskScheduler是与Task的分配和执行、管理相关的，这部分与下层面向资源的部分是隔离开的，所谓是面向摆放的。换句话说，SchedulerBackend在1，2，3步之后，已经从集群里，获得了本身app的executors资源。通过它，TaskScheduler可以根据自己的

顺着昨天spark standalone实现那篇文章继续扯淡，看看Mesos Scheduler的两种实现的异同。对我来说，回过头再仔细看Spark在这一层的实现，思路又清晰了许多。

背景主体逻辑具体实现AMYarnAllocatorExecutor背景Spark on Yarn分yarn-cluster和yarn-client两种模式。 本文通过Cluster模式的TaskScheduler实现入手，梳理一遍spark on yarn的大致实现逻辑。 前提我对两种模式以及yarn任务的整体运行逻辑不是很清楚。主体逻辑cluster模式中，使用的TaskSche

DAGScheduler面向stage的调度层，为job生成以stage组成的DAG，提交TaskSet给TaskScheduler执行。每一个Stage内，都是独立的tasks，他们共同执行同一个compute function，享有相同的shuffledependencies。DAG在切分stage的时候是依照出现shuffle为界限的。

本文面向对Spark，Mesos和Zookeeper有一点了解的读者，介绍下Run Spark on Mesos with Zookeeper的方法和一些注意点。因为Spark和Mesos的相关文档里，关于结合Zookeeper之后应该怎么改写相应URL和参数这块讲得不太清楚。版本信息Zookeeper 3.4.5 stableSpark 0.8Mesos 0.13

standalone集群 默认是simple FIFO scheduler，也就是说允许接入的应用使用全量的cpu和mem。如果想要在多用户下限制，需要设置参数来控制每个应用占有的资源数，比如System.setProperty("spark.cores.max","10"), System.setProperty("spark.executor.memory ","10g")在standalone模式，yarn模式，和粗粒度的mesos模式下，都是使用static partition的方式，设定每个应用

“Tachyon是一个高容错的分布式文件系统，允许文件以内存的速度在集群框架中进行可靠的共享，就像Spark和 MapReduce那样。通过利用信息继承，内存侵入，Tachyon获得了高性能。Tachyon工作集文件缓存在内存中，并且让不同的 Jobs/Queries以及框架都能内存的速度来访问缓存文件”。因此，Tachyon可以减少那些需要经常使用的数据集通过访问磁盘来获得的次数。”

Spark0.8已于今天正式发布，是Spark成为Apache顶级孵化项目后第一次重大发布。主要有几方面最大的改动：MLlib机器学习库面世；支持YARN；Python的提升及API的丰富；增加webUI监控。历数这次重大更新的各个新增点，我最看重的是MLlib的发布，扩充了spark上机器学习基础算法库，MLbase也是初次正式面世，参照现有scala的实现，开发者完全可以开始着手丰富自己的spark机器学习库。

Shark即Hive on Spark，本质上是通过Hive的HQL解析，把HQL翻译成Spark上的RDD操作，然后通过Hive的metadata获取数据库里的表信息，实际HDFS上的数据和文件，会由Shark获取并放到Spark上运算。Shark的特点就是快，完全兼容Hive，且可以在shell模式下使用rdd2sql()这样的API，把HQL得到的结果集，继续在scala环境下运算，支持自己编写简单的机器学习或简单分析处理函数，对HQL结果进一步分析计算。Shark速度快的原因除了Spark平台提供

现在处于从3进入4的阶段，而关于Spark的构想，也还有一些东西需要去实践，新的技术需要去调研和了解。大致是有了Spark集群之后，对Mesos和YARN有一个选择问题，从Spark读取另一个Hadoop的HDFS上文件，这件事的网络延迟影响究竟有多大，毕竟现在的情况是hadoop和spark肯定是部署两套机器上，存储节点和计算节点分离，特别是基于Mesos的话，肯定是这种状态。像豆瓣的Dpark可能是和MFS上的数据打交道的，可能会比较好地解决本地化的问题，可能能检测到目标数据存在某个节点上，而把这次任务

我使用0.7.2的Spark版本，且是pre-built过的版本，支持的hadoop版本是hadoop1。在http://spark-project.org/files/上能下载的预编译过的spark版本里，凡是预编译cdh4的压缩包，下载后解压会中断，文件本身有问题。我在google论坛上发帖说明了这个问题：https://groups.google.com/forum/#!topic/spark-users/Y4iJ1458d18。所以我现在使用预编译了1代hadoop的spark，来连接2代hadoo

Spark可以搭建在Mesos上或YARN上，两个都是资源管理系统。了解资源管理系统的话，可以先参看以下几篇文章：浅谈Borg/YARN/Mesos/Torca/Corona一类系统 多集群下资源共享方案介绍 统一资源管理与调度平台(系统)介绍 淘宝借助自己的第二代集群——云梯系统，把Spark部署在了YARN上，里面是淘宝技术部对Spark的一些实战小结，也算是在捣鼓阶段。关于Mesos的论文，可以在这里下载。他的官网上文档没有github的wiki上多。Mesos搭建在了解了资源管理

前段时间断断续续通读了下Spark-0.8的源码，边读边画的一张大体的流程图 ，覆盖了最重要的几个模块及其关键类。希望对源码的细化阅读有所帮助。

Sparrow是一个去中心化(分散)的无状态的分布式调度者，为细粒度task提供低延迟的调度。在一个由次秒级的tasks组成的workload里，调度器必须每秒为百万tasks提供毫秒级别延迟的调度决策，同时容忍调度失败。Sparrow主要借助Batch Sampling + Late Binding + Constraints来达到较好的效果。下面会具体介绍Batch Sampling 和 Late Binding，而Constraints是指用户可以对每个job进行一些约束和设定，比如所有tasks必须

MLBase是Spark生态圈里的一部分，专门负责机器学习这块(出塔之外，还有负责图计算的GraphX、SQL ad-hoc查询的Shark、具备容错性查询能力的BlinkDB等)。看了MLBase的论文后，我是迫不及待想要分享一下这个ML系统。虽然对具体ML算法了解不多，但是对比类似的系统，比如Weka，Mahout而言，我感到MLBase的构想有更进一步的创新和独到之处。而且更重要的是，Spark上支持python算法包这件事情，我现在考虑的是：能打通策略组同学写的算法程序能依赖各节点上已经分配好的或自

Spark Core源码分析: RDD基础

Spark新发布的Spark SQL组件让Spark对SQL有了别样于Shark基于Hive的支持。参考官方手册，具体分三部分：其一，能在Scala代码里写SQL，支持简单的SQL语法检查，能把RDD指定为Table存储起来。此外支持部分SQL语法的DSL。其二，支持Parquet文件的读写，且保留Schema。其三，能在Scala代码里访问Hive元数据，能执行Hive语句，并且把结果取回作为RDD使用。第一点对SQL的支持主要依赖了Catalyst这个新的查询优化框架（下面会给出一些Catal

Optimizer本文分析Catalyst Optimize部分实现的对逻辑执行计划(LogicalPlan)的处理规则。Optimizer处理的是LogicalPlan对象。Optimizer的batches如下：object Optimizer extends RuleExecutor[LogicalPlan] { val batches = Bat

Catalyst作为一个实现无关的查询优化框架，在优化后的逻辑执行计划到真正的物理执行计划这部分只提供了接口，没有提供像Analyzer和Optimizer那样的实现。本文介绍的是Spark SQL组件各个物理执行计划的操作实现。把优化后的逻辑执行计划映射到物理执行操作类这部分由SparkStrategies类实现，内部基于Catalyst提供的Strategy接口，实现了一些策略，用于分辨logicalPlan子类并替换为合适的SparkPlan子类。SparkPlan继承体系如下。接下里会具体

本文是阅读《Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing》过程中，抽了局部一些关注点翻译出来的文章，没有将全文都翻译。希望这些碎片化甚至不通顺的记录，可以帮助读者取代阅读原论文。论文地址http://www.cs.berkeley.edu/~matei/papers/2012/nsdi_spark.pdf

本文介绍Spark SQL增加的Columnar模块代码实现。首先介绍Columnar内的代码结构和实现，然后介绍在SqlContext里的使用方式。

很早以前有个Pig Spork分支，尝试把Pig迁移到Spark上，但是代码很久没有更新了。目前Pig on Spark应该是在Twitter内部进行着。flare-spork是基于Spork对Pig和Spark的衔接，把Spark部分的代码迁移到了Pig 0.12.0上，并且升级了依赖和版本，升级为Scala 2.10.3，Spark 0.9.1，且兼容Hadoop 2.2.0。目前项目在Github上，地址。打算参考Spork已经做的一些东西，继续Pig on Spark的开发。Github

ArchitectureØ 把输入的SQL，parse成unresolved logical plan，这一步参考SqlParser的实现Ø 把unresolved logical plan转化成resolved logical plan，这一步参考analysis的实现Ø 把resolved logical plan转化成optimized logic

Spark 是一种与 Hadoop 相似的开源集群计算环境，在性能和迭代计算上很有看点，现在是Apache孵化的顶级项目吧。Spark 由加州大学伯克利分校 AMP 实验室 (Algorithms, Machines, and People Lab) 开发，可用来构建大型的、低延迟的数据分析应用程序。Spark 启用了内存分布数据集，除了能够提供交互式查询外，它还可以优化迭代工作负载。Spark 是在 Scala 语言中实现的，它将 Scala 用作其应用程序框架，而Scala的语言特点也铸就了大部分Spa