如果你没有太多留意的话,可能会认为这两个是一个东西。虽然它们看起来很像,但是确实是两回事。
WebHDFS是HortonWorks开发的,然后捐给了Apache,可见博客:WebHDFS – HTTP REST Access to HDFS。而HttpFS是Clouera开发的,也捐给了Apache,可见博客:HttpFS for CDH3 – The Apache Hadoop FileSystem over HTTP。
先说说两者的相同点:
HDFS提供了Java Native API,客户端应用程序使用它可以高效的访问HDFS。但是如果客户端应用程序位于HDFS集群之外怎么办?你总不能让人家也必须安装个Hadoop库和Java库吧。所以,为了解决这个问题,前赴后续的出现了一批项目,例如:Yahoo的HFTP和HdfsProxy V3,Cloudera的Hoop。但是大浪淘沙,目前胜出的就是这两个了。
它们的终极目标完全一致:就是让身处HDFS集群之外的应用程序,不但不用安装Hadoop和Java库,并且可以通过流行的REST风格的接口去访问HDFS集群,还有HttpFS与WebHDFS的HTTP REST API完全兼容。这样一来,不管是使用C++、Python或其它语言的外部程序,都可以以一种统一的方式访问HDFS,这真是程序员的福音呀......
再来说说两者的不同点:
WebHDFS是HDFS内置的组件,已经运行于NameNode和DataNode中。对HDFS文件的读写,将会重定向到文件所在的DataNode,并且会完全利用HDFS的带宽。HttpFS是独立于HDFS的一个服务。对HDFS文件的读写,将会通过它进行中转,它能限制带宽占用。
看起来,HttpFS有些类似于Thrift呀......这样看来,如果访问大文件时,HttpFS服务本身有可能变成瓶颈。当然,如果你想限制客户端流量,以防其过度占用集群的带宽时,那就要考虑HttpFS了。
看看两者的基本使用吧:
#curl -i -L "http://NameNode_host:50070/webhdfs/v1/foo/bar?op=OPEN"
HTTP/1.1 307 TEMPORARY_REDIRECT
......
Location: http://DataNode_host:50075/webhdfs/v1/user/test.txt?op=OPEN&namenoderpcaddress=NameNode_host:8020&offset=0
......
#curl -i -L "http://HttpFS_host:14000/webhdfs/v1/foo/bar?op=OPEN"
WebHDFS默认端口是50070和50075,HttpFS默认端口14000.可以看到,WebHDFS访问时,首先访问NameNode获知文件所在的DataNode地址,然后重定向到目标DataNode获取文件内容。