SlideShare ist ein Scribd-Unternehmen logo
1 von 30
Downloaden Sie, um offline zu lesen
Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p /
4章  Hadoopクラスタの計画
〜~Hadoopオペレーション〜~
2015年年2⽉月9⽇日
株式会社セラン  R&D戦略略室
須⽥田幸憲
@sudabon
Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p /
4.1  Hadoopディストリビューションとバージョン選択
2
Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p /
•  本家  @  Apache  Software  Foundation
•  ディストリビューション(クラウドサービスを含む)
–  オンプレミス
•  CDH  @  Cloudera
–  本家と⽐比べて、リリース遅め
–  重要な機能やバグはバックポートされる
•  HDP  @  HortonWorks
–  CDHよりは、リリース早め
–  HDPのCMと⾔言えるAmbariが⾮非⼒力力
•  MapR  M7  @  MapR  Technologies
–  本家のソースを独⾃自に改良良し、OSSではない
–  HDFSだけでなく、Linux  FSでも動作
–  クラウドサービス
•  EMR  @  AWS
–  本家のソースを独⾃自に改良良
•  Azure  @  Microsoft
4.1  Hadoopディストリビューション
3
Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p /
•  CDH  5.3.0のコンポーネント
–  avro
–  bigtop
–  cdk
–  crunch  :  MR  Pipeline
–  datafu  :  UDF  for  Pig
–  flume
–  hadoop
–  hbase
–  hive
–  hue
–  impala
–  kite  :  For  Developers
–  llama
4.1.2  Hadoopのコンポーネント
4
(※1)
–  mahout
–  oozie
–  parquet  (parquet-‐‑‒format)
–  pig
–  search  (solr)
–  setnry
–  spark
–  sqoop
–  sqoop2  :  also  MongoDB
–  whirr  :  scripts  for  Cloud
–  zookeeper
Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p /
•  紆余曲折があったが、重要なのは、
–  バージョン1系
–  バージョン2系
が存在すること
•  バージョン1系
–  0.20.0がベースで、MRv1世代
–  既に昔話になりつつあるので、知らなくていいと思います
•  バージョン2系
–  0.23.0がベース、YARN(MRv2)世代
–  本家の最新バージョンは2.6
–  CDHにはバージョン2.5以降降が含まれる
4.1.3  Hadoopのバージョン
5
Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p /
•  重要なこと
–  RAIDではなく、JBOD(Just  a  Bunch  Of  Disks)指向
–  マスターは耐障害性が必要
–  ワーカー(スレーブ)は障害発⽣生が前提
–  基本的にマスターとワーカーの2種類のサーバを準備
•  マスターノード
–  ハイエンドスペック
–  ⼆二重化電源
–  ボンディングNIC
–  RAID  1+0
–  ⼤大容量量RAM
–  OS⽤用とHadoop⽤用のディスクを分離離
4.1.5〜~7  ハードウェアの選択
6
Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p /
•  20台以下のクラスタであれば...
–  マスターノード
•  4コア2.6GHz  CPU  ×  2
•  24GB  DDR3  RAM
•  1Gbps  NIC
•  SATA  II  ×  2  ×  2
•  NameNodeのハードウェア
–  安定運⽤用の絶対条件
•  メタデータ量量で必要となるサイズ以上のメモリ
•  NameNode専⽤用のディスク
•  独⽴立立ノード(他のデーモンと共存させない)
–  ⼤大量量の⼩小サイズのファイルを処理理させない  ⇒  結合
•  100万ブロックで1GBのメモリを消費
4.1.5〜~7  ハードウェアの選択
7
Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p /
•  JobTrackerのハードウェア
–  ⼤大量量のメモリを消費
•  100個(デフォルト値)のジョブのメタデータ情報をメモリに保持
•  ワーカーノードのハードウェア
–  ストレージ  ⇒  データ量量に依存、⼀一時保存⽤用(20〜~30%)
–  メモリ  ⇒  処理理データ量量に依存
–  CPU  ⇒  並列列処理理度度(必要スロット数)に依存
4.1.5〜~7  ハードウェアの選択
8
Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p /
典型的なワーカーノードのハードウェアスペック
9
Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p /
典型的なワーカーノードのハードウェアスペック
10
Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p /
•  ノード数の決定⽅方法は2つある
–  通常は、ストレージ容量量
–  場合に依っては、ジョブの処理理時間
•  実⾏行行しないと必要なリソース量量が明確にならない(鶏と卵卵の問題)
•  map処理理では、消費リソースはリニアに増⼤大するので、⼩小規模な
データサイズでベンチマークで予測可能
•  reduce処理理は、処理理内容依存  ⇒  reducerスキュー問題(9章)
4.1.8  クラスタのサイジング
11
Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p /
•  基本的にどれも使わない⽅方がいい
–  ブレードはI/Oの少ない演算集約型ワークロード向け
–  SANやNASも、Hadoopの並列列処理理においてはI/Oボトル
ネックになる
–  仮想化はHadoopにメリットをもたらさない
•  I/Oのパフォーマンスに敏感なアプリケーションは不不適
4.1.9  ブレード、SAN、仮想化
12
Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p /
4.2  オペレーティングシステムの選択と準備
13
Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p /
•  基本的にはLinux
–  Windowsでも⼀一応動作する(※2)
•  ディレクトリの種類
–  Hadoopのホームディレクトリ
–  NameNode⽤用ディレクトリ(<100GB)
–  DataNode⽤用データディレクトリ
–  MR⽤用ローカルディレクトリ
–  Hadoopのログディレクトリ
–  Hadoopのpidディレクトリ
–  Hadoopのtempディレクトリ(JARファイルの要削除)
⇒  データの増え⽅方に応じてディスクの分離離が必要
•  JAVA
–  64bit  Oracle  JDKが安定動作
4.2.1〜~2  OS、ディレクトリ、JAVA
14
Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p /
•  Hadoopの基本動作
–  DNがハートビートでホスト名とIPアドレスをNNに通知
–  クライアントはNNから通知されたホスト名やIPアドレスを
使⽤用してDNにアクセスする
•  DNでの取得⼿手順
–  InetAddress.getLocalHost()
–  InetAddress#getCanonicalHostName()
⇒  これらの処理理はOS/Javaの実装に依存
•  DNがループバックアドレスを⾃自⾝身のアドレスとして
NNに通知しないよう注意!
4.2.3  ホスト名、DNS、識識別
15
Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p /
•  Hadoopデーモンのユーザ
–  HDFS系  ⇒  hdfs
–  MRv1系  ⇒  mapred(MRv2系  ⇒  yarn)
•  ファイルディスクリプタの上限
–  LinuxはPluggable  Authentication  Modules(PAM)で制御
–  hdfsとmapredユーザに32k個のファイルオープンを許可
•  ディレクトリに適切切なパーミションを設定
–  dfs.name.dir
–  fs.checkpoint.dir
–  dfs.data.dir
–  mapred.local.dir
–  $HADOOP_̲LOG_̲DIR
–  hadoop.tmp.dir
4.2.4  ユーザ、グループ、権限
16
Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p /
•  vm.swappiness  =  0
–  メモリからディスクへのスワップの傾向を制御
–  設定可能な値は、0〜~100
–  値が⼤大きくなると、積極的にスワップする
–  値が⼤大きい場合、処理理がタイムアウトする
⇒  ex)  HBaseはZookeeperと通信できないHRSが障害となる
•  vm.overcommit_̲memory  =  1  ではなく  2
–  物理理的なRAM+スワップ領領域より多くのメモリを割当許可
–  設定可能な値は、0  or  1  or  2
–  Hadoop  Streamingを利利⽤用している場合に問題になる
⇒  Javaのフォーク処理理がvfork()ではなく、fork()で実装されたため
–  vm.overcommit_̲raitoも適切切な値(デフォルト値:50)
⇒  1GBのメモリで、最⼤大1.5GB+スワップまでアロケートを許可
4.3  カーネルパラメータのチューニング
17
Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p /
•  MRはI/O律律速なので、ディスク性能の影響⼤大
•  ファイルシステムの選択
–  ext3  or  ext4  or  xfs
–  パフォーマンスが劣劣化するため、Logical  Volume  Managerは使⽤用しない
–  Volume  Groupも使⽤用しない
•  Volume  Group  ⇒  Physical  Volumeを束ねて1つの記憶容量量にする
•  ext3(リスク回避時はこれを選択すべき)
–  ジャーナリングサポート
–  4KBブロックサイズ  ⇒  最⼤大2TBのファイル、16TBのFSまで対応可
–  ジャーナルレベルは、orderedモード
–  -‐‑‒m1オプションで、4%の節約(スーパーユーザ⽤用ブロック)
–  最適化オプション
•  sparse_̲super:  スーパーブロックのバックアップの⽣生成量量を低減
•  dir_̲index:  B-‐‑‒treeインデックスによりディレクトリ検索索を⾼高速化
4.4  ディスクの構成
18
Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p /
•  ext4
–  ext3よりシーケンシャル処理理を⾼高速化
–  ジャーナルチェックサム機能
•  書き込み処理理時に障害が発⽣生した場合のリカバリーの成功確率率率アップ
–  唯⼀一の弱点は、実績が少ないこと(訳注:⼗十分実績あり)
–  最適化オプション
•  extent:  サイズの⼤大きいファイルのI/O性能が向上(※3)
•  xfs
–  ext3とext4と同様、ジャーナリングサポート
–  ext4と同様、extentベースのアロケーション
–  ext3やext4と異異なり、並列列処理理が可能(※4)
•  複数のアロケーショングループに分割できる
•  各アロケーショングループは固有のinode空間と空き領領域を持つ
•  複数の異異なるスレッドやプロセスから同時にアクセス可能
4.4  ディスクの構成
19
Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p /
•  noatimeオプションを/etc/fstabに追記
–  noatime
•  アクセス対象がファイルかディレクトリを問わず、アクセス時間の
記録を無効化
–  nodiratime
•  ディレクトリへのアクセス時間の記録を無効化
•  ファイルへのアクセス時間の記録は有効のまま
⇒  noatimeオプションのみでOK(nodiratimeは不不要)
•  noatimeオプションによる改善
–  read()システムコールの実⾏行行時間が半減(※5)
4.4.2  マウントオプション
20
Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p /
•  HDFSのトラヒック
–  トラヒックの分類
①  クラスタ管理理のためのトラヒック
–  ブロックレポート
–  ハートビート
②  クライアントからのメタデータ操作
③  ブロックデータの転送
⇒  トラヒックの⼤大半は③が占める
–  ⼀一般的なS/Cの垂直⽅方向ではなく⽔水平⽅方向
–  データノード障害時もデータコピーにより⼤大量量のトラヒッ
クが発⽣生
4.5.1.1  ネットワークの設計
21
垂直⽅方向
⽔水平⽅方向
Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p /
•  MR
–  トラヒックの分類
①  実⾏行行ジョブを監視するためのトラヒック
–  ハートビート
②  実⾏行行ジョブのシャッフルフェーズでのデータ転送
⇒  トラヒックの⼤大半は②が占める
4.5.1.2  ネットワーク設計
22
Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p /
•  1Gbネットワーク  vs  10Gbネットワーク
–  コストメリットで判断すべき
–  利利⽤用形態で選択するのもアリ
•  ETL(Extract/Transform/Load)的な利利⽤用  ⇒  10Gbが望ましい
•  カウントや集計などの分析的な利利⽤用  ⇒  1Gbでも⼗十分かも
–  HBaseで低レイテンシを期待するならば10Gbがベスト
–  1Gbをボンディングするならば、10Gbを検討すべき
•  ポート単価が同じくらいになる
4.5.2  ネットワーク設計
23
Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p /
•  ツリー型トポロジ
–  576台のホストを接続できる構成(12  x  48)
48Gb  >  4  x  10Gb  ⇒  オーバーサブスクリプション(⽐比=1.2:1)
ネットワーク設計
24
4
48
Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p /
•  ツリー型トポロジ
–  1152台のホストを接続できる構成(24  x  48)
–  1.2:1のオーバーサブスクリプション⽐比が維持できない
4.5.3.1  ネットワーク設計
25
3
48
12
Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p /
•  ツリー型トポロジの注意点
–  クラスタへのデータ⼊入出⼒力力はトポロジのルート近くで実施
すべき
•  ETL、プロセスオーケストレーション、データベースなど
–  低レイテンシのサービスは、ディストリビューションス
イッチ配下にはおいてはいけない
•  ⼤大量量のデータトラヒックがネットワーク遅延を引き起こす
4.5.3.1  ネットワーク設計
26
Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p /
•  スパイン(背⾻骨)ファブリック型トポロジ
–  どのホストも可能な限り等距離離になるメッシュ型に近い
–  1.2:1のオーバーサブスクリプション⽐比を維持できる
ネットワーク設計
27
L3ルーティングネットワーク
2
2
48
Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p /
•  スパインファブリック型トポロジ
–  1.2:1のオーバーサブスクリプション⽐比を維持しつつ、
2304台のホストを接続できる
4.5.3.2ネットワーク設計
28
48
10GbE 10GbE 10GbE 10GbE
(48)
(2304)
L3ルーティングネットワーク
1
1
1
1
Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p /
•  ツリー型トポロジ
–  ホストの台数が少ないと、オーバーサブスクリプション⽐比
を低く抑えることができる
–  逆に、台数が増えると、層の追加が必要となり、オーバー
サブスクリプション⽐比が劣劣化する
•  スパインファブリック型トポロジ
–  ホストの台数が増えても、オーバーサブスクリプション⽐比
が劣劣化することなく、スケールアウトできる
–  通信経路路が1つではないため、static  routingが利利⽤用できず、
L3レベルのルーティングプロトコルを動作させる必要あり
4.5  ネットワーク構成
29
Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p /
※1:  http://archive.cloudera.com/cdh5/cdh/5/
※2:  http://qiita.com/moris/items/0a23bf26abc4289bb258
※3:  http://wiki.openwrt.org/doc/howto/storage
※4:  http://ja.wikipedia.org/wiki/XFS
※5:  http://shiumachi.hatenablog.com/entry/20080614/1213415948
参考情報
30

