sunjincheng created FLINK-5804:
--
Summary: Add [non-partitioned] processing time OVER RANGE BETWEEN
UNBOUNDED PRECEDING aggregation to SQL
Key: FLINK-5804
URL: https://issues.apache.org/jira/browse/FLINK-5804
sunjincheng created FLINK-5803:
--
Summary: Add [partitioned] processing time OVER RANGE BETWEEN
UNBOUNDED PRECEDING aggregation to SQL
Key: FLINK-5803
URL: https://issues.apache.org/jira/browse/FLINK-5803
Zhuoluo Yang created FLINK-5802:
---
Summary: Flink SQL calling Hive User-Defined Functions
Key: FLINK-5802
URL: https://issues.apache.org/jira/browse/FLINK-5802
Project: Flink
Issue Type: New Fea
Hi all,
thanks for this thread.
@Fabian If I didn't miss the point, the main difference between the two
approaches is whether or not taking these time attributes as common table
fields that are directly available to users. Whatever, these time
attributes should be attached to records (right?), an
Dear All,
I have few use cases for Flink streaming where the cluster consist of
heterogenous machines.
Additionally, there is skew present in both the input distribution (e.g.,
each tuple is drawn from a zipf distribution) and the service time (e.g.,
service time required for each tuple comes fro
Patrick Lucas created FLINK-5801:
Summary: Queryable State from Scala job/client fails with key of
type Long
Key: FLINK-5801
URL: https://issues.apache.org/jira/browse/FLINK-5801
Project: Flink
Hi,
Thanks for starting the discussion. I can see there are multiple trade-offs
in these two approaches. One question I have is that to which extent Flink
wants to open its APIs to allow users to access both processing and event
time.
Before we talk about joins, my understanding for the two appro
Stephan Ewen created FLINK-5800:
---
Summary: Make sure that the CheckpointStreamFactory is
instantiated once per operator only
Key: FLINK-5800
URL: https://issues.apache.org/jira/browse/FLINK-5800
Project
Till Rohrmann created FLINK-5799:
Summary: Let RpcService.scheduleRunnable return ScheduledFuture
Key: FLINK-5799
URL: https://issues.apache.org/jira/browse/FLINK-5799
Project: Flink
Issue Ty
Till Rohrmann created FLINK-5798:
Summary: Let the RPCService provide a ScheduledExecutorService
Key: FLINK-5798
URL: https://issues.apache.org/jira/browse/FLINK-5798
Project: Flink
Issue Typ
Pat,
Thanks for adding the new test results. This idea for this implementation
was Gábor's from the FLINK-3722 description.
Since you will be filing a FLIP I recommend including these benchmarks for
consideration and discussion on the mailing list. In part because the PR is
4 months old and need
Yelei Feng created FLINK-5797:
-
Summary: incorrect use of port range selector in BootstrapTool
Key: FLINK-5797
URL: https://issues.apache.org/jira/browse/FLINK-5797
Project: Flink
Issue Type: Bug
Hey Theodore,
Thanks for pointing us to Tensorflow, I didn't think it would be useful
for this.
From what you cite they seem to have a very similar state-handling
mechanism to Flink (as well as fault tolerance).
I'm sure we can get ideas from how they do model-parallel training. I'll
definitel
Hello all,
I would also be really interested in how a PS-like architecture would work
in Flink. Note that we not necessarily talking about PS, but generally how
QueryableState can be used for ML tasks with I guess a focus on
model-parallel training.
One suggestion I would make is to take a look a
Nico Kruber created FLINK-5796:
--
Summary: broken links in the docs
Key: FLINK-5796
URL: https://issues.apache.org/jira/browse/FLINK-5796
Project: Flink
Issue Type: Bug
Components: Docu
Hey Ufuk,
I'm happy to contribute. At least I'll get a bit more understanding of
the details.
Breaking the assumption that only a single thread updates state would
brings us from strong isolation guarantees (i.e. serializability at the
updates and read committed at the external queries) to n
Hey Gabor,
great ideas here. It's only slightly related, but I'm currently working on a
proposal to improve the queryable state APIs for lookups (partly along the
lines of what you suggested with higher level accessors). Maybe you are
interested in contributing there?
I really like your ideas
sunjincheng created FLINK-5795:
--
Summary: Improve “UDTF" to support with parameter constructor
Key: FLINK-5795
URL: https://issues.apache.org/jira/browse/FLINK-5795
Project: Flink
Issue Type: Su
sunjincheng created FLINK-5794:
--
Summary: Improve “UDF" to support with parameter constructor
Key: FLINK-5794
URL: https://issues.apache.org/jira/browse/FLINK-5794
Project: Flink
Issue Type: Imp
Hi Gyula, Jinkui Shi,
Thanks for your thoughts!
@Gyula: I'll try and explain a bit more detail.
The API could be almost like the QueryableState's. It could be
higher-level though: returning Java objects instead of serialized data
(because there would not be issues with class loading). Also, i
Hi Swapnil,
Flink does not have explicit support for this. It's the responsibility of
the user to make sure that the right watermarks are extracted from the
incoming events. This also means the correct handling of different time
zones.
Cheers,
Till
On Tue, Feb 14, 2017 at 8:41 AM, Swapnil Chougu
Hello,
Pat, the table in your email is somehow not visible in my gmail, but
it is visible here:
http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/FLINK-5734-Code-Generation-for-NormalizedKeySorter-tt15804.html#a15936
Maybe the problem is caused by the formatting.
> FLINK-3722
> appro
Hi [~greghogan]
I have done the benchmark comparing between FLINK-3722 and our approaches.
As you can see at *Score * column which represents sorting time, FLINK-3722
approach seems to be the fastest one.
--
View this message in context:
http://apache-flink-mailing-list-archive.1008284.n3.na
Hi,
It would as in the query I gave as an example before:
SELECT
a,
SUM(b) OVER (PARTITION BY c ORDER BY proctime ROWS BETWEEN 2
PRECEDING AND CURRENT ROW) AS sumB,
FROM myStream
Here "proctime" would be a system attribute of the table "myStream".
The table would also have another system att
24 matches
Mail list logo
