ひしだまの変更履歴

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

AsakusaFW0.7.0 Hive・Hadoop2・Excel2

2014-09-27 23:30:39 | PG(分散処理)

もうすぐ出ると言われてからちょっと経ったような気がするけれども^^;、Asakusa Framework0.7.0が出た。
リリースノート 

今回はけっこう盛り沢山で、まず最初はHive連携機能
Hiveで使われるParquetおよびORCFileフォーマットのファイルの入出力が出来る。
DMDLに(@directio.csv等と同様に)@directio.hive.parquetや@directio.hive.orcを指定することで、Importer/Exporter抽象クラスが生成される。
DMDL EditorX属性追加ウィザードにも雛形を追加しないといけないなぁ^^;)

gradlewにもgenerateHiveDDLというタスクが追加されており、HiveのDDL(CREATE TABLE文)を作ることが出来る。
これを使えば、Asakusaアプリで出力したファイルをHiveのテーブルとして扱えるというわけかな。

また、JinrikishaにもHiveが同梱されるようになっている。


次いで、Hadoop2に正式対応

build.gradle内のバージョン記述(asakusafwVersion)を、今までは「0.6.2」という形式だったが、自分が扱いたい方に応じて「0.7.0-hadoop1」か「0.7.0-hadoop2」のどちらかにする。
(DMDL EditorXでもバージョン番号を比較する処理を持っているので、対応しないといけないorz)


それから、テストドライバーの改善。

Excelの数式が使えるようになった。つまり、別セルや別シートのセルを参照したり計算式を使ったりできる。

また、値の完全一致比較だけでなく、±nの範囲指定が出来るようになった。
double型やBigDecimal型ではこれが無いとつらい。 
これに伴い、ルール記述のシートのバージョンが2.0.0に上がった。
(こういうバージョン番号って、なんだかんだで変わらないことが多いので、ちょっと驚きw) 

あー、DMDL EditorXでもExcelルールシートのバージョン変換ツールとか作りたいけど、POIにはシートやセルのコピー機能すら無いので、大変そうだなー。
というかExcelマクロだけでも出来そうな気がするので、自分が作る必要も無いかなー・・・?


最後に、実行時パフォーマンスの改善。重要!(笑)

ライブラリー(jarファイル)のキャッシュ機能が使えるようになったり、Mapタスクのスケジューリングが改善されたりしたらしい。
Reduceタスク数の調整もExperimentalでなくなったっぽい。 

さらっと書かれているけど重要だと思うのが、ステージ間の中間データに新しい形式を使うようになったこと。
Asakusaアプリケーションは複数のステージ(Hadoopジョブ)として実行されるが、その間でやりとりするファイルのデータ形式が変わり、効率よくなった。
(ステージ間のデータ形式はAsakusaFW内部だけの話なので、自由に出来るわけだよね)


あと、AsakusaアプリケーションをEMR上で動かす為のドキュメントもけっこう手が入ったみたい。

これだけ色々作ってテストしてドキュメントを書いていれば、そりゃリリースも時間がかかるよね^^;

コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

bash ShellShock確認用コマンドの意味を調べてみた

2014-09-26 23:59:59 | PG(UNIX)

bashに脆弱性が見つかって、Shell Shockという名前が付けられた。

その脆弱性があるかないかを調べる為のコマンドが以下のようなもの。
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

なんだけど、ぱっと見た感じではどういう構造なのかがよく分からなかったので^^;、意味を調べてみた
(ちなみに当初はCygwinのbashは問題ないと思ってたんだけど、改めて試してみたらアウトだったorz)

あと、環境変数に関数定義を入れて関数として実行できるのは脆弱性対応前のバージョンだけで、脆弱性を対応したバージョンでは環境変数名が変更になったようで、関数と認識されないから実行できないようだ。
まぁ、この仕様変更で困るのは攻撃者だけだと思うけど^^;

P.S.
シェルショックという感じの名前のバスケットシューズありそうだなw 

コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

バッチの未来、どうするHadoop

2014-09-13 13:35:32 | PG(分散処理)

ITproの『DBの未来、どうするHadoop』のタイトルに釣られてみたw
(以下長々書いたけど、結局言いたいことは、DBとHadoopは関係無いってことと、タイトルについて何か勘違いしたっぽいということだけだった^^;)

僕の意見では、Hadoopはバッチ処理を分散して実行する基盤である。データを溜めるのは副次的な効果に過ぎない。(暴論w)
もちろん、そもそも分散処理を行う必要があるのは処理対象データが大量だからなので、データの溜め方も必須ポイントだし、Hadoopが分散処理する原理も密接に結びついているのだが。

あらかじめ断っておくと、自分は非構造化データとか分析とか機械学習には興味が無い。
自分がHadoopに興味を持ったのは、自分が担当していた“RDBを対象にした夜間バッチ”の実行が遅かった為だ。
テーブルをパーティション化して複数のバッチサーバーからアクセスして並列処理するようにしたけれど、バッチサーバーを増やしてもDBサーバーの負荷が高くなる(ボトルネックになる)だけで、全体の実行時間は改善しない。パーティションもそう簡単には変更できないし。
その点、Hadoopならサーバーを増やせば(データ量の範囲内で)簡単にスケールする。
(ついでに、バッチアプリケーションのリリースを一箇所だけに行えば、後は勝手にやってくれるのも便利だ。自前で分散させようとすると、全サーバーにバッチアプリケーションを配置する必要があるし、スケジュールの定義も個別にしないといけないし、それぞれの処理対象範囲を決める方法も考えないといけない)

ITproの記事中に「日本で使われているHadoopクラスターのほとんどは10ノード以下」とあって、そんなものかもしれないと思うけれども、バッチアプリケーションを分散して実行するという意味では、それでも充分。
それですら、Hadoopが出てくる前(RDBMSしか無かった頃)は面倒だったんだから。
それに、Hadoopでバッチ処理をするという事は、その間はDBを使わないので、DBサーバーの負荷が下がるはず。DBはバッチ以外からも使うので、とても意味がある。
てゆーか、あの記事を解釈すると、今のRDBMSは10台のバッチサーバーから同時にアクセスされても速度が落ちないってことだよなぁ。自分がバッチを担当していた頃にその性能があればなぁ。


個人的にHadoopで目から鱗だったのは、処理(アプリケーション)をデータのある場所に転送して実行するという考え方。
DBサーバーにバッチサーバーから接続して処理を行う方法だと、データが多ければ転送量も増えるが、アプリケーションはそれらに比べれば遥かに小さいので、転送量も少なくて済む。(もちろん、シャッフル処理とかでデータ転送は発生しちゃうけど)

これをRDBMSを使ったシステムに応用しようとすると、DBサーバー上でアプリケーションを実行するという事で、きっと負荷が上がるだけで全然嬉しくないorz
(ネットワークが遅いシステムなら意味があるかもしれないが)
もしかすると、RDBMSのストアドプロシージャなんかはDBサーバー上で分散して処理しているのかもしれないけれども、ストアドプロシージャの言語って、あんまり進化している気がしない(自分でコーディングしたくない^^;)。

あと、バッチ処理は細かい条件分岐が多いので、細部では手続き的なコーディング方法の方が書きやすい。
なので、分析(対話型処理)にはSQLは超便利だと思うけど、バッチアプリケーションはSQLだけでは書けない。

もしJavaやScalaで書いたバッチアプリケーションをRDBMSが勝手に分散処理してくれて、サーバーを増やせばスケールするなら、Hadoopも一気に廃れると思う(爆)


今実際にシステムを作るとすると、バックエンドには信頼性の高いRDBかHDFS、フロントには検索性能の良いRDB、中間処理(バッチ処理)にHadoopを使うという形になると思う。

DBMSの人の考え方は「RDBもHDFSも透過的にSQLで扱う」ということになるようだが、自分は逆に「RDBのテーブルもHDFSのファイルも透過的にファイルとして扱う」になってきた。
(これはAsakusa Frameworkで開発しているせいかもしれない^^;) 

この方法の場合、DBサーバーにデータを置いたままだと処理がスケールしないので、HDFSにデータを転送してくる必要がある。
また、処理結果をRDBに戻す(転送する)必要がある。

なので、HDFSとRDBとのデータ転送を高速に行う仕組みが一番欲しい。以前からずっと待ってるw
でもDBMSのベンダーからそれが提供されたという話を聞いた覚えが無いんだよなー。
出来るならとっくにやっているだろうから、きっと原理的に難しいんだろうなー。

あるいは、HDFS上にDBを構築すれば、データの配置されている場所で処理するという仕組みは達成できるなー。
って、それはHBaseやんけw


まぁそういう訳で、Hadoopの競合はDBMSではなく、他のバッチフレームワークであると思っている。 

バッチ処理基盤として見ると、Hadoop(MRv1)はタスク実行の際のオーバーヘッド(いわゆるHadoop税)が大きいので、ジョブ数の多いバッチで悲しい思いをするorz

なので、オーバヘッドが少ないらしいApache Sparkが目下の個人的興味の的。
Scalaでコーディングできるし(笑)
ただしSparkはファイルシステムを持っていないので、HadoopのHDFSを利用する。 

あと、Apache Tezも既存のMapReduce上で動いているアプリケーション(HivePigや、もしかするとAsakusa Frameworkも?)の実行を改善できるっぽい雰囲気らしい感じがするので、ちょっと興味が出てきたところ。

こうなってくると、Hadoopの存在意義はYARN(リソース・コンテナー管理)と、HDFS(分散ファイルシステム)。
Hadoopは分散処理の基盤を目指すようなので、目的に合致していると思う。


