AWSの話題を中心に、日々の業務やプログラミングの徒然を綴るエンジニアブログです。

HANDS LAB

HANDS LAB ENGINEERS BLOG

ハンズラボエンジニアブログ

おみやげAPIをつくろう〜絶賛開発中!re:Invent企画〜

Pocket

エンジニアブログからこんにちは、マーケ担当の青木です。

AWS re:Invent 2015に参加したエンジニア、井上&今井のアイディアから生まれた
「おみやげAPIをつくろう」というプロジェクト。
re:Inventでゲットしたおみやげは無事メンバーの手に渡るのか!?
スーパーAWSエンジニアの加藤もJOINし、プロジェクトは進行中。
中間報告をレポートします!

omiyageicon

アイコンはデザイナー田名網作 Amazon風?

前回のブログでお伝えしたように、今回はre:Inventでゲットしてきたおみやげを
メンバーに配ることが目的。

事前準備として、以下の項目が入った「おみやげリスト」を青木が作成。

・おみやげの内容(例:DockerTシャツ)
・サイズや量(例:Lサイズ、2枚)
・商品写真 (例:DockerTシャツの写真)
dockertshirt

おみやげAPIは、ざっくり以下のようなイメージです。
・web&iPhoneアプリ対応
・Facebookでログイン
・商品一覧が出てきて、3つまで応募できる
・抽選ボタンが出てくる
・当選かどうか確認できる

10/23時点では以下AWSサービスを利用して構築しています。
1) API Gateway
2) Lambda/Pythonの利用
3) Cognito / Facebook認証
4) WAF
5) サーバーレス(NoEC2)

また、以下も考えています。

1) Firehose の利用
entry -> DynamoDB stream -> lambda -> s3 -> redshift
2) Lambda cron の利用
entry 状況をメールでお知らせする

構成図については近日公開予定!お楽しみに!

これが当たっちゃったらどうしよう…

snowball

注:SnowBallの重さは約23kgらしいです

Pocket

Amazon様とAmazon Machine Learning ハッカソン/Meet-up を開催しました

Pocket

臼井です。
他の皆がリアルタイムに 10月の re:Invent の報告をしている中、
なんと9月中旬から下旬にかけて行われた Amazon Machine Learning ハッカソン/Meet-up について報告します!
今回はADSJ様(Amazon Data Service Japan)による主催・運営と、
ハンズラボによるデータ提供とサポートによる共催でした。
以下、このハッカソンについてお知らせしていたページを記します。

Amazon Machine Learning ハッカソン/Meetupを開催します|ニュース|ハンズラボ株式会社
Amazon Machine Learning ハッカソン with ハンズラボ 2015年9月12日【Amazon ML ハッカソン】
Amazon Machine Learning Meet-up with ハンズラボ 2015年9月29日【Amazon ML Meet-up】

どのようなハッカソンだったか

概要

今回ハッカソンという名称で開催しましたが、1,2日こもってアイデア出しから始めてアプリケーションを作る!
というよく聞く感じのものとは少し違います。
イベントタイトルにもあるように、今年ローンチされた、
Amazon Machine Learning(以下、AWS ML と表記)を使用して、
素材データからお題に対する解を得てスマートアプリケーションを作る、
という、ややデータハッカソン要素のあるものです。

AWS ML については、以下のADSJ様の記事をご覧下さい。
Amazon Web Services ブログ: 【AWS発表】Amazon Machine Learning – Data-Driven Decision at Scale

データハッカソンについては、有名どころで言うと、Kaggleが主催のものが挙げられます。
Competitions | Kaggle
常時、企業や組織の実データに基づく課題を受け付け、
一般のデータサイエンティストらが、それらに対してよりよいモデルを作成しようとし、結果を出そうと常に競っています。
モデルの買取があるし実データいじるのが楽しいしで、皆必死ですw

今回のAWS ML ハッカソンは、以下の様な特徴が有ります。

  • 必ずAWS ML を使用して、予測モデルの生成に使用するというレギュレーションの存在。
  • 参加者はデータサイエンティストだけではなく、アプリケーションエンジニアも想定する。

非データサイエンティストでも、データサイエンスの果実を自ら手を動かして一定の程度得ることが、
手を出しやすい分析サービスの存在により既に容易に可能となっている、ということを、
実データと最新のサービスを用いて実感してもらう、という想いで、
ADSJ様と二人三脚で進めて参りました。

スケジュールは、
2015/09/12 ハッカソン初日開催。
~2015/09/28 ハッカソン初日開催日から引き続きHacking.
参加者の皆様とはSlackでコミュニケーションをとりつつ、ADSJ様と共にサポート。
2015/09/28 Meet-up にて成果発表!
という流れでした。

