その他お問い合わせ先

lodestar@truestar.co.jp

運営会社

株式会社truestar
truestar activation株式会社

Tableauの機能拡張

完全に受け売りネタです。

いつも参考にさせていただいているDevelopers.IOにて、先週ラスベガスで開催されたTableau Conferenceの内容が早くも共有されています。

Developers.IO – Tableau Conference 2015 at Las Vegas [基調講演レポート] Keynote: Christian Chabot and Chris Stolte

今後の機能拡張に関する記載が多数ありますが、直近に私が投稿した内容と関連するものもありましたので、私の雑感をまとめてみます。

 

◆Data

・Union ⇒先日の投稿『Alteryxでデータの一括結合』で取り上げたばかりの内容がTableauでできるようになるようです。 集積されているデータ量が膨大な場合などは引き続きTableau外で処理した方が良いかもしれませんが、使用頻度は高くなりそうです。

・Cross Database Join ⇒これまでは、同じフォルダのCSVとか同じエクセルのシート間でしかできませんでした。これも期待大です。

 

◆Visualization

・Global Post Code ⇒郵便番号をデータソースに持っておく必要がありますが、郵便番号から色塗りマップが使えるようになるそうです。 GPSなどから取得する緯度経度データを適用させる場合、緯度経度データを郵便番号に紐付ける必要があります。これは近日中にAlteryxで実装して投稿しようと考えています。

・Custom Territories ⇒これは便利です。エリアの管理区分(例えば関東に山梨や新潟を含めるか、とか)は組織によって異なりますので、カスタマイズできると使いやすいですね。

・Spatial Data ⇒シェープファイルが読めるようになります!

上の3つは空間情報処理系の機能拡張になる訳ですが、現状では以下のような課題もありますので、それらも改善されることを期待したいところです。

課題①ポリゴンデータはプライマリーデータソースになる ⇒こうなると可視化上の制約が大きくなります。ポリゴンはあくまでバックグラウンド情報であり、そこに落とし込むデータの表現が重要な訳なので、ポリゴンはセカンダリか、専用のデータソース的に持てると良いのですが。

課題②1つのビューの中で複数フィールドの緯度経度を表現できない 例えば、AさんがX店で商品を買ったというレコードには、Aさんの位置情報と、X店の位置情報の二種類の緯度経度を持ったりしますが、いまのTableauでは同時に表現できません。 データソースを“うまく”加工して無理やり実装することはできないこともないですが、別の課題が出たりするのであまりお奨めはできません・・・。

いずれにせよ、空間情報処理は計算量が多く、Tableauで全て計算させようとするとパフォーマンスへの悪影響が大きいと想定されます。計算が複雑化して処理時間が長くなる場合にはAlteryx等による外部でのデータ処理を検討する必要がありそうです。

・Viz within a Viz! ⇒もっとも期待度が高いです。サンプル画像にあるように、特にマッピングのビューで有効だと思います。

 

◆Analytics

続きを読む Tableauの機能拡張

Alteryxでデータの一括結合

特に実務部門では“あるある”ネタだと思いますが、分析やレポート用にデータを既存のシステムから抜き取ったり、抜き取ってもらったデータを共有してもらった場合、同形式(同じテーブル、同じ拡張子)のデータが別々のファイルとして多数蓄積することがあります。

例えば、アクセスログの集計データが毎日CSVで自動で吐き出されているケースなどです。この場合、Tableauで分析を行うには、いったんデータを一つに結合する必要があります。

プログラムが書けるエンジニアならば、ちゃっちゃっとコードを書いて、自動でまとまるようにしてしまうと思います。 しかし、実務部門においては、プログラミングができずに一つずつファイルを開いてエクセルで一つにまとめる作業を毎週繰り返し行っていたりすることが意外と多く存在するのではないでしょうか? 毎週でも30分で終わる作業だったりすると、わざわざシステム部門に申請しなくても、という考えもあるかもしれませんが、ヒューマンエラーのリスクと、累積していく不毛な集計作業時間を考えると極めて非効率・非生産的な業務と言えます。

