2019年03月03日

オフィスの引っ越しとブログの引っ越し

会社のオフィスを渋谷から四谷に移しまして、心機一転、ブログもbloggerに移してみました。また、note.muにも記事を書いてみたり。どれをどのように使っていくか、これから考えます。


新オフィス: 〒102-0083 東京都千代田区麹町6-6-2 WeWork内



posted by jinya at 15:59| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2018年12月14日

Google Fusion Tables が終了

来年の12月で、Google Fusion Tables が終了するとのこと。


分析の過程で位置情報を表示するのに重宝していたのですが、主要ツールになかなか格上げされず、最近は新規登録の導線も無くなっていたので、時間の問題だろうと思っていました。長い間ありがとうございました。

自分の履歴を調べたら、2011年頃から使っていました。初回リリースが2009年だそうです。lat, longを持ったデータの地図表示はもとより、kml形式テキストでデータを突っ込めば、ポリゴンなんかも描画してくれるので、非常に便利でした。今はもう無い Google Maps Engineがでたときも、使い比べてやはりFusion Tablesの方が(手っ取り早く可視化するには)使いやすかったですね。データ分析はアドホックにいろんな見方でデータを加工して可視化するので、システムとしての使いやすさよりも、思ったことがすぐに可視化できる柔軟性の方が重要で、その点でFusion Tablesは優れていました。Map View 界隈の Excel みたいなものです。(ちなみに Excel でも Power View を使うとBing Map の上で似たようなことができます。そちらも便利です。)

最近は、BigQueryにGIS系の関数が組み込まれて、Data Studio でも Map View ができるようになってきたので、そちらに移り変わっていくんでしょうか。分析を全てクラウド上で行うことが増えてきたので、そちらの方が今後は使いやすいかもしれません。上の記事を読むと、別のサービスも予定されているように読めるので、そちらも期待したいです。

posted by jinya at 16:44| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2018年11月20日

ホワイトボードを共有したい 〜 Microsoft Whiteboardを使ってみた

もう20年ほど前のことですが、大学で研究をしていた頃、海外や他大学などの研究者との議論が大変でした。2000年よりちょっと前くらいのことで、電子メールでのやりとりはできたので、遠方とのコミュニケーションは電子メールで往復書簡というのが普通でしたが、同じ場所にいれば黒板を挟んで、図や数式などを書きながら、指示語を多用しながら議論やレクチャーができるものを、遠方だとなかなか伝わらないなと思ったものです。それでも、電子メール以前の世界とくらべてえらいスピードになったものだと思っていました。

ですから、将来は黒板を遠方と共有して使えるようになったらいいですね、などと話していたのですが、それが20年経ってやっと現実のソリューションとして手が届くところにやってきました。

一般ユーザー向けには去年あたりから出回っていたようですが、企業向けのアカウントで使えるようになったり、iPadで使えるようになったりしたのがつい最近とのこと。丁度良いタイミングで発見できてよかったです。もともと、数式を共有したいのが一番の動機だったので、手書きで細かく書けることが重要視ポイントその1、また、議論のベースとして使いたいので、リアルタイムに共有されることが重要視ポイントその2です。これが、Microsoft Whiteboard × ( iPad + iPencil ) で乗り越えられました。(注:おそらく、去年くらいからsurface proでは同じことができていたと思います。)

ちなみに、2だけならば実はGoogle Docsを使えば数年前からできました。数式や図を書くのはちょっとしんどいですが、文字情報のリアルタイム共有はできました。

一方で、1の方は、リアルタイム共有ではなく、こまめに保存とリロードを繰り返せばできるとか(Google Keep等)、カメラで実ホワイトボードを撮影しながら議論するなどのことは、過去でもできましたが、一長一短あって、リロード型だと「ここがこうで・・・」のような指示語が使いにくい、カメラだと見えにくかったり、実ホワイトボードがある方の人しか書き込めなかったり。Google の、Jamboardも1のソリューションの一つですけれど、こちらも書けるのはjamboardがある拠点の人だけで、しかも価格が高い。100万円はちょっとインパクトあります。

その点、Microsoft Whiteboard × ( iPad + iPencil ) は
  • 共有している誰もが書き込めて、それがリアルタイムに共有される
  • 手元で展開されるので、見やすい
  • iPad+iPencil は細かい数式も書きやすい
  • 低価格で環境をそろえられる ( ipad + iPencilで 5万円程度 )
と、やっと全て揃ったソリューションになりました。これで遠隔での議論が今まで以上にやりやすくなります。

例えば、Skypeやハングアウトがあれば今でも
  • 声が届く
  • 顔が見える
  • 資料の画面を共有できる
まではできましたので、これにもう一枚、ホワイトボードの画面を追加して、かつ、手元にそのiPadを置いておけば完璧です。自分のデスクでどこの拠点とも深い議論ができます。「ここをこうして、・・・」と言いながら矢印を書いたり、数式を書いたりできます。


遠隔コミュニケーションのハードルがどれだけ下がるかが、働き方改革の上で非常に大きなファクターになっていて、特に今後の日本の社会で、子育て介護と仕事をどうやって両立させるかが求められていますし、これを乗り越えられる会社しか生き残っていけないだろうなと思っています。私自身も、まだ両親が田舎で健在なので東京で働くことができますが、もし何かあったときには、生活の拠点を地方に移さなければならなくなる可能性もあって、その意味でも切実な課題です。ですから、その時までに自分の会社では、日本中もしくは世界のどこにいても、隣にいるときと同じようなコミュニケーションができる環境を(それなりの安価で!)作っておくことに積極的に取り組んでいきたいと思っています。

最後に蛇足で、ここが不便、とか、もっとこうなったいいなという点を。

  • Microsoft Whiteboard の「書く」UIがちょっと中途半端なので、もっと洗練されると嬉しい。
    • 例えばペンの太さを切り替えられるとか、タイプ文字を書き込みやすいとか。
    • iPadの「メモ」アプリのUIがそのまま使えたら最高!
  • 企業向けはOffice365のユーザー同士しか繋がらないのですが、実は共有のinvite先として選べるのはExchange契約者のみ
    • Office365のBusiness PremiumやE3ならExchangeが付いているので、inviteを受信できますが、BusinessのユーザーはExchangeが無いので、inviteされない。Office365をMS Officeライセンスのためだけに使っている人は要注意。
    • Exchange無しユーザーから有りユーザーへinviteを送信することは可能
  • GSuiteで同じものを提供してほしい
    • 普段からMicrosoft Exchangeユーザーならばこれで十分ですが、ウチはGSuiteユーザーなので、GSuiteでできたらいいなと。平たく言えば、パクってほしい(笑)。ユーザビリティ的にもセキュリティ的にも、コミュニケーションが散乱せず閉じた世界でまとまっていた方がありがたいです。Googleさんよろしくお願いします。
    • 但し、入力UIはアンドロイドだけじゃなくてぜひiPadにも対応してほしい。やはり対人間インタフェースとしてapple製品は本当によくできています。






















posted by jinya at 19:26| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2018年07月27日

GCP × condor で分散計算

GCP × condor で分散計算をした記録です。

【前提】
対象とした計算は、高速道路・有料道路料金提供サービスや高速.jpで利用している、高速道路の料金計算。高速道路の料金は「最安経路」で決まるというルールがあります。日本の主要な高速道路はおよそ距離あたりいくら(例えば普通車は約24.6円/km)で決まっているのですが、中にはそうでない場所が沢山混ざっていて、例えば飛騨トンネルはちょっと割高(36.36円/km)だったり、100kmを超えると料率が低減していったり、中にはキロあたりではなくてここからここまではいくらで決まっている区間があったり(中には無料化されている区間があったり)するので、その中から「最安」の経路を探すのはなかなか難しい経路探索問題になっています。
そして、この料金データは、新しいインターができたり、新しい道路が開通したりする度に更新する必要があり、およそ月に一度、日本全国のインター約1000件の組み合わせ全100万ペアに、いくつかの割引料金を合わせて全500万ペア程度の計算を実施しています。

【これまでの状況】
さて、この沢山の計算を、これまではオンプレの計算サーバーで実施していました。現在はコア数およそ20を使って20時間程度を要していますので、400CPU時間程度かかっていることになります。しかし、そろそろこの計算サーバーも古くなってきたので、新しいマシンに置き換えたい。というより、せっかくクラウドデータ分析の仕事をしているので、この計算もクラウドに置き換えたいと思い立ちまして、今回の記事になります。

【これまでも置き換えようとしたことはあった】
実は、これまでもこの計算をクラウドに置き換えようとしたことはあったのですが、いくつかの課題(次)があって実現しませんでした。
  • 現状の計算には、ジョブスケジューラーとして condor を使っているのですが、これを他の仕組みに置き換えるのは大変。
  • 計算エンジンはC++で書かれていて、いくつかの実行形式に分かれているものを繋いで使っています。高速化にかなりチューニングしているので、これをひっくり返すのは大変。(例えばlightweight系の言語で書き直したりすると、おそらく計算時間が100倍以上になる。)
  • 計算が終わるのにある程度の時間がかかるので、ずっと監視しているわけにいかない。すると、クラウドでCPUを沢山調達してちょっと目を離すと、それなりに無駄なコストがかかってしまう。例えばCPU=128(例えばn1-standard-32を四本)などというモンスターマシンを調達して、計算を実施するのに手間取って数時間つけっぱなしにすると1時間で8ドル、前処理後処理に数時間かかったりするとそれだけで何十ドル、消し忘れて24時間たつと192ドル・・・これは痛い。
ということで、計算ができる、というところまでは試したことがあったものの、実際にクラウドに移行する迄には至っていませんでした。

【今回取り組んだ、最適な組み合わせ】
さて、このように、コスト面でちょっと難があって、というより、今までオンプレの低コストで運用し続けられていたので、実験以外ではあまりクラウド化に消極的だったのですが、先日たまたま見つけた GCP の記事で、これはいけそうだと思い、今回のクラウド移行になりました。その記事はこちら →「HTCondor による高スループット コンピューティング」。
この記事にあるアーキテクチャを少し修正して、料金計算の仕組みを作れると思いまして、取り組みを始めました。記事の図1を拝借して説明します。


