作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/在Spark中作业调度的相关类最重要的就是DAGScheduler，DAGScheduler顾名思义就是基于DAG图的SchedulerDAG全称DirectedAcyclicGraph，有向无环图。简单的来说，就是一个由顶点和有方向性的边构成的图中，从任意一个顶点出发，没有任何一条路径会将其带回到出发的顶点。在作业调度系统中，调度的基础就在于判断多个作业任务的依赖关系，这些任务之间可能存在多重的依赖关系，也就是说有些任务必须先获得执行，然后另外的相关依赖任务才能执行，但是任务之间显然不应该出现任何直接或间接的循环依赖关系，所以本质上这种关系适合用DAG有向无环图来表示。概括地描述DAGScheduler和TaskScheduler（关于TaskScheduler的相关细节，在我之前的关于Spark运行模式的文章中有）的功能划分就是：TaskScheduler负责实际每个具体任务的物理调度，DAGScheduler负责将作业拆分成不同阶段的具有依赖关系的多批任务，可以理解为DAGScheduler负责任务的逻辑调度。基本概念Task任务：单个分区数据集上的最小处理流程单元TaskSet任务集：一组关联的，但是互相之间没有 ...继续阅读 (45)

作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/Tachyon是AmpLab的Li Haoyuan所开发的一个基于内存的分布式文件系统，出发点是作为AMPLAB的BDAS的一个组成部分总体设计思想从Tachyon的设计目标来看，是要提供一个基于内存的分布式的文件共享框架，需要具备容错的能力，还要体现内存的性能优势Tachyon以常见的Master/worker的方式组织集群，由Master节点负责管理维护文件系统MetaData，文件数据维护在Worker节点的内存中。在容错性方面，主要的技术要点包括：底层支持Plugable的文件系统如HDFS用于用户指定文件的持久化使用Journal机制持久化文件系统的Metadata使用Zookeeper构建Master的HA没有使用replica复制内存数据，而是采用和Spark RDD类似的Lineage的思想用于灾难恢复（这一点后面再讨论）此外为了兼容Hadoop应用，提供了HDFS兼容的API接口具体实现分析初始化流程Tachyon文件系统的初始化，其实就是创建和清空Master/worker所需的工作目录对Master节点来说这些目录包括底层持久化文件系统上的Data/worker/Journal目录 ...继续阅读 (53)

作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/Memcached和Redis作为两种Inmemory的key-value数据库，在设计和思想方面有着很多共通的地方，功能和应用方面在很多场合下(作为分布式缓存服务器使用等)也很相似，在这里把两者放在一起做一下对比的介绍基本架构和思想首先简单介绍一下两者的架构和设计思路MemcachedMemcached采用客户端-服务器的架构，客户端和服务器端的通讯使用自定义的协议标准，只要满足协议格式要求，客户端Library可以用任何语言实现。从用户的角度来说，服务器维护了一个键-值关系的数据表，服务器之间相互独立，互相之间不共享数据也不做任何通讯操作。客户端需要知道所有的服务器，并自行负责管理数据在各个服务器间的分配。在服务器端，内部的数据存储，使用基于Slab的内存管理方式，有利于减少内存碎片和频繁分配销毁内存所带来的开销。各个Slab按需动态分配一个page的内存（和4Kpage的概念不同，这里默认page为1M），page内部按照不同slab class的尺寸再划分为内存chunk供服务器存储KV键值对使用Memcached的基本应用模型如下图所示RedisRedi ...继续阅读 (21)

作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/是什么简单的说Docker是一个构建在LXC之上的,基于进程容器(Processcontainer)的轻量级VM解决方案拿现实世界中货物的运输作类比,为了解决各种型号规格尺寸的货物在各种运输工具上进行运输的问题,我们发明了集装箱Docker的初衷也就是将各种应用程序和他们所依赖的运行环境打包成标准的container/image,进而发布到不同的平台上运行从理论上说这一概念并不新鲜,各种虚拟机Image也起着类似的作用Docker container和普通的虚拟机Image相比,最大的区别是它并不包含操作系统内核.普通虚拟机将整个操作系统运行在虚拟的硬件平台上,进而提供完整的运行环境供应用程序运行,而Docker则直接在宿主平台上加载运行应用程序.本质上他在底层使用LXC启动一个Linux Container,通过cgroup等机制对不同的container内运行的应用程序进行隔离,权限管理和quota分配等每个container拥有自己独立的各种命名空间(亦即资源)包括:PID进程, MNT文件系统, NET网络, IPC, UTS主机名等与LXC有什么不同基本上你可以认为目前的Docker ...继续阅读 (37)

