RT @hamaken: #hadoopreading RT @shiumachi 第9回 Hadoop ソースコードリーディング、もう残り3席か http://hadoop-scr9th-estw.eventbrite.com/

posted at 08:43:56

#event 2012/05/30 Wed 「Hadoopソースコードリーディング 第9回」<http://hadoop-scr9th-estw.eventbrite.com/ > : 今回はHive。あっちのおしごと的にも参加してみたい。が、もろもろの都合をつけられるかしら --;? #hadoopreading

posted at 09:21:12

#index 「Hadoopソースコードリーディング 第8回 (2012/02/08) 参加メモ」<http://twilog.org/nsiena/date-120208/asc > #HadoopReading

posted at 09:12:57

本日のMTGは途中退席させていただいて、 #HadoopReading に移動中。ぎりぎりまで参加していたので、始まるまでに着けないことが確定なのです /_;

posted at 17:57:02

会場着いたー ^^= #HadoopReading

posted at 19:09:41

#event 2012/02/08「Hadoopソースコードリーディング 第8回」<http://hadoopsrc8th.eventbrite.com/ > : 「最近こればっかという気がしつつも MapR を取り上げることにした」とのこと。 #HadoopReading

posted at 19:12:26

「第7回 日本OSS貢献者賞・奨励賞 <http://ossforum.jp/ > に、ぜひ推薦をしてほしい。これだけ言えれば、今日は満足w #HadoopReading

posted at 19:14:03

『オレオレMultipleInputを作る方法』(@muddydixon) : 「MongoDB を使うために MongoMultipleInput を作った経験から。 #HadoopReading

posted at 19:15:57

RT @ryu_kobayashi: ちょっと遅れてUST開始 (live at http://ustre.am/Ht6D/1) #hadoopreading

posted at 19:17:47

「TaggedInputSplit クラスが private なので、DelegatingInputFormatから利用できなくて困った。これは public であるべきでは? しかたなく、バイパスするためのクラスを作成してしのいだ。 #HadoopReading

posted at 19:21:51

ソースコード、読めるほど見えないです…… #HadoopReading

posted at 19:22:49

まぁ、ソースを読めばわかるだろう、といったところかしらん。 < <https://github.com/muddydixon/mongo-hadoop/blob/develop/mul... > #HadoopReading

posted at 19:36:41

『MapR & マルチテナント - MapR ってどうよ? -』(リクルート 中野さん、高林さん、大坪さん) : 「MapR とは。という資料は作ってません! というわけで、EMC の方に 10分ほど前にお願いしました!!」 (^^; #HadoopReading

posted at 19:54:40

「＼OSSな場で、プロプライエタリな話をするのはどうかという気もしますが／。 MapR Tech. は、元Google エンジニアによって創業。2年間の闇開発ののち、2011/05 に公開。 #HadoopReading

posted at 19:59:59

「HDFS を C/C++ で MapR FS に再設計・実装。Java API としては 100% 互換。 分散NameNode, NFS アクセス, ボリューム, ミラーリング, スナップショットなどをサポート。様々なボトルネックを解消。 #HadoopReading

posted at 20:00:56

「ここからが本題。MapR の 1.性能検証, 2.マルチテナントでの機能検証, 3.リクルートにおける Map の評価について。 #HadoopReading

posted at 20:03:22

「中古車サイトで使われているサマリ処理のバッチ処理で比較。パーティション・圧縮で MapR が 1.3倍、非パーティション非圧縮で 1.76倍程度高速。もちろん、チューニングによって変わるので注意。 #HadoopReading

posted at 20:06:23

「マルチテナント検証。1クラスタに複数ユーザのジョブを実行。ユーザは、お互いに隔離されて、データなどは見えないという設定。 #HadoopReading

posted at 20:08:06

「ユーザは Linux ユーザ準拠。MapR クラスタを一つのリソースとしてとらえて、ジョブ管理などの操作権限をいろいろ設定。ボリュームという、ユーザや HDFS などとは独立した論理ユニットを使用。 #HadoopReading

posted at 20:14:09

「FairScheduler に関して。プールのスロット数の設定を変えて、1テナント内で複数ジョブが実行された時のプールへの割り当て状況を確認。これは、課金処理などを想定した調査。 #HadoopReading

posted at 20:17:57

「じゃらん PV データ 1ヶ月分をロードし、検索処理などを行なう。ZooKeeper と CLDB に最大 3台、他に 8台を割り当てる "3+8台構成” や、全てを均等に使う "11台構成"、8台は不使用とする "3台構成" を比較。 #HadoopReading

posted at 20:23:01

「3+8台、11台構成はほぼ同様に。3台構成は台数なりに。それなりにフェアな割り当てが行われていることを確認。 #HadoopReading

posted at 20:24:21

「フェイルオーバ。Apache Hadoop と異なり、マスタ/スレーブを意識した設計が必要がない。 #HadoopReading

posted at 20:28:24

「JobTracker の切替え時間を累積時間で調査。停止検知まで 30秒前後 (ハートビートのタイミングか), 切替終了まで 1分前後, 実行中ジョブの引き継ぎ完了まで 6分前後, ジョブ実行西海まで 13分程度。 #HadoopReading

posted at 20:29:53

RT @muddydixon: 本日の資料です。 http://www.slideshare.net/muddydixon/multipleinput #hadoopreading

posted at 20:37:59

「残り 5分くらいで Mesos のばーっと説明をするので、覚えて帰ってください >< Mesos は、Apache Incubator プロジェクト下で展開している、効率的なリソース分離・共有機能を提供するクラスタマネージャ。 #HadoopReading

posted at 20:38:46

「Hadoop クラスタから Mesos マスタにジョブ投入され、その後になって初めて Mesos スレーブ (== JobTracker) が起動されて、データノードで処理が実行される。 #HadoopReading

posted at 20:42:19

「MapR と異なり、Mesos では、CPU 使用率やメモリ使用率に制限をかけられない。マルチテナントでは、注意が必要。 #HadoopReading

posted at 20:44:08

マルチテナント環境での MapR と Mesos の利点・欠点の比較表。これは目立つところで共有すべきだと思った。 # 読みきれないよー /_; #HadoopReading

posted at 20:46:18

「リクルートにおける MapR に対する評価。利点: パフォーマンス、運用、耐障害性、バックアップ、NFS。課題: 保守、将来性、ドキュメント。CDH の相対評価はこれらが逆転。 ＼速いだけじゃ不安。CDHはNTTデータの保守サポートがあって安心／。 #HadoopReading

posted at 20:50:46

RT @mogemogu: MapRの宣伝かと思ったらNTTデータの宣伝だったおw #hadoopreading

posted at 20:52:04

RT @shin_semiya: 「CDHに将来性を感じた理由ってなんですか？」「ステマ？」　#hadoopreading　→「いつEMCがHadoopから独自路線で行くぜ－ということへの危惧」「NTTデータがサポートしているから」→「NTTデータがMapRをサポートしたら？CDHを捨てたら？」

posted at 21:13:15

RT @shin_semiya: 結論：「 @shiumachi さんがいるからCDH超サイコー」　#hadoopreading

posted at 21:13:21

なにやら、書籍の執筆が進んでいるらしい。次回は、3月かも、とのこと。 #HadoopReading

posted at 21:20:10

というわけで、おしまい。もう少ししたら解散、かな。 今回も、おもしろかった。いつもありがとございますー。 #HadoopReading

posted at 21:21:17

今日の #hadoopreading は、TL によるといつになくひどい(謎)様子だったようで、行けなかったのが残念でならない。ぐぬぬ。

posted at 22:38:27

#index 「Hadoopソースコードリーディング #6 参加メモ」<http://twilog.org/nsiena/date-101217/asc > #hadoopreading

posted at 03:14:37

#event 「Hadoopソースコードリーディング #6」<http://atnd.org/events/10425 > : 日時が "2010/12/17 19:00 to 2010/12/18 13:00" になってる。もしかして:夜通し(違) #hadoopreading

posted at 15:29:57

そろそろはじまる #hadoopreading

posted at 19:10:01

『Hadoop World NYC 2010レポート』(山下@NTTデータ) #hadoopreading

posted at 19:12:21

「開催は約2か月前の 2010/12/12 Tue。参加者は900名 (2009年は 500人弱)。BI関係の人が目立ってた。5パラ 全42セッション。事例発表、Hadoopを利用した製品紹介、技術評価など。 #hadoopreading

posted at 19:15:06

.o(だれか、公式サイトの URI、ぷりーず #hadoopreading

posted at 19:16:07

「キーノートの事前アンケートによると、平均 66ノード, 114TB のクラスタ, 総サイズ 60+TB。Tim の特別講演では Hadoop の Ha の字も出なかったw リアルタイム/センサプラットフォーム/予測的解析など。 #hadoopreading

posted at 19:18:43

「個別事例 ebay。ランキング処理や商品推薦に利用。2010/5 に養家用 500+台を運用。/11 に実運用で 850プロセッサ, 16PB。 #hadoopreading

posted at 19:21:39

エコシステム: Ganglia, Nagios; HUR, Oozie, Mahout; Pig, Hive, Perl, Pythom Scala, ...; Fair Scheduler, ... #hadoopreading

posted at 19:21:46

「個別事例 AOL。広告用, 検索用, コンテンツ用の 3系統のクラスタ。最初は 50台の要らなくなっていたマシンを使って構築開始。Mahout を活用しながら情報推薦環境を開発。まだ商用ではなく試験用という位置づけ。 #hadoopreading

posted at 19:24:01

「Cassandra や MySQL と組み合わせて、バックエンドとして Hadoop を利用している。URL ビューアなどのツールを作って利用している。 #hadoopreading

posted at 19:24:51

「個別事例 Intel。Intel の HWによる Workload での性能評価での統計処理などに活用。LZOデータ圧縮の恩恵, HT の恩恵, HW選定などの比較。 #hadoopreading

posted at 19:27:42

「個別事例 GE。新しいビジネス展開のために、Twitter や youtube などの情報を利用した感性分析。MySQL で二日ほど → Hadoop で 1h 程度。結果は MySQL へ戻して、利用者は MySQL のデータを参照。 #hadoopreading

posted at 19:29:55

「個別事例 リクルート。社内の情報集積基盤の一つとして検討。評価モデル: 1.データが少ない短期のターゲット, 2.データが溜まりつつある短中期のターゲット。3.データ規模が大きく成長した長期のターゲット。3. はそれなりに有用そうと結論。 #hadoopreading

posted at 19:32:00

「個別事例 米国陸軍。組織 →グループ →個人 といった階層化された情報に対する関連性を評価。Digital Reasoning 社 Synthesys を採用。Hadoop で処理 → Cassandra で利用。この組合せは他の事例でも多かった。 #hadoopreading

posted at 19:34:29

「製品紹介: pentaho, membase, Kermasphere, Quest woftware など。BIツールとの連携。Hadoop サーバの分解。ほか。/ #hadoopreading

posted at 19:36:43

「まとめ: データ分析用途での利用が増加。BIベンダによる BI製品との連携の活発化。技術解決は終わり経営課題など高次の課題へ適用されつつある。＼もっと世界に発進して行きましょう／ #hadoopreading

posted at 19:38:04

「Q.NTTデータの発表に対する反応 A.それなりに受けたと思うけど、間隔が広すぎて閑散としていた。盛り上がらない。 #hadoopreading

posted at 19:39:17

「Q.利用についてのアンケート結果は A.一部が特に大規模でほとんどを占めている。十数台規模のユーザが大半を占めているのではないか。あくまでも平均としてこれくらい。 #hadoopreading

posted at 19:41:16

『HDFSソースリーディング第2回』(@shun0102) #hadoopreading

posted at 19:42:23

RT @shun0102: 今日の発表はこのpdfの資料の話をするので参考として載せておきます http://ow.ly/3qHoc (pdf) #hadoopreading

posted at 19:44:22

「資料を slideshare にアップロードしたよ <http://twitter.com/shun0102/status/15714500468547584 >。前回: Hadoop の FS はプラガブル。今回はサーバの方を紹介。 #hadoopreading

posted at 19:44:52

「HEFS-265 の appendDesign3.pdf (Append/Hflush/Read design)。書込み時、読込み時、エラー処理時の振舞いの詳細が書かれている。一貫性モデルや故障時の振舞いの理解に。 #hadoopreading

posted at 19:46:35

「DataNode でのブロックをレプリカ、NameNode でのブロックをブロックと呼んでいるのを踏襲する。レプリカはそれぞれの状態を持つ。 #hadoopreading

posted at 19:48:59

「以前は、ブロックが作られるとテンポラリ状態になって、クローズされると完了状態になるか、エラーなら削除状態に。Append 導入後は、完了状態からテンポラリ状態に。ここでエラーになると削除状態になる。これを避けるため新しいブロックの状態が必要。 #hadoopreading

posted at 19:50:19

「目標。1.Append する前のデータに対する強い耐障害性。Hflush したデータに対するベストエフォートな耐障害性。※ Hadoop-1700 では原子的な追記を目指していたが、今回は原子的ではない。 #hadoopreading

posted at 19:52:11

「レプリカの状態: 1.Finalized, 2.Rbw (Replica Being Writtern to), 3. Rwr, 4. Rur (Replica Under Recovery). 5.(Deleted?: 読み落とした ><) #hadoopreading

posted at 19:53:25

「2.Rbw: レプリカが作成されるか append される時。常にファイルの最後のブロック。他のレプリカとデータサイズが一致していない。 #hadoopreading

posted at 19:54:38

「3.Rwr (Replica Waiting to be Recovered): データノードが死んで再起動した時、全 rbw レプリカは rwr へ。パイプラインには復帰しないので新しいバイトは受け取らない。リースリカバリの動作と併せて理解。 #hadoopreading

posted at 19:57:17

「Temporary: レプリカ作成かクラスタのバランシングのためのレプリカ。 #hadoopreading

posted at 19:58:11

「ディスク上での保存方法: dfs.data.dir.{current,ftmp,rbw} に保存。 #hadoopreading

posted at 20:00:38

「再起動された時、current (finalized) → finalizrd, tmp (temporary) →削除, rbw (rbw,rwr,rur) rwr の処理がされる。 #hadoopreading

posted at 20:00:44

「レプリカの状態遷移図。ドキュメントに書いてあるのを簡略化したもので実際には盛っと複雑。」.o(一気に複雑になったな ^^; #hadoopreading

posted at 20:02:05

「ブロックの状態: UnderConstrunction (書き込み中), UnderRecovery (復旧中, 有効期限が切れたら削除), Committed, Complete。状態遷移図: 通常時, クライアントが死んだ時, NN再起動時。 #hadoopreading

posted at 20:07:09

「まとめ。Appendの目的: 一度 finalized されたデータに対する強い耐障害性と、Hflush したデータに対するベストエフォートな耐障害性。Append のための新しいレプリカの5状態とブロックの4状態を導入。状態はメモリ上に保存。 #hadoopreading

posted at 20:09:31

「次回は一貫性保証について説明する予定。 #hadoopreading

posted at 20:09:56

「Q/A.ブロックが finalized になり、レプリカが committed になったのが確認されたら、ブロックが complete になる #hadoopreading

posted at 20:11:37

.o(あれ、状態名が違ったか #hadoopreading

posted at 20:12:39

g「Q/A.ここまで複雑にしてまで append がほしかったのは、ログの追記などの用途ではないか。 #hadoopreading

posted at 20:15:39

「Q/A.複雑になったが、実装は複雑にはなったが、性能には影響してはいなそう。書込みのスループットはあまり変わらないのではないか。実験した範囲での印象でも、あまり変わっていない。 #hadoopreading

posted at 20:17:20

18:30 まで休憩。次は『BigSheets』(@pandrbox) #hadoopreading

posted at 20:19:03

「気軽に聞いてください。PARTAKE は hadoop と関係ありませんんw #hadoopreading

posted at 20:31:10

「DB は Cassandra。RDB に向いたものをあえて作ってみて苦労してみるのが目的。」.o(この姿勢はえらい #hadoopreading

posted at 20:33:04

本編に戻る。『BigSheets』(@pandrbox) #hadoopreading

posted at 20:35:59

.o(あれ、タイトルが違う ^^;;? #hadoopreading

posted at 20:37:09

「IBM Biginsight。下層半分くらいは OSS を使っている。IBM 内部で検査したものしか製品に使えないという制限がある。 #hadoopreading

posted at 20:41:22

上層に Job Scheduler / Big Data Analytics + Workflow Mgmt Engine / Jaql + BigSheets。BigSheets は UI になる。 #hadoopreading

posted at 20:41:27

「SPSS から Jaql 経由で Hadoop にアクセスしたりすることもできる! #hadoopreading

posted at 20:42:21

「Jaql (JSON QL)。準構造化 (semi-structured) データ処理。原稿を書いた例を使っちゃうよ。」.o(半構造化と訳されることが多い気がした #hadoopreading

posted at 20:46:10

.o(え。東京に戻ってきて、ここに直行してきたの!? #hadoopreading

posted at 20:50:52

「BigSheets。表型の UI。シートから新しいシートを作ることが、一つのデータ処理ステップに対応。表計算ソフトと同じように、行や列に対する計算式としてデータ処理指定ができる。 #hadoopreading

posted at 20:53:42

「一部の計算結果だけを見せることで高速に応答。全てのデータを処理するには、ちょっと操作に手をかける必要がある。Jaql は Java で、BigSheets は Pig で処理を実行する。 #hadoopreading

posted at 20:56:06

「Q/A.製品としては幾らくらいか。未発表なので言えない。Q/A.データ投入は。インポート機能がある。HTMLでリンクされたデータをどんどん取り込むこととか、PCから、ネットワークからなど、いろいろ。細かく制御するには Jaql の方が向いている。 #hadoopreading

posted at 21:00:04

「Q/A. TBクラスのデータで表示がかたまることがありそうだけど。一部しか表示しないし、バックグラウンドで非同期に処理しているので問題ない。 #hadoopreading

posted at 21:03:00

「Q/A. 運用監視系のツールは。MetaTracker というワークフローエンジンなど。障害回復やエラーハンドリングなども扱う。 #hadoopreading

posted at 21:03:05

『検索エンジンのための転置インデックス構築 - Data Intensive Text Processing with MapReduce 第4章』(@nokuno) #hadoopreading

posted at 21:04:05

「大規模テキスト処理の教科書。Hadoop に限らず、MR 全般を扱う。<http://www.umiacs.umd.edu/~jimmylin/book.html > #hadoopreading

posted at 21:07:08

「ウェブクローラ。クロール先に過大な負荷をかけてはいけない。クロール優先順位を決める。重複を避ける。複製へ対処。スパムへ対処。などが必要。 #hadoopreading

posted at 21:09:04

「検索エンジンの構造。表現関数で表現に変換して、索引を作成。比較関数で索引と問合せの表現と比較。転置索引は、単語から文書ID と頻度を検索可能にするためのメタデータ。 #hadoopreading

posted at 21:11:15

「初期実装のボトルネック: posting リストをメモリに保持, posting リストを自前でソート。→ 値を鍵に含めて MR でソート。e.g. {term} → {docid,num} を {term,docid} → {num}。 #hadoopreading

posted at 21:17:38

.o(Ruby でスクリプト書いてる時とか、富豪的に同じようなことをよくするなぁ ^^; #hadoopreading

posted at 21:19:55

「Q/A. それでもリストが長くなるとメモリを食い潰すよね。その通り。同じdocid の文書が複数ノードにばらまかれてしまう。ハッシュ関数を docid だけで計算するようにするなどで回避。 #hadoopreading

posted at 21:22:12

「差分符号化。docid の差分を取れば値の上限が小さくなる。e.g. {1,9,21,34} → {1,8,12,13}。更に、値の大きさに合わせたビット数を使うユナリ符号を利用。他の符号化でも、ユナリ符号を利用する。 #hadoopreading

posted at 21:25:35

.o(これで、値の分布の上限は何%くらいに削減できるのかしら #hadoopreading

posted at 21:26:03

「ガンマ符号: 指数部(のユナリ符号) とオフセット(2進符号) のに分割して表現。e.g. 9 は 2^4 + 001 → 1110:001 #hadoopreading

posted at 21:28:26

「デルタ符号: ガンマ符号と応用だが、指数部も再帰的にガンマ符号で符号化する。ライス符号: 可変長符号 + 固定長符号。ごロム符号: 2^k でない b も許す拡張。 #hadoopreading

posted at 21:41:32

.o(バッテリが悲鳴を上げ始めた >< #hadoopreading

posted at 21:43:28

「次回は 1/末 or 2/中くらい。@okachimachiorz さんの期間で使うための話が確定。連載ネタ募集中。今こそ HBase 入門? また来年! #hadoopreading

posted at 21:58:43

解散した。みなさん、どうもありがとでした。今回も楽しかった ^^= #hadoopreading

posted at 22:11:11

@yutuki_r 読み返してたら、じわじわきた... ^^; #hadoopreading

posted at 22:38:22

@kkawamura しっかりとっちゃってください ;_; #hadoopreading

posted at 23:10:41