使用データとテーマ

テーマはずばり、以下です。

2015/09/14(月)~ 2015/09/20(日)の 東急ハンズの店舗毎の売上予測をして下さい!

であれば、上記を行う為に必要なデータは……?

2010年9月から現在(2015/09 上旬)までの、 東急ハンズ全店のPOS取引データ!

ということでした。

今回公開したPOS取引データというのが、多少の加工をしていますが、
テキストファイルにして80GB程度と、たまたまですが絶妙な量で、
みんな大好きMacBook Pro程度のローカルPCのスペックやストレージサイズで、
全体を一度にストレス無くETL(Extract, Transform, Load)をするにはギリギリ、程度のサイズでした。

他細かい実施要項については、スライドを公開してますので、そちらを見て下さい。

Meet-up

9/12 の20名を超えるハッカソン参加者のみなさまのうち、結果を提出して頂いた6組7名様の成果を、
9/29 のMeet-upにて披露して頂きました。
ハンズラボ賞と、オーディエンス賞(ハッカソンに参加してなくてもMeet-upに出席頂いた人の投票)の2つの賞を用意しておりました。
それぞれ、以下の様に評価し、決定しました。

  • ハンズラボ賞 : 売上予測が、店舗×日付それぞれについて、売上実績値を真値とした相対誤差20%以内であった割合にて、50点満点の評価。他、ハンズラボメンバーによるプレゼン、アイデアの評価でさらに5,60点程度。
  • オーディエンス賞 : 各チームの発表について、会場にいるみなさまに各自5段階評価してもらい、その合計値。ハンズラボ賞とは完全に別個に評価。

売上予測の正解を相対誤差20%以内としたのは、
1桁%ではつらいが50%を超えていると正解とは直観的に言い難い、
誤差20%とかなら、現実の小売を考えて、ぶれたとしても上下のぶれを考えたらそこそこ相殺されて、
会社はすぐには潰れないだろう、程度の後付けの根拠となっていますw

売上予測結果

なんと最も正解率が高かった方は、正解率50%をたたき出しました。
参加者の中では、10%正解するのも難しい中、これは驚異的でした。
また、MLのモデル作成は出来たが、締切までに予測実施が間に合わず途中提出の方がいたのですが、
提出分だけの1店舗で見ると7日中6日正解、つまり正解率85.7%の方がいて、ざわざわしましたw

ちなみに東急ハンズは、店舗にいる管理や庶務会計系の社員が毎月翌月の売上予算を日別に計算し、本部に提出しているのですが、
今回の売上予測の正解基準である相対誤差20%以内でジャッジにかけると、正解率はなんと8割に迫る勢いで、
現場感覚すげーな、負けてらんないな、と思った次第です。

売上予測の実施手法

では、参加者がどのような手法で上記の予測をしたのか、紹介していきます。

ETL

参加者みなさんそんなに大きな差は無く、

  • S3->Redshift->ML
  • S3->EMR(Hive)->S3->ML

という感じでした。

MLのデータソースはS3上のCSVかRedShiftであることが必要だったので、
このようなパターンに収束したと思われます。
EMR(Hive)は、S3上のCSVに対してSQL叩けるらしいです。知らなかった。

また、8月のハンズメッセや、12月のクリスマス商戦など、売上が際立っている期間は、
チームによっては異常値として除外している所が多かったです。
異常値として処理せず、時間軸の自明な周期成分を除去することで処理したチームもありました。
フーリエ変換とかラプラス変換とかデジタル信号処理とかいう単語が浮かびますね。

説明変数の決定

お渡ししたデータのカラム数はさほど多くなかったこともあるのと、
Meet-up当日までのやりとりでも変数が多すぎてもつらいという空気が出来ていた認識です。
参加者が使用してプレゼンで紹介していた変数の和集合をとると、以下の様な感じになりました。

  • 店舗コード
  • 売上
  • 過去数日分売上のウィンドウ集計
  • 曜日
  • 祝祭日か
  • 休日かどうか
  • ハンズメッセ期間内かどうか
  • 天気
  • 降水量
  • 店舗最寄り駅の乗車人数
  • 温度
  • 不快指数

思いついたけど使用できなかったと発表があった変数や要素としては、

  • 競合他店データ
  • 床面積
  • 在庫高。震災時の在庫高による売上キャップチェック

というのが出ました。

先の結果と合わせて考えると、
数百以上も説明変数を使用する必要は必ずしもないのではないか?という印象を受けます。

