リアルタイムに近づくバッチ処理、大容量・高速・安価が身近に
今回取り上げた分散バッチ処理はいずれも、トランザクション処理システムが管理するデータをテキストデータなどとして複製してから処理を行う。データウエアハウス（DWH）よりも、導入コストや開発コストが安価だ 同社は2009年10月、当日の売り上げを店舗別、商品別に分析するために使用していたデータウエアハウス（DWH）ソフトを廃棄した。売り上げ分析をやめたわけではない。DWHを、「テキストファイルを使ったバッチ処理」に置き換えたのだ。 現在同社は、POSレジから集めた売り上げデータをテキストとして保存し、1時間ごとにバッチ処理を行って、店舗別、商品別の売上高を集計する。非常に古典的なバッチ処理に見えるが、処理時間は大幅に短縮した。 同社は全国に70店舗を展開し、合計3万アイテムの商品を扱う。その3万アイテムすべてに対して、売り上げ個数や粗利益、値引き消化率（値引きをして売れた商品の比率）、廃棄率、
Hadoopは汎用機の夢を見るか？ - 急がば回れ、選ぶなら近道
オープン系の歴史は、基本的に汎用機との戦いでした。個人的にも自分の戦いも、わりとまじめに汎用機との戦いでした。Linux? おもちゃですね。Java? 飲めるの？Object指向? 品質高いの? ・・・まぁこんな感じでしたね。確かにLinuxはもはや標準になりました。Javaでの開発は普通になりました。Object指向以外の開発はまぁ普通にないですね。・・・しかし、残念ながら基幹バッチは未だに汎用機です。汎用機は未だに現役であり、基幹処理の根っこは、いまだ汎用機で動いています。信頼性は突出しているし、パフォーマンスもバッチ処理に関しては依然として最強だと言えるでしょう。新人COBOLな人のバッチが、ハイパーなOracle使いのSQLバッチを軽く凌駕する事は、まだ普通にあります。・・・なぜか？ 多重度が違いすぎますね。 汎用機はハードウェアからOSレベルまですべて、多重度が上がる事を前提に処
Asakusaでの設計・実装の方法についてのドキュメント - 急がば回れ、選ぶなら近道
Asakusaのドキュメントを大幅に見直し+追加しました。自分の担当は設計関連の部分だったので、その辺の“あとがき”的なものを以下。自分で書いて気になったところもまとめて置く感じで。 http://www.asakusafw.com/techinfo/methodology.html 1.設計手法について 理論的な背景はともかく、業務バッチ処理をどのように設計するか、ということについての一つの「やり方」を書きました。これは完全に経験則と過去の方法論の掘り起こしによるものです。基幹バッチ処理をデータフローで、ゼロから設計するという手法は、周りを見るところ、ほぼ完全なロスト・テクノロジーになってしまっていて、ちょっと見当たらないです。（調査が足りないという話もありますが） データフローベースの、（有り体にいうとCOBOLライクな環境での）バッチの作成は、現状では、メンテナンスで既存に手をいれる
インサイド MapR (1) （Hadoop アドベントカレンダー 2011 16日目） - nagix
この記事は Hadoop アドベントカレンダー 2011 の16日目の記事です。 今年の5月にMapR Technologies社から発表された、独自実装のHadoopディストリビューション（以降、単純にMapRと呼びます）ですが、そのユニークな特徴やオープンソース実装のはるか先をいく先進性から、いろいろなところで注目を集めています。ただ、非常に多彩な機能を持ちながら、これどうやって実現しているの、という風に思っている方も多いと思います。私はお仕事柄MapRの実装を若干詳しく知る立場におりますので、MapRの中身を少し掘り下げてみたいと思います。 MapRはHadoopのどこを改良しているのか MapR TechnologiesはもともとGoogleでGFS、BigTable、MapReduceなどの検索基盤技術を担当していたエンジニア M.C. Srivas 氏などが中心となって3年ほど
hadoop コミュニティ開発メモ - 科学と非科学の迷宮
注: 必要があってこの記事を書いているのであって、決して万人向けに書いているわけではありません。 用意するもの(Mac) JDK6 Eclipse maven git protocolbuffer (protoc) 多分最低この5つのツールがあればなんとかなる。 pb が必要なのは、pb がないと 0.23 以降(正確に言うと yarn)をコンパイルできないため。 事前準備 ASF JIRA にユーザ登録する してください。 apache/hadoop-common を git clone する common, hdfs, mapreduce 全部入り。マスターブランチは master ではなく trunk であることに注意。 朝起きたら git checkout trunk; git fetch; git rebase origin/trunk 。習慣づけよう mvn eclipse:e
来年のHadoop - 急がば回れ、選ぶなら近道
Hadoopアドベント・カレンダーの多分最終日のはず。 せっかくなんで、来年の予想でもしてみようかと。 日本の話です。世界のことはよくわかりません。本当のことは、日本には伝わらない（表向きの話はともかく、現状ではVCあたりの外野の方が発言力があると思うし、向こうでも、その辺の正確な情報は伝播してる気がしません）と思うので。とはいえ、日本のHadoopマーケットは、それなりわかっている（というか、わかっていないとまずい）感じみたいなので・・・勝手に、来年のHadoopとか予想します。外れたら焼き肉おごります。 1 大量データ処理でのデファクト化 ・いわゆるWeb系ではつかっていないところは一社もなくなる 特にレコメンデーションエンジンあたりは、もう普通に実装して使う。ただし、それ以上のものは出ない。集計処理と推論をうまく利用したレコメンデーションエンジン（とその亜流）、従来からのフィルタリン
"BigData"では何が問題なのか？ - 急がば回れ、選ぶなら近道
”ビッグデータで奇跡が起こる” はいどうも。まず、個人的には楽天的な進歩史観には、まったく組しない。 従って、突然に新技術ができて、なんか凄い事になる、というのはさらにまったく同意しない。すべからくブレイクスルーは課題解決により起こると思っているので、問題意識のないところに、こんなものできました的な発想は、基本的にプラスにならないことが多いと思っている。現状のビッグデータブームは2011年の秋口現在は完全にハイプになっており、バブルと言ってもいいと思う。印象として、十数年前のナノテク・ブームに似ている。 とはいえ、過度の期待という側面を除けば、それなり効果もある部分もあり、”そこだけ”を見ていけばそれなりに効果はある（と思う）。大体において、今後は以下の二つのユースケース・カテゴリーに集約されると思う。すなわち、ビッグデータの拠り所はまずもって以下の２点だ。 1 Webのログ解析 というか
Hadoop＆Asakusaを基幹業務で使い倒す--ノーチラス 神林飛志氏
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 日立ソリューションズは12月2日、東京・品川にて「Hadoopが導く分散処理における次世代のバッチ処理開発とは〜Asakusa FrameworkによるHadoopエンタープライズ適用セミナー〜」を開催した。 本稿ではその中から、ノーチラス・テクノロジーズ代表取締役副社長 神林飛志氏による講演「Hadoopによるバッチ処理の導入」を紹介する。 Hadoopを定義するのにビッグデータという言葉は必要ありません——神林氏は冒頭、こう切り出した。 いまやバズワードとして定着し始めている「ビッグデータ」だが、その言葉が語られるときはサブセットのごとく「並列分散処理システム」としてHadoopも引き合いに出されることが多い。だが神林氏は「ビッグデ
zusaar.com - このウェブサイトは販売用です！ - zusaar リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
AWSと国内DCサービス - 急がば回れ、選ぶなら近道
自分的な話題なので書いておきたい。 まず立場的はっきりさせて置く。AWSを基本的にはエンタープライズ・ユースで考えています。もっと直裁にいえば、Asakusaの実行基盤として、すなわちEnterpise Hadoopの実行基盤として見ています。クラウドの利用は単社ではできないことをできるのが特長であり、それは現時点では分散処理です。多数のノードを利用する分散処理は、単社で持つにはコスト的にペイしません。ので、一種のハードの共同利用としてクラウドを利用すべきです。単純にレンタル・サーバーの延長上で見るのであれば、クラウドのメリットはないでしょう。分散処理を一定の計算資源を利用して行うことがクラウドでできるかどうかがポイントと考えています。AWSは十二分にこの目的には合致しています。特にパブリックではないVPCの存在は非常に大きい。 （分散処理としてHadoopMapReduceが最適か？とい
Hadoopはルイーダの酒場 - wyukawa's diary
昨日の深夜に某氏講師による「JavaエンジニアのためのHadoop入門」 の話題がネタになってましたが、僕はJavaエンジニアとしてキャリアを積んできてHadoopに入門しました。キリ HadoopはJavaで書かれているのでJavaエンジニアのキャリアのひとつとしていいと思いますけどね。 当初はHiveでデータ処理をしていましたがうまくHiveQLが書けず、DBエンジニアからHadooperになった人にSQLやデータモデルについて教えてもらったりしてました。 最近はインフラまわりをやるようになって、HeartBeatわかんねーーーーってなって、インフラエンジニアからHadooperになった人にいろいろ教えてもらったりしてました。 かようにHadoopを使う場合はいろいろなスキルが求められます。 まずインフラ構築、運用ならざっと下記のような作業が必要になるでしょう。 ハードウェア選定 ハー
アトムとビット〜Hadoopでバッチが速くなって何がうれしいか？ - 急がば回れ、選ぶなら近道
まず、社内のオープニングで説明した内容だったりするのですが、一回まとめておきたいので。 断っておくとこの言い方はニコラス・ネグロポンティから取っています。彼の主張は明確でいままでアトム（物質）的な存在だったものが、ビット（電子情報）的な存在に凌駕される、いや大きく姿を変えてるという指摘でございますね。Being digitalが出版されたのが95年なので、もう15年以上になるわけですね。ま、ざっくりすぎてアレですが。・・ワーディングとして便利なので利用させてもらいます。 まず、主題は何かというと、「バッチが速くなって何がうれしいのか？」という問題の背景をちゃんと説明しておきたい。もともとHadoopで何がしたかったのかというと、そもそもバッチのスピードを上げたかった。そもそもRDBMSではまぁ限界があったというのが事の起こり。んで分散処理を行うとIOが分散されるので、スピードがあがりますね
Mapreduce2.0 - 急がば回れ、選ぶなら近道
次世代Hadoopの開発が進んでいる。現状の推移では、少なくとも分散クラウドでの「OSSインフラ」としてはHadoopが最有力候補であることは間違いない。クラウド上での分散処理基盤での技術競争ではGoogleやAmazonが相当抜きんでいる現在、それに対抗しうる可能性があるOSSはHadoopの潮流の延長線上にしか考えられない。その形としてHadoop-MapReduce2.0があるように見える。現在の状態で自分なりの次世代Hadoopの理解をまとめておく。基本的に全部は見切れていないので、そのあたりはあしからず。基本的に次世代Hadoopの仕組みは大きく二つの要素からなる 現在のところの柱はHDFSとMapreduce2.0の二つだ。 まずMapReduce。これは従来の「MapReduce」というものからはほど遠い。むしろ「任意」の分散処理実行フレームワークにたいして、適切なリソースを
FacebookがHBaseを大規模リアルタイム処理に利用している理由（後編）
Facebookは大規模なデータ処理の基盤としてHBaseを利用しています。なぜFacebookはHBaseを用いているのか、どのように利用しているのでしょうか？ 7月1日に都内で行われた勉強会で、Facebookのソフトウェアエンジニアであるジョナサン・グレイ（Jonathan Gray）氏による解説が行われました。 この記事は、「FacebookがHBaseを大規模リアルタイム処理に利用している理由（前編）」の続きです。 事例1 Titan（Facebookメッセージ） HBaseがFacebookでどのようなアプリケ－ションで使われているのかを紹介しよう。 Facebookの新メッセージ機能。
FacebookがHBaseを大規模リアルタイム処理に利用している理由（前編）
Facebookは大規模なデータ処理の基盤としてHBaseを利用しています。なぜFacebookはHBaseを用いているのか、どのように利用しているのでしょうか？ 7月1日に都内で行われた勉強会で、Facebookのソフトウェアエンジニアであるジョナサン・グレイ（Jonathan Gray）氏による解説が行われました。 解説はほぼスライドの内容そのままでした。当日使われた日本語訳されたスライドが公開されているので、ポイントとなるページを紹介しましょう。 Realtime Apache Hadoop at Facebook なぜリアルタイムデータの分析に、Hadoop/HBaseを使うのか？ MySQLは安定しているが、分散システムとして設計されておらず、サイズにも上限がある。一方、Hadoopはスケーラブルだがプログラミングが難しく、ランダムな書き込みや読み込みに向いていない。 Faceb
第2回Asakusaソースコードリーディングに参加してきました - AOEの日記
AsakusaSCR第弐回に参加してきましたので、そのメモをまとめました。ほとんど自分向けの内容ですが折角なので表に置いておくにします。立て続けに勉強会参加レポートのエントリになっちゃいました。 今回はAsakusaにおいて外部とのデータのやり取りを引き受けているThunderGateのお話でした。 講師はThunderGateのアーキテクチャを設計したウルシステムズの埋金さんです。UMLaut/J-XMLの開発も担当されたそうで、昔はテレメータの開発をされてたとか。あと懇親会で聞いたのですが、かつてはWebLogicの鬼だったそうな。 なぜThunderGateを作ったのか？ Hadoopはデータ配るところが弱いので、そこを補うのがThunderGate データをどこに置く？ HDFS 信頼性？SPOFあるね バックアップリカバリのノウハウがない (復旧できる技術者いる？少なくともデータ
いまさら聞けないHadoopとテキストマイニング入門
ビッグデータ時代の救世主「Hadoop」とは 「Apache Hadoop」は今、最も注目を集めている技術の1つです。Hadoopとは、大量のデータを手軽に複数のマシンに分散して処理できるオープンソースのプラットフォームです。 Hadoopを活用している企業は年々増え続けていて、不可欠な技術になりつつあるといえるでしょう。 本連載では、Hadoopとは何か、Hadoopがどう活用できるのかということを、「テキストマイニング」に焦点を当てて解説していきたいと思います。 重い処理を複数のマシンに分散させる 複数のマシンに処理を分散させるには、プロセス同士の通信、監視、障害時の対応などを考えなければならず、プログラマにとってハードルが高いものです。しかし、Hadoopはそういった面倒くさい処理を一手に引き受けてくれ、プログラマは、やりたい処理だけに集中できます。 例えば、Hadoopを使うと、1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【Cloud Days基調講演】“AmazonはAWSのクラウドを使っているの？”という疑問に答えます
株式会社ノーチラス・テクノロジーズ
Asakusa Framework — Asakusa Framework v0.2.6-r1 documentation