Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
MapReduce >> mail # user >> Fwd: Bulk Import & Data Locality


Copy link to this message
-
Fwd: Bulk Import & Data Locality
Thank you a lot for the replies.

To me it is clear when data locality gets broken though (and it is not only
the failure of the RS, there are other cases). I was hoping more for
suggestions around this particular use-case: assuming that nodes/RSs are
stable, how to make sure to achieve the data locality when doing bulk
import (writing HFiles directly from MR job). Running major compaction
helps here (as new files are created instead of old ones *on the DataNode
local to RS where region is being compacted), but I'd really want to not do
it. This is quite resource intensive and thus expensive process...

I was hoping also guys from HDFS/MapReduce teams would comment on my latter
Qs.

I heard that there is some work in HBase community to allow "asking" HDFS
to replicate blocks of the files together (so that there are full replicas
on other nodes, which helps as Lars noted) too. I also heard from a HDFS
guy that there are ideas around better replication logic.

Little offtop:

>> >>>> Also is it correct to say that if i set smaller data block size data
>> >>>> locality gets worse, and if data block size gets bigger  data
>> locality
>> >>> gets
>> >>>> better.

*Theoretically* if your region data stored in one HFile (say one flush
occurred or major compaction caused that, given that there's one CF) and
this HFile is smaller than the configured block size on HDFS, then we can
say that 3  (or whatever is replication) replicas of this file (and hence
of this region) are "full" replicas, which makes it easier to preserve data
locality if RS fails down (or when anything else cause re-assigning the
region). But since Region size is usually much bigger (usually 10-20 times
bigger at least), this fact doesn't buy you something.

Alex Baranau
------
Sematext :: http://blog.sematext.com/ :: Hadoop - HBase - ElasticSearch -
Solr

On Wed, Jul 18, 2012 at 9:43 PM, Ben Kim <[EMAIL PROTECTED]> wrote:

> I added some Q&A's went with Lars. Hope this is somewhat related to your
> data locality questions.
>
>  >>>
> >> >>> On Jun 15, 2012, at 6:56 AM, Ben Kim wrote:
> >> >>>
> >> >>>> Hi,
> >> >>>>
> >> >>>> I've been posting questions in the mailing-list quiet often lately,
> >> and
> >> >>>> here goes another one about data locality
> >> >>>> I read the excellent blog post about data locality that Lars George
> >> wrote
> >> >>>> at
> >> http://www.larsgeorge.com/2010/05/hbase-file-locality-in-hdfs.html
> >> >>>>
> >> >>>> I understand data locality in hbase as locating a region in a
> >> >>> region-server
> >> >>>> where most of its data blocks reside.
> >> >>>
> >> >>> The opposite is happening, i.e. the region server process triggers
> >> for all
> >> >>> data it writes to be located on the same physical machine.
> >> >>>
> >> >>>> So that way fast data access is guranteed when running a MR because
> >> each
> >> >>>> map/reduce task is run for each region in the tasktracker where the
> >> >>> region
> >> >>>> co-locates.
> >> >>>
> >> >>> Correct.
> >> >>>
> >> >>>> But what if the data blocks of the region are evenly spread over
> >> multiple
> >> >>>> region-servers?
> >> >>>
> >> >>> This will not happen, unless the original server fails. Then the
> >> region is
> >> >>> moved to another that now needs to do a lot of remote reads over the
> >> >>> network. This is way there is work being done to allow for custom
> >> placement
> >> >>> policies in HDFS. That way you can store the entire region and all
> >> copies
> >> >>> as complete units on three data nodes. In case of a failure you can
> >> then
> >> >>> move the region to one of the two copies. This is not available yet
> >> though,
> >> >>> but it is being worked on (so I heard).
> >> >>>
> >> >>>> Does a MR task has to remotely access the data blocks from other
> >> >>>> regionservers?
> >> >>>
> >> >>> For the above failure case, it would be the region server accessing
> >> the
> >> >>> remote data, yes.
> >> >>>
> >> >>>> How good is hbase locating datablocks where a region resides?

Alex Baranau
Sematext :: http://blog.sematext.com/ :: Hadoop - HBase - ElasticSearch -
Solr
Alex Baranau
Sematext :: http://blog.sematext.com/ :: Hadoop - HBase - ElasticSearch -
Solr
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB