Asakusa Enterprise Batch Processing Framework for Hadoop

Asakusa ～ Enterprise Batch Framework for Hadoop Hadoop Japan Conference 2011/2/22

自己紹介
神林飛志
所属　ウルシステムズ ( 株 ) 　取締役
ソリューション事業部
基幹系業務処理専業
B2B ミドル・ SOA － TX 管理基盤の製品開発
販売・営業・コンサル・ SI ～なんでもやる
Hadoop での基幹処理とか、そんな感じで。

目的
Asakusa の目的
基幹バッチ処理を Hadoop 上で、開発・実行・運用すること
Hadoop 上で基幹を動かすことの狙い
バッチ処理時間の短縮
バッチ処理の短縮で何が可能になるのか？
① 今まで時間的な制約できなかった処理を何度も行うことができる
月次・週次での処理を日次で行える。可能であれば「即時処理」
シミュレーション・確定処理・クレンジング・引当・受発注・在庫管理・予測処理
② 時間的に処理が不能であったデータも処理をする
13 か月実績推定から 100 カ月超のデータも取り込む
データ種が異なるデータもまとめて処理にかける
③ 無駄な時間がなくなり、運用のコストが劇的に下がる
夜間バッチをなくして、運用監視の人的なコストを下げる

実際どんなものか？
基幹バッチ処理の例～一部抜粋
仕入データ取り込み残高更新照合処理仕入明細データ仕入返品データ費用振替データ売価変更データ出力データ中間 TRN 入力データ未払計上在庫計測仕入 TRN 在庫振替 TRN 在庫移動 TRN 未収収益 TRN 売価変更在庫変更 TRN 修正在庫振替 TRN 修正在庫移動 TRN 修正未収収益 TRN 未払計上 TRN 4 種類のデータ In 9 種類のデータ In 5 種類のデータ In 5 種類のデータ Out 4 種類のデータ Out 7 種類のデータ In 計上済仕入 TRN 計上済未収収益 TRN 計上済未払費用 TRN 更新済買掛残高 TRN 請求 TRN 支払不可消込 TRN 支払可消込 TRN 照合済未払費用 TRN 請求エラー TRN 照合済未収収益 TRN 照合済仕入 TRN 照合済請求 TRN

さらにブレイクダウンする
多層構造になっているのが普通
仕入データ取り込み仕入明細データ仕入返品データ費用振替データ売価変更データ仕入 TRN 在庫振替 TRN 在庫移動 TRN 未収収益 TRN 売価変更在庫変更 TRN 4 種類のデータ In 5 種類のデータ Out データ取り込みクレンジングデータ分割 Level-0 Level-1 Level-2 Level-3 階層が深くなるの普通大抵の規模で 4-5 階層データ整形日付チェックマスターチェック付随データ生成附番データ一次出力

基幹バッチの特徴
特に Hadoop がよく使われる BI 処理との比較でいうと・・・
① データの種類が多い。
4-5 種類は通常にある。多い時は 20-30 のデータ種を一気に処理することは普通にある。
中間データの生成も多い
フラグの違いだけといった同じようだが、微妙に違うデータ種類が混在する
・・・ generics の乱発とかしたくなって発狂する。
② 処理の組み合わせは単純
四則演算やパターンマッチング、フラグ判断が多い
条件分岐と演算が組み合わさることも多い
③ データフローが複雑
条件分岐・コントロールブレイク・ネスト処理
IF 文のネスト
条件にヒットした段階で処理を変更するフロー
④ 割と設計が重要
規模がおおきいので、設計の失敗は痛い

基幹バッチの特徴からみると・・・
基幹バッチで処理を行うには今の Hadoop には何が足らないのか？
Mapreduce 自体に不足はない
ないと言えば嘘になるが、万能の技術はないでの、うまく欠点を補う必要がある
HDFS ・ Mapreduce ・ Core は一体の技術
まずは生 Hadoop で基幹バッチを作ってみると・・・
自作 MapReduce
制限的なインターフェイスは仕方なし
謹製 Writable
HadoopIO はちょっと面倒
根性デバッグ
テストツール？自分でつくるのが基本ですね
シャーロックホームズな運用
Log の解析はぜひ Hadoop で。
ゴッドモードしかないメンテ
責任者出てこい！

Hadoop の何がたらないか？
基本的に BI を前提の仕組みなっているので、足りない部分が多い
そもそも大規模開発の手法がない
MR や Writable の実装が職人芸
テストツールが貧弱
運用についてはあまり考えていない
かように、ちょっと人数が増えると制御不能になるので Pig ・ Hive のような上位層の利用が必須になる。
ところが・・・ Hadoop では、基幹バッチでよく使われる「非常に多種類のデータ」の「単純な処理の組み合わせ」を「複雑なフロー処理」で行う仕組みのための上位層がない。 Pig ・ Hive ではちょっと無理っぽい。
また、開発方法論も特にない。テスト・運用ツールが不足している。

なので・・・
「もしかして、普通に
基幹バッチを書くと、
しねる？」
「ええ、もう完璧に」

そこで
屋形船が登場するわけです。
Powered by @kis まだ案ですが！

位置づけ
もう一つの Hadoop の上位層
Hadoop 　 Core Core ・ HDFS ・ MapReduce Pig Hive Asakusa Oozie MonkeyMagic ： Ruby ベース運用環境 MonkeyMagic は ( 株 )EC-ONE さんの製品でございます。

Asakusa の構成
DAG ベースの多層 DSL 構造
構造化を行う多層管理 DSL
ビルディングブロックの構成により処理フローの記述
トランザクション管理～ロールバック制御：すげー大事
開発方法論まで視野
MR コンパイラ
Ashigel コンパイラ
ステージングコンパイラ
運用スクリプトの生成
多層 DSL を最適な MapReduce プログラム群に生成する
ModelGenerator
データ層の自動化
Writable 自動生成と DSL への組み込み
テストとのインテグレーション
外部との一体統合
Import/Export
外部接続
便利系 API
上位の開発方法論から、実装フレームワーク・コンパイラ・データモデリング・テストツール・運用連携まで含む「フル・スタック」のフレームワーク

DAG ベースの多層 DSL 構造
構造化を行う多層管理 DSL
3 層の DSL
BatchDSL ・最上位のバッチを記述言語
FlowDSL ・バッチのビルディングブロックを記述する言語
OperatorDSL ・処理の最小単位を記述言語
ビルディングブロックの構成により処理フローの記述
フロー部品を構成的・多層的に構築する
Replace （可換性）の向上
変更への強化
再利用性の向上
見通しの良さと品質の確保
トランザクション管理～ロールバック制御
TX を DSL で指定することで、データを DB に保全する
必要に応じてロールバックする
単位は MR ではなく、その上位の業務の塊で処理する
データのリカバリー・配布に工夫
「 Hadoop 自体がぶっ壊れても、大ジョブだ、心配ない」

DAG の開発方法論と表裏一体
一連の非同期処理をどのように実装していくのか
プロセスの設計
DAG ベースでの詳細ブレークダウン
構造化手法の援用
STS 分割法
モジュール強度
SPF 演算子的考え方の利用
GRASP 原則の適用
凝集度（ Cohesion ）
結合度（ Coupling ）
データモデルの設計
静的なモデルを渡り歩くスタイル
TX データとマスターデータの設計
Join の設計が影響する
キーの扱いがポイントになるが、 No_SQL 系はキー付けの絶対性が低い
都度キーを生成する感じの「データモデルの変遷」になる

DSL
3 層構造の DSL
BatchDSL 最上のバッチフローを記述する FlowDSL ビルディングブロックの記述多層的な構成演算子 DSL データ操作の最小単位

DSL の記述例
バッチの記述例～ BatchDSL
とりあえず何も考えなくても書ける
フローの組み合わせを記述していく
バッチクラスを作成して内部で、下位の DSL で作成した job フローを連結して、記述する。

DSL の記述例
Flowpart の記述例～ FlowDSL
・・・・・・・・・・・・・・・・・・・・・・・・ @Override protected void describe() { // まずは明細と商品マスタを結合 Join join = op.join(itemIn, orderIn); // 結合に失敗したものはエラーフラグを立てて終了させておく SetStatus missing = op.setStatus(join.missed, " 商品不明 "); orderOut.add(missing.out); // 結合に成功したものは注文ごとに集計 Sum sum = op.sum(join.joined); // そのままでは使えないので、テーブルモデルに変換して出力 ToAmount result = op.toAmount(sum.out); resultOut.add(result.out); // 不要な出力を除去 core.stop(result.original); } フローを記述していく Java での記述 DAG の実装に近い頂点： Operator 辺：結線 Obj

DSL の記述例
Flowpart の記述例～ FlowDSL ・・・その 2
@Override protected void describe() { NewTxApMachingOperatorFactory f = new NewTxApMachingOperatorFactory(); UpdateTxOperatorFactory f1 = new UpdateTxOperatorFactory(); CoreOperatorFactory core = new CoreOperatorFactory(); // 伝票 No 設定未設定で振り分ける BranchSlipWithoutNo branch1 = f.branchSlipWithoutNo(inApMached); // 伝票 No 設定済に対して、前回までの突合結果区分より「計上ずれ」「不一致」とそれ以外を振り分ける BranchGapAndUnmatch branch2 = f.branchGapAndUnmatch(branch1.out2); // 伝票情報の初期化 InitSlipInfo update1 = f.initSlipInfo(branch2.out1); // 請求情報の初期化 InitBillInfo update2 = f.initBillInfo(branch2.out1); // 伝票 No 設定済で前回までの突合結果区分が「計上ずれ」「不一致」以外と請求情報初期化したファイルを一つにまとめる Confluent<TxApMaching> confuent1 = core.confluent(branch2.out2, update2.out); // 伝票情報が入っているデータに対して、支払消込トランから赤黒ペアの未照合を抜き出す GroupSortBranchDeficitSurplusDiv grs11 = f1.groupSortBranchDeficitSurplusDiv(confuent1.out); Operator 生成入力 edge Ope 固有処理出力 edge 出力 edge から入力結線出力 edge 二つから入力結線

DSL の記述
OperatorDSL
最下層 DSL
DAG でいうと頂点をにあたる部分の記述
Operator クラスを記述し、その Operator の処理メソッドを記述
アノテーションにより適切な挙動に制御を行い、 MapReduce へ展開する
/** * 注文商品の情報と明細を結合する。 * @param info 注文商品の情報 * @param order 明細 * @return 結合した結果 */ @MasterJoin public abstract JoinOrder join(ItemInfo info, OrderDetail order); /** * 明細の価格を、注文ごとに集計する。 * @param each それぞれの明細 * @return 集計した結果 */ @Summarize public abstract SumOrder sum(JoinOrder each); /** * 集計結果をテーブルモデルに変換する。 * @param total 変換対象 * @return 変換後 */ @Convert public OrderAmount toAmount(SumOrder total) { amount.setAmount(total.getAmount()); amount.setOrderId(total.getOrderId()); return amount; } Asakusa で準備されている演算子のアノテーションを利用して、演算子を記述する。演算子クラスの記述で必要な要件はアノテーションごとに異なる。間違うとコンパイラに怒られる。

DSL の記述
業務系の複雑な処理も演算子として記述可能
例は非等価結合の演算子を作ってみたケース
日付から有効なマスターデータを検索して、価格の結合するという処理
public abstract class ExampleOperator { /** * 有効なマスタを選択する。 * @param masters 選択対象のマスタデータ一覧 * @param tx トランザクションデータ * @return 実際に利用するマスタデータ、利用可能なものがない場合は null */ @MasterSelection public ItemMst selectItemMst(List<ItemMst> masters, HogeTrn tx) { for (ItemMst mst : masters) { if (mst.getStart() <= tx.getDate() && tx.getDate() <= mst.getEnd()) { return mst; } } return null; } /** * マスタの価格をトランザクションデータに設定する。 * @param master マスタデータ * @param tx 変更するトランザクションデータ */ @MasterJoinUpdate(selection = "selectItemMst") public void updateWithMaster( @Key(group = "id") ItemMst master, @Key(group = "itemId") HogeTrn tx) { tx.setPrice(master.getPrice()); } } 条件の記述結合の記述

Default で準備されている DSL データ編成 CoGroup グループ結合演算子 Confluent 合流演算子 Convert 変換演算子 Duplicate 複製演算子 GroupSort グループ整列演算子 Split 分割演算子業務系 MasterBranch マスタ分岐演算子 MasterCheck マスタ確認演算子 MasterJoin マスタ結合演算子 MasterJoinUpdate マスタつき更新演算子 Summarize 単純集計演算子フロー制御 Branch 分岐演算子 Checkpoint チェックポイント演算子 Empty 空演算子 Identity 恒等演算子 Logging ロギング演算子 Stop 停止演算子割と一般的な「アルゴリズム」や処理を実装している。ソート・マージ・分割業務系の演算子の実装拡張して業務フレームワークになっている「マスターとの突合」処理フロー制御のための演算子 DAG の記述をしていると発生する

MR コンパイラ
Ashigel コンパイラ
Made by @ashigeru
日本の若手ハッカーによる初の MapReduce コンパイラ
Pig ・ Hive と比べても遜色がない
というか基幹バッチのようなものであれば現時点これしか選択肢がない。
ステージングコンパイラ
DSL を順番にコンパイルする
演算子->フロー部品->バッチ->最適化
各レイヤーを部品化することで開発効率を上げる
多層 DSL を最適な MapReduce プログラム群に生成する
SI ・運用優先
普通に書くと増えてしまう Map ・ Reduce のタスクを統合する
最適化も行う～今も最適化中

Ashigel コンパイラ～構成図
データモデルと連動コンパイルで最適化わりといろんな黒魔術を使っています。（ by@ashigeru)

Asakusa の構成
Asakusa の実行時構成イメージ
最上位でのバッチ実行・監視 Job ネットが複数の job に展開される TRX 制御バウンダリー管理 HadoopJob の実行管理 Hadoop との IO 管理 MapReduce 実体 JarFile

TX 管理
TX のバウンダリーの管理
@JobFlow(name = "stock") public class StockJob extends FlowDescription { private In<Shipment> shipmentIn; private In<Stock> stockIn; private Out<Shipment> shipmentOut; private Out<Stock> stockOut; /** * コンストラクタ。 * @param shipmentIn 処理対象の注文情報 * @param stockIn 処理対象の在庫情報 * @param shipmentOut 処理結果の注文情報 * @param stockOut 処理結果の在庫情報 */ public StockJob( @Import(name = "shipment", description = ShipmentFromDb.class) In<Shipment> shipmentIn, @Import(name = "stock", description = StockFromDb.class) In<Stock> stockIn, @Export(name = "shipment", description = ShipmentToDb.class) Out<Shipment> shipmentOut, @Export(name = "stock", description = StockToDb.class) Out<Stock> stockOut) { this.shipmentIn = shipmentIn; this.stockIn = stockIn; this.shipmentOut = shipmentOut; this.stockOut = stockOut; } フロー部品の In と Out の結線を外につなぐことにより、外部での永続化をサポートする。この記述をフロー部品に組み込むことで、処理の外部接続と業務 TX のバウンダリー管理を行う

ModelGenerator
HadoopIO は結構面倒くさい
Writable を実装する必要がある
変に作るとバグ混入
「 ModelGenerator 」
Table ・ View をつくると自動的にクラスを生成
HadoopIO は意識しなくてもよい
作ったクラスは Eclipse で利用できるので、 DSL で操作できる
Table から Hadoop への展開は自動！
Hadoop から Table への戻しは自動！
要は、 SQL でアクセスできます。
普通に MySQL がつかえれば、いいわけです。
普通にアクセスできます。
画面とか、そのままいじらずに Hadoop にアクセスできるわけです。
データモデルについてもぬかりはありません・・・

こんな感じで sql ファイルをつくればおｋ
平易な記述でデータモデルを作成できる
CREATE TABLE ITEM_INFO ( -- Application columns CODE BIGINT NOT NULL , NAME VARCHAR (255) NOT NULL , PRICE INT NOT NULL ) type =InnoDB; CREATE TABLE ORDER_DETAIL ( -- System columns for BulkLoader SID BIGINT PRIMARY KEY AUTO_INCREMENT, VERSION_NO BIGINT NULL , RGST_DATETIME DATETIME NULL , UPDT_DATETIME DATETIME NULL , -- Application columns ORDER_ID BIGINT NOT NULL , ITEM_CODE BIGINT NOT NULL , STATUS VARCHAR (255) NULL ) type =InnoDB; CREATE VIEW JOIN_ORDER AS SELECT ORDER_ID, ITEM_CODE, PRICE FROM ORDER_DETAIL, ITEM_INFO WHERE ORDER_DETAIL.ITEM_CODE = ITEM_INFO.CODE; CREATE VIEW SUM_ORDER AS SELECT ORDER_ID, SUM (PRICE) AS AMOUNT FROM JOIN_ORDER GROUP BY ORDER_ID; 普通に TBL をつくるこっちは IO も一緒に書いてあるケース VIEW とかもできる View まで書くと演算子まで勝手につくる。

テスト
Test ツールの構成図

テスト
テストは結構大事
テストの記述 / 実行に注力したい
Asakusa では Junit でたたけるテストドライバーが提供される

テストモジュールは各 DSL 単位で自動生成される
モデル・ジェネレーターからはテストシートが自動生成される
データモデルの生成と同時にテストシートが生成
テスト内容を作成していく
作成したフロー部品単位やジョブフロー単位でのテストドライバーも自動生成される。
普通に JUnit から実行可能
FlowDSL のテストツール
BatchDSL FlowDSL OperatorDSL でそれぞれテストツールが提供されるすべて JUnit から実行可能

外部との一体連携
外部連携
特に外部リソースとの自動連携は仕組みとして準備している
一応デフォルトは Sqoop になっています
・・・一応、現在の Prj ではもっと高機能なやつ使ってます・・・・
高速データ展開
データの排他制御・セキュリティ管理とか
開発的には Hadoop は全く意識しない

運用
# workflow
jobnet("#{BATCH_ID_QUALIFIER}.tutorial", :instance_name => "master", :credential_name => "asakusa") do
boot_jobs("order")
# jobflow – order
jobnet("order", :to => []) do
auto_sequence
jobnet("__IMPORT__") do
boot_jobs("bulkloader")
jobnet("bulkloader") do
auto_sequence
job("bulkloader.asakusa", ""$ASAKUSA_HOME/"bulkloader/bin/importer.sh primary asakusa tutorial order "$($ASAKUSA_HOME/monkeymagic/bin/execution_id.sh)" 20380101000000 "#{BATCH_ARGUMENTS}"", :instance_name => "asakusa", :credential_name => "asakusa")
end
end
jobnet("__STAGE_GRAPH__") do
boot_jobs("stage0001")
# stage - tutorial / order / stage0001
hadoop_job_run("stage0001", "$ASAKUSA_HOME/monkeymagic/bin/hadoop_job_run.sh com.example.tutorial.batch.tutorial.order.stage0001.StageClient "$ASAKUSA_HOME/batchapps/tutorial/lib/jobflow-order.jar" -D "com.asakusafw.executionId=$($ASAKUSA_HOME/monkeymagic/bin/execution_id.sh)" -D "com.asakusafw.user=$USER" -D "com.asakusafw.batchArgs=#{BATCH_ARGUMENTS}"", :to => ["stage0002"]) do
hadoop_job("tutorial.order.stage0001")
end
# stage - tutorial / order / stage0002
hadoop_job_run(“stage0002”, “$ASAKUSA_HOME/monkeymagic/bin/hadoop_job_run.sh ・・・・・・・・・・・・・・
運用のためにスクリプトが生成される
Ashigel コンパイラから自動生成
下の例は、 MonkeyMagic 用の rb の生成

運用ツール
運用ツール
現時点ではデフォルトは、 MonkeyMagic
1. とりあえず実績～すでに Hadoop クラスターとか実証結構やっている
本番の基幹なので実績は大事
2. 動的な言語の特性を活かして、制御できるアイテムが割と自由
Ruby の特性を活かしている
3. クラウド用のライセンス体系
既存の体系に引きずられない
Asakusa 自体には experimental shell script を準備
拡張して、運用ツールと連携できる
OSS なので自分でスクリプト生成を書くことも可能
自分用の job コントロールスクリプトも作成可能
他の運用・監視用ツールとの連携も普通にできる

OSS 化について
とりあえず 3 月目標です
今、 Asakusa の実案件が 2/E の C/O です。
基幹系なので、半年間の段階リリース
次の Prj も仕掛中
割とマジです。
100 人 101 脚状態。
なので、なんとかまとめて C/O 後に Asakusa を公開します。
β 版利用したい人は募集中ですので連絡ください。

Asakusa で何がうれしいのかよくわからん
だいたい、説明速すぎだろ・・・
図が見づらいし・・・・
コードだされても・・・
そもそも 30 分で説明する気 Nothing だろ、これ・・・・
そんなあなたにポイントだけ

Hadoop つかって、よかですか？
俺 BI とかよく知らんし。
数学とかよくわからんし。
「さいゆうほう」って漢字かけないし
カーネル法って言われると普通にケンタッキーのおっさんが FA ですそれがなにか？

ようするに
そんなあなたも Hadoop
つかえます！

Asakusa で何がうれしいのか？
基幹バッチがほいほい書ける
というか、 Hadoop で一般業務向けの処理が書ける
誰でも書ける
アイデア勝負
なんと言っても「お金になる」
マーケットは確実に BI よりも大きい
BI ～ワンショットで 3000 千万とかそんな感じです。億単位はあんまりないです。
基幹系～億円以下はむしろない。
基幹系じゃなくても普通の業務系でも使える。
正直いうと BI でも使える。
BI も本当に複雑な処理は一部であとは、基幹系と同じだったりするので
そのあたりの煩雑な処理とか省ける。
テストも便利・パーツも追加回し前提。
クラウド時代で先行きどうなるの？->でも食える。割と各自に金になる
インフラ？
Amazon でいじゃね？他にいろいろあるし・・・
ソフト
Hadoop ＋ Asakusa ＝ OSS 。
ま～ <censored> とか要らんし。だいたいバッチだけなら <censored> より、はええし。

Asakusa のターゲット
使い方
① Hacker な人
中身をいじって、自分用に作り替える事も可能
ツールも作れる
コンパイラ拡張
DSL の独自設計・実装
外部連携の実装
② 業務屋の人
プロトを自分作れる
考え方を検証できる
③ SI 屋な人
大規模開発が可能
ツールとかがそろっているで、 Hadoop で大規模開発が可能
工数の見積もりもできる

技術屋の人であれば
とりあえず Asakusa を触ってみる
もっとすげーコンパイラとか書いてみる？
中身を見ますか？
-> Ashigel コンパイラの勉強会へどうぞ
2/25 開催。＠ EC-ONE
もっとおしゃれな DSL とか書いてみる？
Scala ？ JRuby ？
-> Asakusa Scala DSL の勉強会にどうぞ
3/10 開催。＠ EC-ONE
もっと中身が知りたいですか？
3 月に大規模な勉強会を実施予定
実装者のよる解説
Twitter で告知予定

Ashigel コンパイラの勉強会
Ashigel コンパイラの勉強会です。
http://atnd.org/events/12865
Ashigel コンパイラの開発者である、 @ashigeru さんにコンパイラの説明をしてもらい、 Ashigel コンパイラの中身を理解してしまおう、という勉強会です。
Ashigel コンパイラは何をしているのか～概要編
Ashigel コンパイラは何を入力にして、何を出力しているのか～詳細編
最適化
2-3 時間の内容でございます。
参加資格は特になしです。但し「遠慮無しレベル」での話で行く予定なので最低限 Hadoop とかは知っているかもしれないレベルは欲しいところです。
二次会もあるので、飲みましょう。 http://atnd.org/events/12866

Asakusa Scala DSL
Asakusa Scala DSL
@asami224 の浅海さんが、現在サンプルベースで、 Asakusa DSL の Scala 版をプロトタイピングで作成されています。
可能であれば、集まって、そのデザイン・レビューをしようという話になりました。 AsakusaDSL のサンプルコードも同時に見ながら、あるべき DSL 論について、議論をしようという勉強会です。
参加者には事前に、 Asakusa Scala DSL と実際の AsakusaDSL のサンプルコードも配布します。 Asakusa は OSS として公開されることが決まっています。公開と同時に ecoSystem 化を進めようという面白い試みにもなりますので、是非ご参加ください。
メイン討議者として @ashigeru さん荒川さん Ashigel コンパイラの作者で AsakusaDSL デザイナー @frsyuki さん　古橋さん　 msgPack ・ kumofs の作者 @masayah さん　 MS の萩原さん @shot6 　ショットたん
を予定しております。わりと適当に行く感じなので、そのつもりでぇえ～
二次会もやります。
http://atnd.org/events/13174

http://d.hatena.ne.jp	988
http://forza.cocolog-nifty.com	911
http://diary.overlasting.net	618
http://blog.restartr.com	291
http://webcache.googleusercontent.com	41
http://paper.li	41
https://p.yammer.com	8
http://storage.zetta.flab.fujitsu.co.jp	8
http://www.lab.nbgi.jp	7
http://kumano.zetta.flab.fujitsu.co.jp	5
http://drfrunk.tumblr.com	3
http://twitter.com	2
http://app.m-cocolog.jp	1

Asakusa Enterprise Batch Processing Framework for Hadoop

by okachimachi on Feb 22, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

13 Embeds 2,924

Statistics

Asakusa Enterprise Batch Processing Framework for Hadoop — Presentation Transcript