DevFest Tokyo 2016で機械学習とかTensorFlowの話をしました

タイトル通りですが、最近色々あって、TensorFlow user Groupというものを立ち上げることになり、その結果立ち上げの決起会翌々日の10/9に開催されたDevFest Tokyo 2016 で 「TensorFlow User Groupから来ました〜」という謎の形で参加させていただくことになりました。TensorFlow User Group自体は10/7付で立ち上げたばかりなので、ロゴも何もない感じでTensorFlowのロゴを借りていますが、滑り込みで他のコミュニティと並べていただきました。

f:id:rindai87:20161009225910j:plain

DevFestとは

googledevjp.blogspot.jp

DevFest は、Google Developer Group(GDG)コミュニティによって世界各地で開かれるデベロッパー向けイベントです。参加者は Android、Firebase、Google Cloud Platform、TensorFlow による機械学習、Webなどの Googleデベロッパー テクノロジーに関する技術情報、知識やアイデアを共有できます。

と言うGoogle関連の技術コミュニティ主体のデベロッパー向けのイベントですね。これから全国で開かれていくみたいですが、その最初のDevFest Tokyo 2016にて発表させていただいたというわけです。最近Google機械学習人工知能を推しているわけで、そんな中でお話させていただいたのは光栄ですね。

gdg-tokyo.connpass.com

最近妙に広めの会場で話す機会が多くて、今日も一番大きなホール(満員で500名)が割り当てられていました。まあでも人間慣れるもんでだんだん緊張などはしなくなってくるもんですね。

f:id:rindai87:20161009230032j:plain

と、思ってたら、今日は朝から大雨で参加率自体がかなり低かったとのことで比較的空席が目立つ感じでした。

f:id:rindai87:20161009230133j:plain

この後もうちょい人が増えたと記憶していますが、せいぜい2/3も埋まってないくらいだったかなぁ、という感じです。

発表資料は公開してます

軽い気持ちで引き受けたら、TensorFlow User Group立ち上げの準備も色々あったり、業務などが諸々重なって資料作成が一週間前でも完全に未着手で久々に冷や汗ものでした。 今回は奇跡的に資料作成の神が降りてきて、なかなか良いものができた気がしています。タイトルが無駄にキャッチーですが、まあ内容は至って普通の機械学習とTensorFlowの基本の話で、すでに公開済みです。

speakerdeck.com

発表自体も比較的好調だったような気がして、AndroidエンジニアやWeb系のエンジニアが多い場だったため、機械学習やTensroFlowの立ち位置を明確化するように努めたのが勝因かもしれないと思っています。

TensorFlow User Groupについて

元来わっしょいしていくこと自体は得意ではないのでこれからどうしたものか、という感じですが、個人的にはビッグデータブーム、データサイエンティストブームの時のように技術を理解していない方々に蹂躙されて焼き畑にされてしまった感があったのがやや悔しく、日に日に高まる人工知能/機械学習ブームについてはそうならないようにしたいな、と思ってはいます。ので、まあ端っこの方でそういう気持ちを持ちながら楽しんでコミュニティ活動をしていきますよ、と。

tfug-tokyo.connpass.com

まずは第1回のMeetupを10/12(水)に開催です。いきなり濃い目の会になるのですが、2回目以降も継続して開催していけるようにしたい。参加や発表への閾値を下げていくのがポイントですね。

PR記事:データ分析の複雑化/大規模化に伴う環境の変遷と途中にある壁

仕事柄、色んなパターンのデータ分析してる人の環境を見る機会があるのですが、よくあるのは下記のような7つかな、と思います。段々とやりたいことが複雑/高度化する、もしくはデータの規模が大きくなると下の方に進んでいく気がします。

(私見ですが)よくある7つのパターン

1. WindowsGUIアプリやWebサービスの管理画面

いわゆるエンジニアじゃない方がデータ分析を行う時はまずここからではないでしょうか。Excelなども何気に高機能ですし、Tableauなどでも色々できます。Web上でもGoogle DocsのSpreadSheetはExcel並に色々できてしまいます。

2. Windows上でのプログラミング

少し高度な事や複雑な事をしたいなぁ、と思ったらこの領域になるのではないでしょうか? Excel上のVBAから始まり、Rを使ったり、それでも足りない部分はPythonを利用したり、という感じでしょうか。

そこまで高度な事をしない、もしくはそんなにデータ量が多くないかぎりは、この領域でほとんどカバーできてしまうイメージです。

