1

１．はじめに

２．基幹業務系バッチへ進化する Hadoop

３．バッチ向け Hadoop 開発環境について

４．高可用、高性能 Hadoop バッチ実行基盤製品

５．富士通 NetCOBOL の Hadoop 連携機能の実力は？

６．まとめ

要 旨

企業システムのオンライン系処理のアーキテクチャはスケールアップ主体の

アーキテクチャからステートレスを前提としたスケールアウトアーキテクチャ

に変わってきたが、その間、バッチ系処理のアーキテクチャは、ホスト時代か

らのCOBOLをベースとしたスケールアップ主体のアーキテクチャのままであり、

依然として企業システムの大きな課題として放置されている。

本稿では、近年ではHadoopが基幹業務系バッチ基盤として、開発環境、実行

基盤の視点から十分使える状況となっていることを紹介する。

さらに、既存COBOL資産をそのままHadoopによってスケールアウト可能なバッ

チ基盤へ移行させることが可能なNetCOBOLのHadoop連携機能について紹介する。

NRIではこのような技術を使い、今後、基幹業務系バッチのスケールアウト化

を自社SIやサービスとして提供していく予定である。

キーワード：スケールアウト可能な基幹バッチ、 Hadoop、 NetCOBOL、 Asakusa Framework、

Greenplum MR、 Infosphere BigInsights、 Interstage Big Data Parallel

Processing Server

※このレポートに記載された会社名、製品・サービス名はそれぞれ各社の商標もしくは

登録商標です。

2

1. はじめに

企業システムの基盤アーキテクチャがホスト

からクライアントサーバ、Web3階層、さらには

クラウドへと移り変わっていくにともなって、オ

ンライン系処理のアーキテクチャはスケール

アップ主体のアーキテクチャからステートレス

を前提としたスケールアウト主体のアーキテク

チャに変わってきている。

その間、バッチ系処理のアーキテクチャは、大

きな進化がなく、ホスト時代からのCOBOLをベー

スとした処理でスケールアップ構成を前提とし

ている物が多い。

しかし、その状況も昨今のHadoopの進化によ

り変わろうとしてきている。本稿では、Hadoop

の基幹業務系のバッチ基盤としての進化状況を

整理し、紹介する。

視点としては、アプリケーション開発基盤と、

バッチ実行基盤の２つの視点から整理、紹介する。

2. 基幹業務系バッチへ進化するHadoop

Hadoopは大規模データを分散処理するための

オープンソースのフレームワークである。当初

は分析(BI)系機能中心だったHadoopも、先行

ユーザによるHadoop利用経験のフィードバック

が順次サブプロジェクトとして取り込まれ、Ha

doopのエコシステムとして拡大してきている。

このような流れの中で、特に日本においては

バッチ基盤向けの機能拡張が行われている。

バッチ向けHadoop開発基盤としては、ノーチラ

ス・テクノロジーズのAsakusa Framework、富士

通NetCOBOLのHadoop拡張機能の２製品が有名で

ある。

ZooKeeper

Chukwa

HDFS

MapReduce HBase

Avro

HBase Hive Pig

操作性向上運用性向上

HDFSのデータをSQLライクな言語から利用する仕組み

ランダムアクセス/リアルタイムアクセスへの対応

分散協調サービスを簡単に作るための基盤を提供する。ZooKeeperはより汎用的な用途を想定している。

Hadoopが分散されたノードに生成するログファイルを集約し、解析するための仕組み

Hadoop内部で扱われるデータ操作（ソートや比較等）、分散ノード間のRPC通信の効率化のための仕組み

性能向上

バッチ向け機能拡張

Asakusa

業務バッチ用のフレームワークで、DSL（バッチ専用言語）からMapReduceプログラムを自動生成することでHadoopの知識が無くてもプログラミング可能

Hadoop連携NetCOBOL

従来のCOBOLプログラムをそのままHadoop上で動かす仕組みを提供する

分析（BI）系機能

高可用、高性能

独自ファイルシステム

MapReduceの高可用化

機能向上

図１：基幹業務系バッチへ向けた進化

3

一方、Hadoop実行基盤に目を向けると基幹系

のバッチ業務でも使えるような、高可用、高性

能を売りにしたHadoop製品が、メジャーベン

ダー中心に提供されてきており、基幹業務へのH

adoop適用が可能な状況となってきている。（図

１参照）

3. バッチ向けHadoop開発基盤について

Hadoopをバッチ処理で使う場合に最初に問題

となるのは開発生産性の低さである。

Hadoopのプログラミングモデルは汎用性が高

い半面、I/F（インタフェース）的には<Key, V

ale>のみで抽象度が高いため、業務ロジックを

記述する観点では敷居が高く開発生産性が下が

ることが多い。具体的には、業務ロジック以外

にHadoop特有の仕組み（Shuffle&Sort）を理解

し、キーのハッシュ関数を適切に選択するなど

の制御系を含めて考える必要があるが、バッチ

向けHadoop開発基盤はこれらを隠蔽し、よりビ

ジネスロジックに注力した開発を可能にし、開

発生産性を高めてくれる。

前述のノーチラス・テクノロジーズのAsakus

a Framework、富士通NetCOBOLのHadoop拡張機能

は、このようなバッチ向けHadoop開発基盤とし

て開発生産性を高めてくれるが、開発の前提な

どは大きく異なっている。

ノーチラス・テクノロジーズのAsakusa Fram

ework は、DSL(Domain Specific Language)を

使って、部品を組み合わせた開発を前提とし、M

apReduceプログラムを自動生成することでHado

opの知識がなくてもプログラミング可能として

くれる開発基盤となっている。このため、Hado

opの知識はなくてもいいが、Javaに加えてAsak

usa DSLの習得が必要となる。

比較ポイント Hadoop標準 AsakusaFramework

NetCOBOLHadoop連携機能

開発生産性 低い 高い 中程度

開発言語 Java Asakusa DSL(Javaベース)

COBOL

言語習得 Java Javaに加えAsakusaDSLが必要

COBOL

開発 I/F 低レベル<Key, Value> I/F

高レベルAsakusa提供の部品

中レベルCOBOLの通常I/F

業務適用性 汎用 Asakusa提供の部品依存

汎用

Hadoop知識の必要性 高い 低い 中程度

主な適用シーン 分析(BI)系 バッチ新規 バッチ既存（移行）

表１：バッチ向けHadoop開発基盤比較

4

一方、富士通のNetCOBOL Hadoop 連携機能は、

既存のCOBOLプログラムをそのまま動かすこと

を前提としているため、COBOLだけ理解していれ

ば、プログラミング開発的には使えるが、若干H

adoopの仕組みを理解した上で利用する必要が

ある。

このような特長があるため、前者は新規開発

において部品ベースで開発生産性を重視した開

発に適しており、後者は既存のCOBOLプログラム

を活用した既存バッチの移行に適している。

上記を通常のHadoop環境でのJavaの標準的な

開発手法との比較においてまとめると表１とな

る。

4. 高可用、高性能Hadoopバッチ実行基盤

製品

次に、Hadoopバッチ実行基盤の方を見てみる

と、当初、分析（BI）系の情報系中心での利用

だったため、それ程高可用、高性能についての

要求はなかったが、昨今その重要度がより増し

たり、より基幹業務系に使われたりするにつれ、

メジャーベンダーを中心に高可用、高性能を売

りにしたHadoopバッチ実行基盤製品が提供され

てきている。

従来のHadoop(Hadoop1.0系)での可用性の問

題点は、マスターノードが単一障害点となるこ

とであった。（図２参照）

この可用性の問題点を高可用、高性能Hadoop

バッチ実行基盤製品では、以下の方式で解消し

ている。

マスターノード スレーブノード

NameNode

JobTracker

DataNode