こういった処理はAlteryxで簡単に実装することができます。

今回は先日の投稿で用いた、国交省が公開している日本の学校のポイントデータを使って処理のフローを見てみましょう。

実際にはこちらのサイトから全国分のデータを一括でダウンロードできるので、それを使えば済む話ですが、ここではデータの一括結合の処理事例を示すため、あえて都道府県別に47のZIPファイルをダウンロードします。

ありがちなケースを想定すべく、『都道府県別』フォルダの下に個々のダウンロードファイル(ZIPを解凍した後のフォルダ)を置く形にしています。 例えば、月別にフォルダがあって、その中に日別アクセスログのCSVが置いてあるようなケースが同類ですね。

『都道府県別』フォルダ

個々のフォルダの中身は先日の投稿と同じく、シェープファイルなどが含まれています。

ではAlteryxモジュールを見てみましょう。[Directory]と[Dynamic Input]ツールで簡単に実装できます。

これで完成!

と思ったら以下のようなエラーが出てしまいました。

格好悪いので別のファイル群に切り替えようかと一瞬心が揺れましたが、エラーへの対処も実装の一部なのでその後の修正処理も記します。

上の画像では切れてしまっていますが、エラーは5つのファイルで発生していました。 エラー内容は全て以下のような感じです。 …\P29-13_02.shp” has a different schema than the 1st file in the set. つまり、最初に読み込んだ(テンプレートでも使用した)P29-13_01.shpとスキーマが違うようです。

解決するのに意外と時間がかかってしまったのですが、結論から言うと、変数の型が違うだけでした。

上図で示した[Union]ツールのように厳密に型が一致しなくてもエラーが出ないものもありますが、そうでないものもあります。 [Dynamic Input]は後者なようで注意が必要です。

最終的には以下のようなモジュールで対処しました。

システムから自動的に吐き出されているデータならば、このようなエラーは生じにくいと思いますので通常はシンプルなモジュールで実装可能なはずです。 今回はトラブル処理のおまけつきということで。

T.Fuji

続きを読む Alteryxでデータの一括結合

Tableau * Alteryx でシェープファイルを可視化

空間情報処理の一例として、TableauとAlteryxでシェープファイルを可視化してみます。

過去の投稿でも取り上げていますが、その際はポリゴンデータでした。もっとシンプルにポイントデータを使ってみます。 今回は国交省が公開している、日本の学校の所在地データを使って処理のフローを見てみましょう。 こちらのサイトから北海道の学校データをダウンロードします。

ダウンロードしたファイルを解凍すると、一つのフォルダにシェープファイルとその関連ファイルがあり、学校の位置情報などが含まれています。

このシェープファイルからは、学校単位のレコードごとにフィールド名”SpatialObj”という空間情報、具体的にはポイントデータ(その地点のデータ)が取得できます。 この中に緯度経度の情報も含まれますので、それを抽出するとTableau上で簡単にマッピングできることになります。実際に実装してみましょう。

Alteryxでは[Spatial Info]ツールでPointの緯度経度を取得します。Spatial Dataはサイズが大きいため、Tableauの集計用データソースとして抽出することが目的であれば、Spatial DataであるPointフィールドは[Select]ツールでカットしておくことが推奨されます。

Alteryxのモジュールとその解説を下の画像に簡単にまとめてみます。 ※Browseツールは無くても構いません。

5分もあれば完成するようなモジュールです。

TDEで出力されていますので、これをTableauから接続して可視化します。 フィールド名や一部のコードを別名で編集したものが以下のアウトプットです。

ノンプログラミングで簡単に実装できました。

国交省の国土数値情報や総務省のestatには、様々なシェープファイルがオープンデータとして公開されています。 これらを自社のデータと組み合わせることで、全く新しい発見が得られるかもしれませんね。

T.Fuji

続きを読む Tableau * Alteryx でシェープファイルを可視化

Tableau * Alteryx

主に業務部門の中・上級者向けになりますが、Tableauの価値をより強化するツール”Alteryx“(アルタリクス)について今回は取り上げます。