Weitere ähnliche Inhalte

Was ist angesagt?

HBaseを用いたグラフDB「Hornet」の設計と運用
HBaseを用いたグラフDB「Hornet」の設計と運用HBaseを用いたグラフDB「Hornet」の設計と運用
HBaseを用いたグラフDB「Hornet」の設計と運用Toshihiro Suzuki
 
Kuduを調べてみた #dogenzakalt
Kuduを調べてみた #dogenzakaltKuduを調べてみた #dogenzakalt
Kuduを調べてみた #dogenzakaltToshihiro Suzuki
 
CDH4.1オーバービュー
CDH4.1オーバービューCDH4.1オーバービュー
CDH4.1オーバービューCloudera Japan
 
HiveとImpalaのおいしいとこ取り
HiveとImpalaのおいしいとこ取りHiveとImpalaのおいしいとこ取り
HiveとImpalaのおいしいとこ取りYukinori Suda
 
ATN No.1 MapReduceだけでない!? Hadoopとその仲間たち
ATN No.1 MapReduceだけでない!? Hadoopとその仲間たちATN No.1 MapReduceだけでない!? Hadoopとその仲間たち
ATN No.1 MapReduceだけでない!? Hadoopとその仲間たちAdvancedTechNight
 
20190314 PGStrom Arrow_Fdw
20190314 PGStrom Arrow_Fdw20190314 PGStrom Arrow_Fdw
20190314 PGStrom Arrow_FdwKohei KaiGai
 
