Alteryx EngineとAMPの主な違い

従来の Engine のアーキテクチャでは、主にシングルスレッド処理が可能で、データはレコードごとに連続して処理されていました。一方、新しい AMP コンセプトでは、大規模なマルチスレッド処理を可能にします。レコード処理は高速化のために 4 MB パケットで並列実行されます。そのため、出力レコードの順序に影響を与える場合があります。

改行を引用符で囲んだフィールドを含む CSV ファイルは、追加オプションAMP のみ: 引用符で囲まれたフィールドで改行を許可するを有効にしていない場合、失敗します。

ワークフローをAMP Engineで実行すると、いくつかのツールは従来のEngineと異なる順序でレコードを出力することがあります。次のようなツールがあります。

ワークフローで、上記のツールのレコードを下流のツールの作業のために特定の順序にする必要がある場合は、エンジン互換モード設定を使用して、従来のEngineと同じ並べ替え順序を維持できます。これは、主に従来のEngineで作成されたワークフローをAMP Engineで実行するために移行する場合など、特定のワークフローを慎重に検討した上で使用します。

AMP に変換されていない特定の機能または設定は、動作するために従来の Engine ツールに戻ります。したがって、AMP 変換ツールと変換ツール以外の両方のツールを含むワークフローは、AMP とシームレスに実行されます。

AMPに変換されたツールについて質問がある場合は、AMPでのツール使用を参照してください。

従来のEngineではツールのつながりが強く、下流に何もなければすぐに機能が停止します。AMP並列実行では、下流に何もなくてもツールが停止しない場合があります。下流に何もない場合、データストリームは処理されないというのが前提です。ログメッセージは、単なる情報の通知です。ストリーム内のレコード数が重要な場合は、テストツールを使用して、適切なレコード数が得られない場合にエラーメッセージを生成させることができます。

AMP Engine で書き込まれた YXDB ファイルは、従来の Engine で書き込まれた YXDB よりも高速に読み込まれます。従来の Engine で書き込まれた YXDB ファイルは、AMP が有効になっていると読み取り速度が遅くなります。ただ、これらの形式に互換性があることに変わりはありません。

AMP では、XLSX、CSV、YXDB、および SQLite ファイル形式を使用し、これらのファイル形式は、マルチスレッドの読み込みデータをサポートしています。

Zipファイルを読み込むときに、従来のEngineとAMPの間でレコードを変換してパッケージ化すると、パフォーマンスが低下します。これにより、AMPでは大きなZipファイルの読み取り速度が大幅に低下する可能性があります。

従来の Engine のパフォーマンスを向上させる (従来の Engine で作成された YXDB ファイルを AMP で書き込む) には、データ出力 - 構成 メニューに、Designer 18.1 以前のバージョンと互換性のある YXDB ファイルを作成するオプションがあります。

出力ツールは、従来のEngineとAMP EngineでCSVファイルを保存するとき、SpatialObjデータを含むレコードでの挙動が異なります。AMPはCSVファイルとして保存するときにSpatialObjデータをファイルに書き込みますが、従来のEngineは書き込みません。この違いによりファイルサイズに違いが生じ、パフォーマンスが低下する可能性があります。

必要な場合は回避策として、セレクトツールを介してレコードからこの空間データを削除することができます。これにより、両方のエンジンが同様の時間で完了します。

AMPを使用したツールごとのパフォーマンスプロファイリングは、Designerのバージョン2021.3以降で利用できます。

データは、AMP と R との間では従来の Engine の形式で渡されます。二重変換には時間がかかります。単一Rツールの実行時間は、従来のEngineよりもAMPの方が遅くなる可能性がありますが、複数のブランチが同時に実行される場合はより速くなります。

AMP は、下流のツールで処理したときにフィールドのサイズが不足するという問題に対処しました。結果のデータが元のデータ型の長さを超える場合に、データ型を変更するセレクトツールを追加する必要はありません。AMP は文字列と整数に最大サイズフィールドを作成し、以降の操作では、より大きな下流の値を保持するために必要な容量を保ちます。

