Hadoop不可变与数据类型可变

我是大数据领域的新手，正在努力学习Hadoop。让我吃惊的是，大数据或Hadoop在默认情况下支持不变性，因为我们希望一次写入数据，多次读取数据，不变性是分布式存储和处理领域的最佳选择。同时，我了解到Hadoop中实现可写接口的所有数据类型本质上都是可变的，以支持框架中的序列化。我在这里感到困惑，当所有数据类型都是可变的，那么整个Hadoop中如何支持不变性呢？这两件事不矛盾吗

---

提前感谢您回答我的问题。

我认为您可能混淆了HDF，即存储的文件，这些文件通常只写入一次，不支持使用内存对象（可写对象）进行任意覆盖。这些文件可以编辑，因为它们并没有提交到磁盘上，而且为每个操作创建一个新的可写文件的成本会很高（想想GC成本）

使用Hadoop，所有写入的记录都是不可变的，因为Hadoop不支持随机写入。有时这真的是一种痛苦，但它能很好地适应。您甚至会发现，越来越多的语言重新提出了不可变对象的概念。为什么？因为可变对象存在几个问题。首先，可变对象必须处理并发性。这本身就需要额外的编程，以确保对象一次只能由单个源更新。在更新已写入磁盘的可变对象时，需要重写更改下面的整个文件。这可能代价高昂。 参考号-

原因是序列化机制。让我们看看代码：

//版本1.x MapRunner#run（） K1 key=input.createKey（）； V1值=input.createValue（）

。。。 因此，我们再次重复使用同一个键/值对实例。为什么？我不知道当时的设计决策，但我认为这是为了减少垃圾对象的数量。请注意，Hadoop非常古老，当时的垃圾收集器没有今天的效率高，但是即使在今天，如果您映射数十亿个对象并直接将它们作为垃圾扔掉，在运行时也会有很大的不同

不能使可写类型真正不可变的真正原因是不能将字段声明为final。让我们用IntWritable创建一个简单的示例：

public class IntWritable implements WritableComparable {
  private int value;

  public IntWritable() {}

  public IntWritable(int value) { set(value); }

。。。 如果要使其不可变，它肯定不会再与序列化过程一起工作，因为需要定义final值。这无法工作，因为键和值是在运行时通过反射实例化的。这需要一个默认构造函数，因此InputFormat无法猜测填充最终数据字段所需的参数。因此，重用实例的整个概念显然与不变性的概念相矛盾

但是，您应该问问自己，不可变键/值在Map/Reduce中应该有什么好处。在Joshua Bloch的高效Java第15项中，他指出不可变类更易于设计、实现和使用。他是对的，因为Hadoop的reducer是最糟糕的易变性示例：

void reduce(IntWritable key, Iterable<Text> values, Context context) ...

void reduce（可写键、可写值、上下文）。。。

iterable中的每个值都引用同一个共享对象。因此，如果许多人将自己的值缓冲到一个正常的集合中，并问自己为什么它总是保留相同的值，那么他们就会感到困惑

最后，它归结为性能（cpu和内存——想象一下一个键的数十亿个值对象必须驻留在RAM中）与简单性之间的权衡

参考号-

while (input.next(key, value)) {
   // map pair to output
   mapper.map(key, value, output, reporter);

public class IntWritable implements WritableComparable {
  private int value;

  public IntWritable() {}

  public IntWritable(int value) { set(value); }

void reduce(IntWritable key, Iterable<Text> values, Context context) ...