Hadoop YARN覚え書き | OpenGroove
Hadoop YARNの仕様とか設計について過去記事に書いたことがあるんだけど、も一回まとめ、というか覚え書き。 YARNではスロット数を制御するプロパティがなくなった、とドキュメントや参考書にある。これはMRv1でのmapred.tasktracker.map.tasks.maximum ,mapred.tasktracker.reduce.tasks.maximum のことだろう。実際にはMRv2に対応するmapreduce.tasktracker.map.tasks.maximum ,mapreduce.tasktracker.reduce.tasks.maximumというプロパティが存在しているが書いても無視されるらしく、何故これらが残っているのか謎。ともあれYARNではスロットの概念が消滅した代わりにコンテナという概念が採用され、ジョブのプロセスはコンテナ内で実行される。コンテナ
MySQLのAUTOCOMMIT（オートコミット）覚え書き – OpenGroove
MySQLの機能のひとつ、AUTOCOMMIT（オートコミット）が有効／無効でどのように挙動が変わるのか、今イチ理解できていない。やっぱり、一回書いておかないと。 前提として、トランザクションセーフであるInnoDBテーブルが対象であること（MySAMはトランザクションをサポートしていない）。なお、この記事内における「暗黙のうちに、暗黙的」という表現は「自動的に」と同義語と 捉えるものとする。（・・・と勝手に決めます） AUTOCOMMIT（オートコミット）有効／無効の違い AUTOCOMMIT（オートコミット）を有効にするか無効にするかにより、トランザクションの開始／終了の方法が変化する。 オートコミットを有効にした場合（デフォルトで有効） この場合のトランザクションは単一のSQL文実行時に暗黙のうちに、またはSTART TRANSACTION文によって明示的に開始される。 この中でST
MySQLリレーログの仕様を学ぶ – OpenGroove
MySQLレプリケーションの実装にあたってはバイナリログの存在が不可欠。 そしてスレーブ側マシンにおいてはリレーログが不可欠である。 レプリケーションの処理におけるバイナリログとリレーログの相関について、 今一度まとめてみた。簡単に書くと以下のようになる。 マスタ側の更新系のクエリが、マスタのバイナリログに記録される。 ↓ ↓ ↓ スレーブのI/OスレッドがマスタのBinlog Dumpスレッドに接続し、 マスタのBinlog Dumpスレッドはバイナリログの内容を送信する。 ↓ ↓ ↓ スレーブのI/Oスレッドは、受け取ったマスタのバイナリログをリレーログに保存。 ↓ ↓ ↓ スレーブのSQLスレッドがリレーログからクエリを読み取って実行。 リレーログの挙動について今ひとつ理解していなかったのだが、オフィシャルサイト に以下のように書いてある。 リレーログはバイナリログと同じ形式なので、
ZooKeeperのsnapshotをClean upしたいのだが – OpenGroove
（注）前半は完全に無駄な迷走の記録です。結論は最後に書いてあるので、せっかちな人はもうそっちを読んでください。 HBaseと連携するZooKeeperのネタ。ZooKeeperのdataDirにはバイナリのログとスナップショットが保管されるが、ほったらかしにしていると、いつのまにかすごいことになる。古いファイルの削除等のメンテナンスは、ユーザー側で行う必要がある。 $ ls -lh /var/lib/zookeeper/version-2 -rw-r–r– 1 zookeeper zookeeper 65M Jan 15 00:08 log.1 -rw-r–r– 1 zookeeper zookeeper 65M Feb 17 10:51 log.13b -rw-r–r– 1 zookeeper zookeeper 65M Feb 17 15:29 log.19f : : -rw-r–r–
HiveでJSONデータの分析（の準備） – OpenGroove
fluentdでJSON形式のデータを溜め込んだらそれを分析してみたいよね…、ということでHiveでJSONデータを扱うには、という観点でうっすら調べてみた（分析までやっていないので「準備」です）。 実はその前に、fluentdのログをJSONではなくLTSVというフォーマットで出力するプラグインも試してみた。LTSVというのははてなが開発したフォーマットで、これでTSVファイルとして変換できれば当然Hiveでも扱いやすくなる。しかし、こっちの方がJSON parserを調べるよりてっとり早くていいかも、という目論みは通らなかった。2つほどプラグインを実装してみたが、fluentdの起動時にFAILEDになってしまい動作以前の問題。基本的な導入方法とか設定が間違っているのかもしれないが、何せ開発元のドキュメントも乏しい。ここで格闘するのも時間の無駄なのでこっちはパス。 で、Hive + J
SqoopでMySQL & Hadoop連携 – OpenGroove
RDB〜Hadoop間でデータのやり取りを行うSqoopをいじってみた。まぁ、押さえておくべきポイントかと思うので。実行環境はAWS m1.smallのHadoop疑似分散環境、CDH4.3。RDBは、Hiveのメタストア用に入れたMySQLを使う。 インストール # yum install sqoop jdbcドライバをsqoopのlibに配置する。 # cp /usr/share/java/mysql-connector-java-5.1.17.jar /usr/lib/sqoop/lib/ MySQLでテスト用DB、ユーザを作成。 mysql> create database sqoop; mysql> GRANT ALL PRIVILEGES ON sqoop.* TO sqoopuser@localhost -> IDENTIFIED BY 'sqoopuser999' WITH
SUID,SGID,Sticky bit – OpenGroove
前回に引き続きパーミッション絡みで、もう少し。 以下のように、Linuxには通常のパーミッションの他に特殊なものがある。 SUID(Set User ID,setuid) SUIDをセットしたファイルは、所有者ユーザの権限で実行可能となる。 設定対象は実行可能ファイル。 SGID(Set Group ID,setgid) SGIDをセットしたファイルやディレクトリは、所属グループの権限で実行可能となる。 設定対象は実行可能ファイル・ディレクトリ。 これらはchmodコマンドで以下のように設定する。 SUID $ chmod u+s file name SGID $ chmod g+s file name 通常のパーミッションの設定と合わせて、絶対モードで以下のようにすることもできる。 （SUID,SGIDはそれぞれ8進数で4000,2000と表す） $ chmod 4755 file na
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