この記事は、GCPの Deployment Manager を使って、この図の中にある condor の計算環境をすべて一気にデプロイし、計算を実施し、終わったらすべて削除します。Computeのインスタンスはプリエンプティブで立てるので低コスト。また、何台でも自由に設定できます。よって、この環境をデプロイし、沢山のジョブをSubmitして計算し、終わったら全部消せばよい。消し忘れてもcomputeインスタンスはプリエンプティブなのでコスト的に我慢できなくもない。(もちろん、ジョブが全て終了したら自動的に delete されるように仕込めばよい。)

一方で、現状の計算方法では、前処理、後処理がそれなりにかかり、その後にジョブ発行するので、SubmitするホストはMasterやComputeと一緒にデプロイするのではなくて、別途永続ディスクで立てておきたい。但し、そちらにはあまり大きなCPUリソースは必要ない。また、実はこの記事のサンプルでは master も compute も同じインスタンスタイプで立ち上がるのですが、計算負荷がかなり大きいのに対して、データのジョブの取り回しはさほど大きくないので、master は小さいインスタンスで十分。

そこで、修正後は次のような環境にしました。
  • Submit hostは別立てで用意し、前処理、後処理などの計算およびジョブの発行を実施する。
    • n1-standard-4 を永続ディスクで立ち上げ、condor および コンパイラと、計算環境の一式をインストール。
    • OSはContOS7を利用した。
    • condor の daemon は、MASTERとSCHEDD のみ。なお、submit hist への condor のインストールは、サンプルの中にある startup-submit.sh を参考にすると容易。
  • ネットワークはあらかじめ専用のネットワークとサブネット、ファイアウォールを作っておく。
    • 実は上の記事のサンプルでは、ネットワークとファイアウォールもデプロイ対象になっている。実は condor の環境設定で一番面倒なのはネットワークで、セキュリティをそこそこ意識しつつ、マシン間通信が筒抜けになるように設定しないとうまく動いてくれない。
    • しかし今回は、Subnet hostはこのデプロイとは別に立てるので、ネットワークもあらかじめ作っておいてその中にSubmit hostを置いておく。
  • デプロイマネージャーはmaster と compute だけをデプロイする。
    • ネットワークはあらかじめ作ってあるので、デプロイマネージャーはその中に master および compute を突っ込む。
    • このとき、想定する計算負荷によって、インスタンスタイプやノード数は適宜決める。容易に修正できるのは、デプロイマネージャーを使う利点で、計算エンジンの利用するメモリ容量に応じて(例えば、計算すべき経路が沢山あるところはハイメモリタイプで、そうでないところはスタンダードで)設定ファイルを修正すればよい。
    • まずは、master は n1-standard-4、compute は n1-standard-32、計算ノード数は3で設定した。これで96並列の計算ができる。

このように環境を作ると、作業フローは次のようになりました。

  • まず Submit host のみを立ち上げて、いろんな前処理を実施。
  • 計算エンジンによる並列計算の直前に、デプロイマネージャーから master および compute を立ち上げる。
  • master との通信が確立(*)したら(1,2分かかる)、job を submit する。
  • 計算が終わるのを待つ。もしくは放置する。
  • 計算が終わったら、デプロイマネージャーを利用して master と compute を消す。
  • Submit host で後処理を実施。最終結果をGCSに保存して終了。
  • Submit host を停止する。

これでかなり現実的な計算環境が構築できたと思います。現在は、このGCPプロジェクトのCPU数上限が128なので、96並列×4時間程度の計算になっていますが、CPU数上限を1000程度にすれば30分程で全ての計算を終わらせることができ、しかもコストはほとんど変わりません。さすがに1000並列はGCPさんに負荷を掛けすぎかなと思うので、いまのところは128程度にしておこうと思いますが、クラウド × condor の利用によって、レガシーな分散計算でも容易に環境を作れるようになりました。

【いくつか注記】

・本当は Dataflow がいい
おそらく、このような計算を実施するのにいま最も適しているソリューションは、Dataflow だと思います。が、C++で書かれているレガシーな計算エンジンををうまくラッピングして dataflow に持っていくのが難しそうだったので、今は断念しました。Cloud Functions もありだと思いますが、こちらは1ジョブあたり2GBまでしかメモリを使うことができず、この計算では最大4GB程度まで行くので、こちらも断念。そのうち、利用可能メモリがもっと大きくなったら、cloud functions にジョブを投げまくって回収するのが良さそうです。

・condor の submit - master 間の通信がうまくいかない
上の(*)で示したところ、Submit host と master との通信が確立したら、のところですが、実は現状、ただデプロイするだけではうまく通信ができず、いつまで経っても submit してあるジョブを master が読んでくれません。おそらく、submit host → master の順でマシンを立ち上げているからなのではないかと思いますが、正確なところはまだ理解していません。condor 環境を作るとき、通常は master と submit host が同じマシンだったり、master のある環境の中でsubmit host を立ち上げることが多いような気がしますが、それが逆になることで、submit host の側から master がうまく見えていないのではないかと思います。
これは、submit host の側でcondor の DAEMON をリセットしてあげるとうまく動きました。(systemctl reload を実施)ただ、もっといい方法があるんじゃないかなと思っています。

・CPU数やInner IP数は、googleに上限アップ申請が必要
これらの上限値は、最初はあまり大きくは割り当てられていないので、大規模分散計算をしたいときには上限アップ申請が必要です。1日程度で反映してくれました。CPU数上限だけ上げてもらえばいいと思っていたら、Inner IP数の上限に引っかかって二度手間になってしまいました。ただ、compute の方は、小さいインスタンスタイプを沢山立ち上げるのも、大きいインスタンスタイプで少なく立ち上げるのも、コスト的にはおそらくほぼ変わらないので、大きなインスタンスを少なく立ち上げて、IPなどの資源をあまり利用しない方がいいんじゃないかなと思います。特に、何十個もインスタンスを立ち上げると、外部IPをそれだけ食うので迷惑なんじゃないかと。(外部IPを割り当てない立ち上げ方があると思うので、そうすれば良いかも。)

【おわりに】
ということで、無事、計算環境をクラウド化することができたので、しばらく様子を見て、うまく継続運用できそうでしたら、高速道路料金計算はオンプレとはおさらばになります。
この高速道路の計算を始めたのが2008年頃ですから、それから10年くらいやってきました。1ジョブあたりの計算性能はその頃からあまり変わっていないのですが(エンジンのアルゴリズムやコードもほとんど変わっていない)、並列計算環境や、クラウド環境はまったく別次元で進化しましたね。こんなに使いやすく、また、安価になるとは思っていませんでした。当時はデータセンターで計算サーバーを何十台も借りて並べてもらったり(30CPUで一ヶ月に100万円ほどかかった記憶が・・・)、5年ほど前にはAWSのMapreduceで計算してみたりもしたのですが(当時は課金単位が1時間だったので、100CPUの計算で失敗すると100時間分の課金をされてしまった)、かかる手間と費用と時間が全く違います。高速道路料金の一回の計算にかかるGCPサーバー代はおよそ2000円。何度かやり直しても1万円。前処理や後処理も数十円。もちろん人件費が最も大きくて、情報収集や検証などでしっかりコストがかかっているのですが、サーバー代だけなら一回高々1万円で、96並列の計算環境が利用できるというのは、素晴らしい進歩だと思います。


posted by jinya at 20:07| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2018年05月02日

「前処理大全」(本橋 智光, 2018)を読みました。

「前処理大全[データ分析のためのSQL/R/Python実践テクニック] 」(本橋 智光, 2018)(→amazon.co.jpのリンク)を読みました。内容紹介で、「本書はデータサイエンスに取り組む上で欠かせない「前処理スキル」の効率的な処理方法を網羅的に習得できる構成となっています。」とのことですが、まさにその通り。私がいつもやっていることの大半がちゃんと書いてあって、それが整理されていました。少なくともここに書いてあることはデータ分析をする前に必須のスキルですし、データサイエンスの業界に入門する方はおさえておくのがよいと思います。データサイエンスにおいて、前処理の作業に大半を費やすのはそのとおりで、この前処理部分をどれだけ時間短縮できるかが、データ分析の仕事のクオリティを上げたり、沢山こなしたりする上で重要です。

一方で、前処理は前処理。分析自体はこの作業の次にありますし、そもそも前処理の前に、「仮説」が必要です。前処理を効率的にすることで、データサイエンティスト本来の業務である、仮説設定と検証分析に注力することになります。

本書自体はかなりボリュームがありますが、実施したい内容を、R, Python, SQLの三通りでコードサンプルを掲載してあるので、実際のボリュームはさほど大きくありません。Rだけ、Pythonだけ、SQLだけという読み方もできますし、これまでRしか書いたことなかったという人が、最近はPythonの必要性に駆られてとか、サーバーサイドでSQLだけで処理したい、と言うときに重宝すると思います。


posted by jinya at 16:57| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2018年02月23日

【Excel】でグラフの要素を選択する方法が変わった

Excelでグラフを操作する話。

Excelで作成したグラフにて、各データ系列を選択したい場合、グラフを選択したあと上下矢印キーを押すことで選択系列が順に変わりました。例えば、横軸に時間を、縦軸に東京の気温と札幌の気温を表示した折れ線グラフの場合、[↑]もしくは[↓]を何度か押せば、東京の折れ線を選択したり、札幌の折れ線を選択したりできました。この操作は、最初に作成したグラフの見栄えを細かく手直ししたい場合や、系列が指すデータを変更したい場合などに重宝していたのですが、しばらく前から操作方法が変わったようで、できなくなっていました。グラフを選択してから[↑]もしくは[↓]を押すと、グラフ全体が上下に移動してしまい、選択はグラフを指したままです。

では、選択系列を順に変更するにはどうしたらよいかというと、[ctrl]+[↑]もしくは[ctrl]+[↓]で可能です。両手が必要になってしまったので、ちょっと面倒になりましたが、できないよりはマシです。

実はこの操作ができるようになったのがつい最近で、どのくらいの間だったかは定かではないのですが、半年〜一年くらいは、矢印キーでグラフの要素の順次選択ができない時期がありました。[ctrl]+[↑]でもグラフ全体が動いてしまいます。もちろんグラフの要素をクリックすれば選択可能なのですが、いちいちクリックするためにキーボードから手を離すのは大変ですし、さらには、クリックできないほど小さい系列や、他の系列の裏に隠れてしまっている系列をクリックで選択することは不可能。最終的には、グラフ選択→リボンの「グラフツール」から「書式」→左端の「グラフエリア」と書いてあるところのプルダウンメニューを選択したい系列に変更、という非常に手間の掛かる方法で選択しなければなりません。矢印キーを数回押すだけ、一瞬ですんでいた作業が、何度もクリックする作業に変わってしまって、うんざりしていました。おそらく最近のアップデートで[ctrl]+矢印キーの操作が追加されたようです。
posted by jinya at 17:58| Comment(1) | 日記 | このブログの読者になる | 更新情報をチェックする

