前にIoT,ビッグデータ,CEP,機械学習,SDN等の全体像をまとめてみた－概要を書いたけど、あれだけでは、抽象的なので、具体的に、どのような製品があって、どう動くのかのイメージがつかめないと思うので、そこを書いてみた。
まず、全体図。
以下、製品を交えた説明。上記「概要」の説明と比較できるように書いてある。
ただ、順番をかえて、まずは、IoTから。
■IoT
○デバイス
センサーは、例えば温度センサーは、温度が上がると抵抗値があがる。ということは、電圧が一定なら電流が変わる。
このように、計測したいもの（温度）の変化によって、抵抗などがかわり、電流、電圧が変わるというしくみでセンサーは動いている（ものが、たぶん多いと思う）。
このセンサーをデバイスのポートに線でつなぐことにより、この電気変化が、電気信号に変えられ、メモリ上のどこかに展開される（どこに展開されるかは、データシートに書いてある）
「デバイスドライバ」
このメモリ上（のどこかのアドレス）に電気信号がOn,Offの形で表現されるので、
それを、Cのポインタ（(volatile unsigned short *)でキャストして、データシートに書かれたアドレスを書けば、ON Offをリード／ライトできる）で入出力する。
あ～LinuxでGPIOの場合、/sys/kernel/debug/gpioの下のファイルを見れば分かるだろう・・・
って言われれば、そのとおりだが、今回は、それは反則とする。
OSから（あるイベント発生により）呼ばれたら、上記方法でデバイスの入出力を行う部分のプログラムを記述したプログラムが、デバイスドライバ。
Linuxの場合は、*.koとかの拡張子で決められたように作る。
Windowsの場合は、WindowsPKとか言われるものが、ここにあたる。
「通信部分」
Linuxの場合、上記デバイスドライバはmknodとかすることによりにより、
「/dev/どこかのデバイス」に結び付けられ、Open/Closeして、Read/Writeできるようになる。
そこで、このデータを取得し、データを・・・データウェアハウスに送ると、更新に時間がかかるので、一時的な「データ収集」先に送る。送るプロトコルはいろいろあるが、RESTなら、みんな書けるよね！
つまり、
・一定時間ごとに、
（crontabに書くか、sleepさせて一定時間ごとに起こして）
・センサーデータを取得し、
・その内容を通信でデータ収集のところに送る
という処理をするプログラムを自分で作成する。このとき、「センサーデータの取得」は、
Linuxだと上記のように/dev/どこかのデバイスをファイルのように扱えるし、Windowsだと、
SDKで扱えるようになる。
通信部分は、RESTなら、どこかにいろいろ書いてあると思うので省略する。
○データ収集
センサーデータをいきなりデータウェアハウスに送ろうとしても、
データウェアハウスは更新処理が苦手なので、処理しきれない。
そこで、いったん、センサーデータを保存しておき、
データウェアハウスには、ある程度たまったところで
（夜間）バッチなどで、ゆっくりと更新するという手をとる。
そのために、センサーデータをためておくところが必要になる。
Amazonに送る場合、kinesisにデータを一時的に蓄えておく（２４時間）ことが
出来るので、kinesisで受けて、バッチでまわす方法がある。
クラウドにすぐに送るのでなく、いったんローカルで処理したい場合は
（後述するCEP処理までをローカルで行いたい場合など）
NoSQLの例えば、DataStaxEnterprise(Cassandraのインメモリ）等に
送ることが考えらる。
RDBの場合、ジャーナルに書き込む分、遅くなるようであれば、
それは無駄なので、NoSQLのほうがよさそうだが、例えば、MySQL(cluster)の
場合、インメモリを選択し、memcachedと同じアクセス方法を選べば、
それはNoSQLと実質同じことになる。
○CEP
収集されたデータは２種類の利用方法が考えられる。
一つは、異常検知など、即座に送られてきたデータ（数個を利用）して、
対処したい場合のCEP処理
もう一つは、データをいっぱいためて、過去データと見比べて、いろいろな
知見を得たい場合、データウェアハウスを使った分析処理
後者は別エントリ（データ解析）として、今回は前者。
このCEP処理としては、StormとSparkが人気なんでしょうか？
くわしくは、ここ
Twitter Storm でビッグ・データをリアルタイムに処理する
http://www.ibm.com/developerworks/jp/opensource/library/os-twitterstorm/
にいろいろ説明がありますね。
StormとSparkの違いについては、
■[Spark]Apache Spark Streaming＝大規模準リアルタイムストリーム処理？
http://d.hatena.ne.jp/kimutansk/20130902/1378142510
あ～、似たようなもん？
用は、いくつかのデータ（ウィンドウと呼ばれる）をもとに、
異常かどうか、何かしたほうがいいかどうかを判断して処理する
という感じでしょうか・・・
（このウィンドウを
全く重ならないようにする・・・ジャンピングウィンドウ
一部重なるようにする・・オーバーラップウィンドウ
一つ一つずらす・・・スライディングウィンドウ
というように、CSPのウィンドウ処理には、いろいろ種類があるようですが）
○機械学習
CEP処理で、異常かどうか「判別する」のように、判別とか
予測をする場合は、あらかじめ過去のデータを使って学習し、
それに基づいて予測・判別します。
これが機械学習なのですが、機械学習には
・過去のデータをもとに学習し、予測モデル（数式みたいなもん）を
組み立てる
・予測モデルをもとに、センサーデータをあてはめ、判別する
という２つの部分があります。
前者は、Hadoop＋Mahoutとか、Rでぐりぐりまわすとか、
いろいろありますが、それは、今回の範囲ではありません
（データ解析）
後者の予測モデルが出来た場合ですが、
CEP処理のひとつとして、予測モデル式にセンサーのデータ
を入れるプログラムを作って、ストリーム処理します。
異常値が出たら、後述の「出力等」への処理を行います。
なお、
Microsoft Azure Machine Learning
のようなものがあるらしいのですが、
使ったことないので、よくわかりません。
○出力等
CEP処理、機械学習の結果、
・異常等があるために、なにかに表示等する
→スマホに電話がかかってくるなど
・アクチュエーターを操作する
→モーターを回すなど
のような処理を行います。
これには、
（1)CEP、機械学習側から、アクチュエーターや表示側に通信する
→これが、上述「出力等」への処理
（2）その通信を受けて、表示、アクチュエーター処理をする
ということになります。
たとえば、Twilloを使って、異常があったら、
電話をかけてもらうなどというのも、１つの方法です。
ただ、一般的には、出力側に
・サーバーをたてて、そこで通信する
・Push型通信を行う
・双方向通信を行う
が考えられることとなります。
サーバーを立てる場合、RESTでやるのなら、センサーと逆方向のことを
すればいいだけで簡単なので省略。node.jsなんかでサーバーを書くのでしょうか？
Push型通信は、エンタープライズでは話し違うけど、
個人レベルでは、milkcocoaが話題なんですかね・・・
双方向通信は、WebScoketですね！
今後はWeb Socketが来るんでしょうか・・・？
もっとも、簡単な操作であれば、メールを送ったり、SSHで入ったり、RPC起動したりでも、
すんでしまうのですが・・・
IoT編は、ここまで。
長くなったので、今回はIoT編でおわり。つまり、ここまで。
まず、全体図。
以下、製品を交えた説明。上記「概要」の説明と比較できるように書いてある。
ただ、順番をかえて、まずは、IoTから。
■IoT
○デバイス
センサーは、例えば温度センサーは、温度が上がると抵抗値があがる。ということは、電圧が一定なら電流が変わる。
このように、計測したいもの（温度）の変化によって、抵抗などがかわり、電流、電圧が変わるというしくみでセンサーは動いている（ものが、たぶん多いと思う）。
このセンサーをデバイスのポートに線でつなぐことにより、この電気変化が、電気信号に変えられ、メモリ上のどこかに展開される（どこに展開されるかは、データシートに書いてある）
「デバイスドライバ」
このメモリ上（のどこかのアドレス）に電気信号がOn,Offの形で表現されるので、
それを、Cのポインタ（(volatile unsigned short *)でキャストして、データシートに書かれたアドレスを書けば、ON Offをリード／ライトできる）で入出力する。
あ～LinuxでGPIOの場合、/sys/kernel/debug/gpioの下のファイルを見れば分かるだろう・・・
って言われれば、そのとおりだが、今回は、それは反則とする。
OSから（あるイベント発生により）呼ばれたら、上記方法でデバイスの入出力を行う部分のプログラムを記述したプログラムが、デバイスドライバ。
Linuxの場合は、*.koとかの拡張子で決められたように作る。
Windowsの場合は、WindowsPKとか言われるものが、ここにあたる。
「通信部分」
Linuxの場合、上記デバイスドライバはmknodとかすることによりにより、
「/dev/どこかのデバイス」に結び付けられ、Open/Closeして、Read/Writeできるようになる。
そこで、このデータを取得し、データを・・・データウェアハウスに送ると、更新に時間がかかるので、一時的な「データ収集」先に送る。送るプロトコルはいろいろあるが、RESTなら、みんな書けるよね！
つまり、
・一定時間ごとに、
（crontabに書くか、sleepさせて一定時間ごとに起こして）
・センサーデータを取得し、
・その内容を通信でデータ収集のところに送る
という処理をするプログラムを自分で作成する。このとき、「センサーデータの取得」は、
Linuxだと上記のように/dev/どこかのデバイスをファイルのように扱えるし、Windowsだと、
SDKで扱えるようになる。
通信部分は、RESTなら、どこかにいろいろ書いてあると思うので省略する。
○データ収集
センサーデータをいきなりデータウェアハウスに送ろうとしても、
データウェアハウスは更新処理が苦手なので、処理しきれない。
そこで、いったん、センサーデータを保存しておき、
データウェアハウスには、ある程度たまったところで
（夜間）バッチなどで、ゆっくりと更新するという手をとる。
そのために、センサーデータをためておくところが必要になる。
Amazonに送る場合、kinesisにデータを一時的に蓄えておく（２４時間）ことが
出来るので、kinesisで受けて、バッチでまわす方法がある。
クラウドにすぐに送るのでなく、いったんローカルで処理したい場合は
（後述するCEP処理までをローカルで行いたい場合など）
NoSQLの例えば、DataStaxEnterprise(Cassandraのインメモリ）等に
送ることが考えらる。
RDBの場合、ジャーナルに書き込む分、遅くなるようであれば、
それは無駄なので、NoSQLのほうがよさそうだが、例えば、MySQL(cluster)の
場合、インメモリを選択し、memcachedと同じアクセス方法を選べば、
それはNoSQLと実質同じことになる。
○CEP
収集されたデータは２種類の利用方法が考えられる。
一つは、異常検知など、即座に送られてきたデータ（数個を利用）して、
対処したい場合のCEP処理
もう一つは、データをいっぱいためて、過去データと見比べて、いろいろな
知見を得たい場合、データウェアハウスを使った分析処理
後者は別エントリ（データ解析）として、今回は前者。
このCEP処理としては、StormとSparkが人気なんでしょうか？
くわしくは、ここ
Twitter Storm でビッグ・データをリアルタイムに処理する
http://www.ibm.com/developerworks/jp/opensource/library/os-twitterstorm/
にいろいろ説明がありますね。
StormとSparkの違いについては、
■[Spark]Apache Spark Streaming＝大規模準リアルタイムストリーム処理？
http://d.hatena.ne.jp/kimutansk/20130902/1378142510
あ～、似たようなもん？
用は、いくつかのデータ（ウィンドウと呼ばれる）をもとに、
異常かどうか、何かしたほうがいいかどうかを判断して処理する
という感じでしょうか・・・
（このウィンドウを
全く重ならないようにする・・・ジャンピングウィンドウ
一部重なるようにする・・オーバーラップウィンドウ
一つ一つずらす・・・スライディングウィンドウ
というように、CSPのウィンドウ処理には、いろいろ種類があるようですが）
○機械学習
CEP処理で、異常かどうか「判別する」のように、判別とか
予測をする場合は、あらかじめ過去のデータを使って学習し、
それに基づいて予測・判別します。
これが機械学習なのですが、機械学習には
・過去のデータをもとに学習し、予測モデル（数式みたいなもん）を
組み立てる
・予測モデルをもとに、センサーデータをあてはめ、判別する
という２つの部分があります。
前者は、Hadoop＋Mahoutとか、Rでぐりぐりまわすとか、
いろいろありますが、それは、今回の範囲ではありません
（データ解析）
後者の予測モデルが出来た場合ですが、
CEP処理のひとつとして、予測モデル式にセンサーのデータ
を入れるプログラムを作って、ストリーム処理します。
異常値が出たら、後述の「出力等」への処理を行います。
なお、
Microsoft Azure Machine Learning
のようなものがあるらしいのですが、
使ったことないので、よくわかりません。
○出力等
CEP処理、機械学習の結果、
・異常等があるために、なにかに表示等する
→スマホに電話がかかってくるなど
・アクチュエーターを操作する
→モーターを回すなど
のような処理を行います。
これには、
（1)CEP、機械学習側から、アクチュエーターや表示側に通信する
→これが、上述「出力等」への処理
（2）その通信を受けて、表示、アクチュエーター処理をする
ということになります。
たとえば、Twilloを使って、異常があったら、
電話をかけてもらうなどというのも、１つの方法です。
ただ、一般的には、出力側に
・サーバーをたてて、そこで通信する
・Push型通信を行う
・双方向通信を行う
が考えられることとなります。
サーバーを立てる場合、RESTでやるのなら、センサーと逆方向のことを
すればいいだけで簡単なので省略。node.jsなんかでサーバーを書くのでしょうか？
Push型通信は、エンタープライズでは話し違うけど、
個人レベルでは、milkcocoaが話題なんですかね・・・
双方向通信は、WebScoketですね！
今後はWeb Socketが来るんでしょうか・・・？
もっとも、簡単な操作であれば、メールを送ったり、SSHで入ったり、RPC起動したりでも、
すんでしまうのですが・・・
IoT編は、ここまで。
長くなったので、今回はIoT編でおわり。つまり、ここまで。
アクセス
トータル
ランキング
