トップ > 勉強

MIT Media Lab新所長、伊藤穰一とPivotalのCTO,Ian McFarlandが語る会に行った

勉強 技術 agile

27日(金)にこのイベントに行ってきたので、内容のメモ。
http://atnd.org/events/16029

スライドがあって云々ではなく、ほぼ伊藤さんのフリートークで、時々、Ianが回答するという形式だったので箇条書き形式にて。

  • アジャイル全般
    • スクラムなど、日本から出てきたコンセプトも幾つかあり、海外のエンジニアには、日本がアジャイル先進国だと思っている(勘違いしている？)人も多い。
    • 外注方式ではアジャイルを実践することは不可。ビジネスオーナーと作成者が同じ組織にいなければならない。
    • 基本的な方向性は決まっているけど、最終的なアウトプットは決まっていない状態で実装が進められていく。このため、プロジェクトマネージャーという役割は存在しない。
    • １〜２週間に１回、ピボットと呼ばれるタイミングを設け、これまでのアウトプットや各フィードバック(数字の話、他社の新機能の話など)を元に次の進め方を決める。YouTubeなんかも最初の頃はころころとコンセプトを変えていた。
  • TDDに関して
    • テキストなどでリストアップされた機能（フィーチャー）→ 機能毎のテスト → 機能毎の実装 のフロー(=TDD)による開発。パワポなどは存在しない。
    • 常にテストは動いているので、不意に今リリースしよう！ってなっても、実装済みの機能に関しては動くことが保証されている。
    • 動作的な部分だけでなく、ページのロード時間や色の比率などをテストする場合もある。
    • 「いつまでに○○をする。」ではなく、「いつまでに○○まで終わる」という形式での仕事の進め方。機能単位で実装されていくため、進捗のペースがつかみやすく、予測も立てやすい。
    • これまでの実績に基づいて工程が組み立てられるため、無理な工程を引かれることが少なく、プログラマにとってハッピー。
  • ペアプログラミングに関して
    • 実装の７〜８割の時間は何かに詰まっていたり、何か違うこと(メール,ネット)をしていたりする。ペアプロだと、これができない。
    • 全ての実装をペアプロで行う。
    • ピボタルラボ(Ianの会社)では、開発用のスペースとメールを見たりするスペースが物理的に分かれている。
    • 新しい人が来たときも、一人でコードを読んでキャッチアップということをする必要がない。
    • 定期的に技術力や実績をベースにチームを入れ直す。
    • 休憩時間も一緒にする必要があるため、朝ごはんを会社で準備して皆で食べるようにして、同じ頃にお腹がすいてお昼をとるようにしたりすることもある。
  • プロトタイプはどうしているか
    • コードを書いている時に技術者がイノベーション(=機能を足してみたり、変更したり)してはいけない。あくまでもリストアップされた機能のテストコード → 機能の実装 という作業のみを行う。
    • コードでイノベーションするのはスパイクと呼ばれる時間に行う。
    • スパイクの時間に作成されたコードは絶対に製品コードとはしないという約束がある。
  • その他
    • ピボタルが開発のコンサルティングとして入る時、まずは既存のコードを全てストーリー付きの形でそのまま書きなおす。バグ等もそのまま。数か月単位の作業になることも。。
    • こうしておくことで、他社の動向に応じて、新しい機能追加などが容易になる。
    • コードは資産ではなくて負債という側面もある。一回書いてしまうと捨てられない。。
    • 機能追加や機能のドロップを話し合うプロダクトMTGの場には、技術者を入れない会社もある。
    • デザインベースで始めると、どうしてもウォータフォールに近い流れになってしまうので、デザインも巻き込んでのPDCAにする必要がある。昔は有名デザイナーが作ったサイトをバーンと作れば良かったが、そういう時代ではなくなった。
  • QAその１ アジャイルは将来のアウトプットに関して何も約束しないという話でしたが、発注者としてはいついつまでにこれができるという約束が欲しいのではないか？
    • 何らかの企画を立てた段階で一年後、三ヶ月後にユーザが欲しているものを予測できていると考えるのは、今の世の中では無謀な考え。TwitterやFacebookなどなど、今の勝ち組企業の多くはアジャイルを採用しているけど、それでもあなたの会社のやり方が正しいと言えるのかい？と聞いてみればいい！？
  • QAその２ プロダクトMTGでは技術者を呼ばないこともあると言っていたが、プロダクトの出し入れの意思決定はどのように行われるのか？
    • シリコンバレーのプロダクトマネージャーはめちゃくちゃデータドリブン。会議はチャートだらけだし、自分でがんがんSQLを叩いて必要なデータを引っ張ってくる。ダメな機能をどんどん落とすと共に、全てがデータに残っているので、同じ失敗は繰り返さない。ただし、あまりにデータに寄り過ぎるとイノベーションしないし、データを見なさすぎると過去と同じ失敗を繰り返してしまうこともあるので、そのバランス感が大事。


対談は一時間ほどで終わってしまいましたが、もっともっと聞いていたい内容でした。聞いていて凄くワクワクすると共に、身の引き締まる感じ。というか、是非一回そういう仕事の進め方を経験してみたい。若いうちに。まだ、若いかどうかはあれですが、、

テストコードはそれなりに書いたことはあるし、TDDやらペアプロなどのアジャイル系の単語は知ってはいたけど、実はアジャイルのアの字も理解できていなかったのだな、、と痛感。ものづくり業界ではTOYOTAの圧倒的な強さを支えているかんばん方式が色んな所に輸出されているという話を聞いたことがありますが、アジャイル手法もどんどんと輸出されてくる、、というか、最近の勝ち組企業達の多くがこの手法を採用しているということで、自然淘汰的にこの手法が残っていくのかなと思ったりもしました。

ジオロケーションカンファレンス @yahoo

技術 勉強 ジオ

http://gihyo.jp/event/2011/geoconf
行く前はなぜyahooのイベントにGoogleのスーパーエンジニアが来たり、Open Street Mapの創設者が来てOSMの紹介するんだろうと？？な感じでしたが、ふたを開けてみれば、YOLP(=Yahoo Open Local Platform)の枠にとどまらない、今後のジオ業界どうなっていくんだろう的な規模のでっかい話が聞けて、凄く面白かったです。と同時にこれからどうなってくんだろう的な恐怖も少々。。

以下、まとめ系の情報。


以下、メモのまとめとか。

ジオロケーションサービスの現状とこれから Yahoo 村田さん

  • ジオロケーションの変遷。
    • 昔からジオロケーションは重要。文字が誕生する前から地図が存在していたと言われているが、きりがないので、、
    • 1995年 エピソード1の始まり。
      • 神戸大震災、サリン事件、アメリカyahoo誕生、windows95 、インターネットという言葉が流行語大賞に. etc..
      • 2003年 ナビウォーク
      • 2004年 Keyholeがgoogleに買収される。KMLのKはここからきてる。
      • その他色々
    • 2005 エピソード2の始まり
    • ５年周期なので、2015年にエピソード３の始まりを告げる何かがくる！？
      • その間は？？？
      • Where 2.0の今後のトレンド予測を見ながら考えてみる。
      • HTML5
      • Future of Mapping. 地図の作り方が変わる！？
      • Data Collection. Real time
      • Users vs features
      • Ads vs subscriptions. お金儲けどうする？
      • Interface. 今はARだけど、そのままいくか？
      • Public vs Private
      • Government & Humanitarian
      • これを手がかりに考えていこう
      • where2.0の本家サイトwhere2.0 、そして、日本語訳をしてくれた人がtwetter上にいた。ジオロケーション（位置情報）界隈の2011年の技術トレンドやトピックス | 世界 - daipresents!!
        • 全然関係ないですが、後のパネルで村田さんが冗談でジオ系にもっと女性が増えて欲しいということをおっしゃっていましたが、where2.0のメインスピーカーに女性が多くてちょっとびっくりしました。

OSMとの連携話を発表したいがために、この会を開いたんだろうな〜。
TechWaveの記事もこの件に集約されていたし、なかなかの目玉発表でした。
YOLPで地図と1100万のPOIを解放するってだけでもおおって感じだったのに、さらに自由に使えるようになるということで、どうなっていくんだろうな〜。

