Just got a chance to look this over. I don't have anything to add, but I'm
pretty excited to follow this project. Have the JIRAs been filed since you
shared the doc?
On Wed, Feb 22, 2017 at 10:38 AM, Jason Kuster <
jasonkus...@google.com.invalid> wrote:
> Hey all, just wanted to pop this up again
I think that a per-key watermark is not just consistent with the model, but
also there's an argument to be made that it is the correct way to conceive
of watermarks in Beam. The way we currently hold watermarks inside of
ReduceFnRunner is via a WatermarkHold, which is set per-key. As a result,
the
Hi Davor, Jean-Baptiste,
Many thanks!
Roberto
Il giorno mar 28 feb 2017 alle 07:44 Jean-Baptiste Onofré
ha scritto:
Welcome aboard !!
Looking for your contributions !
Regards
JB
On 02/27/2017 11:51 PM, Roberto Bentivoglio wrote:
> Hi Everyone,
>
> I am a big fan of distributed streaming eng
Following up on what Kenn said, it seems like the idea of a per-key
watermark is logically consistent with Beam model. Each runner already
chooses how to approximate the model-level concept of the per-key watermark.
The list Kenn had could be extended with things ilke:
4. A runner that assumes the
This is a really interesting topic. I think Beam is a good place to have a
broader cross-runner discussion of this.
I know that you are not the only person skeptical due to
trickiness/costliness of implementation.
On the other hand, at a semantic level, I think any correct definition will
allow a
Thanks @Tyler, @JB. The first question for me is how it's used, a SQL
prompt like StormSQL, or the DSL API in Flink. In my project, it goes with
the 1st one as it's targeted on self-service for analyst. looks odd for me
to mix Java code and SQL string.
Regarding to the scope, that's a good point t
Hi Mingmin,
Thanks for writing it up.
I haven't had the chance to start work on it.
Happy to help on tasks for building it.
Feel free to assign BEAN-301 to yourself.
On Tue, Feb 28, 2017 at 9:38 AM, Tyler Akidau
wrote:
> Hi Mingmin,
>
> Thanks for your interest in helping out on this task, a
Hi,
It looks like you may have tried to attach an image or something, but it
did not come through the mailing list. Can you please try again?
This is what we see:
https://lists.apache.org/thread.html/f4a1ce5291428a70ecd54d3eefff56daf2f32b7a558f575eddc3729e@%3Cdev.beam.apache.org%3E
Dan
On Tue,
Hi Mingmin,
Thanks for your interest in helping out on this task, and for your initial
proposal. I'm also very happy to work with you on this, and excited to see
some progress made here. Added a few more comments on the doc, but will
summarize them below as well.
As far as the DSL point goes, I a
Thank you all. I will wait for release blocking issues to be closed.
Sergio, thank you for the information. I will document the friction points
during this release process. Following the release we can start a
discussion about how to fix those.
Ahmet
On Tue, Feb 28, 2017 at 9:22 AM, Aljoscha Kre
Joining in just a bit late, I'll be quick and say that IMHO the SDK is
mature enough and so my only point to add is *HDFS support*.
I think that in terms of adoption we have to support HDFS as a "first-class
citizen" via the FileSystem API, and provide data locality (batch) on top
of it - it serves
That was my mistake, sorry for that. I should have tagged [1] as a blocker
because leaking state is probably a bad idea. At least then people would be
aware and we could have discussed whether it is a blocker.
There is already an open PR for this now.
[1] https://issues.apache.org/jira/browse/BEA
Regarding BEAM-649, it's not a release blocker, it's a good to have.
As I'm pretty close to the end of the Pull Request (hopefully tonight or
tomorrow), it's a "Good To Have".
Regards
JB
On 02/28/2017 06:09 PM, Davor Bonaci wrote:
Can we please use JIRA to tag potentially release-blocking is
hello, in my case, I wan't to join double stream, while my join key is a
customer-defined Class(DataWithMeta), but exected failed! Below is the result!
I don't know why
Alright -- sounds like we have a consensus to proceed with the first stable
release after 0.6.0, targeting end of March / early April. I'll kick off
separate threads for specific decisions we need to make.
On Thu, Feb 23, 2017 at 6:07 AM, Aljoscha Krettek
wrote:
> I think we're ready for this! T
Can we please use JIRA to tag potentially release-blocking issues? Anyone
can just add a 'Fix Versions' field of an open issue to the next scheduled
release -- and it becomes easily visible to everyone in the project.
In general, I'm not a fan of blocking releases for new functionality.
Rushing ne
I would like to finish these two:
https://issues.apache.org/jira/browse/BEAM-1036: Support for new State API
in FlinkRunner
https://issues.apache.org/jira/browse/BEAM-1116: Support for new Timer API
in Flink runner
Both of them are finished for the streaming runner, for the batch runner
I'm mergin
Fair enough.
I also try to merge https://github.com/apache/beam/pull/1739 asap.
Regards
JB
On 02/28/2017 09:34 AM, Amit Sela wrote:
I'd prefer we wait to merge https://github.com/apache/beam/pull/2050
Shouldn't take long now..
On Tue, Feb 28, 2017 at 10:00 AM Sergio Fernández wrote:
Sounds
I'd prefer we wait to merge https://github.com/apache/beam/pull/2050
Shouldn't take long now..
On Tue, Feb 28, 2017 at 10:00 AM Sergio Fernández wrote:
> Sounds good!
>
> Ahmet, notice ASF has not current infrastructure to stage Python Release
> Candidates. Anyway we left unmanaged the Maven dep
Sounds good!
Ahmet, notice ASF has not current infrastructure to stage Python Release
Candidates. Anyway we left unmanaged the Maven deploy lifecycle for the
Python SDK, but it should be discussed at some point.
On Mon, Feb 27, 2017 at 11:01 PM, Ahmet Altay
wrote:
> Hi all,
>
> It's been abou
20 matches
Mail list logo