2018年02月06日

Excel PowerPivot にて、テキストソースのデータでのカラム追加方法

Excel(2016)のPowerPivotにて、テキストソースのデータでのカラム追加方法です。

テキストデータ(csv等)をソースにPowerPivotにデータを読み込んでPowerPivotを使っていて、データソースを更新したい場合に、元のテキストファイルを新しいものに置き換えたあと、PowerPivotのデータモデル管理から「ホームタブ:最新の情報に更新:更新」を行うと、データを更新することができます。

ここで、元のテキストファイルに新しいカラムを追加した場合、この更新作業だけでは新しいカラムは反映されないので、次のようにします。

まず、データファイルを置き換えます。同じファイル名(絶対パスで)で置き換えるとパスの張り直しをしなくて済みます。パスを張り直す場合は、「ホームタブ:既存の接続」から当該接続を選んでファイルを選びなおしてください。

次に、PowerPivotの管理画面から置き換えたいテーブルを選択し、「デザインタブ:テーブルのプロパティ」を選択します。すると、データの頭の部分をさっと読み直して、カラムが追加になっている場合はそれが表示されます。しかし、新しく追加になったカラムにはチェックがついていません。そこで、導入したいカラムにチェックを入れて、保存します。

すると、自動的にデータを全部読み直し、新しいカラムが反映されます。

これは例えば、旧ファイルでワークシートを作り込んだあとに新しいカラムを追加したくなった場合などに使えます。既存のリレーションやピボットテーブルを壊すことなく、新しいカラムを導入できます。

posted by jinya at 19:14| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2017年11月30日

【Excel】積み上げグラフを比較する

Excelにて、積み上げ棒グラフを二つ比較したいという状況がありまして、その解をみつけたのでリンクを張ります。

https://hamachan.info/win7/Excel/tumigraph.html

こんな感じのグラフができます。

tsumiagegraph.png


「AAA」や「BBB」のラベルを自動的にセンタリングしてくれるのがいいですね。
posted by jinya at 13:09| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2017年11月19日

研究会「日本のスイーツ文化と経営」聴講メモ

2017/11/18(土)、甲南大学で開催されました「日本のスイーツ文化と経営」を聴講して参りましたので、そのメモです。

本研究会はスイーツ学会と日本フードサービス学会の共催で、後援が甲南大学、辻調理師専門学校、辻製菓専門学校、協賛に株式会社神戸風月堂(但し風はかぜがまえに百、フォントがないので、以下「風」で同字を記します)、UCCフードサービスシステムズ株式会社。甲南大学は阪急電鉄神戸三宮と芦屋の間くらいにあって、関東の私からはあまりなじみがないのですが、阪神間の高級住宅街とのこと。そして、今回の主テーマである「神戸スイーツ」は、まさにこの甲南大学を中心とした高級なエリアにすむ「お金持ち」の需要に支えられた文化である、というのが全体を通して流れている通奏低音でした。

それぞれの講師の方のお話が非常に興味深く、沢山の思いつきがあっていろいろ質問したかったのですが、なかなか時間も少なく終了してしまいました。いつかまた先生方にお目にかかった機会にお伺いしてみたいと思います。(いや、その前に自分で調べてみるのがいいですね。)

さて、以下は質問したかったことを忘れてしまわないように、自分のメモです。ただ、メモだけ書いていてはなんのメモだか忘れてしまいそうなので、ご講演のアウトラインも記しますが、これは私が消化した限りしか書けないので、もしかしたら先生方の仰ったことや意図を正しくくみ取れていないかもしれません。あしからず。


最初のご講演は甲南大学の西村先生。「地域スイーツ店の成長とその意味」という題で、いかにして神戸に「神戸スイーツ」の文化が花開き、またそれが支えられてきたのか。またこれを題材として、製造業、小売業とは異なる「製造小売業」における産業集積のご研究でした。神戸のスイーツは神戸港の開港による欧州文化の流入に、大阪で成功した人達が移り住んだ阪神間の高級住宅街の需要が掛け合わさって生まれたもの。これに明治時代の関税増から、それまで輸入に頼っていた材料等が内製化されるようになり、神戸スイーツの産業集積が成ったとのことでした。

さて、同じような街が関東にもありまして、神戸と横浜との違いは何かというのが、私の疑問です。質問もさせていただきまして、横浜は米国系の文化の流入に対し、神戸は欧州系だったことが大きな違い。また、神戸スイーツには原材料供給元として「増田製粉」「日仏商事」の影響が非常に大きく、その原材料を中心とした産業集積があったとのこと。なるほど、フランスがキーポイントのようです。そうか、「洋菓子」というのはフランスのお菓子のことで、それは米国でも英国でもイタリアでもないんですね。和洋という字面から、洋は和以外の海外すべてを指すと思っていたのですが、そうではなくて、「洋菓子」や、ほぼそれらを指す最近の「スイーツ」という言葉はすべてフランスを指すのか。だから、欧州、特にフランスからの文化の流入口だった神戸がその舞台となったし、「横浜スイーツ」を聞かないのもそのせいかもしれません。

ところで、風月堂の日崎さんのお話では、実は神戸には洋菓子と同じくらい和菓子の集積もあるとのこと。ただ、洋菓子店は繁華街や商店街に所在しているのに対して、和菓子店は住宅街に点在しているようで、その対比も面白かったのですが、ともかく洋菓子、和菓子とも職人さんが多い。また、辻調理師専門学校の尾藤さんのお話によれば、今、洋菓子の世界的なコンテストでは日本人の活躍がめざましく、常にトップに日本人調理師がいらっしゃるとのこと。この二つを合わせると、つまり和菓子も洋菓子も根っこは同じ、職人さんのマインドは似ていて、ただ材料や作り方が違うだけなのではないか。造形を美しいと思う感覚や、繊細な味覚などが日仏で非常に近いために、和菓子、洋菓子の世界(日菓子、仏菓子の世界というべきか)が非常に近く、その両方が存在している街が神戸なのでしょう。逆に言えば、フランスの職人さんが和菓子を作るのも相性がいいのかもしれません。

ところで、神戸という街がそういう供給側、製造側として特殊なことはわかったのですが、需要側ではどうなのかというのが、帰りの新幹線の中で考えていたことです。阪神間のお金持ちの文化、ということならば、東京にもお金持ちは沢山いらっしゃいますし、東京はあまりにも人が多すぎてスイーツが目立たないだけで、もしかしたら神戸と同じくらいかそれ以上、レベルの高い洋菓子が集まっていても不思議ではない。では、人口分布に対する洋菓子需要の構造はどうなっているのか。家計消費に占める洋菓子消費の割合や額と、そのボリューム。もしかしたら、お客さんの側の構造は東京や横浜と神戸でほとんど変わらず、ただそのボリュームだけが違っていたりはしないか。洋菓子需要に対する洋菓子店の数はどうか。もしくは、洋菓子需要額自体に関東と神戸とで違いがあって、需要側でも神戸スイーツというのは特殊なのか。横浜スイーツや銀座スイーツというのは単に産地ブランド化されていないだけで、需給の市場としては神戸に負けていなかったりしないか。東京の方が移動可能距離内にある人口が大きいので(洋菓子、特に生洋菓子は日持ちしないので、移動距離が効く)、いわゆる舌の肥えた人口も到達圏内には多いんじゃないか。

京都や金沢など、和菓子文化の街と定量的比較にも興味があります。上で考察したように、和菓子と洋菓子を同一視してみたら、菓子経済はもしかしたら相似形かもしれません。京都はお茶、とのことでしたが、神戸でそれにあたるのはコーヒーでしょうか?フランスとコーヒーはあまり結びつかないような気がしますが・・・。金沢は単純にその菓子経済圏を小さくしたようなものなのか、それともまた別の特色があるのか。海外との接点という意味では、長崎なども気になるところです。

尾藤さんのお話では、世代間ギャップの話が印象的でした。ミレニアル世代の社会に対する意識が、欧州を中心とした「世界」の方向性と近い。持続可能性の問題であったり、フェアトレード、オーガニックに対する感じ方だったり。団塊〜団塊ジュニアで形成された日本型超個人主義的な世代と、共同体への帰属意識が高いミレニアル世代とのギャップ。世界(=欧州?)の潮流がローカルな持続可能性のある共同体を指向していることに対して、日本の食文化は対応できていないけれど、ミレニアル世代の持つ意識が今後は引っ張っていってくれるのではないか。

おそらく、日本的、村社会的な社会主義から、欧州的、市民社会的な社会主義への変化なのだろうと思います。ミレニアル世代は生まれたときから既に世界がすぐそばにあって、容易に世界中の知識が入り込んでくる環境がありますので、そういう傾向が強いのかも。クールジャパンといって日本の文化を世界に発信しようとしても、官製クールジャパンはなかなかクールじゃない。本当にクールなものは勝手に出て行っています。中高年は口は出さずに黙ってお金だけ出すのがよいのかもしれません。

風月堂の日崎さんのお話は、神戸に根ざした菓子を文化に昇華させてきた神戸の歴史、それと一緒にあった風月堂さんのお話で、当時の写真等もみせて頂きながら。橘街道プロジェクトではスイーツトレインなども走っているんですね。丁度先週、会津若松に行った際、磐越西線で開催されているフルーツ列車「フルーティアふくしま」を見ました。こちらも大人気で、予約が取れなくて大変らしいです。郡山から会津若松までの約一時間をフルーツとともに過ごす、または、スイーツトレインで奈良から三宮までの時間を過ごすのは非常に贅沢な空間ですね。

上島珈琲の梅下さんからは、上島珈琲店の歴史と店内スイーツのお話を頂きました。ワッフルが一推しだそうですよ、皆さん!喫茶店は東京では個店がなくなりつつあって、チェーン店ばかりになってきていますが、そのチェーン店も需要が多い時間帯はなかなか入れません。上島珈琲店さんもいつも混んでいて非常に入りにくい。一方で、喫茶店は客単価が低くて大変とのこと。これは需給バランスがうまくあっていないんじゃないでしょうか。上島珈琲店さんは他のチェーン店と比較して見た目のスマートさもあるし、1.5倍程度の価格付けになっても十分お客さんが入る気がします。