TaskTracker Task1

Task2

Block1

Block2

スレーブノード

DataNode

TaskTracker Task3

Task4

Block1

Block2

×

Task1

×

ブロックファイルは他ノードに複製済み（デフォルトで３重化）のため、障害時にはそちらで実行

Taskが失敗したらリト

ライ、それでも駄目な場合は他のノードでリトライ

← HeartBeat

← HeartBeat ×

×

データを保持する代替のスレーブノードが存在するため、稼働中のスレーブに処理が引き継がれる。

×メタデータ(位置情報）

単一障害点

・NameNodeのメタデータが失われる事によりHDFSが壊れる・JobTrackerの障害でジョブの管理情報が失われる。（再実行が必要）

×

図２：Hadoopでの可用性の問題点

5

(1) NameNode (HDFS) の単一障害点の解消

NameNodeはHadoopの分散ファイルシステム(H

DFS:Hadoop Distributed File System)のメタ

データ（位置情報など）を管理している。Name

Nodeが障害となった際に、管理するファイルシ

ステムのメタデータが失われてしまうため、HD

FSがファイルシステムとして壊れてしまいデー

タが全て失われてしまう。

それを防ぐために、HDFSのI/Fをそのままにし

て、それ以下を高可用、高性能の独自ファイル

システムに変更することで単一障害点を解消す

る。より具体的な構成イメージは、図３のよう

になる。

製品によって、独自ファイルシステムは異

なっているが、従来からHPC(High Performance

Computing)や、クラスターなどの分野で使われ

ていた実績のある分散(クラスター)ファイルシ

ステムが使われることが多い。また、さらに図

３から見て取れるように、従来のHDFSでは、HD

FSの下位にさらにOSのファイルシステムが存在

することに起因するオーバーヘッドが大きかっ

たが、この点が独自ファイルシステムに置き換

わることで直接ストレージへのアクセスとなり、

性能向上も図られている。

(2) JobTrackerの単一障害点の解消

JobTrackerとはHadoopのジョブ実行を管理す

るコンポーネントである。JobTrackerに障害が

起こるとJobTrackerが管理する実行待ちのジョ

ブキューがなくなってしまったり、実行中の

ジョブの応答が返ってこなかったりするため、

実行待ちのジョブを再実行する必要がある。

上記を解消するためにJobTrackerをクラスター

従来のHDFS

NameNode 、DataNodes

ストレージ

Hadoop アプリケーション

OS ファイルシステム

HDFS

ローカルDISK

HDFS I/F

HDFSの高可用、高性能化

ストレージ

Hadoop アプリケーション

高可用、高性能の独自ファイルシステム

ローカルDISK or SANストレージ

HDFS I/F HDFS I/F 以下の実装を置き換え

HPC等で実績のある分散ファイルシステム

図３：HDFSの高可用、性能対策

6

・・・

HDFS（分散ファイルシステム）

HDFS

Map

・・

並列処理 結果の集約（並列処理）

結果Map

Map

Reduce

Reduce

データ

データ

データ

データ

データ

データ

COBOLアプリ

COBOLアプリ

COBOLアプリ

COBOLアプリ

COBOLアプリ

自動分割

出所） NetCOBOL のHadoop連携の紹介資料にNRI加筆

図４：NetCOBOL Hadoop連携機能の概要

キーによる自動分割(Shuffle&Sort) Hadoopによる内部処理

比較ポイント Interstage Big Data Parallel Processing Server (Fujitsu)

Infosphere BigInsights(IBM)

Greenplum MR (EMC)

実装方式 Apache Hadoop 1.0 Apache Hadoop 1.0 MapR(Hadoop 1.0)

独自ファイルシステム P-DFS GPFS-FPO MapR-FS

外部ストレージ ETERNUS 無し or GPFS-FPO Cluster 無し

耐障害性(JT) JobTracker HA(1対1) JobTracker HA(1対1) JobTracker分散(1対N)

ツール（性能） なし なし あり

ツール（監視） なし あり あり

ツール（バックアップ） ETERNUSで代用 GPFS-FPOで代用 あり(+SnapShot機能)

ツール（その他） スマートセットアップログ収集コマンド

インストール、アップグレードツールログ収集コマンド

ローリングアップデート(手動)

高速化（M/R) なし Adaptive M/R Direct Shuffle&Sort