MapR アーキテクチャ概要 - MapR CTO Meetup 2013/11/12
MapR アーキテクチャ概要 - MapR CTO Meetup 2013/11/12MapR アーキテクチャ概要 - MapR CTO Meetup 2013/11/12
MapR アーキテクチャ概要 - MapR CTO Meetup 2013/11/12MapR Technologies Japan
 
なぜApache HBaseを選ぶのか? #cwt2013
なぜApache HBaseを選ぶのか? #cwt2013なぜApache HBaseを選ぶのか? #cwt2013
なぜApache HBaseを選ぶのか? #cwt2013Cloudera Japan
 
Hadoopのシステム設計・運用のポイント
Hadoopのシステム設計・運用のポイントHadoopのシステム設計・運用のポイント
Hadoopのシステム設計・運用のポイントCloudera Japan
 
Cloudera Impalaをサービスに組み込むときに苦労した話
Cloudera Impalaをサービスに組み込むときに苦労した話Cloudera Impalaをサービスに組み込むときに苦労した話
Cloudera Impalaをサービスに組み込むときに苦労した話Yukinori Suda
 
大規模ログ分析におけるAmazon Web Servicesの活用
大規模ログ分析におけるAmazon Web Servicesの活用大規模ログ分析におけるAmazon Web Servicesの活用
大規模ログ分析におけるAmazon Web Servicesの活用Shintaro Takemura
 
HBase×Impalaで作るアドテク 「GMOプライベートDMP」@HBaseMeetupTokyo2015Summer
HBase×Impalaで作るアドテク「GMOプライベートDMP」@HBaseMeetupTokyo2015SummerHBase×Impalaで作るアドテク「GMOプライベートDMP」@HBaseMeetupTokyo2015Summer
HBase×Impalaで作るアドテク 「GMOプライベートDMP」@HBaseMeetupTokyo2015SummerMichio Katano
 
Hadoop Troubleshooting 101 - Japanese Version
Hadoop Troubleshooting 101 - Japanese VersionHadoop Troubleshooting 101 - Japanese Version
Hadoop Troubleshooting 101 - Japanese VersionCloudera, Inc.
 
MapReduce/Spark/Tezのフェアな性能比較に向けて (Cloudera World Tokyo 2014 LT講演)
MapReduce/Spark/Tezのフェアな性能比較に向けて (Cloudera World Tokyo 2014 LT講演)MapReduce/Spark/Tezのフェアな性能比較に向けて (Cloudera World Tokyo 2014 LT講演)
MapReduce/Spark/Tezのフェアな性能比較に向けて (Cloudera World Tokyo 2014 LT講演)Hadoop / Spark Conference Japan
 
HDFS新機能総まとめin 2015 (日本Hadoopユーザー会 ライトニングトーク@Cloudera World Tokyo 2015 講演資料)
HDFS新機能総まとめin 2015 (日本Hadoopユーザー会 ライトニングトーク@Cloudera World Tokyo 2015 講演資料)HDFS新機能総まとめin 2015 (日本Hadoopユーザー会 ライトニングトーク@Cloudera World Tokyo 2015 講演資料)
HDFS新機能総まとめin 2015 (日本Hadoopユーザー会 ライトニングトーク@Cloudera World Tokyo 2015 講演資料)NTT DATA OSS Professional Services
 
スケーラブルなシステムのためのHBaseスキーマ設計 #hcj13w
スケーラブルなシステムのためのHBaseスキーマ設計 #hcj13wスケーラブルなシステムのためのHBaseスキーマ設計 #hcj13w
スケーラブルなシステムのためのHBaseスキーマ設計 #hcj13wCloudera Japan
 
[D36] Michael Stonebrakerが生み出した列指向データベースは何が凄いのか? ~Verticaを例に列指向データベースのアーキテクチャ...
[D36] Michael Stonebrakerが生み出した列指向データベースは何が凄いのか? ~Verticaを例に列指向データベースのアーキテクチャ...[D36] Michael Stonebrakerが生み出した列指向データベースは何が凄いのか? ~Verticaを例に列指向データベースのアーキテクチャ...
[D36] Michael Stonebrakerが生み出した列指向データベースは何が凄いのか? ~Verticaを例に列指向データベースのアーキテクチャ...Insight Technology, Inc.
 
Apache Drill Overview - Tokyo Apache Drill Meetup 2015/09/15
Apache Drill Overview - Tokyo Apache Drill Meetup 2015/09/15Apache Drill Overview - Tokyo Apache Drill Meetup 2015/09/15
Apache Drill Overview - Tokyo Apache Drill Meetup 2015/09/15MapR Technologies Japan
 

Was ist angesagt? (20)

MapR M7 技術概要
MapR M7 技術概要MapR M7 技術概要
MapR M7 技術概要
 
HBaseを用いたグラフDB「Hornet」の設計と運用
HBaseを用いたグラフDB「Hornet」の設計と運用HBaseを用いたグラフDB「Hornet」の設計と運用
HBaseを用いたグラフDB「Hornet」の設計と運用
 
Kuduを調べてみた #dogenzakalt
Kuduを調べてみた #dogenzakaltKuduを調べてみた #dogenzakalt
Kuduを調べてみた #dogenzakalt
 
CDH4.1オーバービュー
CDH4.1オーバービューCDH4.1オーバービュー
CDH4.1オーバービュー
 
HiveとImpalaのおいしいとこ取り
HiveとImpalaのおいしいとこ取りHiveとImpalaのおいしいとこ取り
HiveとImpalaのおいしいとこ取り
 
ATN No.1 MapReduceだけでない!? Hadoopとその仲間たち
ATN No.1 MapReduceだけでない!? Hadoopとその仲間たちATN No.1 MapReduceだけでない!? Hadoopとその仲間たち
ATN No.1 MapReduceだけでない!? Hadoopとその仲間たち
 
20190314 PGStrom Arrow_Fdw
20190314 PGStrom Arrow_Fdw20190314 PGStrom Arrow_Fdw
20190314 PGStrom Arrow_Fdw
 
MapR アーキテクチャ概要 - MapR CTO Meetup 2013/11/12
MapR アーキテクチャ概要 - MapR CTO Meetup 2013/11/12MapR アーキテクチャ概要 - MapR CTO Meetup 2013/11/12
MapR アーキテクチャ概要 - MapR CTO Meetup 2013/11/12
 
なぜApache HBaseを選ぶのか? #cwt2013
なぜApache HBaseを選ぶのか? #cwt2013なぜApache HBaseを選ぶのか? #cwt2013
なぜApache HBaseを選ぶのか? #cwt2013
 
Hadoopのシステム設計・運用のポイント
Hadoopのシステム設計・運用のポイントHadoopのシステム設計・運用のポイント
Hadoopのシステム設計・運用のポイント
 
Cloudera Impalaをサービスに組み込むときに苦労した話
Cloudera Impalaをサービスに組み込むときに苦労した話Cloudera Impalaをサービスに組み込むときに苦労した話
Cloudera Impalaをサービスに組み込むときに苦労した話
 
大規模ログ分析におけるAmazon Web Servicesの活用
大規模ログ分析におけるAmazon Web Servicesの活用大規模ログ分析におけるAmazon Web Servicesの活用
大規模ログ分析におけるAmazon Web Servicesの活用
 
HBase×Impalaで作るアドテク 「GMOプライベートDMP」@HBaseMeetupTokyo2015Summer
HBase×Impalaで作るアドテク「GMOプライベートDMP」@HBaseMeetupTokyo2015SummerHBase×Impalaで作るアドテク「GMOプライベートDMP」@HBaseMeetupTokyo2015Summer
HBase×Impalaで作るアドテク 「GMOプライベートDMP」@HBaseMeetupTokyo2015Summer
 
Hadoop Troubleshooting 101 - Japanese Version
Hadoop Troubleshooting 101 - Japanese VersionHadoop Troubleshooting 101 - Japanese Version
Hadoop Troubleshooting 101 - Japanese Version
 
MapReduce/Spark/Tezのフェアな性能比較に向けて (Cloudera World Tokyo 2014 LT講演)
MapReduce/Spark/Tezのフェアな性能比較に向けて (Cloudera World Tokyo 2014 LT講演)MapReduce/Spark/Tezのフェアな性能比較に向けて (Cloudera World Tokyo 2014 LT講演)
MapReduce/Spark/Tezのフェアな性能比較に向けて (Cloudera World Tokyo 2014 LT講演)
 
HDFS Deep Dive
HDFS Deep DiveHDFS Deep Dive
HDFS Deep Dive
 
HDFS新機能総まとめin 2015 (日本Hadoopユーザー会 ライトニングトーク@Cloudera World Tokyo 2015 講演資料)
HDFS新機能総まとめin 2015 (日本Hadoopユーザー会 ライトニングトーク@Cloudera World Tokyo 2015 講演資料)HDFS新機能総まとめin 2015 (日本Hadoopユーザー会 ライトニングトーク@Cloudera World Tokyo 2015 講演資料)
HDFS新機能総まとめin 2015 (日本Hadoopユーザー会 ライトニングトーク@Cloudera World Tokyo 2015 講演資料)
 
スケーラブルなシステムのためのHBaseスキーマ設計 #hcj13w
スケーラブルなシステムのためのHBaseスキーマ設計 #hcj13wスケーラブルなシステムのためのHBaseスキーマ設計 #hcj13w
スケーラブルなシステムのためのHBaseスキーマ設計 #hcj13w
 
[D36] Michael Stonebrakerが生み出した列指向データベースは何が凄いのか? ~Verticaを例に列指向データベースのアーキテクチャ...
[D36] Michael Stonebrakerが生み出した列指向データベースは何が凄いのか? ~Verticaを例に列指向データベースのアーキテクチャ...[D36] Michael Stonebrakerが生み出した列指向データベースは何が凄いのか? ~Verticaを例に列指向データベースのアーキテクチャ...
[D36] Michael Stonebrakerが生み出した列指向データベースは何が凄いのか? ~Verticaを例に列指向データベースのアーキテクチャ...
 
Apache Drill Overview - Tokyo Apache Drill Meetup 2015/09/15
Apache Drill Overview - Tokyo Apache Drill Meetup 2015/09/15Apache Drill Overview - Tokyo Apache Drill Meetup 2015/09/15
Apache Drill Overview - Tokyo Apache Drill Meetup 2015/09/15
 

Andere mochten auch

⾃宅で Hive 愛を育むための⼿順(Raspberry Pi 編)
⾃宅で Hive 愛を育むための⼿順(Raspberry Pi 編)⾃宅で Hive 愛を育むための⼿順(Raspberry Pi 編)
⾃宅で Hive 愛を育むための⼿順(Raspberry Pi 編)Yukinori Suda
 
自宅でHive愛を育む方法 〜Raspberry Pi編〜
自宅でHive愛を育む方法 〜Raspberry Pi編〜自宅でHive愛を育む方法 〜Raspberry Pi編〜
自宅でHive愛を育む方法 〜Raspberry Pi編〜Yukinori Suda
 
Hadoopエコシステムを駆使したこれからのWebアクセス解析サービス
Hadoopエコシステムを駆使したこれからのWebアクセス解析サービスHadoopエコシステムを駆使したこれからのWebアクセス解析サービス
Hadoopエコシステムを駆使したこれからのWebアクセス解析サービスYukinori Suda
 
Cloudera impalaの性能評価(Hiveとの比較)
Cloudera impalaの性能評価(Hiveとの比較)Cloudera impalaの性能評価(Hiveとの比較)
Cloudera impalaの性能評価(Hiveとの比較)Yukinori Suda
 
