ひしだまの変更履歴

ひしだまHPの更新履歴。
主にTRPGリプレイの元ネタ集、プログラミング技術メモと自作ソフト、好きなゲームや音楽です。

Asakusa Framework 0.9.0のOracleダイレクトパスインサート

2016-12-09 00:00:00 | PG(分散処理)

Asakusa Framework Advent Calendar 2016の9日目です。
今日は、2016/12/6にリリースされたAsakusaFW 0.9.0のWindGateのデータベース接続時の最適化オプションについてです。

AsakusaFWはWindGate JDBCでRDBアクセスが出来ます。
WindGate JDBCはどのRDBMSでも使えるようにする為、標準的なSQLのみでDBアクセスするようになっています。

が、今回、Oracle11gのダイレクト・パス・インサートを使うオプションが追加になりました。
以下のような設定を行うと、INSERT文にAPPEND_VALUESヒント(/*+ APPEND_VALUES */)が追加されるそうです。(今はOracle DBを持ってないので試せてないです^^;)

  • WindGateのプロファイルに「resource.jdbc.optimizations=ORACLE_DIRPATH」を指定する
  • ExporterクラスでgetOptionsメソッドをオーバーライドしてOption.ORACLE_DIRPATHを返すようにする

ただ、APPEND_VALUESでネットを検索してみたら、使いどころを間違うと逆にパフォーマンスが劣化することがあるようですね。このオプションを付けたり外したりして試してみるのが良さそうです。
(AsakusaFWでは基本的にある程度大量のデータをINSERTすることになるので、たぶんダイレクト・パス・インサートの方が速いのだろうとは思いますが) 

コメント
この記事をはてなブックマークに追加

Asakusa Framework 0.9.0の対応プラットフォーム

2016-12-08 00:00:00 | PG(分散処理)

Asakusa Framework Advent Calendar 2016の8日目です。
今日は、2016/12/6にリリースされたAsakusaFW 0.9.0の対応プラットフォームについてです。

AsakusaFW 0.9.0では、Java7(JDK7)が非対応になりました! Java8(JDK8)を使う必要があります。
M3BPは最初からJava8でないと駄目なので関係ないですが、MapReduce版やSpark版だと影響が大きそうです。Hadoopクラスターの各スレーブノードのJavaのバージョン(Hadoopのバージョンも?)を全部上げないといけない訳ですから…。

あ、Asakusa on Sparkが対応しているSparkも、1.6ではなく2.0以降になったそうです。 

コメント
この記事をはてなブックマークに追加

Asakusa Framework 0.9.0のバージョン体系

2016-12-07 23:13:12 | PG(分散処理)

Asakusa Framework Advent Calendar 2016の7日目です。

昨日(2016/12/6)、AsakusaFW 0.9.0がリリースされました。→リリース情報
アドベントカレンダーのネタが切れそうだったところになんてタイムリーw ちょうどいいので複数日に分けて紹介していきたいと思います。

まずは、バージョン体系について。今回からディストリビューション方式になったそうです。

AsakusaFWは複数のコンポーネントがあり、それぞれにバージョンが付いています。(Asakusa on Sparkは0.3.2でAsakusa on M3BPは0.1.3とか)
そして使用できるバージョンの組み合わせが決まっていますが、バージョンが進んでいくと、どれが対応しているのか分かりにくくなってきます。
そこで、build.gradleにはディストリビューションのバージョン(0.9.0)を指定するだけで、各コンポーネントのバージョンは自動的に判断されるようになりました。

という訳で、build.gradleの書き方が変わったので、バージョンアップする際にはマイグレーション作業が必要です。


それから(AsakusaFWとしては珍しく)、0.8系でも最新版(AsakusaFW 0.8.2)がリリースされています。
こちらはバグフィックスのメンテナンスリリースだそうです。 


ちなみに、Elastic Stack(Elasticsearch等のプロダクト群)も、組み合わせられるバージョンが混乱するとの理由から、バージョンが全て5.0に統一されたそうです。こちらは各プロダクトの最新バージョンが全て5.0になったので、間の3とか4が無いプロダクトがあるようです。
AsakusaFWのコンポーネントの場合は、各コンポーネントのバージョンは別々に付いたままです。build.gradleでディストリビューションのバージョンを指定すると、それに対応したバージョンのコンポーネントが使われる、ということです。

コメント
この記事をはてなブックマークに追加

Asakusa Frameworkも分散処理フレームワークです

2016-12-06 23:16:59 | PG(分散処理)

Distributed computing Advent Calendar 2016(およびAsakusa Framework Advent Calendar 2016)の6日目です。

Asakusa Frameworkは、分散処理するバッチアプリケーションを記述・実行する為のバッチフレームワークです。
ASF(Apacheソフトウェア財団)のプロジェクトではありませんが、OSSです。(アドベントカレンダーに例示されているプロダクトはASFばっかりだったので、敢えて書いてみましたw)
Asakusa DSL(実態はJava)でアプリケーションを記述し、コンパイルすることで、様々な実行基盤、すなわちHadoopSparkM3BPで動くバイナリー(jarファイル)を生成できます。 

AsakusaFWが初めて登場したとき(2011年3月)は、実行基盤としてサポートしているのはHadoopのみでした。
つまり自分としては、HivePigと同じような、Hadoop(MapReduce)を隠蔽するフレームワークという認識でした。(しかしながら、Hadoopエコシステムの一員としてAsakusaFWを出してくれる人は稀でしたが^^;)

しかし去年はSparkに対応し、今年はM3BPに対応しました。
アプリケーションを変えずに、リコンパイルするだけで実行基盤を切り替えることが出来るのです。


HadoopやSparkは、複数サーバーで分散して処理するフレームワークであり、1台のサーバーで処理しきれない量のデータ(ビッグデータ)を扱う為のものです。
しかし時代は流れ、最近の(高性能)サーバーなら、1台で数百GB~TB級のメモリーを持ち、CPUのコアも数十~100以上持つよう(メニーコア)になっています。(CPUのクロック数は頭打ちになっていますが)
つまり、200GB程度のデータなら今は1台のサーバーで処理できるわけで、こうしたサイズのデータをHadoopやSparkで処理するのはオーバーヘッドが(相対的に)大きくなります。
そこでM3BPが登場しました。

M3BPは、1台のサーバーに特化した、マルチスレッド(OSネイティブのスレッド)で分散処理するフレームワークです。
自分が扱っているバッチは、今のところ全てM3BPで動かせるデータサイズで、バッチの実行速度もM3BP版が最速です。(→実行時間の例
ただし、M3BPは1台のサーバーのメモリーに乗り切るサイズのデータしか処理できないので、データ量が増えたら実行できなくなります。ただ、その場合でも、AsakusaFWはリコンパイルのみでSpark用のバイナリーを生成できるので、Sparkで実行するという方策が採れるのが強みです(笑)

(なお、Sparkもメニーコアマシンに対応しようという話があるようですが、1年ほど前に指摘したら却下されたのでM3BPを作ったとか? そして、M3BPの方が速いらしい?です)

コメント
この記事をはてなブックマークに追加

Asakusa Frameworkチュートリアル

2016-12-05 22:17:41 | PG(分散処理)

Asakusa Framework Advent Calendar 2016の5日目です。

1日目に書き忘れたのですが、今年、AsakusaFWのドキュメントにAsakusa Frameworkチュートリアルが加わりました。
これは、インストール方法から実装・リリース方法などを、実際のソースを例に順を追って説明している、なかなかの力作です。

自分もWordCountを例にした実装方法のページを書いていますが、さすがにチュートリアルには敵いません^^;
(というか、一番最初はHadoopから入ったのでWordCountを例にするのが分かりやすかったんですが、今となっては、WordCountもどうなんだろうという感じですね(苦笑))

コメント
この記事をはてなブックマークに追加

AsakusaFWで転職

2016-12-04 12:27:03 | Weblog

Asakusa Framework Advent Calendar 2016の4日目です。
というか、アドベントカレンダーに関連付けする為に無理矢理ブログタイトルに「AsakusaFW」を入れましたが、内容はJJUG CCC 2016 Fall(2016/12/3)の感想ですw

なぜか話を聞きたいと言われて『Javaエンジニアのキャリアを考えるパネルディスカッション』のパネリストとしてjohtaniさんから誘われ、自分は特にキャリアとか格好いいこと考えてないんだけどなーと思いましたが、せっかくなので参加させていただきました。(発表用メモをこっそり置いておきます→こっそり
他の人が社長だったり人事部長だったりエバンジェリストだったりするのに対して自分はずっとプログラマーなので、人選的には合っていたのかもしれません。
しかし予想通り、yoshioriさんやjohtaniさんは格好いいことを言うし、yusukeさんも手馴れた感じでコーディネーターを務めていましたが、自分は意識低い事を言っているだけでしたorz
何か参考になる事があったのであればよいのですが…。
自分の経験談から自信を持って言えることは、「アウトプット大事」くらいです(笑)

自分が転職できたのはAsakusaFWをやっていたおかげだと思っていますが、AsakusaFWのことをウェブページに書いていなければ(アウトプットしていなければ)、他の人の目に留まることも無かったわけです。
ちなみにAsakusaFWを知ったのはHadoopに興味を持って調べていたからで、Hadoopに興味を持ったのは、当時自分が担当していた夜間バッチが遅いという問題をかかえていたからです。
もしその問題が無かったら、Hadoopを知っても「自分には関係ない」と流していたかもしれません。何がきっかけになるのか、分からないものですねw

そういえば、yusukeさんがTwitter社に入った際にTwitter4Jが役立ったのか、自分から売り込んだのか先方から声をかけられたのか、聞いてみたいなーと思っていたけど聞きそびれました^^;
それと、yusukeさんが「プログラミングは土日でも出来るので仕事はそれ以外でも」と言っていましたが、自分は逆に、プログラミングが好きなので仕事でもプログラミングできるのが一番良いと思いました。

あと、yoshioriさんが「一番底辺になる場所に行く」と言っていましたが、自分も期せずして、今の会社ではそんなポジションですw


自分はキャリアプランとか人生の目標とかは特に考えていませんが、(寿命以外で)死にたくないとは思っていますw(ゲームもやりたいし本も読みたいw)
川の上を流される葉のごとく、「気が付いたらこんなところに来たかー」って思って死にたいけど、出来れば良いところに行きたいなぁ。

コメント
この記事をはてなブックマークに追加

Let's Retz!

2016-12-03 00:04:55 | PG(分散処理)

Asakusa Framework Advent Calendar 2016の3日目です。

Asakusa on M3BPのバッチは1台のサーバーのメモリー上に全データが乗る必要がありますが、当然、バッチの種類およびデータ量によっては、サーバーの全メモリーを使用するわけではありません。
例えばメモリーを512GB搭載しているサーバーであれば、最大128GBしか使わないバッチは4並列まで実行できることになります。
(それぞれのM3BPバッチがマルチスレッドで動くのでCPUのコア数もそれなりに必要ですが、これまでの経験では、コア数はそんなに多くは必要なかったです。メモリーは足りないとバッチが落ちますが)
しかし、256GB使うバッチが混ざっていると3並列まで可能? 256GBのバッチ2つなら2並列?という具合に、並列実行させるのは結構面倒です。

そこでRetzの出番です!(笑)

Retzは、バッチの実行を行うジョブスケジューラーです。
Retz自身はAsakusaFWと直接の関係は無く、AsakusaFW以外でも使用可能です。

スケジューラーと聞くと、個人的には、バッチを特定時刻で起動したり、前のバッチが終わるまで待って後続バッチを実行したりするツールを思い浮かべるのですが、Retzはそういうものではありません。
Retz管理下のクラスター(複数のサーバー)の中からリソース(CPUやメモリー)が空いているサーバーを探し、そのサーバー上でジョブ(バッチ)を実行してくれるものです。
Retzに対して複数のジョブの実行を指示しておけば、リソースが足りている分について並列でジョブを実行してくれます。
リソースが空いていなければ、空くまでジョブの実行を待ちます。 

これを応用し、M3BPマシンでクラスター(1台構成でも可w)を組んでおけば、そのマシンのリソースを使い切るまで、バッチを詰め込んで並列で実行してくれるわけです。

ちなみに、Retzを使ってバッチを実行することを、業界(弊社内のごく一部)用語で「Let's Retz」と言うようです。
^^; 

コメント
この記事をはてなブックマークに追加

バッチのメモリー使用量の確認方法

2016-12-02 00:00:59 | PG(分散処理)

Asakusa Framework Advent Calendar 2016の2日目です。

Asakusa on M3BPのバッチでは、データがマシンのメモリーに乗り切らないと処理できません。
したがって、どれくらいのメモリーを積んだマシンを用意すればよいか?ということが問題になります。
しかしながら、バッチの種類(どんな処理をするのか?入力データを絞る処理なのか、データを増幅させる処理なのか、中間データが膨らむような処理なのか)によって必要なメモリー量は異なるので、一概にどれくらいあればいいとは言えません。
一応、余裕を見て、入力データの5倍くらいのメモリーがあれば大丈夫かなぁというのが目安な感じではあるようですが。

そして、バッチが完成したら、実行の際に実際にどれくらいのメモリーを使ったのかが気になります。
Unixのtopコマンドでメモリー使用量は分かりますが、ずっと見ていないといけません(爆)
昔ながらのstat系のコマンドを使うならvmstatでしょうか。
最近のLinuxだと、dstatというコマンドがとても便利です。stat系の情報(指定したもの)を全て表示できます。

$ dstat -t --cpu --sys --mem --disk --net --output dstat.out 1

(dstat.outというファイルにCPU使用率・メモリー使用量・ディスクアクセス量・ネット通信量を出力します)

ただ、メモリーの最大使用量を確認するだけなら、timeコマンドが便利です。
timeはシェルの組み込みコマンドのようですが、/usr/bin/timeというものもあって、後者に-vオプションを付けると、コマンドの実行時間の他にメモリーの最大使用量等の情報が表示されます。

$ /usr/bin/time -v $ASAKUSA_HOME/yaess/bin/yaess-batch.sh m3bp.ExampleBatch
~
        Command being timed: "/home/hishidama/asakusa/yaess/bin/yaess-batch.sh m3bp.ExampleBatch"
        User time (seconds): 1879.28
        System time (seconds): 70.34
        Percent of CPU this job got: 1588%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 2:01.69
~
        Maximum resident set size (kbytes): 47875156
~
        Exit status: 0

なお、yeass-batch.shに対してtimeコマンドを仕掛けるのではなく、その中で起動されるjavaコマンドに対して仕掛けることも出来ます。

$ export ASAKUSA_M3BP_LAUNCHER="/usr/bin/time -v"
$ $ASAKUSA_HOME/yaess/bin/yaess-batch.sh m3bp.ExampleBatch

ただ、どちらの方法でも結果は大差無かったです。

コメント
この記事をはてなブックマークに追加

Asakusa Frameworkとは(2016版)

2016-12-01 00:54:59 | PG(分散処理)

Asakusa Framework Advent Calendar 2016の1日目です。

アドベントカレンダーの初日ということで、2016年時点のAsakusa Frameworkの紹介を書いておきたいと思います。


Asakusa Frameworkは、分散バッチアプリケーションを開発・実行する為のフレームワークです。
実行基盤としてHadoopSparkを使うことが出来ますが、今年、実行基盤にM3BPが加わりました!
(去年までは「メニーコア対応として開発中」だったものです) 

HadoopやSparkは複数サーバーにまたがって分散処理しますが、M3BPは1台のサーバー上でマルチスレッドで分散処理するものです。
(M3BPのマルチスレッドはOSのネイティブスレッドなので、Javaのマルチスレッドより高速です) 

昨今ではサーバーのメモリー搭載量が増え、数十~数百GBのデータなら1台のマシンに乗るようになりました。そこで、複数マシンでの分散でなく、1台のマシンで処理する方式が実装されたのです。HadoopやSparkのアンチテーゼと言えるかもしれません。
なお、M3BPではメモリーに乗り切らないデータは処理できませんが、AsakusaFWではAsakusaアプリケーションのコンパイルのみでSpark版とM3BP版の両方の実行バイナリーを作成することが出来るので、M3BPで処理できなければ(アプリケーションを変えずに)Sparkで処理する、ということが出来ます。

今のところ、自分が扱っているバッチは最大でもメモリー使用量270GB程度なので、メモリー512GBのサーバーで全てのバッチがM3BPで実行できています。
経験上、M3BPで動かすと、Sparkよりも平均で4~5倍速いです!
(実行時間の例は、Scala関西サミットの資料に少し載せてあります) 

今までSpark(やHadoop)で動かしていたバッチが、リコンパイルのみでM3BPで動くようになるのは、なかなか感動的だと思います(笑)

コメント
この記事をはてなブックマークに追加

Gitリポジトリーのコピー

2016-11-28 20:42:08 | PG(CVS・SVN・Git)

Windows10がWindows史上最悪のWindowsなので、Windows7を再インストールして環境構築中なのだが。
Cドライブは再インストールの為にフォーマットしたけど、データはDドライブに入れていたから、基本的にはそのまま使える。
と思っていたら、Cygwin上のGitのアカウント管理でハマったorz

Windows7をインストールしたときにユーザー名は同じにしたんだけど、内部ではIDが異なっていると思われる。そのせいで、Cygwinの今までのディレクトリーおよびファイルが「異なるユーザー」という扱いになってしまう。パーミッションが700のファイルだと、アクセスできない。
そのままだとchmodもchownも実行できない(パーミッションのエラーになる)。管理者モードでCygwin bashを起動すれば実行できたので、オーナーを変更できたが。

やれやれ、これで解決…と思ったら、Gitでブランチを変更するときに問題発生。いくつかのファイルがパーミッションエラーになる。
そのファイルのパーミッションを見てみると、グループだけrwで、ユーザーは権限無し。
たぶんGit内部でユーザーのIDを管理していて、そのIDでファイルを作ろうとしているのではないかと思う。そのIDのユーザーは無いので、ユーザーのパーミッションのrwが付かないのではないかと推測する。
(たぶん、.gitディレクトリーをそのまま別のWindowsマシンに持っていってCygwinで使ったら、同じ問題が起こるのではないかと思う) 

結局、git clone --bareでリポジトリーをコピーして作り直したら、新しいリポジトリーは普通に使えるようになった。(git clone --mirrorでもおおむね大丈夫そうだったが、bareとmirrorの違いはよく分からない…)

コメント
この記事をはてなブックマークに追加