ユニケージ開発手法
ビッグデータ導入事例
有限会社ユニバーサル・シェル・プログラミング研究所
２０１３年２月© usp lab. 2013

Confidential Proprietary1ユニケージ開発手法によるビッグデータ処理の事例①バッチ処理の置換え （某クレジット会社）②複雑なＥＴＬ （某証券会社）③複雑なＥＴＬ （某電力会社）④大量データ検索 （韓国大手検索サイト）⑤まとめ© usp lab. 2013

Confidential Proprietary2

①バッチ処理の置換え （某クレジット会社）概要
ホストで、大量データの加工処理を実行しています。
この処理をユニケージへ移行します。
そのため、ホストから処理に必要な元データを受信し、ユニケージで一部の処理を作成し、比較を行っています。
ホスト
データベース

大量データ加工処理（＃１）

データベースアンロード処理

大量データ加工処理（＃３０）

フラット
フラットファイル
フラットファイル
ファイル

受信
大量データ加工処理の一部を比較の対象とします。

フラットファイル

Confidential Proprietary

大量データ比較
ユニケージサーバ

フラットファイル

フラットファイル

© usp lab. 2013

大量データ加工処理（＃５０）

フラットファイル

大量データ加工処理（＃３０）

フラットファイル

フラットファイル

3処理速度
処理時間がＣＯＢＯＬの８分の１になりました。（116.00/929.69=12.4%）
ユニケージは、ＰＣサーバ５台（ＣＰＵ６コアｘ２、メモリ４８ＧＢ）での測定結果です。
サーバの台数を増やして分散処理を行えば、さらなる高速化が可能です。

処理時間

COBOL

ユニケージ
（ＰＣサーバ １台）

ユニケージ（ＰＣサーバ ５台）

929.69分（15時間29分）

313.58分（5時間13分）

約116.00分（1時間56分）

PCサーバ １台

PCサーバ ５台

CPU 6コアx2
メモリ 48GB
HDD SATA(2TB)x2

CPU 6コアx2
メモリ 48GB
HDD SATA(2TB)x2（初期費用は100万未満）（保守費用も安価）（初期費用は500万未満）（保守費用も安価）

ホストハードウェア© usp lab. 2013

（初期費用は億単位）（保守費用も高額）

Confidential Proprietary4

開発生産性・ＣＯＢＯＬの場合・ユニケージの場合７ＪＯＢ、２４処理ありますので、コーディング： ５日３ヶ月程度かかると思われます。

動作検証： ５日

パフォーマンス改善 ： ３日・ユニケージエンジニア１名（経験５年）が合計１３日で開発しています。

© usp lab. 2013

COBOL

ユニケージ

処理の数

７JOB、２４処理

１１シェルスクリプト

開発期間

３ヶ月（想定）

１３日

ステップ数

３，６４５ステップ

９８１ステップ

Confidential Proprietary5

②複雑なＥＴＬ （某証券会社） 概要
ユニケージ開発手法を使って取引データ蓄積データベースにロードできるフォーマットの変換処理を行います。
処理時間について比較を行っています。
取引ログ

レコード種（約100種）

親

DBへのI/Fデータ

A

親子1

孫1−1

A

親子1

孫1−2

A

親子1

孫2−1子2

B

親子1

孫2−1

B

親子2

C

親子1子1
孫1−1

A

孫1−2

親子1

B

親子孫関係を解決したレイアウト子2
親子1子2子2C

実行速度Java+PostgresSQLで約90分の処理

階層的マルチレイアウトデータ© usp lab. 2013

Confidential Proprietary

6

処理速度
開発・実験環境
コンピュータオペレーティングシステム
シェルコマンド

デスクトップPC（Intel Core i7プロセッサ, メモリ16GB）
FreeBSD 9.0 Release#0
usp TUKUBAI ビジネスバージョン

アプリケーション

内容

PROCESS-MASTER

トップシェルPROCESS-001

例外処理18,327 件

8PROCESS-002

例外処理2

117,838 件

9PROCESS-003

例外処理381 件

11PROCESS-004

例外処理45,028 件

19

PROCESS-005

例外処理5332 件

14PROCESS-006

通常処理27,614,260 件

629,015,393件（4.36Gバイト）

96© usp lab. 2013

Confidential Proprietary

処理件数

実効ステップ数29

