Hadoop2.X オープンソースソフトウェアとエコシステムの最新動向を総合的に分析
、Hadoopのバージョンの概要
現在のHadoopは、Apacheのオープンソース版に加えて放出するだけでなく、Huawei社がリリース、Intelがリリース、Clouderaのディストリビューション（CDH）、Hortonworksリリース（HDP）、MAPR、これらのリリースのすべては、Apache Hadoopのに基づいて導出されていますうちは、Apache Hadoopのオープンソースライセンスは、誰もがオープンソースや商用の製品発表と、それを変更することができますので。ほとんどの国内企業は、このようなように、インテルのリリース、Huawei社のリリースとして、有料でリリース。Hadoopのの無償版ません4外国人がありますが、ApacheのHadoopの財団、Clouderaのバージョン（CDH）、Hortonworksバージョン（HDP）、MAPRバージョンです。
二、Hadoop2.x基本原則とアーキテクチャ
ApacheのHadoopのマシンが互いに通信し、高度に分散的に連携し、大量のデータを一緒に格納されて処理できるように、ビジネス・マシンは、クラスタにインストールすることができるオープンソース・ソフトウェア・フレームワークです。Hadoopの分散ファイルシステム（HDFS）とMapReduceジョブの形で実現し、プログラムを実行をサポートし、分散コンピューティングエンジン：最初に、Hadoopのは、2つの主要な構成要素を含みます。Hadoop2.xはHadoop1.xと比較して、HDFSとのMapReduceのアーキテクチャの大きな変化を有し、そして、Hadoop2は、2つの重要な変更があり大きく速度と使いやすさを改善しました。
（1）HDFS名前ノードクラスタ、すなわち、スケーラビリティおよび高可用性名前ノードのレベルを増強するように配備されてもよい：HDFS連邦とHAと、
（2）（タイミングやトリガーモニターを含む）、リソース管理とタスクライフサイクル管理でのMapReduceジョブトラッカーは、2つの別個の構成要素に分割され、糸にその名前を変更し（もう一つのリソース交渉）。
図1 Hadoop2.xチャート
2.1 HDFS
2.1.1 HDFSの概要
HDFSはまだマスター/スレーブモードを使用します。マスターノードは、ノードが、まだ多くのデータノードで、まだ名前ノードです。データセットの名前ノードの記録メタデータ。負荷は、デフォルトのデータは64メガバイト（ブロック）のブロックに分割され、名前ノードがどのブロックにファイルを管理するように、これらのデータブロックは、実行するために並列処理データノードの複数に分配され、これらのHDFSにそれぞれ大きなファイル以来ブロックは、データノードに分散しています。これらのマッピングは、メタデータです。データノードの変更のブロックは、メタデータの名前ノードのレポートを更新する必要がある場合。クライアントのオペレーティングデータは、データが、配置されているデータノードのデータを照会した後、問い合わせ元の名前ノードするデータノードと直接対話する必要がある場合にはリード/ライト動作を行い。ブロック別のデータ・ブロックは、（主にデータセキュリティのための）複数のコピーを持っています。ラックは、ラックである、データの複数のコピーが異なるサーバラック上に存在してもよいです。
図2 HDFSアーキテクチャ図
2.1.2 HA
HAにおけるHadoop2.x HDFSは、主に同時に開始名前ノード2を指します。2.0スタンバイ名前ノード（SNN）の増加、およびマスタノードは、他のスタンバイ（待機）状態にあり、作動（アクティブ）状態である活性名前ノード（ANN）、と呼ばれています。したがって、サーバは、名前ノードの下に位置する場合、可能なデータを手動または自動で他のサービス名前ノードに切り替え、失われていない場合です。SNNとサードパーティの共有ストレージANNは冗長性、自動フェールオーバーです。一の実施形態の構成を示す図3は、HA Hadoop2に実装されます。
図中、図HA実装アーキテクチャ3のHadoop
2.1.3 HDFS連盟
連盟の1）新しいアーキテクチャ
HAは、単一ノードの障害の問題を解決し、貧しい人々スケーラビリティの名前ノードの問題が未解決のまま。次のように名前ノード連合（EU）は動作します：ブロックの複数のブロックプール（1人の関係のないもの）に複数のデータノードに格納されているメタデータ、および名前ノードは、複数のブロックのプールを管理することができます。これにより、任意の配位せず、互いに独立してメタデータ管理名前ノード、の各部分。図4に示されているアーキテクチャ：
図4 HDFSフェデレーションチャート
2.2 YARN
2.2.1 YARN基本的なアーキテクチャ
糸はない次のMapReduce（MRv2）、第一世代のMapReduceのMapReduce（MRv1）プログラミングインターフェース、データ処理エンジン（MapTaskとReduceTask）の次の世代は異なる、これらのモジュールのMRv2 MRv1を再利用することができる、全く同じですリソース管理、ジョブ管理システムは、MRv1ジョブ管理やリソース管理、ジョブトラッカーによって実装される、2イン1セットは、MRv2にしながら、2つの部分が分離されました。請求ApplicationMaster、リソース管理によって実現ジョブ管理が糸汎用性から、新しいシステム糸によって行われるので、糸リソース管理システムは、他のコンピューティングフレームワークとして使用することができる、MapReduceのこれらに限定されないが、他の計算フレームワーク（例えば、スパーク）中の管理プラットフォーム。
5 Hadoop2.x図の部分概略図です。
図5から分かるように、Hadoop2 MapReduceは、処理データの解析に特化され、糸は、リソース・マネージャとして存在します。分散リソース管理とスケジューリングシステムYARNの性質があります。これは、1つのリソースマネージャ（リソースマネージャ）、ジョブごとマネージャアプリケーション（応用マスター）、各マシンマネージャのノード（ノードマネージャ）を備えます。
该架构将JobTracker中的资源管理及任务生命周期管理（包括定时触发及监控），拆分成两个独立的服务，用于管理全部资源的ResourceManager以及管理每个应用的ApplicationMaster，ResourceManager用于管理向应用程序分配计算资源，每个ApplicationMaster用于管理应用程序、调度以及协调。一个应用程序可以是经典的MapReduce架构中的一个单独的Job任务，也可以是这些任务的一个DAG（有向无环图）任务。ResourceManager及每台机上的NodeManager服务，用于管理那台主机的用户进程，形成计算架构。每个应用程序的ApplicationMaster实际上是一个框架具体库，并负责从ResourceManager中协调资源及与NodeManager(s)协作执行并监控任务。如图6所示：
图6 YARN架构图
在 YARN 架构中，一个全局 ResourceManager 以主要后台进程的形式运行，它通常在专用机器上运行，在各种竞争的应用程序之间仲裁可用的集群资源。ResourceManager 会追踪集群中有多少可用的活动节点和资源，协调用户提交的哪些应用程序应该在何时获取这些资源。ResourceManager 是惟一拥有此信息的进程，所以它可通过某种共享的、安全的、多租户的方式制定分配（或者调度）决策（例如，依据应用程序优先级、队列容量、ACLs、数据位置等）。
在用户提交一个应用程序时，一个称为 ApplicationMaster 的轻量型进程实例会启动来协调应用程序内的所有任务的执行。这包括监视任务，重新启动失败的任务，推测性地运行缓慢的任务，以及计算应用程序计数器值的总和。这些职责以前分配给所有作业的单个 JobTracker。ApplicationMaster 和属于它的应用程序的任务，在受 NodeManager 控制的资源容器中运行。
NodeManager 是 TaskTracker 的一种更加普通和高效的版本。没有固定数量的 map 和 reduce slots，NodeManager 拥有许多动态创建的资源容器。容器的大小取决于它所包含的资源量，比如内存、CPU、磁盘和网络 IO。目前，仅支持内存和 CPU (YARN-3)。未来可使用 cgroups 来控制磁盘和网络 IO。一个节点上的容器数量，由配置参数与专用于从属后台进程和操作系统的资源以外的节点资源总量（比如总 CPU 数和总内存）共同决定。
2.2.2 YARN应用程序提交过程
当键入 hadoop jar 命令，将应用程序提交到 ResourceManager。ResourceManager 维护在集群上运行的应用程序列表，以及每个活动的 NodeManager 上的可用资源列表。ResourceManager 需要确定哪个应用程序接下来应该获得一部分集群资源。该决策受到许多限制，比如队列容量、ACL 和公平性。ResourceManager 使用一个可插拔的 Scheduler。Scheduler 仅执行调度；它管理谁在何时获取集群资源（以容器的形式），但不会对应用程序内的任务执行任何监视，所以它不会尝试重新启动失败的任务。
在 ResourceManager 接受一个新应用程序提交时，Scheduler 制定的第一个决策是选择将用来运行 ApplicationMaster 的容器。在 ApplicationMaster 启动后，它将负责此应用程序的整个生命周期。首先也是最重要的是，它将资源请求发送到 ResourceManager，请求运行应用程序的任务所需的容器。资源请求是对一些容器的请求，用以满足一些资源需求。
三、Hadoop商业发行版的对比分析
Hadoop 是一个开源项目，先后有许多公司在其框架基础上进行了增强并且发布了商业版本。Hadoop项目的最大诱惑在于使用者可以根据自身的业务需要定制差异化的功能。在Apache开源社区，Hadoop把所有的相关项目组成一个完整的生态系统，用户几乎不费吹灰之力就可以通过搭配一些组件来实现一个完整功能。Hadoop商业发行版的提供者们通过优化核心代码、增强易用性、提供技术支持和持续版本升级为Hadoop平台实现了许多新功能。市场上受认可的Hadoop商业发行版的提供者主要有Cloudera（CDH），MapR和Hortonworks。
总体来看，Hadoop商业版的区别如下表所示：
| 版本 |
优点 |
缺点 |
| CDH |
CDH有一个友好的用户界面及一些实用的工具，比如：Impala |
CDH相对MapR Hadoop来说，运行效率显著降低 |
| MapR Hadoop |
运行效率高；节点之间可以通过NFS直接访问 |
MapR Hadoop没有像CDH那样的用户界面 |
| HDP |
唯一一个能运行在Windows上的Haoop系统 |
Ambari管控界面功能比较简单，不够丰富 |
表1 商业版比较
3.1 Cloudera
Cloudera 是Hadoop领域知名的公司和市场领导者，提供了市场上第一个Hadoop商业发行版本。它拥有350多个客户并且活跃于Hadoop生态系统开源社区。在多个创新工具的贡献着排行榜中，它都名列榜首。它的系统管控平台——Cloudera Manager,易于使用、界面清晰，拥有丰富的信息内容。Cloudera 专属的集群管控套件能自动化安装部署集群并且提供了许多有用的功能，比如：实时显示节点个数，缩短部署时间等。同时，Cloudera 也提供咨询服务来解决各类机构关于在数据管理方案中如何使用Hadoop技术以及开源社区有哪些新内容等疑虑。美国电商“高朋”公司是CDH的用户。
3.2 MapR
MapR的Hadoop商业发行版紧盯市场需求，能更快反应市场需要。一些行业巨头如思科、埃森哲、波音、谷歌、亚马逊都是MapR的Hadoop的用户。与Cloudera和Hortonworks不同的是， MapR Hadoop不依赖于Linux文件系统，也不依赖于HDFS，而是在MapRFS文件系统上把元数据保存在计算节点，快速进行数据的存储和处理。其架构图如下所示：
图7 MapR架构图
3.3 Hortonworks
いくつかのヤフーのエンジニアによってHortonworksは、Hadoopのための技術的なサービスを提供する会社を設立しました。他の企業とは異なり、それは完全なオープンソースのHadoopデータプラットフォームを提供し、ユーザーは無料で利用できます。ユーザーが簡単にダウンロードHortonworksのHadoopディストリビューションHDPを取得し、様々なアプリケーションに統合することができます。イーベイ、サムスン、ブルームバーグ、SpotifyはユーザーがHDPです。Hortonworksは、第1のHadoop 2.0本番環境のニーズを満たすために提供するHadoopのバージョンに基づきます。が、CDHのHadoop 2.0は、以前のバージョンではいくつかの機能が含まれていますが、これらの機能は、生産のニーズを満たすことができません。HDPは現在、Windows用のHadoopの唯一のサポートされるバージョンです。ユーザーは、HDInsightサービスでのWindows Azureの上のHadoopを展開することができます。
第四に、Hadoopのの技術の応用
4.1のHadoopは、データサービスインフラストラクチャプラットフォームに適用されます
ユーザ肖像4.2のHadoop
ウェブサイトのクリックストリームデータマイニングのための4.3 Hadoopのログ