ちなみに日本での認知度は限りなく低く、日本語の記事も非常に限られていますが、欧米ではTableauとAlteryxがセットで用いられているケースが多いようです。 実際に何ができるのか、という点については、Developers.IOのこちらの記事が参考になります。

ざっくり特徴をまとめると以下の4つに集約されると思っています。

①ETL(Extract/Transform/Load)処理 ②統計解析(Rベース) ③空間情報処理 ④レポーティング

これらがノンプログラミングで行えます。

一つずつ詳しく取り上げながら、なぜ欧米ではTableauとセットで使われているかを解き明かしたいと思います。

 

①ETL処理

Tableauで多様なデータソースにアクセスをし、業務部門でもノンプログラミングで様々なアウトプットが作れるようになりました。 ただ、Tableauのスキルが上がると、複雑なアウトプット、複雑な集計のニーズが高まったり、より大規模なデータを取り扱いたくなります。

Tableau上でもテーブルジョインや異なるデータソースのブレンド、カスタムSQLなどによるETL処理が可能ですが、そもそもETLツールではないので、できることに限りがあります。また、何でもTableau上で処理しようとすると可視化のパフォーマンスにも少なからず影響が出ます。

そうなるとTableauに接続するデータの持ち方を工夫する必要性が生じます。

Alteryxでは「ツール」と呼ぶアイコンをGUI上でつなげるだけ、一切のプログラミングなしでETL処理が可能です。Tableau同様、主要なデータソースには接続可能で(プラグインが必要なことが多い)、しかもTDE(Tableau抽出ファイル)形式でアウトプットすることも可能です。

セルフ(サービス)BIというワードも浸透してきましたが、ETLまでできないとレベルの高いアウトプットのセルフBIは実現しない、最近は特にそう感じるようになりました。

 

②統計解析(Rベース)

TableauではVer8.1からR連携が可能になりました。ただし、Tableauの中では、一つのビュー内で表計算的にRの関数がワークすることになります。 例えば、Rの関数を使って、一つのビュー内で外れ値を見つけたり、クラスター分けを行うことはできますが、その結果を別のシートで使うには、分析結果を元のデータソースから切り離す必要があり、ダイナミックな分析はできません。また、使える関数も限られます。 また、Tableau Desktopがインストールされた端末にRがインストールされている前提となります。共有を前提としたアウトプットには不向きです。 あくまで、分析者個人のその場の統計処理用に一部のR関数が使える、という認識が良いと思います。実際にTableau社も、Rで何でもできます、とは一言も言っていないようですし。

結局、現時点では複雑な統計処理はTableauの外で行う必要があります。

Alteryxでは、主要な統計手法についてRベースで実装された「ツール」が用意されており(先述した参考サイトの下部に詳細あり)、こちらもノンプログラミングで多彩な統計解析が可能になります。

Alteryxで事前に統計処理を行い、その分析結果を含むTableau用データソースを生成することで、高度な分析もBIに含むことが可能になります。

Rを含め、統計ソフトのグラフ機能は貧弱なケースが多く、従来から統計分析の結果をTableauで可視化することは多かったのですが、統計処理そのものをAlteryxのモジュールに組み込むことで、 ローデータ⇒統計分析⇒結果の可視化 という一連の処理、特にデータ更新による分析の焼き直しを大幅に効率化することが可能です。

なお、ノンプログラミングとは言えなくなりますが、自作のRスクリプトを動かすこともできます。この点については、後日別の記事で取り上げられればと思います。

 

③空間情報処理

簡単に言うと地図系のデータ処理のことです。

最近はスマートフォンのアプリなどでユーザーの位置情報が簡単に取れるようになりました。緯度経度データはTableauで簡単にマッピングできます。 ですが、それだけだとタダの点の集まりですし散布図にしかなりません。ユーザーの移動データは大量にたまってきたものの全く有効活用できていない、と感じられる方も多いのではないでしょうか?

