真也お初にお目にかかります稲本です。コンゴトモヨロシク......さて。4.0で追加された新機能『マルチストリームコンバータ』をご紹介します。機能ということで、その実力のほどを見ていきます。『マルチストリームコンバータ』とは何者か機能を適切に使うためには、まず何ができるのかを知らなければなりません。そこで、Studioヘルプから該当項を引用してみます。ソート処理は、Mapperとは別に、専用のコンポーネントが用意されています。Converter(マルチストリームコンバータ)という変換処理に特化した高速エンジン上で動作し、大容量データを扱うことに長けています。マルチコアCPU上では、リソースを有効に活用して並列で処理し、(従来のMapperと比較して)高速かつ省メモリで動作します。Converterの特性は、並列処理をサポートするコンポーネントとの組み合わせにおいて、最大の効果を発揮します。処理ごとに専用のUIが用意され、直感的に操作・設定が可能になっています。内容を要約すると、次の特徴が挙げられます。処理が速いメモリの使用を抑えられる大容量のデータを処理できるテーブルモデル型のみ処理できる直感的に使用できる(専用のUIによって)並列処理を行う(マルチコアCPUで効率が上がる)要約の感触としては、スクリプトの処理速度を向上させる手段として使わない手はないと言えます。良いことずくめな『マルチストリームコンバータ』ですが、やはり不得手もあります。そのような状況では既存のコンポーネントの出番となります。Studioヘルプの内容ですが、本稿の主題ではないためこちらは概略とします。※引用元がテーブル形式なので、原文を持ってこられませんでした。無念XML型データモデルのマッピング「Mapperロジック」の複合3点以上のデータ結合(「結合」コンポーネント)大文字/小文字の優先順位指定(「ソート」コンポーネント)これらの制限は検証にも影響するため留意しておきます。『マルチストリームコンバータ』の実力を計るでは、要約した特徴を基に、『マルチストリームコンバータ』の実力を試します。本稿では、スクリプトの処理速度向上の確認を主な目的として、次の通り検証します。『マルチストリームコンバータ』によってこれまでよりパフォーマンスが向上することを確認したいので、既存コンポーネントと追加コンポーネントの処理時間を比較します。『マルチストリームコンバータ』は並列処理によって効率的に動作するようですので、せっかくですからCPUコア数を増やして効果を確認しておきたいところ。決まりましたので、評価対象となるデータの取得方法を決めます。今回の検証ではコンポーネントの実行結果を取得できればよいので、追加コンポーネントから各処理1点ずつ、それに既存コンポーネントも合わせて用意した検証スクリプトを試行します。連携サーバのスケールごとに評価したいので、使用できるすべてのスケールで試行します。...マイログよりスクリプトの実行時間を取得する※スケールの仕様は本稿執筆時点のものです。検証スクリプトと入力データを準備します。検証スクリプトは、追加コンポーネントを含んだスクリプト3点と、追加コンポーネントと同等の処理を行う既存コンポーネントのロジックを含んだスクリプト3点、計6点を用意します。入力データは、特徴の一つである大容量データ処理を行わせたいので、ある程度の大容量データ(10万件程度)を2点用意します。検証用の入力データがないと検証スクリプトを組むことができません。検証に都合の良い条件として大容量で準備しやすいデータがあるとよいのですが、はてそんなデータどこに...なんて、あります、都合の良いデータ。本稿では入力データとして日本郵便株式会社が公開している郵便番号データを使います。全国の郵便番号が含まれていてそのデータ件数は10万件超。キーが重複したレコードもあり検証に最適です。なんとこのデータは著作権を気にする必要がありません。検証にあたり最も手間のかかるテストデータの準備があっという間に終わってしまいます。公開している郵便番号データです。『郵便番号データの説明』にある通り、このデータの利用にあたっては著作権が主張されないため、自由に使用できます。本稿の検証では『読み仮名データの促音・拗音を小書きで表記するもの』より『全国一括』データをダウンロードして使用しています。本稿執筆時点のデータでは12万4117件・約12MBの容量がありました。検証用の入力データとして2点用意しなければならないので、このデータを適当に分割して使用します。ソート」コンポーネントが使われているもの3点、「Mapper」「Merge」コンポーネントの「And-Integrate」「グループ化」「キーによるソート」ロジックが使われているもの3点のスクリプトを用意しました。「ソート」プロパティ追加コンポーネントは、それぞれ独立したコンポーネントであるためマッピング不要です。配線を考えることなく手軽に配置できます。「グループ化」ロジックでは出力形式がXML型になります。CSVアダプタはテーブルモデル型のみに対応していますので、XML型からテーブルモデル型への変換(テーブル化)を挟んでいます。『マルチストリームコンバータ』にいかんなく性能を発揮してもらうために、Studioヘルプを参考に次の点に留意してスクリプトを組みました。一連のプロセスを『並列処理をサポートするコンポーネント』で統一する「CSVファイル読み取り」コンポーネントで[並列処理設定を有効にする]追加コンポーネントは並列処理の適用により処理速度が向上します。一連のプロセスに並列処理を適用するためには、追加コンポーネントの入力元と出力先双方が並列処理に対応していなければなりません。そこで検証スクリプトでは、並列処理をサポートしているCSVアダプタを使用しています。「CSVファイル読み取り」コンポーネントは既定の動作では並列処理が適用されません。並列処理を適用するために、[並列処理設定]タブより[並列処理設定を有効にする]にチェックを入れました。コンポーネントの出力データは並び順が保証されない並列処理が適用されることで、追加コンポーネントが出力するデータは並び順がバラバラになります。コンポーネントの後に「ソート」コンポーネントを配置して改めてデータを並び替えなければなりません。準備が整ったところで、検証スクリプトを実行していきます。これまでに準備した検証スクリプト6点と入力データ2点を連携サーバにアップロードします。後でスケール別に結果を比較しますので、各スケール計3基の連携サーバにアップロードします。エクスプローラここからは地味にスクリプトを試行していきます。検証スクリプト6点×スケール3種の合計18パターン。結果として概算が取れれば充分ですので、試行回数は各1回とします。試行結果という訳で、試行結果は次の通りです。既存コンポーネントと比べておよそ4倍の速度が出ています。10万件のデータ2点のマージ結果としてかなり良い線行っているのではないでしょうか。スケールアップによる効果は、SmallからMediumについては速度比201%とvCPUの数の差がそのまま結果に出ているようですが、SmallからLargeについては速度比333%と少々物足りない結果になっています。単位:ミリ秒かなり顕著に性能差が出ました。Smallで170倍の速度です。ここまで差が出ると同等のロジックを再現できているか少々不安になりますが、出力データは一致していましたので実力です。スケールアップの効果も、SmallからMediumで速度比249%、SmallからLargeで速度比484%と、vCPUの数が綺麗に結果へ反映されています。単位:ミリ秒おっと、思いのほか差が出ませんでした。既存コンポーネントが優秀と言うべきでしょうか。多少想定外の結果となってしまいましたが、この現象は仕様によってある程度説明がつきそうです。ここまで触れてきませんでしたが、実は「ソート」コンポーネントは部分的に並列処理が適用されません。出力結果として指定の並び順を担保しなければならず、必然的に直列処理となるためです。これはStudioヘルプでも確認できる仕様で、『並列処理をサポートするコンポーネント』を読むと分かるようになっています。受け渡された入力データを複数のスレッドで並列に処理し、ソートを行います。(データのサイズやCPUのコア数によっては、中間データを一時ファイルに出力する場合があります。)順序を保証するため分割は行わず、ソートした結果を出力します。コンポーネントに比べ結果が振るわない一因と考えられます。このように、処理速度面では既存コンポーネントと変わりのない「ソート」コンポーネントですが、何気なく3つ以上のキーによるソートが可能(既存コンポーネントでは不可)となっており、利便性が向上しています。言え、既存コンポーネントに負けてはいられません。今後さらなる性能向上を目指す所存。スケールアップの効果については、SmallからMediumで速度比293%、SmallからLargeで速度比431%と、こちらは順当にvCPUの数が結果に反映されています。検証結果さて、本稿では、先に挙げたものの中から次の特徴を検証しました。処理が速い大容量のデータを処理できるテーブルモデル型のみ処理できる並列処理を行う(マルチコアCPUで効率が上がる)試行結果と評価より、「追加のコンポーネント」は「(既存コンポーネントと比べて)処理が速く」「大容量のデータを処理でき」「並列処理が行われている」ことが確認できました。ソート」、これまでパフォーマンスの問題などによりテンポラリDBを利用する機会も多かったこれらのデータ操作ですが、『マルチストリームコンバータ』によってテンポラリDBを経由しなくてもよくなるかもしれません。テンポラリDBを利用した処理との比較もいずれ試してみたいと考えています。本稿をお役立ていただけましたら幸いです。免責など●検証除外項目お気づきの方もいらっしゃるかと思いますが、本稿では次の特徴について、検証観点の違いや確認の難度などを理由に検証から除外しています。直感的に使用できる(専用のUIによって)メモリの使用を抑えられる●スケールアップオプション本稿では並列処理の効果を確認するためvCPUの増加に焦点を当てましたが、スケールアップによりvCPUの増加に加えてメモリ容量も増加します。データ量などの要因によりメモリ使用量が増減することで処理時間が変動することがあります。~Salesforceへ大容量のファイルをアップロード関連するキーワードSkyOnDemandTerraSkyBaseについてTerraSkyBaseはクラウドサービスを手掛ける株式会社テラスカイのコンテンツプラットフォームです。