asteria warpをもっと便利に使いこなすためのtips紹介

インフォテリア株式会社

2017/08/08

©1998-2017 Infoteria Corporation

ASTERIA WARPをもっと便利に使いこなすためのTips紹介

はじめに

ASTERIA WARPのTipsは、ASTERIA WARPをご利用いただいている方に、

“もっとASTERIA WARPを利用してもらいたい！”

という思いで、

● こういう使い方できますよ（活用！）

● こんな使い方はだめですよ (-_-メ)

など、ASTERIA WARPの効果的な使い方のTipsをまとめたものになります。

今後、ASTERIAをさらにご利用いただく上での参考にしていただければ幸いです！

ASTERIA WARP Tips集担当 “TKY”

• 注意してください・・・- TableDB（コード変換）関数に潜む罠・・・

- Start/EndResponseコンポーネントの罠・・・

• チューニングについて- サイジングのポイントは？

- パフォーマンス向上のポイントは？

- 並列処理ってどう？

目次

- TableDB（コード変換）関数に潜む罠・・・

- Start/EndResponseコンポーネントの罠・・・

注意してください・・・

ASTERIAで利用する機能の注意点をご紹介します。

TableDB関数

たとえば社内のコード変換用マスタテーブルを参照し、入力データを項目単位で変換します。


TableDB（コード変換）関数に潜む罠・・

よく利用するTableDB関数での注意すべき使い方を説明します。

便利ですよね〜

TableDB関数

でも・・・・これってSQLを度々なげているので

パフォーマンス悪いんじゃないの？実際ベンチとると・・・

注意してください・・・ TableDB（コード変換）関数に潜む罠・・

TableDB関数使わない

TableDB関数使う

(1Fieldのみ変換)

単位：ミリ秒 10,000レコード 1,000,000レコード

カラム RecordGet Mapper Total RecordGet Mapper Total

20

1回目 94 46238 46362 8457 4576079 4584613

2回目 78 45692 45801 8058 4589911 4598021

3回目 93 45177 45302 8112 4579001 4587167

4回目 78 45255 45364 7998 4529291 4537334

5回目 78 45270 45380 8287 4561102 4569440

平均 84 45526 45642 8182 4567077 4575315



20

1回目 109 32 1201 8395 2291 106471

2回目 109 18 1186 7878 1887 108421

3回目 110 31 1232 8346 1951 106767

4回目 109 15 1201 8799 1965 106081

5回目 109 15 1201 8176 1933 108232

平均 109 22 1204 8319 2005 107194

２０００倍遅くなる！１回のSQLで4.5ms！(-_-メ)

件数多いと使えない・・・回避策は？

処理時間：2秒

処理時間：75分

TableStreamコンポーネントあります！

まずStreamPutコンポーネントを使用して、

対象のテーブルレコードをメモリ上に格納します

MapperコンポーネントでTableStream関数を使用します


TableStream関数を利用した場合



20

1回目 94 46238 46362 8457 4576079 4584613

2回目 78 45692 45801 8058 4589911 4598021

3回目 93 45177 45302 8112 4579001 4587167

4回目 78 45255 45364 7998 4529291 4537334

5回目 78 45270 45380 8287 4561102 4569440

平均 84 45526 45642 8182 4567077 4575315

●注意点・タイミングによっては最新のデータを参照していないので、その前提での利用をお願いします。

・メモリ上に格納するのであまり大量データ利用はお勧めしません。



20

1回目 80 2013 2141 8551 141871 150802

2回目 60 2004 2114 8321 139012 148550

3回目 75 2019 2135 8190 140889 149880

4回目 82 2027 2145 8033 142229 151788

5回目 78 2025 2148 8281 139772 148801

平均 75 2017 2136 8275 140754 149964

まさかの約20倍以上のパフォーマンス向上！

RDBGet：平均40msStreamPut：平均30ms


処理時間：2分20秒


TableDB関数使う


TableDB関数使う


Startコンポーネント

初めから置いてありますよね。。でも大丈夫ですか・・・


Start/EndResponseコンポーネントの罠・・よく利用するStart/EndResponseコンポーネントでの

注意すべき使い方を説明します。

コンポーネント処理ごとにトランザクションが発生！ファイルのOpen/Closeでパフォーマンスのボトルネックに・・RDBの更新（commit）も同様・・・

トランザクション化：“はい”に設定してみてください。パフォーマンスが向上します！注）すべてのケースで向上するわけではありません

安心してください！

注意してください・・・ Start/EndResponseコンポーネントの罠・・

約8倍の差が

トランザクション＝“いいえ”

トランザクション＝“はい”

Startコンポーネントのトランザクション設定比較-ファイル出力でのパフォーマンス

EndResponseコンポーネント

普通に使いますよね。でも大丈夫ですか・・・

注意してください・・・ Start/EndResponseコンポーネントの罠・・

メモリ上にデータが溜まっていきます。。。

レスポンス（標準出力）を返さないでいい場合はEndコンポーネントを利用してください！

安心してください！

- サイジングのポイントは？

- パフォーマンス向上のポイントは？

- 並列処理ってどう？

チューニングについて

ASTERIAを利用する際のチューニングポイントとなる点をご紹介します。

サイジングはどうすれば？

-CPU

-メモリ

-HDD


サイジングのポイントは？

ASTERIAを導入する際のサイジングの基準について説明します。

CPUは？同時処理数（スレッド数）=Core数＊推奨

（Core数の目安）

Ex. フローが同時8処理の場合の目安

・物理環境

クアッドコア２CPU（8Core）以上を目安に

・仮想環境

ゲストOS割り当て8Core以上を目安に

（クロック周波数）

なるべく周波数が高いものを選択

Flow1

Flow2

Flow3

・・・・・・Flow8

同時処理数

メモリは？

ASTERIAサーバに割り当てる領域８GB以上（64bit環境）＊推奨

（メモリ使用量の目安）

Ex. RDBからデータを抽出・変換しファイル書き出し

Ex. CSVファイルからデータを抽出・変換しRDB書き出し

レコード件数データサイズメモリ使用量（10万件ループ）

100,000 50MB 1.0GB -

300,000 150MB 2.5GB 1.0GB

500,000 250MB 4.0GB 1.2GB

1,000,000 500MB 5.0GB 1.5GB

レコード件数データサイズメモリ使用量（10万件ループ）

100,000 50MB 0.7GB -

300,000 150MB 1.7GB 1.2GB

500,000 250MB 2.3GB 1.4GB

1,000,000 500MB 3.5GB 1.8GB

チューニングについてサイジングのポイントは？

ハードディスク容量は？

１TB以上＊推奨

そんなに必要？

フロー処理で出力するログをサーバ上に長期保管する、

もしくはログをデバックレベルで実行することを想定した容量になります。

よってインストールなどで必要な最低限の容量としては

10GB以上を目安としてください。

チューニングについてサイジングのポイントは？

大量レコードファイル読み込み

1億件のファイルを“FileGetコンポーネント”で読み込むのはNGです。。

OutofMemoryが発生・・・

“RecordGetコンポーネント”を利用ください。

メモリを考えると

一度の処理で10万件~30万件くらいがいいのでは・・


パフォーマンス向上のポイントは？フロー処理のパーフォーマンスを向上させる方法について

紹介します。

大量レコードDB書き込み

“RDBPutコンポーネント”でのバッチ処理件数で一度にRDBに

登録する件数を調整できますので、パフォーマンスを向上できます。

ただし、先ほどのデータを読み込む処理を前段階として考えると、一度の処理で10万件~30万件くらいの登録になります。

チューニングについてパフォーマンス向上のポイントは？

注意事項

ASTERIAのフローでは極力シンプルな処理をさせる

→生産性が悪くなるので

（1回の）処理件数はメモリ容量を考えて適切に設定する

→想定外の対応をしておく

ファイルI/OやDBとのトランザクション（通信）回数は

なるべく少なく効率よく行う

→パフォーマンス向上/ボトルネック回避

