ポケモンＧｏの検索も、自動化する時代に・・・

いや～、自動化も、ここまで来ているのですね・・

ポケモンを検索するのに
Pokevision(https://pokevision.com/)（いま、繋がらない？）や
P-GO SEARCH（https://pmap.kuku.lu/）
を使うのは、もはや当たり前、最近は、AmazonにＥＣサイトたてて、自動化する時代なの？

ポケモンGOで自分の近くにポケモンが出現したらSlackに通知する
https://blog.animereview.jp/pokemon-go-to-slack/

NECのAIブランドWISEって、富士通のZinraiみたいなもん？

NECからAIおまとめブランドWiseっていうのが出たらしい

NEC、AI（人工知能）技術ブランド「NEC the WISE」を策定
http://jpn.nec.com/press/201607/20160719_01.html


これって、富士通のZinrai

当社が培ったAI技術を「Human Centric AI Zinrai」として体系化
http://pr.fujitsu.com/jp/news/2015/11/2.html


みたいなもん？

IoT案件は２つの前提を入れると、Web案件に変化（難易度低下）する件

って、あまり知られていない？ひょとして？

---

まず、IoT案件は、以下のように思われているので、難しいと感じてしまう。

・センサーからの出力はシリアル（UART,I2C,SPI）→無線（ZigBee,Wi-Sun,Wifi,BLE)
・センサー入力から、アクチュエーター・表示系が、双方向で通信する

この案件を、そのまま処理しようとすると、たしかに難しくなってしまい、
Webの世界にならない。

---

しかし、ここに２つの前提をいれる

（１）ゲートウェイ（GW)を利用する。またはWiFiにする

　XBee（開発会社Digi)等、多くの会社は、無線通信データをインターネット上に流せる
　ゲートウェイを持っていて、さらにデータ加工できる場合もある。

　この場合、データをHTTPプロトコルに変更し、Webサーバーを叩くようにしてしまえば、
　Webサーバーで処理できる。

　または、もともとWiFiで、HTTPでアクセスしてWebサーバーを叩くようにする。


（２）画面表示やアクチュエーターのデータ獲得は、一定間隔おきにする

　　●センサーデータは、センサー→サーバーの一方向しかない。
　　　（サーバーからセンサーにコントロール信号を送る場合は考えられるが、
　　　センサーは一定期間ごとに送信するので、その返事にコントロール信号を
　　　載せても良い。そうすれば、一方向になる。そこまで考えなくても、ふつう一方向）
　　　この方向は、センサー→GWからWebサーバーを叩くことで実現できる

　　●表示画面やアクチュエーターは、サーバーからデータをもらうことになる。
　　　なので、双方向といっているが、これは、もし、１秒なり、ある一定ごとに
　　　聞くことが許されるのならば、一定間隔ごとに、タイマー（HTMLの場合は
　　　　meta http-equiv=" refresh " ）をかけて、サーバーにきく形にすれば、
　　　画面→Webサーバーを叩くという結果になる


（１）（２）の前提を入れると、すべての通信は、最終的にWebサーバーを叩くという
通信の流れに出来るわけで、そうすると、Web案件になってしまう。

---

つまり、２つの前提

　　（１）GWを使うか、WiFiにするかして、すべて通信はHTTP（HTTPS）
　　（２）表示画面、アクチュエーターは定期的にサーバーに確認するのでOK

があれば、IoT案件ってのは、Webと同じ開発手法で開発できて、
それってPHP＋JSでできるから、簡単なお話になるのだ・・・

要するにApache NiFiって、TalendみたいなETLなの？

話きいて、そんな風に感じた。
その「話」とは、７月２７日に行われた

Apache NiFi 勉強会 ～データフローの自動化～
講師：Hortonworksのかたがた

その内容をメモメモ

---

■会場提供のご案内　IDCフロンティア
・親会社 yahoo
・IoTのとりくみ
　ツール・ド・東北支援IoT　ハッカソンやります
　今週金曜日説明会。ぜひきて！
　８月１９日発表会
　復興支援
　connpassに記載してある。

■そのデータフロー Wifiで楽にしてあげましょう
・自己紹介

・HDF Apache NiFiとは
　DataFlowの概略図：簡単、明確？→実際は複雑
　シェルスクリプト書いてマネジメント：コストかさむ
　　→スキーマ変わった！とか
　Apache NiFi　
　　ＥＴＬでもあるし、
　　ストリーム処理につよいし
　　Ｗｅｂブラウザから実行できる、