性能（HDFS1.0比） 2倍程度 2倍程度 2-5倍程度

表２：主要な高可用、高性能Hadoopバッチ実行基盤製品

化することで耐障害性を向上している。

上記の比較ポイントを主要な高可用、高性能H

adoopバッチ実行基盤製品で比較すると表２と

なる。

5. 富士通 NetCOBOLのHadoop連携機能の

実力は？

さて、冒頭に記載したようにバッチ系処理の

アーキテクチャは、大きな進化がなく、ホスト

時代からのCOBOLをベースとした処理でスケー

ルアップ構成を前提としている物が多い中、そ

の資産をそのまま使い、スケールアウト構成が

可能な技術として、富士通がHadoop連携機能を

付加したNotCOBOLを2012/12末にリリースして

7

図５：マスタ・トランザクションマッチングパターンの処理比較

出所） NetCOBOLの利用マニュアルにNRI加筆

いる。既存のCOBOLバッチ資産を抱えていても

アーキテクチャ的にスケールアウト構成を可能

とする注目の技術となっており、以下ではその

機能概要を紹介する。

(1) 機能概要

従来、HadoopでJava以外の開発言語を使う場

合には、Hadoop Streamingと呼ばれる技術を使

う必要があり、この制約により、ファイルへの

直接I/Fはできず、標準入力からデータを受け取

り、標準出力に結果を書きだす必要があった。

このため、COBOLバッチによくあるマスター、ト

ランザクションの付き合わせ処理なども計算ロ

ジックなどは流用できるが、ファイルの入出力

や制御ロジックはそれなりの書き直しが必要と

なっている。 NetCOBOLのHadoop連携機能では、

この違いをCOBOLランタイムの中で吸収してく

れるため、COBOLプログラムからは今までどおり

の通常のファイルI/Fも使え、既存COBOLプログ

ラムがそのまま動くようになっている。その概

要を示したのが図４である。

(2) COBOLバッチでの処理パターンとHadoop

移行概要

COBOLバッチで良く使われるファイルベース

の処理パターンは以下の３つに集約される。

① マスタ・トランザクションマッチングパ

ターン

8

② 単一レコードの集計パターン

③ 複数レコードの集計パターン

このそれぞれが具体的にNetCOBOL Hadoop

連携機能によりどのように移行可能かを順次

説明する。

① 最初のマスタ・トランザクションマッチン

グパターン（図５参照）は、マスタとトランザ

クションの特定のキー（この例では、商品ID）

で突き合わせて、レコードをマージする処理で

ある。従来環境では、その前処理として特定の

キー(商品ID)で予めマスタ、トランザクション

ファイルをソートしておく必要があり、その後C

OBOLバッチで突き合わせ処理を実行するという

作りであった。これがHadoop連携機能では、Ma

pタスクにおいて定義されたレコード定義ファ

イル（レコード長、キー位置）により自動実行

されるMapプログラムがキーをHadoopの内部処

理であるShuffle&Sortに渡し、結果として同一

のキー（商品ID）がソートされた形でReduceタ

スクに渡り、そこで従来のCOBOLバッチが動くよ

うになる。

ポイントは、従来環境で必要だった事前の

ファイルソート処理がHadoopの内部処理に移る

ため不要となり、高速化が図られる点がまず挙

げられる。次に、従来のCOBOLプログラムは、そ

のままReduceタスクで稼働が可能で、さらに

キーにより分割稼働しているため、容易に並行

処理が可能なことが挙げられる。

図６：単一レコードの集計パターン

