AlteryxのIn-DB機能の話

こんにちは、小澤です。

AlteryxにはIn-DBという機能があります。 今回は、この機能に関する話を書かせていだきます。

In-DBとは

Alteryxでは通常、実行している環境のメモリ上にデータを展開して処理していきます。 これは、ローカルにあるexcelやcsvファイルを読み込んだ場合のみに限る話ではなく、データベースなどを利用した場合においても同じです。

これに対して、データ量が多くなってくるとそれでは対応しきれなくなります。 Alteryx Desginerであれば、動かしている環境は通常、メモリは数GB~数十GB程度でしょう。 一方で大規模なデータになるとTB(テラバイト)以上のサイズになることもよくあります。

そのため、多くの複雑な処理をSQLで記述して、集約された結果をAlteryxのData Inputツールで受け取るなどの工夫が必要になってしまいます。 Alteryxでは、プログラムやSQLを記述せずにデータ分析が行えるのが利点ですが、これではそれが活かされません。

そういった時に利用できるのがIn-DBとなります。 この機能では、ローカルのAlteryxでデータを取得することなく、データベース上で処理を実行します。

これによって、通常のワークフローと同様のやりかたで処理内容を作成することができます。 その際、データベース上ではそれをどのように実現しているかを利用者は意識する必要はありません。

In-DBに対応したデータベース

さて、このように大規模なデータを扱う際に便利なIn-DBですが、どのようなデータベースを使っている際に利用可能なのでしょうか？

公式のHelpによると以下のデータベースに対応しているようです。

• Amazon Redshift
• Impala(*)
• Databricks
• EXASOL
• Hive
• HP Vertica
• IBM Netezza
• Microsoft Analytics Platform System
• Microsoft Azure SQL Database
• Microsoft Azure SQL Data Warehouse
• Microsoft SQL Server
• Oracle
• Pivotal Greenplum
• PostgreSQL
• SAP Hana
• Snowflake
• Spark
• Teradata

(*) HelpにはCloudera Impalaと記載されていますが2017/08/23現在、Apache Impala (incubating)となっています。

ほとんどの場合において、対応可能であることがわかります。 一般的に利用されるもので、あがっていないものはMySQL, Google BigQuery, Prestoあたりでしょうか？ これらを利用している際はご注意ください。

使ってみる

では、早速In-DBの使い方を見てみましょう。 今回利用するワークフローは以下のようになります。

なお、今回はOpenFligths Dataのairportsとroutesを利用しています。

これらを順に見ていきましょう。

データベースの指定と確認

最初に利用するデータを指定します。 これには、Connect In-DBツールを利用します。

Connect In-DBツールの設定は以下のようになっています。

接続先のデータベースと取得するSQLを記述しています。

接続先のデータベースに関しては右側の▼を押すと以下のような選択肢が現れます。

ここで「Manage Connections...」を選択すると詳細な設定画面移ります。

データソースの種類や接続に関する情報を入力します。 「Connection String」については、ODBCデータソースで登録してあるものであれば右側の▼で一覧から選択可能なのでこの書式を覚える必要はありません。

また、一度接続したことのあるデータベースであれば、接続先選択時に一覧に表示されます。

注意点として、通常のデータソースと、In-DBの接続先は別に管理されているようです。 In-DB用の接続先は Options > Advanced Options > Manage In-DB Connections　からも管理できますが、同じメニューにあるMnange Data Connectionsとは別物になっています。

この後は、通常のData Inputツールなどと同様のUIで入力のデータソースを選択してくことになります。

今回は、routes側のデータを読み込んでいます。 入力データの指定を変更したい場合は一番下にある「Query Builder」を選択することで同様の画面が表示されます。

ここで指定するデータは、Data Inputツールの時と挙動がことなり、実行時に取得されローカル環境に展開されるわけではありません。 In-DBではデータベース上で処理が完結するので、この段階で実行した結果はデータベース上にしか存在しません。

では、このデータを確認するにはどうすればいいのでしょうか？ それには、In-DB環境で利用できるBrowseツールである、Browse In-DBツールを利用します。

Browse In-DBツールでは通常のBrowseツールと異なる点として、データ取得件数とキャッシュの有無という2つの設定項目があります。

ローカルにあるデータを利用する

さて、続いてIn-DBを使いたいが一部のデータがローカルにあるという場合の対処法を見てみましょう。

通常通りInput Dataツールでファイルを読み込んだ後に、Data Stream Inツールを利用しています。

これによって、Alteryx上にあるデータをIn-DBで利用可能なデータベース上に置くことができます。 ツールの設定は以下のようになっています。

まずは接続先を選択します。 これは、Connect In-DBツールで指定したのと同じものを選択します。

Creation Modeでは、以下の3つが選べます。

項目	動作
Create Temporary Table	一時テーブルを作成してデータを保存する
Create new Table	テーブルを作成してデータを保存する
Overwrite Table	既存のテーブルを削除(Drop Table)して作成し直してから保存する

Creta Temporary Table以外を選んだ場合は、テーブル名もあわせて指定します。 今回は、airports側のデータをこの機能でデータベース上に保存しています。

なお、途中にあるSelectツールですが、今回のデータはヘッダ行がないため、列名をつけるのに利用しているのみとなります。

