ITproの『DBの未来、どうするHadoop』のタイトルに釣られてみたｗ
（以下長々書いたけど、結局言いたいことは、DBとHadoopは関係無いってことと、タイトルについて何か勘違いしたっぽいということだけだった＾＾；）
僕の意見では、Hadoopはバッチ処理を分散して実行する基盤である。データを溜めるのは副次的な効果に過ぎない。（暴論ｗ）
もちろん、そもそも分散処理を行う必要があるのは処理対象データが大量だからなので、データの溜め方も必須ポイントだし、Hadoopが分散処理する原理も密接に結びついているのだが。
あらかじめ断っておくと、自分は非構造化データとか分析とか機械学習には興味が無い。
自分がHadoopに興味を持ったのは、自分が担当していた“RDBを対象にした夜間バッチ”の実行が遅かった為だ。
テーブルをパーティション化して複数のバッチサーバーからアクセスして並列処理するようにしたけれど、バッチサーバーを増やしてもDBサーバーの負荷が高くなる（ボトルネックになる）だけで、全体の実行時間は改善しない。パーティションもそう簡単には変更できないし。
その点、Hadoopならサーバーを増やせば（データ量の範囲内で）簡単にスケールする。
（ついでに、バッチアプリケーションのリリースを一箇所だけに行えば、後は勝手にやってくれるのも便利だ。自前で分散させようとすると、全サーバーにバッチアプリケーションを配置する必要があるし、スケジュールの定義も個別にしないといけないし、それぞれの処理対象範囲を決める方法も考えないといけない）
ITproの記事中に「日本で使われているHadoopクラスターのほとんどは10ノード以下」とあって、そんなものかもしれないと思うけれども、バッチアプリケーションを分散して実行するという意味では、それでも充分。
それですら、Hadoopが出てくる前（RDBMSしか無かった頃）は面倒だったんだから。
それに、Hadoopでバッチ処理をするという事は、その間はDBを使わないので、DBサーバーの負荷が下がるはず。DBはバッチ以外からも使うので、とても意味がある。
てゆーか、あの記事を解釈すると、今のRDBMSは10台のバッチサーバーから同時にアクセスされても速度が落ちないってことだよなぁ。自分がバッチを担当していた頃にその性能があればなぁ。
個人的にHadoopで目から鱗だったのは、処理（アプリケーション）をデータのある場所に転送して実行するという考え方。
DBサーバーにバッチサーバーから接続して処理を行う方法だと、データが多ければ転送量も増えるが、アプリケーションはそれらに比べれば遥かに小さいので、転送量も少なくて済む。（もちろん、シャッフル処理とかでデータ転送は発生しちゃうけど）
これをRDBMSを使ったシステムに応用しようとすると、DBサーバー上でアプリケーションを実行するという事で、きっと負荷が上がるだけで全然嬉しくないorz
（ネットワークが遅いシステムなら意味があるかもしれないが）
もしかすると、RDBMSのストアドプロシージャなんかはDBサーバー上で分散して処理しているのかもしれないけれども、ストアドプロシージャの言語って、あんまり進化している気がしない（自分でコーディングしたくない＾＾；）。
あと、バッチ処理は細かい条件分岐が多いので、細部では手続き的なコーディング方法の方が書きやすい。
なので、分析（対話型処理）にはSQLは超便利だと思うけど、バッチアプリケーションはSQLだけでは書けない。
もしJavaやScalaで書いたバッチアプリケーションをRDBMSが勝手に分散処理してくれて、サーバーを増やせばスケールするなら、Hadoopも一気に廃れると思う(爆)
今実際にシステムを作るとすると、バックエンドには信頼性の高いRDBかHDFS、フロントには検索性能の良いRDB、中間処理（バッチ処理）にHadoopを使うという形になると思う。
DBMSの人の考え方は「RDBもHDFSも透過的にSQLで扱う」ということになるようだが、自分は逆に「RDBのテーブルもHDFSのファイルも透過的にファイルとして扱う」になってきた。
（これはAsakusa Frameworkで開発しているせいかもしれない＾＾；）
この方法の場合、DBサーバーにデータを置いたままだと処理がスケールしないので、HDFSにデータを転送してくる必要がある。
また、処理結果をRDBに戻す（転送する）必要がある。
なので、HDFSとRDBとのデータ転送を高速に行う仕組みが一番欲しい。以前からずっと待ってるｗ
でもDBMSのベンダーからそれが提供されたという話を聞いた覚えが無いんだよなー。
出来るならとっくにやっているだろうから、きっと原理的に難しいんだろうなー。
あるいは、HDFS上にDBを構築すれば、データの配置されている場所で処理するという仕組みは達成できるなー。
って、それはHBaseやんけｗ
まぁそういう訳で、Hadoopの競合はDBMSではなく、他のバッチフレームワークであると思っている。
バッチ処理基盤として見ると、Hadoop（MRv1）はタスク実行の際のオーバーヘッド（いわゆるHadoop税）が大きいので、ジョブ数の多いバッチで悲しい思いをするorz
なので、オーバヘッドが少ないらしいApache Sparkが目下の個人的興味の的。
Scalaでコーディングできるし(笑)
ただしSparkはファイルシステムを持っていないので、HadoopのHDFSを利用する。
あと、Apache Tezも既存のMapReduce上で動いているアプリケーション（HiveやPigや、もしかするとAsakusa Frameworkも？）の実行を改善できるっぽい雰囲気らしい感じがするので、ちょっと興味が出てきたところ。
こうなってくると、Hadoopの存在意義はYARN（リソース・コンテナー管理）と、HDFS（分散ファイルシステム）。
Hadoopは分散処理の基盤を目指すようなので、目的に合致していると思う。
ところでITproの記事のタイトル『DBの未来、どうするHadoop』だけど。
「DBが進化していくので、それに対抗してHadoopはどうするのか？」って意味だと思ったんだけど、もしかして、「DBの今後の方向として、Hadoopとどう付き合っていくか・Hadoopをどう扱うか・Hadoopをどうするか」という意味だったんだろうか？
（追記：「DBの未来をHadoopがどう変えていくのか」という意味にもとれるなぁ）
前者だと思っていたので、記事の中でHadoopの将来について何も触れてなくて違和感を持ったんだけど、後者の意味なら納得だ＾＾；
ちなみに自分のブログのタイトルは、バッチの未来（Hadoop以外のバッチ処理基盤）に対してHadoopはどうするのかというニュアンスのつもりですよｗ
