为什么Hadoop需要像Text或IntWritable这样的类而不是String或Integer？

为什么Hadoop需要引入这些新类？为了以Hadoop方式处理对象，它们似乎使接口复杂化了。例如，hadoop使用

文本

而不是java的

字符串

。hadoop中的

Text

类类似于java

String

，但是，

Text

实现了类似

Comparable

、

writeable

和

writeablecomparable

的接口

---

这些接口都是MapReduce所必需的；

Comparable

接口用于在reducer对键进行排序时进行比较，

Writable

可以将结果写入本地磁盘。它不使用java

Serializable

，因为java

Serializable

对于hadoop来说太大或太重，

writeable

可以非常轻松地序列化hadoop对象

因为在大数据世界中，结构化对象需要序列化为字节流，以便通过网络移动或持久化到集群上的磁盘…然后根据需要再次反序列化。当你拥有像Facebook这样规模的海量数据来存储和移动时，你的数据需要高效，并尽可能少地占用存储空间和移动时间

String

和

Integer

太“胖”。分别是

Text

和

intwriteable

，在表示相同类型信息的字节数组之上提供了一个更简单的抽象。

一些更好的信息：

它们有两个相关的特性

他们有“可写”接口——他们知道如何显式地写入数据输出流和读取数据输入流

它们通过set（）操作更新内容。这使您可以重复使用相同的值，而无需创建新实例。如果重复调用同一个映射器或reducer，效率会高得多：只需在构造函数中创建可写的实例并重用它们

相比之下，Java的可序列化框架“神奇地”序列化了对象——但它的序列化方式有点脆弱，并且通常不可能读入旧版本的类生成的值。Java对象流被设计为发送一个对象图回来——它必须记住已经推出的每个对象引用，并在返回的过程中执行同样的操作。可写内容设计为自包含的

这是来自以下内容：

来自Apache文档：

可写

接口描述为

一种可序列化的对象，它基于

数据输入
和
数据输出
实现一个简单、高效的序列化协议

有了这个新的API，您就不会有复杂的问题了。这些新类的序列化过程是
crisp
和
compact

为了提高Hadoop的效率，应该优化序列化/反序列化过程，因为集群中的节点之间会发生大量的远程调用。因此，序列化格式应该是快速、紧凑、可扩展和可互操作的。由于这个原因，Hadoop框架提出了一个IO类来代替java原始数据类型。e、 g.
intwritebale
用于
int
，
longwriteable
用于
long
，
Text
用于
String
等

您可以在《Hadoop权威指南：第四版》中找到有关此主题的更多详细信息