データ集計・分析環境のあれこれ
現在自分の主業務はデータ集計・分析基盤の構築なのだけども、意外とまとまった情報ってなさそうなのでまとめてみる。まずは雑多に並べてみて、あとで整理します。あと自分が触ってないものもあります。
・何を使っていくべきか？
まず機械学習とか分析するのにいきなりHadoopクラスタ組み上げるのも大変なので、必要に応じて学んで行けばよいかと。
逆に大量ログデータを一括で処理したいって場合にはHadoopでも組み上げた方がいいかと。
参考：昨年秋の日記
http://showyou.hatenablog.com/entry/2014/09/15/005055
・言語
R
Julia
HiveQL
・並列計算エンジン
Hive, HBase, Pig, YARNなどはHadoop上の1部品。Hadoopの中身を列挙するだけでも長くなるので別エントリで
Spark
Sparkはメモリ上でのバッチ計算を行うシステムで、メモリに乗るレベルの計算ならHadoopより早い(対MapReduce. YARNベースのものは要比較)
・KVS
HBase
Hadoopの上で動く
Redis
シンプル故に早い
MongoDB
jsonでデータやりとり出来るのが楽。トランザクションで偶に泣きを見てる人がいる気がする。
Riak
Cassandra
Column(列)ベース
Pivotal GemFire の OSS 版、Geode のビルド - めざせ！細マッチョ
https://network.pivotal.io/products/project-geode
in memory KVS. Pivotal GemfireのOSS版。ビルドは一手間いりそう。
最近couchDBは聞かなくなった気が
・DB
Greenplum
Vertica
Redshift
Hive
DBというより、Hadoop上のファイルや集計処理をDBのように扱えるツールといった感じ。SQLとは少し違うHiveSQLを使用。
Impala, Presto, Drill, HAWQ
・Streaming処理
Apache Storm
Norikra
Spark Streaming
自分まだ触ってないですが、バッチ処理を細かくして実行間隔を短くしてるので、上２つほどではない気が
・視覚化
ipython notebook
RStudio
Hue
shib
Pentaho
Tableau
Microstrategy
・ログ・データ転送
Flume
Sqoop
fluentd
embulk
pentaho
・機械学習
scikit-learn(python)
Torch7
libsvm(liblinear)
・Deep Learning
Deep Learning リンク集 - 人工知能に関する断創録
Torch7
H2O
適当に列挙するだけじゃなくて、ユースケースに応じて使い方を紹介した方がよさそうですね。
#ingress UPV 10000行くための行動方法
UPVは、今(2014年12月)時点ではもう少し増えてるかと思いますが、少し前はA16のエージェントでも2000程度でした。私は5000強です。恐らく日本の人でUPV10000ってのもそうそういないと思うので、10000目指したいと思います。
とか書いてましたが、3ヶ月でUPV10000行きました。東京も多いですが、地方にも結構顔を出しています。
前回からですと、
- 名古屋周辺。というか名古屋から東京までの東海道線沿線
- 上野公園
- 広尾
- 中野・杉並
- 栃木
- 仙台
- 盛岡
あたりに顔を出しました。既に東急バス沿線は大体ハック済みです。
コツですが、
- Portal密集区間はmissionを頼りにする
- 移動は路線バス＋徒歩メイン
- 旅行を楽しむ
あたりでしょうか。Portalが増えたのはいいのですが、多すぎてどこから攻めればいいかわからない場合があります。その場合はmissonで15min(分)未満のものを選んで行けば自然と近場にあるPortalをまとめて取れるわけです。あとingressを目的に実施すると途中で虚しくなるので、旅行のついでにハックするくらいの方が気楽でいいと思います。
横須賀・猿島に行ってきた
2月はいろいろありましたが、とりあえず生きてます。
たまたま軽く休みができたので、今日でingressのキャンペーン終了だとか言う横須賀まで行ってきました。
ちょうど行った時間が14:00時だったので、無人島の猿島を散策できる、ぎりぎり最終の便に乗ることができました。
これが猿島に行く船。出発地点の三笠公園では激しい闘いが広げられてました。
ぼやけてますが猿島
船上から横須賀南東方向
猿島の船着場
降りたところ
島の中の施設
ミッションクリアの様子(一番左2つのメダル)
キャンペーン最終日だし何としてもPortalを取りに行くエージェントいるかと思いましたが、明日も恐らく船があるからか、あんま攻撃激しくなかったですね。
何とか一箇所だけは占拠しました。
島の南部は特に問題無いですが、北端あたりだと電波がかなりつかみにくいですね。
んで、キャンペーン応募が今日までだったのですが・・帰って寝てたら日付が変わってたというオチ。残念。
2chの専用ブラウザ以外データ取得禁止の話について
全然関係ないですがtwitterでも似たような残念な話がありました。
もともとTwitterはAPIを公開していたのですが、初期の頃はそれが恐ろしく不安定だったため、Webのページをスクレイピングしていました。Twitter社はスクレイピングを認めてはいなかったと思いますが、便利なのでスクレイピングを使ったクライアントはシェアを伸ばしていきました(Tweenのことです)
その後、streamingができたりAPIでもきちんとデータが取れるようになってきたのと、開発者の間でも一部"API使わない奴は外道"的な話が出てくるようになりました。さらにTwitterのWebページのレイアウトが頻繁に変わりスクレイピングも難しくなってきたため、APIに切り替えるようになっていきました。
んで数年後何が起きたか。
Twitter社は公式クライアント以外を締め出すべく、1APIキーあたりの利用者数に制限を設けました。律儀にAPI使ってたクライアント憤死です。
「Janetter」PC版などユーザー数が上限に Twitterの他社利用制限、国産アプリに影響 - ITmedia ニュース
何が言いたいかというと、真面目に企業のポリシー守っても企業側から切られるとか平気であるんで、その辺はリスク考慮しつつテキトーに使っていくしか無いんじゃないですかね？
生きてます
日記あまり書いてないですが元気です。
今月は中古PCとNUC買いました。
あと久々にingressで歩きまわってます。大体一日10km, 20万APくらい。
Hadoop on docker 後編
前回は既存のコードからHadoopのコンテナを動かすところまで書きましたが、今回はそれに手を加えて複数ノードで動くようにしました。
少し試行錯誤してたので、ソースだけ置いて要点だけ書いて行きます。
showyou/hadoop-docker at multinode · GitHub
まずDockerのパッケージを作るのは、Dockerfileになります。なのでいつも共通の設定とか初期設定はここに書いて行きます。bootstrap.shは毎回起動する度に呼ばれるファイルになっています(ただしbootstrap.shは今回指定して読んでいるだけで、dockerの決まりでは無いと思います)。また今回はNameNode/ResourceManager側とDataNode/NodeManager側でディレクトリを分けました。
作っていった手順ですが、まずsequenceiq/hadoop-dockerイメージを複数立ち上げて、そこで環境をいじって複数ノードで立ち上がるようにしました。次にdockerのソースに戻って同じように動くように変えて行きました。今回はgithubで公開するためこんな回りくどいことをしています。しかし手元の環境で使う場合は、動作した環境に対しdocker commitコマンドを実行することでdockerイメージが作成できます。dockerイメージは差分管理されるのでVMのスナップショットよりも容量が少なくて済むようです。
細かい変更点としてはここ(https://github.com/showyou/hadoop-docker/compare/multinode)を見てもらえればわかります。
core-site.xml, yarn-site.xml, hdfs-site.xmlにNameNode / ResourceManagerを指す設定を付け加えています。擬似分散では自動的にlocalhostを見ればよいですが、完全分散では明示する必要があります。またstart-dfs.sh / start-yarn.shはNameNodeマシンから(恐らく)slavesファイルを通して呼ばれるので、DataNode側から呼ばないようにしています。先ほどのxmlファイルをDataNode等が立ち上がる前にばら撒く必要もあります。
DataNodeは複数立てられます。詳しくはgithubリポジトリのReadmeに拙い英語で手順を書いているので読んで貰えればと思います。わからなければ日本語で書きます。
以上、車輪の再開発を泥臭くやっていきました。ここで言いたいのは、Hadoopのインストール作業は(パラメータチューニングは別途あるものの)この程度で出来るものであり、とても難しいソフトウェアとか神聖視とか構えないで欲しいということです。YARNの挙動管理は大変かもしれませんが・・
今年嬉しかったこととして、これまでデータ分析や大量のデータに興味がなかった方たちが取り組み始めたということがあります。今後彼らを引き上げていく役目になれれば嬉しいと考えています。
あと日本はまだその兆しが無いですが、少しずつHadoop/Sparkシステム(俗に言うデータレイクシステム)単体だけでなく、Hadoopの構成管理の方にまで注目が移ってきてきています。前回の最後に上げたPivotal HD for Pivotal Cloud Foundryなどもそうですが、他にもHortonworks + Openstackとか(HortonworkもCloudFoundryの一員ですね)もあります。また私が紹介することなのか、って感じもしますが、巨人も少しずつ動きつつあります(
IBM Big SQL Benchmark vs. Cloudera Impala and Hortonworks Hive/Tez | Sheffield View , オマケでPivotal HAWQ vs Cloudera Impala も置いときます)。