もう一つ、せっかくスイーツの研究会だったので、スイーツ×珈琲店で思ったこと。昔の喫茶店は、近所のケーキ屋さんからケーキを持ってきていましたよね?商店街の洋菓子店が慣れないイートインをやったり、喫茶店が自前のスイーツを提供したりするよりも、近隣の洋菓子店ともっとコラボレーションしたらいいんじゃないかと、素人考えながら思いました。配達が難しいのかな?ケーキを一切れ運ぶのはかなりたいへんなのかも。

最後はスイーツ学会理事長加護野先生のご講演。非常にエキサイティングな講演で、いろんな企業名がダイレクトに出てきてそれはここには書けません(笑)。非常に印象深かったのは、神戸洋菓子のクオリティを維持できている理由には、神戸の職人達の間にある強い関係性、職人ギルドのような強い連帯があるとのこと。そういえば、これと同じことを湯布院でも聞きました。湯布院でも湯布院の景観や体験の質を維持するために、強い横の連携、よく言えば相互に高め合う工夫、悪く言えば相互監視し、はみ出し者を排除する機能があるとのこと。他の地域ブランドでも同じことを聞きます。確かに、ブランドを維持するためにはそれぞれが好き勝手なクオリティでやっていてはダメで、最低ラインに届かない職人や店舗を排除しつつ、相互に監視をし、また向上し合っていく必要があるのはある意味当たり前のことです。

一方で、そういう組織的な動きは、新しいものや新しい考え方を受け入れにくい。特に、尖った若者にはそのようなある種旧態依然とした関係性は停滞に見えるし、反発したくもなるところ。伝統を守りつつ、時代に合わせて生き残っていくにはどうすべきか。これは、神戸スイーツだけでなく、すべての伝統文化に共通する悩みですね。

ということで、非常に興味深く、刺激的な研究会でした。帰り、摂津本山駅では時間がなくてお土産を買えなかったのですが、新大阪駅で風月堂さんのゴーフルをゲット。自宅用と会社用と。普段は滅多に会社には買って帰らないのですが(これには理由がありまして、また機会があれば)、今回はやはり本場神戸風月堂のゴーフルを買って帰らなくては、社内で研究報告しても半分も伝わらないですから。
posted by jinya at 02:10| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2017年11月14日

アイデアは積極的に話しておくといい

アイデアはいろんなところで話しておくのがよいですね。

特別に自分だけが思いつくことなんてそうそうありません。自分が思いつくことは、きっと誰かも思いついている。だから、これは面白いと気がついた話は早めに話しておいたり、ブログなどに書いておくと、もしかしたら自分の周りの誰かが実現してくれるかもしれません。

自分で手を動かす気のあるものはもちろんすぐに手を動かすのですが、そうでもないものだったら、誰かが実現してくれた方がいいですよね。思いついたアイデアは基本的にはオープンにして、自分のみの周りをより便利で豊かにしていくのがよいと思います。

ということで、GCPで実現するセキュアでデータにやさしいプラットホーム、お待ちしてます。誰か作ってください! → 「クラウドでのデータ分析を推奨する理由


そういえば思い出しました。スマホが出始めた頃、2010年頃だと思いますが、「仏像クエスト」っていう位置ゲーを作りたいと思ったことがあります。これは結構いいアイデアだと思って、当時は社内でしか伝えなかったんですよね。周りはあまりピンときていなくて、自分ではなかなか作れず、結局お蔵入りになったことがありました。日本全国の仏像をRPGの対戦相手に見立てて攻略していくゲームなんですけれど、有名な仏像は強くて、みんなで協力しないと倒せないって仕掛け。もちろん位置ゲーなので、その場にいかないと戦闘に参加できない。例えば、上野の西郷さんや鎌倉の大仏さんなんかがボスキャラで、10人ほどがそこに集まって対戦する・・・って、今で言うレイドバトルですよね。(もちろん、ポケモンと仏像では集客力が違いますが。)

当時は自分のなかでかなりヒットしていて、大仏さんにカメラを向けるとゴゴゴッて立ち上がったり、周りの仲間にカメラをかざすと服装や武器が見えたり、というのを想像して熱く語るのですが、仏像っていうモチーフが悪かったのか、それとも言葉ではなかなか伝わらなかったのか、ぽかーんとされて終わりでした(笑)。

あと、ネット越しにホワイトボードの共有をしたいというのも、これは20年ほど前ですが、某家電メーカーさんに要望して一蹴されたことがあります。当時は数学の研究をしていたので、海外にいる研究者と手書きの数式をホワイトボード的ななにかで共有しながら議論をしたかったのですが、今ではskypeの画面共有やGoogle Docsなどの共同編集で達成されています。

もちろん、そういう環境にいれば誰しもが思いつくことなのですけれど、広く伝えることでその実現が少しでも早くなれば、便利が自分に返ってきますね。
posted by jinya at 19:16| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2017年11月03日

パソコン甲子園を観戦中

パソコン甲子園の本戦を見に、会津大学に来ています。

残り1時間を切って、開成高校がトップを爆走中。なじみのある高校があまりないのですが、地元の富山中部高校が6位で健闘しています。あと少し、頑張ってほしい!

pccompe.png
posted by jinya at 16:58| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2017年10月27日

便利なGoogle Filestream。但しMicrosoft Officeとの相性は悪いかもしれない。

Google のエンタープライズ向けサービスであるGSuite、そのアプリケーションの一つであるGoogle Driveがこの秋にリニューアルされまして、Googleファイルストリームになりました。

これが非常に便利で、マシンを問わず自分のGoogleアカウントで繋げば、リモートにあるファイルがあたかもローカルにあるかのように取り扱えるというもの。実際にはキャッシュを持っているのですが、全てのファイルを同期するわけではなく、必要なファイルだけ同期するので、ディスク使用サイズが抑えられ、大きなファイルを放り込んだ後に他のマシンでダウンロードに時間が掛かることもなく、さらにはgoogleアカウントとの接続が切れれば全てのファイルが見られなくなるので、セキュリティ的にも感じがいいです。さらには、Gsuite Business以上であれば「チームドライブ」という仕組みが提供されました。これは、当該ドライブの直下のディレクトリは組織内でそれぞれ閲覧権限を設定することができて、閲覧権限のないディレクトリは見えなくなる。例えば、あるプロジェクトで一つディレクトリを作って、それに関係のあるスタッフだけをアサインすれば、アサインされたスタッフのローカルにだけそのディレクトリが現れます。さらにさらに、全てのファイルはクラウド側に履歴が保存されていて、過去の状態を復元することができたり、ファイルを削除してもクラウド側で数日間はファイルが残っていたり、と、業務用として便利が充実。そしてこれらのファイルの全てを検索できる。これは便利。

と、将来はこういうファイル管理がデファクトになるのだろうと思ってしばらく試用していたのですが、一つだけ調子の悪いことがありましたので、メモしておきます。

問題は、Microsoft Office関連のファイルとの相性が悪いこと。そもそもGoogleではMS Officeに替わるソリューションとして、Google DocsやGoogle Spreadsheetなどを提供していますが、これらは、長年の蓄積とそれなりの価格とで非常に高機能に仕上げられているMS Office製品にはまだまだ及ばない。よって今後しばらくはMS Office製品から離れることができないのですが、これらをGoogleファイルストリームのディレクトリの中で使っていると、しばしば壊れます。いや、大きいファイルを取り扱っていると、かなりの確率で不具合が発生しています。

Officeがバックグラウンドで作成するキャッシュファイルについて、これの同期やロックの問題じゃないかと思っていますが、本当のところまではまだ調べていません。ただ、大きめのExcelやWordファイルを保存しようとしたとき、また、自動保存が動いたときに、ファイルの保存に失敗したり、ファイルが壊れたり、書いていた内容が目の前で消えてしまったりと、かなり深刻な破壊が発生します。Officeの中では正しく保存されたつもりでも実際には保存されていないというケースも発生するようで、自動保存からの復元さえできない状況で失われることもありました。これは致命的です。

小さなファイルの編集でこのような現象が発生しないのは、おそらくキャッシュファイル等を作ったとしても一瞬で消えてなくなるために、filestreamが検知しないから、もしくは、検知しても同期が始まる前に無くなるからではないかと思います。しかし、大きなファイルになると一定時間掛かってキャッシュファイルを作って、それと元のファイルとのいろんなやりとりをするのだろうと思いますが、その間に同期が始まってしまって、一部ファイルはロックされていたり、もしくはファイルだけ存在するのにその中身がなかったりと、そういった問題が発生するのではないかと想像しています。

ということで、大きめのファイルをgoogleファイルストリームの中のディレクトリで直接利用する場合は注意が必要です。安全をとるならば、一旦ローカルディスクにコピーして、編集して、戻すのが現状では最もリスクが小さいと思われます。これではGoogleファイルストリームの便利さがほぼ失われてしまうのですけれど。

おそらく、googleではなく、MicrosoftのソリューションであるOne DriveやSharepoitなどではこういった問題は発生しないのだろうと思います。どちらが便利かはなかなか難しいところです。
posted by jinya at 16:20| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2017年09月27日

Googleの誕生日を祝う

今日、2017年9月27日はGoogleの19歳の誕生日だそうです。もう19年も経ったのですね。

Googleの誕生前後は私は大学院生で、大学の計算機室に置いてあるUNIXだったかマッキントッシュだったかを使って「Googleの検索結果が凄い!」と盛り上がった記憶があります。

Google以前、1995年頃はまだ検索サービスというものは無くて、手動で集めて分類されたインデックスサービスがメインでした。海外だとYahoo!、日本だとCSJインデックスをよく使っていた記憶があります。分類されたディレクトリを一つずつ辿っていって、望ましいリンクを見つけて飛ぶ、というもので、辞書で文字を引くのに似ていました。もちろん、インデックスに載っていないサイトにはたどり着けず、有用だけれどメジャーじゃないなURLは人づてに伝達されていました。

日本のインデックスサービスの検索はディレクトリに整理された情報しか出てこなかったのに対し、Yahoo!はディレクトリに整理された情報だけでなく、沢山のインターネット上のウェブサイトを自動的に集めてきて、それを引っかけてくれた点で、画期的だったと思います。おそらくちょうどその頃、Windows95が発売され、パソコンをインターネットに繋ぐことのハードルが一気に下がった時期でしたので、ウェブサイトが飛躍的に増加した時期でもあったと思います。それより以前にはそもそもインターネット上に情報が無く、ほとんどのウェブサイトは大学のサイトだったものが、95年頃から企業がインターネットに顔を出してくるようになりました。