3. Linux上でのコマンド操作

データソースが複数にまたがったり、データの加工処理が必要になってきた場合はWindowsでは段々辛くなってきて、脱Windows化が起きてくる気がします。組み込みのコマンドを駆使したデータ加工を行うイメージです。最近では仮想マシン上で簡単にLinux環境を手に入れられるようになっていますね。

4. Linux上でのプログラミング

コマンドだけではできない加工処理や、加工処理からそのまま統計や機械学習の処理を行う場合をイメージしています。手軽なところではAWKなどから、シェルスクリプトへ、そしてPythonなどに向かっていくイメージです。

5. DBとかKVSとかを自前で用意する

Linux上でもファイルを読み込んで処理するのが辛くなってくる(メモリに全部載り切らず値の突き合わせができない、時間がかかり過ぎる、等)ので、元のデータソースとは別に、処理の中間着地点として、DBやKVSの利用を検討し始めます。段々とミドルウェアの知識が必要になってきます。

6. Hiveとか、最近だとMPP

データが大きすぎて単体のマシンだといつまで時間がかかるか分からない、そもそも上手く処理できない、みたいなケースが出てくると、Hadoopだー、Sparkだー、という世界になります。が、HadoopやSpark上でそのままプログラミングするのはツライので、HiveやPigなどの裏側でいい感じにMapReduceを生成してくれるものに頼り始めます。最近だとImpala, Presto, Drill等もでしょうか。要はクエリをどんと投げていい感じにデータを抜き出したり加工したいという要望でしょうか。AWSのRedshiftやGCPのBigQueryもはいってきますね。

7. Hadoop/Sparkなどの環境下でのプログラミング

Hive等では手がとどかない部分までコントロールしたい、しなければならない、となって直接プログラミングを行います。分散、大規模やで!(意味不明)

問題意識:2と3の壁が大きい

2と3の壁が非常に大きいと思っています。何となく3になると「黒い画面」になって尻込みする人が多くなって、3以上の人が「こっちに来ましょうよ」と言っても「ちょっと・・・」となってしまう方が一定数いるような気がしています。4と5なども壁としてはありますが、今の仕事で関わる範囲だと、2の人が3になることがデータ分析の業界全体にとってメリットが大きいことかなと思っています。

もちろん、データ分析に携わる人がみんなLinuxなどを扱える必要があるかは微妙なところですが、課題意識としてここを越えやすくする何かが必要だなぁと考えていました。そのタイミングで、縁ががありまして、まさにドンピシャな本の監訳に関わらせていただくことができました。

Data Science at the Command Line

Data Science at the Command Line http://datascienceatthecommandline.com/

本書は著者のJeroen Janssensさんがブログで書いた7 command-line tools for data scienceという大反響となったエントリが基になり、ものすごく大幅に加筆されたものとなります。

実際に発売されているのはこっち

コマンドラインではじめるデータサイエンス ―分析プロセスを自在に進めるテクニック

コマンドラインではじめるデータサイエンス ―分析プロセスを自在に進めるテクニック

本書のポイントとしては、データサイエンスを行うプロセスをOSEMN(awesomeと読むらしいです)と定義して、それぞれのプロセスをコマンドラインで行おう、というものになります。curlなどでAPIからデータを取得して、JSONの結果をjqでパースして...のようにデータの取得、加工にもかなり重きをおいているのがポイントかと思います。また、VMが配布されており、本書で扱っている作業は全て再現できるのも、WindowsユーザーでLinuxに二の足を踏んでいる方にとってはとっつきやすいのではないかな、と思っています。

すでに上述の分析環境で3以上は楽勝です、という方には物足りない内容かもしれませんが、私自身も本書の監訳を通じてこれまで知らなかったけど便利そうなコマンドを知ることができました。

あ、そうそう、監訳に参加したメンバーにて、いざ使うにあたって躓きポイントになりそうな日本語に関してや、弊社でよくある分析パターンなどを書きおろしています。

編集後記

発売の前後のタイミングがちょっとバタバタしており、非常にタイミングが悪いのですが、マーケティングに関する企業に勤めているので一度やってみたかったコンテンツマーケティングってやつです。こんなマニアックなブログの記事を見る人なら関連性は多少なりともあるでしょう。みなさん書店で手にとたり、Amazonでポチったりしてみてくださいね。

