hadoop2.5中hdfs写入中文乱码问题？

bg4.png

你的哪个是二进制转换，从string转换下private

static

final

String

utf8

=

"UTF-8"

//

将UTF-8转换成GBK

也困雀可以整体改变下eclipse的环境，参考乱谨Eclipse

乱码

解决方案汇总汪陪早（UTF8

--

GBK）

上半句话，访问文件不外乎读和写，需要读写时调用函数FileSystem&open()和FileSystem&create()，返回的对象是FSDataInputStream和FSDataOutputStream。 data直译成中文就是数清前绝据，stream直译成中文就是流。 这两个对象分别继承于java.io.DataInputStream和java.io.DataOutputStream， 是java的常用的文件读写类。 需要读时用DataInputStream的函数readInt(), readFloat()...，悔慧写时也差不多。

下半句话，两个关键词， ”单个客户“和”追加“。单个客户指不能有两个线程同时写；追加指写的形式只能是在文件后加内容(append)，不能覆盖(overwrite)。 这两个限制都是设计上简化考虑。 多个线程同时append时，由于hdfs是一份文件存于多个答姿机器，保证在每台机器上两个线程写的顺序一致(从而结果一致)是一个很难的问题（当然不是做不到）， 出于简单考虑， 就不这么做了。 多个线程同时overwrite就更麻烦。

,就当是抛砖引玉了。

相信楼主知道,hadoop的文件系统叫做hdfs,就是hadoop分布式分布式文件系统的中文简写。这个系统是对google的gfs的开源实现。下面来回答问题。

首先是节点故障:

google在他们那篇gfs的论文中说,google在使用gfs曾说过,google在使用gfs时遇到过各种各样的问题,主要有:应用程序bug、 *** 作系统的bug、人为失误,甚至还有硬盘、内存、连接器、网络以及电源失效。在一个大型的系统中,硬盘内存等等组件的老化,过度使用(因为数据读写非常频繁)等问题也是不容忽视的。hadoop的hdfs是需要考虑这些问题的。

然后是备份恢复的处理:

备份恢复因为我没尘闷有做过,不过我可以提供给楼主一个方法实验。

楼主可以先搭建一个只有3台datanode的小集群,设置数据备份为2。首先清空已有数据,然后在其中一台datanode上上传数据,默认时,hadoop是会在上传数据的datanode存入一个数据备份的。然后在down掉这台datanode,这样,你就少了一个数据备份,之后,你在另一台机器上读取数据,这时,你可以查看剩下的两台datanode中的dfs文件夹(也就是你存储hdfs数据的文件夹),打开其中block开头的文件看,这时应该就可以看到两台机器都有备份了。(推测)

根据gfs的论文,hadoop应该在数据被再次使用时进行检查,如果发现少了一个备份,会进行数据恢复工作。另一个时间是,机器空闲时会在后台监测数据备份情况。也就是说,数运袭据恢复是自动,这也是hadoop的强大之处嘛。

至于namenode的恢复,没有旁兄兄处理过类似的问题,不过猜想和secondary

namenode

有关,应该是将secondary

namenode

存储的数据copy到namenode上,或是直接将secondary

namenode

变成namenode

。

至于节点问题,down的节点经过恢复后,可以直接链接进入hadoop集群,而不用重新启动集群。命令是

bin/hadoop-daemon.sh

start

datanode

---