そんなYahoo!の検索は、今までなら絶対にたどり着けなかった情報にたどり着けるようになったという点で素晴らしかったのですが、検索結果はまだまだユーザーフレンドリーではなく、玉石混淆というか、何でもかんでも引っかかって、それが無造作に並べられていたため、目的の情報にたどり着くにはかなりのテクニックを要する状況。そして、96年、97年とインターネットの一般普及に従ってサイト数が爆発的に増加し、Yahoo!での検索が困難になっていきます。

Googleの噂がきこえてきたのはそんな頃だったと思います。スタンフォードになにか凄い検索があるらしい、という触れ込みでURLが伝わってきて、検索をしてみると、まさに「I'm feeling lucky」な検索結果が返ってきたことを憶えています。1997年だったと思っていたのですが、創立は1998年ということで、どこかで記憶が一年飛んでしまったようです。I'm feeling luckyのボタンはその当時からありました。

1998年11月のGoogleトップページを、internet archiveで見ることができます。このトップページのシンプルさも当時画期的でした。Yahoo!もCSJもイエローページも、トップはディレクトリでごちゃごちゃしていたのに対し、Googleは検索窓一つ。全てを検索窓からという思想は既にこのときにあったんですね。

Pagerankの論文も当時触れた記憶があります。最新の数学が一般社会に役立つことはあまりなく、当時は暗号理論に整数論が使われてホットだったくらいでしたが、pagerankの論文は簡単な線形代数でありつつも、目の前でその理論が新しいサービスに結びついて展開されたのは非常にインパクトがありました。

そんな頃からもう19年経ったというのは感慨深いですね。いまや世界中の情報がGoogleにあつまり、Googleを通って世界が動いています。50年前にフレドリック・ブラウンやアイザック・アシモフが預言した世界に一歩ずつ近づいていっている気がしますね。

Answer (Fredric Brown)

The Last Question (Isaac Asimov)

Analyisis of "The Last Question" by Isaac Asimov and "Answer" by Fredric Brown


ちなみに。

フレドリック・ブラウンの「Answer」、実はずっと探し続けていた本でした。おそらく小学生の頃に読んで、そのシーンがすごく印象に残っていたのですが、googleのことを考えるといつもこの話が思い浮かびます。ただ、誰の何という小説だったかさっぱり憶えていませんでした。

科学者は世界中のコンピューターを繋いで、聞いた。
「神はいるか」
「Yes, 今こそ神は存在する」


今回googleのことを書くにあたって、これまで曖昧だった記憶を辿って、そして「Google」の能力を駆使して(!)やっと探し当てました。大人になるまでずっと、このコンピューターってのは2001年宇宙の旅に出てくるHALだと思っていたのですが、大人になってから映画を見直してみてもどこにもそんなシーンが存在しない。星新一のショートショートだったかなとおもって調べても、似ているけれど違う。(「神」という作品があります。)しかし、これを世界中のテキストの中から探し出すことを可能にしたgoogleという仕組みは素晴らしいですね。今は当たり前に存在していますけれど、20年前にはまったくあり得ませんでした。その意味で、確かに「神」は私達の手の中に存在しているのかもしれません。
posted by jinya at 18:54| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2017年09月10日

googleクラウドにたてた Web Server をセキュアに使う

一つ前の記事「クラウドでのデータ分析を推奨する理由」で予告した話題です。ウェブブラウザ経由で利用する分析ツールを想定していて、それに対して簡単かつ安全にローカルからアクセスする方法です。この方法はエンジニアにとっては当たり前のことを繋げただけなのですが、データ分析者にとってはなかなか敷居が高い話題なので、ご紹介したいと思います。

やりたいこと


最近はブラウザベースの分析ツールが増えてきました。JupyterやRStudioなどがその最大手だと思いますが、これに限りません。分析者は主に、ローカルにウェブサーバーをたてて利用していると思います。

一方で、最近はクラウドでデータ分析をすることが増えてきました。上で参照した記事でも書きましたが、データセキュリティの面で安全であること、ビッグデータに対応しやすいこと、計算機リソースを調達しやすいこと、作業を一元管理できることなど、様々なメリットがあります。

この二つを併せて、クラウドでたてたウェブベースの分析環境を利用したい、しかも安全に、というのが今回のモチベーションです。

悩み


しかしそのためには悩みがありました。データや分析ツールはクラウドにあって、ローカルからはブラウザでそのリソースにアクセスしたい。このとき、データセキュリティを保つためには、@通信経路が適切に暗号化されること、A認証が適切に処理されていること。Aは特に、どこからでもID/PWだけでログインできるのはよくない、必ず二段階認証や、公開鍵認証などの方法で本人確認がなされてほしいです。

ここで、ITエンジニアであればこれらを満たす環境を容易に作ることが可能ですが、データ分析者にとってはなかなかハードルが高いです。

例えば一つの案として、クラウドに立てた分析マシンにグローバルのIPアドレスをつけてやって、そのポートに対してhttpで直接アクセスできるようにしてしまうと、通信経路が暗号化されませんから、機密のデータが全て漏れてしまいます。では、https化しようと思っても、SSLの認証が、ポートが、などなど、分析者はあまり得意ではありません。もう一つ、SSHトンネルを使ってローカルマシンのポートをクラウドに転送する方法もありますが、これも多くの分析者にとってハードル高めです。

もう一つ、これは小さな悩みとして。ローカルマシンから計算サーバーへSSHトンネルを掘ってその中を通す手段を確立するところまではできたとしましょう。SSHの通信元はローカルマシン、通信先は計算サーバーのグローバルIPです。さて、計算サーバーは計算をしている間だけ動いていればいいので、使い終わったらいちいち停止します。すると、次に立ち上げたときに、IPが替わってしまうんです。IPは共有資源ですから、使っていない間は占有しない方がいい。よって毎回返すのですけれど、そのために毎回IPが替わって、SSHトンネルを掘る宛先も毎回変えなければならない。この些細な手間が悩みです。(プロキシサーバーをたてるとか、IPでなく名前でアクセスすればとか、もちろんいろいろ方法ありますが、それはそれで事前にいろいろセッティングしなければならないので。計算サーバーというのはある種使い捨てなので、毎回小さな手間がかかるのはデータ分析に差し障りがあるのです。)

GCPでの解決方法


全体図を示します。以下でこれを解説します。ここではブラウザベースの分析ツールということで、RStudio Serverに出演していただきますが、これに限らず何でもよいです。
tunnel.png

google cloud shellはブラウザからアクセスできる小さな仮想マシンで、google側にあります。GCPのコンソールの右上にあるボタンを押せばすぐ、ブラウザでコンソールが立ち上がります。そしてこのマシンは、ローカルとはブラウザで繋がっており、リモートではGCEと繋がっています。このマシンをシエルさんと呼びましょう。また、以下ではGoogle Cloudにある計算サーバーをサブさん、ローカルで操作するマシンをロカさんと呼びます。

ロカさんとシエルさんとの通信はブラウザで行います。シエルにアクセスするにはまずGCPの管理コンソールにアクセスしますから、この時点でロカさんとシエルさんの通信はGoogle Accountで認証されています。Google Accountはほとんどの場合ID/PWと携帯電話などによる認証コード確認の二段階認証されているので、これは安全だと思いましょう。そして、ロカさんのブラウザとシエルさんとの通信はこの認証と、Gooleさんへのhttpsアクセスの中を通っていますので、安全です。つまり、シエルさんのシェル画面が、Google Accountで認証されたhttpsのトンネルの中を通って、ロカさんのブラウザに転送されています。

次に、シエルさんとサブさんとの通信を確保します。ここはSSHでトンネルを掘るのですが、シエルさんには素晴らしい機能が搭載されていて、Google Cloudとの間にアクセス承認がビルトインされています。つまり、シエルさんはGCPで作ったプロジェクトへのアクセス権が、プロジェクトのアクセス権と同等に既に与えられています。ですから、自分が参加しているプロジェクトに対してシエルさんはSSHでアクセスすることができ、逆に参加していないプロジェクトのリソースにはアクセスできないようになっています。さらに、cloud shellは初めて利用する際にシエルさんのインスタンスで鍵ペアを生成して、これを使って自分のアクセス権が設定されたプロジェクトとの認証を行いますので、その鍵を使うときにパスフレーズを入力する(これは、その鍵を開けるための鍵で、初期設定の際に決めます。確かブランクでもよかったと思いますが、何か入れましょう)だけで、あとは公開鍵認証でさくっと認証してくれます。これは便利!

さて、では、シエルさんからサブさんへSSHのトンネルを掘りましょう。GCPコンソールからgoogle cloud shellのボタンを押すと、シェル画面が立ち上がります。これはシエルさんのコンソールです。ここで、

gcloud compute ssh sabusan --project projectSabusan-123456 \\
--zone asia-northeast1-a --ssh-flag="-L" --ssh-flag="8080:localhost:8787"
を実行します。ここで、「sabusan」はサブさんのインスタンス名、「projectSabusan-123456」はサブさんが立っているプロジェクトの名前(フルネーム)、「asia-northeast1-a」はサブさんの立っているゾーン、「8080」はそのままで、「8787」はサブさんに立てたRstudio Serverへのアクセスポートです。なお、8787はRStudioのデフォルトポート、つまり、なにも指定しなければ8787番で立ち上がりますが、普通のhttpでサブさんのツールを立ち上げた場合は80番になります。ここはサブさんのなかで何を使うかによって適宜変更してください。

「gloud compute ssh」はgoogle cloud用のsshで、これを使うとGCPの中での用語を使ってsshアクセスできます。つまり、「sabusan」や「projectSabusan-123456」という名前をうまくIPに変換してくれて、その認証なども考えてくれて、正しくアクセス先に導いてくれます。上で、IPアドレスが毎回変わるのが面倒ということを書きましたが、ここではプロジェクト名とインスタンス名で通信経路を確保できるので、その悩みはなくなります。最後に、もしシエルさんのキーペアにパスフレーズを設定している場合はそれを入力すれば、無事、SSHの接続が完了します。

これで全ての通信経路が確保されました。最後に、ロカさんのブラウザ上に開かれたシェル画面の右上にある「ウェブでプレビュー」ボタンを押し、「ポート上でプレビュー8080」を選択すると、ブラウザで新しい画面が立ち上がって、サブさんでサービスしている画面、この例ではRstudio Serverの画面に繋がります。

