【超入門】Hivemallで機械学習 〜Treasure Dataでロジスティック回帰編〜
こんにちは。俺やで。
ビッグデータとかデータサイエンティストとかいう言葉が未だブームですね。
(「データサイエンティスト」は下火か。)
ビッグデータ扱えるエンジニアも、
統計解析ができるアナリストも、
どっちもできるスーパーマンも世の中にはたくさんいますが、
ビッグデータも統計解析も扱えるインフラは多くはない現状です。
そこで!
この記事では、
ビッグデータに対応したHiveで使える機械学習ライブラリ、
「Hivemall」の使い方を学ぼうじゃないか!
という志をたくさん表現するべく書いています。
そして統計やるんだったら、
初歩的だけどおもしろいロジスティック回帰がいいだろうなと、
これを取り上げました!
ちなみにですが、
あくまで「Hivemallの使い方」に重きを置くので、
統計云々みたいな深い話は最低限しかしません。
あとTreasureDataで試させていただきました。
いつもお世話になります。
それでは、よろしくお願いします。
■1. ロジスティック回帰とは
①概要
「統計云々みたいな話は最低限しかしない」と言っといて、
いきなり統計の話です。恐縮です。
でもこれ説明しておかないとこの先意味ないので…
ロジスティック回帰とは、
いろんなパラメータでもって対象が「真」である確率を求める手法です。
広告業界ではCTR予測がいろんなところで例に出されますが、
もっとわかりやすいところで言うと、
「将来がんを患う確率」でしょうか。
がんになってしまう原因(=パラメータ)はいろいろです。
・年齢
・1日で吸うたばこの本数(=非喫煙者はゼロ)
・身内でがんになった人がいるかどうか(=遺伝的特性)(=本当に関係あるかどうかは知りません)
・運動習慣の有無
などなど。
患者さんからデータをとって、
”どのパラメータ”が”どの程度”がん疾患の原因として効いているのか把握することができます。
そうすれば今(たぶん)がんではない僕が、将来がんにかかる確率も求めることができるわけです。
医療研究で本当にロジスティック回帰が使われているかどうか知りませんが、
例えばこんなことができますよー、という認識で留めていただければ。
②数式
もうちょっとだけ統計の話(というか数学の話)します。
統計やるからには必須ですのでご勘弁ください。
ロジスティック回帰は次の数式になります!
n個のパラメータはそれぞれαという原因の重みをもつわけです。
(expは自然対数ですよ。一応)
グラフにするともっとわかりやすいです。
※値はテキトウです。
ロジスティック回帰はS字を描きます。
がんの話に戻すと、たばこの本数が増えれば増えるほど(横軸)、
がん疾患確率も高くなる(縦軸)、の図です。
※当然ですが縦軸は確率なので0~1、つまり0%〜100%の値をとります。
これは説明変数(パラメータ)がひとつの場合の図ですが、
これが複数の場合は各パラメータが確率に対して同じように作用しているんだと思ってください。
統計と数学の話は以上です!
■2.実践!Hivemall
①ここでやること。
R言語のサンプルデータ、irisでHivemallのロジスティック回帰を試してみます。
irisには3種類の花の、「がく(顎)」の長さと幅、「花弁」の長さと幅のデータが、全150レコード並んでいます。
具体的には次のようなデータ。
【超入門】ということで、説明変数はひとつ。
花弁の幅でもって、その花が「virginica」である確率を求める回帰式を求めてみましょう。
つまりは次の数式のα0とα1を算出すればいいんです!
x1が「花弁の幅」になります。
②学習データの用意
学習させるためのデータの用意をします。
「label」にはその花が「virginica」であるかどうかのフラグ、
「features」はその花の花弁の幅が入っています。
「1:」という書き方で、さらに配列に入れていますが、これがHivemallの書式です。
この「1」は1番目の特徴(=説明変数)だということを表しています。
話の本筋から逸れてしまいますが、説明変数を複数使いたいときは、こんな感じです。
とあるレコードが1番目の値を持っていない場合、
何も書かなくてもOKっぽいです。
(その場合、nullとして処理されるのか0として処理されるのか…検証不十分です。すみません。)
何にせよ、これで学習データの準備完了です。
③ロジスティック回帰
ここでやっとHivemallの登場です。
さっき用意したテーブルを「iris」という名前にした想定で、次のクエリを投げましょう!
[sql]
SELECT
A.feature,
CAST(AVG(A.weight) AS FLOAT) AS weight
FROM (
SELECT logress(addBias(features) ,CAST(label AS FLOAT)) AS(feature, weight)
FROM iris
) A
GROUP BY A.feature
[/sql]
addBiasはおまじないと思ってください。
(addBiasを指定しないとα0が常にゼロになってしまう)
logress関数が、Hivemallによるロジスティック回帰のミソです。
logressで引数にとったfeaturesとlabelがそれぞれ説明変数と目的変数として認識され、
ロジスティック回帰のパラメータを返してくれます。
はい。ほぼ終わりです。
さきほど次の数式のα0,α1を求めればいいと書きました。
その答えがここに!
α0が「-0.497〜」、α1が「1.416〜」になるんです!
例えばx1=0.1を代入するとp=0.41(=41%)、x1=1.4を代入するとp=0.82(=82%)になります。
つまり、花弁の幅が長ければ長いほど、その花が「virginica」である確率が高いわけですね!
なお説明変数を複数使った場合は、次のような結果が返ってきます。
α2(=2番目の説明変数として定義したもののパラメータ)の値がくっついてくるわけですね。
あとは予測したいデータに関して、これらの数式をあてはめてやれば、
そいつがどのくらいの確率で「真」なのか数字が出ます!
※ロジスティック回帰においてはsigmoidという関数を使うべしです。説明は割愛します。
データさえ作ってしまえば、あとは簡単なクエリで統計が使えるHivemall。
チャンスがあれば是非使ってみてください。
■追記 〜Hivemallを使う際の注意点〜
irisを使ったロジスティック回帰について解説しましたが、
R言語を使って単純にロジスティック回帰をすると、結果が全然違います。
というかHivemallの精度はirisを使う限りにおいては、めちゃくちゃ精度が低いです。
なぜなら、Hivemallのロジスティック回帰は、
Logistic Regression using Stochastic Gradient Descent
であって、普通のロジスティック回帰(Logistic Regression)ではないからです。
using Stochastic Gradient Descent が余計なわけですね。
詳細は割愛しますが、
要は「ビッグデータ用」のロジスティック回帰なんです。
「ビッグなデータを全部処理してると計算量が膨大になるから、
計算量減らすためにちょっとズルしますよ、
そのかわりちょっと精度落ちますよ」、
というのが「using Stochastic Gradient Descent」が言わんとするところです。
でもデータが大きければ多少ズルしても精度は大きく落ちません。
一方でirisは150行しかない、いわば「スモールデータ」。
ズルしたらいかん量なんですね。
データ選び間違えました。
また次回がんばります。
次記事:「HivemallでMinhash!〜似てる記事を探し出そう。〜」

