HDFSのヘテロジニアス対応
HDFSとヘテロジニアスな構成
一般的に、Hadoopは同一構成のサーバを大量に並べる方が、運用が簡単です。非均一な構成は、特に設定ファイルの管理、チューニングが厄介です。 そんな中、HDFS-2832で「Enable support for heterogeneous storages in HDFS」というチケットを見つけました。これは、データノードを「単一のストレージ」として扱うのではなく、データノードを「ストレージのコレクション」として扱うところです。
ストレージのコレクション？
HDFSは、データノードが使用しているストレージの種類、ファイルシステムの種類に関与しません。つまり、/dev/sdaはHDDでext4、/dev/sdbはSSDでxfs、、という構成も可能です。これは良い点もあるのですが、例えば特定のデータはSSDに、それ以外はHDDに、というような書き込みを行うことはできません。 このチケットではHDFSにストレージの種類の情報を持たせる拡張を行い、上記のようなデータの種類によるストレージの選択や、ブロックのレプリケーションも一つはSSDに配置するなど、柔軟な構成が取れることを目指しているようです。 まだ先は長そうですが、SSDが普及してくるに従ってこのようなチケットが増えてきそうですね。
注）本家ブログは http://linux.wwing.netです。はてなブログはバックアップ／待避用のため、内容が古いことがあります。
Hadoopのセキュリティ
Hadoopのセキュリティについての雑記
認証についてはKerberosを使うというのがスタンダードですが、暗号化についても徐々に進んでいます。
ネットワークの暗号化
例えば、ネットワークの暗号化については下記のブログがお勧めです。
http://blog.cloudera.com/blog/2013/03/how-to-set-up-a-hadoop-cluster-with-network-encryption/
ファイルシステムの暗号化
ファイルシステム／ディスクの暗号化は現状対応していないので、LinuxのDevice Mapperを使用したdm-cryptや、eCryptfsの仕組みを利用するしかありません。
ところが先週 Jira に「Hadoop cryptographic file system」というチケット(HDFS-5143)が登録されました。今後どうなるかわかりませんが要注目です。
Sentry
話は逸れますが、Hive/Cloudera Impala用の認可モジュール、SentryもApacheのトッププロジェクトを目指しています。Hadoopがエンタープライズ用途での利用が増えるに従いセキュリティはさらに重要な要件となります。今後の展開が楽しみです。
※本家は linux.wwing.netです
Giraph関係のメモ
Facebookのグラフ処理はApache Giraph
たまたまTwitterでGiraphの記事を見つけたのでメモ。
Facebookがグラフ処理にApache Giraphを使っているという記事
FacebookはGiraphに貢献しているようです。この記事ではGiraph関連の話題が中心ですが、個人的に少々興味深かったのは、CoronaではなくYARNというところ（Hadoopからみて）。GiraphがYARNに対応したからでしょうね
https://issues.apache.org/jira/browse/GIRAPH-13
NSAはAccumuloを使っている？
関連するスレッドで、NSAがグラフ処理にApache Accumuloを使っているというスライドを発見。
http://es.slideshare.net/daniel_bilar/big-graph-analysis-issues-nsa
この手法は、CyberAgentのHornetに近いのかも？（Hornetではグラフ処理にHBaseを使用している）
HBaseを使ったグラフDB、Hornet
http://www.slideshare.net/brfrn169/hbasedbhornet-16105526
余談
いよいよ本家のサーバ(linux.wwing.net)を移行することになりました。うまく移行できると良いんですが、、、だめならこちら(Hatena Blog)が本家になるかもしれません。
HDFSのショートサーキット雑感
HDFSのShort-Circuit Local Readについてのブログ記事を読んで
先週お盆休みに公開されたブログ、「How Improved Short-Circuit Local Reads Bring Better Performance and Security to Hadoop」には興味深い内容が書いてあります。これは必読では？と思ったので、少しまとめてみます。
元々の処理
クライアントがHDFSからデータを読み出す場合、データノードとのネットワーク通信が発生します。これはシンプルですが、カーネル内でTCPソケットを保持しておくなどのオーバヘッドがかかります。（ブログ中の最初の図）
Short-Circuit Local Reads with HDFS-2246
このチケットでの改善は、クライアントとデータノードが同一マシンの場合、直接ローカルファイルシステムからデータを読み込むようにするというものです。（ブログの２番目の図）
この機能は既にCDH3u3以降でサポートされており、パフォーマンスに寄与しています。
しかし、クライアントがローカルファイルシステムから直接データを読み出すと言うことは、パーミッションなどのセキュリティ上問題が生じます。つまり、データノードのデータディレクトリにあるファイルが、クライアントから全て見えてしまうというセキュリティ上の問題でした。結果、全てのユーザーが恩恵に預かれるというものではありませんでした。
HDFS-347: Making Short-Circuit Local Reads Secure
幸いなことにLinuxには「file descriptor passing」という仕組みがあり、この機能を使うことで、安全にShort-Circuit Readを行うことができるようになりました（Windowsでも同様の仕組みがあるようです）
HDFS-347ではディレクトリ名をクライアントに直接返すのではなく、データノードがファイルをオープンし、メタ情報をクライアントに返して、クライアントはそのメタ情報を元にファイルを読み込む、という流れになります。。これにより、必要なファイルだけを安全に読み出させることができます。
（注：Java標準APIから利用できないため、JNIを使用する必要があります）
Caching File Descriptors
HDFSから何度も同じブロックを読み出す場合があります(HBaseなど）。Short-Circuit Local Readではブロックのパスをキャッシュしているので効果があります。ただ、キャッシュされているパス情報から、もう一度ファイルをオープン(reopen)する必要があるため、オーバヘッドがあります。この修正ではファイル記述子をキャッシュ（FileInputStreamCache）することにより、reopen, rereadが不要になるために効果があるようです。
ベンチマークの結果もHDFS-347が良い結果を出しているようですね。さらにHDFS-4697ではreadheadにより、さらにランダムアクセスでのパフォーマンスの効果が期待できますね。
なお、Cloudera ImpalaにはShort-Circuit Readが必須なのでご注意下さい。
Mandatory: Short-Circuit Reads
Enabling short-circuit reads allows Impala to read local data directly from the file system. This removes the need to communicate through the DataNodes, improving performance. This setting also minimizes the number of additional copies of data. Short-circuit reads requireslibhadoop.so(the Hadoop Native Library) to be accessible to both the server and the client.libhadoop.sois not available if you have installed from a tarball. You must install from an.rpm,.deb, or parcel to use short-circuit local reads.
Enterprisezine連載2回目
前回に引き続き、EnterprisezineのDBOnlineに記事が掲載されました！
Cloudera Managerはかなり良くできていますし、無償版でもかなり使えるので、疑心暗鬼な方もだまされたと思って一度使って下さい。きっと止められなくなる、、、はずですw。（ツールなので、嫌だったら使わなければ済みますし。。面倒ですが）
Hadoop運用管理の今―その2 Cloudera Managerを使ってみよう -
