Hi Vino,
> The local keyed state we introduced is not exposed to the outside!
I have read your design and know the way how you implement local
aggregation via local keyed state, and how the local keyed state works.
Currently, Flink exposes two basic kinds of state: operator state and keyed
state.
+1 (non-binding)
- built from source successfully
- checked signatures and hashes
- run a couple of end-to-end tests locally with success
- started a cluster both for scala-2.11 and scala-2.12, ran examples, WebUI
is accessible, no suspicious log output
- reviewed the release PR and left comments
Dear community,
this weeks community digest with updates on Flink 1.8.1 & Flink 1.9.0,
another thread on our development process and a few API related threads. I
still include older threads from time to time. Enjoy!
As always, please feel free to add additional updates and news to this
thread!
Hi hequn, Thanks for the reply! I think `withKeys` solution is our better
choice!
Hequn Cheng 于2019年6月26日周三 下午5:11写道：
> Hi Jincheng,
>
> Thanks for raising the discussion!
> The key information is very important for query optimizations. It would be
> nice if we can use upsert mode to achieve
+1 (binding)
With the following checks:
- checked gpg signatures by `gpg --verify 181.asc flink-1.8.1-src.tgz`
[success]
- checked the hashes by `shasum -a 512 flink-1.8.1-src.tgz` [success]
- built from source by `mvn clean package -DskipTests` [success]
- download the `flink-core-1.8.1.jar`
Hi,
I have a question about the key information of TableAggregateFunction.
IIUC, you need to define
something like primary key or unique key in the result table of
TableAggregateFunction, and also
need a way to let user configure this through the API. My question is, will
that effect the logic of
Hi Jark,
> I will call them "local keyed state" because they have different
semantics with keyed state, even if "ListState", "MapState" are keyed state
primitives currently. From the point of my view, this exposes local keyed
state to users.
Actually, it depends on how to understand. From a
Hi Haifeng,
Thank you for your willingness to contribute to the Flink community! I've
given you contributor permissions!
We communicate offline to correct your JIRA id is Spafka. :) Just confirm
that your profile is:
https://issues.apache.org/jira/secure/ViewProfile.jspa?name=Spafka
Please
Hi Kurt,
Thanks for your questions, I am glad to share my thoughts here:
My question is, will that effect the logic ofTableAggregateFunction user
> wrote? Should the user know that there will a key and make some changes to
> this function?
No, the keys information depends on the implementation
Hi Jincheng,
Thanks for the clarification. Take 'TopN' for example, if I want to write
such kind function,
should I make sure that this function is used with some keys? If I need a
use case to calculate
topn without key, should I write another function or I can reuse previous
one.
I'm not sure
Yun Tang created FLINK-13034:
Summary: Improve the performance when checking whether mapstate is
empty for RocksDBStateBackend
Key: FLINK-13034
URL: https://issues.apache.org/jira/browse/FLINK-13034
11 matches
Mail list logo