・ＨＤＰとＨＤＦ
　　ＨＤＰ：Hadoopエコシステムをまとめたもの
　　　→ビッグデータ、データレイク
　　ＨＤＦ：データを取ってくる位置づけ
　　　→データレイクの手前、IoTデータを取りに行く

・統合されたプロセスと制御

・実績のある運用有効性

・国家安全保障局（ＮＳＡ）が開発したＮｉＦｉ
　→エンタープライズにマッチ

・リアルタイムデータロジスティックスの統合的かつインタラクティブな制御

何かと便利そうなので、まずは使ってみよう！
・インストール方法
　Ａｐａｃｈｅ　ＮｉＦｉ単体でも（Ｊａｖａのアプリケーション）
　ＨＤＰとセットで
　Ｄｏｃｋｅｒイメージもあるので
　Ａｐａｃｈｅ　ＮｉＦｉソースからビルド

・起動：
　ダウンロードして、展開
　bin のなかにシェルがある起動すると
　8080ポートにアクセスすると使える
　設定はconfの中

・ＨＤＦインストール方法：ＨＤＦとセットでお試ししたい方向け
　ＨＤＦのバージョンとNiFiのバージョンは別
　NiFi 今0.7　この夏1.0

・起動すると：真っ白なキャンバス

簡単チュートリアル
・Ｓｔｅｐ１：データを集める
　プロセッサーをドラック
　Get
　どっかからデータとって来る
　出力とつなぐ
　再生をクリック

・ここがポイント
　データフロー、フローファイル（流れるデータ）
　フローファイル：コンテントとアトリビュート
　プロセッサー：フローファイルを何かする
　プロセッサーに名前が付けられる
　終端になるプロセッサー：オートターミネート

・Ｓｔｅｐ２：データを加工する
　ばらす：sprit text
　　　大きく分割→１行ごとに
　extract text
　入ってきた　加工　メタデータ
　→アトリビュートをリッチにしていく

　ここがポイント

・Ｓｔｅｐ３：データを分類する
　るーとおんあとりびゅーと
　他システムのスキーマ：キャッチすると検知しやすい
　$ $フローファイルのアトリビュート
　データフローを作った後に
　足りなくなったらバッファリング

・例
　put slack

・データ来歴；時間をさかのぼって

・今回しゃべった内容

---

■Apache NiFiと他プロダクトのつなぎ方
・自己紹介

１連携手段
　おおきく２つ
・外部データストアの利用
・Input Outputポートを使用

・外部データストアを使用
　データストアを解して他プロダクトと連携
　ＮｉＦｉ，連携先にコンポーネントが必要
　利点
　　並列化で容易にスケール
　欠点
　　管理プロセス増大

・Input Outputポートを使用
　ＨＴＴＰ
　ヘッダー部に存在
　複数のＰｏｒｔを管理可能
　Site to Siteクライアント
　　任意のJavaプロセスが直接通信
　　公開されている
　　　Flinks,Apex
　　クラスタ？、ロードバランサ？？

・Flinkとの接続サンプル

---

■IoTアプリケーションで利用するApache NiFi
　Hadoop Summit Tokyo　１０月２６日、２７日

・ＨＤＦ　ＨＤＰ
・ＩｏＴ　and ＮｉＦｉ
　ＩｏＴ？
　What we can do with IoT 自動車
　・商用自動車
　　利用率、燃費最適化、故障予知（プリディクティブメンテナンス）
　　ドライバーのスコアリング
　　たくさんのデータソース　天気、車の管理情報なども
　　ＩｏＴデータでコネクティッドカーのデータをさらに豊富に
　　事例：プログレス（個人的自動車保険　ＯＢＤ）
　What we can do with IoT 農業事業者
　　水をまいたり、ドローン
　What we can do with IoT 通信事業者
　　基地局の最適化：利用率の監視
　　セルフオプティマイジング
　　セルタワーの管理
　　ＣＤＲ，
　ＩｏＴアプリケーションはデータソースが様々
　　　データの種類、
　　　データの流速、
　　　データのあて先
・Ｄｅｍｏ
　ＩｏＴ　ＭＴＡ　サブウェイ　ＩｏＴ　アプリケーション
　　ＮｉＦｉ
　　　ストリーム
　　　　getHTTP（一定時間でＨＴＴＰを取りに行く）
　　　　ラムダアーキテクチャ
　　　バッチ取り込み
　　　　駅の位置情報など　getHTTP
　　　　スタティックなストレージ
　　どこまでＮｉＦｉでやるかが設計のしどころ

・まとめ
　データソースが多種多様
　システムアーキテクチャ：データソースとデータ処理
　　それってfluentdでよくね？どっちもあり！