そもそもの原点に立って考えると、東急ハンズの各店舗の売上を予測する、ということなので、

  • 総売上はひとりひとりのお客さんが買ってくれた金額の合計である
  • その日にお客さんが何人来たか
  • 来たお客さんのうち何割くらいが買ってくれたか。入店カウントは結構しているので、来店した人とレジを通った人の比率は概数値で既知である
  • 客単価の平均や分布がどんな感じか
  • etc…

という、小売業界の社員、特に管理職とかだったらそういうこと考えなきゃモグリでしょ?(個人の感想です)
レベルの発想から変数を洗い出し、ブレークダウンして考えていけば、
いたずらに変数を増やしすぎず、でも人間がやるには大変だ、
という程度の数の説明変数に自然となるのではないでしょうか。

例えば、その日にお客さんが何人、というのは、
お客さんの来店理由には、商品指名買い、たまたま来た、などの種類があり、
それぞれのクラスタに対して異なった購買に至る確率があると思います。
指名買いの場合は購買確率が高く、たまたま来た人は普通ですよね。
そして、たまたま来た、という人の人数は、
ハンズがある街を歩いてる人の人数を従属変数に持っていると考えられます。
街を歩く人の内一定の割合の人が東急ハンズという魔窟に吸い込まれ、
さらにそのうち一定の割合の人がうっかりお買い上げになってしまう、という美しい流れです。
これはさらに、日付・曜日や店舗の所在地、
天候や最寄り交通機関の運行状況などを従属変数に持っていると考えられます。

と、こんな風に、誰が考えてもわかりやすい要因を挙げ、それらがどのような変数の関数であるか、
という考えを再帰的に突き詰めていけば、
どのような説明変数を使うべきか、ということが考えられると思います。
実際には上記の様に綺麗に考えることは難しいと思うので、
これも変数じゃね?あーこれは別のあの変数の従属変数だな、のように、
発見的になることもありそうです。

また、天候や最寄り交通機関の運行状況などは重要でありながら、
せいぜい確率的にしかわからないはずなので、
こういった変数をどのように活かすか、あるいは使用しないか、という判断も必要になると思います。

MLのモデルの作成

チームによって若干の違いがあり、大きく以下のように手法が分かれました。

  • 全店共通の1モデル。店舗コードを説明変数に持つ。
  • 1店舗毎の約50モデル
  • 東急ハンズ業態の店舗と、ハンズビー業態の店舗の2モデル(売上規模によって2分)

売上予測の結果は、
店舗毎モデル>業態別モデル>全店共通モデル
の順に正解率が良いチームがはっきりと分布していました。
なので、今回は店舗コードをカテゴリカルな従属変数にするよりも、
店舗毎の隠れた変数を、店舗毎のモデル生成に繰り込んでしまうのが正解だった、
と言えそうです。

可視化

特徴的だった方は、

  • ML->S3->Lambda->Kibana
  • Tableau
  • Elastic Beanstalk + DynamoDB WebApp

でした。
Kibanaやっぱりかっこいいなー、という小学生並みの感想。

また、前述の様に天気は本来確率的にしか予測できないので、その矛盾を解消するために、
天気ごとの予測売上を出すアプリケーションを作った方がいました。

まとめ

データ分析におけるETLにかかる時間の割合は非常に大きく、もちろん今回のハッカソンでもそれは例外ではないようでした。
元データを取り回してMLに投げられるデータを作るに至るまでの苦労が、ほとんどの参加者の発表から伺えました。
普通の統計解析だろうが、機械学習だろうが、避けて通れない道なのだなというのを改めて感じました。

また、機械学習だから大量の説明変数を使えるからといって、対象によっては、無理に増やさなくてもそれなりのモデルは作成可能なのではないか、という印象も受けました。
それはそれで、得られる結果が古来よりある多変量解析と何が違うんだという気もしますが……

また、ハンズの店舗の管理系社員が作成した予算の精度、本当にすごいなというのが、
ハンズラボメンバーの感想です。
在庫高、仕入れや販売の流量などが肌感覚でも帳簿の上でも詳細にわかっているからというのもあるかもしれませんが、
それにしても8割方誤差20%以内の日であるというのはすごいものだなと思います。

ハッカソン、Meet-up 共に、参加者の皆様には楽しんで頂けたようで、
おかげさまで開催してよかったと思えるイベントとなりました。
以下の様に、まとめと感想も書いて頂いております。
Amazon Machine Learning ハッカソン with ハンズラボに参加しました – Qiita