反省点など

  • キャッチーなタイトルをつけられなかった(難しい)
  • 記事は30分以内に書くと決めたが45分くらいかかった(記事を書くのはそう簡単ではない)
  • 内容が薄っぺら過ぎる(ささっと書くので深掘り感が足りない)
  • うまいこと商品の紹介に繋がらなかった(文章力の問題)
  • この記事に分析っぽい書籍のレコメンドとかしたらどうなるのだろうとか漠然と思った

まあなんでもやってみないと分からないですし、簡単な話はないですね、という。

Strata + Hadoop World参加記録 その5

という感じで念願のStrataに参加でき、無事日本に帰国して落ち着いたので色々振り返ってみています。

今回の個人的な感想

という感じです。これは、Hadoopオワコンとかそういう訳ではなく、もうすでにHadoopが浸透しきって、MapReduceによるバッチ処理はひと通りやり尽くしたので、次になにを?、という感じで、MapReduceが苦手としていた繰り返しの処理に強いSparkが、特に昨今の機械学習への注目と相まって、まさにブレーク一歩手前、という感じになっていた、というのが正確な表現でしょう。

DatabricksのCTOのMateiさんのトークからもその勢いがうかがわれます。

Sparkの利用実態は?

皆さんまだ検証段階というのが実情のようでした。しかし、これからまさに本番投入していく直前、という感じを受けました。

なので、これからどんどん本番投入しました、という感じの動きが出てくるのでしょう。実際、これまでのSparkの話は機能的な側面の話が多かったですが、今回のStrataでは機能の話以上に、チューニングや内部的な仕組みの話を行って、実運用を始めた時にぶつかる壁の回避策等を伝播しようとしている感じを受けました。

Stream処理も熱い

MapReduceを用いたバッチ処理が一巡し、次に注目が集まっているのがデータ処理のPipeline化に伴うStream処理の話のように感じました。この領域は現状だとKafkaを組み込んだアーキテクチャ一択な印象を受けました。Kafkaを中継地点としたPipelineの構築が事例としても多く上がっていました。Kafkaまわりのトピックとしては、SparkとDatabricksの関係のような感じで、Confluentという会社があったり、LinkedInのベンチマーク結果は驚異的であったりという感じでしょうか。アーキテクチャもかなり面白いものになっています。

で、Kafkaとのコンボでは、これまではStorm一択だったところに、SparkStreamngや、SamzaApacheトッププロジェクト昇格などにより選択肢が多様化している状態です。

正解はないにせよ、Sparkエコシステムに乗っかりやすいSparkStreamingは大きな注目を集めていました。実際に、Strata内でも一つのセッションとして紹介されていました。

インメモリの分散DB系の台頭

Sparkよろしく、メモリをうまく使う系のDBも存在感を示していました。

MemSQLVoltDBAeroSpike、などなど...

詳細はちゃんと見ていないですが、それぞれACID特製をサポートしており、データのロストも無いと言っていたので、耐障害のところも考えられているのでしょうね。MemSQLなんかは割と舐めていましたが、デモでは恐ろしくパフォーマンスが良いように見えました。

MesosとかYARNとか

大人の事情でBDAS(Berklay Data Analysis Stack)の仲間のMesosの事をDatabricksが言わなくなったもので急激に影が薄くなっていたMesosですが、YARN on Mesosの話が上がってきていました。そんなにぽこぽこYARNクラスタ作らないでしょ、と思うのですが、myriadというまさにYARN on Mesosを体現しているOSSが出てきており、MapRのTedさんがメンターをしているようです。という訳で、何がしかの狙いがあるプロダクトのような気がしますが、真相は分かりません。

その他あれこれ

書き始めるとキリがないのですが、相変わらず機械学習の話題はホットですし、その中でもDeepLearningは注目を浴びているようです(日本と同じですね)。個人的には、アルゴリズム的なブレークスルーはもちろん、GPUの力技合戦に見える部分もある中で、DeepLearningとSpark等がどうか変わっていくのかは注目しています。そんな中で、DeepLearning × Sparkという意味では、H2ODeepLearning4J等に注目が集まっているように感じます。話を聞くとH2Oは思った以上に評判が良く、開発スピードも非常に早いようでした。

さあどうしよう?

という感じで、個人的にはSpark+αのビッグウェーブを感じ、「乗るしかない!このビッグウェーブに!!」という感じです。現地でもぽろっとつぶやいたのですが、

