Hadoop 2.0数据写入操作确认
Hadoop 2.0 data write operation acknowledgement
我有一个关于 hadoop 数据写入的小查询
来自 Apache 文档
For the common case, when the replication factor is three, HDFS’s placement policy is to put one replica on one node in the local rack, another on a node in a different (remote) rack, and the last on a different node in the same remote rack. This policy cuts the inter-rack write traffic which generally improves write performance. The chance of rack failure is far less than that of node failure;
下图中，write acknowledge什么时候被视为成功？
1) 向第一个数据节点写入数据？
2) 将数据写入第一个数据节点+另外2个数据节点？
我问这个问题是因为，我在 youtube 视频中听到了两个相互矛盾的说法。一个视频引用一旦数据写入一个数据节点就成功写入，另一个视频引用只有在将数据写入所有三个节点后才会发送确认。
第 1 步：客户端通过调用 DistributedFileSystem 上的 create() 方法创建文件。
第 2 步：DistributedFileSystem 对名称节点进行 RPC 调用，以在文件系统的命名空间中创建一个新文件，没有与之关联的块。
名称节点执行各种检查以确保该文件不存在并且客户端具有创建该文件的正确权限。如果这些检查通过，名称节点将记录新文件；否则，文件创建失败并且客户端抛出 IOException。 TheDistributedFileSystem returns 一个供客户端开始写入数据的 FSDataOutputStream。
第 3 步： 当客户端写入数据时，DFSOutputStream 将其拆分为数据包，并将其写入内部队列，称为数据队列。数据队列由 DataStreamer 使用，它负责要求名称节点通过选择合适的数据节点列表来分配新块来存储副本。数据节点列表形成一个管道，这里我们假设复制级别为三，所以管道中有三个节点。 DataStreamer 将数据包流式传输到管道中的第一个数据节点，它存储数据包并将其转发到管道中的第二个数据节点。
第4步：类似地，第二个数据节点存储数据包并将其转发到管道中的第三个（也是最后一个）数据节点。
第 5 步： DFSOutputStream 还维护着一个等待数据节点确认的内部数据包队列，称为确认队列。仅当数据包已被管道中的所有数据节点确认后，才会从确认队列中删除该数据包。
第 6 步：当客户端完成写入数据时，它会在流上调用 close()。
第 7 步： 此操作将所有剩余的数据包刷新到数据节点管道并等待确认，然后联系名称节点以发出文件已完成的信号名称节点已经知道哪些块该文件由 组成，因此它只需要等待块被最小化复制就可以成功返回。
一个副本写入成功即为数据写入操作成功。它由 hdfs-default.xml 文件中的 属性 dfs.namenode.replication.min 控制。
如果在写入副本时数据节点出现任何故障，则写入的数据不会被视为不成功，而是复制不足，这在平衡集群时会创建那些丢失的副本。
确认包独立于写入数据节点的数据状态。即使未写入数据包，也会发送确认包。
我有一个关于 hadoop 数据写入的小查询
来自 Apache 文档
For the common case, when the replication factor is three, HDFS’s placement policy is to put one replica on one node in the local rack, another on a node in a different (remote) rack, and the last on a different node in the same remote rack. This policy cuts the inter-rack write traffic which generally improves write performance. The chance of rack failure is far less than that of node failure;
下图中，write acknowledge什么时候被视为成功？
1) 向第一个数据节点写入数据？
2) 将数据写入第一个数据节点+另外2个数据节点？
我问这个问题是因为，我在 youtube 视频中听到了两个相互矛盾的说法。一个视频引用一旦数据写入一个数据节点就成功写入，另一个视频引用只有在将数据写入所有三个节点后才会发送确认。
第 1 步：客户端通过调用 DistributedFileSystem 上的 create() 方法创建文件。
第 2 步：DistributedFileSystem 对名称节点进行 RPC 调用，以在文件系统的命名空间中创建一个新文件，没有与之关联的块。
名称节点执行各种检查以确保该文件不存在并且客户端具有创建该文件的正确权限。如果这些检查通过，名称节点将记录新文件；否则，文件创建失败并且客户端抛出 IOException。 TheDistributedFileSystem returns 一个供客户端开始写入数据的 FSDataOutputStream。
第 3 步： 当客户端写入数据时，DFSOutputStream 将其拆分为数据包，并将其写入内部队列，称为数据队列。数据队列由 DataStreamer 使用，它负责要求名称节点通过选择合适的数据节点列表来分配新块来存储副本。数据节点列表形成一个管道，这里我们假设复制级别为三，所以管道中有三个节点。 DataStreamer 将数据包流式传输到管道中的第一个数据节点，它存储数据包并将其转发到管道中的第二个数据节点。
第4步：类似地，第二个数据节点存储数据包并将其转发到管道中的第三个（也是最后一个）数据节点。
第 5 步： DFSOutputStream 还维护着一个等待数据节点确认的内部数据包队列，称为确认队列。仅当数据包已被管道中的所有数据节点确认后，才会从确认队列中删除该数据包。
第 6 步：当客户端完成写入数据时，它会在流上调用 close()。
第 7 步： 此操作将所有剩余的数据包刷新到数据节点管道并等待确认，然后联系名称节点以发出文件已完成的信号名称节点已经知道哪些块该文件由 组成，因此它只需要等待块被最小化复制就可以成功返回。
一个副本写入成功即为数据写入操作成功。它由 hdfs-default.xml 文件中的 属性 dfs.namenode.replication.min 控制。 如果在写入副本时数据节点出现任何故障，则写入的数据不会被视为不成功，而是复制不足，这在平衡集群时会创建那些丢失的副本。 确认包独立于写入数据节点的数据状态。即使未写入数据包，也会发送确认包。