Developers Summit 2015 Autumnに行ってきました
【 マイクロソフトデータプラットフォーム使い倒せ!】
Azure SQL Data WarehouseはMPPのアーキテクチャを採用。
AzureData Lake
- Azure Data Lake Store
- Azure Data Lake Analytics
- HDInsight
AzureEventHubs
- Azure上でのスケーラブルなイベントの受信・送信
- AMQP/HTTPをサポート
- 同一イベントに対して複数のコンシューマグループを作成可能
Azure Stream Analytics
- Azure上でのストリームデータ処理
- Tumbling Window
- Hopping Window
- Sliding Window
Azure Machine Learning
- Hotmail,Bing maps,Bing search,Kinectなど、Microsoftは機械学習の深い知見がある。
- 開発したAPIをMarketPlaceに公開してマネタイズするところまでサポート
- Webベースの設計ツールなら、完全にゲストで使用も可能です。統計分析の勉強にもどうぞ!
Power BI
- Azure上で提供されるSaaS型BIサービス
- オンプレのExcelやSQL Serverのデータも使用可能
- モバイルクライアントもあります。
【Webサービス開発のエンジニア組織からアドテク志向のエンジニア組織への大転換!ーその裏側見せます―】
ランチセッションでした。 話が面白くて夢中になったのでメモ少なし。
【エンジニア目線で見たデジタルマーケティング業界のこれまでとこれから】
これまでマーケティングでは非エンジニアが活躍することが多かったが、これからはエンジニア的素養が必要になるはず。
●マーケティングとは?
- コトラーの4Pとかあるけど…
- 「デジタル上でもの/サービスを普及させるための手段」でいいのでは?
●マーケティングファネル
- AIDA,AIDASなどのモデルがある
●カスタマージャーニー
- マーケティングファネルを具体化したもの
●アドテクが流行ったことの功罪(罪)
- 事業者側は効率の追求に走り始めた
- セグメントの数が増加していくと、セグメントごとのクリエイティブや施策の検討材料が増える
- マーケティング担当者/代理店の担当者の業務量が増加
- 効果が上がった分の費用が別のところに行ってしまい、ベンダーは悲しくなる
●ユーザ拡張の意味
- 突然ターゲティングされ始めるの何で?
- 購入したユーザのセグメントに似たユーザをターゲットにし始めるから
全く興味の無い分野の広告が表示されるのはこれが原因。
購入にいたるまでのフローを逆にたどる ので気持ち悪い。
●今後面白そうなところ
- アドブロック
- マーケティングオートメーション
- DMPの次にバズワードにされそう
- ネイティブアド
- オンラインとオフラインの統合
●動画広告
獲得系の広告、認知系の広告ともオンラインだけでは限界
- 大きな代理店が出てきて…
●SSP(Single Source Pannel)
オンラインとオフラインの壁を越えるためのもの
- リサーチデータの一種
- 協力者から情報の接触や消費行動を収集したもの
しかし、母集団が少ない、データが歪んでいるなどの問題があるので、
●オンライン/オフラインの統合が確実に進みつつある
- コールセンターなどで顧客とのやりとりを分析するの面白い
- ただし、気持ち悪いと思われないようにしたいですね
●まとめ
- データを利用してPDCAを回すというマーケターの理想型があった
- マーケティング業界における制約を理解する
- その上で技術をどこにあてはめるかを考えていきたい
- 気持ち悪いと思われないように、エンジニアが歯止めをかけたい
「気持ち悪いと思われない」が3回。ユーザーの立場から考えるとすごく大事な言葉。
【なぜテスラを買う人は 43日前に一人旅をするのか?~多次元データベースによる未来予測の実現~】
撮影不可、あとから資料公開も無しなので聞き流してました。
【データファースト開発 〜 開発チームのためのデータ分析環境の構築と継続的改善の仕組み】
システム改善のサイクルは
- 現状把握
- 改善案の策定
- 設計・実装
今日はアドテクとかマーケティングではなく、 サーバサイドエンジニアの立場で 現状把握のお話をします!とのこと。
●現状把握に何分かかるか?
- 定型的な集計なら即時
- アドホックな分析だと1週間以上も…
●時間がかかることによる弊害
- 本当に困るまで調査しなくなる
- 根拠のない思い込みによる誤った判断
- 古い調査結果に基づく誤った判断
- データを見るには特異なスキルが必要だと認識
- データ抽出&分析の属人化
●どの行程に時間がかかるのか?
- ETL、データ抽出は分析対象のデータサイズに依存
- 結果が得られる範囲でしか分析しない、というようなことに陥る。
- 理想は誰でも気軽に分析ができるべき
- 結果が得られる範囲でしか分析しない、というようなことに陥る。
●理想に向けて必要なこと
- データへのアクセスが容易
- 高い応答性(理想は5分以内)
- 最重要!
- 手順の再現性
●やったこと
- 分析用に専用のログを出力するようにした
- Apacheのログ、とかではなく分析用に項目を精査したログを出力する
- 基盤の構築
●データ分析基盤の構成
- fluent pluginでBigQueryに送信
- 分析ログ以外はSpark/S3などに保存して、必要なときに使用
なぜこの構成?
- 応答性を重視
- BigQueryではIndex的なものの定義が不要
- アドホック分析に向いてる
- BigQueryではIndex的なものの定義が不要
- 用途/データソースで環境を使い分ける
- 機械学習を使いたいときにはSparkやScikit-Learn
- 分析ログに含まれないものはSpark
●応答性を重視する理由
- フィーリングは重要
- 直感は案外正しい
- 根拠が欲しい
- 直感は案外正しい
- 結果を得るのに時間がかかると
- 調査コストを考えると、遊びのある調査ができない
- 思いついてから10分以内には結果が欲しい
調査に1週間かかります!遊びの調査です! とは言えないのでw
●使い方を共有するために
- Zeppelin、Jupyterではノートブックに他の人の分析手順が残っている。
- 一番役にたった!
●エンジニアはデータ分析基盤を何に使うのか?
- 開発項目の選定
- システム改善の事前/事後の評価
- 運用フローの改善
●まとめ
- 速いことは正義!
- 誰でも、データアクセスできるといいことがある
- 開発者が自分で機能を評価できる
- 改善サイクルを回すスピードがあがる
- データを見られないことはリスク と捉えるべき
【AWSで作るオムニチャネル戦略実現のためのマーケティング・プラットフォーム】
●クラスメソッドとビッグデータ
2013年のAmazonRedshiftの公開がきっかけ。
●データ分析基盤への期待
…といった機能を「いますぐ使いたい」と言われる。
●CSデータ(カスタマーストーリー)
クラスメソッドでは”CSデータ”としてパッケージ提供しています
- Redshift×Tableauがシステムの中心
●構成例
という流れ。Redshiftが中核です。
資生堂のPOS,そしてAWSといえばスシローの事例(Kinesis)の紹介
●CSモバイル
使用しているコンポーネントの数が多すぎてメモ取れなかったので、資料公開を待つ。
●ビッグデータに効くAWSの新サービスおよびアップデート
新サービスで
- サーバーレス
- EC2を使用せず、マネージドサービスのみで構築できる
- リアルタイム分析
- IoT
が可能に。
EC2無しでシステム構築、ってのは結構なインパクトだな。
①AmazonQuickSight
- クラウドベースのBI
- 高速エンジンSPICE
②AWS Lambda
- ストリーミングデータを直接S3/Redshiftへ。
- Kinesis Stream→S3/Redshiftをアプリ無しで実現
- EC2で転送アプリを書く必要がなくなった
- ストリーミングデータをSQLで処理/分析
- 処理結果をRedshiftやS3へ送信
⑤Amazon Elasticsearch Service
- AWSのマネージドサービス
- Kibanaも使える
- 自動スナップショット
- CloudWatch Logs連携
⑥AWS IoT
- IoTで必要となるバックエンドの仕組み一式
- 通信、セキュリティ、データのルーティングなどなど
今後、 SORACOMを使用した新たなサービス を提供します!とのお言葉。
【プログラマブルなIoTプラットフォーム"SORACOM"】
司会が_%{color:red}「プログラマブル」%_ をひたすら噛むw
今日のお目当ての講演。
玉川さん、ドローンが好きすぎるが会社では飛行禁止されてる。
- 黒歴史のWatchpadまで持ち出して、15年たってもバッテリやインターネット接続の問題は解消されていない、との言葉。
http://pc.watch.impress.co.jp/docs/article/20011011/citizen.htm - 有線LAN、無線LANではなく、モノにはモバイル通信が合っているがヒト向けのサービスしかない。
- 基地局を借りて、パケット交換などの機能はすべてAWS上で構築。それがSORACOM。
- 夜が安い、上りが安いなどIoT向けの従量課金体系です。
- プログラマブル、ということでコマンドラインも作っています。
- エンジニアがドヤ顔で「soracom sim terminate」→これ バルス やろ!w
- 現在は解約の際にきちんと確認入るようになってます。
- エンジニアがドヤ顔で「soracom sim terminate」→これ バルス やろ!w
●事例紹介
- フォトシンス
- 鍵ロボット、Akerun RemoteでSORACOM Airの導入検証
●セキュリティの問題
- docomoのデータセンターまでは安心
- インターネット経由でサーバに行くのが危険。
ということで SORACOM Beam
- クラウドの潤沢なリソースで暗号化/プロトコル変換すればいいじゃん
- デバイスは非力なので、SORACOMでHTTP→HTTPSなどの変換
- SIMのID、タイムスタンプを自動付加して、なりすましを難しく
- SORACOM BeamもAPIでコントロールできます
…と思っていたら、AWS IoT!?
- 大丈夫。機能にカブリは無い。むしろAWS IoTに直接接続できるメリットがある。
http://bit.ly/sora-iot
↓
使えない
↓
SORACOM Airが必要です
↓
買ってね!!
のネタコンボ。
SORACOMのロゴは、
- SORA=宇宙
- COM=コミュニケーション
をイメージしており、 一つ一つのSIMを星に見立てているそうです。