スロットルツールは完全にはAMP用に変換されていませんが、ダウンロードツール  と一緒に使用できます。(スロットルツールを先に使用してください)

ファジーマッチは、従来のEngineとAMPでは異なる結果を出力する場合があります。AMPレコードは、別の方法を使用して照合されます。一致の順序が異なる場合があり、出力も順序が逆になる場合があります。ファジーマッチは、従来のEngineに比べてAMPでのパフォーマンスが低いという既知の問題があります。

AMPではUnicodeおよびPerlのエンコード標準が使用され、文字 $、 +、 <、 =、 >、 ^、 |、 ~ は句読点と見なされません。式関数REGEX_Replaceまたは正規表現ツールを使用して、正規表現セット[[:punct:]]で句読点をフィルタリングする際に、AMPを使用する場合は式を変更する必要があります。

従来のEngineを使用する結合アルゴリズムは、ソートマージ結合方式に基づいており、レコードは常に並び替えられた順序で実行されます。AMPを使用した新しい結合アルゴリズムはハッシュ結合方式に基づいているため、レコードは順序通りにはなりません。例:

左入力:

右入力:

従来のEngineと CustomerID で結合する場合、レコードの順序は CustomerID フィールドで並べ替えられます。

AMPでは、レコードは同じですが、順序は異なります。

結合出力並べ替え順序を設定する必要がある場合は、[結合]の後に[ソート]ツールを追加するか、[ワークフロー設定] > [ランタイム]で[AMP Engineを使用する]設定の下の[エンジン互換モード]設定を有効にします。

従来のEngineとAMPの違いは、マクロ内のツールがエラーを報告した際に表れます。シングルスレッドの場合、マクロでエラーが発生すると、従来のEngineは停止します。AMPは、反復出力が空になるまで、または最大反復回数が発生するまで機能します。実行された反復回数が多いため、次のような状況が発生する可能性があります。

フォーミュラ ツールの ConvertFromCodePage および ConvertToCodePage 関数は、文字列をパラメーターとして受け取り、結果として文字列を返すため、文字列がどのようにエンコードされているかは判別できません。これらの関数を従来のEngineとAMPで使用した場合、フォーミュラ ツールの出力が異なります。

入力データのバイナリ表現が異なるのは、UTF-8エンコード文字列のAMPでの内部処理の違いによるものです。異なるエンコードのデータをインポートすると、元のデータに戻す方法はありません。従来のEngineでは、バッファとして使用された文字列をLatin-1またはUTF-16でエンコードされた文字列として保存し、データを正しく元通りに変換できます。

フォーミュラアドインはAMPではサポートされていません。フォーミュラアドイン機能を含むワークフローを実行する必要がある場合は、従来の Engineを使用して実行してください。

マップツール を使用して、分析アプリの 空間参照 レイヤーから選択するアプリは、引き続き、従来のEngineを使用する必要があります。

従来のEngineでは、等しいことを検証(Expect Equal)ツールはCReWマクロのままです。AMPでは、ネイティブツールとして実行されます。

一部のワークフローは、ファイルから読み取った後、書き戻しを行います。これには、書き込みを開始する前に読み取りが完了したことを確認するために、シーケンスが必要です。同様に、1 つの XLSX ファイルに複数のシートを書き込むワークフローでは、シートを 1 つずつ書き込む必要があります。Alteryx Designer には、完了までブロック (BUD) ツールが用意されており、処理をフェーズに分けて、他の処理をお互いに邪魔しないようにすることができます。

E メールツールについても、前のブランチからの出力ファイルを添付ファイルとして受けて使用する場合、同じ回避策が適用可能です。データ処理が完了したら待つ必要があり、その後に E メールツールに添付ファイルとして追加します。

複数の分岐 (主に入力から出力に大別されるストリーム) を持つワークフローで作業する場合、入力ツール ID の番号が最も小さいワークフローの分岐に 完了までブロック ツールを配置します。これにより、後続のすべての分岐は、前の分岐が完了し、ツールが期待どおりに動作するまで実行を待機します。

特定のツール機能の詳細については、AMP でのツール使用 にアクセスしてください。