関連記事
-
-
Treasure Dataの新機能(Data Tank)をAudienceOneのレポート機能で利用した話
Data Tankとは? Treasure Dataの新機能でTreasure Dataのプラットフォーム上に構築されたデータマートです。 Tableau等のBIツールとの接続を想定されており、AWSでいうところのRedshift的なものだと考えるとわかりやすいかと。 Data TankはPostg …
-
-
Amazon ElastiCache/Redisのパフォーマンス確認
はじめに こんにちは、AudienceOne開発部です。AudienceOne開発部ではいわゆるビッグデータと呼ばれる大量のデータをアドホックあるいは定常的に日々ETLだの集合演算だのをする一方で、様々な大規模データ処理ソリューションを継続的に検証しております。 本記事は、その中でもユーザが保持して …
-
-
HivemallでMinhash!〜似てる記事を探し出そう。〜
こんにちは。俺やで。 前回の投稿に続き(間が空きましたが)、 ビッグデータに対応したHiveで使える機械学習ライブラリ、 「Hivemall」の使い方、第2弾となります。 今回はMinhashという手法について書きたいと思います。 ※前回 【超入門】Hivemallで機械学習 〜Treasure D …
-
-
fastavroとjqでAVRO形式のファイルからデータを取得しよう
AVRO形式のファイルを取り扱いたい AVROとはApacheプロジェクトのひとつとして開発されているデータ交換形式です。 コンパクトなバイナリで高速なシリアライズ・デシリアライズが行えるため、サーバーログなどに利用されています。 弊社内での一部システムのログデータにも利用されているのですが、専用の …
-
-
【入門編】TreasureDataでWEBログ分析をしてみた
この記事は Treasure Data Advent Calendar 2015 – Qiita の24日目の記事です。 こんにちは。 今回はWEBログの集計や解析をする際によく使うHiveQLのクエリと、UDF(User Defined Functions)について実際の集計クエリを使 …
-
-
HyperLoglogでcount distinctを速くする
こんにちは。俺やで。 HyperLoglogについて書きます。おもしろいです。名前が。 ■1. HyperLoglogとは? count distinctを速くするアルゴリズム 以前、Minhashについて書きました。 (Treasure Dataさんのブログにも載せていただきました。ありがとうござ …
-
-
GoogleスプレッドシートからTreasureDataへデータを取り込む
AudienceOneの開発を担当しています。skryoです。 またまたTreasureDataネタですが、今回はGoogleスプレッドシートからGoogleAppsScriptを使ってTreasureDataへデータを取り込む手順を紹介したいと思います。 なぜ? Googleスプレッドシート上でマ …
-
-
ディープラーニングで「顔が似ているAKB48のメンバーを教えてくれるbot」を構築
概要 こんにちは、システム開発部の中村です。 今回は、Facebook Messenger APIを利用して、 画像をアップロードすると、似ているAKB48のメンバーを教えてくれるbotを実装しました。 尚、ディープラーニングやTensorFlowそのものの解説というより、 「エンジンとしてディープ …
-
-
GoogleAppsScriptとTreasureData REST APIを使ってサーバレスにTwitterのデータを取得
またまたTreasureDataネタです。 ただ、今回はクエリ系のネタではなく、GoogleAppsScriptとTreasureDataのREST APIを使ってTwitterのデータをTreasureDataに入れてみたので、その方法を紹介したいと思います。 はじめに ログデータだけではなく、公 …
-
-
いま必要なのは「アナリティクスアプローチ」
こんにちは。 ビッグデータ解析部のakiです。 解析部で、Markezineでの連載をはじめましたのでご紹介です。 いま必要なのは「アナリティクスアプローチ」、ビッグデータ活用の課題とこれから (http://markezine.jp/article/detail/21293) マーケターのかた向け …