Hadoop中的超大键值对

我是Hadoop的新手，目前程序的复杂性仅限于字数的复杂性。我试图理解Hadoop的基本架构，以便更好地构建我的解决方案

---

我的一个大问题是Hadoop如何处理块边界上的大键值对？假设我有一个大小为10MB的键值对（例如，如果该值是一个完整的10MB文件），并假设我使用一个序列文件。Hadoop如何在其块边界处处理这个问题？它是否将拆分为两部分并将其保存在两个不同的块中，或者它是否意识到键值对非常大，因此，它不是拆分，而是为整个键值对创建一个新块

HDFS中的默认块大小为64 MB。如果一个键/值对是10 MB，那么它可能会/可能不会在块之间分割

• 如果第一对KV为60 MB，第二对为10 MB。然后，第二个KV对在第一个块中只剩下4 MB的空间（当块大小为64MB时）。因此，4MB的第二个KV存储在第一个块中，其余6MB存储在第二个块中

• 如果第一对KV为40 MB，第二对为10 MB。然后，第二个KV对在第一个块中剩余24 MB空间（当块大小为64MB时）。因此，第2千伏电压完全存储在第1块中，而不是分开

使用SequenceFile时，映射程序不知道记录的起始位置在块中，因此Hadoop框架会自动将同步添加到SequenceFile中。根据

同步点是流中的一个点，当读卡器“丢失”时（例如，在查找到流中的任意位置后），可以使用该点与记录边界重新同步。同步点由SequenceFile.Writer记录，它每隔几条记录插入一个特殊条目，将同步点标记为正在写入的序列文件。这样的条目很小，只会产生不到1%的适度存储开销。同步点始终与记录边界对齐

当地图任务开始处理块时，它将从第一个同步点开始处理记录。当它到达块的末尾时，它将寻找下一块的第一个同步点，数据通过网络传输到该点，以供映射器处理

---

总而言之，Hadoop框架是记录感知的，即使记录是跨块分割的。

好问题！我认为它在值的中间拆分，然后在运行时重构它（也就是说，它忽略了键/值边界）…但我不太确定能否提供一个正式的答案。谢谢你提供的信息。这回答了我的问题，但我想这也意味着当大的键值对被拆分时，在节点之间传输大量数据会有相当大的开销。（在您的示例中，需要6MB或4MB的传输）。因此，拥有大的键值对可能没有意义。我说的对吗？如果有一个较大的kv对，那么HDFS块大小可以从默认值64 MB增加。