ロカさんとgoogle cloud platformはインターネットで繋がっていて、ここが一番危険な場所ですが、そこを守っているのがSSL, Google Account認証です。そしてここはGoogle Accountでログインしていれば既に守られています。つまり、Google Accountの取り扱いさえ気をつけていれば大丈夫で、それは普段から気をつけている場所なので、問題ありません。特に、会社のメールにGSuiteを使っているところは普段からしっかり対処しています。そしてそのSSLのトンネルはシエルさんまで繋がっていて、シエルさんとサブさんは先ほどの「gcloud compute ssh 〜」でsshのトンネルを作りました。最後に、サブさんに組み込まれたRStudio Serverで作られたRStudioの画面は、SSHのトンネルとSSLのトンネルを通ってロカさんのブラウザ上に表示されます。

便利なところ


この方法の便利なところは、使うまでのアクションが三つだけだということです。(サブさんでのサーバーのインストール等の時ではなくて、すべて設定が終わって、普段分析用に利用するときです。)

@インスタンスを立ち上げる


まずは計算サーバーを立ち上げる必要があります。通常、分析するインスタンスは大きなリソースを割り当てるのが普通なので、作業が終わったら落とて、使うときに立ち上げます。これはGCPコンソールのGCEから、停止状態にあるインスタンスをクリックして「開始」すればOK。なお、RStudio Serverは自動起動するように、RStudioをインストールする際に設定しておいてください。

AGoogle Cloud ShellでSSHを指示する


上に記した、「gcloud compute ssh 〜」を実行します。このフレーズはマシン名が変わらないため毎回同じなので、cloud shellの中にメモを残しておくか、そのままスクリプトにしておいてもいいとおもいます。cloud shellはGoogle Accountが存在する限りずっとなくならないはずなので、ブラウザでGCP〜cloud shellにアクセスすればいつでもそのメモはそこにあります。

Bポート上でプレビュー


最後に、「ウェブでプレビュー」から「ポート上でプレビュー8080」を選択すれば、サブさんで立ち上がっているRStudio Serverに接続して、RStudioが使える状態になります。

安全なところ


経路は全てSSLまたはSSHで暗号化され、インターネットを通る認証はGoogle Accountによる認証だけです。Google Account認証は通常二段階認証で、普段よく使うアカウントですから、リスクが低いです。SSHもGoogle Cloudの中だけですし、認証は公開鍵認証がデフォルト、かつ、自身が割り当てられたプロジェクトにしかアクセスできないようになっています。そして特にこの方法では、プロジェクトにアクセスできるのはブラウザでGoogle Account経由、もしくはSSHでの接続だけで、httpやhttpsのポートを開けているわけではありません。プロジェクトに侵入する経路が少なければ少ないほどよく、SSHはデフォルトで開いていますが、公開鍵認証が必須なので問題ありません。サブさんのグローバルIPも立ち上げなおす度に変わるので、リスクは非常に小さいと言えます。

おわりに


以上、googleクラウドにたてたブラウザベースの分析ツールをセキュアに使う方法でした。

このように、クラウドを安全に使う方法がどんどん便利になってきていて、便利になるからこそまた安全性が増します。不便だったり、様々な知識が必要だったりすると、手抜きや知識不足のためにセキュリティが下がる可能性があるので、便利になることはいいことですし、将来的にはもっともっと便利になると思います。
posted by jinya at 11:49| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2017年09月08日

クラウドでのデータ分析を推奨する理由

私の仕事では日頃からデータ分析を仕事としているのですが、普段の行動で最も気をつけているのが、「データのセキュリティ」です。

【現状のデータ分析におけるリスク】

データ分析という仕事はお客さんのデータを預かり、これを様々な切り口で切って観察し、仮説をたてて検証する、というプロセスを何度も繰り返すのですけれど、ほとんどの場合でその預かるデータの機密性が非常に高い。それは当然で、ビジネスにおける様々な課題について、その意思決定を左右するような力をそのデータが持っているわけですから、これが軽々しく流出してよいわけがありません。

さて、そういう「虎の子」のデータを普段どうやって取り扱っているかというと、すべての局面で様々な対策をとっています。

*受け渡しから結果報告まで

まずは受け渡し。データを預からないことには始まりませんので、お客さんからデータを預かります。最近でこそ暗号化してメール添付やウェブストレージで受け渡しということが多くなってきましたが、まだまだポータブルハードディスクで現物渡し(もちろん、内部のデータは暗号化済み)とか、USBメモリに入れて郵送(これも暗号化、送付はトラッキング可能な方法で)というケースがあります。

そして実際の加工や分析の場面。預かったデータを取り扱うマシンはディスク暗号化、ログインのポリシーも強め(これを書くとセキュリティが下がるので書けません)、どのマシンに入っているかとか、誰が取り扱えるかなど、ちゃんと管理します。基本的には担当者のみがそのデータを扱うことができて、同じ社内でも担当の違うデータは扱えません。PCやポータブルハードディスクは施錠管理ですし、すべて暗号化してあるので、万が一盗難があった場合でも大丈夫にしてあります。

分析の結果をお客さんと共有する際も、昔は分析報告書を紙に印刷して現物納品というのが多かったのですが、最近はほとんどが電子ファイルでの納品で、ワードやエクセル、パワーポイントなどのドキュメントの他、分析コードや簡易ツールのコードなども電子媒体で納めることが多く、これらも暗号化してメール添付や暗号化して現物送付など、受け渡し方法に応じて対策をとっています。

*本当のリスクはどこにあるのか

さて、このように、どうしてもデータやそれに関する資料が動くものですから、それが行き来する度にリスクは発生します。「絶対安全」であることを目標としてもちろん対策をとっているのですけれど、理論的にはリスクに「絶対」はあり得ませんので、必ずリスクが存在します。

そして実は、このデータのリスクというのは私達のように外部でデータ分析の仕事を実施している会社にとどまりません。むしろ、私達はそれが本業ですから様々な対策をとっていますけれども、本当のリスクはお客さんの側にあると感じています。たとえば、データが暗号化されていない状態でPCに入っていないでしょうか。もしくは、会社内の計算サーバーがハダカの状態で足下に転がっていたりしないでしょうか。近年はSIにおけるデータのセキュリティというのは非常にうるさく言われていて、情報漏洩の事故が起きる度にセキュリティ投資が行われ、どんどん堅牢に(その一方で使いにくく)なっていますが、データ分析はアドホックに実施されることが多いので、堅牢なシステムからデータを一時的に吸い出して、手元のPCで操作するというケースが非常に多いです。堅牢すぎるシステムの中では、それが堅牢すぎるために、分析ができる環境を作る余地がありません。その結果、リスクが手元に集中します。

【クラウドの方が安全】

さて、そういう環境の中で最近にわかにクローズアップされてきたのが、クラウドです。Amazon Web Service、Google Cloud Platform、Microsoft Azureなど。2003年頃からビッグデータの時代に入り、今ではビッグデータの取り扱いはクラウドの力無しでは非常に難しい。しかし、プライベートクラウドならばまだしも、これらのオープンなクラウドでデータを取り扱うのは危険なんじゃないか。自社のデータが、その他大勢のデータと混在して置かれているのはリスクが高いんじゃないか。

数年前まではそういう話もよく聞きましたし、実際にクラウド事業者のセキュリティに関する関心度やレベル感もまちまちでしたので、そう言われても仕方がない面はありましたが、ビッグデータの波が一段落して、つまり、「ビッグデータ」がバズワードから本当に意味のあるものが選別されてきた頃から徐々に、ビジネスで使えるクラウドとは何かという部分でコンセンサスが取れてきて、各社、セキュリティの担保に非常に力を入れてきています。ですから、五年前まではまだ言えませんでしたが、今は確実に、「データはクラウドにある方が安全」です。受け渡しのリスク、盗難のリスク、暗号化してないリスクなど様々なリスクが、クラウドを利用することで解消されます。

*クラウドデータ分析のワークフロー

ここではGoogleのクラウドサービスであるGoogle Cloud Platformを例に挙げますが、他のクラウドでも、使いやすさや構築のしやすさが少し異なるだけで大体同じように使えます。

Google Cloud Platform、以下GCPと略しますが、ここではまず「プロジェクト」という単位で全てのデータが管理されます。この概念がデータ分析では好都合で、あるデータ分析プロジェクトが始まったら「プロジェクト」を作り、その中で全ての作業を行います。セキュリティもプロジェクト単位で設定できるので、誰がこのプロジェクトに参加するのか、それぞれどのデータをどのように扱えるのかなどを決めることができます。

次に、データ元はデータをそのプロジェクトにアップロードします。GCPでは様々なデータベースが備え付けられていますが、特別な操作をしない限りそれらのデータはプロジェクト以外からは参照できず、プロジェクトの参加者、さらに、参加者のうちでもデータを閲覧する権限を付与されたアカウントのみが、そのデータを見ることができます。

データを加工するのは、そのプロジェクトの中で利用される様々なサービスです。最近ではgoogleが用意している人工知能APIなどが強力で、テキスト解析や画像解析の前処理などは学習済み人工知能を用いて前処理ができます。また、bigqueryやdataprepなど、データをアドホックに操作加工できるツールもあり、さらには備え付けられていない処理はCompute Engineというサービスで計算サーバーを立ち上げ、それがプロジェクト内でデータを受け取り、加工し、またプロジェクト内のデータベースに返すことで処理することができます。

そのようにして加工されたデータを実際に分析するのも、Compute Engineで立ち上げた計算サーバーを利用したり、最近では機械学習のAPIを利用したりします。機械学習をAPI化したサービスはいま大流行していますから、google, amazon, microsoftの大手三社もこれからリリース合戦になりそうです。人工知能の花形である深層学習、googleではTensorflowもAPIで利用できますし、予測系でよく利用されているXGBoostなどもそのうちAPI化されるでしょう。APIになっているものはそれを利用し、そうでないものだけ計算サーバーをたててプログラミングする、そういう時代になってきました。

*クラウドが安全な一番の理由

