DMDLの属性の選び方

Asakusa Framework Advent Calendar 2013の15日目、DMDLの話の第3弾です。

11日目のDMDLの基礎でも書いた通り、DMDLの文法では「属性（@で始まるやつ）」を指定することが出来ます。
問題は、どういう属性を指定するのか？（指定すればよいのか？）という事です。

DMDLファイルはコンパイルされてモデルクラスが生成されますが、その他の拡張機能を指定するのが属性の役割です。
@namespaceや@auto_projectionといった属性もありますが、どちらかといえばマイナーだと思います。（拙作のDMDL EditorXでは対応していません(爆)）
一番使われているのは、インポーター・エクスポーター（外部システムとやりとりするファイル）のクラスを生成する事でしょう。
DirectI/OのCSVファイルの場合は@directio.csv、WindGateのCSVファイルなら@windgate.csv、JDBCなら@windgate.jdbcを指定します。
（逆に言えば、インポーター・エクスポータークラスを生成する必要のないデータモデルでは、こういった属性を指定する必要はありません）
（なお、DirectI/OやWindGateとは、Asakusaアプリケーションの外側のシステムとの入出力（外部連携）を行う仕組み（コンポーネント）です） 

つまり、どの属性を指定すればよいかは、外部システム（Asakusaアプリケーションの外側のシステム）との連携方法をどうするか？を決めないと決まりません。
外部連携方法（システムの構成方法）は、www.asakusafw.comの参考資料の『Asakusa Framework-RDBMS連携方法』が参考になると思います。
また、cocoatomoさんがアドベントカレンダーに書かれている外部連携の話(前編・後編)も、ずばりそのものですね(笑)

ちなみに、ひとまずAsakusaFWを試してみようという場合は、たぶん外部連携を考えるよりもDMDLやFlow DSL・Operator DSLを書いてみる方が主になるでしょうから、とりあえず@directio.csvを使っておけばよいと思います。 

HadoopのWindows対応状況

Hadoop Advent Calendar 2013の15日目です。
昨日は@s_woolさんの『hueでロードバランシングできるようにしてみる』でした。

Hadoopは基本的にUNIX上で動作しますが、Windowsにも対応して…いたりなかったり＾＾；なので、ちょっとまとめてみます。
以下、「動作した」というのは、スタンドアローンモードで円周率算出サンプルが動いたことを意味します。

---

Hadoop0.20の頃はCygwin上で動作させることが出来ました。ドキュメントにもCygwinを使って動作させる方法が書いてあったと思います。
ClouderaのCDH3もHadoop0.20系なので、Cygwin上で動かせます。 

ところが、（0.20の後継である）Hadoop1.2.1（Hadoop1系の最新）をCygwin上で動かしたらエラーになりました。
シェルの中にはCygwinかどうかを判別している箇所はあるので、Cygwin対応をしているとは思うんですけどね（以前から残っているだけという可能性も高そうですが）。
ちなみに、さっき見たら（Hadoop0.23の最新である）Hadoop0.23.10が出ていたので試してみたら、あっさりCygwin上で動きました＾＾；

次に、HortonworksのHDP1はWindows対応を謳っていて、Cygwinを使わず、hadoop.cmd等が提供されています。
が、この「Windows」はWindows Serverの事であり、WindowsXP・Windows7とかは対象外です。Windows ServerでHadoopクラスターを組むことを目的としており、開発環境として使うことは想定していないっぽいです。
無理矢理やったらWindows7にインストールできるし、コマンドプロンプトからちゃんと実行できましたけどね。やっぱり正式対応を宣言してくれないと、他の人には勧めにくいです＾＾；

こういう状況なので、やっぱり主流はWindowsに興味が無いんだろうなぁ…と思っていたら、Hadoop2系のHadoop2.1.0-betaがWindowsをサポートしたとあって、びっくり！（たぶん、HDPのWindows対応の内容がApache Hadoopにバックポートされたんだと思うんですが）
ところが、喜んで試してみたら、途中でエラーになる＞＜
cmdファイルはあるんですが、その後、中で呼び出しているwinutils.exeが無いんですよねー。他にもDLLファイルが必要そうなんですが、Hadoopのアーカイブに含まれていないし。まぁ、この時点ではベータ版だったので、正式版が出るときには同梱されるだろうと思っていたんですが。
Hadoop2.2.0-GAも同様の状況でしたorz
ozaさんがissue（HADOOP-10051）を作ってくださったので、そのうち対応されると思うのですが、進捗どうですか？＞開発者の方々
ちなみにこの件に関連して、stackoverflowにソースをコンパイルしてwinutils.exeやhadoop.dllを生成する方法があるのを見つけましたが、それを皆がやるかというと、どうなの？って気がします。Hadoopのドキュメントに手順としてそう書かれていたら仕方ないかなーとも思うんですが、特に何も書かれていないし。
僕は英語が苦手なんでよく分からないんですが、Hadoop2.2.0-GAの「GA」ってどういう意味なんでしょうね？(苦笑)

あと、CDH4・CDH5（Hadoop2系）は試していませんが、たぶんWindowsは対象外でしょうね。
HDP2（Hadoop2系）も対応バージョンにWindowsは含まれていません。

---

何故Windowsにこだわるかと言うと、やっぱり日本では、Hadoopを使って開発をする人（SIer）の環境はWindowsが多いと思うからです。
WindowsでHadoopクラスターを組みたいわけではありません。（HDP（というかHDInsight）はWindows Azure向けに開発された感じがするので、きっとAzureはWindows ServerでHadoopクラスターを作っているのだと思いますが）
まぁ、きっとこれは日本独自の話であり、Hadoopを作っている人達は気にしていないでしょうorz 

というか、HadoopがWindowsに正式対応してくれないと、Asakusa FrameworkがWindowsで動かせないのです(爆)
AsakusaFWで作ったアプリケーションは、Hadoopのスタンドアローンモードを利用してテストを実行するので。
Cygwinを使って動かすことも頑張れば出来ますが、やはり正式対応して欲しい…。 

---

Hadoopアドベントカレンダー、明日は@nagixさんです。
先にMapRとDrillのネタを書いてnagixさんにネタ被りしないように無茶振りするのは、自分の力では無理です＞＜

DMDLエディター（とExcel）

Asakusa Framework Advent Calendar 2013の12日目、DMDLの話の続きです(笑)

昨日のDMDLの基礎でも書いた通り、DMDLファイル自体は単なるテキストファイルです。
DMDLはAsakusaFW独自の言語なので、普通のエディターではキーワードに色が付いたりしません。
が！ なんと！！ 拙作のDMDL EditorXを使うと、キーワードに色が付いたり入力補完できたりソース整形できたりします(笑) テキストベースの機能ばかりでなく、プロパティーを検索したり一括して属性を変更したりするウィザードも付いています。とっても便利でっせ！まぁなんて素敵なの♥ #ステマ

DMDL EditorXはXtextを使って作ったEclipseプラグインでして、インストール手順はAsakusaFW本家の紹介ページが丁寧です(笑)

---

そういえば、データモデル（特にレコードモデル）は一般的なレイアウト定義なので、Excelを連想する人もいるかもしれません。テーブル定義をExcelで書くのと似てますよね。そんでDDLをExcelマクロ（VBA）で生成してみたりして＾＾；

という訳で、以前、Excelでデータモデルを定義してDMDLファイルを生成するマクロを作ってみたので、ついでに紹介しておきます。Hadoop-example2-CSVのafw-dmdl.xlsがそれです。
まぁ、中間データのデータモデルまでExcelで管理しようとすると大変だと思うんですけどね＞＜

データモデルの数やプロパティーの数が増えると、Excelよりもテキストの方が検索・コピー&ペーストがしやすかったりするかもしれません。
Asakusa DSLにせよDMDLにせよ、AsakusaFWのDSLがテキストベースになっているのは、大量に書く場合は結局テキストの方が便利、という考えらしいです。
テキストで書いてあれば、変更した後の差分チェックも簡単ですし。

DMDLの基礎

Asakusa Framework Advent Calendar 2013の11日目です。
3種類のAsakusa DSLのうち、Batch DSL・Flow DSLと来て次はOperator DSLです
と見せかけて、今日はDMDLについてです(笑)

DMDLはデータモデル定義言語（DataModel Definition Language）の略で、その名の通り、「データモデル」を定義する為のDSLです。
データモデルはファイルレイアウト（レコードレイアウト・テーブルレイアウト）相当のものです。 

Batch DSL・Flow DSL・Operator DSLが「Javaをホスト言語とする内部DSL」であるのに対し、DMDLは外部DSLです。
つまりDMDLファイル（「DMDLスクリプト」というのが公式な名称のようです）を読み込んで解釈するコンパイラーがあって、コンパイルされるとJavaのクラス（JavaBeans相当のモデルクラスや、インポーター・エクスポーターの抽象クラス）が生成されます。

---

では、DMDLがどんなものか見てみましょう。最小限の例は以下のようになります。

example = {
  value : INT;
  hoge : TEXT;
};

JSONぽい雰囲気で、どういうものか見ただけで直感的に分かると思います。
以下のように、もう少し色々指定することが出来ます。

//データモデルの例   ←コメント
"サンプル"   ←データモデルの説明
@directio.csv   ←データモデルの属性
example = {   ←データモデル名
  "値"   ←プロパティーの説明
  @directio.csv.field(name="value")   ←プロパティーの属性
  value : INT;   ←プロパティーの定義（プロパティー名およびデータ型）
};

「//」または「--」以降は行コメントになります。ブロックコメント「/*~*/」も使えます。
ダブルクォーテーションで囲むと「説明」になります。説明というより「タイトル」と言った方が近い気がします。いわゆる「日本語名」を定義します。
「@」から始まるものは「属性」です。Javaのアノテーションに似ているので、個人的にはついアノテーションと呼んでしまいますが＾＾；
属性を指定すると、モデルクラス以外のクラス（主にインポーター・エクスポーター関連のクラス）が生成されるようになります。
データモデル内の各データ定義のことは「プロパティー」と呼びます。

なお、データモデル名とプロパティー名には、英小文字と数字・アンダースコア「_」しか使えません。
Javaに変換される時に各単語の先頭は大文字・他は小文字に変換される（Javaの標準的なコーディング規約に則ったキャメルケースになる）ので、大文字を許すとプロパティー同士で重複する可能性が出てくる為と思われます。
日本語が使えてもいいんじゃないかなーと思ったこともありましたが、データモデル名はクラス名になるので、クラス名が日本語なのはWindows・UNIXの環境を行き来する運用を考えるとけっこう鬼門なので、やらない方が無難ではあります＾＾；

---

上記の例が、最も基本的な「レコードモデル」の定義方法です。

他にも「集計モデル」「結合モデル」がありますが、特別な演算子でのみ使用するものなので、後日改めて紹介します（たぶんｗ）。
（結合モデルの例はteppei_tosaさんがアドベントカレンダー10日目に書いて下さっています） 

もうひとつ、「射影モデル」というものがありますが、これは多相データフローでのみ使用するものなので、けっこう上級者にならないと使わないと思います。（自分は試したことがありません(爆)）

Flow DSL・インポーター・エクスポーター

Asakusa Framework Advent Calendar 2013の9日目です。
今日はFlow DSLについてです。

Flow DSLは「ジョブフロー」や「フロー部品」を定義するDSLです。
内容としては、「演算子」をどういう順序で呼び出すかを記述します。「演算子」は、個別の処理を行うサブルーチン（つまりJavaのメソッド）だと思えばいいでしょう。

例えばWordCountを行うアプリケーションのジョブフローのFlow DSLは以下のようになります。

WordCountOperatorFactory operators = new WordCountOperatorFactory();
Split split = operators.split(this.in);
Count count = operators.count(split.out);
this.out.add(count.out);

this.inはフロー全体の入力ファイル、this.outは出力ファイルを表しています。
operators.split()とoperators.count()が演算子です。Operator DSLを書くとFactoryクラスが生成されるので、それを使います。
split.outやcount.outは各演算子からの出力データを表しています。
出力データを次の演算子に渡してゆき、最終的に出力ファイルに渡すことでアプリケーションを構築します。
見た目の形式はメソッド呼び出しなので、普通のJavaプログラミングと比べてもそんなに違和感は無いかと思います。
（が、『Asakusa DSLの裏側』でも書いた通り、これらはAsakusaFWのコンパイル時に呼ばれるものであり、実行時には呼ばれません） 

---

冒頭にも書いた通り、Flow DSLではジョブフローとフロー部品の2種類が記述できます。

ジョブフローは入出力ファイルまで指定した、完成したアプリケーションです。
フロー部品は複数の演算子の呼び出しを1つにまとめたサブルーチンです。
表面上の違いは、入出力ファイルが定義されているかどうかです。

AsakusaFWでは、この入出力ファイルのことをインポーター・エクスポーターと言います。
ここまで普通に「ファイル」と呼んできましたが、これはいわゆる論理ファイルの事であり、実体としてはHDFS・Amazon S3上のファイルやローカルファイル、あるいはRDBのテーブルを扱うことも出来ます。

Flow DSLの範疇には含まれませんが、インポーター・エクスポーターを記述するクラスもあります。これもいわばDSLだと思いますが、DSL名は付いていないようです＾＾；
「インポーター記述」とか「エクスポーター記述」と呼ばれます。ImporterDescriptionやExporterDescriptionといったインターフェースを実装したクラスを作るので、普通のクラス定義そのものだからかもしれませんね。
インポーター記述やエクスポーター記述の基本部分が書かれたクラスは、DMDLから生成することが出来ます。DMDLはまた後日紹介したいと思います。

ちなみにどうでもいい話ですが、インポーター（Importer）とエクスポーター（Exporter）をまとめて呼ぶ言い方は何か無いですかね＾＾；
Xxporterとか書くのも違和感あるしorz