Hadoop Operations #cwt2013
Hadoop Operations #cwt2013Hadoop Operations #cwt2013
Hadoop Operations #cwt2013Cloudera Japan
 
Hadoopの標準GUI HUEの最新情報
Hadoopの標準GUI HUEの最新情報Hadoopの標準GUI HUEの最新情報
Hadoopの標準GUI HUEの最新情報Cloudera Japan
 
基幹業務もHadoopで!! -ローソンにおける店舗発注業務への Hadoop + Hive導入と その取り組みについて-
基幹業務もHadoopで!! -ローソンにおける店舗発注業務へのHadoop + Hive導入と その取り組みについて-基幹業務もHadoopで!! -ローソンにおける店舗発注業務へのHadoop + Hive導入と その取り組みについて-
基幹業務もHadoopで!! -ローソンにおける店舗発注業務への Hadoop + Hive導入と その取り組みについて-Keigo Suda
 

Andere mochten auch (8)

⾃宅で Hive 愛を育むための⼿順(Raspberry Pi 編)
⾃宅で Hive 愛を育むための⼿順(Raspberry Pi 編)⾃宅で Hive 愛を育むための⼿順(Raspberry Pi 編)
⾃宅で Hive 愛を育むための⼿順(Raspberry Pi 編)
 
自宅でHive愛を育む方法 〜Raspberry Pi編〜
自宅でHive愛を育む方法 〜Raspberry Pi編〜自宅でHive愛を育む方法 〜Raspberry Pi編〜
自宅でHive愛を育む方法 〜Raspberry Pi編〜
 
Hadoopエコシステムを駆使したこれからのWebアクセス解析サービス
Hadoopエコシステムを駆使したこれからのWebアクセス解析サービスHadoopエコシステムを駆使したこれからのWebアクセス解析サービス
Hadoopエコシステムを駆使したこれからのWebアクセス解析サービス
 
Cloudera impalaの性能評価(Hiveとの比較)
Cloudera impalaの性能評価(Hiveとの比較)Cloudera impalaの性能評価(Hiveとの比較)
Cloudera impalaの性能評価(Hiveとの比較)
 
Hadoop Operations #cwt2013
Hadoop Operations #cwt2013Hadoop Operations #cwt2013
Hadoop Operations #cwt2013
 
Hadoopの標準GUI HUEの最新情報
Hadoopの標準GUI HUEの最新情報Hadoopの標準GUI HUEの最新情報
Hadoopの標準GUI HUEの最新情報
 
JSONBはPostgreSQL9.5でいかに改善されたのか
JSONBはPostgreSQL9.5でいかに改善されたのかJSONBはPostgreSQL9.5でいかに改善されたのか
JSONBはPostgreSQL9.5でいかに改善されたのか
 
基幹業務もHadoopで!! -ローソンにおける店舗発注業務への Hadoop + Hive導入と その取り組みについて-
基幹業務もHadoopで!! -ローソンにおける店舗発注業務へのHadoop + Hive導入と その取り組みについて-基幹業務もHadoopで!! -ローソンにおける店舗発注業務へのHadoop + Hive導入と その取り組みについて-
基幹業務もHadoopで!! -ローソンにおける店舗発注業務への Hadoop + Hive導入と その取り組みについて-
 

Ähnlich wie Hadoop operation chaper 4

Impala + Kudu を用いたデータウェアハウス構築の勘所 (仮)
Impala + Kudu を用いたデータウェアハウス構築の勘所 (仮)Impala + Kudu を用いたデータウェアハウス構築の勘所 (仮)
Impala + Kudu を用いたデータウェアハウス構築の勘所 (仮)Cloudera Japan
 
ゆるふわLinux-HA 〜PostgreSQL編〜
ゆるふわLinux-HA 〜PostgreSQL編〜ゆるふわLinux-HA 〜PostgreSQL編〜
ゆるふわLinux-HA 〜PostgreSQL編〜Taro Matsuzawa
 
Open stack reference architecture v1 2
Open stack reference architecture v1 2Open stack reference architecture v1 2
Open stack reference architecture v1 2Dell TechCenter Japan
 
[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)
[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)
[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)Insight Technology, Inc.
 
[db tech showcase Sapporo 2015] A12:DBAが知っておくべき最新テクノロジー: フラッシュ, ストレージ, クラウド b...
[db tech showcase Sapporo 2015] A12:DBAが知っておくべき最新テクノロジー: フラッシュ, ストレージ, クラウド b...[db tech showcase Sapporo 2015] A12:DBAが知っておくべき最新テクノロジー: フラッシュ, ストレージ, クラウド b...
[db tech showcase Sapporo 2015] A12:DBAが知っておくべき最新テクノロジー: フラッシュ, ストレージ, クラウド b...Insight Technology, Inc.
 
Cloudera大阪セミナー 20130219
Cloudera大阪セミナー 20130219Cloudera大阪セミナー 20130219
Cloudera大阪セミナー 20130219Cloudera Japan
 
OpenStackでつくる開発環境と外道塾
OpenStackでつくる開発環境と外道塾OpenStackでつくる開発環境と外道塾
OpenStackでつくる開発環境と外道塾外道 父
 
最新版Hadoopクラスタを運用して得られたもの
最新版Hadoopクラスタを運用して得られたもの最新版Hadoopクラスタを運用して得られたもの
最新版Hadoopクラスタを運用して得られたものcyberagent
 
Hadoop 2.6の最新機能(Cloudera World Tokyo 2014 LT講演資料)
Hadoop 2.6の最新機能(Cloudera World Tokyo 2014 LT講演資料)Hadoop 2.6の最新機能(Cloudera World Tokyo 2014 LT講演資料)
Hadoop 2.6の最新機能(Cloudera World Tokyo 2014 LT講演資料)NTT DATA OSS Professional Services
 
Linux の hugepage の開発動向
Linux の hugepage の開発動向Linux の hugepage の開発動向
Linux の hugepage の開発動向Naoya Horiguchi
 
BOSTON Viridis for Hadoop by ELSA Japan
BOSTON Viridis for Hadoop by ELSA JapanBOSTON Viridis for Hadoop by ELSA Japan
BOSTON Viridis for Hadoop by ELSA JapanAtsushi Suzuki
 
[db tech showcase Tokyo 2014] D24: データベース環境における検証結果から理解する失敗しないフラッシュ活用法 by ネッ...
[db tech showcase Tokyo 2014] D24: データベース環境における検証結果から理解する失敗しないフラッシュ活用法  by ネッ...[db tech showcase Tokyo 2014] D24: データベース環境における検証結果から理解する失敗しないフラッシュ活用法  by ネッ...
[db tech showcase Tokyo 2014] D24: データベース環境における検証結果から理解する失敗しないフラッシュ活用法 by ネッ...Insight Technology, Inc.
 
Red Hat OpenShift Container Storage
Red Hat OpenShift Container StorageRed Hat OpenShift Container Storage
Red Hat OpenShift Container StorageTakuya Utsunomiya
 
