タグ

ITproとHadoopに関するtartvfのブックマーク (8)

  • 分析技術編:Hadoopへの期待と課題

    >>前回 この連載では、ビッグデータの収集から格納までのシステムデザインについて概観してきた。最終回は締めくくりとして、分析技術の課題と今後の方向性を考えてみる。 ビッグデータにおける分析技術の課題 分析技術の課題を考えるために、前回取り上げたECサイトの消費者行動ログデータの分析を想定してみる。図1は、割引率と売上額の相関だけでなく、購入時に表示されていた口コミ情報がどの程度の影響を与えるかを分析する例を示したものだ。この例では、口コミ評価が高いと、割引率に関係なく売上額が高いことを示している(右グラフの円の大きさは売上額の大きさを示す)。 このような分析を行う場合、1回のデータベース検索だけでは結果を出せないため、次のような複数の処理ステップが必要となる。 (1)1画面に含まれる複数の口コミ評価から、価格に関する評価を除外し、総合評価指数を算出する。 (2)会員向け割引を加算するなど割

    分析技術編:Hadoopへの期待と課題
  • Hadoopの真価が問われる1年がスタート

    2011年にIT分野で注目度が高かった話題の1つが分散バッチ処理基盤「Hadoop」活用機運の高まりだ。海外でビジネス利用の事例が増えてきており、国内でも一部の先進企業で導入検討が進められている。2012年はますますビジネスへの貢献を念頭においた発表が盛んになるだろう。 なぜこれほどに注目されるのか? 大きくは、Hadoopは「ビッグデータ」の実現手段の1つとして注目を浴びている。企業や消費者、あるいは各種機器がネットワークでやり取りする情報の増加を背景に、今後も大量の活動履歴などが蓄積されていく。それらを有効活用すれば、「異変を察知する」「近未来を予測する」といった分野で、人間の脳を超える正確さとスピードで意思決定できるロジックを開発できる可能性がある。 ・「ビッグデータ」が注目される理由 ・ビッグデータを迎え撃て…超高速化する「バッチ処理」 Hadoopが開く可能性 Hadoopの具体

    Hadoopの真価が問われる1年がスタート
  • ビッグデータを迎え撃て…超高速化する「バッチ処理」

    連載では、情報システムの次代を担うITの7大トレンドを順次紹介していく。今回は、分散処理の徹底によって超高速化を狙う最新の「バッチ処理」技術を見ていこう。 【分散バッチ処理】 Hadoop型の分散処理で、バッチを超高速化 銀行の勘定系システムなどに採用され、古くからよく知られるバッチ処理は、今や、情報システムの最先端分野だ。多くのコンピュータメーカーが提供していた独自仕様のメインフレームから現在主流のパソコンサーバーに至るまで綿々と続くバッチ処理をオープンソース・ソフトウエアに委ね、しかも分散処理を徹底することが大きなトレンドになりつつある。 西鉄ストアは、オープンソースの分散バッチ処理ソフト「Hadoop(ハドゥープ)」を使った基幹業務システムを2011年9月末に稼働させる。店舗から集まるPOS(販売時点情報管理)データの集計・分析から会計までを担うシステムで、「4~5時間を要していた

    ビッグデータを迎え撃て…超高速化する「バッチ処理」
  • 「ビッグデータ」が注目される理由

    IT業界に新しい流行語がやってきた。「ビッグデータ」である。巨大なデータを、高度なデータマイニング手法によって深く分析し、その結果を活用する。そうすることで、専門家でさえ気づかない事象の変化への対応や、人を介さない意思決定が実現可能になる。ネット企業でなければ難しかったビッグデータの活用は、最近になって一般企業にも可能になってきた。そのためビッグデータの注目度が、一気に上がっている。 ビッグデータの活用は、米グーグルや米フェイスブックといったネット企業にとっては、企業競争力の源泉である。例えばグーグルは2010年6月の学会「ACM Symposium on Cloud Computing(SOCC)2010」で、同社が自社開発した分散バッチ処理基盤「MapReduce」を使って、月間94万6460テラバイト(2010年5月時点)というデータを処理していることを明らかにした。グーグルは毎月、

    「ビッグデータ」が注目される理由
  • [後編]買収される可能性はないかって? 独立性にこそ価値がある

    [後編]買収される可能性はないかって? 独立性にこそ価値がある 米レッドハット 社長兼CEO(最高経営責任者) ジム・ホワイトハースト 氏 最初にパラダイムシフトの話をしましたが、今はまだ初期の段階です。今後いろいろな動きがあると思います。その変化に対応する余地を残しておく意味でも、ベンダーロックインを避けることのできる柔軟なアーキテクチャーが必要です。そして現段階で、そうしたアプローチのソリューションを提供できるのはレッドハットだけだと自負しています。 最近Hadoopなどクラウド生まれの新しいオープンソースソフトが続々と登場していますが、レッドハットとしては、どのように関与していくのですか。 そうしたWeb2.0関連の企業などが生み出すテクノロジーの新た潮流に対しては、緊密に連携していくという方向で当然考えています。例えばクラウド関連の新たなインフラには、Hadoopベースのものがたく

    [後編]買収される可能性はないかって? 独立性にこそ価値がある
  • 100万件では専用ツールが最速

    実際に構築するHadoopのシステムでは(a)インポートや(d)エクスポートのように、扱うデータ量に依存し、Hadoopのノード数を増やしても性能が向上しない処理があり、そこがボトルネックになり得る。いかに効率良くRDBMSからデータをインポート/エクスポートするかが非常に重要だ。 ここでは、(a)インポートに焦点を当て、「JDBCドライバを使用して標準SQLでアクセス」「米Clouderaが提供するデータ転送ツールsqoopを使用」「MySQLの独自機能を利用したダンプ」の3通りの方法を試した(図4)。

    100万件では専用ツールが最速
  • 12ノードまでほぼ比例して向上

    スレーブノード数を変化させた場合、100万件のデータの場合はノード数を増加させてもスループットがわずかしか向上しなかったが、1000万件のデータの場合はノード数にほぼ比例してスループットが向上した 12ノードの場合の性能は、処理時間にすると2分5秒である。実際にはこれにインポートなどの処理時間がかかるが、数分で終わるだろう。筆者らが開発に携わったRDBMSの実システムでは、約100万件の仕入データの買掛計上処理に約1時間を要していた。それに比べると100倍近い性能になる。 もちろん、検証環境では「実データより性能が得られやすい分布のデータを使用した」「検証用のプログラムは実システムと比べると処理が簡略化されている」などの違いはあるが、ケタ違いの性能が出たことは確かだ。 また、分散処理システムの中には数ノード程度で性能が頭打ちになるものもあるが、Hadoopは10ノード以上でも性能が向上し、

    12ノードまでほぼ比例して向上
  • 1000万件のバッチを2分で実行

    Hadoop(ハドゥープ)は複数のサーバーでクラスターを構成し、MapReduceという実行環境や、HDFS(Hadoop Distributed File System)という分散ファイルシステムなどによって、効率的な並列分散処理を実現するミドルウエアである。 MapReduceでは、データを整理・抽出するMapタスク、Mapタスクの出力を基にデータを集計するReduceタスクを、クラスターの各ノードで分散処理することで性能を高める。 現状では、Hadoopは主にログ分析やBI(Business Intelligence)に使用され、大量データを分析するための基盤ソフトと理解されることも多いが、それにとどまらず企業の基幹システムを大きく変える可能性を持っている。 Hadoopは分散処理を容易かつ高速に実現するため、割り切った作りになっている。基的に処理中のデータの外部からの更新や複雑な

    1000万件のバッチを2分で実行
  • 1