SPSS Modeler まめちしき8つ
SPSS Modelerってググっても情報が少ないですよね
データを扱う場面によっては、使えるツールは手元の環境に用意されたものだけってこと、ありますよね。ツールの使い方がわからない場会、ネットが使えれば検索で何とかしたいところですが、歴史の長い統計ソフトの場合、ネットで調べるのはかなり難儀します。そんなソフトの1つ、SPSS Modeler *1を使ってる人だけに向けて書きました
前提
データソース関係
CSVファイルをドラッグアンドドロップ
拡張子.csvのファイルは、ストリームキャンバスにドラッグアンドドロップで可変長ファイルとして認識されます。.tsvとか.xlsxには対応してないようです。
テーブル名検索
テーブル/ビューの選択 > オプション > 名前 。「%」がワイルドカードで使えます
オプション関係
ストリーム自動保存
ツール > システムオプション > ストリーム自動保存間隔
クラッシュしやすいので短めで。一見5分が最低値だけど、手入力で5分以下にできます。
上書き警告外す
ツール > ユーザーオプション > ノードがファイルを上書きするときに警告
ツール > ユーザーオプション > ノードがデータベース テーブルを上書きするときに警告
スクリプトで出力回す場合、この警告で止まってたりがあるので外してます。
外すとまずい場合も多々あると思うので参考程度に。
画面表示の数値をカンマ区切り表示
ストリームオプション > 全般 > グループ化記号
記号が入るのは画面表示だけで、ファイル出力には記号入りません。
プレビュー行数を増やす
ストリームオプション > 全般 > データプレビューに表示する最大行数
100とか適当に増やしましょう。
進捗レコード数表示を外して高速化
ストリームオプション > ログとステータス >レコードのステータスを表示
画面下に表示される入力/出力レコード数。あるとまあまあ便利だけど、高速なストレージで読み書きする場合は「しない」にすると進捗が早くなります。
ノードの配置設定
ストリームオプション > レイアウト > グリッドセルサイズ
好みがわかれる部分だと思いますが、ノード位置がずれてると気になっちゃってという場合「2.00」にするとノード同士の間隔が揃います。ただし、同じノードが同位置に重なってしまったとき*3に気づきにくいという欠点もあります。
参考資料
SPSS Modeler関連本はこの1冊だけでしょうか。秒で買いました
(take)
色々なBIツールの特徴について考えてみた
近頃、可視化分析の研修ではTableauと他のBIツールの比較のお話を依頼されているので、この際に記事にまとめてみた。
世の中に多くの種類が存在するBIツールたちには、共通な目的がある。BI = Business Intelligence という名前が付いているには、ビジネスに役に立つ知恵・知見を引き出すことが目的である。社内・外部に散らかっている様々な種類のデータを統括管理し、分析に使いやすくしてくれる。迅速かつ的確な経営判断を実現すべく、より多くの時間を施策・思考を考えるようにするために、データ分析の労力を最小限にするのがポイントである。
BIツールの導入意義
主に以下が考えられる:
- 効率性・スピード(優れた操作性、レポーティングの自動化)
- データドリブンな意思決定を支援
システムを横断してあらゆるデータを統合した上、複数の軸・角度からビジネスを俯瞰できる為、データそのものの中から法則・インサイトを引き出しやすい
- 表現能力が高い
インタラクティブなダッシュボードのおかげで見る人の視覚・直感に訴えることが出来、思考過程をストーリーで伝えやすい
- 分析の属人化防止、労力の低減
専門スキルがなくとも、データの準備と分析を実施し情報を活用できる。複数人で分析機能を活用でき、分析結果も共有しやすい。
Tableauの特徴と他のBIツールの比較
Tableauの特徴
Tableauとは何かを、それを全く聞いたことがない方に向けて「可視化分析を行うツールの1種で、それを用いてダッシュボードを作れる」と一言で説明できるでしょう。しかしメインの利点ダッシュボードが出来上がることではなく、Tableauを使う人も、そして作る人も見る人も触れば触るほどデータからインサイトを引き出せることにある。Tableauというツールの特徴をもっと言及すると以下となる(一部は他のBIに共通)
- 一般的に言われるのは、誰でも使いやすい・比較的短時間でそこそこ使える状態になるまで学べる。つまり習得に費やすコストを抑えられる。早く施策に役に立って欲しい想いで導入したのに使えるまで長い時間がかかるようでは元も子もないですから。これは、使いやすい・分かりやすいインターフェイスを持っていることにも起因する。
- もう1つは、インパクトのある可視化・分析ができること。TableauはBIツールの中でも優れたデータ表現力、豊富な機能を実装可能の方と言われている。実装する側のみならず、閲覧する側も直感的な操作性から恩恵を受けている。
- 最後に、これは分析専門家や可視化分析を推進する側からの観点ではあるが、Tableauは何よりも「有名」であり、「ビジュアル分析のゴールドスタンダード」 のとして売りやすく、お客さんに勧めしやすい。
もちろんデメリットもある。日本語ヘルプの質がよく苦情に出る。マニュアル系の日本語訳が不自然、日本語化された学習用動画が少ないのが改善すべき点である。コミュニティも英語が苦手な方は使いづらいことが多い。別件で、高度な機能を自ら実装できるとはいえ、スキルが不十分なユーザが不適切な使い方をすると、知見を得るまで遅く感じてしまう。また、高度なビジュアルや表現をを実現しようとハマりやすくて、、望む通りのグラフが作れず悩んでしまい、ついつい時間を忘れてしまいがちである(私もそう)。つまり、Tableauは特別なものだと思わずに、あくまでも開発自由度のやや高めのBIツールの1種であると受け止めるべきでしょう。
他のBIツールの特徴は?
では、上記で述べた特徴のどれが他のBIツールも持っている点でしょうか。ここではTableauを他のいくつかの著名なBIツールと比較してみた。GRI では従来Tableauをメインに知見を貯めてきているので、仕様経験のある人の声やウェブ上の情報を参考にした。
今回比較するのは、Power BI(Microsoft)、DOMO、Motion Boardである。これらのツールの間の共通点は、BIツールであるだけに、比較的簡単な操作で分析と可視化(ダッシュボード作成)が出来る点である。細かい相違点は以下にあると思われる:
- ターゲットユーザーの範囲
- 使い勝手・機能・表現力(ユーザーの背景、相性にも依存)
- 導入・運用の価格帯
- 導入実績 / 知名度 / コミュニティの大きさ
- サポート・サービス
Tableauは先述のように、一般的に使いやすい、何がどこにあるかわかりやすく、そして柔軟に計算法・表現をカスタマイズ可能、美しいダッシュボードで大きなインパクトを醸し出しやすい、作る側も見る側も直感的に操作しやすい、が特徴と言われている。
Power BI
Power BI もTableauと並んで知名度が高く、Microsoft製品ならではの明瞭さ・安心感があり、特にExcelユーザが馴染みやすく、まるで、大容量データを扱えるEXCELの感覚で使われたりする。そしてかなり嬉しいのは、安価で手軽に始めやすいこと( “wowed within five minutes”)。抜群に手頃な利用料のおかげで、 BI利用の入口として社内決裁取りやすい。特徴的な機能としては、自然言語クエリでチャートが返される、データソースからの定期更新が可能であることが挙げられる。ただし(特に無料版は)データ容量は少な目なのでビッグデータ向けとは言えない。
DOMO
500種類程度の豊富なデータソース対応できて、可視化以外にデータの統合・集約・加工機能がオールインワンに統括されている。使い勝手や管理性上の利便性の多いクラウド型BIツールとして、ETLなどのインテグレーションに必要な技術のない一般的なビジネスユーザーにも使いやすいと言えるでしょう。また統合基盤はトータルで導入コストが低い(データウエアハウスやETLのインテーグレーション不要)とか投げられる。
Motion Board
Excelと連動しやすく、円滑な業務を支援する機能が充実している。例えば、Excelで入力・加工して更新するとMotion Board上で自動連動され、Excel・PPT・PDFへの出力、自動メール配信機能、業務・業種に合わせたテンプレートが様々内蔵されてる。一方で、高度な機能が作り込まれているということもあって(?)、月額料金が割高の方である。
更に俯瞰的にマッピングすると(以下は「どちらかというと、的な話」)以下の図にまとめられるでしょう。
結局、社内のリソースと何を重視するかに依存し。。。高度な視覚化、見栄え、計算機能、カスタマイズの柔軟性を選ぶならTableau、「誰でも使える」操作性を重視なら、Power BI, DOMO, MotionBoard など掲示板らしいツールが良いと言えるでしょう。
価格帯
導入に関して誰もが気になる利用料金は以下となる。DOMOのみ非公開なので省略。
作者:アナリティクスチーム ・ヤン
GCP Dataprepで大規模データを扱うときネックになるポイント
どうも、アナリティクス&デベロップメント部のTです。
GCPのサービスの一つ、Dataprepを使えば、GUI上でインタラクティブにデータの集計~整形・加工を行うことができます。
プログラミングコードを書けない人でも手軽にBigQueryやGCS上のデータをいじることができるので、
このサービスを利用してデータ加工パイプラインを組めば、ビジネス側の人も触れる大規模データの分析基盤を構築できるのでは...!
という話になり、機能調査してみました。
・・・
結論からお話ししますと、機能的には不足はないものの、オープンデータを使って基本的な処理を行う実験から以下の難点が見つかりました。
- 処理速度が遅い
- 特にCOUNT DISTINCTやJOINはデータ量が増えると結果が返ってこない
- 課金額の予測が困難
- 処理時間×使用CPU数による課金、ただしCPU数は自動でスケールされるので制御が効かない。
そもそも数MB程度のデータでも処理に5~10分程度かかってしまうのですが、それが数億行・数十GBのデータになると、処理によってはいつまでも結果が返ってこず時間課金だけ積もっていき、つらいです。
プログラミングができない人向けの小~中規模データのアドホック分析ツールとしてはよいかもしれませんが、
ビジネスサイドの人もいじれるETL(Extract, Transform, Load)ツールとして運用に乗せるのには、無理があるように思いました。
- Dataprep #とは
- 概要
- できること・できないこと
- 設定可能な項目
- データソース
- 処理パフォーマンス
- 料金体系
- 実験:大量データの扱い
- 概要
- データ内容
- 実験内容
- 実験結果
- 処理時間
- 料金
- 考察:何故こんなにコスパが悪いのか?
- なぜ遅い?
- なぜ高い?
- まとめ
Dataprep #とは
概要
続きを読むPythonの可視化パッケージ Seaborn の Lineplot の凡例でハマったこと
What is Seaborn?
Pythonの可視化パッケージにはいくつかありますが、そのうちの一つに Seaborn があります。
代表的なパッケージとしては以下があります。
- Matplotlib: Matplotlib: Python plotting — Matplotlib 3.1.2 documentation
- Seaborn: seaborn: statistical data visualization — seaborn 0.9.0 documentation
- Dash (Plotly): Modern Analytic Apps for the Enterprise - Plotly
- Bokeh: <no title> — Bokeh 1.4.0 documentation
それぞれにユニークな特徴がありますが、Seaborn は 比較的に低級なパッケージである Matplotlib のラッパーになっていて、簡単にキレイなVizをつくれるのがうれしいです。
また、最近のパッケージにはほとんど導入されていると思いますが、列指向の DataFrame を前提に作られているのが特に気に入っています。
BIツールのTableauも列指向のデータが前提ですね。
Seaborn の ドキュメントには列指向データを以下のよう簡潔で分かりやすく表現しています。
(seaborn.lineplot の API reference より抜粋)
Parameters:
data : DataFrame
Tidy (“long-form”) dataframe where each column is a variable and each row is an observation.
データサイエンティストは Tidy なデータは大好物ですが、Messy なデータはちょっと。。。という感じですよね。
ちなみにTidyデータの構造に関する資料は以下のペーパーが気に入ってます。
https://vita.had.co.nz/papers/tidy-data.pdf
Lineplot でハマった点
本題ですが、あるIoTデバイスの加速度データを周波数解析し、各周波数帯ごとのスペクトルパワーを可視化した際に、
その凡例が正しく表示されない挙動でハマりました。
前提条件は以下です。
- Seaborn==0.9.0
- 入力データフレーム (df_filter_bank)
(sampling_at: 時刻, Period: 波長(周波数の逆数で、単位はhour), PSD: スペクトルパワー)
上記条件下で以下のコードを実行しました。
df_plot = df_filter_bank.loc[df_filter_bank['Period'].isin([2.0, 4.0, 8.0, 16.0])] fig, ax = plt.subplots(figsize=(20, 8)) sns.lineplot(data=df_plot, x=df_plot.index, y='PSD', hue='Period', ax=ax) fig.show()
上記コードを補足すると、波長が2, 4, 8, 16 時間のデータを抽出し、それらを個別にlineplot で描画するという単純なものです。
結果は以下のようになりました。
Vizの凡例(legend)に注目してください。プロットする波長は4つの組合せ(2, 4, 8, 16 時間)のはずなのに、
結果はなぜか(0, 5, 10, 15, 20)となっています。値が違うどころか、個数すら違います。
hue に指定したデータ型がNumeric が原因なのではと思い、文字列型にcastしたところ、以下のエラーが。。。
AttributeError: 'str' object has no attribute 'view'
解決した方法
以下のGithubのIssueに情報がありました。
github.com
詳細はIssueを読んで頂ければ分かると思いますが、数値型データをhueとして使う場合には、一旦Tex形式の文字列にするという割とトリッキーな方法が紹介されてました。
Matplotlib にはTex形式で数式記述ができる機能が公開されていて、それを利用しているんですね。
Writing mathematical expressions — Matplotlib 3.1.2 documentation
実際、実行コードを以下のようにすると正しい挙動になりました。
df_plot = df_filter_bank.loc[df_filter_bank['Period'].isin([2.0, 4.0, 8.0, 16.0])] # 以下を追加 df_plot['Period'] = ["$%s$" % x for x in df_plot['Period']] fig, ax = plt.subplots(figsize=(20, 8)) sns.lineplot(data=df_plot, x=df_plot.index, y='PSD', hue='Period', ax=ax) fig.show()
さいごに
Lineplot をつくる際には hue に数値型データを利用したいことは結構あると思います。Seaborn を上手く改修できるのが一番ですが、この記事ではちゃちゃっと改修するための方法を紹介しました。
Markdown使っていて、不満に思うこと
まだドキュメント作成にWord Excel 使ってるの
Markdown使っていて、不満に思うこと
文章を書く時、Markdownを使っている方は多いと思います。
私もあらゆるメモはMarkdown形式で記載することが多いのですが、さて、納品用ドキュメントを作成する際に困ることがあります。
* ヘッダー・フッターに共通の要素を入れたい
(ページ番号、copyright、ロゴ画像など)
* 改ページを任意の場所に入れたい
* 目次を自動生成したい
提出先によっては、書式を整えて提出したくなる場合があり、その際にMarkdownだといささか心もとないですね。
asciidocが良いみたい
プロジェクト内でドキュメントを作成する時は、複数の人間が同じ書類に変更を加えたり、レビューをしたりするので、当然テキストベースのマークアップ言語で記述して、Gitで管理するのが良いわけです。しかし、最後にWordにコピペする作業も、ドキュメント種が多くなると大変ですし、無駄な作業の感じがして辛いです。
でも、最初からWordで作ると、変更管理機能はあるものの、ファイル共有、レビュー、修正などにGitのメリットが活かせずスピード感が出ません。そんな時は、asciidocを使うことが多いです。記載もMarkdown同様に直感的ですし、ちょっとルールを覚える必要はありますが、前述の不満も解消できています。ドキュメント形式としては、HTMLまたはPDFにして収めることになります。(納品ファイル形式が定められている場合は、、素直に諦めます)
asciidocを使ってみよう
環境準備、記法などは、だいたい検索すれば出てくるので、ここでは割愛します。 個人的にいいなと思ったところを紹介しますね。 (わたしの環境は、macにasciidoctor/asciidoctor-pdf をインストールして使っています)
アイコンが簡単かわいい
文章の前に文字を記載するだけで、かわいいアイコンが出てきます
NOTE: こんな情報アイコンが出てきます 。
WARNING: 警告を書くこともできます
目次が作成できる
asciidocは、文章の構造から自動的に目次を生成してくれます。
以下のコードを、文章の頭に埋めるだけ。 * sectnums 番号を振る * toclevels サブタイトルの2階層目までを目次に採用する * toc-title 目次の名称を指定(デフォルトが英語のため)
:toc: :sectnums: :toclevels: 2 :toc-title: 目次
この文章のここまでの見出しを例にすると、以下のように生成されます
改ページを入れられる
改ページを入れるのも簡単です。
以下のように記載するだけで、文章1と文章2の間に改ページがを入れることができます
文章1 <<< 文章2
もっと使いたおそう
こちらの記事では紹介しませんでしたが、asciidoctorでは、テーマをカスタマイズすることで 出力するPDFのレイアウト、フォント、文字サイズなどが指定できます。
もっと色々試して、実用的なものを紹介できればと思います。
角度データにおける平均方向と分散の算出方法
こんにちは!
新卒2年目分析官のMです。
皆さんは風向や波向などの角度で表現することができるデータ(以下角度データ)を扱った経験はありますか?
角度データは0°から360°の周期性を持つため、体重や身長などの線形データとは扱い方が異なってきます。
本記事では基本的な統計量として、角度データの平均方向と分散の算出方法についてご紹介します!
・角度データの平均方向
x1,x2,...,xnを線形観測値としたとき、
一般的な算術平均は(x1+x2+...+xn)/nで与えられます。
しかし角度データの場合、この計算方法では平均方向を算出することはできません。
例としてθ1=30°,θ2=330°を角度観測値とした場合で考えてみましょう。
この場合、下図の通り平均方向は0°ですが一般的な算術平均の算出方法だと
(30+330)/2=180°となってしまいます。
角度データの平均方向を算出するには、
まずはじめに角度観測値θi(i=1,2,...,n)を平面上の単位ベクトルvi=(cosθi,sinθi)に変換します。
つぎに各単位ベクトルviの和を取り、合成ベクトル(C,S)を算出します。
※CとSは以下のように定義されます。
この合成ベクトルの向きが平均方向となります。
先ほどの例だと、
となり、下図の通り合成ベクトルは(√3,0)となります。
よって平均方向は0°となります。
・角度データの分散
平均方向と同様、分散の算出方法も線形データの場合とは異なります。
例としてθ1=30°,θ2=330°とφ1=60°,φ2=300°を角度観測値とした場合で考えてみましょう。
θの平均方向とφの平均方向はともに0°となります。
しかし、同じ平均方向をとるθとφでもθの方が散らばり具合が小さく、
より平均方向にデータが集中しています。
この散らばり具合は合成ベクトルを基準化した
平均合成ベクトル(C',S')の長さR'(以下平均合成ベクトル長)により数値化することができます。
※C',S',R'は以下のように定義されます
R'は0から1までの値をとり、
1に近いほどデータの散らばり具合は小さく、
また、0に近いほどデータの散らばり具合は大きくなるといえます。
このことから、角度データの分散は1-R'で与えられます。
先ほどの例だと
θの平均合成ベクトル長は√3/2となり、
φの平均合成ベクトル長は1/2となるため、
θのほうが散らばり具合が小さいということになります。
・さいごに
角度データを扱う統計学は方向統計学や角度統計学と呼ばれており、
様々な角度データ用の確率分布や回帰モデル等が存在します。
興味を持たれた方はぜひ調べてみてください!
仕事における「脳」の使い方を考える
一時期流行った手と腕の組み方で自分の資質がわかるという診断があります。
参考)貴方の効き脳はどっち? 右脳派?左脳派?
http://www.izmic.jp/mame/2014/01/entry_1903/
これを仕事に当てはめてみると、右脳タイプは「感性を大事に仕事を進める」 顧客の要望を汲み取り、共感し、どちらかというと営業や企画の方がより求められる素質ではないでしょうか?
感覚的には「粘土づくり」に似ていると思います。 うっすらとしたイメージはあるのでそれに近づける仕事となります。
また、左脳タイプは「論理的に仕事を進める」 顧客の問題点を解消する具体案を提示し、決まったことをきっちりとさばくのが得意で、エンジニアや経理の方により求められる素質かと思います。
こちらも感覚的には「模型づくり」に似ていると思います。 設計図はあるのでそれに忠実に作成していく仕事となります。
ただ多くの記事でも言われるように、大事な点としては自分がどんな素質でも仕事においてバランス良く頭を使う必要があり、 バランスが悪いとうまく仕事が進まないことが多々あると思います。人間なので右脳と左脳両方使うのが大事です。 偏ってしまうと、それぞれ以下のような状況になります。
◆右脳寄り過ぎな仕事
・顧客要望に共感しすぎて本質がブレる
・自分の考えに固執してしまい、思い込みで進めてしまう
◆左脳寄り過ぎな仕事
・自分の知識が想像の限界で、柔軟な発想が出ない
・仕事を「作業」として進めてしまい、本来の目的を見失う
必要なのは左右の脳をそれぞれスイッチしながら使う。 「アイデアをロジカルに詰める」ことが重要だと思います。 これをまとめると以下のような感じになると思います。
・要望を聞き、素材を得て、周辺情報を集める(右脳・左脳)
↓
・集まった情報から本質を想像する(右脳)
↓
・そこから具体案を組み立てる(左脳)
↓
・案を顧客とディスカッションする(右脳)
↓
・最終案をまとめ、その内容でモック、ドラフトを作成する(左脳)
↓
・できたものの見直し、改善する(右脳)
↓
・顧客へ報告し、更なる改善を議論し、顧客の要望を引き出す(右脳・左脳)
そう、先程の「模型と粘土」の例でたとえるのならば、右脳と左脳を全力で活用するあの世界大会「GBWC」がイメージに近いと思います。
https://bandai-hobby.net/GBWC/japan/
既製品に足りない点を自分の頭で考え作り出す、そんなこの大会で求められる資質同様に 自分の独りよがりでもなく、設計図通りでもない「想像の上を行く創造」が毎回仕事でもでできればなぁと 思いながら自身も仕事をしていますが、なかなかうまくできないことも多々あります。
ただ意識することは大切だと思うので、上記を頭の片隅に置いて日々の仕事を行うのが良いと思います。