|
Measures reported by HdpBlockStatTest
Files in Hadoop's file system are broken into block-sized chunks called data blocks. Hadoop stores each file as a sequence of blocks. The blocks of a file are replicated across Data Nodes for fault tolerance.
The NameNode makes all decisions regarding replication of blocks. The NameNode periodically receives a Blockreport from each of the DataNodes in the cluster. A Blockreport contains a list of all blocks on a DataNode. The NameNode constantly tracks which blocks need to be replicated and initiates replication whenever necessary.
The timely and successful replication of blocks is important for minimizing data loss at the time of disaster recovery. It is hence the responsibility of the administrator to watch over replication operations and proactively detect abnormalities (if any) in it.
Other common causes for data loss are corrupted blocks and missing blocks. An administrator needs to be able to spot such anomalies rapidly, isolate their cause, and resolve them quickly, so that Hadoop is able to deliver on its promise of 'reliable storage'.
Towards this end, administrators can take the help of the HdpBlockStatTest test. This test monitors data blocks in the Hadoop file system and turns administrator attention to corrupt and missing blocks. This way, the test urges administrators to find the reasons for such problems and the resolution for the same. The test also monitors replication operations and alerts administrators to deviations in the replication process, so they can see if the replication policy can be tweaked to remove the deviations and improve storage reliability.
Outputs of the test : One set of the results for the target Hadoop cluster
The measures made by this test are as follows:
| Measurement |
Description |
Measurement Unit |
Interpretation |
| Num_corrupt_blocks |
Indicates the current number of blocks that HDFS reports as corrupted. |
Number |
Ideally, the value of these measures should be 0. A non-zero value for the Corrupt blocks measure indicates that one/more blocks are with corrupt replicas. A block is “with corrupt replicas” in HDFS if it has at least one corrupt replica along with
at least one live replica. As such, a block having corrupt replicas does not indicate unavailable data, but they do indicate an increased chance that data may become unavailable.
A non- zero value for the Missing blocks measure indicates that one/more blocks are missing. If none of a block’s replicas are live, the block is called a missing block by HDFS.
Here are lists of potential causes and actions that you may take to handle the missing or corrupted blocks:
HDFS automatically fixes corrupt blocks in the background. A failure of this may indicate a problem with the underlying storage or
filesystem of a DataNode. Use the HDFS fsck command to identify which files contain corrupt blocks. Delete the corrupt files and recover them from backup, if it exists.
Some DataNodes are down and the replicas that are missing blocks are only on those DataNodes. Bring up the failed DataNodes with missing or corrupt blocks to resolve this issue.
The corrupt/missing blocks are from files with a replication factor of 1. New replicas cannot be created because the only replica
of the block is missing. You may want to increase the replication factor of critical data to 3 to address this issue.
|
| Num_missing_blocks |
Indicates the current number of missing blocks. |
Number |
| Num_allocated_blocks |
Indicates the current number of allocated blocks in the system. |
Number |
|
| Replication_sched_blocks |
Indicates the current number of blocks scheduled for replications. |
Number |
This value varies from datanodes being online or offline, and the number of replicas being changed in
the hdfs-site.xml(dfs.replication). |
| Under_replication_blocks |
Indicates the current number of blocks that are under-replicated. |
Number |
UnderReplicatedBlocks are the number of blocks with insufficient replication. Hadoop’s replication
factor is configurable on a per-client or per- file basis. The default replication factor is three, meaning that each block will be stored on three DataNodes. If you see a large, sudden spike in the number of under- replicated blocks, it is likely that a DataNode has died. |
| Delete_pending_blocks |
Indicates the current number of blocks that are waiting for deletion. |
Number |
Datanodes that are back online after being down reduces the number of blocks waiting for deletion. |
| Excess_blocks |
Indicates the current number of excess blocks in the cluster. |
Number |
Excess blocks can be caused by a NameNode losing heartbeats from one or more datanodes, thus
resulting in the scheduling of extra replicas. |
|