AlteryxはもともとGIS(地理情報システム)系の会社だったようで、空間情報処理系のツールが豊富に揃っています。 特定地点から各点の距離を測ったり、円商圏を作ってその中に含まれる点の数を数えたり、ポリゴンからメッシュを作ったり、などといった処理を簡単に行うことができます。

AlteryxでShapeファイルが読み込めることは過去の記事でも取り上げられています。 例えば、総務省統計局のeStatから行政区域の境界データ(ポリゴン)を取得できますが、行動データとして取得した緯度経度データをこのようなポリゴンとマッチングさせることによって、緯度経度情報のみから市区町村や町丁目のようなエリア単位で集計や、A地区からB地区に動いたユーザーがどの程度存在するか、といったフローの分析が可能になります。

これらの具体的な処理方法については後日サンプルとともに公開していく予定です。

 

④レポーティング

Alteryxはデータビジュアライゼーションの部分についてはTableauやQlikviewといった別のBIツールに任せています。データソースとライブでつないでツール上でいろいろ切り替えるような動的なレポートではなく、パワーポイントやPDFで吐き出す静的なレポートの作成が得意です。

良いか悪いかはさておき、TableauのようなBIを導入しても、従来のPDFが良い、パワポが良い、帳票形式が良い、エクセルの条件付書式が見やすい、といった方々が少なからずいらっしゃいます。無視して突き進む、なんてことができれば苦労はないのですが、実際はそうならないことがほとんどです。

PDF化はTableauからエクスポートできますので何とかなるとは言え、フィルタやスクロールが機能しないのでその前提で作らなくてはなりません。 また、帳票形式はTableauの得意分野ではありません。そもそも以下のような観点からも目指す方向が違うと考えています。

Tableauが後者なのは明らかですね。

さて、そんな従来型の帳票形式ですがまだまだ必要とされているのは事実です。Alteryxならその取り扱いも簡単です。

例えば、TableauではおなじみのSuperstore SampleをAlteryxで読み込み、エクセルっぽい簡単な帳票とグラフを作成し、Region別にA4のPDFレポートを作成してみました。 (画像はCentral

続きを読む Tableau * Alteryx

Tableauでのネットワーク分析方法について

今回はTableauでのネットワーク分析方法について解説いたします。 基本的にTableauはネットワーク分析をターゲットとしておらず、Tableau上で実現するにはやや強引な手法が必要となります。 本格的なネットワーク分析をするのであれば、専用のソフトウェアを使うことを検討すべきですが、 他のダッシュボードと一緒にTableau上で表示したい、といったニーズもあるかと思いますのでそういった場合に参考になれば幸いです。 こちらを参考にしています。 http://public.tableau.com/profile/joe.mako#!/vizhome/handoff-map/Dashboard 今回はデータソースとしてネットワーク分析に使えるのものが手元になかったため、 政府統計の総合窓口(e-Stat)の男女,移動前の住所地別都道府県間移動者数-都道府県,3大都市圏(東京圏,名古屋圏,大阪圏) http://www.e-stat.go.jp/SG1/estat/List.do?lid=000001129166 を加工して都道府県間の移住者数を表示します。(意味のない分析ですがご容赦ください) 都道府県間の移動のみを抜き出し、それに地方データ、2014年度の人口データ、各都道府県の座標を加えています。 座標データ(X,Y)はRの標準パッケージ「igraph」の「layout.kamada.kawai」をつかって作成しています。 勿論、実際の緯度経度を使っても結構です。(ただし相当表示を大きくしないと円が重なって見にくくなります。) データを作る際の注意点としては、「異なる場所にある同じ名前のものを繋げる」ことでネットワークの線を表現しているため、 データとして、移動元と移動先をつないだデータ(from)と移動先と移動元をつないだデータ(to)が必要であり、位置情報や付加情報を示すためのデータ(node)が必要になるということです。

本格的な分析には不向きかと思いますが、一応頑張ればそれらしいものが表示できるということで。

細かい仕組みについては是非ダウンロードしてご確認ください。

Tableau_id執筆者:林 周作(Shuusaku Hayashi)

続きを読む Tableauでのネットワーク分析方法について