出所） NetCOBOLの利用マニュアルにNRI加筆

9

より具体的には、データ量が増えて処理に

時間がかかるようになった場合には、Reduce

数を増やすことで、COBOLプログラムの並列度

が簡単に上げられ、プログラム自身は変更する

ことなく処理時間の短縮化が図れることにな

る。

② 二つ目の単一レコードの集計パターンは、

単一レコード内の項目間の集計をする処理であ

る。例えば、ある伝票明細の商品レコードの単

価と個数から売上を計算する処理を例にすると、

単純に１レコードからそのまま計算すればいい

だけであるので、Hadoopの内部処理であるShuf

fle&Sortすら通さずに、単純にそのままMapタス

クとして動かすことでHDFSで自動分割された単

位（ブロックサイズ）で並列処理が可能となる。

（図６参照）

この場合、データ量が増えたときには、その分H

DFSのブロック数が増えるため、自動的にMapタ

スクの数も増え、自動的にスケールアウトする

作りとなっている。

③ 最後に複数レコードの集計パターンであ

るが、①のマスタ・トランザクションマッチン

グパターンと同様に特定のキーで集約して計算

結果を求める処理である。従来環境では、その

前処理として特定のキーで予めソートしておく

必要があり、その後COBOLバッチで集計処理を実

行するという作りであった。これをHadoop適用

環境では、①と同様に定義されたレコード定義

ファイルからキーを判定し、Mapプログラムが自

動実行され、Hadoopの内部処理であるShuffle&

図７：複数レコードの集計パターン

出所） NetCOBOLの利用マニュアルにNRI加筆

10

Sortにデータを渡すことで同一のキーがソート

された形でReduceタスクに渡り、そこで従来のC

OBOLバッチが動くようになる。（図７参照）

ポイントは、①と同様にソート処理が不要と

なることによる高速化と、従来のCOBOLバッチを

そのままReduceタスクで動かせ、さらに容易に

並行処理が可能となることが挙げられる。

上記のNetCOBOLのHadoop連携機能による

COBOLプログラムの移行パターンを整理する

と表３になる。

このように従来のCOBOL資産であってもNetC

OBOLのHadoop連携機能を使うことで容易にス

ケールアウト構成が組める状況となってきてい

るのである。

6. まとめ

当初は分析(BI)系機能中心だったHadoopも、

近年では高可用、高性能のHadoop実行基盤製品

の登場とその上位のバッチ向けHadoop開発環境

が出そろってきていることで十分に基幹業務系

バッチ基盤として使える状況となってきている。

今回は、既存COBOL資産からのHadoopバッチ

移行にフォーカスを当てて紹介したが、新規

バッチ開発においては、ノーチラステクノロ

ジーのAsakusa Frameworkを利用することで同

様のスケールアウト可能な基幹業務系バッチ基

盤が構築可能となっている。

NRIでは今回紹介したHadoopによる基幹業務

系バッチ基盤を順次自社のSIの中で活用すると

同時に、外部向けのサービスとしての提供も含

めて進めている。

さらに、Hadoopのエコシステムに目を向ける

と、Cloudera社のImpalaに代表されるようなHa

doopをDWH(Data Warehouse)基盤として活用す

る技術、製品がリリースされている状況であり、

NRIではHadoop関連技術を引き続きSIやサービ

スで活用すべく技術調査、適用評価を進めてい

る。

# COBOLパターン キー＆ソート定義 Mapタスク Shuffle&sort Reduceタスク

1 マスタ・トランザクションマッチングパターン

マスタ、トランザクションに主キーとソート指定

定義により自動実行 定義によりシャッフル＆ソート

COBOLアプリ

2 単一レコードの集計パターン

主キーとソート指定 COBOLアプリ 実施しない 実施しない

3 複数レコードの集計パターン

主キーとソート指定 定義により自動実行 定義によりシャッフル＆ソート

COBOLアプリ

表３：COBOLプログラムの移行パターン