Treasure Dataでの大容量データベンチマーク - Qiita
あふれるデータ 会社で、Treasure Dataを使った分析システムを作っている。ゲーム情報を収集して、ユーザーの体験向上に役立てるためだ。そのため、ユーザーの行動を細かく把握する必要がある。勢いデータ容量は増えてしまう。加えて、オンラインのゲームは、パッケージゲームと違い売って終わりではなく、その後何年にも渡って、サービスを提供する。そのため、ユーザーの行動ログは数億件に達することも珍しくない。 Treasure Dataでのログ分析 先に書いたが、大量のログに対応するため、hadoopを利用した問題解決が様々な企業から提供され始めている。タイトルに有るTreasure Dataもその企業の一つだ。こちらからは、ログを送るだけでhadoopやhiveを用いた分析環境を提供してくれる。一方で、こちらが分析機材を用意するわけではないため、どのくらいの速度で分析できるかわからない。特に複雑な
ほぼやけくそHive Hacks – OpenGroove
Hive Hacksあれこれ。内容はほぼO’REILLY Hadoop Hacksからの引用そのまんま。ただの個人メモなのだが、ずうずうしく公開させてもらいます。いろんなところに記録しておいてもすぐに「あれ、あのメモどこやったっけ」となるのでここに書くのが一番なんだよね。書いたからって理解できるわけでもないんだが… （初めに書いておくと、この投稿長いです） 基本原則的なこと。 ●UPDATEは回避する 処理速度が遅延するため、UPDATEを多数含むようなSQLをHiveSQLに変換することは避けるべき ●MapReduceタスクのオーバーヘッド Hiveは「高スループットを目指す処理には向いているが、低レンテンシを目指す処理には向いていない」というMapReduce処理の特徴を引き継いでいる。MapReduceタスクのオーバーヘッドが付きまとうことを念頭におく。 ●並列分散ができない処理
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
