#garagekidztweetz

#garagekidztweetz

id:garage-kid@76whizkidz のライフログ・ブログ!

Hadoopソースコードリーディング 第11回のメモを共有しよう #hadoopreading

スポンサーリンク

今日は第11回目となる Hadoop Source Code Reading に参加してきたので、わたしのメモを共有したいと思います。

日 時: 2012年7月30日(月) 19:00〜21:00 (受付開始 18:40)
場 所: 豊洲センタービルアネックス(NTTデータ、豊洲駅直通)
地 図: http://www.nttdata.com/jp/ja/corporate/profile/guide/map.html
定 員: 80名
参加費: 1000円 (懇親会費用として)

今日の発表は以下の 3 つでした。
(どれも聞き甲斐がある内容でした)

Contents.

  1. BigTopに関するお話 (Cloudera, Inc Andrew Bayer氏)
  2. CDH4に入った新機能 NameNode HA の実力を試してみました (NTTデータ 山下 真一 氏)
  3. 複数DCで運用するHadoop/Hiveデータ解析 (GMOインターネット 新里 祐教 @hirotakaster 氏)

では以降が、わたしのとってきたメモになります。

1. BigTopに関するお話 (Cloudera, Inc Andrew Bayer氏)

  • Apache Bigtop (incubating)
  • Packaging and testing the Hadoop ecosystem
▶ QA team Engineer
  • so called Kitchen Team.
  • to attend Jenkins Conference come to Japan.
▶ Introduction
  • Cloudera Kitchen team
  • Committer Bigtop, Flume,...
▶ WHat is Bigtop
▶ WHat is Bigtop for a casual user
  • fully integrated pagaged and validated sgtack of Hadoop
▶ What is BIgtop for the ASF
  • First focused on the system level integration
▶ what for Linux Distro?
  • source for packaging
▶ what for Hadoop Distro?
  • without start from scratch
▶ Bigtop history
  • Based on Cloudera's CDH
▶ Bigtop Contents: source
  • build and packaging code for all components
▶ Bigtop contents: test
  • installation/removal
  • package contents
  • functional test
  • unit tests
▶ Bitop contents: binaries
  • also have.
▶ Bigtop 0.3.0 components
  • Hadoop 1.0.1
  • ZK 3.4.3
  • HBase 0.92.0
  • Oozie 3.1.3 ...
▶ Bigtop 0.3.0 Platforms
  • Fedora
  • Ubuntu ...
▶ Bigtop 0.4.0 conponent
  • Hadoop 2.0.0
  • ZK 3.4.3
  • HBase 0-.94.0
  • Oozie 3.2.0 ...
▶ 0.4.0 Platforms
  • Fedora 16, 17
  • Ubuntu ....
▶ Changes in 0.4.0
  • New components
  • Hue, Giraph ...
▶ Bigtop Source
  • bigtop-packages
  • bigtop-deploy ...
▶ bigtop-packages
  • the source code for bigtop packaging
    • common
    • dev, rpm
▶ bigtop-deploy
  • deployment tools for the bigtop packages
    • livecd
      • kick starter script
    • puppet
      • puppet modules for bigtop
    • vm
      • vm image
▶bigtop-test-framework
  • a.k.a. iTest, the bigtop package testing framework
    • written in Groovy, uses Maven for builds and test execution
    • provide junit extensions
    • package manager/repository helpers ...
▶ bigtop-tests
  • The actual package/integration tests
  • test-artifacts
    • for various components and general package tests
    • package
    • test-execution
      • where the tests are run from
      • consumes the artifacts from test-artifacts as Maven dependencies
▶ Installing Hadoop from Bigtop
  • Example for CentOS 5.x
  • Bigtop 0.4.0 RC1

#

  • sudo yum search hadoop
  • yum install hadoop
▶ Getting Involved
  • Test the RC
  • Add components (Giraph recently added by Trendmicro team)
  • Fix bugs
  • Write tests
▶ Links
  • Jenkins
  • Mailing List
  • Downloads
  • SVN
  • JIRA