実行速度
real : 91.58sec
User : 132.85sec
sys : 22.53sec

7

③複雑なＥＴＬ （某電力会社） 概要
ホストデータのコード変換（ホスト形式→SJIS）を行います。
自動検針端末

メインフレーム

検針データ

検針データ
（ホスト形式）

UNIXサーバ

検針データ（ホスト形式）

コード変換処理（Java）

検針データ（SJIS）EBCDIK
ゾーン形式
パック形式
バイナリ形式漢字コード（外字有）比較

受信
現行処理では、ホスト形式のデータをSJISにコード変換しています。

ユニケージサーバ

この処理をユニケージへ移行します。

※入力ファイルと出力ファイルを確認し、ユニケージによる高速化を行います。

© usp lab. 2013

Confidential Proprietary

検針データ（ホスト形式）

コード変換処理（ユニケージ）

検針データ（SJIS）

8処理速度
２Ｇ、５Ｇ、１０Ｇの３種類のデータ量で計測を行いました。
使用したサーバは以下の通りです。
・Ｊａｖａ： HP-UX, Itanium 1.60GHz 2core, 4GB・ユニケージ ： FreeBSD, Core i7 4core, 16GB, SATA(2TB)

データ量

2GB（7,240,555件）

5GB（18,095,303件）

10GB（36,178,437件）

Ｊａｖａ

3時間7分53秒

7時間３０分
（想定値）

１５時間
（想定値）

ユニケージ

４３．４１１秒

１分４９．0８５秒

４分1６．９０６秒

差異

11273秒/43.411秒→259倍

27000秒/109.085秒→247倍

54000秒/256.906秒→210倍© usp lab. 2013

Confidential Proprietary9④大量データ検索 （韓国大手検索サイト）概要
大規模サイトの検索ログ分析
検索文字列・ユーザアクセス元IPアドレス等を軸に分析【構成】

想定データは1日約10.8GB x 365日 x 5年 = 19.2TB（5年で約500億件）（2,761万件）
フロント端末Webサーバ（振分け）シェルスクリプト＋Pompa

・・・

ユニケージサーバ群
0.5TB x 40台

スケールアウト© usp lab. 2013

Confidential Proprietary

10SQLとシェルプログラミング(1/2)
B3 : C_QUERY_NOSP, C_USER 毎の行数を数える
B4 : C_USER 毎の行数を数え、行数が30以上を出力
B5 : C_DATE と C_USER を条件に C_QUERY_NOSP を一覧
B6 : C_REQ_FRM 毎の行数を数え、行数の降順で出力B7 : C_CONNECTION 毎の行数を数える
B8 : C_DATEとC_CONNECTIONを条件に1行以上のC_QUERY_NOSP毎行数を数える
B9 : C_CONNECTION'X'のみの500以上C_QUERY_NOSP毎の行数を数える
B10 : C_QUERY_NOSP毎の3以上のC_SESSION1 のユニーク数を数える
B11 : 別の指定日にない C_QUERY_NOSP毎の行数を数える
B12 : 3以上の C_IP 毎の行数と C_QUERY_NOSPのユニーク数を数える© usp lab. 2013

Confidential Proprietary

11SQLとシェルプログラミング(2/2)
2.シェルプログラミングの例
シェルプログラミングとSQLの対応例です。
B3 【SQL】:
select C_QUERY_NOSP, C_USER, count(*)
from SEARCHLOG
where C_DATE='2006-09-18‘
group by C_QUERY_NOSP, C_USER;

B3 【USP】:
cat ${lv3d}/L3.DAY
awk '$4=="20060918"
self 23 16
dsort key=1/2
count 1 2B9 【SQL】:
select A.q1, A.cnt1 as a1, B.cnt2 as a2 from(select C_QUERY_NOSP as q1, count(*) as cnt1
from searchlog
where C_DATE='2006-09-18' and C_CONNECTION='X'
group by C_QUERY_NOSP having count(*)>500 ) A,
(select C_QUERY_NOSP as q2, count(*) as cnt2
from searchlog
where C_DATE='2006-09-18' and C_CONNECTION<>'X'
group by C_QUERY_NOSP) B
where A.q1=B.q2 order by a1 desc, a2 asc;

