虎塚スマートフォン用の表示で見る虎塚この広告は、90日以上更新していないブログに表示しています。2014」へ遊びに行ってきました。使ったことない技術の話をいろいろ聞いてみよ〜〜という軽いノリで、14:40のセッションから参加しました。以下にメモをアップしておきます。あとで概要みるRMが落ちたらどうなるか感想YARNのアーキテクチャの話がすごく面白かった。1.6対応なんですね。土橋さん最初は、スペシャルゲストの田中聡さん(NTTドコモ)による「社会の頭脳システムの構築と運用」の話。同一クラスタ内でデータを共有しながら使うモデルに期待YARN今後は、インメモリ、ストリーム、バッチ処理をYARNの上でやる感じとのこと。ここで土橋さんにバトンタッチして、巨大Hadoopクラスタの上でのSPARKのお話。今回の検証で確認したかったポイント4つの説明。数十TBのデータをSparkに突っ込んでもちゃんと動くかどうかおなじみwordcountのプログラムでユーザ定義のオブジェクトをSparkのキャッシュに明示的にのせることができるロジスティック回帰のプログラムでシャッフルプロセスのパフォーマンスGroupByTestというプログラムでmulti-stageジョブにSparkを使うとどうなるかとあるプロジェクトで(詳細は公表できないらしい)検証環境の紹介。CentOS線形にスケールしたデータローカリティが効いた?キャッシュにデータをのせた結果を確認3回の学習データの読み込み1回目はHDFSから。2、3回目は一部キャッシュから、一部HDFSから。キャッシュに乗り切らないサイズになると、乗った分については処理時間を短縮してくれるユーザ定義のオブジェクトをぽんぽん載せるとメモリを有効活用できないキャッシュにのせるデータをできるだけシンプルにするべき(シンプルとは?については後述)大きなシャッフルを投げた結果データサイズが大きくなっても大きな変化はなし。I/OとおなじくらいディスクI/Oによって制限される大きなデータをシャッフルしようとするとメモリのチューニングに苦労するフィジビリティテストに成功?最後にTipsについて。嶋内さんImpara凄く速いから皆使えという話。実際に使われるメモリはクエリによる(どれくらいのサイズのテーブルの何割の行を使うのか?)新しめの機能の紹介。Warehouse?)ワークロードにおける評価指標レスポンスタイム並列性とクエリスループットデータサイズ計測の注意点の話。実際のデータを個々のワークロードで確認してね評価データとしては1TB以上はないとダメ今回は15TBでテストしたあと、今年の今後のリリースについて。性能を決めるのはどんなクエリを発行するかなので、クエリの書き方やデータの持ち方を考えるのが大事なんだろうなぁと。LuceneのラッパーLucidWorksを今回は使ったなぜこれらの検索エンジンを使うかというと、クエリのモデルとレコメンデーションのモデルとが似通っているので、効率的に検索エンジンに表示できる、というアイデアによる。ここからサンプルアプリケーションを使って説明。リアルタイム計算が必要。結果のディザリングの話が面白かったです。amazon.comのオススメ商品が毎回ちょっとずつ違うのは、そういうわけなのかな。NS-SHAFTやってみました(買ったばかりのiPhoneで初めて遊んだ記念すべきゲームになりました)。Conference楽しかったです。運営の皆さま、発表者の皆さまありがとうございました。扇子もこの夏活用させていただきます。アーカイブはてなブログをはじめよう!torazukaさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。