そして、ここに述べた一連の作業において一番のポイントは、全ての作業が「プロジェクト」の中で完結するということです。データをローカルにコピーしないポリシーにすれば、全てのデータはクラウドのプロジェクト内に収まっており、そこから外に出ることはありません。ローカルにコピーする必要がなくなることは、データセキュリティ的にもリスクが小さくなり、機密情報の漏洩に怯える必要がなくなるため、精神衛生上も非常に良い効果をもたらします。ログインに二段階認証を義務づければ、第三者がアカウントを乗っ取って入ってくるリスクも非常に小さくなります。そして最後に、プロジェクトを削除することで、すべてのデータが無事に消えます。私達の側では、どのマシンでどのデータを扱っているかというトラッキングをする必要がなくなり、データを観察することに集中できますし、お客さん側ではプロジェクトが消えたことをもって全てのデータが安全に消去されたことを確認できるわけですから、安心です。

*特に、GCPの特徴

また、これはGCPの特徴なのですが、アカウント管理が非常に分析者向けにうまくできています。GCPにおけるプロジェクトへの参加は基本的に自身のGoogle Accountを用います。Google Accountというのはメールやカレンダー、ウェブストレージなどを束ねたそれらのすべてを使うためのもので、エンタープライズ向けにはGSuite(旧google for work)というサービス名で提供されています。エンタープライズ向けなので企業向けにしっかり管理されていて、これを導入している企業では毎日のようにメールやカレンダーツールとして利用しています。その毎日利用しているアカウントを用いて、GCPにログインすることができるのが、セキュリティを大きく向上させます。

その理由。エンタープライズ向けメールというビジネスの基幹とも言うべきツールですから、皆さんかなりセキュリティに気をつけています。多くの会社は二段階認証を用いていると思います。Google側も不審なログインには目を光らせています。そして、毎日使うものですから、アカウントに異常があったときに気付きやすい。気がつくのが早ければ早いほど、なにかあっても被害は小さくできます。

プロジェクト毎にアカウントを作ったりすると、どのプロジェクトでどのアカウント、どのパスワードだったかを管理しなければならず、そこにリスクが生じますが、毎日基幹で使うものは皆さん堅牢に使っても慣れますよね。

プロジェクトへの利用権の追加は基本的にはこのGoogle Accountを抜き差しするだけです。最近のデータ分析者はもちろんある程度こういう情報インフラの扱いに慣れているのですが、セキュリティ管理をするのが仕事ではなく、仕事はあくまでもデータの分析ですから、「google accountを入れるだけ」という簡単さでセキュリティが保たれることが非常に大事です。これが難しいと、専門のシステム担当者をつけなければならず、コストが高く付いてしまいますが、そういう面倒だけど大切な部分をGCPが肩代わりしてくれるのは、データ分析者にとっては非常にありがたいことです。

このように、データ分析プロジェクトとクラウドは非常に相性がいいんです。実は、これによって私はAWSでデータ分析を行うことのストレスから解放されました。AWSでは基本的にはことあるごとにIAMを作りますが、これはシステム開発的視点なんだと思います。作ったシステムが長期にわたって使われて、開発者はある段階でそこから抜けるので、特定のアカウントだけ消したい。でも、データ分析プロジェクトでは逆で、分析者は居続けるのだけれど、プロジェクトの方が完結すると消えてくれます。だから、GCPはデータ分析と非常に相性がいい。おそらくそのうち、私の会社のようなデータ分析をする企業は、ほとんどがGSuiteを利用して、GCPでデータ分析をするようになるのではないかなと思えるくらいです。

【分析クラウドの弱点】

しかし、このように万能に見えるクラウドデータ分析ですが、弱点もあります。

*グラフィカルツールの導入が遅れている

データ分析は、データを様々な形で観察し、そこからヒント(=仮説)を得て、検証するというプロセスを何度も何度も繰り返しますが、そこで非常に大切なのはビジュアリゼーション、可視化です。手元にデータがある場合には、ExcelやRstudio、Jupyterや、SPSS、Amosなど、視覚に訴えるツールが沢山ありました。これが、クラウドに移行したらコンソール作業しかできない、なんて状況になってしまったら、浮かぶアイデアも浮かばなくなってしまいます。データ分析に可視化の便利さは必要不可欠です。データをぱっと入れたらぱっと出てきてほしい。そこに、いちいち画像をダウンロードしたり、データをダウンロードして手元で可視化したりなどしていたら、クラウドで作業している意味がなくなってしまいます。

もっとも、これまでもグラフィカルツールが全く利用できないわけではありませんでした。昔はX-Serverなどがありましたが、最近ではウェブベースで画面が提供されます。Jupyterはそうですし、RstudioもRStudio Serverはウェブベースでの分析環境を提供してくれます。しかし、それをクラウドに仕込んで、遠隔からアクセスするにはhttpやhttpsのポートをあけるか、sshでトンネルするか・・・そういう作業は多くの分析者は苦手とするところなので、簡単に、セキュアに、ウェブの画面をこちらに飛ばしてくれるような環境が望まれます。

実はその動きは既に始まっており、GCPでは、Jypyterはcloud datalabというサービス名で最近提供され、簡単にウェブベースのクラウド分析プラットホームとして利用できるようになりました。一回だけコマンドラインで命令を入れる必要があるのですが、あとはブラウザに出てきたボタンを押してJupyterを利用することができます。

RStudioも、ローカルのRStudioを利用して、クラウドのRStudio Serverの仮想マシンを立ち上げ、アクセスすることを簡単にする試みが始まっています。(GoogleComputingEngineRからRのDockerで立ち上げる試み)このケースではまだ簡単にウェブアクセスができる部分が抜けているのですが、これも時間の問題でしょう。もちろん、ネットワークやクラウドを理解している人はセキュアなトンネルを掘ってその中を通してセキュアにアクセスすることは可能です。(私も次の記事でその方法について書く予定です。)

*プロジェクト管理ツールがない

大手三社のサービスをデータ分析プロジェクトの視点で眺めていると、プロジェクト管理ツールがないことに気付きます。ドキュメント管理やタスク管理、チャット、スケジューラーなどは、そのプロジェクトのために使えるツールが付いていると嬉しい。なぜなら、データ分析プロジェクトにおいてはドキュメント自体が機密情報満載ですし、タスクも詳細に記すと機密情報に触れざるをえなくなります。多くのプロジェクトでは外部のプロジェクト管理サービスを利用したり(その場合、機密情報は別で管理しなければならなかったり、セキュアであっても情報がプロジェクトの外に出てしまう)、Google Docsなど、同じアカウントで管理されているけれども、プロジェクトの外にあるリソースを利用しなければならなくなってしまう。これでは、「プロジェクト内で完結」の理想から外れてしまいます。

ですから、これらのツールがプロジェクトに紐付いて提供されることは、データ分析プロジェクトのセキュリティをさらに向上させ、分析者を分析以外のことで悩ませる時間が減ります。

なお、仮想マシンを立ち上げて、そこにプロジェクト管理ツールをインストールして利用するという手はもちろんあります。しかしその場合、管理ツールを管理するエンジニアを別にアサインする必要が出てきて、コスト高になります。繰り返しますが、データ分析者はそういったツールのセッティングやセキュリティに精通しているわけではないので、SaaSで提供されればそれに越したことはなく、それがプロジェクトに紐付いていてくれれば、「プロジェクト内で完結」します。

*遅いか、高いか

これはデータ分析のワークフローの特徴なのですが、データ分析にはデータをあれこれ眺めながらう〜んう〜んと考えている時間と、考えがある程度まとまって、分析の方針が決まって、えいやっと巨大なデータを加工したり、大量のCPUやメモリを使って大規模な計算を実施する時間があります。それが間欠的にやってきます。すると、考えている時間は計算リソースをほとんど使わず、計算している時間は大量に計算リソースを使うので、大きい方にあわせて計算機を動かしておくと、使っていないのにどんどん費用が嵩んでいきます。かといって、使っていない時間が勿体ないからと小さいリソースしか割り当てないと、いざ計算したいときには全然計算が終わらない、などというクラウドらしからぬ時間が勿体ない状況になってしまいます。

ですから、データ分析は仮想マシンを立ち上げて実施するのではなく、本当はSaaSで実施できるのが嬉しい。例えばR ServerのAPIが提供されていて、それにデータとリソース規模を入れてあげれば、裏で巨大なリソースが動いて、数時間後に答えが返ってくる、など。RStudio Serverの裏で自由にRのAPIが利用できるような環境になったらいいですね。TensorflowはAPI化されましたから、要望が多ければその可能性もあるでしょうし、そういう汎用分析APIがもっと多種多様にできてくると、クラウドデータ分析の利用価値がもっと高まります。


【最後に】

現状ではもちろん、お客さんの了解がなければデータをクラウドで分析することは許されませんので、ローカル環境を使うことがまだまだ多いです。しかし早晩、クラウドに置き換わっていくでしょう。クラウドのセキュリティがちゃんと認識され、ローカルに受け渡ししたりすることのリスクと同じ天秤に掛けられるようになってくれば、自然とデータはクラウドで取り扱われるようになっていきますし、ローカルで取り扱うリスクやコストが何倍にもなることが意識されていきます。その環境をgoogleが作るのか、AWSか、Azureか、はたまたアリババクラウドのような新興勢力が市場を根こそぎ持っていってしまうのか、ここから5年くらいが最も激動の時期になるんじゃないかなと、思っています。
posted by jinya at 21:45| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2017年08月03日

WordでLatex

LaTeXで数学、物理の論文を書いたことのある人はどのくらいいらっしゃるのでしょうか。MS Wordでは長らく数式を美しく、読みやすく入力することができなかったので、数学物理など、数式を主に取り扱う論文では圧倒的にLaTeXを使う方が多かったと思いますが、最近、Office 2007頃からだったと思いますが、数式エディタが刷新されてからは、Wordでもそこそこ美しく数式を入力することができるようになったので、もはやLaTeXに頼ることがなくなりました。

過去記事:
Word2007の数式エディタが実はすばらしいこと
マシになった(はず)のMS数式エディタをTeXと比較

さて、そういうところに最近のニュースで、「LaTeXを使った数式の入力がWordやPowerPointで可能に。マイクロソフトが明らかに」というのを見かけました。これは今までの数式エディタと何が違うのでしょう?

MS Wordの数式エディタの入力は、LaTeXっぽい入力ができるのですが、まだまだ開きがありました。例えば、文字自体を操作するのは(例えばギリシャ文字や記号など、また、上付き、下付文字等)ほぼLaTeXと同様の記入感でいけるのですけれど(これをUnicodeMathと言うそうです、参考:「Linear format equations using UnicodeMath and LaTeX in Word」)、分数や記号の入れ子など数式が多段になっているところは、記号を入力すると出てくる箱にうまく文字を入れてやらなければなりません。例えば、分数を入力するには「a/b」と入力すると自動的に

