株式会社アプレッソ開発部 開発グループ第2チーム リーダー

土岐 拓未

2014年4月17日 dstnHUB

自己紹介

• 名前– 土岐 拓未 (とき たくみ)

• 所属– 株式会社アプレッソ 開発部

• 開発グループ 第2グループリーダー

• 担当業務– PIMSYNC、その他新製品開発

• dstn担当– 連載記事の執筆・管理

• 神尾みかさんのDS自由自在• DataSpiderデザインパターンβ• DataSpider Cookbook• dstn インタビュー

– パワポ絵職人

神尾みかさん

本日のテーマ

DataSpiderはなぜ高速なのか？

Part.1 アーキテクチャ編Part.2 テクニカル編

1. スクリプトのコンパイラ型実行

2. PSP&スマートコンパイラによる大容量処理高速化

3. 各コンポーネントのパフォーマンス最適化実装

DataSpiderの高速処理を支える3つの技術

1. スクリプトのコンパイラ型実行

Servista 2～コンパイラ型実行形式

DataSpider 1.x インタプリタ型実行形式

どのようにスクリプトは実行されるか？

スクリプト作成・保存時

Studioでのスクリプト作成・保存

XML形式・設定情報・位置情報・フロー設定・変数設定など

設定ファイル(.script)

保存

開く

スクリプトの各種設定情報は「.script」ファイルに保存

設定ファイル

インタプリタ型実行形式

各コンポ―ネントの処理

ループによる繰り返し

Ifアイコンによる条件分岐

データ変換処理

JavaVM

実行

インタプリタによる変換インタプリタによる変換インタプリタによる変換

インタプリタによる変換

実行

実行

実行

インタプリタ

インタプリタ型実行形式のパフォーマンス上の問題点

1. インタプリタによる変換が逐次行われる

2. ループ、条件分岐自体も処理が必要となりコストがかかる

3. Javaコンパイラ、JVMによる最適化がされにくい

XML形式・設定情報・位置情報・フロー設定・変数設定など

設定ファイル(.script)

Javaソースコード・メソッド・変数・制御・その他処理

.javaファイル

classファイル

.classファイル

生成 コンパイル

Servista 2～スクリプト保存時

Javaソースコード・メソッド・変数・制御・その他処理

….for (process_d00000fg3ml1i0i8gmg3mo2igdgf() ; .....

if (evaluate_u80000fg3ml1i0i8gm9vb8megdge()) {

process_oi0000fg3ml1i0i8gm7vls1igdge();} else if

(evaluate_sk0000fg3ml1i0i8gme1hq00gdgf()) {….

} ….}….

if・forアイコンなどのアイコンはそのままJavaのif文・for文に変換

手組みのJavaアプリケーションと同等のパフォーマンス

Servista 2～コンパイラ型実行形式

classファイル

実行

classファイル JavaVM

コンパイル型実行形式のパフォーマンス上の長所

1. インタプリタ変換が不要2. ループ、条件分岐はfor文・if

文になり処理コストが大幅減少

3. Javaコンパイラ、JVMによる

最適化の恩恵を最大限に享受できる

DSS 2.0DS 1.5 vsループ、分岐処理の処理速度比較データ

100万件のデータを繰り返し・分岐させた合計値

繰り返し(LOOP) 分岐（IF)

DS1.5 6分7秒 5分16秒

DSS 2.0 0.8秒 0.9秒

繰り返し・分岐処理の処理コストは極限まで減少

2. PSP/スマートコンパイラによる大容量処理高速化

Parallel Stream Processing(PSP)とは

メモリ消費を抑えながら大容量データを高速に処理する機構

• 読み取り、変換、書き込みの処理を並列に実行する→高速な処理が可能

• メモリに保持するのは一定のサイズのデータのみ→メモリを使い過ぎることなくデータ処理が可能

通常フローの実行イメージ

変換

読み取り

書き込み

中間データ

中間データ

処理ごとにすべてのデータをメモリ(※)

に保持(※)大容量データ処