今後も、また何か一般公開のハッカソンをやるかも……?
AWS QuickSight を使ってやるとかも良さそうかなと。早く使えるようになるのを待ってます。
Amazon Web Services ブログ: 【AWS発表】 Amazon QuickSight – 高速で簡単に利用できるビッグデータ用BI(Business Intelligence), 従来型ソリューションの1/10のコストで実現

最後に、今回のハッカソンを共に推進してくれたハンズラボメンバー、
ADSJの皆様、そしてハッカソン参加者の皆様、本当にありがとうございました!

AmazonMLHackathon2015

Pocket

Baby Engineer はハイハイをはじめた。

Pocket

3月に入社したひよっこエンジニア、ケイティにブログを書いてもらいました。
初めてのプログラミング、しかも外国語で勉強するというハードル高めな環境ですが、毎日元気にがんばっています。
今回はこれまで学んだことの中で、特に気になるトピックを紹介してもらいました!(段落ごとに本人による日本語訳も書かれています)

21319284629_f9763cd9f2_o

Hello there! My name’s Katherine. I am an energetic, Southern belle from the States. I fell in love with Japan when I studied abroad and decided that when I graduated I would come back. It has been 5 years since I moved here and so far I am still enjoying Tokyo life. Since this is my first blog, I thought I’d write about what I know. Unfortunately, that is not a lot considering I just joined my company (i.e. the web engineering world) in March. Before March, I hardly touched a computer much less programed on one. Well here I am, half a year later, ready to tell you about my experience! I have come across some wonderfully interesting topics and today I would like to share my top three with you.

はじめまして!アメリカから参りました、元気なサザンベルです。日本の大学に留学した時、日本のことこんなに愛してしまいましたから、卒業したら後で住もうと決めました。日本の生活はあっという間に5年間過ぎちゃったんですが、まだenjoyしています。
3月にハンズラボに入社し、その後の研修の間に、色々ととても面白いトピックを見つけました。
本日、その中でも魅力のあったTOP3をご紹介したいと思います。

In my original presentation, I used Reveal.js as a platform for these topics. Reveal.js is like magic. It already has JavaScript API etc…, loaded on to the framework. The actual write up in HTML and markdowns are directly inside the presentation. This creates a smooth transition between slides and an impressive presentation! Customization is possible but is not easy, explaining the lack of plug-ins available.

これらのトピックを紹介するplatformは、「Reveal.js」と呼ばれています。
先輩エンジニアさんに紹介されて、利用方法も教えてもらいました。「Reveal.js」はJavaScriptAPIなどの機能を乗せているframeworkであり、イケてるpresentationを作成するのに役に立ちます。
Presentationの中身は、HTMLでの記述に加え、markdown記法にも対応し、スムーズに動くスライドを簡単に作成でき、印象的なPresentationをつくることが出来ます。
カスタマイズも可能ですがcustomize又はextendは簡単じゃありません。

While I have been learning CSS and Style Sheets, I discovered the property that changes the shape of your cursor on your computer. When the mouse sits upon the component, it intuitively shows what kind of operation it is.

CSSとStyle Sheetを習いつつ、cursorの形状を変えるためのプロパティがあるのを発見しました。
ここでは要素の上にマウスが乗った時に、どんな操作ができるかを cursor の形状で直感的に示します。

For example, Help me! becomes a question mark, Drag me! changes into a multiple direction cursor, and Click me! turns into a hand. Finally, and one of my favorites, Smile! shows when a picture is added(I just happened to use my company’s logo).

例えば、help に関しては cursor がはてなマークになります。
他にも、drag me だとこのように動かせそうな cursor に変わっています。
Click meもこうですね。Smile!に関してはこのようにチャント画像が表示されています。


Speaking of pictures, I became interested in how to attach photos to the background to create a visually appealing web page. For this, I am using the background-attachment property! As you scroll, this property determines whether or not the background moves.

Here we have the default scroll, and fixed which is an optional value.

The scroll setting sticks with the element while fixed sets the background to scroll with regard to the view point.

画像と言えば、視覚的なWeb pageには背景に画像を操作するのが気に入りました。
background-attachmentというプロパティを使います!
これは背景はscrollしながら動くかとうかのプロパティです。
こちらはデフォルトで scroll、もう 1 つ取りうる値としては fixed というものがあります。
「scroll」だとscrollと一緒にくっついていく設定になります。
こちらを「fixed」にしてあげるとscrollしてもセンターに貼り付いたまま、という指定になります。


This movement is not only for slide shows but for users as well making it interactive.

Reveal.js also has the ability to connect to your web camera as a way to change slides!


