Return-Path: X-Original-To: apmail-hadoop-mapreduce-user-archive@minotaur.apache.org Delivered-To: apmail-hadoop-mapreduce-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C9D7DCE73 for ; Mon, 17 Mar 2014 17:08:18 +0000 (UTC) Received: (qmail 78951 invoked by uid 500); 17 Mar 2014 17:08:01 -0000 Delivered-To: apmail-hadoop-mapreduce-user-archive@hadoop.apache.org Received: (qmail 78280 invoked by uid 500); 17 Mar 2014 17:08:00 -0000 Mailing-List: contact user-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hadoop.apache.org Delivered-To: mailing list user@hadoop.apache.org Received: (qmail 78269 invoked by uid 99); 17 Mar 2014 17:07:59 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 Mar 2014 17:07:59 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of tucu@cloudera.com designates 209.85.192.181 as permitted sender) Received: from [209.85.192.181] (HELO mail-pd0-f181.google.com) (209.85.192.181) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 Mar 2014 17:07:54 +0000 Received: by mail-pd0-f181.google.com with SMTP id p10so5802021pdj.12 for ; Mon, 17 Mar 2014 10:07:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:from:content-type:in-reply-to :message-id:date:to:content-transfer-encoding:mime-version; bh=bac7cRWT+C9sSSE22yapoH+bx1i6U1dm1kpOfRUvVvE=; b=W8Vb/hej9c0lHihme8gz41l05GiXTWpXBms/SAcpTD3lMJhDL7SRHl1OG/RGXtPnsw RID95PSNGUpxITuCR94jhKPyn40yRuFoOsvZiwrMrhley96z06gGqjlA1JlUD/5RGqo2 B7YCRuTqGban+sdxwM1g5tlumjTWBsrsFsj7WmshBzerFYxYaDDaYlmyzfHdknWwzGjw wS5rs1Xzk4pQlpP4couqGcEPeYoPh+qCNXuAzMDIdI0ool4bCsDqi/ckTK9RLsXTysoX HtsScsmVZFfKOnZIzJVhbSDd9Zyue62nePVdxeT5EQEa9oV8p3lH6PKj0a275aPGe5rQ A6MQ== X-Gm-Message-State: ALoCoQloVAVGZHmaLvM5wsuCET/Weuue8wk0lhYs56qhBsB2ZU44FuQM4HDC/Lx05XZtFTUDLFLT X-Received: by 10.68.164.4 with SMTP id ym4mr28085763pbb.53.1395076054364; Mon, 17 Mar 2014 10:07:34 -0700 (PDT) Received: from [192.168.2.102] (70-36-143-86.dsl.dynamic.sonic.net. [70.36.143.86]) by mx.google.com with ESMTPSA id st4sm74457684pab.34.2014.03.17.10.07.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Mar 2014 10:07:33 -0700 (PDT) Subject: Re: Data Locality and WebHDFS References: From: Alejandro Abdelnur Content-Type: multipart/alternative; boundary=Apple-Mail-D3354A3E-4F25-403C-BE90-135E1F8DE4AD X-Mailer: iPhone Mail (11D167) In-Reply-To: Message-Id: <56681234-BFCC-4293-A9D9-05547F53F9B3@cloudera.com> Date: Mon, 17 Mar 2014 10:07:31 -0700 To: "user@hadoop.apache.org" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail-D3354A3E-4F25-403C-BE90-135E1F8DE4AD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable dont recall how skips are handled in webhdfs, but i would assume that you'll= get to the first block As usual, and the skip is handled by the DN serving t= he file (as webhdfs doesnot know at open that you'll skip) Alejandro (phone typing) > On Mar 17, 2014, at 9:47, RJ Nowling wrote: >=20 > Hi Alejandro, >=20 > The WebHDFS API allows specifying an offset and length for the request. I= f I specify an offset that start in the second block for a file (thus skippi= ng the first block all together), will the namenode still direct me to a dat= anode with the first block or will it direct me to a namenode with the secon= d block? I.e., am I assured data locality only on the first block of the fi= le (as you're saying) or on the first block I am accessing? >=20 > If it is as you say, then I may want to reach out the WebHDFS developers a= nd see if they would be interested in the additional functionality. >=20 > Thank you, > RJ >=20 >=20 >> On Mon, Mar 17, 2014 at 2:40 AM, Alejandro Abdelnur w= rote: >> I may have expressed myself wrong. You don't need to do any test to see h= ow locality works with files of multiple blocks. If you are accessing a file= of more than one block over webhdfs, you only have assured locality for the= first block of the file. >>=20 >> Thanks. >>=20 >>=20 >>> On Sun, Mar 16, 2014 at 9:18 PM, RJ Nowling wrote: >>> Thank you, Mingjiang and Alejandro. >>>=20 >>> This is interesting. Since we will use the data locality information fo= r scheduling, we could "hack" this to get the data locality information, at l= east for the first block. As Alejandro says, we'd have to test what happens= for other data blocks -- e.g., what if, knowing the block sizes, we request= the second or third block? >>>=20 >>> Interesting food for thought! I see some experiments in my future! =20 >>>=20 >>> Thanks! >>>=20 >>>=20 >>>> On Sun, Mar 16, 2014 at 10:14 PM, Alejandro Abdelnur wrote: >>>> well, this is for the first block of the file, the rest of the file (bl= ocks being local or not) are streamed out by the same datanode. for small fi= les (one block) you'll get locality, for large files only the first block, a= nd by chance if other blocks are local to that datanode.=20 >>>>=20 >>>>=20 >>>> Alejandro >>>> (phone typing) >>>>=20 >>>>> On Mar 16, 2014, at 18:53, Mingjiang Shi wrote: >>>>>=20 >>>>> According to this page: http://hortonworks.com/blog/webhdfs-%E2%80%93-= http-rest-access-to-hdfs/ >>>>>> Data Locality: The file read and file write calls are redirected to t= he corresponding datanodes. It uses the full bandwidth of the Hadoop cluster= for streaming data. >>>>>>=20 >>>>>> A HDFS Built-in Component: WebHDFS is a first class built-in componen= t of HDFS. It runs inside Namenodes and Datanodes, therefore, it can use all= HDFS functionalities. It is a part of HDFS =E2=80=93 there are no additiona= l servers to install >>>>>>=20 >>>>>=20 >>>>> So it looks like the data locality is built-into webhdfs, client will b= e redirected to the data node automatically.=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On Mon, Mar 17, 2014 at 6:07 AM, RJ Nowling wrot= e: >>>>>> Hi all, >>>>>>=20 >>>>>> I'm writing up a Google Summer of Code proposal to add HDFS support t= o Disco, an Erlang MapReduce framework. =20 >>>>>>=20 >>>>>> We're interested in using WebHDFS. I have two questions: >>>>>>=20 >>>>>> 1) Does WebHDFS allow querying data locality information? >>>>>>=20 >>>>>> 2) If the data locality information is known, can data on specific da= ta nodes be accessed via Web HDFS? Or do all Web HDFS requests have to go t= hrough a single server? >>>>>>=20 >>>>>> Thanks, >>>>>> RJ >>>>>>=20 >>>>>> --=20 >>>>>> em rnowling@gmail.com >>>>>> c 954.496.2314 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> --=20 >>>>> Cheers >>>>> -MJ >>>=20 >>>=20 >>>=20 >>> --=20 >>> em rnowling@gmail.com >>> c 954.496.2314 >>=20 >>=20 >>=20 >> --=20 >> Alejandro >=20 >=20 >=20 > --=20 > em rnowling@gmail.com > c 954.496.2314 --Apple-Mail-D3354A3E-4F25-403C-BE90-135E1F8DE4AD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
dont recall how skips are handled in webhdfs, but i would assume t= hat you'll get to the first block As usual, and the skip is handled by the D= N serving the file (as webhdfs doesnot know at open that you'll skip)=