オープンローカルプラットフォームの設計思想 Yahoo 服部さん

  • 全体像
    • YOLP = 地図 ＋ 検索 ＋ ストレージ
    • 地図
      • 22種類のデザインを用意。
    • 検索
      • 1100万レコード。パートナー数28社
    • ストレージ
      • YOLPギャラリー。POIデータに対して写真をアップロードできる。
    • マルチプラットフォーム
      • WebのAPI + スマフォ系のネイティブのSDK
  • Technology behind YOLP
    • YDFテクノロジー。全てのAPIがYDFに従っている。YOLP(地図):YDF - Yahoo!デベロッパーネットワーク
    • ジオストレージ。全てのPOI情報を一つのストレージに格納。
      • 一つのPOIに対して複数の提供者からデータが提供された場合、名寄せを行って一レコードとして取り扱うことができる。
    • On Demand ラスタライズ地図
      • 事前に画像を生成せずに、リアルタイムに合成して画像を作成している。種類が多い。表示のカスタマイズを可能にしているので、このような形態をとった。
      • 地図画像の再圧縮。フルカラーの地図画像の色数(83色)を減らして、画像を圧縮している。3G回線での利用にも耐えうるように。
  • ロードマップ
    • Check - in API。サービス自体というよりは、それをサポートするようなAPI。
    • 略地図API。案内図的なものを作れるように。
    • AR SDK。
  • Where's YOLP heading for
    • 地域生活圏に根ざしたサービスを目指す。

地図画像の圧縮話は初めて聞いたので、おおって感じでした。見た目やパフォーマンス等、けっこう気になります。
あとは、略地図APIやAR用のSDKはリリースされたら触ってみたいな〜。

Easy Mapping in the Cloud @ManoMarks

  • 資料

Easy Mapping in the Cloud: New features in the Google Maps API an

  • Google fusion table
    • これまでgoogle はデータをstoreする場所は提供していなかった。
    • Cannot I do that with spreadsheet??
      • ファイルをアップすると、ワンクリックで地図上に可視化できるようにした。
    • テーブルのマージ
    • Visualのカスタマイズも色々ある。
    • 色んなレンジの表現が可能。日本の人口分布とか、世界の何かの消費量とか。
    • Read only
      • Maps API fusion table layer
      • HTTP GET using SQL like queries
    • Write
      • Use a client library
      • Do data collection
      • Use open data kit or App Inventor
      • 一つのlayerとして描画されるので、パフォーマンスが良い。
      • Rectangle, circle, order by distanceのような検索方法が可能。
    • その他
      • KML, 緯度経度, 住所文字列のいずれかでそのレコードの位置が特定できる。
      • 一テーブルあたり100MBまで。テーブル数聞きそこねた。。
      • サイト内への埋め込み用のscriptも生成できる。
  • QA
    • スマフォで使えるのか？
      • まだ使えない。
    • Googleが地図を作っているという話があるが、、
      • Google map maker というプロジェクトで地図作成を目指している。データをユーザにアップロードしてもらい、集約して地図を作りたい。

Fusionテーブルというのは最近知ったけど、少し時間をかけて勉強したいところ。とはいえ、個人で使うにはそもそも何を表示しよう？？ってなりそうだし、会社で使うにあたっては、ライセンスがちょっと気になる所です。調べてみねば。

Mapping the future. @SteveC (Open Street Mapの代表)

  • OSM概要
    • 2004年に設立。
    • 最近はbingからの支援を受け、Steve氏はMicrosoftの中の人になって活動中。
    • 二つの意味でfree
      • 料金がfree(無料)。
      • ライセンスがfree。ただし、ライセンス表示、同等のライセンスでの公開が必要。
  • OODA Premier
    • Observe
    • Orient
    • Decide
    • Act
    • OSMはこのサイクルが速い所に強みがある。
      • 常に更新可能。分単位、時間単位でチェックが入る。
    • 商用地図 vs open street map
      • 更新頻度はOSMが常に上。仮にコストをかけて迫ってきても抜かれることは無い。
      • Qualityは今は負けているが、徐々に追いついていく。それにより、OSMに流れる人が増え、商用地図の利用者、レベニューシェアが減り、さらに二つの差が縮まる。
      • いずれ逆転！？
      • 何となくこんな感じかなと思うのですが、この辺の話はけっこうあつめにされていたし、図等あったほうが分かりやすいので、ユーストをチェックし直すべし。
    • ハイチ地震では一気に地図が構成された時の爆発力。
    • セッション中に紹介されていた動画

OSM vs 商用地図の話の所で、いかにしてOSMが逆転していくかを時間をかけて、理論的に説明していて、うーむ、、となってしまいました。

What is MapQuest Open? @hurricanecoast

  • 概要
    • OSM上に作成できるアプリケーション。
    • Free
    • 27 languae-site
    • navigation, search, geocoader. Etc..
    • 日本語版も始まったよ。
  • 機能
    • OSMがベースのため、地図の更新が頻繁
    • Tourism power
      • 色んな言語での表示に対応している。
    • Routing API
      • クリックandドラッグで使うルートを変えれたり
    • Search
    • Evelation
    • 日本ではyahooとの協力により、データの精度が上がっていくはず。

自分が属している会社的にRouting APIの存在が気になりました。現状、地図の更新頻度が強みかと思うけど、例えば、それを生かして通行止め道路情報が即時反映されるようになったり、あとは、公共の交通機関と連携して、APIに取り込まれるようになったたら、えらいことになりそうだな〜と。


パネルディスカッション

あんまりメモ取れず。
印象的だったのは、地図を作製している会社の人が、今後の展開に関して質問したのに対し、@SteveC さんが「技術が発展すれば、新しく職を得る人、失う人、別の分野に移動して行く人色々いる。これまでもずっとそうだった。」的なことを言っていたこと。
色んな本とかでそういうのは読んだことがあったり、勿論、IT業界でもそういうことは起きまくっているて、そんなの当然だと頭では思っていたけど、いざ、自分の周りにそういう流れが来ると、少し抵抗したくなるな〜という気持ちになったりwww。AWS(Amazon Web Service)についての説明を聞いた時にも同じことを思ったけど、ラッダイト運動を起こした人の気持ちが少し分かる気がします。。
あと、@hurricanecoast さんが "It's just beggining"というのを盛んに強調していたり、OSMが他のサービスに対して勝っている所として、コミュニティの存在を真っ先に上げていたのが素敵で、楽しそうなコミュニティだなと感じました。

YOLP 地図検索プラットフォーム　Yahoo 西岡さん

  • 空間解析
    • 一番近いコンビニ、港区の図書館、駅から五分の図書館 etc..
    • 空間情報をリポジトリ化している。
  • テキスト処理
    • 前処理 ⇨ 検索 ⇨ 後処理
    • 前処理
      • 同義語の置き換え、表記揺れ対策、異体字、ローマ字対応
    • 後処理
      • ソート
      • 形態素解析、距離順 ⇨ 回転楕円体での計算が必要。
      • 距離 ＋ 適合度。「六本木 ラーメン」 で検索された時とか。
      • ただし、「六本木 コンビニ」の場合は人気は考えなくていいでしょう。

YOLPについて。　Yahoo 河合さん (latlon)

  • エンジニア観点からのYOLP
    • データ
      • 地図、航空写真、地下街図 ← これ注目
      • 地図注記は別レイヤーとして配信されている。
      • 施設、POI、標高値 ← 全国10mメッシュ
      • 地図 たくさんのデザインの中にアルプス時代のノウハウが詰まってるよ！
    • 活用事例
      • 注記クリックプラグイン yubichizで利用している。
      • iPadではある程度のバッファを持たせて判定している。
      • yubichizでは固定だけど、オンデマンドでも使えるっしょ。

広告関連の話で、yahooはかなりの人数をかけて、辞書の整備をしているというのを聞いたことがありましたが、それが検索のゆらぎ表現などにも生かされているのかな〜と感じました。
アメリカのYahooのほうはこんなブログはてなダイアリーが評判になったりと色々あるみたいですが、JAPANのほうは"地図"、"辞書"といった一見地味だけど、一朝一夕では身に付かない技術にがっつり投資している印象があり、さらに今回のオープン化の話など、ばりばりのハイテク企業だな〜という印象を受けます。楽しそう。

GeoHex @sa2daさん

GeoHex勉強会に行ったりしていて、けっこう既知(スライドに、カタンやっている時の手だけ登場できましたww)。採用サービスが着々と増えていて、さすがだな〜。
個人的にも、ちょこちょこと触っているので、早く何か作ったり、公開したりしたいな〜と。頑張らねば。

