Interesting - HDFS-6133 would directly help HBase data locality use case.
On Fri, Dec 19, 2014 at 2:20 PM, Yongjun Zhang wrote:
> Hi,
>
> FYI,
>
> A relevant jira HDFS-6133 tries to tell Balancer not to move around the
> blocks stored at the favored nodes that application selected. I reviewed
>
Hi,
FYI,
A relevant jira HDFS-6133 tries to tell Balancer not to move around the
blocks stored at the favored nodes that application selected. I reviewed
the patch, and the latest on looks good to me. Hope some committers can
pick it up and push it forward.
Thanks.
--Yongjun
On Fri, Dec 19, 2
Hello Zhe,
Thanks a lot for the inputs. Storage policies is really what I was looking
for one of the problems.
@Nick: I agree that it would be a nice feature to have. Thanks for the
info.
Regards,
Ananth
On Fri, Dec 19, 2014 at 10:49 AM, Nick Dimiduk wrote:
> HBase would enjoy a similar funct
HBase would enjoy a similar functionality. In our case, we'd like all
replicas for all files in a given HDFS path to land on the same set of
machines. That way, in the event of a failover, regions can be assigned to
one of these other machines that has local access to all blocks for all
region file
> The second aspect is that our queries are time based and this time window
> follows a familiar pattern of old data not being queried much. Hence we
> would like to preserve the most recent data in the HDFS cache ( impala is
> helping us manage this aspect via their command set ) but we would like
Hello All,
I was wondering if the following issues can be solved by extending hdfs
classes with custom implementations if possible.
Here are my requirements :
1. Is there a way to control that all file blocks belonging to a particular
hdfs directory & file go to the same physical datanode ( an
