Hi Michael,
The reason is that cluster B is a production environment with jobs running
on it non-stop. I do not want to take ressources away from it. Secondly,
the "destination" cluster A is a much less powerful test environment, thus,
even when running the job on B - the slow HBase sink on cluste
Just out of curiosity...
Why do you want to run the job on Cluster A that reads from Cluster B but
writes to Cluster A?
Wouldn't it be easier to run the job on Cluster B and inside the Mapper.setup()
you create your own configuration for your second cluster for output?
On Mar 24, 2013, at 7
Hello J-D,
Thanks, it was instructive to look at the source. However, I am now stuck
with getting HBase to honor the "hbase.mapred.output.quorum" setting. I
opened a separate topic for this.
Regards,
/David
On Mon, Mar 18, 2013 at 11:26 PM, Jean-Daniel Cryans wrote:
> Checkout how CopyTable d
Checkout how CopyTable does it:
https://github.com/apache/hbase/blob/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/CopyTable.java
J-D
On Mon, Mar 18, 2013 at 3:09 PM, David Koch wrote:
> Hello,
>
> Is it possible to run a M/R on cluster A over a table that resides on
> clust
Hello,
Is it possible to run a M/R on cluster A over a table that resides on
cluster B with output to a table on cluster A? If so, how?
I am interested in doing this for the purpose of copying part of a table
from B to A. Cluster B is a production environment, cluster A is a slow
test platform. I