壊れたgzipファイルの直し方
Flumeなどのアプリやgzipコマンドを使って、
ストリームで圧縮をかけていると、
ディスクが壊れたり、
プロセスが突然死して、
成果物なる圧縮ファイルが壊れることってよくありますよね。
しかもストリーム使っている場合は、
オリジナル(圧縮前)のファイルがあるわけではないので、
もう一度、というわけにはいきません。
壊れた、というのは、
具体的には、
解凍しようとしたときに以下のメッセージが出るようなときです。
gunzip: XXXX.gz: unexpected end of file
それらは、以下のコマンドで直すことができます。
gunzip < [壊れたgzファイル] > [修復後のファイル]
例) gunzip < kowareta.gz > naotta
→kowareta.gzの圧縮前のファイルがnaottaに保存されます。
参考:
>今回の直し方について、書いてある記事(本家)
http://www.gzip.org/recover.txt
>gzipのフォーマットについて日本語で知りたい方向け
http://www.glamenv-septzen.net/view/495#ida1dffd
>マニアックに知りたい方向け
http://www.futomi.com/lecture/japanese/rfc1952.html
Hiveで半構造化ログをそのまま読み込んでしまえ!
Hiveを勉強したら、思った以上によかったので
いいと思ったことを紹介。
①正規表現で半構造化ログファイルを読める!
Hiveのテーブルを以下のように作ると、
ログファイルをそのまま読むことができます!
https://issues.apache.org/jira/browse/HIVE-662
input.regexにログ1行のログのフォーマットを正規表現で指定します。
output.format.stringでHiveが読むときのフォーマットを
JavaのFormatterクラスの変換形式に従って指定します。
#http://java.sun.com/javase/ja/6/docs/ja/api/java/util/Formatter.html
簡単に言えば、
input.regexの正規表現で「()」書きした箇所が、先頭から順に
output.format.stringの%1$s、%2$s、%3$s…
となっていくイメージです。
※文字列ならば。数字が入ると「s」が「d」や「f」になります。
リンク見て、お分かりの通り、
転送してきたログファイルをいちいち加工(パース)することなく、
HiveにLOADしてあげるだけで、検索できるようになっちゃんです!
BigDataと呼ばれるほど、大きなデータになればなるほど、
効力が出てくるんじゃないでしょうか。
②圧縮ファイルをそのまま読める!
Hiveは圧縮ファイルを解凍せずとも、ファイルを読めます。
http://metasearch.sourceforge.jp/wiki/index.php?Hive%A4%C8%B0%B5%BD%CC%A5%C7%A1%BC%A5%BF
できる圧縮形式はGZip,LZO,BZip2,
あと、上記リンクには紹介されていないですが、Snappyもできます。
※(英語)http://mapredit.blogspot.com/2012/01/use-snappy-codec-with-hive.html
あ、もちろんSequenceFileもOK。
てっきりplainじゃないと読めないと思ってました。
よくよく考えてみれば、
Hiveの検索は結局MapReduceですから、
MapReduceでできていることはHiveでもできて当然なんですけどね。。
③パーティションを事前に作れば、LOAD不要
なぜかは知りません。
やったらできたレベルです。
もう少しHiveのメタデータについて、勉強しないと仕組みはわかりません。
けど、これで、
転送されてきた圧縮ファイルをHDFSの特定のディレクトリに配置するだけでよいので
転送されたその時から、即検索できちゃう!!
リアルタイムにデータ転送をするストリーム転送と相性よさそうですね。
Fluentd meetup in Japanに参加してきました。
今日は
Fluentd meetup in Japan
>http://www.zusaar.com/event/193104
に参加してきました。
そのメモを少し書き換えて、感想を書かせていただきます。
※かなり雑ですみません。
※あと私のフィルタがかかってしまい、メモし切れていない箇所が多分にあります。
ご容赦ください。。。
======================================================
「What's Fluentd? - The missing log collector」
http://www.slideshare.net/treasure-data/fluentd-meetup-in-japan-11410514
Treasure Data, Inc.
古橋 貞之 (@frsyuki)
======================================================
●fluentdとは…
一言で言うとsyslogd not TEXT but JSON
●特徴(売り)として、
・1イベントはtime & tag & recordで構成される
・入力、出力をpluginで開発可能
・ClientLibrariesを多く提供
Ruby、Perl、PHP、Python、Java... etc
・fluentdでリアルタイムにログ収集ができる!
→ストレージに突っ込んで解析可能。
●設定ファイルについて、
sourceとmatchで構成されます。
○source
役割は入力:typeで指定します。
例)
http:httpでデータ受信
tail:ファイルのtail
○match
役割は出力:タグでマッチング、該当データを指定先に出力します。
●ほかのログ収集アーキテクトとの比較
vs scribe
・ログのパースが必要
・インストールが面倒
・C++で書かれているので、pluginが作りにくい
・gemでインストールできるので、インストール/plugin拡張可能
vs Flume
・JVMはメモリ食うので、FrontEndに突っ込む怖さがある。
●構成
input,Buffer,Outputからなります。
Bufferは書き出せないときchunkとして保存します。
例)
out_forward
・ほかのfluendに転送する
・転送先とheardbeat通信
・2:3など負荷の振り分けできる。
buf_file
・出力先が死んでしまっても、ファイルに書き出し、
データを保存
・その後再送(2のべき乗後に)
in_tail
・ApacheParserでログを構造化できる。
●TestDriverあります。
・pluginの試験可能が容易です。
●性能
・秒間数万イベント裁けます。
●その他(Q&A)
chunkのあるサイズになったら次に移ります。
かつ順序は保存されます。
再送はパフォーマンス優先で順序保障しないです。
Flumeとの比較において、Flumeは大規模分散環境に有利ではないかとのこと。
クラスタ上での監視はfluentdではなく、別に仕組みを用意する必要があります。
フェイルオーバは今のところなし
buffer(デフォルト256MB,キューサイズ制限なり)あふれた場合、
ログはセカンダリに送られる、それでもダメならログは失われます。
直接話を伺わせていただきましたが、
古橋さん自身、fluentdは
・messagepackを有効活用し、効率よくログ収集を行う
・多種多様なニーズに合わせ、pluginを作成できる
ことを念頭に置き、開発されたそうです。
ログが失われることに関して、反応してしまったのですが、
しばらく(6時間)転送できなくても、後に再送してくれるし、
セカンダリという設定もありで、
容易なpluginでの拡張や運用でカバーするのがよさそうですね。
======================================================
「Dive into Fluent Plugin」
http://www.slideshare.net/repeatedly/fluentd-meetup-dive-into-fluent-plugin
Preferred Infrastructure, Inc.
Masahiro Nakagawa (@repeatedly)
======================================================
検索エンジン会社にお勤めだそうです。
●Fluentdのフレキシブルなplugin機能
pluginの名前は「fluentd-plugin-xxx」
インストールは fluent-gem install xxx
●Cool.io、messagePackを使用している。
●rubyはシングルスレッド、シングルプロセスだが、
Mixin によりプロセスで起動してinput,outputなどがそれぞれ動いてくれる
→パフォーマンス対策です。
inputはとくにeventloopもしくはスレッド分割が必要
Time.nowは使えないので、Engine.nowを使用する
●Bufferは作るのが難しいが、memoryとFileで事足りる
●outputは多く作られている。
formatメソッドとwirteメソッドをoverride
formatでシリアライズ→buffer→wirteでデシリアライズ、出力
mapにchunkがあるので、時刻指定すれば、その時刻のchunkにinsert
●その他(Q&A)
複数行のログを1eventとして扱う場合はin_tailを拡張?
→tailをoverrideしてparserLineを実装する。複数行のparserは難しいけどね。
railsの中のログを集めてというplugin をTD社の中では既に作っています。
======================================================
「fluent を使った大規模ウェブサービスのロギング」
http://www.slideshare.net/hotchpotch/20120204fluent-logging
COOKPAD, Inc.
舘野 祐一 (id:secondlife, @hotchpotch)
======================================================
CookPadの開発基盤部だそうです。
●PVログは超巨大
→一日分はMySQLをオンメモリで高速に処理
ところがそれ以上はオンメモリ使えず遅い
blackholeエンジンで保存速度は速いけど、遅いときもある。
ほかのログはJSONでシリアライズor createtable
→insertコストがかかるし、手軽に取れない
●だからfluentd
構造化ログができてない時代だと、様々なところに気を使う。
たとえば新しい集計をしたくなったら、サービスを落とさない・サービスに影響の少ない時間帯のメンテが必要になる。
あるいはメンテコスト・開発コストが必要になるので「そもそもやらなくなる」
●パフォーマンス
ローカルにfluentd,定期的に転送
本体は安定している。エラーはプラグインで発生する
再送があり、6時間とめてもちゃんとmongodbに保存された。
●管理
Centosなのでrpmインストール
td-agentにはruby1.9.2入り
puppetで構成管理
リトライ2の16乗=1日ぐらい失敗し続けてからはつらい。retry_limitは覚えておこう。
中央の転送用サーバ
・RVM(Ruby1.9.2)
・gitで設定ファイル管理
・Gemfile
バッファをすぐに処理する方法あり
かつシグナル送って設定再読み込みできる。
●はまり
設定でルーティングミスってもエラーにならない(反映後の再起動漏れ)
●要望
設定ファイルの柔軟化
・正規表現、フィルタなどでpluginを管理したい
・変数使いたい
●まとめ:ログはこれから重要になる
・ログをとるのがfluentdで簡単になる
・きちんと統計を考えられるエンジニアとなる
→巨大データ処理ができるので、
どのデータに何の価値があるのか、それを仕事に結び付けられるか?
●その他(Q&A)
限界性能は
→1台集約して40Mbps裁けた
もうここまでやっていたんですね。はやいなぁ。
アプリケーションのログを収集してきた人たちが
fluetndを使って、こうやって置き換えていくのかなと感じました。
fluentdの運用に関しても、
集中制御する機構をもたなくても、
puppetなどのほかのツールでカバーしています。
また、fluentdがもつ構造化ログを扱う強みがすごく生きてますね。
JSONで統一されるので、その後の取り回しがやりやすそう。
======================================================
「fluentをサービスで使ってみた」
http://www.slideshare.net/naverjapan/20120204fluent-public
NHN Japan株式会社
Tetsuya Ohira (@just_do_neet)
======================================================
●fluentdを使った理由
解析処理より転送・コピー処理でこける
ファイル数が多い
既存システムに影響与えたくない
もっと安心できr氏間に実施したい
定期的に細かい単位で処理したい
●社内向けログ解析
access_logを使用してデータを収集する
ブログ参照
旧来の解析システムを置き換え
fluentdが直接投入せず、HDFSには定期的にアップロードする
●効果
fluentdによりログコピー処理の高速化
MapReduceで処理するときにはHDFS上にログがある!
●耐障害性
App上の生access_logを使って復旧
復旧時は途中まで書いたログは破棄して、再転送
書き込み失敗した場合はfluentd再書き込み
本体は安定、pluginでエラーになるが、自分で直せる安心さ。要ruby力
●使い勝手
JSONで統一できているので、fluentd+mongoDB+node.jsがイケてる
●相談ポイント
・動的に設定ファイルの内容を変更したい
例)ログファイル名に日付が入っている
・必要な情報だけ送信したい
・fluentdのメトリクス情報がほしい
======================================================
「Distributed message stream processing on fluentd」
http://www.slideshare.net/tagomoris/distributed-stream-processing-on-fluentd-fluentd
NHN Japan株式会社 ウェブサービス本部
Tagomori Satoshi (@tagomoris)
======================================================
●用途
Hiveへデータを収集→集計
会社的にJavaでのビルド、デプロイは避けたい
→rubyがいい
TimeslicedOutput
時間単位でログを扱ってくれるのはうれしい
●性能
127台146のログストリーム
毎秒7万メッセージ 120Mbps
89インスタンス(12台fluentd専用node)
タブ区切りでログ出力→あとあとの読み込みで楽になる
ログローテートに頼ると1,2秒ずれる(誤差10万行!)
→ログ内容見てローテート
●fluentd導入効果
いままでは
・生ログのままHDFSに書き込み
→コンバートして別のHDFS上のパスに保存
→aggregate(ログの解析)
結果ログ収集は2,3時間遅延する
今は
・fluentdでストリーム処理
→来た順番に変換していく
結果HDFSにかけた時点ですぐにHiveに登録できるので、
集計が早くなった
●耐障害性
いつでもバッチを再実行できるようにしたい
バッチ処理とストリーム処理は同一コードだから、再実行できる
具体的には、
out_exec_filter
fluentd→標準入力→外部プログラム処理→標準出力→fluentd
●構成
・deliver(二重化:hotstanby)送り先を考えてくれる
コンバートするworkerのロードバランスする
・worker
ログをコンバートする。(タブ区切り)
・serializer
workerからのデータを受け取り、HDFSにデータを書き込む
同じパス(ディレクトリ)に書き込む人を少なくするため、
バッファリングしてくれる
・watcher
監視のために用意
deliverとserializerからデータを受け取る
deliverの場合 :生ログから解析
serializerの場合 :コンバートされたデータから解析
●fluentdを使う理由
scribeはログを転送するだけには重い
scribeで使えるプログラムがあるから
●サーバ内部の動き
・deliverサーバ内部
roundrobin
56のあて先(7台×8worker)に順序送れる箇所へ送信
・workerサーバ内部
8つのworkerと1つのserializer
ここでout_exec_filterが発動
→整形してfluentdのpluginにデータを渡してくれる
●各サーバの性能
・deliver性能
deliver2台あわせて120Mbps
動画配信のログは頭打ちになる
→agentが待たされた
CPUはscribeが重たいから?
・worker性能
30台
入力120Mbps
出力の性能がギザギザのグラフとなったのはHoopの性能
CPUは40%程度
out_foward でのラウンドロビンだとバッファやフラッシュ時間設定に依存するので粒度が大きすぎるが、
roundrobin 経由で out_foward するとメッセージ単位でのラウンドロビンが出来る
今日の勉強会で一番気になっていたセッションでした。
Hiveへ突っ込む前の中間処理をストリームで流しながら、fluentdでやらせている点、
先進的に感じました。
かつ性能もかなり詳細に数字を出していただけたので、
いろんな人がfluentdでのリアルタイム処理の夢を描いたと思いました。
やりたいですよね。
【LT】
======================================================
* @shun0102: 「fluent-plugin-dstatを使ったリアルタイムクラスタモニタリング」
http://www.slideshare.net/shun0102/fluent-plugindstat
======================================================
dstat
vmstatやnetstatの内容を1つのコマンドで実行できる
fluent-plugin-dstat
dstatの内容をparse→性能データを転送できるようにする
これらを使い、
mongoDBにデータを集約、node.jsで結果を表示する
======================================================
* @chobi_e: 「Fluentd & PHP」
http://www.slideshare.net/shuheitanuma/fluentd-and-php
======================================================
FluentLoggerの紹介
fluent-plugin-delayed
未来の日付のデータを時間差おいて出力する
======================================================
* @railute:「Fluent Output Plugin for Cassandra」
https://skydrive.live.com/view.aspx?cid=D105615A0F594518&resid=D105615A0F594518%21333
======================================================
書き込みが早いCassandra
データ設計が大事なCassandra
ゆえに
動的Columnマッピングができるようにしたいなぁ
======================================================
* @choplin: 「Write Parser with fun!」
http://www.slideshare.net/choplin/write-parse-with-fun-11414130
======================================================
fluentdなどの新しいOSS導入には、
・非構造
・会社ポリシー
の障害がある。
お勧めしたいポイント:parsar書いてはどうか?
Tail inputを拡張すれば簡単にできる→障壁クリア
parseLineをoverrideすればOK
======================================================
* @ixixi: 「fluent-plugin-couch」
http://www.slideshare.net/ixixi/fluent-plugins-for-couchdbamazon-sqssns
======================================================
・fluent-plugin-couchdb
CouchDBはHTTP&JSONを持つので相性がよい
バルクインポートできるので、内部で使用した。
今後はサーバの状態遷移を収集できるかな
・fluent-plugin-sqs
送信側と受信側を疎結合にしたい
→queueが必要
→そこでAmazonSQS
バルクインサートあるので、内部で使用した
かつこの方が安上がり
今後はinput_pluginかな
・fluent-plugin-sns
マルチプロトコル(e-mail(JSON),http(s),SMS,SQS)
で通知可能
配信者がfluentdを使用する
→SNSが適切なプロトコルで通知を行う
※配信者が通知先を管理しない
フォーマットの指定、複数指定をやりたい
======================================================
●出版の紹介
======================================================
niftyクラウドに関する本で
fluentdをTipsで紹介します
dailyでログ収集する記事
2/22出版予定
Openクラスドで100冊用意するそうです。
======================================================
●fluentdのAnalizeからみた視点
======================================================
@doryokujinさんから総纏めのLTです。
1.EventCollection
2.DataStorage
3.DataFiltering、Aggrecation
------------------------ ↑Hadoopでもてはやされた部分
↓まだまだ
4.DataMining/Visualization
上記すべてを1つのサービスと考えれば、
EventCollection(fluentd)は重要
課題点
・ユーザごとのアクセスログ取得・最適化
・短い単位(毎時・毎分)での解析
・データの構造化→収集する時点で戦略が必要になる
fluentdならば、、、
Web3.0で必要とされるログの構造化(JSON)が行える
リアルタイムに収集できる
必要なものをすべて収集する
======================================================
======================================================最後に、
今日の勉強会に参加できて本当によかったと思いました。
正直、ログ収集だけでこんなに濃密な内容になるとは思いませんでした。
耐障害性や性能、運用まで
実績を積みつつあるんでしょうね。
かつ黄金のパターン
fluentd + mongoDB + node.js
ができちゃってますね。
相性がいいのはわかっていましたが、ここまで普及しているとは。。。
さらにplugin作成の魅力が多くの人に伝わったと思いした。
これから先、さまざまなプロトコルに対応したpluginが作られ、
その点で、ほかのログ収集アーキテクト(Flume,scribeなど)を圧倒すると思います。
「目指せ、ApacheCamel並みのインターフェース」でしょうか。
本当に最後になりましたが、
講師、運営の皆さんありがとうございました。
[FlumeNG]FlumeNGを動かしてみる
昨日の続き。
mvnコマンドで作成された、
flume-ng-dist-1.1.0-incubating-SNAPSHOT-dist.tar.gz
をLinux環境で展開し、
できたディレクトリに移動します。
このディレクトリが基本的にFlumeNGを動かすHomeディレクトリになるので、
覚えておいてください。
先に起動方法について説明してしまいます。
以下のコマンドが基本形です。
./bin/flume-ng <node | avro-client> --conf <設定ディレクトリ> [-d 一時ディレクトリ] <オプション>
起動には以下2つのモードがあります。
①Flume nodeを起動する
これはイメージとしては、
転送されてきたログを受信する役割を持ちます。
オプションとして、以下を指定する必要があります。
-f <ファイル名> ⇒ 設定定義ファイルを指定する。
この後紹介するプロパティファイルを指定します。
-n <ホスト名> ⇒ FlumeNGが起動するホスト名を指定する。
指定したホスト名で名前解決できなければいけません。
実行時のコマンドはこんな感じ。
./bin/flume-ng node --conf ./conf -f ./conf/flume.properties -n centos57
②Flume Avro-Clientを起動する。
これはイメージとしては、
APLからログを取得し、ログを転送する役割を持ちます。
オプションとして、以下を指定する必要があります。
-H <ホスト名> ⇒ ログ転送を待ち受けているFlumeNGが起動しているホストを指定します。
-p <ポート番号> ⇒ ログ転送を待ち受けているFlumeNGがbindしているポートを指定します。
-F <ファイル名> ⇒(任意)転送するログデータが書き込まれたファイル名。
指定したファイルを1行ずつ転送します。
指定がない場合は、標準入力に与えられたデータを転送します。
実行時のコマンドはこんな感じ。
./bin/flume-ng avro-client --conf ./conf -H centos57 -p 41414 -F /etc/hosts
ちなみに、
./bin/flume-ng help
で実行コマンドのヘルプが出るのですが、
明らかにドキュメントと食い違っています。
このhelp通りにすると動かないので、ドキュメントを信じてください。(笑)
※どこかで書きましたが、
FlumeNGはまだ正式なリリースではなく、
アルファ版的な位置づけです。実装中です。
②avro-clientはそのまま動かせばよいとして、
①nodeのほうは設定ファイル(ここではflume.properties)を記述する必要があります。
では、設定ファイルの記述ルールについて、説明します。
設定では当然、いろんな機能を指定できるのですが、
動かすことが今日のゴールなので、
ドキュメントどおりの設定に対し、必要最小限の変更を行って動かします。
※時間があれば各機能について説明がかければと思っています。
待てない方はドキュメントに書いてあるとおり、
JavaDocを読んでください。
まず、Source/Channel/Sinkの名前を決めます。
<ホスト名>.sources = <Source名(任意)>
<ホスト名>.channels = <Channel名(任意)>
<ホスト名>.sinks = <Sink名(任意)>
次に、Sourceの設定を行います。
<ホスト名>.sources.<Source名>.type = <Sourceタイプ>
<ホスト名>.sources.<Source名>.<Sourceタイプのオプション> = <Sourceのオプション設定>
...
Source同様に、ChannelやSinkも設定します。
ドキュメントでは、
ホスト名 ⇒ host1
Source名 ⇒ avro-source1
...
としているので、
環境に依存するホスト名を今回のホスト名centos57に修正して、以下のとおりになります。
centos57.sources = avro-source1
centos57.channels = ch1
centos57.sinks = log-sink1
centos57.sources.avro-source1.type = avro
centos57.sources.avro-source1.bind = 0.0.0.0
centos57.sources.avro-source1.port = 41414
centos57.sources.avro-source1.channels = ch1
centos57.channels.ch1.type = memory
centos57.sinks.log-sink1.type = logger
centos57.sinks.log-sink1.channel = ch1
これにより、以下の挙動となります。
Source:centos57(任意のIPアドレス)の41414ポートでListen
↓
Channel:受信したログをメモリ上に蓄積
↓
Sink:メモリ上のログをロガー設定に従い出力
(デフォルトでは、標準出力に転送されたイベントそのまま出力となります。)
これで前述の起動コマンドでそれぞれ動かしてあげれば、
コンソール上に転送されたログを見ることができます!
※bodyの部分が文字化け(?)していて何かいてあるかわからないです。。。。
おそらくString型ではなくByte型そのままではないかと思います。
停止は気合(Ctrl + c)でエラー出しながらとめてください。
以上です。
参考になれば。
逆に間違えている箇所があればコメントいただけると幸いです。
[FlumeNG]FlumeNGを使ってみよう
あまりにFlumeNGに関する情報がネット上にないので、
私がいろいろ動かして見知った情報を書いてみます。
といっても、
今日は眠いので、動かす直前(セットアップ)だけ。
まず、そもそもFlumeNGがなんなのかわからない方は
以前HadoopAdventCalendarでFlumeNGについて書いているので、
読むとほんの少しわかるかもしれません。
http://d.hatena.ne.jp/t_otoda/20111221/1324486507
そして、FlumeNGの動かし方に関するドキュメントは以下のURLにあります。
https://cwiki.apache.org/confluence/display/FLUME/Getting+Started
基本的には、上記のリンクの内容どおりに進めていきます。
が、ドキュメントの情報は、これぐらいしか知らず、
しかも好き勝手動かすには情報不足なので、別の日に追記します。
①では、FlumeNGをダウンロードしましょう。
ダウンロードしたいDirで以下のコマンドを実行してください。
$ svn checkout https://svn.apache.org/repos/asf/incubator/flume/branches/flume-728/
svnコマンドなんかないよ!と怒られてしまう人は、
svnコマンドが使えるようになるツール(以下はCollabnet)をインストールしてください。
http://www.collab.net/downloads/subversion/
また、初めて上記のコマンドを実行すると、
信頼してダウンロードしてもいいですか、といった内容(だったと思う)のメッセージが出てきます。
pで答えて、よいと思います。
私はわからないのですが、
gitを使える人は上記svnコマンドの代わりに、以下のコマンドを実行してもダウンロードできます。
$ git clone git://git.apache.org/flume.git
$ git checkout flume-728
※読み込み専用で、変更できないそうです。
ダウンロードするとカレントディレクトリに「flume-728」というDirができます。
②では次にFlumeNGをビルドします。
flume-728のDirに移動してもらい、以下のコマンドを実行してください。
$ mvn package -DskipTests
実行後、
flume-ng-dist\target\flume-ng-dist-1.1.0-incubating-SNAPSHOT-dist.tar.gz
が生成されればOKです。
これでFlumeNGの媒体ができました!!
これを自分のLinux環境に持っていき、展開すれば
FlumeNGの実行環境ができます。
ちなみに、ビルドについて
ドキュメントには
$mvn package
の実行が書いてありますが、使えません!
テストが通りません!(笑)
今日はここまでです。
次は実際にFlumeNGに設定を行い、
動かすところまでやります。
ではでは。
[Hadoop][HDFS]HDFSはファイルディスクリプタをどのくらい使うのか?
HDFSはよくファイルハンドル数の上限値(ulimit -n)を上げるよう、言われている。
さもないと、IOException : too many open filesが発生してしまう。
じゃあ、
HDFSが使用するファイルハンドル数はいくつが適性なの?
プロセスが使用しているファイルディスクリプタの数え方は以下の通り。
ls -1 /proc/[pid]/fd | wc -l
/proc/[pid]/fdにはシンボリックリンクで各オープンしているファイルへのリンクが張られているようだ。
つまりこの/proc/[pid]/fd配下のファイル数を数えれば、
すなわちファイルディスクリプタの数となるわけです。
で、HDFSの中身をあらかじめ空っぽにした状態で、ファイル追加/参照/削除をやってみた。
構成は
CDH3u2
擬似分散モード
計測対象はNameNode、DataNode
まず、起動直後は
NameNode:73
DataNode:72
の状態でした。
内容は/usr/lib/hadoop/libのjarファイルか/var/log/hadoopのログファイル、socketがほとんどでした。
一部pipeや/dev/randomとかありましたが、何でしょうね。
で、おなじみ
hadoop fs -put [srcファイルパス] [dstファイルパス]
で6バイトのファイルを置いてみたのですが、3ぐらいNameNodeで増えてすぐ元に戻った。
レプリカ3だったので、
ブロック(デフォルトのまま64MB)3つ分のファイルディスクリプタを作ってクローズしたのだろうな。
その後10kぐらいのファイルも置いてみたのですが、同じく3ぐらいしか増えませんでした。
参照(cat)したらfdは一瞬DataNodeのほうで1増えて元に戻った。
削除(rmr)もputと同様、3増えて元に戻った。
結論、以下のことが予想できる。
1.HDFSがファイル生成/削除で使用するファイルディスクリプタ数はレプリカの数だけ倍になる。
例)レプリカ3、HDFS上1ファイル → ファイルディスクリプタ数は3使用する。
2.HDFSのファイルサイズをブロックサイズで割った数だけ、ファイルディスクリプタ数は増える。
例)HDFS上200MBファイルを扱う → ファイルディスクリプタ数は200/64 = 3.12... ≒ 4使用する。
レプリカ3、HDFS上200MBファイルを削除する →ファイルディスクリプタ数は 200/64 × 3 ≒ 12使用する。
今回1台のマシンの中で擬似分散で動かしたけど、
きっと他のマシンとやり取りすることになっても、
自分が持っていないブロックの数だけ、socketが開くから、同じ結果になるでしょう。(※予想)
あとやり方が雑すぎて、
検証足りず、結論急ぎすぎだとは思うけど、大体予想できたので、
私的にもういいかな。知的好奇心は満たした。
[Hadoop][HBase][Cloudera]HBase 0.92 がリリースされました
Apache HBase 0.92.0がついにリリースされました。
http://www.cloudera.com/blog/2012/01/apache-hbase-0-92-0-has-been-released/
最近あまりHBaseは触っていなかったのですが、
紹介だけでも。
HBaseなにが変わったか、ざっくりといいますと、
性能(performance)と頑健性(robustness)とロゴ(logo)
性能では、主に以下のような修正があります。
・HFile v2が導入された
・サーバダウン時のHLog(コミットログみたいなもの:WAL)の分割の分散化
・テーブル作成やバルクロード、コンパクションなどのマルチスレッド・非同期化
私的には特に、コンパクションが早くなっているのが気になりますね。
コンパクションはMemStoreのフラッシュのたびに増えるStoreFileの集約・効率化のために欠かせないのですが、
コンパクションを行っている間は書き込みがブロックされてしまうため、
処理性能の劣化や予期しないタイミングでの実行による不安定化を招きます。
※JavaのGCやPostgreSQLのバキュームのイメージです。
HBaseを商用運用したことがないので予想が、
どうコンパクションやその後のRegion分割をコントロール(回数減らす、手動で実行など)するか
が、ポイントだと思います。
それを後押ししてくれるのは、うれしい限りでして。
次に頑健性については、
・WebUIにより詳細なHBase内部の情報が見れるようになった
・遅い検索処理をロギングする機能を改善
・データの競合や修復用のコマンドhbckやメタデータテーブルをリビルドできるOfflineMetaRepairを改善
なんでも、遅いクエリをメトリクス(JSON)でロギングしてくれるそうで、
たまたまGCやフラッシュ、コンパクション、Region分割と処理が株って遅くなったのか、
そもそも検索条件がおかしいのか、
これで分かるようになるようです。
その他としては、
・開発者向け開発環境が改善
・ Hadoop1.0.0をベースにビルドを行い、0.22や0.23のベータ版とも試験をしていく。
・メモリのフラグメント化などが起きぬよう、手動でメモリ管理するoffheap slab cacheの実装
・テーブルの削除なしにスキーマ削除できる
あ、ロゴは以下の通り。
Clouderaの予定としては、
CDH4でHBase0.92.0をベースにするそうです。
HBase0.92の機能の一部はチケット対応などですでにCDH3に一部が含まれているとか。
今度個別にインストールしてみようかな。
ではでは。