[db tech showcase Tokyo 2015] D13:PCIeフラッシュで、高可用性高性能データベースシステム?! by 株式会社HGSTジ...
[db tech showcase Tokyo 2015] D13:PCIeフラッシュで、高可用性高性能データベースシステム?! by 株式会社HGSTジ...[db tech showcase Tokyo 2015] D13:PCIeフラッシュで、高可用性高性能データベースシステム?! by 株式会社HGSTジ...
[db tech showcase Tokyo 2015] D13:PCIeフラッシュで、高可用性高性能データベースシステム?! by 株式会社HGSTジ...Insight Technology, Inc.
 
トランザクションの設計と進化
トランザクションの設計と進化トランザクションの設計と進化
トランザクションの設計と進化Kumazaki Hiroki
 
Hadoop Trends & Hadoop on EC2
Hadoop Trends & Hadoop on EC2Hadoop Trends & Hadoop on EC2
Hadoop Trends & Hadoop on EC2Yifeng Jiang
 

Ähnlich wie Hadoop operation chaper 4 (20)

Impala + Kudu を用いたデータウェアハウス構築の勘所 (仮)
Impala + Kudu を用いたデータウェアハウス構築の勘所 (仮)Impala + Kudu を用いたデータウェアハウス構築の勘所 (仮)
Impala + Kudu を用いたデータウェアハウス構築の勘所 (仮)
 
ゆるふわLinux-HA 〜PostgreSQL編〜
ゆるふわLinux-HA 〜PostgreSQL編〜ゆるふわLinux-HA 〜PostgreSQL編〜
ゆるふわLinux-HA 〜PostgreSQL編〜
 
Apache Big Data Miami 2017 - Hadoop Source Code Reading #23 #hadoopreading
Apache Big Data Miami 2017 - Hadoop Source Code Reading #23 #hadoopreadingApache Big Data Miami 2017 - Hadoop Source Code Reading #23 #hadoopreading
Apache Big Data Miami 2017 - Hadoop Source Code Reading #23 #hadoopreading
 
Open stack reference architecture v1 2
Open stack reference architecture v1 2Open stack reference architecture v1 2
Open stack reference architecture v1 2
 
[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)
[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)
[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)
 
[db tech showcase Sapporo 2015] A12:DBAが知っておくべき最新テクノロジー: フラッシュ, ストレージ, クラウド b...
[db tech showcase Sapporo 2015] A12:DBAが知っておくべき最新テクノロジー: フラッシュ, ストレージ, クラウド b...[db tech showcase Sapporo 2015] A12:DBAが知っておくべき最新テクノロジー: フラッシュ, ストレージ, クラウド b...
[db tech showcase Sapporo 2015] A12:DBAが知っておくべき最新テクノロジー: フラッシュ, ストレージ, クラウド b...
 
Cloudera大阪セミナー 20130219
Cloudera大阪セミナー 20130219Cloudera大阪セミナー 20130219
Cloudera大阪セミナー 20130219
 
OpenStackでつくる開発環境と外道塾
OpenStackでつくる開発環境と外道塾OpenStackでつくる開発環境と外道塾
OpenStackでつくる開発環境と外道塾
 
最新版Hadoopクラスタを運用して得られたもの
最新版Hadoopクラスタを運用して得られたもの最新版Hadoopクラスタを運用して得られたもの
最新版Hadoopクラスタを運用して得られたもの
 
Sensu + Graphite を1年運⽤してみて #sensucasual
Sensu + Graphite を1年運⽤してみて #sensucasual Sensu + Graphite を1年運⽤してみて #sensucasual
Sensu + Graphite を1年運⽤してみて #sensucasual
 
Hadoop 2.6の最新機能(Cloudera World Tokyo 2014 LT講演資料)
Hadoop 2.6の最新機能(Cloudera World Tokyo 2014 LT講演資料)Hadoop 2.6の最新機能(Cloudera World Tokyo 2014 LT講演資料)
Hadoop 2.6の最新機能(Cloudera World Tokyo 2014 LT講演資料)
 
Linux の hugepage の開発動向
Linux の hugepage の開発動向Linux の hugepage の開発動向
Linux の hugepage の開発動向
 
BOSTON Viridis for Hadoop by ELSA Japan
BOSTON Viridis for Hadoop by ELSA JapanBOSTON Viridis for Hadoop by ELSA Japan
BOSTON Viridis for Hadoop by ELSA Japan
 
Hadoop, NoSQL, GlusterFSの概要
Hadoop, NoSQL, GlusterFSの概要Hadoop, NoSQL, GlusterFSの概要
Hadoop, NoSQL, GlusterFSの概要
 
[db tech showcase Tokyo 2014] D24: データベース環境における検証結果から理解する失敗しないフラッシュ活用法 by ネッ...
[db tech showcase Tokyo 2014] D24: データベース環境における検証結果から理解する失敗しないフラッシュ活用法  by ネッ...[db tech showcase Tokyo 2014] D24: データベース環境における検証結果から理解する失敗しないフラッシュ活用法  by ネッ...
[db tech showcase Tokyo 2014] D24: データベース環境における検証結果から理解する失敗しないフラッシュ活用法 by ネッ...
 
Red Hat OpenShift Container Storage
Red Hat OpenShift Container StorageRed Hat OpenShift Container Storage
Red Hat OpenShift Container Storage
 
[db tech showcase Tokyo 2015] D13:PCIeフラッシュで、高可用性高性能データベースシステム?! by 株式会社HGSTジ...
[db tech showcase Tokyo 2015] D13:PCIeフラッシュで、高可用性高性能データベースシステム?! by 株式会社HGSTジ...[db tech showcase Tokyo 2015] D13:PCIeフラッシュで、高可用性高性能データベースシステム?! by 株式会社HGSTジ...
[db tech showcase Tokyo 2015] D13:PCIeフラッシュで、高可用性高性能データベースシステム?! by 株式会社HGSTジ...
 
WalBの紹介
WalBの紹介WalBの紹介
WalBの紹介
 
トランザクションの設計と進化
トランザクションの設計と進化トランザクションの設計と進化
トランザクションの設計と進化
 
Hadoop Trends & Hadoop on EC2
Hadoop Trends & Hadoop on EC2Hadoop Trends & Hadoop on EC2
Hadoop Trends & Hadoop on EC2
 

