バッチ処理、ジョブ管理について書いてみる - wyukawa's diary
僕はHive, Pythonでバッチ処理を書いてAzkabanでジョブ管理するシステムを構築、運用した経験が2年ほどあるので今日はバッチ処理、ジョブ管理について書いてみようと思います。 僕の経験上Hadoop特有の部分、例えばテスト環境が作りづらいとかバッチサーバーはジョブをsubmitするだけなので負荷はそんなにかからないとか、はあるけれど割と汎用的なのではないかと思います。そもそもバッチ処理、ジョブ管理について書かれたものはほとんど見た事がないので参考になれば嬉しいし、こういう良い方法もあるよ！とかあれば是非ブログ等に書いてほしいと思っております。 最初に言っておくとバッチ処理、ジョブ管理において重要なのは障害時のリカバリのしやすさです。正常時はまあいいでしょ。 なので例えば引数に日付を持てないようなバッチ書いたら辛いですし、LL言語で書く方がコンパイル、パッケージングとか楽です。CP
Garbage Collectionについてちょっと調べてみた - wyukawa's diary
HBaseのJuliet PauseをきっかけにしてGarbage Collection(以下GC)についてちょっと調べてみました。そういえば長年Javaでお仕事している割にはGCのこと全然知らなかった（汗 GCというのは不要になったメモリを回収することをいいますがそのアルゴリズムにはいくつかあって代表的なものとして以下の2つがあります。 Mark Sweep GC Coping GC Mark Sweep GCはオブジェクトをアプリケーションからたどっていってMarkしていきます。Markが無いのは使われていないオブジェクトなのでSweepします。メリットは実装が簡単なことでデメリットはメモリの断片化、フラグメンテーションが起きることです。 Coping GCはヒープ領域を2つに分けてオブジェクトをコピーしたり移動したりすることです。メリットはスループットが高いことやフラグメンテーション
継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化 - wyukawa's diary
継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化 作者: David Farley,Jez Humble,和智右桂,高木正弘出版社/メーカー: KADOKAWA/アスキー・メディアワークス発売日: 2012/03/14メディア: 大型本購入: 24人 クリック: 567回この商品を含むブログ (53件) を見る 発売日は3/5なのですが僕はレビューに参加したのですでに読み終えてます。忘れないうちにエントリを書きたいと思います。 「イントロ」、「本書を読んだだいたいの感想」、「抽象化によるブランチ」、「誤字脱字、訳質」、「対象読者」、「最後に」と続きます。長いので最初の２つだけ読むと良いかも。 イントロ 最近は アジャイル開発と継続的デリバリー | NTTデータ だったり 明日から始まるデブサミでの川口さんのセッションにあるようにContinuo
fluentdを試してみた - wyukawa's diary
クレジットカード現金化詐欺【業界人が教える口コミ情報】 僕は行ってないんですがTwitter、Ustream、スライド、ブログなどを見る限りだいぶ盛り上がったようですねー。僕自身が仕事で使う予定は今のところ無いんですがログ解析関連の仕事をしていることもあるので素振りしてみようと思います。 環境はVirtualBox上のCenOS 5.7(x86_64)を使いました。 fluentdはRuby 1.9上で動くんですがCentOS 5.7に入っているのはRuby 1.8.5です。Ruby 1.9のインストールから始めるとはまりそうなのでyumでインストールできるtd-agentを使います。td-agentはfluentdの安定版パッケージという位置付けのようです。 試したのは下記３つです。 fluent-catでログを送る Apacheのアクセスログを収集 ApacheのアクセスログをMong
TortoiseHgでMQ - wyukawa's diary
MercurialにはMQというGitには無い機能がある。内容としてはGitのインデックスにちょっと近いかも。 この機能は簡単にいえばパッチ管理なのだが理解しづらい。以下のエントリが一番わかりやすい。 Mercurial MQ について - daily dayflower このエントリの流れをTortoiseHgでやってみたので、スクリーンショットをべたべたはってみた。 初期状態 カクテルを追加します。 ここで普通にコミットするのではなくQNewにadd_menuを指定してQNewします。 そうするとこんな感じ。add_menuというパッチが登録されました。 リポジトリエクスプローラはこんな感じ こんどはワインを追加して、QRefreshします。 リポジトリエクスプローラはこんな感じ。コミットとは異なりQRefreshは積算しメッセージは上書きされます。 リポジトリエクスプローラでPatc
MercurialとGitのブランチの違い - wyukawa's diary
MercurialのブランチというのがどういうものでしかもそれがGitと同じなのかどうかもいままでよくわからなかった。 その辺のモヤモヤがこれを読んで理解できた（気がする）。 experimentalworks » Blog Archive » Mercurial bookmarks A Guide to Branching in Mercurial / Steve Losh まずMercurialでは以下の4種類のブランチがある。 リポジトリをcloneしてつくるブランチ hg bookmarkで作るブランチ hg branchで作る名前付きブランチ 名無しブランチ リポジトリをcloneしてつくるブランチは hg clone test-project test-project-feature-branch というように単純にcloneして新機能を開発してあとでマージなりリベースなりする
EclipseでWebアプリを作っていて別プロジェクトを参照している場合の注意点 - wyukawa's diary
長いタイトルの割には伝わりづらいw ええと、Webアプリsample-webを作っているんだけど、ユーティリティ関連は別プロジェクトとしてsample-commonに切り出している。 で、sample-webはsample-commonを参照しているという状況です。かなりありがちだと思います。DBアクセスも外だししてバッチとWebで共有したりするでしょう。 sample-common側のソースは下記で package common; public class Greet { public static String greet() { return "hello"; } } sample-web側はこんな感じ。 package hello; import java.io.IOException; import java.io.PrintWriter; import javax.servle
Subversion, Git, Mercurialそれぞれでのcherrypicking - wyukawa's diary
つまみ食いとか青田買いといわれるcherrypickingはある特定のコミットをブランチから抜き出して別のブランチに反映させるというものです。 Subversion, Git, Mercuriaそれぞれのやり方を調べてみました。 まずSubversionいってみましょう。 準備 $ svnadmin create repos $ svn checkout file:///tmp/repos work Checked out revision 0. $ cd work/ $ svn mkdir tags branches trunk A tags A branches A trunk $ svn commit -m "add initial dir" Adding branches Adding tags Adding trunk Committed revision 1.trunkの直下に
モダン（かもしれない）なEclipse環境(Java)の構築方法 - wyukawa's diary
「モダンなEclipse環境の構築方法」とかね。 2010-07-21 - marsのメモ 僕が書くのも場違いな気がするけど、とりあえず書いてみるよ。 Webアプリ作るという前提だとまずEclipse IDE for Java EE Developersをダウンロードしてインストールする。JDKは別途ダウンロードする。Tomcatも別途ダウンロードする。 JDKはWindowsの場合はデフォルトではProgram Files以下にインストールしようとするがパスに空白が含まれてるのが嫌なのでC直下とかにする。 Tomcatもインストーラを使わずにZIP版を解凍して、パスに空白が含まれていない場所にインストールする。 プラグインはSubversionクライアントとしてSubclipseを、プロパティエディタとしてちょま吉をインストールする。ここまでは必須。 DB使うようならDBViewerもイ
大規模受託開発におけるCI - wyukawa's diary
そろそろ大規模ソフトウェア開発に一言いっておくか。デイリービルドとリグレッションテスト すばらしいスライドだ。ディリービルドとリグレッションテストを大規模パッケージ開発において適用したときの雰囲気が良く現れている。10年前の話のようだが今で言うCI（継続的インテグレーション）だよね。 僕も2年ぐらい前にパッケージ開発でCruiseControlを適用したことがある。junitのテストケースがあったがメンテされていなかったので使わなかった。結合レベルの自動テストもあったがこれもメンテされておらずそんなに使わなかった。スローテスト問題もあったしね。その代わり新たに結合レベルの自動テストを作っていってそれなりにうまくいったように思う。ただ実質一人プロジェクトだったこともあり途中から面倒になってやらなくなった。一人だと自分のローカルがマスターといってもいいので大規模に比べるとCIのメリットは薄い。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
