New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New operator state interfaces #747
Conversation
public interface CheckpointCommittingOperator { | ||
|
||
void confirmCheckpoint(long checkpointId, long timestamp) throws Exception; | ||
void confirmCheckpoint(long checkpointId, SerializedValue<StateHandle<?>> state) throws Exception; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the chckpointId
still needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, we could potentially omit it but we kept it for now since it will make testing easier to associate confirmations with specific checkpoints at least.
Generally looks good. I was wondering whether we could use Flink's serialization instead of having |
|
||
this.lastOffsets = getRuntimeContext().getOperatorState("offset", defaultOffset); | ||
|
||
//TODO: commit fetched offset to ZK if not default |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can not merge the PR with this TODO open.
3392117
to
8306ddf
Compare
|
I could not fix the kafka test yet. Also I need to fix some tests hardcoded for the previous interfaces that have been added lately :p This will probably happen later this week. At some point i might ask for help for getting kafka to work. |
288ae6f
to
5767ae6
Compare
Some issues that we need to fix before merge: Committing the checkpoint doesnt work properly. We need to commit the states one by one and also pass the names for the state. Statehandles are not properly discarded. I need to add a wrapper statehandle that will discard the ones wrapped as well. |
Also we need to add the partitioning setting to the operators as it is currently not exposed through the API |
0fe84fd
to
450d5f5
Compare
Alright I think I fixed the issues, now the only thing remains is to add partitioning setting to the API. State partitioning should be a property of the operator therefore it should be set afterwards like parallelism. For example: stream.map(Mapper).setStatePartitioner(...) This is quite tricky however as the state partitioner should affect the partitioning scheme of the input streams (otherwise it makes no sense). I see two approaches here: 1. simply overwrite the partitioning without warning |
I vote for the second option, it is more clean and more inline with the current behavior of the API. |
public StateForTask getState(JobVertexID jobVertexID) | ||
{ | ||
if(vertexToState.containsKey(jobVertexID)) { | ||
return vertexToState.get(jobVertexID); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you can save one map lookup by calling get() immediately. It will return null on a missing key.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
Let's keep the current interfaces |
Thats's a good point Stephan, I fixed it. |
I still get these random KafkaITCase failures on travis. This might be a timeout issue of some sort, @rmetzger do you have any tips on debugging that? |
8c999ba
to
cc50603
Compare
Mh. Is it always the same test failing with the same message? |
* | ||
* It creates a new {@link KeyedDataStream} that uses the provided key for partitioning | ||
* its operator states. Mind that keyBy does not affect the partitioning of the {@link DataStream} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But it seems to affect the partitioning of the stream since the constructor of KeyedDataStream calls partitionByHash() on the DataStream. (This also applied to the other keyBy() methods)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
indeed. I removed that part from the javadoc
@senorcarbone You mentioned that the KeyedDataStream disallows calls to shuffle()/repartition()/groupBy() and so on. But KeyedDataStream doesn't seem to have this functionality, unless I'm mistaken. |
The setConnectionType method is overwritten which will actually make this happen |
Ahh I see, my bad. 😅 |
4d694af
to
a024a2e
Compare
Should we merge this? |
I think we have no real blocker here. I would prefer the exception issue could be addressed (message for wrapping exception). Everything else will probably show best when we implement sample jobs and sample backends for this new functionality. |
Okay I will fix the exceptions and will merge it afterwards |
4cf7971
to
ce4d2ff
Compare
… an operator + refactor
… rest of the refactoring Closes apache#747
Please create JIRAs for changes in the future. |
… rest of the refactoring Closes apache#747
… rest of the refactoring Closes apache#747
This PR contains the proposed changes for the streaming operator state interfaces as described in
https://docs.google.com/document/d/1nTn4Tpafsnt-TCT6L1vlHtGGgRevU90yRsUQEmkRMjk/edit?usp=sharing
Highlights: