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

Asakusa Enterprise Batch Processing Framework for Hadoop

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Asakusa Enterprise Batch Processing Framework for Hadoop (20)

Asakusa Enterprise Batch Processing Framework for Hadoop