-
- いいね！0
草薙 昭彦
@nagix
MapRはOSファイルシステムではなくブロックデバイスに直接アクセスすることでオーバーヘッドを削減している。ディスクはデフォルトで3本を1単位としてストレージプールを構成し、その中でソフトウェアRAID-0的にストライプしている。このためディスクは3本単位で構成するのがおすすめ
2012-03-24 01:11:53
草薙 昭彦
@nagix
MapRのボリューム機能は、ファイルシステムを論理的に分割して異なる運用管理ポリシーを適用できるしくみ。ボリュームごとにスナップショットや容量上限、レプリケーション数等を指定可能。よく誤解があるがあくまで論理的な管理単位なので下回りのサーバノードやディスクはボリューム間で共用する
2012-03-26 23:48:46
草薙 昭彦
@nagix
MapRではラックやネットワークスイッチなどの物理配置に基づいてサーバノードを「トポロジ」というツリー構造に設定しておくことで、データブロックのレプリケーションの配置最適化に利用できる。トポロジは明示的に設定もできるがネットワーク構造やサービス構成からある程度自動的に設定される
2012-03-27 08:42:15
草薙 昭彦
@nagix
MapRのボリュームを特定のトポロジにマッピングすることで、ボリュームのデータはそのトポロジに所属するノード群のみに分散配置される。アプリ／ユーザごとにボリュームを分けて物理的にIOアクセスを分離したいときに便利。そのデータを入力とするタスクの実行に使うCPUリソースも分離できる
2012-03-28 10:32:35
草薙 昭彦
@nagix
OSS実装ではNameNodeのファイル生成処理性能の限界からMapの出力やspillしたデータをローカルファイルシステムに格納する設計が選択されたが、MapRでは分散NameNodeによりメタ情報管理の性能が格段にスケールするためこれらをHadoopのファイルシステム上に置く
2012-03-28 10:52:25
草薙 昭彦
@nagix
Map出力先は当然ローカルディスク上であるほうが性能が出るので、MapRではMap出力用のボリュームを各ノード毎に用意し、レプリカ数を1として、それぞれの単一ノードを指すトポロジにマッピングする。これでHadoopファイルシステムでありながらローカルディスクを使うということを実現
2012-03-29 09:50:38
草薙 昭彦
@nagix
HadoopのようなシーケンシャルI/Oが多いシステムではLinuxのファイルシステムキャッシュの悪影響が顕著になる。書込みはライトバックなのであとでまとめてディスクに書き出されるが、一気に書き込み要求が来るのでdirty_ratioを超えた時にI/O待ちになる現象が発生しがち
2012-03-29 12:21:10
草薙 昭彦
@nagix
このLinuxの遅延書込の悪影響は昨年のHadoop WorldでもToddが指摘していて http://t.co/6f5NGzkq dirtyページの即時書込などの改良が0.24あたりに入るらしい(HADOOP-7714)。これがMapRがブロックデバイスを直接使う理由でもある
2012-03-29 12:28:33
Tatsuo Kawasαki
@kernel023
カーネルのI/O周りはファイルシステムやI/Oスケジューラの選択やチューニングを行うこともできますが、あまり頑張ってる事例は見ないですね。 RT @nagix: HadoopのようなシーケンシャルI/Oが多いシステムではLinuxのファイルシステムキャッシュの悪影響が顕著になる。
2012-03-29 17:07:22
草薙 昭彦
@nagix
@kernel023 そうですね、Linuxディストリビューションのデフォルト設定はHadoopにはあまりフィットしませんが、チューニングの定石みたいなものはそれほど認知されてないですね
2012-03-29 18:49:00
Tatsuo Kawasαki
@kernel023
@nagix 仰る通りですね。さらにWindowsネイティブで動くようになったら挙動の違いなどが出てきそうですね。
2012-03-29 19:05:33
wyukawa
@wyukawa
めも＞Hadoop World 2011: Hadoop and Performance - Todd Lipcon & Yanpei Ch... http://t.co/bRZW8FI6
2012-03-29 19:33:24
wyukawa
@wyukawa
ネイティブコード入るのか＞[#HADOOP-7714] Umbrella for usage of native calls to manage OS cache and readahead - ASF JIRA http://t.co/fr1F0EQN
2012-03-29 19:33:47
草薙 昭彦
@nagix
PentahoとMapRを組み合わせて使いたいときはこちらから。ちゃんとドキュメント作ってるのね http://t.co/V48UlqFO
2012-04-02 09:45:01
草薙 昭彦
@nagix
MapRのファイルシステムではデフォルトで内部で圧縮がかかる。圧縮アルゴリズムはLZFの一種で圧縮率より速度を優先。アプリケーションコードで圧縮の心配をしなくて済むのでお気軽。hadoop fs -put/-getやshuffle、ミラーの同期で流れるデータにも圧縮が効く
2012-04-06 10:14:01
草薙 昭彦
@nagix
ただし既に圧縮されているファイルには効果が薄いばかりか性能劣化もあるので特定の拡張子のついたファイルは非圧縮にする設定もある。圧縮の有無はディレクトリ毎に設定可能。あとmapred.compress.map.outputの圧縮設定とも機能がかぶるのでどちらかをオフにしたほうがよい
2012-04-06 10:20:51
wyukawa
@wyukawa
HadoopからMapRへのデータ移行って注意したほうがいいポイントってどんぐらいあるんだろ。圧縮がそのひとつではあるか。＞ https://t.co/Y4BJNOQw
2012-04-06 13:42:49
草薙 昭彦
@nagix
@wyukawa その他では、デフォルトブロックサイズがディレクトリ毎に設定できるのでそこで最適化を考えるとか、レプリケーション数はファイル単位ではなくボリューム単位でしか変えられないのでボリューム構成・ファイルの配置を合わせて考える、くらいでしょうか。そんなに多くないと思います
2012-04-06 20:10:03
草薙 昭彦
@nagix
HDFSは障害に強いと言われるが、オペミスやプログラムのバグによるデータ喪失には対応できない。かといって大量のデータを外部にバックアップするのもコスト的に非現実。MapRはHDFSを置き換えたMapR FSファイルシステムにスナップショット機能を組込み、こうしたニーズに応える
2012-04-10 09:20:24
草薙 昭彦
@nagix
さらに、サイト全体が停止してしまう障害にはスナップショットからの復旧も望めないので、遠隔サイトに別のMapRクラスタを作ってミラーリングを行い、バックアップとすることも可能。転送は差分のみで圧縮も効いているので効率的に同期をとることができる
2012-04-10 09:24:39
草薙 昭彦
@nagix
HadoopをMapRで構築するとコスト面でも有利である。独立したNameNode用のサーバやセカンダリNameNodeは不要だし、わざわざDRDBやHeartbeatでHA化する必要もないし、性能向上分のノード台数を減らせるし、データの退避・復旧にはスナップショットが使えるし。
2012-05-09 09:09:48
草薙 昭彦
@nagix
NameNodeやその冗長化のためのマシンとかデータの出し入れのための一時的な外部ストレージ領域が不要になるっていうのは、特に数台程度の比較的小さなHadoop環境の場合にコスト削減効果が大きい。
2012-05-09 09:18:27
草薙 昭彦
@nagix
HadoopとSolrを連携させるときに、NFSアクセス機能があればこんなに処理フローがシンプルになりますよ : The Search Is Over: Integrating Solr and Had... http://t.co/AlJfe03Y
2012-05-15 14:49:58