Mailing-List: contact user-help@flink.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@flink.apache.org
MIME-Version: 1.0
In-Reply-To: <5731A3B6.2070401@apache.org>
References: <CALKuzdk2ThW0FOq2znFm+kkSNZzYiq7bRRMzKvtuVr01v7_ryw@mail.gmail.com>
	<CALKuzdmQeN+7CBW1wHwpeMGohzn3OWdBk2A3_8xgxNZb6qjiLA@mail.gmail.com>
	<CALKuzdkkJLDTrYb9CMnnP2rkNGo7tjKWJm40PtY6OccK6XR-hA@mail.gmail.com>
	<CALKuzdk6DfMG6rVeBzeX0DcHeDtmScj+e0mgOtWKnAeBks6SZA@mail.gmail.com>
	<CALKuzdkhAZmd002pTxRLP_xzHESwz0RCYAJmUM441fwyBbmMaw@mail.gmail.com>
	<CALKuzd=eNbgVxuO75Zsmqb_r1jO=wMZ-NhQFigkvx1gxCrC2rg@mail.gmail.com>
	<CALKuzdkg7yBoydBeCEn_je4b_afD1k-ESthHHzaYrn=nZK-njA@mail.gmail.com>
	<CALKuzd=4TBiiEPdm0p0bfNck0nRQXSeobBUNNg5jZWiZL_H6qg@mail.gmail.com>
	<CALKuzdmbJGjbyi82LLzxfwx_WyFnrmDvvjpo24=YvAAQouNd7Q@mail.gmail.com>
	<CALKuzdmNW_vQ5BMuwdcRgghiEWiwCmTTdiReZ4EbpFYO+1MWzw@mail.gmail.com>
	<CALKuzdmgvG2gkeb=T8OxB2_eDeJdkCkbW+p0qUhJWSAddqRXjA@mail.gmail.com>
	<CALKuzd=E0FcmncTDyhm4B3G55FAzDWXbuc7jPf3jJQQ4hwf_nA@mail.gmail.com>
	<CALKuzdki4vpP1XY7_Ejm-w2Yq9T0GGBNGOhbgd+hUeDJAkvE5Q@mail.gmail.com>
	<CALKuzdkYH4JChbVKT9oOTPam+1eyZo2jSj8+y0Vxnbq7UbO18Q@mail.gmail.com>
	<5731A3B6.2070401@apache.org>
Date: Tue, 10 May 2016 08:36:43 -0700
Message-ID: <CALKuzdk2OPhD+EEK0H6z7CJFkfaTQcij=FuAYyBDp9B-JJYLVA@mail.gmail.com>
Subject: Re: Cassandra sink wrt Counters
From: milind parikh <milindsparikh@gmail.com>
To: user@flink.apache.org
Content-Type: multipart/alternative; boundary=001a114304563a931405327eb197
archived-at: Tue, 10 May 2016 15:36:49 -0000

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

Hi Chesnay

Sorry for asking the question in a confusing manner. Being new to flink,
there are many questions swirling around in my head.

Thanks for the details in your answers. Here's the facts , as I see them:

(a) Cassandra Counters are not idempotent
(b) The failures, in context of Cassandra, are not the typical failures of
an ACID transaction. The failure indicate that the operation was not able
to continue at the specified transaction level; meaning that at least one
of the nodes didn't ack back in the requisite amount of time the reads or
the writes. This failure is NOT indicative of the fact that some node (or
many ) might have seen and processed the reads or writes; just that at
least one of the nodes did not. There is no rollback either. The
antientropy features of Cassandra will kick in and attempt to correct the
situation internal to Cassandra. From an external system, though, the
situation is different....if such failure occurs, one could try to retry
the operation (specifically writes) again outside of Cassandra; provided
one has the ability to do so through an intermediate layer (think flink)and
the write is specifically modeled to be idempotent in the data model
(specifically Rowkey design).

One could model the data model so as to make Flink work exceptionally well
with Cassandra; except counter tables. There is no way in Cassandra
currently to model an idempotent counter table that I know of. Therefore an
event replay that affects a counter might end up double counting.

When will the Cassandra sink be released?  I am ready to test it out even
now.
Hello Milind,

I'm not entirely sure i fully understood your question, but I'll try anyway
:)

There is now way to provide exactly-once semantics for Cassandra's
counters. As such we (will) only provide exactly-once semantics for a
subset of Cassandra operations; idempotent inserts/updates.

There are several things that would allow exactly-once semantics:

   - transactions
      - rather obvious i think
      - replaying/rollback to a given state
      - replay for sources/rollback for sinks upon failure
      - an atomic idempotent update across 2 tables.
      - allows tracking every read/write made; selectively re-read/write
      upon failure

