PrestoとかAnsibleとかその辺の話を軽く書いてみる - wyukawa's diary
今日はPrestoとかAnsibleとかその辺の話を軽く書いてみようと思います。突っ込んだ話が出来るわけではないのであしからず。 僕のところの環境ではPrestoを使っていて、PrestoはDataNodeやNodeManagerと同居してます。主なユースケースはアドホッククエリの実行です。とあるレポートを作りたいってなったときにデータの中身をチェックするのに使います。従来だとこれがHiveだったのですが、HiveだとMapReduceになって遅いので（ローカルモードで済む場合もあるけど）、その点Prestoは早くていいです。ただこれは僕の環境がスモールデータだからっていうのもあって、圧縮済み数百GBのデータに対してselectかけるとかだとPrestoといえども遅くなると思います。あとなにげに良いのがPresto CLI経由だとカラム名が表示されるのでどのデータがどのカラムなのかすぐ分か
『Prestoとは何か，Prestoで何ができるか』 - トレジャーデータ（Treasure Data）ブログ
トレジャーデータはクラウドでデータマネージメントサービスを提供しています。 Hadoop Conference Japan 2014 以前に告知したHadoop Conference Japan 2014で，弊社Software Architectの古橋が発表しました。 テーマは，Facebookが公開した新しい分散処理基盤，Presto。実はFacebookが彼らの超大規模なデータセットに対してインタラクティブに結果を返せるようにと開発されたものです。開発が始まってまだ2年も経っておりませんが，今ではトレジャーデータを初めとして多くのハッカー達がコミッターとして参加する活発的なプロジェクトに成長しています。 PrestoはHiveやImpalaと同じ「SQL Query Engine」であり，特に数百GBを超える大規模データに対してもインタラクティブなレスポンスを（コンマ0秒以下，遅くて
Aimingデータ解析チーム現場だより - Qiita
ホゲェ〜 なんか色々とまとめといた方が良さそうだ。 自分にとって数が多くて意味がわからんし。 まだ社内データは収集する環境を整えている状態だ。 整えているといってもできてるんだけど、 なんか色々と新しいツールが出てくるしそれに追っついて 書き換えちゃったりを繰り返している。 意味がわからなくなってきたのでまとめてみよう。 社内で共有するにはQiitaに上げたほうが良さそう。 あげちゃまずいものは書いてないつもりだ。 まずかったら消す。 データ解析チームが何やってるのかをまとめてみた。 各担当者の名前を出して問題なさそうなら出そうかなあ Aimingデータ解析チームについて データ解析チームだとつまらんし愛情がわかないのでチーム名をつけている。 Monolithだ。モノリス。あのモノリス。 @shibacowさんが考えだした。トテモ良いチーム名だと思う。 チームメンバー は以下の3名 @sh
SQLite + Pythonユーザ定義関数組込で進捗ダメじゃないですになりました - あんちべ！
概要 これまで「Hiveからデータ取得・簡単な加工→Pythonで加工・分析」 という流れで作業していたのですが、 Hive→SQLite→Pythonという流れにしたところ進捗が改善されたので、 SQLiteの簡単な使い方とPythonによるSQLユーザ定義関数の組込方法 についてメモを残しておきます。 特にユーザ定義関数の組込を自由に出来ると、 分析する際、相当楽になるということに気付きました。 SQLite挟むことで何がどう改善されたの？ Hiveはデカいデータをゴリゴリ取ってくる分には SQLちょっと書くだけで済むので大変便利ですが、 初動遅いためちょこちょこ小さいデータを何度も取ろうとするとストレス溜まります。 そのため、これまではある程度のデータをまとめてHiveで落としてきて Pythonで加工してから分析するという流れを取っていました。 ただ加工するために似たようなコード何
Facebook、分散SQLエンジン「Presto」公開。大規模データをMapReduce/Hiveの10倍効率よく処理すると
Facebookは、数ペタバイト級の大規模データに対しても、対話的にアドホックな問い合わせを可能にする分散SQLエンジン「Presto」を、オープンソースで公開しました。 PrestoはFacebook社内で大規模データの分析のために開発され、すでに同社社内使われているもの。 FacebookはPrestoを開発した背景として、大量のデータをHadoop/HDFSベースで保存したものの、バッチ指向のMapReduceではなく、リアルタイム性に優れた処理が必要になったためだと、次のように説明しています。 Facebook’s warehouse data is stored in a few large Hadoop/HDFS-based clusters. Hadoop MapReduce [2] and Hive are designed for large-scale, reliabl
Treasure Dataでの大容量データベンチマーク - Qiita
あふれるデータ 会社で、Treasure Dataを使った分析システムを作っている。ゲーム情報を収集して、ユーザーの体験向上に役立てるためだ。そのため、ユーザーの行動を細かく把握する必要がある。勢いデータ容量は増えてしまう。加えて、オンラインのゲームは、パッケージゲームと違い売って終わりではなく、その後何年にも渡って、サービスを提供する。そのため、ユーザーの行動ログは数億件に達することも珍しくない。 Treasure Dataでのログ分析 先に書いたが、大量のログに対応するため、hadoopを利用した問題解決が様々な企業から提供され始めている。タイトルに有るTreasure Dataもその企業の一つだ。こちらからは、ログを送るだけでhadoopやhiveを用いた分析環境を提供してくれる。一方で、こちらが分析機材を用意するわけではないため、どのくらいの速度で分析できるかわからない。特に複雑な
日記/2013-10-14/ボカロは衰退している？ - PukiWiki
変わり映えしない同じような曲ばかりなら、そりゃ飽きられますわ。 -- 2013-11-17 (日) 07:52:35 減ってる！とは大声では言い辛い微妙な感じかなあ -- 2013-11-17 (日) 08:46:58 ボカロPのほとんどがアマチュアなんだから、そうそうヒット曲ばかり出てこないでしょう。 -- 2013-11-17 (日) 10:58:43 衰退した？とか言われてるうちは衰退してないよね -- 2013-11-17 (日) 13:09:14 数年、何ヶ月と短い時間で判別しても芸能界とは違うので意味無い、気長に見守るのが大事 -- 2013-11-17 (日) 17:37:03 ボカロが飽きられてきているというより曲が飽きられてきているんだろ。波があるのは当然。 -- 2013-11-17 (日) 18:22:25 ボカロが飽きられてきているというより曲が飽きられてきているん
Elastic MapReduceを使って、FluentdでS3上に格納した、Ltsv形式のNginxのアクセスログを解析してみたお話。 - Technofara
今回何故、Elastic MapReduce + S3 + Fluentd + nginxを調査したのか Mysqlとか、analyticsとか、そのほかで色々データは取っていってるのですが、 更に細かく解析するためには、ログレベルでの解析も必要になってくると思い調査し始めたのがきっかけです。 調べてみると、Redshift、Big Query、TreasureDataなど色々あるんですね、 でも今回は、Facebookで流れてきた記事に目がとまったので、まずはとElastic MapReduceの調査をしてみました。 構成としては、Elastic MapReduce + S3 + Fluentd + nginxでやってみます。 Nginxで書きだしたltsv形式のログが、fluentdでS3に転送されています AWS上で準備（Elastic MapReduce Job Flows作成）
単純な集計とデータサイエンスによる分析とで結果が食い違うかもしれない3ケース - 渋谷駅前で働くデータサイエンティストのブログ
一般に、データ分析の大半はそれほど高度なテクニックの類を必要としないものです。僕も常日頃から口に出して言うことが多いんですが、「統計学だの機械学習だのの出番なんてそもそも少なくて当たり前」。工数もかかるし、できればやらない方が良いです。ぶっちゃけ単純な四則演算で十分なケースの方が多数派でしょう。 なので、普段はDB上でSQL（というかHiveなど）でサクッと四則演算だけで集計処理を済ませてしまって、その結果だけを表示するようにしておいた方が圧倒的に楽で手っ取り早いはず。多くのBIツールもそういう考えのもとで作られていると思います。 ところがどっこい。世の中には、単純な四則演算での集計結果と、データサイエンスを駆使した分析結果とで、食い違ってしまうケースが何故かあることが知られています。どちらかと言うとレアケースだとは思いますが、その矛盾をおざなりにするととんでもないことになることも多々あり
「カジュアル」な規模のデータクラスター上でのデータ解析処理 « NAVER Engineers' Blog
今年はさだまさしさんのデビュー40周年ということで、記念コンサート「さだまつり」も絶賛開催中の折も折、残暑も厳しい中皆様いかがお過ごしでしょうか。大平です。 さだまさし氏は経験の豊富な方ですので彼の歌や発言から学ぶことは大変多いのですが、個人的に非常に感銘を受けているのは「歌はコンサートで成長する」という言葉です。歌い手として、「歌」という作品を作って公開・販売するだけが仕事ではなく、実際にコンサートなどでお客さんに届け、お客さんの反応を参考にしたり日々の演奏活動の中で試行錯誤を繰り返して、内容をブラッシュアップし洗練させていく過程を指して先の言葉があるのだと思います。実際にさだまさし氏の曲はCDに収録されているものと実際にライブで演奏されるものとでアレンジが大きく異なり、かつ作品としても質が向上しているものが少なからず存在します。 …あまりさだまさしの話を続けると本当に上長に叱られますの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
excale.net
【14-B-2】グリーを支えるデータ分析基盤の過去と現在（橋本泰一〔グリー〕）
Cloudera | ハイブリッドデータカンパニー
TechCrunch | Startup and Technology News