ASTERIA WARPをもっと便利に使いこなすためのtips紹介
•Als PPTX, PDF herunterladen•
0 gefällt mir•6,608 views
2017年8月8日名古屋での勉強会資料です。
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie ASTERIA WARPをもっと便利に使いこなすためのtips紹介
Ähnlich wie ASTERIA WARPをもっと便利に使いこなすためのtips紹介 (20)
Mehr von ASTERIA User Group
ASTERIA WARPをもっと便利に使いこなすためのtips紹介
- 1. インフォテリア株式会社 2017/08/08 ©1998-2017 Infoteria Corporation ASTERIA WARPをもっと便利に使いこ なすためのTips紹介
- 2. はじめに ASTERIA WARPのTipsは、ASTERIA WARPをご利用いただいている方に、 “もっとASTERIA WARPを利用してもらいたい！” という思いで、 ● こういう使い方できますよ（活用！） ● こんな使い方はだめですよ (-_-メ) など、ASTERIA WARPの効果的な使い方のTipsをまとめたものになります。 今後、ASTERIAをさらにご利用いただく上での参考にしていただければ幸いです！ ASTERIA WARP Tips集 担当 “TKY”
- 3. • 注意してください・・・ - TableDB（コード変換）関数に潜む罠・・・ - Start/EndResponseコンポーネントの罠・・・ • チューニングについて - サイジングのポイントは？ - パフォーマンス向上のポイントは？ - 並列処理ってどう？ 目次
- 6. 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 単位：ミリ秒 10,000レコード 1,000,000レコード カラム RecordGet Mapper Total RecordGet Mapper Total 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分
- 8. TableStream関数を利用した場合 単位：ミリ秒 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 ●注意点 ・タイミングによっては最新のデータを参照していないので、 その前提での利用をお願いします。 ・メモリ上に格納するのであまり大量データ利用はお勧めしません。 単位：ミリ秒 10,000レコード 1,000,000レコード カラム RecordGet Mapper Total RecordGet Mapper Total 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：平均40ms StreamPut：平均 30ms 処理時間：75分 処理時間：2分20秒 注意してください・・・ TableDB（コード変換）関数に潜む罠・・ TableDB関数 使う (1Fieldのみ変換) TableDB関数 使う (1Fieldのみ変換)
- 12. - サイジングのポイントは？ - パフォーマンス向上のポイントは？ - 並列処理ってどう？ チューニングについて ASTERIAを利用する際のチューニングポイントとなる点をご紹介します。
- 14. メモリ は？ 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 チューニングについて サイジングのポイントは？
- 18. 注意事項 ASTERIAのフローでは極力シンプルな処理をさせる →生産性が悪くなるので （1回の）処理件数はメモリ容量を考えて適切に設定する →想定外の対応をしておく ファイルI/OやDBとのトランザクション（通信）回数は なるべく少なく効率よく行う →パフォーマンス向上/ボトルネック回避 チューニングについて パフォーマンス向上のポイントは？
- 20. FlowService Achitecure チューニングについて 並列処理ってどう？ Trigger（Scheduler,Mail,HTTP,,,） FlowService Listener Request Queue Worker Thread Flow Parallel Request Queue Worker Thread Flow Worker Thread Flow Worker Thread Worker Thread Worker Thread Worker Thread Parallel SubFlow Parallel SubFlow Parallel SubFlow Parallel SubFlow Parallel Architecture SubFlow Request Queue Accepter FlowEngine （Normal/High Priority ） Parallelアーキテクチャ
- 24. 単位：ミリ秒 1スレッド処理 処理件数 1,000,000レコード 10,000,000レコード 100,000,000レコード 120,000,000レコード カラム数 Record Get Mapper RDBPut Total Record Get Mapper RDBPut Total Record Get Mapper RDBPut Total Record Get 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レコード カラム数 RecordGet Mapper＋ RDBPut Total RecordGet Mapper＋ RDBPut Total RecordGet Mapper＋ RDBPut Total RecordGet Mapper＋ 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 処理件数 処 理 時 間 （ ms ） スケールアップによってさらなる パフォーマンス向上を実現！ SPEC：Amazon EC2：Instance Type=m1.xlarge vCPUs=4 Memory=15GB OS=Windows Server 2012 DB＝Amazon RDS （Postgres9.3.3） ：Instance Type=db.m1.xlarge RecordSize＝500Byte/Record パフォーマンス比較 処理時間：216分 処理時間：101分 チューニングについて 並列処理ってどう？
- 25. 煩雑なデータ収集・分析業務の自動化を実現し、 パラレル処理機能によりデータのクレンジング やDWHへの高速LOADを実現。 各部門 経営層 Business Inteligence DWH RDB メインフレーム csv 業務システム データ入力 データ収集 データ統合 （クレンジング、マージ） 分析 分析 レポート配信 ExcelPDF ①DWHへの高速LOAD（ETL） 集計結果 25 FTPサーバやインターネットストレージの 大容量データのファイル転送を分割・圧縮・ パラレル処理機能で高速化。 高速Load ②ファイル転送の高速化 S3 RedShift 高速ファイル転送 ファイルを分割してGZIP圧縮 Upload データ収集 Web アクセスログ 購買履歴 EMR 分析 利用シーンは？ チューニングについて 並列処理ってどう？
- 28. ・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秒 チューニングについて 並列処理ってどう？
- 29. まとめ ASTERIAのフローでは極力シンプルな処理をさせる →生産性が悪くなるので （1回の）処理件数はメモリ容量を考えて適切に設定 する →想定外の対応をしておく ファイルI/OやDBとのトランザクション（通信）回数 はなるべく少なく効率よく行う →パフォーマンス向上/ボトルネック回避 29 是非、今後もASTERIAを有効活用ください！
- 30. Thank you. ©1998-2017 Infoteria Corporation