For the above requirement, the memory consumption would depend on the HDFS set up, so depending on the overall size of the HDFS and its relative block size. Please refer to the below explanation.
One namenode object uses about 150 bytes to store metadata information. Assume a 128 MB block size - you should increase the block size if you have a lot of data (PB scale or even 500+ TB in some cases).
Assume a file size 150 MB. The file will be split into two blocks. First block with 128 MB and second block with 22MB. For this file following information will be stored by Namenode.
1 file inode and 2 blocks.
That is 3 namenode objects. They will take about 450 bytes on namenode. For example, at 1MB block size, in this case, we will have 150 file blocks. We will have one inode and 150 blocks information in namenode. This means 151 namenode objects for the same data. 151 x 150 bytes = 22650 bytes. Even worse would be to have 150 files with 1MB each. That would require 150 inodes and 150 blocks = 300 x 150 bytes = 45000 bytes. See how this all changes. That's why we don't recommend small files for Hadoop.
Now assuming 128 MB file blocks, on average 1GB of memory is required for 1 million blocks.
Now let's do this calculation at PB scale.
Assume 6000 TB of data. That's a lot.
Imagine 30 TB capacity for each node. This will require 200 nodes.
At 128 MB block size, and a replication factor of 3.
Cluster capacity in MB = 30 x 1000 (convert to GB) x 1000 (convert to MB) x 200 nodes = 6 000000000 MB (6000 TB)
How many blocks can we store in this cluster?
6 000 000 000 MB/128 MB = 46875000 (that's 47 million blocks)
Assume 1 GB of memory required per million blocks, you need a mere 46875000 blocks / 1000000 blocks per GB = 46 GB of memory.
Namenodes with 64-128 GB memory are quite common. You can do a few things here.
1. Increase the block size to 256 MB and that will save you quite a bit of namenode space. At large scale, you should do that regardless.
2. Get more memory for name node. Probably 256 GB (Never had any customer go this far - may be someone else can chime in).