チューニングについてパフォーマンス向上のポイントは？

ParallelSubFlowは？

ASTERIAで1つのフロー内で並列処理を行うには

“ParallelSubFlow”機能を利用します。


並列処理ってどう？ASTERIAで利用できるパラレルサブフローの機能について

説明します。

ASTERIAでの並列処理の考え方について説明していきます。

FlowService Achitecure

チューニングについて並列処理ってどう？

Trigger（Scheduler,Mail,HTTP,,,）

FlowService

Listener

RequestQueue

Worker Thread

Flow ParallelRequestQueue

Worker Thread

Flow

Worker Thread

Flow

WorkerThread

WorkerThread

WorkerThread

WorkerThread

ParallelSubFlow

ParallelSubFlow

ParallelSubFlow

ParallelSubFlow

ParallelArchitecture

SubFlow

RequestQueue

Accepter

FlowEngine（Normal/High Priority ）

Parallelアーキテクチャ

SubFlowとParallelSubFlowの違い（ADNブログから）


サブフローの場合は、実行時に親フローとその親フローに含まれるすべてのサブフローが展開されて１つのスレッドで実行される。そのため、複数のサブフローやサブフローが繰り返し呼ばれる場合でもすべて直列に実行される。

パラレルサブフローの場合、親フローから呼ばれるサブフローは、すべて個別のスレッドとして実行されるため、繰り返し呼ばれるサブフローをパラレルサブフローとした場合、マルチコアCPU、マルチCPU環境などでは、処理の並列化によるスループットの向上が可能。

実行時のフローのQueuingと実行Thread （ADNブログから）

親と子を同じスレッドで処理する構成を取ってしまうと、同時実行数には限りがあるので、Dead Lock（親から呼ばれた子が待ち行列に入ってしまい、親がいつまでも終わらないなど）の発生が懸念される。

ASTERIAでは、そういう事態を避けるため、親フロー用のキューとスレッド、パラレルサブフロー用のキューとスレッドを別立てで構成している。これにより、パラレルサブフローの処理状況に影響されることなく他のフローの処理が継続できる。


ParallelSubFlowParallelSubFlowParallelSubFlow

フローデザイナーでのパラレル処理設計開発

CSVファイルからレコードデータを10万件単位で読み込みループさせることでDBへの書き込み処理を行うフローを並列で処理させる

MainFlowから渡されたレコードデータをDBへ書き込む

MainFlow ParallelSubFlow

すべての並列処理が終了後に次へ進む

ループ処理

ループ処理を設定（並列処理単位）

同時4スレッド


並列処理させたい部分をサブフロー化して利用！

単位：ミリ秒 1スレッド処理

処理件数 1,000,000レコード 10,000,000レコード 100,000,000レコード 120,000,000レコード

カラム数Record

GetMapper RDBPut Total

RecordGet

Mapper RDBPut TotalRecord

GetMapper RDBPut Total

RecordGet

Mapper RDBPut Total

20

1回目 8395 2291 95738 106471 91666 20139 963207 1075090 937198 193074 9583714 10714004 1116618 230886 11345934 12693877

2回目 7878 1887 98624 108421 93319 19846 964390 1077586 922921 199871 9612223 10735025 1123389 231102 11292302 12646810

3回目 8346 1951 96439 106767 91674 19546 962363 1073646 916668 192232 9599981 10708020 1198245 223876 12022456 13444591

4回目 8799 1965 95286 106081 92655 19987 963111 1075883 911445 193345 9627611 10732424 1099766 230073 11671823 13001679

5回目 8176 1933 98092 108232 91233 19532 963882 1074703 928766 194884 9617232 10740895 1128733 288731 11860542 13278026

平均 8319 2005 96836 107194 92109 19810 963391 1075382 923400 194681 9608152 10726074 1133350 240934 11638611 13012997

単位：ミリ秒４スレッド並列処理

処理件数 1,000,000レコード 10,000,000レコード 100,000,000レコード 120,000,000レコード

カラム数 RecordGetMapper＋RDBPut

Total RecordGetMapper＋RDBPut



Total

20

1回目 11622 31746 54803 168456 320405 501145 1649047 3336092 4996732 1980174 4072826 6065714

2回目 11404 27362 54554 160683 327413 503540 1679773 3384833 5077196 2013394 4010234 6035821

3回目 10873 32386 55272 166876 319876 498953 1665627 3290876 4969912 1976012 4139022 6127254

4回目 11023 30654 52718 165677 336541 514256 1633201 3398763 5043182 1998902 3998110 6009310

5回目 10976 31123 54901 160987 320921 495002 1676561 3302981 4992401 2018972 4092311 6123501

平均 11180 30654 54450 164536 325031 502579 1660842 3342709 5015885 1997491 4062501 6072320

・SubFlowベンチマーク

・ ParallelSubFlowベンチマーク

4スレッド並列処理で約2倍のパフォーマンス向上！

0

2000000

4000000

6000000

8000000

10000000

12000000

14000000

SubFlow

ParallelSubFlow

処理件数

処理時間（m

s

）

スケールアップによってさらなるパフォーマンス向上を実現！

SPEC：Amazon EC2：Instance Type=m1.xlarge vCPUs=4 Memory=15GBOS=Windows Server 2012DB＝Amazon RDS （Postgres9.3.3）：Instance Type=db.m1.xlargeRecordSize＝500Byte/Record

パフォーマンス比較




煩雑なデータ収集・分析業務の自動化を実現し、パラレル処理機能によりデータのクレンジングやDWHへの高速LOADを実現。

各部門経営層Business

Inteligence

DWH

RDB

メインフレームcsv

業務システム

データ入力

データ収集データ統合（クレンジング、マージ）

分析分析

レポート配信

ExcelPDF

①DWHへの高速LOAD（ETL）

集計結果

25

FTPサーバやインターネットストレージの大容量データのファイル転送を分割・圧縮・パラレル処理機能で高速化。

高速Load

②ファイル転送の高速化

S3 RedShift

高速ファイル転送

ファイルを分割してGZIP圧縮 Upload

データ収集

Webアクセスログ購買履歴

EMR分析

利用シーンは？


並列処理の注意点？

-DBの場合だとDB側のI/Oに影響するので、

それなりの並列処理が対応できるDBが必要。

ex.DWH（OracleExadata、Netezzaなど）

-ループする件数も注意が必要。

並列処理数分メモリを利用するので注意！

-１並列分で10万件〜３０万件あたりの

データ件数を推奨（1並列メモリ使用量１〜２G想定）


DBLoader使うとさらに速く！

DB側のLoaderをEXEコンポーネントで呼ぶと・・・

PureData（旧Netezza）の場合だと・・・ASTERIA WARPからEXEコンポーネントを利用しnzloadを起動することでアップロードデータを標準入力として直接渡すことが可能

ベンチは・・・・


・DBLoader経由

DBLoader使うとさらに速く！

ミリ秒 1,000,000 レコード 10,000,000 レコード

Component RecordGet Mapper RDBPut 合計 RecordGet Mapper RDBPut 合計

1回目 7035 4836 29375 41246 84401 40538 295076 420030

2回目 7427 4150 29794 41403 83415 42415 295401 421247

3回目 7582 4321 28751 40669 83493 40669 296587 420779

平均 7348 4436 29307 41106 83770 41207 295688 420685

ミリ秒 1,000,000 レコード 10,000,000 レコード

Component RecordGet EXE 合計 RecordGet EXE 合計

1回目 7722 14321 22074 83354 136672 221026

2回目 7672 12994 20998 83967 139041 224040

3回目 7274 12995 20800 82963 144986 225980

平均 7223 13437 21691 82761 140233 224015

・JDBCドライバ経由

約2倍のパフォーマンス向上！

ということは並列処理を一緒に使うと・・・さらに倍倍 (☝ ՞ਊ ՞)☝ｱｹﾞｱｹﾞ

処理時間：5分

処理時間：2分20秒


asteria warpをもっと便利に使いこなすためのtips紹介

Engineering