作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/上一篇中介绍了Spark的各种运行模式的基本流程和相关实现，这里主要分析一下各种运行模式中涉及到的一些细节问题的流程和实现Spark的各种运行模式虽然启动方式，运行位置，调度手段有所不同，但它们所要完成的任务基本都是一致的，就是在合适的位置安全可靠的根据用户的配置和Job的需要管理和运行Task，这里粗略的列举一下在运行调度过程中各种需要考虑的问题环境变量的传递Jar包和各种依赖文件的分发Task的管理和序列化等用户参数配置用户及权限控制环境变量的传递Spark的运行参数有很大一部分是通过环境变量来设置的，例如Executor的内存设置，Library路径等等。Local模式当然不存在环境变量的传递问题，在Cluster模式下，就需要将环境变量传递到远端JVM环境中去SparkContext在初始化过程中需要传递给Executor的环境变量，会在executorEnvs变量中（HashMap）中收集起来而具体如何将这些变量设置到Executor的环境中，取决于Executor的Launch方式在Spark Standalone模式中，这些变量被封装在org.apache.spark.deploy.Command中，交给A ...继续阅读 (45)

作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/Spark的运行模式多种多样，在单机上既可以以本地模式运行，也可以以伪分布式模式运行。而当以分布式的方式运行在Cluster集群中时，底层的资源调度可以使用Mesos或者是Hadoop Yarn，也可以使用Spark自带的Standalone Deploy模式Spark处于活跃的开发过程中，代码变动频繁，所以本文尽量不涉及具体的代码分析，仅从结构和流程的角度进行阐述。运行模式列表基本上，Spark的运行模式取决于传递给SparkContext的MASTER环境变量的值，个别模式还需要辅助的程序接口来配合使用，目前支持的Master字符串及URL包括：Local[N]：本地模式使用N个线程Local-cluster：伪分布式模式Spark://：Standalone Deploy模式，需要部署Spark到相关节点Mesos://：Mesos模式，需要部署Spark和Mesos到相关节点Yarn-standalone：SparkContext和任务都运行在Yarn集群中Yarn-client：SparkConext运行在本地，task运行在Yarn集群中此外还有一些用于调试的URL大致工作流程总体上来说，这些运 ...继续阅读 (33)

作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/==目标问题==MillWheel的设计目标是提供一个大规模分布式的低延迟流式数据处理框架，基本的要求包括：数据的及时可用性-也就是低延迟啦，尽可能避免不必要的中间缓冲层造成的数据延迟全局可用的数据持久性API -主要用来处理各种需要数据Buffer的场合，如Window, join类操作能处理乱序到达的数据-即数据非严格按照来源时间戳排序到达保证数据满足严格一次投递(exactly-once delivery)要求-也就是说对应用程序而言，数据不会遗漏，也不会重复接收，减轻应用程序的实现负担==核心思想==数据流程和其它的Streaming Processing系统(e.g. storm)类似，MillWheel的数据处理流程框架基本上就是一个由用户自定义的处理单元（MillWheel里叫computation）按照一定的拓扑结构连接在一起的一个有向图computation之间的数据流以(key,value, timestamp) 这样的三元组为单位组成，每个computation都可以按Key的范围动态的分布在多个的节点上运行。来自同一个KEY的数据按照时间戳顺序由一个处理 ...继续阅读 (25)

作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/==是什么==要了解Samza，最好先了解Kafka :http://blog.csdn.net/colorant/article/details/12081909samza是一个分布式的流式数据处理框架（streaming processing），它是基于Kafka消息队列来实现类实时的流式数据处理的。(准确的说，samza是通过模块化的形式来使用kafka的，因此可以构架在其他消息队列框架上，但出发点和默认实现是基于kafka)==如何实现==作为一个分布式的消息队列系统，kafka已经实现了流式处理框架底层的许多核心基础架构，把消息串联流动起来就是Streaming了。但是要构建一个可用的流式数据处理框架，还是有许多事情要做。例如生产者和消费者进程的管理，作业调度和容错处理，辅助工具和监控管理手段，更友好方便的用户接口等等，本质上说，Samza是在消息队列系统上的更高层的抽象，是一种应用流式处理框架在消息队列系统上的一种应用模式的实现。核心思想Samza的一个job的基本处理流程是一个用户任务从一个或多个输入流中读取数据，再输出到一个或多个输出流中，具体映射到kafka上就是从一个或多个topic读入数据，再写出 ...继续阅读 (32)

作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/==是什么==简单的说，Kafka是由Linkedin开发的一个分布式的消息队列系统(Message Queue)目标Scope（解决什么问题）kafka开发的主要初衷目标是构建一个用来处理海量日志，用户行为和网站运营统计等的数据处理框架。在结合了数据挖掘，行为分析，运营监控等需求的情况下，需要能够满足各种实时在线和批量离线处理应用场合对低延迟和批量吞吐性能的要求。从需求的根本上来说，高吞吐率是第一要求，其次是实时性和持久性。既有的消息队列框架或者对消息传送的可靠性提供了较高的保证，由此带来较大的负担，不能满足海量高吞吐率的要求；或者完全面向实时消息处理系统，对于批量离线处理的场合无法提供足够的缓存和持久性要求。而多数针对大数据开发应用的日志收集处理系统(e.g. scribe, flume)则通常更适合批量离线处理场合，对实时在线处理的场合支持不够。总体而言，kafka试图提供一个同时满足在线和离线处理海量数据的消息派发系统。==如何实现==kafka的集群有多个Broker服务器组成，每个类型的消息被定义为topic，同一topic内部的消息按照一定的key和算法被分区(partition)存储在不同的Broker ...继续阅读 (32)

作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/==是什么==Wasp是阿里集团开发的基于HBase的一个数据库方案，其根本出发点是仿效Google的Megastore，“在HBase系统上不牺牲线性拓展能力的同时又能提供跨行事务、索引、SQL的功能”==架构原理==其设计原理可以参考Megastore的相关论文，Wasp自己的相关设计使用文档可以在下面两个地方找到https://github.com/alibaba/wasp/wiki/Chinesehttp://wenku.baidu.com/view/c85f50d984254b35eefd345c.htmlMegastore框架的核心思想是将数据分割成不同的EntityGroup，EntityGroup的数据备份是跨Datacenter存放的，在EntityGroup内部提供完整的ACID支持，保证数据写操作在所有数据中心的同步备份。从具体实现上来看，Wasp并没有实现Megastore在跨Data Center方面的相关设计思想，仅仅只是采用了Entity Groups这样的方案来划分和管理数据。Megastore在很多设计上都是围绕超大规模的数据的并发这样一个核心思想，比如Entity Groups的跨地 ...继续阅读 (30)

作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/更多论文阅读笔记http://blog.csdn.net/column/details/cloudpaper.html==目标问题==TAO的目标问题是构建一个在Facebook这样大规模的社交类分布式应用服务中，能够从海量相关联的数据中高效的生成精确定制化内容的数据仓库。其应用场合具有全球性，海量动态变化数据，高并发查询等特性。==核心思想==Facebook的社交网络服务的数据模型是基于对象和对象之间的关联来构建的。数据主要表现为对象和关联两类，对象如用户，图片，帖子，评论，一次checkin等等，关联就是各种对象之间的关系，朋友阿，谁的帖子阿，针对哪个帖子的评论啦等等。所有对象和关联都有一个ID字段作为唯一标识。在这种应用模型下，各种离散的数据之间都有众多的关联关系，难以简单的分类处理，最终的应用展现也千变万化，因此众多的工作不是在更新数据时完成，而只能在查询时再进行处理，所以是一个read dominate的过程。Facebook原有的框架靠应用程序分别与MySQL和Memcached服务器交互来管理和缓存数据。问题在于memcached不能有效的利用上这种对象关联模型的信息，各个client也不能有效地全局规划 ...继续阅读 (57)

作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/更多论文阅读笔记http://blog.csdn.net/colorant/article/details/8256145==目标问题==下一代的Hadoop框架，支持10,000+节点规模的Hadoop集群，支持更灵活的编程模型==核心思想==固定的编程模型，单点的资源调度和任务管理方式，使得Hadoop 1.0的应用在模式上和规模上都日益表现出它的局限性。YARN的核心思想是采用两级分布式的资源调度和任务管理框架，支持模块化的任务调度组件和自定义的任务管理模块，以适应多样化的编程模式和日益增大的集群规模。YARN以container为单位调度资源和任务，可调度的资源类型为Memory（长期目标包括CPU/DISK/IO等），通过在各个任务管理框架间分配和共享资源来提高集群利用率，整体思想和Mesos十分接近。==实现==YARN的主要组成部分包括：一个全局的RM(ResourceManager)，每个Job一个的AM(ApplicationMaster)和每个节点一个的NM(NodeManager)RM内部又进一步分为调度模块(scheduler)和应用管理模块(Applications Manager)， ...继续阅读 (42)

作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/更多论文阅读笔记http://blog.csdn.net/colorant/article/details/8256145==目标问题==为了提高资源的利用率以及满足不同应用的需求，在同一集群内会部署各种不同的分布式运算框架(cluster computing framework)，他们有着各自的调度逻辑。Mesos的目标就是在不同的framework之间高效的共享硬件资源，同时简化自身的调度逻辑，使其具有尽可能大的兼容性和可扩展性，以保证在大规模集群使用环境下的鲁棒性和对各种可能的运算框架的普遍适用性。==核心思想==Mesos本质上是一个两级的分布式资源调度框架，Mesos框架本身并不负责资源最终的具体调度，而是将这一任务交给具体的运算框架的调度逻辑来执行。不同的运算框架可以自己的调度逻辑。当然，Mesos还是需要负责将可用资源提交给各个调度框架供他们调度，所以严格的来说，也是承担了预调度的任务。要使用Mesos管理资源调度，具体的运算框架需要将自己的调度逻辑注册到Mesos的master节点上，另外还需要将具体执行任务的逻辑注册到每一个Mesos的Slave节点上。每个Mesos Slave节点将本节 ...继续阅读 (37)

作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/更多论文阅读笔记http://blog.csdn.net/colorant/article/details/8256145关键字集群调度==目标问题==在大规模的集群中，为了充分利用硬件资源，通常会将各种类型(CPU密集，IO密集，批量处理，低延迟等等)的workloads运行在同一台机器上，同时随着集群规模的增大，需要调度的任务的规模也线性增大。该论文的目标是为这种应用场合提供一种能灵活适应各种类型的任务，可扩展的高性能的调度系统==核心思想==Omega的核心设计目标包括：硬件资源的高利用率，用户定义调度策略，快速调度决策过程以及兼顾各种层面的公平调度常见的调度方案大致可分为，中央集中式的调度框架，和两级式的调度框架如Mesos等，前者无论从调度规模还是调度策略的角度上来说，都很难进行扩展。后者在资源分配和并发度上受其资源可见性和锁机制的影响，也有很大的局限性。Omega的方案是围绕着资源状态共享的思想，多个并发的调度进程以乐观锁的方式访问这些共享状态来获得调度框架的可扩展性。==实现==在Omega中，全局所有的资源对于各个调度进程来说都是可见的，各调度进程都有一份资源状态的拷贝，以此为基础来调度资源，在准备好资源 ...继续阅读 (39)

作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/更多论文阅读笔记http://blog.csdn.net/colorant/article/details/8256145关键字Spanner,外部一致性,跨机房, True time==目标问题==提供一个高性能，全球规模的分布式同步备份数据库==核心思想==Spanner的设计目标是支持分布于上百个数据中心，可达百万级数量规模服务器的高性能数据库。其重点在于以较高的性能提供高可靠性和跨机房的数据一致性。Spanner以基于时间戳的方式实现了数据读写的全局一致性，而在全球规模的数据库中高效的实现这一点，其关键在于底层的TrueTime API的实现。TrueTime API的实现基于GPS和原子钟，在全球范围内保证各个服务器取得的时间的绝对误差在1-7毫秒级别以内在TrueTime API提供的精确时间戳的基础上，Spanner通过Paxos选举出来的Leader协调和管理两阶段commit的绝对时间和提交次序，进而保证数据的读写一致性。==实现==Spanner的一个集群部署称为一个Universe，每个Universe由众多Zone组成，每个Zone大致可以类比为一个BigTable的集群。Zone内部包含一个Z ...继续阅读 (41)