東京マラソン応援アプリ ゴーガ 小山さん

一日イベントで、恐らく一銭の儲けにもならないであろう所へ、これだけの情熱を傾けることができるという所に、ジオメディアサミットのコミュニティのパワーの源泉を見た気がしました。見習わねば。

OSM with 基盤地図 @mapconcierge さん

    • OSMの日本グループが法人登記したよ！
      • 何が変わる？？
      • 事務手続きが行える。⇨ 基盤地図が使えるようになる。
      • GPSの精度や都市部の地図が作りやすくなる。

数人のメンバーで乾杯している写真が紹介されていましたが、１０年後にOSMが大コミュニティになったとしたら、１０周年イベントあたりで、最初はこんな感じでしたと笑いながら紹介される写真になるんだろうな〜と勝手に空想しました。
年配の方が多く、若い力でががっといくのもいいですが、これくらいの年齢の方たちが一生懸命こういう活動に没頭しているのを見ると、いいな〜と思います。
最近、@mapconciergeさんが編集に携わっているGIS NEXTという雑誌を買ったのですが、少しお話させていただいた所、次号は、@ManoMarks、@SteveC、@hurricanecoast の巻頭インタビューがあるということで、必見ですね！！


そして、この辺で集中力の限界が。。

yahooの方々、発表者の方々、スタッフの方々、ありがとうございました！OSM来そうですね！！


追記：
Mano Marksさんのブログ

  • -

http://randommarkers.blogspot.com/2011/03/ruminations-on-place.html

  • -

感想系の中で面白かったブログ

  • -

http://d.hatena.ne.jp/ta26/20110309

  • -

MongoDB Conference in Japan（通称 mongotokyo)に行ってきた

勉強 nosql 技術

最近、少しつめこみすぎかなと思いつつ、Early Birdでお金払っちゃってるし、子供を保育園に預けておいて、家でうだうだしたり遊びに行ったりするのは倫理に反するので行ってきた。

ということで、全セッション分というわけではないけど、メモ。
英語聞きながら、メモってのはかなり難しい。。。日本語だとメモしながらでも内容が耳に入ってくるけど、英語だと意識を集中して聞かないと音が遮断されてしまうww。

追記：
@doryokujinさんの技評上でのレポート。動画あり。
http://gihyo.jp/news/report/2011/03/2301

Welcome to Mongo Tokyo @rogerb

資料はまだアップされてなさげ。

    • What is MongoDB?
      • 120000ダウンロード per month
      • アメリカ、ヨーロッパ、日本、中国の順に利用数が多い。
      • 1000以上の採用実績。
      • 昔はRDMSがデータを格納するための選択肢。
      • なぜNoSQLが人気になってきたか？ -> 大量のデータ、コネクション数の増加。
      • RDMSでもできるけど、相当詳しくないと無理。
    • RDMSの特徴
      • 完全なTransactionのサポート

    • NoSQLの特徴
      • 緩いTransaction管理
      • holizontalなスケール
    • MongoDBの特徴
      • MongoDBはmemcachedとRDMSのあいのこ。
      • C++で実装されている。
      • driverは色々とある。Rubyが一番人気
      • No joins and no complex transactions
      • これによってスケーラビリティを確保する。
    • RDBMSとの用語比較
      • Table -> Collection
      • Row -> json document
      • index -> index
      • Join -> Embedding and linking
      • もうちょっとあったけど、資料にて
    • MongoDBの機能
      • 複雑なデータ構造の表現
      • Secondary index
      • 多様なquery
      • $exists, 正規表現
    • スケーラービリティに関して
      • Read scalability -> replicationを増やすことで実現可。
      • Write scalability -> Shardingによる複数のreplica setを生成することで、実現されている。

oreilly本(http://oreilly.com/catalog/0636920001096)の最初のほうを要約してくれた感じ。
ちなみにアプリもある(http://iphone.appinfo.jp/apps/395324056/MongoDB%3A%20The%20Definitive%20Guide)ので、自分はこれをepubにしてiPadに入れています。当時は600円。今は800円。
あと、RDBMSとの比較の所では、デブサミの時にDeNAの奥さんが２者の違いはパッケージングの違いにすぎないというようなことを仰っていたのを思い出しました(http://d.hatena.ne.jp/seikoudoku2000/20110217)。主にconsitencyの取り扱いの所に２者の差があるように思いますが、そう捉えるとより理解し易い気がしました。

Schema design @rogerb

資料はまだアップされてなさげ

    • History of data modeling
      • ISAM
      • Network
      • Hierarchical
      • Relational. 1970年頃から現れた。そこまで古いものでもない。
    • Modeling goals
      • Avoid anomalies(奇形とか変則性という意味)
      • Minimize redisgn. RDMSではこれがかなりネック。三ヶ月かかるとか？
      • Make the model informative
      • Avoid bias towards a particular style of query
    • Advanced scema design
      • Single table inheritance
      • One to many , many to many
      • Trees
      • Queues
    • Hierarchical
      • Shapeテーブル
      • typeというフィールドを作り、circle, square, rect という種類を持たせる。共通するフィールドと、typeにより異なるフィールドがShapeテーブルには混合して存在。circleだとradius(半径)というフィールドがあったり。
      • circleだけにあるradiusを条件にfindクエリを投げることで、該当のレコードを抽出できる。squareやrectは自動的に無視できる。
    • One to many
      • Embed arrays
      • Blog エントリーの中に、コメントの配列を持たせて、さらにそのコメント毎にreplyの配列を持たせる。
      • Simple、まとめて持てる
      • ただし、ドキュメントをまたがって最新のコメントを探すのは難しい
      • Blog とcommentテーブルに分ける。
      • Flexible, more queries
    • many to many
      • Product とcategory
      • よくあるパターンとしては結合用のテーブルを作ること
      • Productの中にcategory idの配列、Categoryの中にproduct idの配列というデータの持ち方。
      • 関連データの検索が容易
      • ただし、一回の更新毎に二回のupdateが必要。
      • Categoryにproductを持たせるのはやめる
      • それでも容易に検索はできる。
    • Trees
      • full tree in document
      • Single document, peformance intuitive
      • 検索が難しい。一つのドキュメントは4MBまでという制限
      • Parent links
      • Trees as a path
      • ディレクトリ構造をdocumentで表すことも可。
      • 前方一致の正規表現で引っ掛ける。
    • Queue
      • Inprogress というフラグとpriorityを表すフィールド
      • findandModify() という関数を使ってデータを取り出すことで、フラグをデータを取り出すと同時にフラグをオンにすれば、Queue的なことが実現できる。
    • その他
      • Capped collections 上限を決めて古いデータから勝手に消えていく

どうしてもRDBMSちっくな考え方から中々抜けることができないというのはあるので、まずはこういったパターンを覚えてしまって、そこに今あるデータをあてはめることはできないかというアプローチはありだなと思いました。
実稼働しているシステム上での具体的なスキーマ構成というのはさすがに中々出てこない & そもそもそこまで突き詰めて構成している人は少ない気がするので、この辺は試行錯誤しながら身につけていく部分になるのかな〜と思います。

Replication and Sharding 10genのエンジニアの人

http://bit.ly/f5UsfF
かなり断片的なメモ。資料見るべし。

    • shardingに関して
      • addshard コマンド
      • 境界値はシステムが自動的に調整してくれる。
      • Timestampをshardのkey に足すといい？
      • More key values to enable split shards
      • ShardのkeyをQueryのkeyと合わせるとseekもスムーズ

    • replication
      • ノードが落ちた時のコネクションのハリ直しはdriverがやってくれる。
      • ノード復旧時には自動でリカバリ
    • slaveOK (ドライバからのアクセスで使えるコマンド)
      • writeはprimary, readはsecondaryという振り分けを行ってくれる
      • Secondaryからの読み込み時は必ずしもconsitentなデータが読めるとは限らない。

    • QA
      • Shardを追加する時、Shard間のノード数は合わせないといけない。
      • Shardingはcollenction単位。shardingのkey指定しないといけないから。DB単位でのshardingをサポートする予定はない。

      • Shardingすると、ユーザ認証が効かないが、サポート予定はあるか？ -> 2.0以降でサポート予定。チケットもある。1.8が出たばかりなので、2.0がいつ出るかは未定。その他、shardingすることで欠落してしまう機能はいくつかある。


まだ、複数台構成で動かしたことがないのですが、shardingのところは結構はまりそうな予感がしました。特にsharding keyを自分で決めるという所で、考慮の足りない設計にしてしまうと、後で大けがをしそう(4sqの障害的な？)。
sharding keyに関しては、複数のフィールドを設定するとbetterという説明でしたが、どのようにデータが格納されていくのかイメージしきれず、今いちピンとこず。。
oreilly本に、"The Key to Sharding"という章があるので、そこを読み返す & とりあえず動かしてみるという感じでしょうか。。

Social data and log analyze 芸者東京 @doryokujin

Social Data and Log Analysis Using MongoDB
View more presentations from Takahiro Inoue

    • ざっくりとした構成
      • Mysql, cassandra, access-logのサマリ等をまとめてmongoDBに入れている。
      • 中間データ（ほぼ生データ）とサマリーデータの両方をMongoDBに入れている。
      • サマリーにはMongoDBのmap reduceを利用。
      • 中間データ生成にHadoopを使っているが、mongoDBへの書き込みでボトルネックあり
      • MongoDB のmap-reduceはsharding毎に並列で行われる。
      • 1.8以降でreduceの機能が改善されるらしい。
    • REST部分
      • sleepy,mongoose
      • HTTPでダイレクトにmongo DBにアクセスして、jsonでデータを取得できる。
    • Rを使っての集計
      • 登録日と課金額の相関関係とかプレイ時間と課金額の相関関係とか。
      • RCurl、Rjsonというのを使って、同様にmongooseにアクセスしてデータを取得できる。
    • その他
      • Muninという監視ツールで稼動状況をチェック
      • Mongo flume plugin. accessデータを直でmongo dbに入れることができる。


先日のhadoop conference(http://d.hatena.ne.jp/seikoudoku2000/20110223)では、DeNA,Cyber Agent共に、access_logの中間データはHDFS上に格納してHiveやらpigやらで集計しているという話でしたが、adhocにクエリを投げたり、GUI化するところがちょっと大変そうだなと感じていたので、MongoDBにデータを突っ込んで、mongoose + javascriptという構成は手軽さという点でもカスタマイズ性という点でも魅力的だな〜と感じました。是非試してみたいです。

MongoDB as a Search Engine platform. @kzk_mover

MongoDB as Search Engine Repository @ MongoTokyo2011

    • sedue
      • エンタープライズ向けの分散検索エンジン。
      • 5000万件くらいのドキュメントの検索が行える。

    • Data model
      • RDBMSのようにスキーマを定義する必要がある。
      • ArticleID, Title, Content,,
      • カラムに対してindexの定義を行う。recommend用のindexも作れる。
      • XMLで記述。
    • Architectureの話。
      • たくさんのサーバが協調して動いている。
      • 図を見るべし。

    • 導入を進めたが、、、
      • Schemaが毎週のように変わる。
      • 使われていないカラムもある。
      • その割にシステムを止めることは許されない
    • storageの再検討
      • Storageはpluggableにできるように実装していた。
      • Tokyo Tyrantはreplication, sharding ができない。
      • Mysqlではshardingしてカラム足すのが大変。
      • NFSはセットアップにコストがかかる。
      • HDFSは安定性に課題が。
      • MongoDBに出会う。
      • API, Replication, online column add, sharding という必要要件をどれも満たしてくれていた。
      • GridFS. MongoDB as a Blob-storage
      • 16MB制限を超えて、大きなファイルを保存できる。
      • crawlerが集めてきた文章の保存、インデックスファイルの保存のところでMongoDBを使っている。後者はGridFSを使っている。
    • 開発にあたって
      • バグに対してpatchも送っている。
      • その取り込みも早いし、MLの対応も早い。
      • patchを送るとマグがもらえる！
      • 一週間で作っちゃってその後テスト的な。

    • 問題点
      • ディスクの使用量がでかい。富豪か！
      • Appendが多い。Vacume的なことをするとDBがとまってしまう。
      • 圧縮がサポートされていない。
      • Consistencyの取り扱いが難しい
      • デフォルトはWriteのリクエストを投げただけで、書き込みOKになる。 -> getLastError を取得すると確認できるがデフォルトではオフ。(MySQLとのパフォーマンス比較をこれなしでやっちゃダメでしょ的な。。）
      • レプリカセットを使うと、eventually consistencyになる。
      • Replicaの設定が深く追えていないので、master-masterにしている。
      • Shardingのパフォーマンスには厳しいものがあった。1.7前半。
      • 勝手にデータが行き来したりするので、何がおこってるんだ？？ってなる。
    • QA
      • Mongo dump でバックアップをとっている
      • logの保存にCapped collectionsを使っているけど、リカバリーの時にこれが足りないと全部リカバリーできない。

検証しながらバグを見つけてパッチを送ってマグもらったとさらっと言っていましたが、それって半端ないなと、圧倒されてしまいました。それがほんとの意味でオープンソースを使うってことなんだろうな〜と。
リアルに100倍くらいの速さで製品を作っているんだろうなと感じます。(http://lab.jibun.atmarkit.co.jp/entries/805)
そして、それだけしっかりと検証をした上での、MongoDBのメリット、デメリットの説明だったので、凄く説得力もあり、勉強になりました。

node.js + mongoDB Cyber Agent @snamura

MongoDB + node.js で作るソーシャルゲーム
View more presentations from snamura

Ameba pico の中の人。facebook上で動いているやつ
EC2上で大規模に動かしている。

    • 作ろうとしているもの
      • PC向けのソーシャルゲーム

    • 使おうとしている技術
      • MongoDB 1.8
      • node.js 0.4
      • WebSocket. -> 現在はflash上で動く独自プロトコルを使っているが、将来的にflash、、、となった時に備えて
      • Flash player

    • node.jsにした理由
      • これまではjavaで開発していたが、javaの静的型付けとの相性が悪くて残念な感じになってしまう。
      • Python + twistedは同僚のエンジニアが拒否。
      • なんか流行ってる。
      • 言語使用がすでにシングルスレッド
    • 構成
      • MongoDBは3 * 3 のクラスタ構成
      • Replica setの最低構成数の推奨が三台。二台だと一台落ちた時に、決定権云々の話がある。特別なプロセスを立ち上げとく必要がある。
      • Ameba picoではこれで数万ユーザの同時接続を実現できている。
    • MongoDBとnode.js
      • 鼻血がでるほど相性がいい。
      • jsonがそのまま使える
      • プログラムがシームレスに統合される
      • No more OR mapper

    • node.js用のドライバ
      • node-mongodb
        • 公式のCドライバのラッパー
        • bulk insert非対応
      • node-mongodb-native
    • node.jsの特徴
      • 全て非同期
      • 何をするにもコールバック。DBアクセスも。
      • コールバック全てにエラーハンドリングが必要。
      • 階層がかなり深くなる。

    • 工夫したところ
      • メソッドチェーンで連続した処理を記述できるようにした。
      • Mongooseという選択肢もあったが自分で作ってみたかった。
    • 運用管理ツール
      • 管理ツールは開発が面倒？？ -> ソーシャルゲームは運用が命。管理ツールの使いやすさはサービスの成功に関わる。
      • 社内ツールなので、最先端技術を導入しやすい。エンジニアの腕の見せ所。
      • 運用チームのテンションを上げてやるようなツールを作ることで、チームの士気が高まる。
      • リアルタイムレポート。 ##動画で画面を見せてくれましたが、凄かった！
      • データ定義をそのままフォーム仕様にしている。
      • 今はget,postではなく、websocktで通信している。
    • まだリリースしておらず、スケーラビリティ的な所は話せないので、また今度。

    • 結論
      • 仕様やデータ構成が複雑なソーシャルゲームとMongoDBの相性がいい。
      • node.jsとMongoDBは良い組み合わせ。
        • ただし、どちらも新しい技術なので何か起こる可能性はある。
      • テストコードが超大事。nodeunit。
        • スペルミスとかしてても容赦なく動くので、ほんと大事。
      • 厳格なシステムには向かない。
    • QA
      • Web socketで接続にくるので、ユーザ単位(プロセス単位?)で大きなドキュメントをプロセス上に保持しておいて、差分のみをMongoDBに反映する的なことをしている。
      • プロキシを挟んでプロセス間通信をして、近くのユーザーを認識させるような仕組みを作り中。
      • 実際の運用話は前回の勉強会の資料を見るべし！
      • shardingはたまに手でバランスを直してる。
        • 不思議とノード１にかたよる。。結構大変。

デブサミ、hadoop conf, MongoTokyoとそれぞれでCyber Agentの発表がありましたが、どれも内容が濃くて、ソーシャルゲームっていうただの流行りではなく、これまでの技術の積み重ねがあって花開いたんだなというのを改めて感じました。
と同時に、それまでの積み重ねた技術に縛られずに、node.js + MongoDB を使って作っちゃいましたってのは改めて凄いなと。
そういうのを使って作っちゃえるのも凄いし、完全にエンジニアにプロダクトの決定権を与えてそんな冒険をさせちゃう会社も凄いし、何よりまだリリースしてないサービスなのに、こんなに詳しく構成の話をしてしまって大丈夫なのか？と部外者なのに心配してしまいましたwww。
あとは運用ツールの話がグサグサきました。picoを作れって言われてもすぐにはできませんが、こういうツールは自分で作れそうなものなのに、ただやれてないだけなんだなと反省。まずはこういう思考の部分で追いついていく & それをコードに落とすということを意識し続けないといけないな〜。


前回の資料も共有されていたのでリンク。

MongoDB CouchDB合同勉強会-2010-12-14
View more presentations from snamura


主催者の方々、10genの方々、発表者の方々、どうもありがとうございました！！

読書メモ

読書 勉強

本日は創立記念日で会社が休みということで、先日(http://d.hatena.ne.jp/seikoudoku2000/20110227)買った本を大分読み進めることができた。

数学ガールのほうは現在第６章まで読んだ。これまでの作品も面白かったけど、どちらかというと学生時代に勉強した話や文系上がりの自分が今まで手をつけたことも無い世界のことを易しく(といっても理解できているわけではないですがww)、美しく紹介してくれている感じだったのが、今回の作品ではアルゴリズムの性能の話が第６章で取り上げられていて、代表的なアルゴリズムをウォークスルーで解説してくれていたり、ちょっと前に読んだ本で紹介されいていて何だか分かりづらいな〜と思っていたO記法に関して、ミルカさんが、

T(n)=O(f(n))
T(n)はたかだかf(n)

(「数学ガール　乱択アルゴリズム」より抜粋)
という言葉を元に明快に説明してくれていて、これまでで一番萌えてしまったかもしれない（笑）。
この先を読み進めるのが楽しみ & 何回か読み直してしっかり腹落ちさせたいなと思う。

そして、わざわざブログを書こうと思ったのは、同じく第六章に出てきた言葉に感動したことをメモしておきたいと思ったから。

伝える価値があることを、正しく伝わるように書く。
　ーそれが、論文の本質だ。
これまでの人類の発見に、自分の発見を新たに重ねる。
　ーそれが、研究の本質だ。
過去の上に現在を重ね、未来を見る。
　ーそれが、学問の本質だ。

(「数学ガール　乱択アルゴリズム」より抜粋)

数学ガールと一緒に買った「みんなが知りたい地図の疑問５０」、「地図の科学」という本を並行して読んでいて、地図というのは文字より誕生が古く、それ以来、各時代の色んな人たちが様々な努力をした積み重ねの上にできてきたものだということを知り感動していたところに、さらに上述のミルカさんの言葉に出会って、webサービス上の地図に同じことを感じた。
あれらの地図はgoogleだけが発祥というわけではなく、これまでの人類の発見・研究・創意工夫が詰め込まれているんだな〜と。
そして、今は、その地図を開発に使える立場にいるのだから、そのこと自体に喜びを感じるとともに、もし、そこに自分なりに何かを重ねて未来が見れたり、新しい価値を生み出すことが出来たら最高だなと！！
会社の創立記念日に感じることの出来たこの思いを胸に、明日からまた仕事に励んでいこうと思う今日この頃なのでした。

【送料無料選択可！】数学ガール 乱択アルゴリズム (単行本・ムック) / 結城浩

【送料無料選択可！】数学ガール 乱択アルゴリズム (単行本・ムック) / 結城浩


【送料無料】みんなが知りたい地図の疑問50 [ 真野栄一 ]

【送料無料】みんなが知りたい地図の疑問50 [ 真野栄一 ]


【送料無料】地図の科学 [ 山岡光治 ]

【送料無料】地図の科学 [ 山岡光治 ]

数学ガール、地図の科学、みんなが知りたい地図の疑問50、GIS NEXT　を買った。

勉強 読書

久々にゆっくりとでかい本屋を巡り、書籍をがっつりと購入した。

結城さんのtweet + RTされてくるtweetを見ていて、我慢できなくなってしまった。まだ、序盤だけど、プログラムよりの話が絡んでいるため、今まで以上にワクワクする感じ。この後の展開に期待大！(一部の感想では今までより数学的に難しくないかもというようなのもあったので、最後までついていけるといいな。。)
最終目標は乱択アルゴリズムを取り入れたサービスの実装！？

【送料無料選択可！】数学ガール 乱択アルゴリズム (単行本・ムック) / 結城浩

【送料無料選択可！】数学ガール 乱択アルゴリズム (単行本・ムック) / 結城浩


残りの３冊は近々GEO系のイベントに参加するにあたって、もっと地図を知らんといけないよな〜という自戒と、そこに詳しくなればもっと面白いもの作れそうだよな〜というワクワク感と、ブラタモリやフォローしている人等がジオ系の話を嬉々としてやっているのを見て、そこに近づいてみたいという思いがぶつかりあって購入した。

【送料無料】地図の科学 [ 山岡光治 ]

【送料無料】地図の科学 [ 山岡光治 ]


【送料無料】みんなが知りたい地図の疑問50 [ 真野栄一 ]

【送料無料】みんなが知りたい地図の疑問50 [ 真野栄一 ]

「GIS NEXT 34号」
http://www.nextpb.com/gisnext/


ほんとは"GIS"という単語に関して、いい入門書ないかな〜というのも探してたんですが、、いいのが見つからず。何か大学の授業で出てきそうなのばっかり。。
でも、GIS NEXTはすんげー面白そう。ディープな記事がある一方、２ページくらい"GISな女性"というコーナーで、普通に働いている女性が、アイドルちっくに結構綺麗に撮られた写真付きで紹介されるというカオスっぷりが何ともいい。貴重な情報源かつ、年４回だけの発刊で、また買いに行くのは大変なので、定期購読しようっと。

hadoop conferenc 2011のLT

技術 勉強

昨日(http://d.hatena.ne.jp/seikoudoku2000/20110222)の続きで、LT部分

Gfarm上でのmap reduce 筑波大学 三上さん

    • HDFSの問題点
      • POSIXに準拠していない
      • マウントが不安定
    • 他のファイルシステムの利用
    • Gfarm
      • 汎用的な分散ファイルシステム
      • 筑波大、KDDI研究所などで使われている。商用サポートをしている会社もあり
      • POSIX準拠。
      • ブロック分割しない
      • 単一ファイルへアクセスがスケールしない
      • 利用方法
      • JNIのレイヤーを挟む、マウントしてアクセス
      • HDFSと比較して書き込みパフォーマンスがよかった。
      • 読み込みは同等。
    • Gluter FS
      • 使いやすいが、少しパフォーマンス悪い。
    • Ceph
      • まだ実用には早い

Hapyrus 藤川さん

Hadoop Conference Japan 2011 LT Hapyrus

    • Hadoop -> 最初の敷居が高い
      • 仕組みの理解、map reduce実装、クラスタ運用
    • Hapyrusとは？
      • Hadoopアプリの実行環境のwebサービス
      • アプリケーション購入や大量データ解析で課金が発生。
      • 色んなアプリを組み合わせて集計を進めていくことができる。
      • 三月下旬にリリース予定
      • Hadoopアプリの開発者募集中

pluggableなMap-Reduceを部品(アプリ？)として販売してしまうと発想は凄いな〜と思った。機械学習的な実装が提供されたら買ってしまうかもしれない。価格観が未知数なので気になります。
というか、map-reduceに限らず、例えば、tweetを収集するプログラムだとか、あるキーワードに言及されたブログを収集するプログラムだとか、すんごいいい精度の形態素解析を行うプログラムだとか、それだけではサービスにならないけど、サービスを作るにあたって色んな人が使いたくなるようなプログラムが部品として売られる時代がきたらいいなと空想した。
AWSの紹介で、インフラが電気のように手に入るようになったことで、よりサービス開発に集中できるというのがあったけど、プログラムに関してもそういう部品部分が売り買いされる時代が普通にくるのかもしれないな〜。未来を感じました。
↓ハピルスの紹介動画


Mysql に map reduce の job trackerを実装 古橋さん

    • 単一故障点がなくなる
    • 任意のmap reduceタスクを連鎖可能
    • マルチユーザ対応
    • Worker以外は既存のモジュールを利用

Hadoop and HBase for Ranking 蒋さん

Hadoop and h base for ranking processing at rakuten
View more presentations from Rakuten, Inc

    • 楽天の商品は8000カテゴリある。
    • それを期間や地域毎の軸で集計を行う。
    • Hadoop採用前は1カテゴリ分の計算に一日以上かかった。
    • 後から更新が入る場合があるので、mutableなHBaseを採用
    • PureなM/Rを実装
    • HBaseによるリアルタイムに近いソート
    • テーブル分割がなくなるので、シンプルなシステムに
    • shardingのkeyの選定が重要。データが片寄ってボトルネックが発生してしまった。

iPadアプリの楽天ランキングはけっこう愛用していますが、そのバックグランドではこういうシステムが動いていると知って、買い物をする時のワクワク感が増しそうです。

bonding とネットワークスループット 金子さん

    • Bondingの設定を変えて、スループットを測ってみた。
    • 三位
      • balancer - rr. とsrc - mac
      • スイッチのログを見るとログがたくさん。
    • 二位
      • 802.3ad. と src - mac
      • でもNICを２枚使っている割にはパフォーマンスが微妙
    • 一位
      • 802.3.ad と src-dst-ip
      • NIC一枚の時の約1.8倍なので、限界に近い性能が出せているのでは？

ネットワークのディープな知識はなく、何のことだか、さっぱり分かりませんでしたが。。

HadoopとMongoDB

集中力の限界を迎えてメモがとれてない。。3/1に参戦予定のMongo Tokyoでも発表があるそうなので、その時に。


様々な知識を得られたとともに、hadoopを使っている人間として物凄く刺激になりました。NTTデータさんや、主催者の方々、発表者の方々には感謝、感謝です。

hadoop conference 2011

勉強 技術

本日はhadoop conference 2011に参加。
http://www.eventbrite.com/event/1278974447/efblike
定員約350人が約4時間で埋まったとのこと。
始まるまで少し時間があったので、参加している人を見渡しながら、ここにいる人が平均１０台のクラスタを利用していると仮定すると、計3500台で、ラック型で１台１ｍの奥行きとすると、3.5km！！とどうでもいいことを考えていました。

ということで、各セッションのメモ

Amazon Elastic MapReduceの紹介 AWS Jef Barrさん

Amazon Elastic MapReduceの紹介(英語)

    • What is big data?
      • まだ新しい言葉。ただ単にでかい容量というだけではない。
      • 課題として、strucuture, demandの発掘もある。
      • また、それらを迅速に解析できる必要がある。
      • これらの手伝いをするのがbig data tool

    • Elastic map reduce overflow
      • EC2, S3をベースに動く
      • 簡単、スケーラブル、安全、コストパフォーマンス良し。
      • 数百TBの実績もあり。
      • 簡単にデプロイ、監視ができる。
      • AWS management consoleというweb UIに加えて、コマンドラインでの操作も可
    • Elastic map reduce 実行まで
      • データをs3にアップロード
      • ジョブフローの作成、実行
      • 処理が完了したら、S3から結果をとりだす。
    • elastic map reduce removes MUCK from Big Data
      • MUCK -> 雨が降った時とかにできる、"ぬかるみ"のこと
      • Big Dataの扱いでのMUCKとは？
      • これらのMUCKを取り除いたのがEMS
    • Use cases
      • 広告配信、ログ解析、遺伝子計算、financial simulation,検索エンジンの生成、データマイニング
      • Data ヘビーか、CPUヘビーかで、ジョブフローの使い分けができる。
      • 前者はデータマイニング、後者は各種分析やシュミレーションなど。
      • Best buy とRazorfish(広告会社)
        • 35億件 per dayのデータ
        • 7100万UU
        • 170万件のターゲット広告配信
      • 100ノードのクラスタを構築し、２日かかっていた処理を8時間に短縮。
      • 解析が行えるようになったことで、広告効果が500%になった。
      • クリック分析の解析を行う会社では、みんな似たような構成を使っている。
      • 広告宣伝や大量データ解析の需要が増えているように思う。

    • Map reduce概要
      • データをインプット
      • データを切り分け
      • ノードに分配
      • 並列で処理を行う
      • 結果を取り出す。

    • EMSの画像デモ
      • ログファイルをバケット(S3のデータの管理単位)に転送。
      • ジョブフローの生成
        • 名前をつける。サンプルプログラムを使うか、自分で開発したプログラムを使うかを選択。
        • ログ分析用のサンプルアプリケーションもあり。
        • Pig を使って処理を行う。
      • インプット、アウトプット先の指定
      • ノード数 EC2の指定
      • デバッグモードの指定
      • Bootstrap を使うことで、起動スクリプトを自作できる。
      • 処理の実行。(数千のインスタンスで使っているお客さんもいる。)
    • その他の特徴
      • コンソールで進捗状況を確認できる。
      • 自分でmap reduce処理を書くことも可。
      • 自由にスケール。処理中に動的に追加できる。
      • R言語のサポートもしている。RHIPEという環境。

    • Q&A
      • スライドにHBaseでシステム構成をしている図(11枚目)があったが？　-> ユーザのほうで構築した環境になる。現在、AWSとしてHBaseをサポートはしていないが、将来的にはサポート予定。
      • 処理時間が短くても時間単位で課金されてしまうのが悲しい。 -> 時間単位での課金に適した処理を組むべし。

後のセッションで、複数ユーザが居る時の云々でリソースやスケジューラの管理の話があったけれど、EMSをベースに開発していれば、そういったことは気にしなくてよくなるし、大規模クラスタになるほど、サーバリソースを使い切るのは難しいように思うので、PaaSとの相性はさらにいいのかな〜と思った。
ログを転送するという点でセキュリティ的な話や、後はやはり料金的な点が気になるところ。調べてみるか。

Hadoopを使った機械学習 PFI 岡野原さん

MapReduceによる大規模データを利用した機械学習

    • 機械学習
      • データから有用な規則、ルール等を抽出すること。
      • 様々な分野の問題に利用可能。
      • タスクと手法の分離が普及の要因。
      • 手法が抽象化されているので、定義された形でデータを準備できれば、誰でも行うことができる。
    • hadoopと機械学習
      • データは増え続けているので、機械学習の分散並列化は必須。
      • Map reduceをベースにした実装が普及してきている。
      • 元は関係ない２つだが、並列処理部分をhadoopに任せて、そこに適した解析ロジックを考えるほうが効率的に開発できるという発想。

    • Apache mahoutの登場。
      • Hadoop baseなのでスケーラブル。活発なコミュニティ。
      • 裏を返せば、まだ枯れた技術ではないので、業務導入にあたっては要検討。
      • クラスタリング、パターンマイニング、分類、行列演算などが行える。
      • EC2上に構築した環境え、100台強で動かしたことがあるが、リニアにスケールした。
      • ドキュメントの不備、ちょっとしたチューニングがしづらいといったあたりが問題。
    • グラフィカルモデル
      • 確率変数を頂点、変数間の依存関係を枝としたグラフ構造。
      • 言語処理、情報抽出、音声認識、画像解析、遺伝子解析 etc...
      • 計算が非常に困難なのに、データが巨大になっている。

    • 共参照解析。
      • 二つの言及が同じ単語を指しているかを解析していく。
      • 僕、君 とか。

    • 数値最適化の並列分散化。
      • Parameter Mixuture -> ダメだった
      • Distributed Grdien -> ノード間のやり取りが多く通信が混雑、収束が遅い
      • Asynchronous Update -> すごい遅い
      • Iterative Parameter Mixture -> これがいい！収束証明ができ、しかもスケーラブルであることが分かった。

    • Dremel
      • 要チェックな新技術
      • 対話的な大規模データ解析基盤
      • 1兆のデータに対するアドホッククエリの結果が数秒で取れる。
      • クエリ言語はSQL
      • データは繰り返しありの木構造。
      • 列指向のデータ格納
      • クエリに必要なオートマトンの生成
      • クエリ処理アーキテクチャは木構造。根から葉に向かって広がり、葉から根に集約されながら帰ってくる。
      • 850億レコード, 87TBのワードカウント,3000ノード を使っての処理 -> Hadoopでは1000秒、Dremelでは10秒程度。
      • 将来的に高速な推論、分類に利用可能では？
    • Q&A
      • Dremelの使用データの生成ではmap reduceを使うのか？ -> 使う。
      • 教師なしの話が多かったように思うが、データが大規模になるにつれ、そのような傾向があるのか？ -> gmailのスパムメールや優先メールの判定のような教師ありの例もあるが、データが大規模になるにつれ、教師なし + ちょっとしたルールによる解析のほうが面白いのではないかと思っている。


機械学習系の話は、知識不足であまりついていけず。。しばらくは定義された通りにデータを準備してみるほうの立場で、これいいよと聞いたのを動かしてみて、知識を深めていくというフローになるかな。。
Dremelの所で出てきた列志向データベースという単語は昔、情報処理系のDB系のやつの勉強をしている時に聞いて、何のためにあるんだ？と思った覚えがあるけど、こんな所ででてきてビックリした。ていうか当時は勉強しながら、使われていないモデルなんか出さずに、データベース = RDBMSでいいじゃねえかと思っていた気がする。。

モバゲーの大規模データマイニング DeNA 濱田さん

『モバゲーの大規模データマイニング基盤におけるHadoop活用』−Hadoop Conference Japan 2011− #hcj2011

    • ソーシャルプラットフォームとしてのモバゲー
      • ゲーム、SNS, 情報発信、作品投稿
      • 有効会員2300万人。20億PV / day
      • Facebook, Zyngaと同レベルの売り上げ、しかしARPUで見れば約30倍！
      • Facebookはリアルな人間関係が軸になる。DeNAには興味軸のソーシャルグラフも存在する。

    • Hadoop DFSに全行動ログが格納されている。
      • Hadoop系列のプロダクト内で処理を完結できる。
      • Pigの利用。javaでのベタ書きもやってる。
      • Zybraによるスキーマ管理。
      • Perlで書かれたゲームをベースに、perlのMRストリームでシュミレーション。
      • R言語、Mahoutも活用。
      • これらの基盤の上に、DeNA独自のData Mining Libraryがのっかる。

    • Hadoopチューニング
      • パラメーターチューニング
      • 中間ファイルをlzo圧縮
      • 出力データサイズの最適化

    • Pigのチューニング
      • Partitioner の実装の最適化
      • 多段map reduceでの中間ファイルの圧縮
      • 独自UDF
      • 共通のログ loader
    • Mahout
      • 用途に応じたデータ変換
      • 一連の処理の実行を定型化
    • 楽しさのマイニング
      • 一日20億以上の行動情報
      • 統計的に優位に立てる
      • 多くの人へ還元することができる

    • 感情がわかる詳細行動情報
      • Webの広告では行動に対する広告に最適化が行われた。
      • ソーシャルゲームでは感情に紐づいたような詳細な行動情報が取得できるようになった。
      • どういった行動パターンがある時に継続の傾向が見られるのか、利用をやめている人との行動パターンとはどこが違うのか。
      • ゲームレコメンデーション
      • コミュミケーション系サービスの解析では自然言語処理も利用
    • 楽しさの行動パターン
      • きっかけを見つける。
      • サービス継続している人の行動特徴
      • どのサービスがユーザに訴求しているかを解明する。
      • そのサービスを新ユーザに早めに提供することで、継続率を増やせる。

    • やめてしまう行動パターン
      • きっかけを見つける。
      • 飽き始めたユーザの予測、判別。
      • 新しい体験、他の楽しみ方の提供。

    • 健全なプラットフォームへ
      • 不正な書き込み判別
      • 年齢詐称の判別
    • 迅速なサービス洗練
      • 数時間から数日スパンで迅速なサービス洗練。
      • サービスを動的に変化できるソーシャルゲームならでは。
    • 統一行動記述
      • Hadoopに解析しやすい形で、全行動ログを格納している。
      • これは物凄く重要！！！
      • サービス毎にログの形式は異なる。
      • そのままいれてしまうと、何を解析すればいい？、値の意味がわからない、類似の解析を個々に実装する必要がある。
      • バラバラに置いていると、ログの運用だけで大変。
      • そうなるとデータマイニングまで手が回らず、定量解析だけで手一杯になってしなう。
      • 統一スキーマにするといいことだらけ！
        • 各種アルゴリズムの再利用
        • 学習コスト (ログの意味とか)の軽減
        • データ探索、収集時間がゼロ。
        • データマイニング、機械学習などのエキスパートがそれぞれの分野の知識をフルに活かした開発が行える。
    • ソーシャルプラットフォームの世界展開
      • NgCore SDKによるクロスプロットフォーム対応
      • サムスンの端末にプレインされることが決まっている


機械学習とか統計とかR言語の所は知識がまだ無いのであれだけど、hadoopのチューニングの所は本に書いてある通りだったり、データの持ち方の所に関しては、自分でもそういうデータの持ち方をできればいいな〜と空想したことはあるし、多くの人がそうなってれば楽だろうなと考えたことはあるんじゃないかと思う。
知識面だけでなく、考えられる全てのことをしっかりと行動に移している（できない理由を考えるのではなく）という点も、エンジニアのあり方として多いに見習うべきと思った。そういう点を全てクリアして初めて次のステップに進めるんだろうな。
デブサミの時の奥一穂さんといい、DeNAは凄い人が集まっているな〜。そういえば、webマイニング勉強会の資料は何度も見たので、知っていたはずなのに、自己紹介の文部大臣の下りで「おおー。」と言ってしまったwww。


Asakusa エンタープライズ ウルシステムズの神林さん

Asakusa Enterprise Batch Processing Framework for Hadoop
View more presentations from okachimachi.

    • Asakusaの目的
      • Hadoopで基幹バッチをやるためのフレームワーク
      • バッチ実行時間の短縮
        • 今まで時間的な制約でできなかった処理を何度も行うことができる。
        • サービスのレベルを上げることができる
        • 夜間バッチもなくしたい。エンジニアの負荷的(夜間対応やだ！)にも、お客さんの要望的にも。

    • 基幹バッチはややこしい！
      • これをBIツールである、hadoopでやるのはハードルが高い。
      • データ量がめちゃめちゃ多い。桁が違う。
      • 処理自体は単純だが、データフローが複雑で種類も多い。
      • 設計が超重要！！

    • Hadoopに何が足りないか？
      • 開発ツールがない。
      • テストフレームワークも貧弱。
      • 運用は考えられていない。

## 基幹で必要なレベルで考えた場合

    • Asakusaの概要
      • Pig, Hiveと同列の位置。hadoopの上位に位置する。
      • DSL, 外部でのトランザクション管理
      • 開発方法論まで検討
      • コンパイラの提供。 AShigeruコンパイラ
      • Model Generator
      • テストのインテグレーション. ## 超重要。基幹系ではテストが工数の八割!?

    • ビルディングブロックの構成による処理フローの構成
      • Pluggableに色んな処理を組み合わせるイメージ

    • 開発方法論
      • DAGベースで詳細ブレークダウン
      • 構造化手法の提供
      • ビジネスロジック部分はMap reduceを知らないCOBOL開発者でも書ける。
      • オペレーター部分は少し難しいので、知ってる人がやろう。
    • その他機能
      • Pig, hiveにはない基幹向けの演算子や機能をデフォルトで提供。
      • チェックポイントもあり。

    • MRコンパイラ
      • 多層DSLを最適なMap Reduceに修練していく。
      • 素人が見ても撃沈する黒魔術が多用されている。

    • Model Generator
      • TableやviewをSQLで作ると、自動でクラスを生成してくれる。
    • テストツール
      • junitで叩けるツールも提供
      • Model generatorからテストシートが自動生成される。
    • 外部連携
      • デフォルトはsqoopになる予定
      • 現在のprjではもっといいやつ使ってるけど、公開するかは未定
      • 運用のためのスクリプトも自動生成。
      • Monkey Magicの使用を前提。(hadoopクラスタ用のツールとしての実績、クラウド用のライセンス提供。)

## 保守系のツールのライセンス問題は、クラウド化を考えた時にけっこうな問題になるよ

    • OSS化
      • 三月目標。
      • β版欲しい人は連絡ください。
    • まとめ
      • Asakusaを使うと基幹バッチがホイホイ書ける
      • マーケットは確実にBIよりも大きい。億単位のビジネス。
      • 普通の業務系、BIでも使えるよ


基幹業務のことは知らないし、DSLやDAGの知識もないので、ついていけない部分もあったけど、目指している所は感じ取ることができた。
テストに関しては皆どこまで検証してんだろうな〜というのは日々疑問に思っていたし、運用に関しても、自分の中で問題発生後の対応でいいべみたいな気持ちがなくはないので、、こういうかっちりした部門のノウハウから吸収できるところは吸収していくべきと思う。


Hiveを用いたAmeba サービスのログ解析 Cyber Agent 福田さん

Hadoop conferencejapan2011
View more presentations from Ichiro Fukuda

    • サービス概要
      • ユーザの女性が六割から七割
      • アメーバ会員数 1300万人 (スマートフォン 367万 UU)
      • アメーバピグは会員数 600万人、有効ユーザでのARPUは\2000 per 月を超えている
      • 「アクセス解析」というサービスがあって、hadoopの0.13が使われている。現役で動いている。
      • picoではEMRを使っている。

    • Patriot開発までの経緯
      • 2009年に hadoop conference Japanに参加し、CDH, Hiveを知る。
      • その２週間後の伊豆合宿での開発合宿で開発もせずに、サービス解析の重要性を語り合う。
      • 上長に相談し、GOサインをもらい開発を開始。

    • 従来の問題点
      • 各サービス毎に独自解析
      • 容量の肥大化
      • 開発担当者では解析部分に手が回らない

    • Patriotの目的
      • 統合的なログの解析基盤
      • HDFS, Map reduce, Hive, webでの集計結果表示, アドホックなクエリ
    • hive概要
      • (略)

    • 開発体制
      • アプリ側三人、プロデューサー、インフラの人が随時
    • クラスタ環境
      • メモリ16GB, HDD1TB で18台構成
      • NamenodeはNFSでバックアップ
      • puppet, nagios, ganglia
      • HUE
      • ファイルフォーマットはSequence file + gzipの組み合わせ
    • 解析概要
      • ログはHDFS上に、サマリーデータはmysqlに入れている。
      • アクティブ率の一覧
      • ブログ毎での訪問者のユーザの属性
      • Beeswax -> Hive QLをweb UIから直接叩ける
      • アドホックな集計
      • ヒープサイズに注意。(実行計画が長期間保存されてしまうため、メモリが足りなくなるが、保存期間を変える方法が不明。)
      • プロデューサー用に読み込み権限のみのスレーブを準備
      • 実際にプロデューサーがたくさんのクエリを投げている！！
      • Join文を使って激重な処理を投げてしまうようなレベル。


今が新卒３年目と言っていたので、これを提案したり作ったりしたのは２年目の時ってことで、その年次でこれを作っちゃったことも凄いし、そういう発案が入社２年目の社員からなされる会社の風土も凄いし、それを認めて作らせちゃう上司も凄いし、その後プロデューサ系の人にHive QLを浸透させたということで、根気よく教えた側、それを拒否せずに学習した側(しかもシステムをハングさせるような複雑なクエリを生成できるレベル！)、みんな凄い。。
技術面もさることながら、そういった企業文化の面で、見習わなければな〜と思う所がたくさんありました。

マルチユーザでのhadoop環境のポイント. NTTデータ 山下さん

    • Hadoopのエピソード
      • その１ ヒープメモリの枯渇
        • 実際に動かして見るとおこることがある。特にマスターノード
        • 空ファイルや小さなファイルを置かない
        • データ量、ファイル数の見積もりは大切。
        • Gangliaによるモニタリング
      • その２ ライブラリ起因による処理の実行
        • 出力ファイルの一部が一部消失。
        • Hadoopの投機的実行、同じ処理の多重実行が原因。
        • Task-id でファイルの削除処理をしてた！！Task-attempt-id で処理しようね
      • その３ hadoopクラスタの利用拡大
        • マルチユーザで使うにあたっての注意点の話が出てくる

    • 概要
      • 利用者にクラスタ構成は意識させない設計
      • 適切なアクセス制限
      • お互いの利用状況を知らないという前提でものごとを考える
      • HDFSは誰かによって領域をおさえられたり、ファイルを削除されたりしまうようなことが起こりえる
      • MapReduceは好き勝手に実行されて、(優先度highばっかりとか)一向に処理が開始しないとか
      • Hadoopのコマンドを意識させない。 HUEの導入。
      • Hadoopのweb画面にはアクセスさせない
      • 特定のクライアントを通してのみのアクセス

    • HDFS
      • ユーザーグループ、パーミッションの設定
      • クオーターの設定、ブロック数の制限
      • HDFS間の通信
      • 認証、認可 Kerberos, 他のアプリケーションの組み合わせとか

    • Map reduce
      • スケジューラによるジョブ制御 。Fair scheduler, capacity task scheduler。それぞれに特徴がある。
      • 内部通信に関するポリシー
      • アクセスコントロールの設定. mapred.acis.enabled

    • もっと使いこなすには、、
      • ChildプロセスのJVMオプション制御
      • スケジューラ改良
      • 共有資源、占有資源の制御
      • 物理ディスク対策
      • ユーザーグループ
    • Q&A
      • hadoopであれこれするのは無理があり、入り口の認証(Gatekeeper?)でマルチユーザを実現するのが一般的だと思うが？？ -> hadoop内で制御できれば、クラスタを統一できコストが減らせるのではないかということでやっている。 (+hadoop内でどこまでできるのかという挑戦的な意味合いも強い。 濱野さんより）


これの直前にLTもあって、この辺から集中力が低下。。
あと、そもそも、複数ユーザの問題に行き当たるほど使い込めてもいないので、もっと利用シーンが広がってきた時に、ああ、これはこういうことを言っていたんだな〜と分かる日が来ると思う。

hadoopとKNIMEを用いた広告配信 リクルート 中野さん

    • 現状
      • 余剰の35台の研修環境、新規に23台のクラスタ環境
      • Hiveの利用開始、HBaseの検証中
      • メルマガ用のリコメンド、相場表のクロス分析などをやりたい
    • 開発に関して
      • 分析屋さんとシステム屋さんが密に連携して開発を行っている。
      • システム屋さん側の仕事としては、分析屋さんから出てきたロジックの移行や、分析屋さんへのデータ提供など。
      • ２者の間で、視点が微妙に異なる。　SQL的 ←→ R言語的
      • 道具を共通化すれば理解が深まるのではないか
      • ただし、ほんとの解析ツールはすげー高くて、全員にってのは、、→KNIMEを知る
    • KNIME
      • データの処理ロジックをビジュアルに組み立てることができる
      • ノード(細かな処理。joinとかソートとか)の組み合わせで実行状況を可視化。
      • ジョブの進み具合もリアルタイム見ることができる。
      • 各ノードをクリックすることで、その時点でのデータの状況を確認することができる。
      • ドイツのコンスタン大学で開発
      • 全世界で約6000人
      • 日本でのサポートもあり
    • やってみた
      • 既存の処理をコンバート
      • いいとこ
      • 悪いとこ
        • 英語。。
        • SQLで簡単にできることがすげー大変だったりする

    • Hadoop + KNIME
      • 前処理をhadoopでしておいて、KNIMEで取り出して解析みたいな。
      • Hive , KNIME間の各種ドライバを作成中。
      • 解析プラットフォームとしたいが、データ取得部分でSQL的な所は出てしまうので、そこは課題。共通で使えるなにかを用意したり？
    • Q&A
      • 可視化ツールときくと破綻しそうな印象があるが？？ ( +Asakusaでも導入しているが、リファクタリング、重複コードの除去はどうするの？？みたいな問題が起こっている。) -> 色々と制約を入れたりすることで防いでいきたいと思っている。


分析専門の人がいれば、簡単に機械学習とかできそうと勘違いしていたけど、そういう人と仕事をするにあたっては、また別の課題があるんだな〜。ただ、そういうことに気付けたり、色々と教授してもらえる人がいるというのは羨ましい。(そういう系列の人は、コミュニケーションが難しそうな印象もありつつ。)
自分の知識不足 + 集中力不足もあって、やろうとしていることの全体像が掴み切れなかったので、次は簡単なデモなど見れるといいなと思った。
あと、Rでも処理フローをビジュアル化して作れるものがあったような無かったような。。



文字書くのに疲れたのでTL部分はまた明日。。