検索
連載

Hadoopの現実解「バッチ処理」の常識をAsakusaで体得：ビッグデータ処理の常識をJavaで身につける（7）（4/4 ページ）

Hadoopをはじめ、Java言語を使って構築されることが多い「ビッグデータ」処理のためのフレームワーク／ライブラリを紹介しながら、大量データを活用するための技術の常識を身に付けていく連載

[笹尾一夫，TIS株式会社] PC用表示 関連情報
Share
Tweet
LINE
Hatena
前のページへ | 　　　　　　

【7】ジョブフローの記述

　データフローのベースクラスであるFlowDescriptionを継承したJavaのクラスとして宣言します。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

【8】バッチの記述

　今回作成したジョブフローは1つなので、下記のように、「run(｛ジョブフロークラス｝).soon()」で、すぐに実行するように記述します。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

Tips

例えば、Job1の終了後、Job2を起動するような場合は、「run(Job2.class).after(job1)」のように記述します。図のようにJob1の終了後、Job2とJob3を並列で起動して、Job2とJob3の両方が終了した後、Job4を起動したい場合は、（例）のように記述します。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

（例）

アプリケーションのビルド

　さて、ようやく1本のバッチが完成しました。早速ビルドしてみましょう。アプリケーションのビルドは、pom.xmlを右クリックして[Run As］→［Maven package］を選択します。

　コマンドラインからビルドする場合は、プロジェクトのディレクトリ（pom.xmlがあるディレクトリ）に移動してから下記のMavenコマンドを実行します。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

　mvn packageを実行すると、テストコードをすべて実行されます。すべてのテストにパスすれば、プロジェクトのターゲットディレクトリにパッケージが作成されます。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

Tips

大量にテストコードがあり、テストの実行だけで数十分かかってしまうということもあるでしょう。ちょっと急いでいるので、テストはスキップしたいということもあると思います。そんな場合は、下記のコマンドで、テストをスキップしてパッケージを作成できます。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

ただし、あまり乱用しないようにしてください。「これぐらいの修正であれば、影響ないだろう」という妄信は、トラブルの元です。


バッチのデプロイと実行

　バッチのデプロイ先は、「$ASAKUSA_HOME/batchapps」です。デプロイは、ここにjarファイルを展開します。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

　デプロイが完了したら、「$ASAKUSA_HOME/batchapps」ディレクトリの下に、バッチIDのディレクトリが作成されます。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

　jarファイルを展開すると、テスト実行用のシェルスクリプト（experimental.sh）ができますが、このシェルスクリプトは、deprecated 予定なので、バッチの実行にはYAESSを使用することが推奨されます。YAESSを使ったバッチの実行は、「$ASAKUSA_HOME/batchapps」ディレクトリで「yaess-batch.sh」にバッチIDを引数に指定して起動します。

Tips

YAESSで実行するバッチに引数を渡したい場合は、yaess-batch.sh実行時に「 -A ｛変数名｝=｛値｝」のように指定します。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

※プログラムの中からバッチ引数の値を参照するには、コンテキストAPIを使用します。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***


新しい価値を生み出す「バッチ処理」の高速化

　現行で5分かかっている「バッチ処理」が1分になったところで、そんなにうれしいことはないでしょう。例えば、8時間かかるので月次でしか実行できない商品別販売数の集計バッチ処理が20分で終わるようになれば、日次で実行することも可能になるかもしれません。

　意思決定の周期が短くなれば、適宜、必要な商品を必要なだけ仕入れられるようになり、過剰在庫をかかえて腐らせてしまうこともありません。これは、一例でしかありませんが、皆さんがお使いになっているシステムや、お客さまに提供しているシステムでも「バッチ処理」が早く終われば、「機会損失が少なくなる」「もっとダイナミックな営業展開ができる」「いままであきらめていたことが、できるようになる」といったことがあるのではないかと思います。

　また、データ量の増大に伴い、「バッチ処理」が実行できる時間帯で、実行が終わらなくなりそうなので、「そろそろハードウェアを増強しないと」みたいな話もあると思います。高価で高性能なハードウェアを増強するよりも、コモディティなマシンで構成したHadoopクラスタで、長時間バッチの実行時間を短縮するという解決法も考えられます。

　とはいえ、自社でHadoopクラスタ構築、運用するというのも、若干、ハードルが高かったりもします。そんなに「たくさんのマシンを導入して管理しきれるのか」であるとか、「1台故障したときにどのように対処すればいいのだろう」であるとか、Hadoopクラスタを導入するのであればそれなりに検討しておかないといけないことがあります。

　最近では、AWS（Amazon Web Serves）などのパブリッククラウドを必要なときに必要な時間だけ借りて、並列分散で「バッチ処理」を行うような事例も発表されています。これなら、時間単位で使用した分だけ課金されるので、比較的少ないコストで、「バッチ処理の時間短縮することによる新しい価値」を得られます。本当に時間短縮できるのか、試験的にHadoopクラスタを使ってみるのにも適しています。

　「ビッグデータ」を安価な「クラウド環境」で高速に処理して「新しい価値」を得られるという、うれしい時代になってきたのです。

著者紹介

笹尾 一夫（ささお かずお）

ビッグデータの分析ツールの調査、検証に従事。本番業務システムにおいて300時間かかっていたバッチ処理をAsakusaFWで設計・実装し直し5時間弱に時間短縮可能であることを検証した。

TIS先端技術センターでは、採れたての検証成果や知見などをWebサイトで発信中


「次回」へ


「ビッグデータ処理の常識をJavaで身につける」バックナンバー

Copyright © ITmedia, Inc. All Rights Reserved.

前のページへ | 　　　　　　
ページトップに戻る