⑴ 分布式任务调度系统Akkaflow介绍
akkaflow 是一个基于 akka 架构上构建的分布式高可用ETL工作流调度工具，可以把任务分发在集群中不同的节点上并行执行，高效利用集群资源，支持时间及任务混合触发；提供多让羡数种节点类型。其中工作流由xml文件，并且提供一套完整的基于Shell的操作命令集，简洁易用，长期稳定运行，可作为构建数据仓库、或大数据平台上的调度工具。
用户提交的xml工作流定义文件，满足触发条件后，系统会触发执行工作流；实例运行产生的各类数据将被记录并提供用户查看与进一步操作，其中
整个 akkaflow 架构目前包含有四个节点角坦首派念色：Master、Master-Standby、Worker、Http-Server，每个角色可以独立部署于不同机器上，支持高可用。
节点角色关系图
注意 ：akkaflow工作流定义可以存放于xmlconfig下，akkaflow启动时，会自动并一直扫描xmlconfig下面的文件，生成对应的worflow提交给Master，所以工作流文件，也可以放到该目录中，安装包下的xmlconfig/example下有工作流定义示例。
执行 ./sbin/stop-cluster , 关闭集群系统
注意: 除了节点启动命令，把工作流定义的xml文件放在xmlconfig目录下，可自动扫描添加对应工作流或调度器，也可以用命令提交.
⑵ 20分钟看懂大数据分布式计算
这是一篇科普性质的文章，希望能过用一个通俗易懂的例子给非计算机专业背景的朋友讲清楚大数据分布式计算技术。大数据技术虽然包含存储、计算和分析等一系列庞杂的技术，但分布式计算一直是其核心，想要了解大数据技术，不妨从MapRece分布式计算模型开始。该理论模型并不是什么新理念，早在2004年就被Google发布，经过十多年的发展，俨然已经成为了当前大数据生态的基石，可谓大数据技术之道，在于MapRece。
在进慎弯粗入到分布式计算技术这个概念之前，我们要先回顾一下传统计算技术，为了使计算机领域的相关概念能够生动形象深入浅出，我们要将计算机类比为人：
下面我们要用一个简单的案例，分析“人型计算机”是如何利用传统计算技术解决实际问题的。在开始之前，要增加一些限定，如同正常计算机的内存是有上限的，我们的“人型计算机”也存在记忆力的上限，这里我们假设一个“人型计算机”最多可以同时在“内存”中记住4种信息，例如：苹果、梨等四种水果的个数：
好了，背景知识已经足够了，让我们进入正题
首先，什么闹知是分布式计算？简单点理解就是将大量的数据分割成多个小块，由多台计算机分工计算，然后将结果汇总。这些执行分布式计算的计算机叫做集群，我们仍然延续前文中人和计算机的类比，那么集群就是一个团队，单兵作战的时代已经过去，团队合作才是王道：
为什么需要分布式计算？因为“大数据”来了，单个计算机不够用了，即数据量远远超出单个计算机的处理能力范围：有时候是单位时间内的数据量大，比如在12306网上买票，每秒可能有数以万计的访问；也有可能是数据总量大，比如网络搜索引擎，要在服务器上检索数亿的中文网页信息。
实现分布式计算的方案有很多，在大数据技术出现之前就已经有科研人员在研究，但一直没有被广泛应用。直到2004年Google公布了MapRece之后才大热了起来。大数据技术、分布式计算和MapRece的关系可以用下图来描述，MapRece是分布式计算在大数据领域的应用：
MapRece模型是经过商业实践的成熟的分布式计算框架，与Google的分布式文件系统GFS、分布式数据存储系统BigTable一起，号称Google的大数据“三宝”，为大数据技术的发展提供了坚实的理论基础。但遗憾的是，谷歌并没有向外界公布自己的商业产品，而真正让大数据技术大踏步前进的是按照Google理论实现的开源免费产品Hadoop，目前已经形成了以Hadoop为核心的大数据技宽镇术生态圈。
让我们回到数扑克牌这个例子中，大数据时代的扑克牌问题是什么样子的？
我个人在查阅了一些资料、进行了一些实践以后，认为MapRece的技术可以简单地用四字诀来总结：分、变、洗、合，分别代表“切分”、“变换”、“洗牌”、“合并”四个步骤：
下面来看如何用四字诀解决大数据扑克牌问题。
既然单个“人型计算机”无法完全处理完所有的扑克，那么我们就把扑克牌随机分成多份，每份扑克牌由一个“人型计算机”来处理，个数不超过单个计算机的处理上限，而且尽量让每份的数量比较平均。
这里我们要讲一下角色分工的问题，多台计算机合作，肯定要有角色分工，我们把负责数据切分的“人型计算机”可以理解为“指挥官”，“指挥官”一般只有一个（在实际中可能有多个），统筹调度之类的工作都归他管。负责执行具体运算任务的“人型计算机”则是“计算兵”，“计算兵”按照承担的任务不同分为“变计算兵”和“合计算兵”，前者负责第二步“变换“，后者负责最后一步“合并“。
“指挥官”在切分扑克牌之前，会先分配好“变计算兵”和“合计算兵”的数量，然后根据“变计算兵”的数量把扑克拆分成相应的份数，将每份扑克分给一个“变计算兵”，然后进入下一步。
每一个“变计算兵”都要对自己分得的每一张扑克牌按照相同的规则做变换，使得后续的步骤中可以对变换后的结果做处理。这种变换可以是加减乘除等数学运算，也可以是对输入数据的结构的转换。例如对于我们这个扑克牌问题来讲，目的是为了计数，所以可以将扑克牌转换为一种计算机更容易处理的数值结构：将每张扑克牌上贴一张小便签，这条小便签上写明了其个数为1。
我们把这种贴了标签的扑克牌叫做变种扑克牌。当在后续的步骤中统计牌型个数时，只需要把每个标签上的数字加起来就可以。有的朋友肯定会好奇为什么不让每个“计算兵”直接统计各自的所有牌型的扑克的个数，这是因为这种“映射变换”运算的本质在于将每张扑克牌都进行同一种相同规则的变换，统计个数的工作要留在最后一步完成。严格的流水化操作，会让整体的效率更高，而且变换的规则要根据具体问题来制定，更容易适配不同种类的计算。
变换的运算完成之后，每个“变计算兵”要将各自的变种扑克牌按照牌型分成多个小份，每个小份要最终被一个指定的“合计算兵”进行结果合并统计，这个过程就是“洗牌”，是“变计算兵”将变换后的扑克牌按照规则分组并分配给指定的“合计算兵”的过程。
洗牌分两个阶段，第一阶段是每个“变计算兵”将变种扑克牌按照一定的规则分类，分类的规则取决于每个“合计算兵”的统计范围，分类的个数取决于“合计算兵”的个数。如上图所示，假设有3个“合计算兵”分别负责不同范围的牌型的统计，那么“变计算兵”需要根据每个“合计算兵”负责的牌型将自己的变种扑克牌分成3个小份，每份交给对应的“合计算兵”。洗牌的第二阶段，“合计算兵”在指挥官的指挥下，去各个“变计算兵”的手中获取属于他自己的那一份变种扑克牌，从而使得牌型相同的扑克牌只会在一个“合计算兵”的手上。洗牌的意义在于使相同牌型的变种扑克牌汇聚在了一起，以便于统计。
“合计算兵”将手中的变种扑克牌按照相同的计算规则依次进行合并，计算规则也需要根据具体问题来制定，在这里是对扑克牌上标签的数值直接累加，统计出最终的结果。
然后所有的“合计算兵”把自己的计算结果上交给“指挥官”，“指挥官”汇总后公布最终统计的结果。
ok，“分变洗合”四字诀介绍完毕，完整过程如下：
分布式处理技术在逻辑上并不复杂，但在具体的实现过程中会有很多复杂的过程，譬如“指挥官”如何协调调度所有的“运算兵”，“运算兵”之间如何通信等等，但对于使用MapRece来完成计算任务的程序员来讲，这些复杂的过程是透明的，分布式计算框架会自己去处理这些问题，程序员只需要定义两种计算规则：第二步中变换的规则和第四步中合并的规则。
正所谓大道至简，万变不离其宗，理解了MapRece就理解了大数据分布式处理技术，而理解大数据分布式处理技术，也就理解了大数据技术的核心。
如果你还没有理解或者发现了文中的逻辑漏洞，欢迎留言讨论。
⑶ 大数据入门(四) - 分布式资源调度——YARN框架
YARN是Hadoop2.x才有的，所以在介绍YARN之前，我们先看一下MapRece1.x时所存在的问题：
可以看到，1.x时,即 Master/Slave 主从结构，在集群上的表现就是一个 JobTracker 带多个 TaskTracker
由于1.x版本不支持其他框架的作业，所以导致我们需要根据不同的框架去搭建多个集群。这样就会导致资源利用率比较低以及运维成本过高，因为多个集群会导致服务环境比较复杂
在上图中我们可以看到，不同的框架不仅需要搭建不同的集群
而且这些集群很多时候并不是总是在工作，如上图可以看到，Hadoop集群在忙的时候Spark就比较闲，Spark集群比较忙的时候Hadoop集群就比较闲，而MPI集群则是整体并不是很忙
这样就无法高效的利用资源，因为这些不同的集群无法互相使用资源
除此之外，我们还得运维这些个不同的集群，而且文件系统是无法共享的
如果当需要将Hadoop集群上的HDFS里存储的数据传输到Spark集群上进行计算时，还会耗费相当大的网络IO流量
所以我们就想着要把这些集群都合并在一起，让这些辩纤不同的框架能够运行在同一个集群上，这样就能解决这各种各样的问题了.如下
正是因为在1.x中，有各种各样的问题，才使得YARN得以诞生，而YARN就可以令这些不同的框架运行在同一个集群上，并为它们调度资源
在上图中，我们可以看到，集群最底层的是HDFS，在其之上的就是YARN层，而在YARN层上则是各种不同的计算框架。所以不同计算框架可以共享同一个HDFS集群上的数据，享受整体的资源调度，进而提高集群资源的利用率，这也就是携衫仿所谓的 xxx on YARN
整个集群中会有多个NM，它主要负责自己本身节点的资源管理和使用，以及定时向RM汇报本节点的资源使用情况。接收并处理来自RM的各种命令，例如：启动Container。NM还需要处理来自AM的命令，例如：AM会告诉NM需要启动多少个Container来跑task。
每个应用程序都对应着一个AM。例如：MapRece会对应一个、Spark会对应一个。它主要负责应用程序的管理，为应用程序向RM申请资源（Core、Memory），将资源分配给内部的task。AM需要与NM通信，以此来启动或停止task。task是运行在Container里塌袭面的，所以AM也是运行在Container里面。
封装了CPU、Memory等资源的一个容器，相当于是一个任务运行环境的抽象
客户端，它可以提交作业、查询作业的运行进度以及结束作业
1.client向yarn提交job，首先找ResourceManager分配资源，
2.ResourceManager开启一个Container,在Container中运行一个Application manager
3.Application manager找一台nodemanager启动Application master，计算任务所需的计算
4.Application master向Application manager（Yarn）申请运行任务所需的资源
5.Resource scheler将资源封装发给Application master
6.Application master将获取到的资源分配给各个nodemanager
7.各个nodemanager得到任务和资源开始执行map task
8.map task执行结束后，开始执行rece task
9.map task和 rece task将执行结果反馈给Application master
10.Application master将任务执行的结果反馈pplication manager。
另外找到两篇关于YARN执行流程不错的文章：
到此为止，我们的yarn环境就搭建完成了.
虽然我们没有搭建MapRece的环境，但是我们可以使用Hadoop自带的一些测试例子来演示一下如何提交作业到YARN上执行。Hadoop把example的包放在了如下路径，可以看到有好几个jar包：