Mailing-List: contact user-help@kudu.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@kudu.apache.org
MIME-Version: 1.0
In-Reply-To: <CAKiisPJpqWzUk2MQcG10BvgvDGg-aYhtqQ28n4KK5tDyWYFw5w@mail.gmail.com>
References: <CAKiisPJpqWzUk2MQcG10BvgvDGg-aYhtqQ28n4KK5tDyWYFw5w@mail.gmail.com>
From: Todd Lipcon <todd@cloudera.com>
Date: Mon, 12 Dec 2016 12:51:14 +0700
Message-ID: <CADY20s4ZY6K_6_9pHUxFwaos6ZS-bPCVPS91zNRJ8V7bZCtvEA@mail.gmail.com>
Subject: Re: performance issue involving "insert as select"
To: user@kudu.apache.org
Content-Type: multipart/alternative; boundary=001a114b39844bcf5105436fb22c
archived-at: Mon, 12 Dec 2016 05:51:40 -0000

--001a114b39844bcf5105436fb22c
Content-Type: text/plain; charset=UTF-8

Hi Rotem,

On Thu, Dec 8, 2016 at 3:25 AM, Rotem Gabay <rotemgabay82@gmail.com> wrote:

> Hi, I have  a small cluster on which I tried to run some performance tests
> on kudu, In order to populate some data I have made simple "insert as
> select" from simple HDFS table that took 10 minutes to finish. I then tried
> to duplicate the same data by doing another insert as select from the kudu
> table to itself ( insert into kudu_tbl select * from kudu_tbl), this insert
> took more then 2 hours to complete. Is there ant reasonable explaination ?
>

One interesting aspect of current releases of Kudu is that Impala queries
don't operate with snapshot consistency. In the case that you are writing
into the same table that you are reading from, it's actually possible that
the query reads its own results.

Put another way, one fragment of the query may be writing into a tablet
while another fragment is still reading that tablet. Without snapshot
consistency, it's actually possible for this to create a sort of "infinite
loop" of inserts. While usually not infinite, it can end up producing far
more rows than you expected.

We're working on addressing this in upcoming releases. In the meantime,
it's probably best to generate your data in a different fashion rather than
inserting into the same table that you're reading from.

Hope that helps. Let us know if the explanation doesn't seem to match up
with what you're seeing.

-Todd
-- 
Todd Lipcon
Software Engineer, Cloudera

--001a114b39844bcf5105436fb22c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Rotem,<div><div class=3D"gmail_extra"><br><div class=3D=
"gmail_quote">On Thu, Dec 8, 2016 at 3:25 AM, Rotem Gabay <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:rotemgabay82@gmail.com" target=3D"_blank">rotemgabay=
82@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">Hi, I have =C2=A0a small cluster on which I tried to run some pe=
rformance tests on kudu, In order to populate some data I have made simple =
&quot;insert as select&quot; from simple HDFS table that took 10 minutes to=
 finish. I then tried to duplicate the same data by doing another insert as=
 select from the kudu table to itself ( insert into kudu_tbl select * from =
kudu_tbl), this insert took more then 2 hours to complete. Is there ant rea=
sonable explaination ?<br></div></blockquote><div><br></div><div>One intere=
sting aspect of current releases of Kudu is that Impala queries don&#39;t o=
perate with snapshot consistency. In the case that you are writing into the=
 same table that you are reading from, it&#39;s actually possible that the =
query reads its own results.</div><div><br></div><div>Put another way, one =
fragment of the query may be writing into a tablet while another fragment i=
s still reading that tablet. Without snapshot consistency, it&#39;s actuall=
y possible for this to create a sort of &quot;infinite loop&quot; of insert=
s. While usually not infinite, it can end up producing far more rows than y=
ou expected.</div><div><br></div><div>We&#39;re working on addressing this =
in upcoming releases. In the meantime, it&#39;s probably best to generate y=
our data in a different fashion rather than inserting into the same table t=
hat you&#39;re reading from.</div><div><br></div><div>Hope that helps. Let =
us know if the explanation doesn&#39;t seem to match up with what you&#39;r=
e seeing.</div><div><br></div><div>-Todd</div></div>-- <br><div class=3D"gm=
ail_signature" data-smartmail=3D"gmail_signature">Todd Lipcon<br>Software E=
ngineer, Cloudera</div>
</div></div></div>

--001a114b39844bcf5105436fb22c--