Hadoop operation chaper 4

  • 1. Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p / 4章  Hadoopクラスタの計画 〜~Hadoopオペレーション〜~ 2015年年2⽉月9⽇日 株式会社セラン  R&D戦略略室 須⽥田幸憲 @sudabon
  • 2. Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p / 4.1  Hadoopディストリビューションとバージョン選択 2
  • 3. Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p / •  本家  @  Apache  Software  Foundation •  ディストリビューション(クラウドサービスを含む) –  オンプレミス •  CDH  @  Cloudera –  本家と⽐比べて、リリース遅め –  重要な機能やバグはバックポートされる •  HDP  @  HortonWorks –  CDHよりは、リリース早め –  HDPのCMと⾔言えるAmbariが⾮非⼒力力 •  MapR  M7  @  MapR  Technologies –  本家のソースを独⾃自に改良良し、OSSではない –  HDFSだけでなく、Linux  FSでも動作 –  クラウドサービス •  EMR  @  AWS –  本家のソースを独⾃自に改良良 •  Azure  @  Microsoft 4.1  Hadoopディストリビューション 3
  • 4. Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p / •  CDH  5.3.0のコンポーネント –  avro –  bigtop –  cdk –  crunch  :  MR  Pipeline –  datafu  :  UDF  for  Pig –  flume –  hadoop –  hbase –  hive –  hue –  impala –  kite  :  For  Developers –  llama 4.1.2  Hadoopのコンポーネント 4 (※1) –  mahout –  oozie –  parquet  (parquet-‐‑‒format) –  pig –  search  (solr) –  setnry –  spark –  sqoop –  sqoop2  :  also  MongoDB –  whirr  :  scripts  for  Cloud –  zookeeper
  • 5. Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p / •  紆余曲折があったが、重要なのは、 –  バージョン1系 –  バージョン2系 が存在すること •  バージョン1系 –  0.20.0がベースで、MRv1世代 –  既に昔話になりつつあるので、知らなくていいと思います •  バージョン2系 –  0.23.0がベース、YARN(MRv2)世代 –  本家の最新バージョンは2.6 –  CDHにはバージョン2.5以降降が含まれる 4.1.3  Hadoopのバージョン 5
  • 6. Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p / •  重要なこと –  RAIDではなく、JBOD(Just  a  Bunch  Of  Disks)指向 –  マスターは耐障害性が必要 –  ワーカー(スレーブ)は障害発⽣生が前提 –  基本的にマスターとワーカーの2種類のサーバを準備 •  マスターノード –  ハイエンドスペック –  ⼆二重化電源 –  ボンディングNIC –  RAID  1+0 –  ⼤大容量量RAM –  OS⽤用とHadoop⽤用のディスクを分離離 4.1.5〜~7  ハードウェアの選択 6
  • 7. Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p / •  20台以下のクラスタであれば... –  マスターノード •  4コア2.6GHz  CPU  ×  2 •  24GB  DDR3  RAM •  1Gbps  NIC •  SATA  II  ×  2  ×  2 •  NameNodeのハードウェア –  安定運⽤用の絶対条件 •  メタデータ量量で必要となるサイズ以上のメモリ •  NameNode専⽤用のディスク •  独⽴立立ノード(他のデーモンと共存させない) –  ⼤大量量の⼩小サイズのファイルを処理理させない  ⇒  結合 •  100万ブロックで1GBのメモリを消費 4.1.5〜~7  ハードウェアの選択 7
  • 8. Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p / •  JobTrackerのハードウェア –  ⼤大量量のメモリを消費 •  100個(デフォルト値)のジョブのメタデータ情報をメモリに保持 •  ワーカーノードのハードウェア –  ストレージ  ⇒  データ量量に依存、⼀一時保存⽤用(20〜~30%) –  メモリ  ⇒  処理理データ量量に依存 –  CPU  ⇒  並列列処理理度度(必要スロット数)に依存 4.1.5〜~7  ハードウェアの選択 8
  • 9. Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p / 典型的なワーカーノードのハードウェアスペック 9
  • 10. Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p / 典型的なワーカーノードのハードウェアスペック 10
  • 11. Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p / •  ノード数の決定⽅方法は2つある –  通常は、ストレージ容量量 –  場合に依っては、ジョブの処理理時間 •  実⾏行行しないと必要なリソース量量が明確にならない(鶏と卵卵の問題) •  map処理理では、消費リソースはリニアに増⼤大するので、⼩小規模な データサイズでベンチマークで予測可能 •  reduce処理理は、処理理内容依存  ⇒  reducerスキュー問題(9章) 4.1.8  クラスタのサイジング 11
  • 12. Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p / •  基本的にどれも使わない⽅方がいい –  ブレードはI/Oの少ない演算集約型ワークロード向け –  SANやNASも、Hadoopの並列列処理理においてはI/Oボトル ネックになる –  仮想化はHadoopにメリットをもたらさない •  I/Oのパフォーマンスに敏感なアプリケーションは不不適 4.1.9  ブレード、SAN、仮想化 12
  • 13. Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p / 4.2  オペレーティングシステムの選択と準備 13
  • 14. Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p / •  基本的にはLinux –  Windowsでも⼀一応動作する(※2) •  ディレクトリの種類 –  Hadoopのホームディレクトリ –  NameNode⽤用ディレクトリ(<100GB) –  DataNode⽤用データディレクトリ –  MR⽤用ローカルディレクトリ –  Hadoopのログディレクトリ –  Hadoopのpidディレクトリ –  Hadoopのtempディレクトリ(JARファイルの要削除) ⇒  データの増え⽅方に応じてディスクの分離離が必要 •  JAVA –  64bit  Oracle  JDKが安定動作 4.2.1〜~2  OS、ディレクトリ、JAVA 14
  • 15. Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p / •  Hadoopの基本動作 –  DNがハートビートでホスト名とIPアドレスをNNに通知 –  クライアントはNNから通知されたホスト名やIPアドレスを 使⽤用してDNにアクセスする •  DNでの取得⼿手順 –  InetAddress.getLocalHost() –  InetAddress#getCanonicalHostName() ⇒  これらの処理理はOS/Javaの実装に依存 •  DNがループバックアドレスを⾃自⾝身のアドレスとして NNに通知しないよう注意! 4.2.3  ホスト名、DNS、識識別 15
  • 16. Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p / •  Hadoopデーモンのユーザ –  HDFS系  ⇒  hdfs –  MRv1系  ⇒  mapred(MRv2系  ⇒  yarn) •  ファイルディスクリプタの上限 –  LinuxはPluggable  Authentication  Modules(PAM)で制御 –  hdfsとmapredユーザに32k個のファイルオープンを許可 •  ディレクトリに適切切なパーミションを設定 –  dfs.name.dir –  fs.checkpoint.dir –  dfs.data.dir –  mapred.local.dir –  $HADOOP_̲LOG_̲DIR –  hadoop.tmp.dir 4.2.4  ユーザ、グループ、権限 16
  • 17. Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p / •  vm.swappiness  =  0 –  メモリからディスクへのスワップの傾向を制御 –  設定可能な値は、0〜~100 –  値が⼤大きくなると、積極的にスワップする –  値が⼤大きい場合、処理理がタイムアウトする ⇒  ex)  HBaseはZookeeperと通信できないHRSが障害となる •  vm.overcommit_̲memory  =  1  ではなく  2 –  物理理的なRAM+スワップ領領域より多くのメモリを割当許可 –  設定可能な値は、0  or  1  or  2 –  Hadoop  Streamingを利利⽤用している場合に問題になる ⇒  Javaのフォーク処理理がvfork()ではなく、fork()で実装されたため –  vm.overcommit_̲raitoも適切切な値(デフォルト値:50) ⇒  1GBのメモリで、最⼤大1.5GB+スワップまでアロケートを許可 4.3  カーネルパラメータのチューニング 17
  • 18. Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p / •  MRはI/O律律速なので、ディスク性能の影響⼤大 •  ファイルシステムの選択 –  ext3  or  ext4  or  xfs –  パフォーマンスが劣劣化するため、Logical  Volume  Managerは使⽤用しない –  Volume  Groupも使⽤用しない •  Volume  Group  ⇒  Physical  Volumeを束ねて1つの記憶容量量にする •  ext3(リスク回避時はこれを選択すべき) –  ジャーナリングサポート –  4KBブロックサイズ  ⇒  最⼤大2TBのファイル、16TBのFSまで対応可 –  ジャーナルレベルは、orderedモード –  -‐‑‒m1オプションで、4%の節約(スーパーユーザ⽤用ブロック) –  最適化オプション •  sparse_̲super:  スーパーブロックのバックアップの⽣生成量量を低減 •  dir_̲index:  B-‐‑‒treeインデックスによりディレクトリ検索索を⾼高速化 4.4  ディスクの構成 18
  • 19. Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p / •  ext4 –  ext3よりシーケンシャル処理理を⾼高速化 –  ジャーナルチェックサム機能 •  書き込み処理理時に障害が発⽣生した場合のリカバリーの成功確率率率アップ –  唯⼀一の弱点は、実績が少ないこと(訳注:⼗十分実績あり) –  最適化オプション •  extent:  サイズの⼤大きいファイルのI/O性能が向上(※3) •  xfs –  ext3とext4と同様、ジャーナリングサポート –  ext4と同様、extentベースのアロケーション –  ext3やext4と異異なり、並列列処理理が可能(※4) •  複数のアロケーショングループに分割できる •  各アロケーショングループは固有のinode空間と空き領領域を持つ •  複数の異異なるスレッドやプロセスから同時にアクセス可能 4.4  ディスクの構成 19
  • 20. Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p / •  noatimeオプションを/etc/fstabに追記 –  noatime •  アクセス対象がファイルかディレクトリを問わず、アクセス時間の 記録を無効化 –  nodiratime •  ディレクトリへのアクセス時間の記録を無効化 •  ファイルへのアクセス時間の記録は有効のまま ⇒  noatimeオプションのみでOK(nodiratimeは不不要) •  noatimeオプションによる改善 –  read()システムコールの実⾏行行時間が半減(※5) 4.4.2  マウントオプション 20
  • 21. Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p / •  HDFSのトラヒック –  トラヒックの分類 ①  クラスタ管理理のためのトラヒック –  ブロックレポート –  ハートビート ②  クライアントからのメタデータ操作 ③  ブロックデータの転送 ⇒  トラヒックの⼤大半は③が占める –  ⼀一般的なS/Cの垂直⽅方向ではなく⽔水平⽅方向 –  データノード障害時もデータコピーにより⼤大量量のトラヒッ クが発⽣生 4.5.1.1  ネットワークの設計 21 垂直⽅方向 ⽔水平⽅方向
  • 22. Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p / •  MR –  トラヒックの分類 ①  実⾏行行ジョブを監視するためのトラヒック –  ハートビート ②  実⾏行行ジョブのシャッフルフェーズでのデータ転送 ⇒  トラヒックの⼤大半は②が占める 4.5.1.2  ネットワーク設計 22
  • 23. Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p / •  1Gbネットワーク  vs  10Gbネットワーク –  コストメリットで判断すべき –  利利⽤用形態で選択するのもアリ •  ETL(Extract/Transform/Load)的な利利⽤用  ⇒  10Gbが望ましい •  カウントや集計などの分析的な利利⽤用  ⇒  1Gbでも⼗十分かも –  HBaseで低レイテンシを期待するならば10Gbがベスト –  1Gbをボンディングするならば、10Gbを検討すべき •  ポート単価が同じくらいになる 4.5.2  ネットワーク設計 23
  • 24. Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p / •  ツリー型トポロジ –  576台のホストを接続できる構成(12  x  48) 48Gb  >  4  x  10Gb  ⇒  オーバーサブスクリプション(⽐比=1.2:1) ネットワーク設計 24 4 48
  • 25. Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p / •  ツリー型トポロジ –  1152台のホストを接続できる構成(24  x  48) –  1.2:1のオーバーサブスクリプション⽐比が維持できない 4.5.3.1  ネットワーク設計 25 3 48 12
  • 26. Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p / •  ツリー型トポロジの注意点 –  クラスタへのデータ⼊入出⼒力力はトポロジのルート近くで実施 すべき •  ETL、プロセスオーケストレーション、データベースなど –  低レイテンシのサービスは、ディストリビューションス イッチ配下にはおいてはいけない •  ⼤大量量のデータトラヒックがネットワーク遅延を引き起こす 4.5.3.1  ネットワーク設計 26
  • 27. Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p / •  スパイン(背⾻骨)ファブリック型トポロジ –  どのホストも可能な限り等距離離になるメッシュ型に近い –  1.2:1のオーバーサブスクリプション⽐比を維持できる ネットワーク設計 27 L3ルーティングネットワーク 2 2 48
  • 28. Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p / •  スパインファブリック型トポロジ –  1.2:1のオーバーサブスクリプション⽐比を維持しつつ、 2304台のホストを接続できる 4.5.3.2ネットワーク設計 28 48 10GbE 10GbE 10GbE 10GbE (48) (2304) L3ルーティングネットワーク 1 1 1 1
  • 29. Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p / •  ツリー型トポロジ –  ホストの台数が少ないと、オーバーサブスクリプション⽐比 を低く抑えることができる –  逆に、台数が増えると、層の追加が必要となり、オーバー サブスクリプション⽐比が劣劣化する •  スパインファブリック型トポロジ –  ホストの台数が増えても、オーバーサブスクリプション⽐比 が劣劣化することなく、スケールアウトできる –  通信経路路が1つではないため、static  routingが利利⽤用できず、 L3レベルのルーティングプロトコルを動作させる必要あり 4.5  ネットワーク構成 29
  • 30. Copyright © CELL▲NT Corp. All right Reserved. h t t p : / / w w w . x d a t a . j p / ※1:  http://archive.cloudera.com/cdh5/cdh/5/ ※2:  http://qiita.com/moris/items/0a23bf26abc4289bb258 ※3:  http://wiki.openwrt.org/doc/howto/storage ※4:  http://ja.wikipedia.org/wiki/XFS ※5:  http://shiumachi.hatenablog.com/entry/20080614/1213415948 参考情報 30