こういった動作は slide show だけではなくて、ユーザも使用する、interactiveなものとなります。
slideにはreveal.jsを使っており、Webカメラの前で手を振って操作できます

It reminded me of another project in the works called FaceTouch. It is a man-less receptionist that show the faces of all company workers.
This uses a touch screen, but can you imagine if it used hand gestures or voice commands? As a plus, you would not have to touch the screen which is more hygienic!

これを見た時にFaceTouchのことを思い出しました。FaceTouchとはすべての社員の顔が見える受付です。
これはtouch screenですが、動くジェスチャーや音声コマンドで使うことが想像できますか?
さらに、画面を触らないのでtouch screenよりも衛生的です。

There you have it: some things that have been fun for me to discover and hopefully some interesting things for you to try out!
ど~ぞお試してご覧!

Pocket

おみやげAPIをつくろう〜AWS re:Invent参加メンバー企画スタート!

Pocket

ラスベガスで開催された「AWS re:Invent 2015」。

参加したメンバーは、基調講演や各セッションはもちろん、
re:Inventグッズや、ブース出展している企業のノベルティ獲得に奔走…。

そして集まった大量のおみやげたちを目にし、漢(おとこ)たちは立ち上がった。

そう、「”おみやげAPI”をつくる」と—-。

omiyage

注:おみやげはこの写真の約3倍あります。

おみやげAPIとは?

ざっくり説明すると、ハンズラボメンバーがおみやげ目的で争うことがないように、
希望商品の応募→複数応募の場合は抽選→結果を返すという仕組みとなる予定です。
絶賛設計・開発中!!
re:Inventで発表された新サービスを無駄にどんどん活用しようと思っています!

使う(予定)のサービス一覧はこちら

・Amazon Kinesis Firehose (new!)
・Lambda Scheduling(new!新機能)
・Amazon API Gateway(祝東京リージョン)
・S3 website
・DynamoDB
・Redshift
・Amazon SNS
・EC2は方針として使わない

注:あくまで予定なので、使うサービスが変更になる場合があります。

エンジニア井上・今井は現地でもmeetingして、今日も始業前の朝早い時間から集まって会議するほどやる気です。

meeting

いったいどんなものができるのか?乞うご期待!
なお社内でのおみやげ抽選会は10/26(月)に開催予定。
今後もPJTの進行状況をUPしてまいりますので、お楽しみに!

おみやげAPIプロジェクト事務局 青木(エンジニア:井上、今井)

Pocket

Amazon Kinesis FirehoseのS3連携をAWSCLIから使ってみた

Pocket

こんにちは、今井です。

ありがたいことに、今年もre:Inventに参加しています。
今日のキーノートでたくさんの新サービスが発表されました。
その中で、Amazon Kinesis FirehoseのS3連携を、公式を参考にしてAWS CLIを使って試してみました。

手順

まずは、AWS CLIを最新化します。

AWS CLIのリージョンとプロファイルを指定します。
現状、us-east-1、us-west-2、eu-west-1のみ対応していますので、us-west-2を使ってみます。

ストリームを作成するコマンドのヘルプは以下のとおり

ストリームを作成するのに必要なパラメータを表示してみます。
S3とRedshiftの設定がありますので、Redshiftのほうは削除します。

IAM Roleが必要なようなので、こちらはマネジメントコンソールから作成します。

IAMのRoleの画面からCreate New Roleボタンを押して、Role名を入力します。

TryFirehose-1

Role TypeとしてAmazon Kinesis Firehoseが用意されているので、その行のSelectボタンを押します。

TryFirehose-2

PolicyとしてAmazonKinesisFirehoseS3DeliveryRoleを選択します。

TryFirehose-3

Create Roleボタンを押して完了です。

TryFirehose-4

また、S3バケットが必要なので作成します。

最終的なパラメータは以下のとおりです。create_delivery_stream.jsonという名前で保存します。
バケット名はARN表記なので、バケット名の前にarn:aws:s3:::をつけます。
S3オブジェクトのプリフィックスとして、Firehose/を指定しています。

それでは、ストリームを作成してみましょう。

作成されたストリームの情報を表示してみます。
DeliveryStreamStatusがACTIVEになるまで2、3分程度待ちました。

レコードを追加してみましょう。

S3に保存されたか確認します。

中身を見てみます。

日本語も入れてみます。

日本語も問題なく入力できました。

利用料はデータを入れた分に対してかかるようですが、忘れずにストリームの削除をしておきます。

最後に

後日Redshiftとの連携も試してみたいと思います!

Pocket