hadoop ecosystem nttdata osc15tk

1 Copyright © 2015 NTT DATA Corporation

(株) NTTデータ基盤システム事業本部吉田耕陽

2015/2/28 OSC 2015 Tokyo/Spring

分散処理基盤Apache Hadoop入門と Hadoopエコシステムの最新技術動向


所属/氏名

基盤システム事業本部 OSSプロフェッショナルサービス

吉田耕陽（よしだこうよう）

お仕事

徹底的に検証・評価したOSSの組み合わせ、設定・運用のノウハウの提供

高品質なシステム基盤を実現する仕組みの整備

最近は、の案件適用やPoC等を中心に活動。

担当には「Hadoop徹底入門」、「HADOOP HACKS」の著者が複数在籍

自己紹介


Hadoop概要～これまでのHadoop～

Hadoopの最新動向

NTTデータのHadoopコミュニティに対する取り組み

アジェンダ

Copyright © 2015 NTT DATA Corporation 4

Hadoop概要～これまでのHadoop～


Hadoopとは？

オープンソースの大規模分散処理フレームワーク • Googleの基盤ソフトウェアのオープンソース版クローン (GFS, MapReduce)

• Apacheプロジェクト (http://hadoop.apache.org/)

Yahoo Research の Doug Cutting 氏(現 Cloudera社)が Java で開発

『扱うデータがビッグ(大容量・多件数)であるために、従来のITアーキ

テクチャでは難しかった、もしくは超高コストでしか実現できなかった

データ活用が可能となる』

Dougさんのお子さんのお気に入りだったぬいぐるみ


集中管理型の分散システム

Hadoopの構成

Hadoopマスタサーバ

Hadoopスレーブサーバ群

Hadoopクライアント

NameNode DataNode

DataNode

DataNode

DataNode

JobTracker

TaskTracker

TaskTracker

TaskTracker

TaskTracker

スレーブサーバは、分散処理の実行やデータの実体を保存

データ管理や分散処理ジョブの管理は

マスタサーバが実施


大きく２つのコンポーネントで構成

分散ファイルシステム

HDFS

並列分散処理フレームワーク

MapReduceフレームワーク

Hadoopの構成するコンポーネント

データを貯める機能を

提供

貯めたデータを処理する機能を

提供


Hadoopとは

集中管理型の分散システムで

HDFSとMapReduceフレームワークの２つのコンポーネントにより

並列分散処理を実現するミドルウェア



HDFSとは

NameNode

DataNode

DataNode

DataNode

DataNode

DataNode

一つのファイルシステムを構成

複数のサーバを束ねて、


外から見ると、１つの巨大なファイルシステム

HDFSの外からの見え方

NameNode

DataNode

DataNode

DataNode

DataNode

DataNode Hadoopクライアント

hdfs dfs -put

HDFSへの命令


外から見ると、１つの巨大なファイルシステム

HDFSの外からの見え方

NameNode

DataNode

DataNode

DataNode

DataNode


hdfs dfs -ls

-rw-r--r-- 3 tester hadoop 129 2015-02-28 12:00 /user/tester/test.txt

所有者権限作成日時


分散ファイルシステムの舞台裏では

HDFSの舞台裏

NameNode

DataNode

DataNode

DataNode

DataNode


入力ファイルは、ブロックサイズで分割される ※分割したものをブロックと呼ぶ

④

①

②

③


分散ファイルシステムの舞台裏では

HDFSの舞台裏

NameNode

DataNode

DataNode

DataNode

DataNode


各ブロックは複製（レプリケーション）され、スレーブサーバに格納される

④

①

②

③

①

①

①

②

②

②

③

③

③

④

④

④

レプリカは異なる３サーバに配置される


MapReduceアルゴリズム

大量の件数のデータがあった時に、複数ワーカーで並列に処理できる仕組み

例として、選挙の開票作業を想定

- 複数人で作業を分担して実施

- 最初に、投票用紙を分けて、みんなで並行して候補者別に用紙を仕分ける

- 次に、候補者別の用紙を1カ所にまとめて、それぞれの枚数を数える

MapReduceって？


MapReduce （アルゴリズム）

①用紙を適当に3つに分ける第1段階

第2段階

第3段階

a氏 e氏

③候補者ごとに用紙を集める

d氏 c氏 b氏

Aさん Bさん Cさん

・・・

・・・

・・・

a氏 b氏 e氏 a氏 b氏 e氏 a氏 b氏 e氏

②3人で並行して、候補者ごとに用紙を仕分ける

④3人で並行して、候補者ごとに枚数を数える

a氏の得票数

b氏の得票数

d氏の得票数

e氏の得票数

c氏の得票数

投票結果

Bさん Cさん Aさん




①用紙を適当に3つに分ける

・・・

・・・

・・・



第1段階

第2段階

第3段階

a氏 e氏


d氏 c氏 b氏


a氏の得票数

b氏の得票数

d氏の得票数

e氏の得票数

c氏の得票数

投票結果


Map処理データを分類・仕分け

Reduce処理分類・仕分けされたデータごとに処理





・・・

・・・

・・・



第1段階

第2段階

第3段階

a氏 e氏


d氏 c氏 b氏


a氏の得票数

b氏の得票数

d氏の得票数

e氏の得票数

c氏の得票数

投票結果


M人でやれば M倍のスピード（相互に影響を受けずに作業できる）

N人でやれば約N倍のスピード（相互に影響を受けずに作業できる）


MapReduceジョブ



・・・

・・・

・・・


②3人で並行して、投票者別に用紙を仕分ける

第1段階

第2段階

第3段階

a氏 e氏

③投票者ごと用紙を集める

d氏 c氏 b氏

④3人で並行して、投票者ごとに枚数を数える

a氏の得票数

b氏の得票数

d氏の得票数

e氏の得票数

c氏の得票数

投票結果


Map処理データを分類・仕分け

Reduce処理分類・仕分けされたデータごとに処理

MapReduceジョブ

Map タスク

Map タスク

Map タスク

Reduce タスク

Reduce タスク

Reduce タスク


MapReduceジョブを実行するフレームワーク

MapReduceフレームワークの外からの見え方

JobTracker

TaskTracker

TaskTracker

TaskTracker Hadoopクライアント

MapReduce ジョブ

HDFS

MapReduceジョブ hadoop jar サンプルジョブ.jar

M R

Map タスク

Map タスク

Map タスク

Map タスク

Reduce タスク

Reduce タスク

Reduce タスク

Reduce タスク

HDFSから読み込み HDFSに書き込み


HDFS 大量データを高スループットに読み込める

サーバが故障しても、データの安全性は担保

サーバ数を増やせば、格納できるデータ量はスケールする

MapReduceフレームワーク Mapタスク、Reduceタスクのみ指定すれば、

（原則はJavaで処理を記述）あとはフレームワークが並列分散処理を実現

サーバが故障しても、タスクが再実行され、ジョブは成功

サーバ数を増やせば、処理性能は基本スケールする

Hadoopの特徴


HDFS 大量データを高スループットに読み込める

サーバが故障しても、データの安全性は担保

サーバ数を増やせば、格納データ量はスケールする

MapReduce Mapタスク、Reduceタスクのみ指定すれば、

（原則はJavaで処理を記述）あとはフレームワークが並列分散処理を実現

サーバが故障しても、タスクが再実行され、ジョブは成功

サーバ数を増やせば、処理性能は基本スケールする

Hadoopの特徴

並列分散処理の面倒な部分を解決してくれるミドルウェア


Hadoopの適用領域

秒

分

時間

日

処理のレイテンシ

バッチ処理

リアルタイム処理

データサイズ少ない多い

オンライン処理

汎用検索

ＧＢ（ギガバイト）ＴＢ（テラバイト）ＰＢ（ペタバイト）

ＴＢ（テラバイト）

オンバッチ処理

純バッチ処理

RDBMSの適用領域

Hadoopの適用領域

バッチ処理の高速化全件データ

（Big Data）処理


Hadoopは「貯める」「処理する」機能に特化。Hadoopを活用した大量データ分析を実現するため、様々な周辺ツールが出現。エコシステムが広がった。

エコシステムを形成


MapReduceフレームワークを直接Javaで記述すると、コード行数が増えることは避け難く、アプリケーションの生産性が課題となる。

分散処理を記述するためのAPIは提供されているが、適切なプログラムの記述のためにはアプリ実装者が覚えることが多いのも事実…

エコシステム～アプリ記述の抽象化・ライブラリ化～

Map? Reduce?

Partitioner?? Combiner??


Apache Hive HiveQLというSQLライクな言語でMapReduceを実行

Apache Pig Pig Latinという独自の言語でMapReduceを実行

Apache Mahout 機械学習アルゴリズムのMapReduce実装のライブラリ

エコシステム～アプリ記述の抽象化・ライブラリ化～

hive> SELECT COUNT(uid) FROM access_log GROUP BY date;

A = LOAD 'data' USING PigStorage() AS (f1:int, f2:int, f3:int); B = GROUP A BY f1; （省略）

$ mahout kmeans --input inputfile --output outputfile


HDFS HDFS HDFS

よくある疑問

MapReduceフレームワークの縛りは厳しそうだけど、 SQLのような複雑な処理を実現できるの？

YES！MapReduceを複数段組み合わせることで、様々な処理が実現できる

M R

M R

M R M

GROUP BY + 集約関数

JOIN(結合処理)

SELECT(射影)やWHERE(選択)

HDFS

JOIN(結合処理)


分析対処のデータをHDFSに格納することも課題となる

既存のRDBMSに格納したデータを移動して利用したい

Ｗｅｂログやシステムログなどを収集したい

エコシステム～データ連携～

処理毎に使い捨てスクリプトを書く？エラーハンドリングや耐障害性など担保すべきことも多い…


Apache Sqoop RDBMS-Hadoop間のデータ連携ツール

Apache Flume ログ収集のための分散フレームワーク

エコシステム～データ連携～

MapReduce

Sqoop RDBMS

HDFS

import

export

内部的にはMapReduceが動作。並列でRDBとテーブルの情報をやりとりする。

HDFS

ログ

ログ

ログ

http://www.google.co.jp/url?sa=i&rct=j&q=&esrc=s&frm=1&source=images&cd=&cad=rja&uact=8&ved=0CAcQjRw&url=http://flume.apache.org/&ei=kP_hVJujAqLWmgW-soDQAQ&bvm=bv.85970519,d.dGY&psig=AFQjCNHcqFbFoffz3lAeDswdnqNzzqNnkw&ust=1424183564055934

http://www.google.co.jp/url?sa=i&rct=j&q=&esrc=s&frm=1&source=images&cd=&cad=rja&uact=8&ved=0CAcQjRw&url=http://sqoop.apache.org/&ei=uv_hVNKUEqSnmAWY4ILgBA&bvm=bv.85970519,d.dGY&psig=AFQjCNHL9gHqIQ6isXaN1-6_Z00r3gOZkw&ust=1424183605089994


Hadoopコア部分に加えてエコシステムが充実することで、データの収集や分析など、「大量データ活用」を身近なものにした。

エコシステムの浸透

HDFS

MapReduce

Pig Hive Mahout HBase

Sqoop RDBMS

外部システム

Flume

http://www.google.co.jp/url?sa=i&rct=j&q=&esrc=s&frm=1&source=images&cd=&cad=rja&uact=8&ved=0CAcQjRw&url=http://sqoop.apache.org/&ei=uv_hVNKUEqSnmAWY4ILgBA&bvm=bv.85970519,d.dGY&psig=AFQjCNHL9gHqIQ6isXaN1-6_Z00r3gOZkw&ust=1424183605089994

http://www.google.co.jp/url?sa=i&rct=j&q=&esrc=s&frm=1&source=images&cd=&cad=rja&uact=8&ved=0CAcQjRw&url=http://flume.apache.org/&ei=kP_hVJujAqLWmgW-soDQAQ&bvm=bv.85970519,d.dGY&psig=AFQjCNHcqFbFoffz3lAeDswdnqNzzqNnkw&ust=1424183564055934


Hadoopの最新動向


Hadoopとエコシステムはユーザーとともに進化を遂げた。活用事例の増加や取り巻く環境の変化から、新たな潮流が生まれる…

Hadoopと周辺環境の変化

•一部のユーザは数千台クラスのHadoopクラスタを構築・利用クラスタ”超”巨大化

•企業の利用拡大に伴い、Hadoopにアクセスしてデータ分析をする利用者が増えたアクセスユーザ増加

•大量データ活用が一般的になるにつれて、「速報値を知りたい」「もっとインタラクティブに分析したい」といった要求が生まれるデータ処理高速化の追求

•Hadoop黎明期はサーバあたりのメモリ4～8Gが一般的だったが、現在は100GB以上のメモリを積んだサーバも普及。ハードウェアの進化

主な”変化”の例


近年のHadoopおよびエコシステムについて、

以下の3点について最新動向を紹介

近年のHadoopの潮流

クラスタ”超”巨大化

アクセスユーザ増加

データ処理高速化の追求

ハードウェアの進化

1.YARN登場

2.新たな並列分散処理エンジンの出現

3.非機能面の強化


YARNの前に：Hadoop1系、Hadoop2系について

Hadoop1系は2007年から開発が始まり、安定化志向。2014年6月に開発は凍結。 Hadoop2系は2012年に分岐。根本のアーキテクチャに変更を入れ、現在も進化を続けている。

2014 2010 2011 2013 2012 2009

branch-2

2.2.0

2.3.0

2.4.0 2.0.0-alpha

2.1.0-beta

branch-1 (branch-0.20)

1.0.0 1.1.0 1.2.1(stable) 0.20.1 0.20.205

0.22.0 0.21.0

New append

Security

0.23.0

0.23.11(final) NameNode Federation, YARN

NameNode HA

2015

2.5.0

2.6.0

これまでお伝えした範囲

これからお伝えする範囲


YARN = Yet Another Resource Negotiator

YARN登場


HDFS

バッチ処理 MapReduce

Hadoop 1


HDFS

バッチ処理 MapReduceV2

Hadoop 2

リソース制御 YARN

「蓄積+処理」の構成からリソース制御を切り出した


MRv1とMRv2との比較 (ノード構成)

JobHistoryServer

NodeManager

TaskTracker

タスクプロセスタスクプロセスタスクプロセス

Hadoop 1系 Hadoop 2系

HDFS HDFS

JobTracker

ResourceManager

TaskTracker

NodeManager ジョブ履歴

管理

リソース管理

タスクプロセス

MRv1

MRv2

YARN

リソース管理

ジョブ・タスク管理

TimelineServer

コンテナ

Application Master

コンテナコンテナコンテナコンテナタスクプロセス


YARNの意義

リソース制御を分離することで… つまり何が嬉しいの？

柔軟なリソース制御によるスループット向上

Hadoopのスケーラビリティをさらに向上させる

MapReduce以外の分散処理を実行する


マスターサーバの負荷軽減

TaskTracker

ジョブ/アプリケーション管理のイメージ

JobTracker

TaskTracker TaskTracker TaskTracker TaskTracker

Hadoop1系

クライアントジョブAお願いします。



TaskTracker


JobTracker


Hadoop1系

クライアント了解です。

Aさんは○○、Bさんは○○をお願いします。定期的に進捗報告もお願いします。



TaskTracker


JobTracker


ジョブAのタスク1、50%終わりました。

余裕あります。

ジョブAのタスク2、30%終わりました。

忙しいです。

ジョブ Hadoop1系



TaskTracker


JobTracker


ジョブAのタスク02を50%終わりました。ジョブCのタスク01を完了しました。

余裕あります。

ジョブAのタスクA30%終わりました。ジョブBのタスクBを50%終わりました。

忙しいです。

ジョブ

マスターサーバの管理コストが多く、メンバが増えるとマスターサーバがボトルネックに…

Hadoop1系



NodeManager


Resource Manager

NodeManager NodeManager NodeManager NodeManager

余裕あります。忙しいです。

YARN

ResourceManagerには余力（≒リソース）を通知



NodeManager


Resource Manager


YARN

アプリAお願いします。クライアント

YARNではジョブ× → アプリケーション○



NodeManager


Resource Manager


アプリAの取りまとめお願いします。リソースが必要であれば連絡ください。

アプリケーション

YARN

仕事(アプリケーション)の管理はメンバに依頼取りまとめ役(ApplicationMaster)になる



NodeManager


Resource Manager


アプリAの取りまとめお願いします。リソースが必要であれば連絡ください。

アプリケーション

YARN

任命されたApplicationMasterは ResourceManagerにリソースの要求が可能

Application Master



NodeManager


Resource Manager


了解です。 ○○だけリソースお願いします。

YARN



NodeManager


Resource Manager


○割の仕事は Bさんの指示に従ってください。

YARN



NodeManager


Resource Manager


タスクＡは進捗50%です。

タスクBは進捗20%です。

YARN

タスク毎の進捗状況はApplicationMasterが管理



NodeManager


Resource Manager


YARN

ApplicationMasterはアプリケーションの進捗状況をRMに通知

アプリAの進捗70%です



NodeManager


Resource Manager


マスターサーバの管理コストが減り、多数のメンバを管理できる（スケーラビリティ向上）

アプリAの進捗70%ですアプリBの進捗30%です

YARN


コンテナ単位でリソースを柔軟に払い出す

Hadoop 1系 Hadoop 2系

TaskTracker NodeManager

Map タスク

Map タスク

Map タスク

Reduce タスク

Reduce タスク

Map タスク

Map タスク

Map タスク

Reduce タスク

Mapタスク、Reduceタスクの並列数は、それぞれに設定したスロット数で制限される。

利用可能な仮想CPU、メモリを制限したコンテナという単位でリソースを払いだす。 (Map、Reduceの区別は無い)

Mapスロット Reduceスロットコンテナ

単一サーバ上での並列実行数管理のイメージ

リソース (VCPU / メモリ)

Application Master

柔軟なリソース管理やリソースオーバーコミット防止は、スループットの向上につながる


MapReduceは、ディスクIOを並列化することでスループットを最大化するが、低レイテンシな処理は苦手。

新たな並列分散処理エンジンの出現

M R M R

Reduce処理

MapReduce ジョブ・・・

M

M R

M R M R

・・・

・・・

・・・

・・・

Map処理

・・・・・・

HDFS

HDFS HDFS

HDFS ApplicationMaster

MapReduceのフレームワークの縛りの中で複雑な処理を行うには、多数のMapReduceを組み合わせることになる。都度HDFSに中間データを書き出すためのオーバーヘッドや、ジョブ(ApplicationMaster)の起動のオーバーヘッドは分析処理の遅延に繋がる。

HiveやPig(on MapReduce)による一連の処理のイメージ

HDFSに書き出し HDFSから読み出し


MapReduceで実現が難しいデータ処理の課題に対して、新たな分散処理フレームワーク・実行エンジンが出現。


次ページより概要を紹介します！

http://www.google.co.jp/url?sa=i&rct=j&q=&esrc=s&frm=1&source=images&cd=&cad=rja&uact=8&ved=0CAcQjRw&url=http://en.wikipedia.org/wiki/Apache_Spark&ei=n5TkVNamG6LUmAWjvILACg&bvm=bv.85970519,d.dGY&psig=AFQjCNGmep_J8Vp-lojeKK7uIvjWRIsvEw&ust=1424352797209148

http://www.google.co.jp/url?sa=i&rct=j&q=&esrc=s&frm=1&source=images&cd=&cad=rja&uact=8&ved=0CAcQjRw&url=http://www.cloudera.com/content/cloudera/en/downloads/connectors/impala/jdbc/impala-jdbc-v2-5-5.html&ei=uZTkVKPoIoe8mgWms4HADg&bvm=bv.85970519,d.dGY&psig=AFQjCNH_Cllpybmlmh1GBc4oSbgfDN92NA&ust=1424352821246671

http://www.google.co.jp/url?sa=i&rct=j&q=&esrc=s&frm=1&source=images&cd=&cad=rja&uact=8&ved=0CAcQjRw&url=http://tez.apache.org/&ei=45TkVIjZF6fymQWJiYGQDQ&bvm=bv.85970519,d.dGY&psig=AFQjCNFpDwJb6rAVzWnjsm6fTb8-OIlxlw&ust=1424352864805507

http://www.google.co.jp/url?sa=i&rct=j&q=&esrc=s&frm=1&source=images&cd=&cad=rja&uact=8&ved=0CAcQjRw&url=http://www.hadoop-times.com/technology/how-turn-raw-data-yelp-insights-minutes-apache-drill.html&ei=B5XkVPvAHMHEmwWOmIBg&bvm=bv.85970519,d.dGY&psig=AFQjCNFo1m8veIvnATRpmJ5nt0lrQ55ngA&ust=1424352901000622


Apache Spark : Hadoop上で動作する低レイテイシ技術

Apache Spark : 大規模データの分散処理をオンメモリで実現

• データ処理を極力メモリ上で実現するため、高速な処理を実現

• Hadoop MapReduceが不得意な繰り返し処理に威力を発揮

• 機械学習やHadoop MapReduceよりも短時間で処理したいものが得意領域

RDD（Resilient Distributed Dataset）の変換で処理を表現

RDD RDD RDD

Stage Stage

RDD

Sparkができるだけ処理をまとめこむ

ユーザ定義の処理の流れ

Sparkによる実際の処理ステージ間は

シャッフルが発生

変換変換変換出力入力

Stageに基づいてサーバ群がタスク実行


Apache Spark : コアを中心に成り立つライブラリ

Apache Spark（コア）

Spark SQL Spark

Streaming MLlib GraphX

ＳＱＬで書けるストリーム処理できる

機械学習できる統計処理できるグラフ処理できる

Scala、Java、Pythonで分散処理を書ける

高度な処理を実現するための標準ライブラリが充実

メモリを活用したアーキテクチャ、インタラクティブにも処理を記述できる仕組み、便利なライブラリなど、分析担当者に嬉しい機能が多い。


Apache Tez : YARN上での処理に最適化された実行エンジン

Apache Tez : DAG(Directed Acyclic Graph)により実行計画を作成

ApplicationMasterの起動回数削減

HiveやPigといったMRv1で実行していたクエリ・コードを流用できる

• Hive on Tez

• Pig on Tez

Tez

Plan

Plan Plan

Plan

ローカルディスクを利用 (HDFSへの書き込みより高速)

Plan

Plan

特定のノードのみでShuffle (通信量・リソース削減)

処理量ベースで実行ノード数を制御

(リソース削減・性能改善)

MapReduceの仕組みにあてはめない 1つのApplicationMasterで処理

ローカルローカル

ローカルローカル

Hive、Pigを利用するユーザは、プログラムの言語(HiveQL、Pig Latin)はそのままで処理時間の短縮が可能。MRが多段になる複雑な処理であるほど、処理時間短縮効果が大きい。


Twitter社のエンジニアにより開発された、並列分散ストリーム処理のためのフレームワーク

Apache Storm : 分散ストリーム処理フレームワーク

Storm Topology

Spout:ストリーム処理の入力を担う Bolt:データへの処理を実行する

HBase

HDFS

ストリームデータ・ログ・センサーデータ

アプリケーションエンジニアは、Bolt・Spoutで処理するロジックを記述、それらを組み合わせたTopologyを定義することで分散ストリーム処理を実現できる。耐障害性やスケーラビリティを意識せずに享受可能！

処理したデータをKVSやHDFSに永続化し可視化や通知を行う

Storm処理の前段にMQ等のシステムを配置し、ストリームデータを受け取る


SparkやStormは元々Hadoopとは独立したプロジェクトだったが、機能追加によりYARN上での動作が可能に。(TezはYARNでの実行を前提としている)

メリット - 専用のクラスタを構築する必要が無く、必要なリソースを払いだしながら多様

な分析処理を実行できる

- 同一のデータ(HDFS)にアクセスできる。(データを移動させる必要が無い)

YARNで、Hadoopに乗る

MRv2

Pig Hive

HDFS

YARN

Tez Spark Storm

MLlib Streaming

…

SQL GraphX

スケーラブルなデータストアの上で、様々な分析処理のワークロードが動作。「Hadoopはビッグデータの”OS”カーネル」という声も。

http://itpro.nikkeibp.co.jp/article/NEWS/20140708/569985/


エンタープライズ用途でより活用されるために、高い非機能要求に対応するための機能拡張も進んでいる

以下の観点で、Hadoop2系で追加された機能を紹介します

可用性

セキュリティ

堅牢なHadoopに向けて


Hadoop1系まではマスター系サーバはSPOFと言われ、他のHA系コンポーネントを組み合わせることで冗長構成をとっていた。

現在は、Hadoopの機能としてHA機能を提供。障害発生時も少ないダウンタイムでフェールオーバーを行う。

NameNode-HA

ResourceManager-HA

MRv2やTezは、ResourceManagerやApplicationMasterの障害・切り替え時もジョブの途中から再実行する

可用性 : SPOFは無い！


Hadoopクラスタへアクセスするユーザ・組織の増加や、クリティカルなデータをHadoopで保持する事例も増え、セキュリティ機能も強化されている。

HDFS Transparent Encryption ファイルを暗号化してDataNodeに書き込む

HDFS ACL 細かな粒度でHDFSへのアクセス権限を制御する

セキュリティ：暗号化 / ACL

-rw-r--r-- 3 tester hadoop 129 2015-02-27 12:00 /user/tester/test.txt

HDFSの拡張属性を利用し、基本のユーザー・グループ以外のアクセス制御も可能

DataNode

DataNode中のデータに直接アクセスしても読めない

クライアントやアプリケーションからは透過的にデータが読める


お話した内容

YARN登場


非機能面の強化

Hadoopの最新動向のまとめ

根本的なアーキテクチャも見直しを入れて Hadoopはさらに進化をつづけている

Hadoopがユーザへ浸透することで生まれた新たな課題に対しても、様々なエコシステムが生まれ活用されている

大量データ保持・活用の様々な課題に対する Hadoopの適用領域は広がりつづけている


NTTデータのHadoopコミュニティに対する取り組み


Hadoopを多数運用してきたことで得られた知見をもとに、改善提案をコミュニティにフィードバックしています

運用上特に問題となるバグの改修

利用者向けのドキュメントの拡充

運用、トラブルシュートを便利にする機能の開発 - OfflineImageViewer via the WebHDFS API

- HDFS Tracing

コミュニティへの貢献


開発面におけるHadoopコミュニティへの貢献

NTTデータはHadoopコミュニティにおいて世界有数のコントリビュータ(貢献企業)として活動しています。

商用環境においてHadoopを多数運用してきたことで得られた知見をもとに、Hadoopに対する改善提案をコミュニティにフィードバックしています。事象の報告にとどまらずHadoop本体への開発も行っています。運用上特に問題となるバグの改修や、利用者向けのドキュメントの拡充のためのパッチを投稿し、コミュニティに貢献しています。

解決済みissue数

2014年 Hadoopコミュニティ貢献指標

Hadoop専業ベンダのHortonworksやCloudera、Hadoopを開発したYahoo! Inc.に次いで、NTTデータもHadoopコミュニティにグローバルレベルで貢献しています。

貢献コード行数

244,975

131,609

30,595

第6位

21,780 23,197 30,595 20,540 14,764 14,534

第4位

370

274

195

85

174

119 72

45 45


小沢健史日本電信電話株式会社ソフトウェアイノベーションセンタ

- YARN：高可用化

- YARN：処理基盤間のインタフェースの整備と実装

- YARN：致命的なバグの修正

- 計算リソースのリークの改善

鯵坂明株式会社NTTデータ基盤システム事業本部

- OfflineImageViewerの拡張

- Hadoop 2系のドキュメント整備

- メトリクスのドキュメント整備

- 品質強化に関する取り組み

岩崎正剛株式会社NTTデータ基盤システム事業本部

- HTraceのモジュール開発

- HTraceトレーシング機能をHDFSに追加

- Sqoopのコネクタ開発

- Hadoopの運用スクリプト改善

コミッタ（主要開発者）に就任

Hadoop

Hadoop

HTrace


小沢健史日本電信電話株式会社ソフトウェアイノベーションセンタ

- YARN：高可用化

- YARN：処理基盤間のインタフェースの整備と実装

- YARN：致命的なバグの修正

- 計算リソースのリークの改善

鯵坂明株式会社NTTデータ基盤システム事業本部

- OfflineImageViewerの拡張

- Hadoop 2系のドキュメント整備

- メトリクスのドキュメント整備

- 品質強化に関する取り組み

岩崎正剛株式会社NTTデータ基盤システム事業本部

- HTraceのモジュール開発

- HTraceトレーシング機能をHDFSに追加

- Sqoopのコネクタ開発

- Hadoopの運用スクリプト改善

コミッタ（主要開発者）に就任

Hadoop

Hadoop

HTrace

コミッタを中心に Hadoopコミュニティを先導し、

Hadoopがより安心して便利に使えるものになるように継続して貢献をしていきます！


Hadoopは1台のマシンで扱えない規模の大量データを高速に処理するためのフレームワークです数台から始めて、数千台(データ量にして数十PB)までスケールアウトします

Hadoopエコシステムの開発の勢いは今も活発です性能面、運用面で便利な機能がどんどん追加されています

より低レイテンシな分散処理フレームワークや分析のためのライブラリも充実し、大量データ活用の可能性を広げています

NTTデータも、Hadoopの開発に参戦していますバグフィックスや、運用を便利にするための機能開発に取り組んでいます

国内初のコミッタ輩出！さらなる開発力の向上を目指しています

まとめ

Copyright © 2011 NTT DATA Corporation

Copyright © 2015 NTT DATA Corporation

お問い合わせ先：株式会社ＮＴＴデータ基盤システム事業本部 OSSプロフェッショナルサービス URL: http：//oss.nttdata.co.jp/hadoop メール： [email protected] TEL： 050-5546-2496

hadoop ecosystem nttdata osc15tk

Technology