One of the key requisites is proper failure reporting though; if an update
fails we *need to know*. As far as i know Cassandra doesn't make this
guarantee.

Regards,
Chesnay Schepler

On 10.05.2016 07:48, milind parikh wrote:

Given FLINK 3311 & 3332, I am wondering it would be possible,  without
idempotent counters in Cassandra, to deliver on an exactly once sink into
Cassandra. I do note that the verbiage/disc2 in 3332 does warn the user
that this is not exactly "exactly once" sink.

However my question  has to do with whether having idempotent counters and
a Data model that enables all other idempotent operations are a necessary
prerequisite to exactly once semantics in flink.

Asked a different way, what source and sink would enable a end-to-end
exactly - once semantics,  in the current state-of-the-art, with Flink in
the middle.

Thanks
Milind

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

<p dir=3D"ltr">Hi Chesnay</p>
<p dir=3D"ltr">Sorry for asking the question in a confusing manner. Being n=
ew to flink, there are many questions swirling around in my head.</p>
<p dir=3D"ltr">Thanks for the details in your answers. Here&#39;s the facts=
 , as I see them:</p>
<p dir=3D"ltr">(a) Cassandra Counters are not idempotent <br>
(b) The failures, in context of Cassandra, are not the typical failures of =
an ACID transaction. The failure indicate that the operation was not able t=
o continue at the specified transaction level; meaning that at least one of=
 the nodes didn&#39;t ack back in the requisite amount of time the reads or=
 the writes. This failure is NOT indicative of the fact that some node (or =
many ) might have seen and processed the reads or writes; just that at leas=
t one of the nodes did not. There is no rollback either. The antientropy fe=
atures of Cassandra will kick in and attempt to correct the situation inter=
nal to Cassandra. From an external system, though, the situation is differe=
nt....if such failure occurs, one could try to retry the operation (specifi=
cally writes) again outside of Cassandra; provided one has the ability to d=
o so through an intermediate layer (think flink)and the write is specifical=
ly modeled to be idempotent in the data model (specifically Rowkey design).=
</p>
<p dir=3D"ltr">One could model the data model so as to make Flink work exce=
ptionally well with Cassandra; except counter tables. There is no way in Ca=
ssandra currently to model an idempotent counter table that I know of. Ther=
efore an event replay that affects a counter might end up double counting.<=
/p>
<p dir=3D"ltr">When will the Cassandra sink be released?=C2=A0 I am ready t=
o test it out even now.<br>
</p>
<div class=3D"gmail_quot&lt;blockquote class=3D" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div>Hello Milind,<br>
      <br>
      I&#39;m not entirely sure i fully understood your question, but I&#39=
;ll
      try anyway :)<br>
      <br>
      There is now way to provide exactly-once semantics for Cassandra&#39;=
s
      counters. As such we (will) only provide exactly-once semantics
      for a subset of Cassandra operations; idempotent inserts/updates.<br>
      <br>
      There are several things that would allow exactly-once semantics:<br>
      <ul>
        <li>transactions</li>
        <ul>
          <li>rather obvious i think<br>
          </li>
        </ul>
        <li>replaying/rollback to a given state</li>
        <ul>
          <li>replay for sources/rollback for sinks upon failure<br>
          </li>
        </ul>
        <li>an atomic idempotent update across 2 tables.</li>
        <ul>
          <li>allows tracking every read/write made; selectively
            re-read/write upon failure</li>
        </ul>
      </ul>
      One of the key requisites is proper failure reporting though; if
      an update fails we <i>need to know</i>. As far as i know
      Cassandra doesn&#39;t make this guarantee.<br>
      <br>
      Regards,<br>
      Chesnay Schepler<br>
      <br>
      On 10.05.2016 07:48, milind parikh wrote:<br>
    </div>
    <blockquote type=3D"cite">
      <p dir=3D"ltr">Given FLINK 3311 &amp; 3332, I am wondering it would
        be possible,=C2=A0 without idempotent counters in Cassandra, to
        deliver on an exactly once sink into Cassandra. I do note that
        the verbiage/disc2 in 3332 does warn the user that this is not
        exactly &quot;exactly once&quot; sink.</p>
      <p dir=3D"ltr"> However my question=C2=A0 has to do with whether havi=
ng
        idempotent counters and a Data model that enables all other
        idempotent operations are a necessary prerequisite to exactly
        once semantics in flink. </p>
      <p dir=3D"ltr">Asked a different way, what source and sink would
        enable a end-to-end exactly - once semantics,=C2=A0 in the current
        state-of-the-art, with Flink in the middle.</p>
    </blockquote>
    <blockquote type=3D"cite">
      <p dir=3D"ltr">Thanks<br>
        Milind</p>
    </blockquote>
    <br>
  </div>

</div>

--001a114304563a931405327eb197--