ところでITproの記事のタイトル『DBの未来、どうするHadoop』だけど。

「DBが進化していくので、それに対抗してHadoopはどうするのか?」って意味だと思ったんだけど、もしかして、「DBの今後の方向として、Hadoopとどう付き合っていくか・Hadoopをどう扱うか・Hadoopをどうするか」という意味だったんだろうか?
(追記:「DBの未来をHadoopがどう変えていくのか」という意味にもとれるなぁ) 

前者だと思っていたので、記事の中でHadoopの将来について何も触れてなくて違和感を持ったんだけど、後者の意味なら納得だ^^;

ちなみに自分のブログのタイトルは、バッチの未来(Hadoop以外のバッチ処理基盤)に対してHadoopはどうするのかというニュアンスのつもりですよw

コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

Apache Spark自習

2014-09-03 16:56:56 | PG(分散処理)

世間では8月で夏休みが終わったようだが、こちとら9月に入ってからが夏休みだぜヒャッハー!(夏とは思えないくらい涼しいけど^^; ヒヤッ)
という訳で夏休み中にやりたい事はいっぱいあったんだけど、Apache Sparkの自習に落ち着いた。

元々Sparkは2011年(Spark0.3の頃)にちょっとだけ試したことがある。
Hadoopを知ったのが2010年で、Scalaの勉強を始めたのがそのちょっと後。そんな中でScalaの分散処理基盤としてSparkが出てきたので、興味を持ったというところ。
ところが最近になってSparkが盛り上がってきた感じなので、改めて調べてみたくなったのだった。

Sparkはインメモリーで処理する(詳しい人からすると違和感がある表現らしいが^^;)という感じで盛んに喧伝されているけれども、自分は頭が悪いので、実際にコーディングしてみないと雰囲気が分からない。
という訳で、とにかく一通りコーディングしてみた。

試す上では、Sparkシェルが便利。ScalaのREPL同様、対話的に実行できる。
特にRDDのメソッドに対し、どのメソッドを呼び出したら実際の処理が始まるのかがはっきり分かる(笑)

RDDのメソッドは通常のScalaのコレクションのメソッドと似ているのだが、結合用のメソッドが充実している点は大きく違う。 

Spark SQLも少し試してみた。
Sparkは通常のScalaのコレクションのメソッドチェーンと同様のコーディングが出来るのが特徴だと思っていたので、SQLで記述するという事には懐疑的なのだが、通常のRDDとは違う最適化を行ってくれるらしいので、良いのかもしれない。 
統合言語クエリー(.NETのLINQがそういう日本語訳のようなので、そのまま使った^^;)はまさにDSLっぽくて、文字列でSQLを書くよりは良さそう。(文字列内のSQLは何が間違っていても一切コンパイルエラーになってくれないし、パースは実行時なので)

あと、HiveのテーブルもSpark SQLの機能でアクセスできる

もうひとつ、いわゆるリアルタイムっぽい処理にもあまり興味は無いんだけど、一応Spark Streamingも試してみた。
どういうコーディング方法なのかが一番疑問だったんだけど、ファイルに出力する部分まで含めて最初に定義(宣言)して、後は定期的に実行されるということが分かった。

最後に、SparkとHadoopの違いをまとめてみた。
聞きかじり+思い込みで書いたものなので、間違っている可能性も非常に大きい。(用語もテキトーだし(汗))
詳しい人に教えていただきたいところだ^^;
ついで言うと、マスターURLのYARNの部分も不安。英語はほんと苦手だorz


コーディングしてみて思ったのが、やはりScalaのメソッドチェーンぽいので、Scalaをやってた人からすると自然な感じ^^
(Hadoopで素のMapReduceを書く人はもういないと思うが、そういうコーディングよりも遥かに簡単。ちなみにSpark SQLの統合言語クエリーによるコーディングは雰囲気的にCascadingに似ているかもしれない)
(とは言え、まだ普通の人がScalaのコーディングをするとも思えないし。SQLやPythonで書くのかー? Sparkに期待している人達って、どうするつもりでいるんだろう?) 

でもメソッドに渡す関数が大きく(数十行とかに)なってしまったら、逆にメソッドチェーンにするのは見通しが悪くなりそうな気もする。
これはSparkに限らず、Scalaで大規模なコーディングってどうやるんだろう?という、かねてからの疑問でもあるんだけど。
Java8のStreamを使ってコーディングする際の、ラムダ式にどれくらい処理を書くか?という問題も今後出てくると思うけど、それも同じ) 

そういう意味では、Asakusa Frameworkが必ずOperatorクラスに処理を書かせて、処理の粒度を保ったり単体テストを書き易くしたりしているのは、Sparkでコーディングする際にも参考になるかもしれない。

コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする