タグ

hadoopとfluentdに関するtknzkのブックマーク (4)

  • Hadoop Conference Japan 2014いってきた&しゃべってきた - たごもりすメモ

    Hadoop Conference Japan 2014- Eventbrite 今年も開催されたのでいってきた。主催者の方は当におつかれさまでした。毎回規模がでかくて、これやるのは当大変だろうなと思う。参加登録者は1299名だそうな。 全体的な空気としてはいよいよYARN移行が避けられず、その上に乗っかるデータ処理フレームワークとしてMapReduceも今後存在しつづけるもののSparkやTez*1が登場し、処理記述言語としてはもう単純な処理についてはSQL一択ですかね、という感じ。機械学習系やそのほかのワークロードはまた違うだろうけど。あとはMPP系のエンジンがその脇にある、という。 今回は事例の話が極端に少なくなって、みんな各コンポーネントについての話をしてた気がする。技術的には過渡期だということかな。いいことだ。 参加者アンケートでFluentdを使っていると答えた人が200人

    Hadoop Conference Japan 2014いってきた&しゃべってきた - たごもりすメモ
  • Googleの虎の子「BigQuery」をFluentdユーザーが使わない理由がなくなった理由 #gcpja - Qiita

    「BigQueryは120億行を5秒でフルスキャン可能」は当か? 先日、kaheiさんがGoogle BigQuery(Googleクラウドの大規模クエリサービス)について、こんなエントリを書いていた。 とにかくパフォーマンスがすごい。(Fluentd Meetupでの)プレゼン中のデモで、ディスクに収められた5億件のデータをSQLでフルスキャンするのに3秒しかかからない。9億件のデータを正規表現を含んだSQLでスキャンしても、7秒で終わる(これ、記憶がちょっとあいまい。もう少しかかったかも)。これには驚いた。佐藤さんがGoogleに入社して一番驚いた技術が、一般公開される前のBigQueryだったと言っていたが、その気持ちはわかる。 From Fluentd Meetupに行ってきました これを読んだ時、BigQueryの検索スピードについてちょっと補足したくなった。確かにFluent

    Googleの虎の子「BigQuery」をFluentdユーザーが使わない理由がなくなった理由 #gcpja - Qiita
  • Logをs3とredshiftに格納する仕組み

    1. LogをS3と Hive Redshi/ に 格納する仕組み 2013年5月22日 株式会社ゆめみ 森下 健 mokemokechicken@twi;er 1 2. 作るきっかけ アプリケーションログをMySQLに保存している (調査目的) MySQLだとスケールしない S3やHadoop(Hive)上に保存しよう (スケールしそう) 2 100〜200Write/sec くらいでキツイ

    Logをs3とredshiftに格納する仕組み
  • Hadoopは基幹業務をどう変えるのか─ソフトバンクモバイルにおけるオープンソース活用 | gihyo.jp

    Hadoopはバッチ処理の課題への解決策となり得るか 企業のあらゆる領域にITが浸透し、それに伴って会計や在庫管理、あるいは販売管理などシステムから出力されるデータ量も拡大し続けています。このデータ量の増大によって、多くの企業において新たな課題となりつつあるのがバッチ処理の遅延です。 たとえば、毎日の売上を集計するために、販売管理システムからデータを吸い上げてバッチ処理を行うといった場合、サーバリソースに余裕がある夜間にバッチを走らせ、翌朝担当者が出社する頃には集計データが出力されているという形が一般的でしょう。しかし、ITが事業のさまざまな領域で活用されるようになったことから、バッチ処理すべきデータ量は増大し続けています。これにより、バッチ処理が時間内に終わらない、「⁠突き抜け」と呼ばれる事態に頭を悩ませる企業が増えているのです。 突き抜けが発生すると、さまざまな領域に大きな影響が及ぶ恐

    Hadoopは基幹業務をどう変えるのか─ソフトバンクモバイルにおけるオープンソース活用 | gihyo.jp
  • 1