▶ QA
  • iTest is not specific for Bigtop.
  • it is generic.
  • unit test is specific for Hadoop.

#

  • How did you choose the next components to add?
  • Choosing from volanteer's requests.
  • and from JIRA tickects.

#

  • Next release will support private cloud.

For the user (from now) want to start using Apache's Hadoop, Bigtop is convenience (why not CDH, though).
But for the user originally start from CDH, not much attractive.

Seeing from contributers of Hadoop ecosystem, maybe seem different.

If Cloudera Manager became OSS, and became one of the component of this, It would be wonderful, I think.

2. CDH4に入った新機能 NameNode HA の実力を試してみました (NTTデータ 山下 真一 氏)

  • CDH 4.0.0 base
▶ 自己紹介
  • 最近、思っている
  • すそのを広げることは大切だ
▶ おさらい:HDFSの可用性
  • DN、障害発生時にサービス継続できる仕組み
  • ブロックを分割、レプリカを保存
  • NNの通信により異常が発生した場合にはレプリカ再配置

  • NNのダウン
  • HDFSサービス停止

  • 連鎖的な後続処理が遅れてしまう
  • 分析の処理、即座に反映できない
▶ CDH3のとき
  • PacemakerとDRBDの組み合わせで回避していた
  • Facebookが提供するAvoterNode
▶ これまでの課題
  • 切り替わった段階でMR Jobは中断されてしまう
  • mapred.jobtracker.restart.recover で設定しても途中から再実行はされない?

  • クラスター起動やジョブの再起動など、あるべき姿に戻すための時間は必要
▶ NN HA (HDFS2.0)
  • CDH4
  • ZKFC がフェンシング
  • NFS の共有ディスクでEditsファイルを共有する
▶ NN異常時の切り替え
  • NNが故障
  • active側のZKFCが検知
  • 新しいNNを選ぶ
  • 旧ActNN疎通確認
  • フェンシング
  • NN Act系に切り替え
  • 新NN情報通知
▶ Active系のzkfcが壊れる場合
  • ZKFCのロック消失
  • 消失確認
  • 新NN決定
  • NN状態切り替え
  • ZK状態更新
▶ いくつかの故障を想定して動かしてみた
  • NFSは soft マウント
  • ZK3台
  • DN3台

  • 前提、多重故障は考慮しない
  • 待機系への切り替えできないケース
    • NFSサーバー故障→×
  • MRジョブ実行中の現用系故障→○(問題なし)
  • HDFS操作中の現用系故障→○(問題なし)
▶ NN HAのポイント
  • フェンシング方法
    • sshfence
      • 異常発生時にSSHで現用系サーバに接続
      • fuser -v -k -n tcp
  • shellfencing
    • 各自で用意したシェルスクリプトで現用系を停止

  • フェンシングを実行するときには、sshfence + shellfence の組み合わせが大切
  • どちらかだけでいいというわけではない

**

  • NFSサーバについて
  • マウント設定→ソフトマウントでマウントすること
  • ハードマウントではNIC異常時の場合に応答不能になることあり

  • NFS自身の対策
  • 現状のじっそうでは NFSがSPOFになってしまう
  • 複数のNFSのマウント先に記述するような実装が必要になる
    • →現状はできない

**

  • フェデレーションとの関係
  • Namespace単位で、HA環境を実現することは可能
  • 設定のポイント
  • fs.defaultFS
  • dfs.nameservices
  • dfs.ha.namenodes.
  • dfs.namede.rpc-address..

**

  • Full GC発生時の考慮
  • タイムアウト設定は意識すること★
  • NN HAでは現用系、待機系ともにメタ情報、ブロック情報をヒープメモリでもっている
  • 待機系はプロセス起動状態で従来のSNNのようにedits をfsimage にマージする
  • 大量データ削除などにより、両系で同時に Full GCが発生する可能性があるかもしれない
  • Full GCから復活すればサービスを継続できる

**

  • NNメタ領域
  • 1.0 から少々変わっている
  • fsimage: 保存世代数を設定できるようになった
    • →dfs.namenode.num.checkpoints.retained, dfs.namenode.checkpoint.period
  • edits: 間隔が短くなった
    • →dfs.namenode.num.extra.edits.retained, dfs.ha.log.... (missed...)
▶ 雑感
  • MRジョブが継続できるという点は魅力的
  • 守るべきポイントがNFSに変わったというか増えた…
  • モニターする仕組みも足りない
    • →ZKFCの情報取得、チェックポイント動作時の状況確認
  • さらにプロセスが増えた
▶ まとめ
  • NN HAはNFSでもOKであれば利用できるかなぁ
  • 構成や設定は十分検証必要
  • HAという意味ではBookKeeperを待つべき
  • 持っっと別の技術を組み合わせるという手段
    • →FT (Fault Tolerance)
▶ QA
  • fencing について
  • ZKで状態を管理しているのがポイント
    • (聞こえないので、あとで誰かのTwitterなどで拾う)

  • チェックポイント間隔がデフォルト2分の理由?

  • FTとは?
    • Fault Torelance の仕組みのこと

3. 複数DCで運用するHadoop/Hiveデータ解析 (GMOインターネット 新里 祐教 @hirotakaster 氏)

▶ 自己紹介
  • Programmer
  • GMO internet
  • working for Cloud project for 2 years.
▶ Data Analytics System
  • for Social Game: mobage, gree, facebook, ....
  • DC -> at Japan, U.S.
▶ Analytics Specifications
  • DAU/PV, Play time, Sales, A/B testing, CVT
  • Hourly, Daily, Weekly, Monthly
  • from 2 years ago

#

  • demands for a realtime analytics.
▶ System Architecture
  • Cloud Side
    • Servers,
    • Logging servers,
    • Hadoop/Hive
    • Scheduler,
    • MySQL (for Hive)

#
latency become problem, not a bandwidth.

▶ Specificaions, Statistics
  • Multiple NN per DC
  • HW:
    • CPU 8 -16 CPU
    • MEM 12-64GB
    • HD: RAID 1/5/1+0
  • Transaction volumes
    • over 20TB/day
▶ Data Flow
  • Cloud server -> Logging Server
    • -> Hadoop/Hive <- Scheduler
    • <-> Management system <-> Scheduler

#

  • partition is useful.
▶ Conversion Count HQL
  • partition を決めてアクセスする
▶ Monitoring/Management (Zabbix)
  • Images.
  • NN のMemory使用状況の遍歴
▶ Memory Management
  • NN Memory
    • become sensitive for File, Block, Directory metadata usage
  • Hadoop Archive
  • Server Memory, 24GB of memory works fine. too much memory makes performance tremendously bad. kernel 2.6's default setting also - - - makes performance tremendously bad.

#

  • experienced vanishing 300TB of data before.
▶ Trouble
  • Realtime is not always become good practice.
    • Re-analytics
    • Backup and Recovery
    • NN HA
    • Hive vs. MR
      • Initially develop program only Hive, be careful not only depends on that.
▶ QA
  • Scheduler 独自
  • 完全独自
  • MySQL 使用、常にここのジョブを管理
  • 失敗したらリスケジュールして再実行
  • 並列度は150ほど
  • CPU 5-600

  • ユーザーから入ってくるデータ
  • タイムスタンプでパーティショニング
  • ??????

  • DC間をまたいだ処理はしていない
  • バックアップはしているけども
  • アメリカにあります、と
  • DCの間があまりにも離れていると latency が半端なくて遅すぎる
  • スケジューラがどこのDCで動いているかを管理
  • すべてを Hadoop にまかせることはしていない
  • タスクは自分たちで管理

  • Hadoop の規模
  • 一番大きいところが 400 CPU くらい
  • 300TBとばしてもリアルタイムの処理だったこと、解析した結果は他に管理していた
  • データは結果に意義がある(これはおっしゃるとおり)
  • 解析済みのデータはアーカイブ行き
  • それをHDFS上で管理する意味はない

こちらもあわせてどうぞ