If the goal is proper isolation between an unstable environment and a production one - HDFS federation wouldn't be the best idea. For (1): You can associate HBase to one of your federated NameNode/NameService URI and that is the one it will use. HBase does not support spreading its table load across multiple nameservices, and thereby if you want both your environments to have HBase as an independent entity, you must run two HBase services, each hosted by a different NameNode via the hbase.rootdir and fs.defaultFS property URI configurations. HBase does have 'namespaces' of its own, but that's quite different than what HDFS namespaces mean in federation context (HBase's are more similar to Databases in Hive). For (2): As long as you divide your configurations well in addressing specific NameNodes, this should be doable, yes. For (3): YARN has no support for identifying one namespace over another, much like HBase does not. It can be bound to one namespace for the history logging/etc. parts, but if your goal is to run a single YARN cluster serving both sets of users/usages, you need to do so via regular queue configurations (and then explicitly using such queues via apps, or making the auto-queue-placement rules work in your benefit with whatever sources of user->queue mapping data it supports).
... View more