Alejandro
(phone typing)
=

On Mar 17, 2014, at 9:47,= RJ Nowling <rnowling@gmail.com= > wrote:

Hi Alejandro,

The W= ebHDFS API allows specifying an offset and length for the request.  If I= specify an offset that start in the second block for a file (thus skipping t= he first block all together), will the namenode still direct me to a datanod= e with the first block or will it direct me to a namenode with the second bl= ock?  I.e., am I assured data locality only on the first block of the f= ile (as you're saying) or on the first block I am accessing?

If it is as you say, then I may want to reach out the We= bHDFS developers and see if they would be interested in the additional funct= ionality.

Thank you,
RJ


On Mon, Mar 17= , 2014 at 2:40 AM, Alejandro Abdelnur <tucu@cloudera.com> wrot= e:
I may have expressed myself w= rong. You don't need to do any test to see how locality works with files of m= ultiple blocks. If you are accessing a file of more than one block over webh= dfs, you only have assured locality for the first block of the file.

Thanks.


On Sun, Mar 16, 2014 at 9:18 PM, R= J Nowling <rnowling@gmail.com> wrote:
Thank you, Mingjiang and Alej= andro.

This is interesting.  Since we will use the d= ata locality information for scheduling, we could "hack" this to get the dat= a locality information, at least for the first block.  As Alejandro say= s, we'd have to test what happens for other data blocks -- e.g., what if, kn= owing the block sizes, we request the second or third block?

Interesting food for thought!  I see some experimen= ts in my future!  

Thanks!


On Sun, Mar 16, 2014 at 10:14 PM, Alejandro Abdelnur <<= a href=3D"mailto:tucu@cloudera.com" target=3D"_blank">tucu@cloudera.com&= gt; wrote:
well, this is for the f= irst block of the file, the rest of the file (blocks being local or not) are= streamed out by the same datanode. for small files (one block) you'll get l= ocality, for large files only the first block, and by chance if other blocks= are local to that datanode. 


Alejandro
(phone typing)

On Mar 16, 2014, at 18:53, Mingjiang Shi <mshi@gopivotal.com> wrote:

According to this page: http://hortonworks.com/blog/webhdfs-%E2%80%93-http-rest-access-to-h= dfs/

Data Locality: The file read and file write calls=20 are redirected to the corresponding datanodes. It uses the full=20 bandwidth of the Hadoop cluster for streaming data.

A HDFS Built-in Component: WebHDFS is a first class=20 built-in component of HDFS. It runs inside Namenodes and Datanodes,=20 therefore, it can use all HDFS functionalities. It is a part of HDFS =E2=80=93= =20 there are no additional servers to install


So it looks like the data lo= cality is built-into webhdfs, client will be redirected to the data node aut= omatically.




On Mon, Mar 17, 2014 at 6:07 AM, RJ Nowling <rnowling@gmail.com&g= t; wrote:
Hi all,

I'= m writing up a Google Summer of Code proposal to add HDFS support to Disco, a= n Erlang MapReduce framework.  

We're interested in using WebHDFS.  I have two ques= tions:

1) Does WebHDFS allow querying data locality information= ?

2) If the data locality information is known, can= data on specific data nodes be accessed via Web HDFS?  Or do all Web H= DFS requests have to go through a single server?

Thanks,



--
Ch= eers
-MJ



--
em rnowling@gmail.com
c 954.496.2314



--
Alejandro



--
em rnowling@gmail.com
c 954.496.2314 = --Apple-Mail-D3354A3E-4F25-403C-BE90-135E1F8DE4AD--