という感じで、何かできるといいな~、という感じです。今のところほぼノーアイデアではありますが、何かできるといいですね!ご意見含め、皆さんの熱い思いが高まれば何か起きるかも??

こういう感じで海外出張させてくれて今の環境はありがたい限りですね〜

Strata + Hadoop World参加記録 その4

今日は自分的に楽しそうなセッションが盛りだくさんですね。メモはけっこう適当です。

Big Data at Netflix: Faster and Easier

  • バックエンドにHDFSは使っておらずS3を利用している
  • 400 Billion Events / Day
    • ビデオの再生とかUIに対するアクションとか
  • Data Platform(High level)
    • Cassandraをハードに使っている
    • Python/Pigでデータ処理
    • クエリはPresto
    • Stingとか色々、BIもかなり使っている
  • Why Presto (vs. Alternatives)
    • バックエンドはS3
    • オープンソースJavaだし、あと、アカデミックなプロジェクトではなく、Facebookが実際に使っているので未来がありそう
  • Spark
    • 良い所
      • 2013年から使ってるけど当時はイマイチだった
      • 限定的な状態ではあるがproductionで使われている
      • 関連プロダクトがぎゅっと集まっている
      • パフォーマンス(Sparkは100倍といわれているがそこまでではない)
      • コミュニティ
      • 未来がありそう
    • 悪い所
      • まだ歴史が浅い
      • マルチテナンシーがない
      • shuffling
      • ハイレベルなAPIのためチューニングがやや困難
      • その他あれこれお
  • Streaming Processing
    • 一貫性と可用性
    • LatencyとScaling
    • Storm, Samza, Sparkとあるが何を選ぶべきか。。。
  • Parquet
    • カラムナ型
  • Pig on TEZ
  • Kafka
  • suro
  • druid
  • genie
  • inviz
  • lipstick
  • metacat
  • Bigdataportl
  • Kragle

  • Netflixのculture

全てはカルチャーのなせる技な気がしました。

Tuning and Debugging in Apache Spark

f:id:rindai87:20150221184137j:plain

席がうまく確保出来ず、メモを取る余裕もありませんでした。パーティションが大事、はとりあえず覚えているのでまた復習的な何かが必要ですね。あとは、やっぱりshuffleがきついのでここをいかに回避するかが一つのポイント、みたいな感じでしょうか?shuffleについては、この日の午後に一つセッションを設けて話されていました。

YARN vs. MESOS: Can’t We All Just Get Along?

f:id:rindai87:20150221184123j:plain

MesosとYarnをmanageするMyriadの話でした。まだまだこれからのプロジェクトだと思いますが、MapRが主導していくとのことなので、個人的にはDrillのように急激に伸びてくるんだろうなぁと思っています。

Everyday I’m Shuffling - Tips for Writing Better Spark Programs

f:id:rindai87:20150221184114j:plain

  • shuffleの話:非効率化の原因
  • driver or workerのどちらでデータを動かすか:エラーの原因
  • Reduce By Key vs GroupByKeyの比較
    • 結果は同じ
    • reduceByKeyの方が効率的
    • shuffleの問題から起きる
    • shuffle前に同じキーで処理してからshuffleするのがreduceByKeyだから
  • 大きなテーブルと小さなテーブルの結合(SpqrkSQL)
    • shuffledHashJoin
    • BroadcastHashJoin
      • 小さな方のデータをBroadCastする
  • How to Configure BroadcastHashJoin
    • 1.2から設定できる。
    • Set spark.sql.autoBroadcastJoinThreshold
  • Join a Medium Table with a Huge Table
    • Left Join
      • ...
  • shuffleの問題を見つける
    • main programはDriverで実行
    • transformはworkerで実行
  • collect()を大きなRDDで呼ぶとOOMKillerで死ぬ

と、出来る限りメモリましたが、不完全なことこの上なく。。。同行者の方から、この手の話はgithub上にも公開されてるよー、と教えていただいたので合わせてshareです。

その他

f:id:rindai87:20150221184039j:plain

今日はDatabricksとMapRのTシャツをゲット!Tシャツが累計10枚くらいになりました。。。

というわけで、長いようで短かったようなStrata出張終わりです。色々消化しきれていない部分を早く消化しないとなー、という感じです。余談ですが、Strataへの参加層として、中国人、インド人はすごく多そうでしたが、やはり日本からはほとんど参加されていないんですね。

Strata + Hadoop World参加記録 その3

今日からはセッションに参加できます。なにげに参加していなかったのですが、キーノートセッションにオバマのビデオが流れたとのこと!


President Barack Obama's Big Data Keynote ...

国のトップがこういうメッセージを出すってすごいインパクトですよね。。。

その他セッションを色々回りながら見ていました。

Spark Streamingの話

Spark Streaming - The State of the Union, and Beyond

にて、PMCのTathagata Das の話を聞くなどしてきました。

f:id:rindai87:20150220182924j:plain

SparkSQLやSparkCore、MLlibとの連携の話や、Spark1.3ではStreaming LDAなどが実装される話、MLlibとの連携強化等が話題にのぼっており、大変興味深い感じでした。

NetflixがStreaming処理系をSparkStreamingにリプレースしている話話や、Pinterestでも使われているよー、みたいな話が共有され、Spark Streamingへの高まりを感じる次第です。

f:id:rindai87:20150220182905j:plain

自分の興味がある部分だからかわかりませんが、Streaming関連の情報がけっこう多かったかな、と。

本日の戦利品はStrataの公式Tシャツ、AerospikeのTシャツ、BashoのTシャツです。Bashoはステッカーももらいましたし、ロゴがかわいいですね。 f:id:rindai87:20150220182801j:plain

明日は楽しみなセッションが多めなのでさらに期待が高まります。

Strata + Hadoop World参加記録 その2

2daysのチケットしか持っていませんので、本日はexpo hallをうろうろしました。 けっこう広い!あと、日本のイベントと違って会場内でアルコールが飲める!(その分参加費が異常に高い!!)

英語は拙いながら、我らが(?)TreasureDataさんのブースもあったりして中々楽しく回らせてもらいました。

f:id:rindai87:20150219191709j:plain

個人的にimpressiveだった事

「Strata + Hadoop conference」だけどほとんどSpark一色だった

時代の移り変わりなのでしょうか? みんなSparkとかストリーミングとか言ってる感じです。

インメモリでガンガン行こうぜ的な

インメモリでガンガン行こうぜ!という感じのモノがけっこうあった気がします。 その最たるものがmemsqlかな、と。VoltDBとの違い等はまだ整理しきれていませんが、30億レコードをささっとgroup byするデモなどを見ると、なんかそうですよねー、というものを感じます。ちなみに、マネジメントコンソール的なものでその時のマシンを見せてもらいましたが、そこまでのスペックでもなかったのが印象的です。

Tシャツやらノベルティやら

ミーハーごころ丸出しで色々いただきました〜

f:id:rindai87:20150219191652j:plain

  • memsql, TreasureData, Cloudera, MicrosoftのTシャツなどをゲットしました!

後は、DataBricksのCEOのIon Stoicaさんやら Doug Cuttingさんと挨拶させて頂くなどしました。HadoopとSparkのお父さん達に多謝。

Strata + Hadoop World参加記録 その1

色々ありまして、出張にてStrataに参加できることになり、前日にあるmeetupに参加してきました。会社に深い感謝の念を抱きつつ、記録的な何かを残していきます。Strata自体はまだ始まっていないけど同会場の一部でのmeetupだったため、前夜祭って感じが出ていました。

f:id:rindai87:20150218185118j:plain

事前に発表予定だったClouderaの人等が参加できなくなったり、食べ物提供予定がなくなったりということで、400人程度参加表明をしつつ実際は50人もいないくらい?な感じでした。

f:id:rindai87:20150218185132j:plain

内容としては、Spark1.3に入ってくるDataFramesの紹介でしたが、これまじでスゴイですね。 ほぼ同内容がブログでも公開されています。

  • PandasやRのdataframeにインスパイアされたインターフェースで敷居が低い
  • (DataSourceAPIとの関連だと思うけど)多様なデータソースに対応
  • pipelineAPIとのコンボ
  • Sparkそのものが遅延評価で動くことを活かして、裏側ではSparkSQLで利用するCatalystを利用するのでパフォーマンスが良い

ということで、今のところは良いことずくしに見えます。

※DataBricksが公開している検証結果(ブログ記事より抜粋)

という感じでかなり広く受け入れられそうな機能がどんどん増えていて大変素晴らしいという感じを受けています。

とりあえず触ってみないとですね。Spark進化が早くて追いかけるだけでもすごく大変です。せっかく現地にいるので速報っぽいのをやってみたかったので書いてみました。