2013年はまた象さんと戯れたいなって思っていて、
最近の状況をキャッチアップしに行って来ました。
＃午前中会社で仕事してから行ったので午後から。
■ NTTデータのHadoopの取り組み
元々PostgreSQLを元々やっていたOSSな部署があった。
PostgreSQLは2008年時点で100件を超える様々なPJでの導入実績あり。
組織的にはHadoopはじめてから毎年5人ずつくらい増えて今は30人くらい。
凄い話題になったNTTデータのHadoop報告書もこの人達。
割りとベーシックな話が多かったですが、
PostgreSQLとの使い分けのところとか興味深かったです。
■ Hadoopサポート担当者の方のお話
やんちゃな象さん。。
1. NameNodeでディスク障害。でもサービスは継続。
NameNodeはHDFSの構造とか操作状況を管理している。コレがイっちゃうとどうしようもない。
・HDFSをリードオンリーにして、メモリ上のデータから復旧したかった。
Safemode, Save Namespaceが動かなくてメモリからのダンプが出来ず…。
NameNodeということでNASにバックアップ取ってた。
・チェックポイントが長期間動作していなくて、HDFS操作ログ(edits)に不正データが…。
UTF8以外のファイル名が悪さして、チェックポイント時に読み込めず…。
→クラウデラ社と一緒にUTF8クラスを改修後、editsをfsimageにマージして解消。
2. DataNodeでレプリカの内容に不整合
3つのレプリカのうち1つが変。
ファイル名とブロックIDが一致。チェックサムが一致してて、
NameNode的には正しいと判断している。
原因はDataNodeで使ってたRAIDコントローラーの不具合だった。
1つのiノードに複数の～的な(よく分からなかったけど…)。
HadoopはDataNode間でレプリカの内容を検査する仕掛けがない
→レプリカのサイズやバージョン番号でという程度。
Hadoopだけ分かっていれば良いわけでなく、広い技術領域をカバーする必要がある。
3. CDH2->CDH3へのマイグレーションで特定のジョブだけ失敗する
CDH3から追加されたパラメータが原因だった。
JobTrackerのメモリ上のsplit管理ファイルサイズが上限超え。
ログとソースコードから頑張って2時間くらいで解決。
4. 日頃からちゃんと見張りましょう的な。
・小さいファイルをHDFS上に沢山置くと、、、
HiveとかPigとかで沢山のReduceタスクで生成されたファイルとかで、
いつまでも不要なゴミを残しておいたら、NameNodeを圧迫しちゃう。
→Web画面でもトレース出来るし、定期的にファイルの棚卸しが必要
・ファイル名やディレクトリ名が無駄に長いと、、
HTTP通信でNameNodeとSecondaryNameNodeの通信とハートビートがバッティングすると
アイタタタな事になっちゃったりするから気をつけましょう。
・Gangliaとかだけじゃなくて、いざとなったらpsとかiostatとかみようとか
話聞いてるだけでビリビリくるセッションでした。
こういう泥臭い運用現場で修羅場をくぐってきた人はカッコイイなぁと。
■ OK WaveさんのHBaseの話
バージョンは↓こんな感じ。HBase連携はThriftで。
CDH3 / HBase 0.90 / Hadoop 0.20 / Java7(理由あり)
・リージョン分割
リージョンが一定サイズこえると自動分割する。
分割中のリージョンはアクセス停止。10秒とか無応答。GCも併発すると、、
⇒自動分割はOFFの方向で。
・メジャーコンパクション
PostgreSQLのvacuumのようなもの。
物理ファイルが一定数を超えたリージョンを狙い撃ちでコンパクションという運用。
blockingWaitTimeを0秒に。
・GC
Promotion Failed, Cuncurrent Mode failureを伴うGCの時にガッツリ。
MinorやFullGCだけならシステム停止にならない。
400秒とかGCにかかると、ZooKeeperがクラスタから切りなはしちゃう。。
JavaVMのパラメータをイロイロやったけどダメだった。。
⇒G1GC(Garbage-FirstGC)採用。Java6だとイマイチだったのでJava7で。
・バックアップとコンパクション
メジャーコンパクションを無効にしてMapReduceのExport。
完了後にメジャーコンパクション。
・ファイルディスクリプタの設定
1TCP/IP接続で使うFDはsocket, epoll, read pipe, write pipeの4つ。
FD値の見積り注意。
チャレンジングな領域に挑む体当たり感がハンパないというか、
長期間の検証とか含めて凄い大変だったんだろうな～って。
自分の現場でHBaseを使う局面って直近ではあまり無さそうですが、
ハマりどころとか、とても参考になりました。
■ Clouderaのプロダクト群に関する話
ここのところ、全然ウォッチしてなかったので、どんな感じなのかな？と。
・CDH4
・Cloudera Manager
・Cloudera Impala
の紹介。
・CDH4
1000ノードとかでテストしてる。コミュニティではなかなかそこまで出来ない。
毎日、全コンポーネントの単体テスト。2万以上。
HDFSのHA、MapReduce2(YARN)、Restインタフェースの追加、HDFSフェデレーション、、
ほうほうって感じ。
YARNなら1万ノードまで対応可能(今までは4000ノードくらいが限界だった)
APIは下位互換性。MR1でもコンパイルすれば動く。
QuorumJournalManagerというedits用のデーモンはCDH4.1から。
ジャーナルノード。それぞれのデータノードのローカルディスクで。ほほぅ。
Hue。昔Cloudera Desktopって名前だったヤツ。Hiveクエリも実行出来る。
日本語対応Done。CDH4.2だとImpalaも実行出来るらしいです。
・ClouderaManager
運用構築も一手に引き受けてくれちゃう優れもの。
プロパティの設定は全部Web画面から出来るし説明も画面上に書いてある。
変な値入れたらワーニングメッセージとか。
ヒートマップ。どこに問題がありそうかビジュアル的に。
・Impala
Google DremelとかGoogle F1とかにインスパイアされて。
今のところデータサイエンティストがアレコレやってみることのお手伝いを想定。
来年の1QにはGAになる予定
■ HadoopとRabbitMQでTwitterの解析
BuzzFinderという分析サービス担当の人。
風評や炎上対策のために、口コミから異変を検知。
リッチインデクシング技術(NTT研究所)という日本語解析技術で以下の抽出。
・キーワード
・関連語
・ポジネガ
・地域
日本語の全データをTwitterのFirehose APIから。
システムは↓こんな感じの今風でイカした感じ。
興味深いところなので、もうちょっと実装よりの話がお聞きしたかったなーと思いました。