B9 【USP】:
cat ${lv3d}/L3.DAY
awk '$4=="20060918"&&$14!="X"'
self 23
dsort key=1count 1 1
cat ${lv3d}/L3.DAYawk '$4=="2006-09-18"&&$14=="X"'
self 23
dsort key=1
count 1 1
awk '$2>500'
join1 key=1 $tmp-b sort -k2,2nr -k3,3n© usp lab. 2013

Confidential Proprietary

|
|
|
|

|
|
|
|
> $tmp-b
|
|
|
|
|
|
|

12

処理速度
開発・実験環境
コンピュータデスクトップPC（Intel Core i7プロセッサ, メモリ16GB）

オペレーティングシステ
ム

FreeBSD 9.0 Release#0

ストレージ

SATAハードディスク１台

シェルコマンド

usp TUKUBAI ビジネスバージョン

対応SQL

実行時間(最小)実行時間(最大)実行時間(平均)

#01

B3

1.132

1.357

1.235

#02

B4

0.139

0.140

0.139

#03

B5

0.002

0.003

0.002

#04

B60.002

0.002

0.002

#05

B7

1.154

1.155

1.154

#06

B8

0.030

0.030

0.030

#07

B9

2.673

2.898

2.748

#08

B10

1.440

1.440

1.440

#09

B11

4.760

4.766

4.763

#10

B12

0.006

0.006

0.006

© usp lab. 2013

Confidential Proprietary

13

⑤まとめ
問題１ 【パフォーマンスの低下】
データ量の増加や度重なる業務ロジックの変更により、処理が徐々に遅くなり、業務に支障が出る。
問題２ 【コスト】
高速な専用ハードウェアや高機能なミドルウェアが必要となり、初期費用や維持費用が高い。

【問題の背景】
データの精度向上や過去データの蓄積が進み、データの件数が増えているがＲＤＢは大量データの扱いが得意ではない。

【一般的な対応】
最新の高速な専用ハードウェアや高機能なミドルウェアを導入する。
→パフォーマンスは改善されるが、その分コストが高い。
ソフトウェアを最新技術（Ｈａｄｏｏｐ等）で作り直す。
→高コストかつ、技術者の確保や育成が困難である。

© usp lab. 2013

Confidential Proprietary14

なぜユニケージは高速か？ 1/2① オーバーヘッドの大きいミドルウエアを組み込みません
DBやランタイムなどのミドルウェアを使わず、OSの基本機能のみを使います。この観点ではUNIX・Linux系ではFreeBSDがカーネルコードがコンパクトで、必要な周辺ソフトはPORTSコレクションから選定導入できなど、優れています。

② 高度にチューニングされたusp Tukubai コマンド群
シェルスクリプトで使用するコマンドを基本的にはC言語で自作し、直接メモリやCPUをコントロールします。SIMD命令をインラインで記述するなど、相当チューニングされています。そのレベルは、通常のjavaプログラマがつくるコマンドの数十倍のパフォーマンスがでます。（コンパイル後のアセンブラのコード量に圧倒的な差が出ます）③ パイプラインによる並列処理
シェルスクリプトはUNIX系の独自技術であるパイプを簡単に利用できます。パイプライン
で usp Tsukubai コマンドを接続することで並列処理が実現し、処理が高速化します。某証券会社の取引データ３０００万件の処理は、16 core マシンのサーバーを使って全CPU平均使用率を９５％にまで高め、従来スピードの６０倍になりました。

© usp lab. 2013

Confidential Proprietary15

なぜユニケージは高速か？ 2/2④ ush
シェルそのものもオーバーヘッドをなくすため、ush というash ベースの自作シェルを作成しています。同じシェルスクリプトでも標準的な bash の 1.7 倍のパフォーマンスを発揮します。ush は進歩を続けており、パイプの実装を、mmap （カーネルメモリ）に変更し、ID渡しに変更するなど、さらなるスピードアップを目指しています。

⑤ pompa
大量データの高速検索を行うために、テキストファイルのディレクトリーツリー分割とメモリ上のキャッシュコントロールを行なっています。(pompa technology)パス名に検索キーを埋め込み、OSとuspTsukubaiコマンドの２段階検索で高速検索を実現します。この技術により、１０テラバイトのログデータ（韓国大手検索サイト）の複雑な検索を、高価なアプライアンスを使うことなく、０．１秒レベルで実現しています。

© usp lab. 2013

Confidential Proprietary16