\begin{eqnarray}
\frac{a}{b}
\end{eqnarray}

と書いてくれるのですけれど、あくまでも「自動的」なので、本当は縦でなくて横のまま

\begin{eqnarray}
a/b
\end{eqnarray}

と書きたかった場合でも勝手に縦になってしまって、わざわざ横用の分数をマウス操作で選択してあげなければならない。つまり、やりたいことの7割くらいは簡単にできるようになったのだけれど、もうちょっと融通きいてほしいなぁと思うところはまだ残ってました。それでも、昔の数式エディタと比較すれば入力のしやすさも数式の美しさも格段に良くなったのですが。

ということで、今までの数式エディタはあくまでも数式用文字の入力が簡単になっただけでした。それが今回の記事によれば、LaTeX側にもっと振れて、数式の構造自体をちゃんとLaTeX式に入力ができるようになる。例えば上の分数は、「a/b」と打って自動的に縦にしてもらうのではなくて、ちゃんと「\frac{a}{b}」と入力することになります。(なお、横向きにa/bと書くときには普通にa/bと書けば良いです。)

ちなみに同記事によれば、日本語版への適用はまだまだ先とのこと。待ち望まれます。
posted by jinya at 17:05| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2017年04月28日

共起関係を用いたアイドルネットワークの分析

ゴーガ解析のメンバーの石田さんが、共起関係を用いたアイドルネットワークの分析をしています。

アイドルに関するデータ収集〜分析:1.1TwitterデータからDD度の可視化

彼はこの春からアイドルオタクになったそうで、業界的にめちゃめちゃ忙しい年度末をアイドルパワーで乗り切ってくださいました。仕事がしんどいときでも笑顔でアイドルのことを語ってくれるので、アイドルに救われるっていうのはこういうことを指すのだなぁと思いました。

さて、彼の分析結果、まだ途中だと思いますけれど、これを見てコメントです。

各アカウントのフォロワー直近500人をとってきているとのことですが、これは少なくとも時期をランダムにするか、もっと量を増やすべきだと思いました。twitterのデータは、ボットやスパムアカウントの影響をどうやって排除するかというところがいつも難しくて、直近500だとその影響が大きく出てしまうのではないかという懸念があります。収集数を増やせばその影響は減りますし、時期をランダムにしても同様の効果が出ると思います。一方で、twitter apiの制約もあると思いますから、そのあたりで妥協しなければならないところもあると思うのですが。

AKB系とハロプロ系で様相が全く異なるのは、記事にもあるとおりタレントさんご本人のアカウントの影響が大きい気がします。グループのファンなのか、タレントさん個人のファンなのかというところで、ファン心理が違うのかもしれません。また、分析者本人がハロプロファンなので、AKB系のファンの動向がよくわかっていないのも、これから補強すべき所なのだろうと思います。

データ分析をするときは、その業界なりその市場に対する深い理解と愛情が必要になります。それなしには市場のメカニズムを想像することなどできません。この現象は、こうなんじゃないか、ああなんじゃないか、と、様々な想像を巡らせて、仮説を作り、検証する、の繰り返しです。一方で、あまりに深入りしすぎて森が見えなくなってしまってもダメなのが難しいところ。主観が入りすぎると、仮説が恣意的になりすぎます。そのシステムに愛情を持ちつつ、一歩引いて客観的に仮説を想像するのが、データサイエンティストのポジションです。

最後に、共起関係のネットワークを見るポイント。

共起ネットワークは、実は繋がっているところを見ていてもあまり面白くないんですね。これは、繋がっていないところを見るべきなんです。なぜここは繋がっていないのかを考えると、いろんな仮説が出てきます。例えば記事中の図を見ると(これはまだ途中の画像なのでこの先変わるかもしれませんが、ひとまず今の段階で見ると)、NMBとHKTのつながりが非常に薄い。これはなぜか。また、ネットワークの外側にあるのはJKT, BNKに加えて、momowgp、つまりももクロが外側にいて、他とのつながりが薄い。JKTとBNKは両方とも海外にあるので、共通のユーザーがいないことの意味がなんとなくわかりますが、momowgpは国内で、かつフォロワー数もそこそこ多いにもかかわらず、孤立しているのはなぜか。このあたりに仮説の種がありそうです。
posted by jinya at 12:42| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2017年04月10日

ノッティンガム大学

懐かしくなって、ノッティンガム大学の地図を見ていたメモです。

通っていた校舎。さすがに約20年ほど経っているので、壁が新しくなっていますが、当時の面影が残っていました。

と思ったら、別の写真では新しい建物が!撮った時期が違うんですね。

お世話になった学生会館みたいなところ。こちら側が当時の面影のある建物なのですが、これも、取り壊されて更地になっているstreet viewが近くにありました。ここでインターネットの契約をしたり、100ポンド紙幣を出して売店のおばちゃんに目を丸くされたり(当時、100ポンド紙幣は通常流通しておらず、偽札じゃ無いかと思われて念入りに調べられました)。

通学路。冬は何にもない道なんですが、春にはこれらに全部花が咲きます。4月後半〜5月が最高に美しい道です。

住んでいた留学生会館。こんなゲートは無かった気がしますが、建物はたぶん変わっていません。留学生の他、海外から短期間招聘された先生などもここに住んでいました。

住んでいるところから一番近いスーパーマーケット、Sainsbury's。ここには米と醤油があったので、キッチンで炊き込みご飯っぽいものを作っていました。椎茸の代わりにマッシュルームを入れて、鶏肉と野菜で。パンは麦の粒がごろごろ入っているもの。

ノッティンガム駅。あちらでは長距離バスがかなり発達しているので、移動は基本的にバスでした。ノッティンガム駅は一度しか使ったことがありません。今はsuicaのようなものがあるらしいですが、当時は改札というものがなく、切符は自己申告で、停車駅ではアナウンスも無いので、常に注意していないと乗り過ごしてしまう。しかも、英国では乗り過ごしたら罰金、不正乗車の罪になりましたので、めちゃめちゃ緊張しました。

ノッティンガム城。唯一(?)の観光名所。ロビンフッドの像があります。でも、たまにしか来たことがありません。ほとんどは宿舎と大学を行ったりきたりでした。
posted by jinya at 18:03| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

クラークスのビジネスシューズ

先日、十何年ぶりかに渋谷のクラークスに行ったところ、ビジネスシューズの取り扱いがあって、大喜びした話です。

クラークス(Clarks, http://www.clarks.com/ )はイギリスの靴メーカーで、創業1825年とのことですから、およそ200年ほども続いている老舗です。私がまだ学生時代、イギリスの中部にあるノッティンガムというところに留学していたとき、靴を買いたいんだけれどと相談したところ、中心街にあるこのお店を、この街で靴を買うならここしか無い!っていうくらい猛烈に勧められて、黒いビジネスシューズを購入しました。このお店です。(→street view )まだ残っていました、さすがイングランドです。

さて、その後日本に戻ってきて就職し、数年はこのときに買った靴を愛用していたのですが、あるときついに破れてしまいまして、同じ靴はないかと思い日本の取扱店を探したのですが、まったく見つかりません。15年ほど前でしょうか。当時、日本のクラークスでは、コンフォートシューズの取り扱いしかなく、クラークスというブランドは普通の靴メーカーではなくて、コンフォートシューズメーカーという位置づけでブランディングされていたんです。ですから、本国では普通の靴メーカーで、ビジネスシューズもお店にたくさん並んでいたのに、日本では結局それらを買うことはできませんでした。当時はまだネット通販など始まったばかりで、amazon.comも本しか売っていなかった時代ですから、日本にいてイングランドの靴を買うことは困難でした。

その後、私の靴探しの放浪が始まります。合う靴が全く見つかりません。おそらく足の形が悪いのと、無理に合わない靴を履いたせいで足の指の関節を痛めてしまい、今でも合わない靴を履くとすぐに痛くて歩けなくなってしまいます。ですので、結婚式などどうしても履かなければならないときには我慢して履きますが、基本的には黒いスニーカーなどをで代用していました。そうすると、スーツなどもだんだん着にくくなって、ジャケットにチノパンという格好が多くなりました。思い出すたびに買ってはみるのですが、数回履いては捨てることも何度も。5万円ほどするのも試しましたし、いろんな形を履いてみて、たまに変な形のでしばらく我慢して履いてフィットさせられても、変な形なのですぐ廃番になってしまってまた放浪です。

ということで、ビジネスシューズにはずっと悩んできたのですが、先日上のクラークスの国内店舗(渋谷店)を何気なくのぞいてみたところ、なんとビジネスシューズが並んでいるではないですか。驚いて店員さんに尋ねてみると、数年前から取り扱いしているのだとか。早速一足はいてみたところ、柔らかいし、フィットするし、即決で購入、ついでに近所のお店で最近来ていないスーツも購入して帰りました。いまのところ快適に履いています。やっと自分が履ける革靴のお店が見つかりましたから、これからは、いままで茶色の革靴が無かったため(黒さえ見つからない状態なので)に着られなかった淡色のスーツやパンツも合わせられそうです。
posted by jinya at 17:16| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2017年02月22日

巨大なcsvファイルのヘッダだけ取り替えたい

巨大なcsvファイルのヘッダだけを取り替えたいということがしばしばあります。例えば、あるソフトウェアにデータを読み込ませたいのだけれど使用できない文字が入っているとか、ヘッダにだけ2バイト文字が入っていて、それらを英数になおしたいとか、ヘッダをつけ間違えたとか。でも、大きすぎてエディタで開いて修正することはできないし。

修正したいヘッダ付きのcsvファイルをA.csvとし、修正済みのヘッダだけを一行書いたファイルをH.csvとします。A.csvのヘッダをH.csvで取り替えて、B.csvに出力します。

コマンドラインから、

cat H.csv <(cat A.csv | tail -n +2) > B.csv

でOK。一つ前の記事でも使ったプロセス置換です。

この方法が本領発揮するのは、巨大なデータファイルがgzipされているとき。そもそも大きいファイルは圧縮されていることが多く、これらを展開するとやたらディスクを食うので、できれば圧縮したまま取り扱いたい。その場合には

cat H.csv <(zcat A.csv.gz | tail -n +2) | gzip > B.csv.gz

こうすれば、展開ファイルを作ることなくヘッダを取り替えられます。

posted by jinya at 23:29| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする
×

この広告は180日以上新しい記事の投稿がないブログに表示されております。