⑴ 分布式任務調度系統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包：