各種処理の実行

続いて、In-DB上ので各種処理を見ていきましょう。

まずは、Join In-DBツールです。

こちらは、In-DB上で実行するJoinツールとなります。 Join Fieldで指定したキーで結合するので動作としては通常のJoinツールとほぼ同様です。 Joinツール違いは

• 結合"しなかった"データの取得は行えない
• 出力のフィールド選択やフィールド名変更は行えない
• inner joinだけでなくleft/right outer joinやfull outer joinも選択可能

となっています。 これらは設定画面を見ていただければ、すぐにわかるかと思います。

left/right outer joinは通常のJoinツールにおいて、「J」の出力と「L」や「R」の出力をUnionしたもの、full outer joinは3つ全てをUnionしたものと同様の結果になります。

今回は、Join In-DBツールを2回利用して、routesにある出発地点、到着地点それぞれの空港情報(airports)を結びつけています。

続いて利用しているのは、Filter In-DBツールです。

こちらはFilterツールのIn-DBバージョンとなります。 設定は以下のようになっています。

こちらも、Basic Filterの使い方に関しては、通常のFilterツールと同様になっています。

Custom Filterを利用する場合は注意が必要です。 変数名を「[]」でくくらなかったり、文字列をダブルクオートではなく、シングルクオートでくくったりしています。 これは、SQLのwhere句のような書き方になると思っていただければと思います。 そのため、通常のFilterツールにあった関数の補完はなくなっており、利用するデータベース固有の関数などで同様の処理を実現することになります。 変数名の補完にかんしては、「Insert Field」とあるところから選択することで可能です。

今回は、ここで、出発地点の空港を日本のもののみに絞っています。

続いては、Select In-DBツールです。

こちらは、Descriptionの項目がない以外は通常のSelectツールと全く同じです。

続いてのFormula In-DBツールです。

こちらは通常のFormulaツールの古いバージョンと同様の設定画面になっています。

上側で変数と型の設定します。 変数名を入力すると新規作成、既存のものを選ぶと上書きとなります。

下側では、上側で選択中の変数のFormula式になります。 こちらは、Filterツールと同様、通常のFormula式ではなくSQLで使える関数などを利用しての記述となります。

今回はSQL Serverを利用しているので、二乗の計算にSQUARE関数を利用してたりします。

ここで計算しているのは出発地点と到着地点のkm単位での直線距離になります。 ただし、緯度経度の仕組み上これは正確な値ではないのでご注意ください。

一連の処理で最後に使っているのが、Write Data In-DBツールとなります。

これは、ここまで処理結果のデータをデータベース上に保存するためのツールになります。 設定は以下のようになっており、Data Stream Inツールと同様に保存先のテーブルを指定します。

処理の流れにおいて、保存する必要がなければこのツールの利用は必須ではありません。 保存しておいたデータを他のワークフローで使いたいといった場合や、BIツールはデータベースに直接接続するからデータベース上に保存したいといった場合に利用することになります。

データをローカルで取得する

このワークフロー最後の処理として、ここまでで生成されたデータをローカル環境で取得します。 集約やサンプリングを行ってローカルでも扱えるサイズになったデータに対してspatialや高度な分析を行うなどといった際に利用することになります。

これには、Data Stream Outツールを利用します。

このツールはすでに接続済みのデータベースからデータを取得するだけなので、細かい設定はありません。 必要に応じて取得の際にソートを行っておくことができますので設定はソートを行うかと、行う場合は基準のみを設定します。

このワークフローでは最後にBrowseツールを用いて、データの確認をしています。

このように、AlteryxのIn-DBと通常のツールはData Stream In/Outツールを介してシームレスにデータをやりとりすることが可能です。 そのため、

• ローカルでは扱いきれないビッグデータはIn-DBで処理を行う
• それによって集約やサンプリングされたデータに対する複雑な分析はローカルのAlteryx上で行う

といったことを1つのワークフローで実現することが可能となっています。

In-DBを使う上での注意点

さて、最後にIn-DBを利用する際の注意点について補足しておきます。

In-DBでは、データベース上で処理を実行します。 そのため、負荷がかかるのはデータベース側となります。 データ分析用途で利用していて普段から誰かが分析してる際は高負荷といった環境であればいいのですが、アプリケーション側が本番運用しているものと同じ環境に接続するなどといったことは行わないように注意する必要があります。

また、Data Stream In/OutツールではAlteryxとデータベース間での通信が発生します。 ここで大量のデータをやりとりするとその部分が処理時間のボトルネックになったり、ネットワークの帯域を占拠したりといったことも起こりえます。 Data Stream Outツールではローカルでは扱いきれない大量のデータを取得してしまうようなワークフローになっているとその後の処理も継続できないといった問題も発生しうるのでご注意ください。

終わりに

今回は、AlteryxのIn-DB関係のツールを紹介しました。 これらのツールを利用することで、通常と同じ感覚でデータベースを利用した大規模なデータの分析も実現可能となります。

また、今回は紹介しませんでしたが実は一部のPredictive系ツールはIn-DBでそのまま利用可能となっています。 今後、それらの使い方も紹介できればと思います。

Alteryxに興味をお持ちいただいた方はこちらからお問い合わせください。