理がオンの場合はファイルに保持

総実行時間はすべての処理の合計時間となる

PSPフローの実行イメージ

変換

読み取り

書き込み

中間データ

中間データ

中間データ

中間データ

中間データ

中間データ

総実行時間はすべての処理の合計時間より短く

なる

一定単位(1000件)ごとにデータを渡し、メモリ負荷を軽減

デモで実験！

PSP モニターアダプタ

読み取り・変換・書き込みのデータ処理状況を監視するデモ用アダプタ&Webアプリケーション

読み取り～変換間の中間データ件数

読み取り処理件数

変換処理件数

変換～書き込み間の中間データ処理件数

書き込み処理件数

デモシナリオ

• 10000件のデータ

– PSPオフ

– PSPオン

• 読み取りが遅い場合

• 変換が遅い場合

• 書き込みが遅い場合

実験結果

• 1000件以上のデータでは並列で処理が実行されるため総実行時間は短くなる

• 次の処理に必要なデータのみメモリに保持する(一定量以上のデータを保持しない)ため、少ないメモリで処理が可能

大容量データの高速・低メモリ負荷の処理を実現

スマートコンパイラ

DataSpider 3.0以前PSPスクリプト形式

通常

スクリプト

PSP

スクリプト

「PSPスクリプト」を作り、通常スクリプトから呼び出す

スクリプト呼び出し

デメリット• PSPを使うことを意識してスクリプトを作る必要がある• 別スクリプトになるため、スクリプト内の一覧性に欠ける

Servista 3.1スマートコンパイラ

メリット• PSP処理を意識することなく、高速・低メ

モリ負荷のスクリプトを作成可能• スクリプト内でPSP処理が可能であるた

め、スクリプトの一覧性がアップ

PSP実行可能な処理を自動的にPSP化！

PSPで実行可能な形式、コンポーネントはヘルプを参照ください

製品コンポーネントでのパフォーマンスやPSPを活かすスクリプトの作り方は

Part.2 テクニカル編で！

3. 各コンポーネントのパフォーマンス最適化実装

コンポーネント 概要 詳細

XML Framework プリミティブ型で値を扱うように実装

高速・低メモリ負荷の処理を実現

アダプタ全般 リソースプーリングによるコネクションキャッシュ

コネクションのオープン/クローズ回数を減少

データベースアダプタ 書き込み処理のBatch実行大量データをまとめて書き込むことでDB書き込みのパフォーマンスを上げる

データベースアダプタ PreparedStatementの使用SQL実行の処理性能を向上

CSVアダプタ CSV読み取りに最適化したファイルI/O処理実装

PushbackReaderの独自実装

Mapper 処理による実行エンジンの切り替え

複雑な処理、単純な処理でエンジンを切り替えて高速化

・・・

さまざまなコンポーネントで行われているパフォーマンス最適化実装

ケース1 CSVアダプタCSV読み取りに最適化したファイルI/O処理実装

• java.io.PushbackReader

→ 読み取った文字を戻すことができるReader

– 任意のバッファサイズを指定できる

– スレッドセーフにするための同期処理を実装

汎用的なクラスであるため、CSV読み取りでは不要な処理が多い

• CSV読み取り専用PushbackReader

→ CSV読み取りに特化したシンプルな設計で実装

– バッファサイズは1のみ

– スレッドセーフである必要がないため、同期処理は排除

読み取りパフォーマンスが1.3～1.5倍に

ケース2 Mapper処理による実行エンジンの切り替え

• マッピング内容によって実行エンジンの切り替えを行う

読み取り処理 書き込み処理

SimpleInputConverter

ExpressionInputConverter

XML2XMLConverter

テーブルモデル型同士で単純な繰り返し、ロジック無し、文字列型のみの場合

テーブルモデル型同士の場合

XML型の場合

可能な限り実行パフォーマンスが高い実行エンジンを使うことで最適化

さらなる高速化を目指して今後も改善し続けていきます！

ご静聴ありがとうございました。