Skip to content
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

[BEAM-4130] Add job submission capabilities to Flink runner. #5493

Merged
merged 6 commits into from
Jun 14, 2018

Conversation

robertwb
Copy link
Contributor

@robertwb robertwb commented May 26, 2018

This is a rebase of the submission service in the hacking branch, updated to reflect the new state of artifact staging.


Follow this checklist to help us incorporate your contribution quickly and easily:

  • Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
  • If this contribution is large, please file an Apache Individual Contributor License Agreement.

It will help us expedite review of your Pull Request if you tag someone (e.g. @username) to look at it.

@robertwb robertwb force-pushed the flink-job-merge branch 4 times, most recently from f819d57 to 421b31f Compare June 13, 2018 16:50
@robertwb robertwb changed the title Add job submission capabilities to Flink runner. [BEAM-4130] Add job submission capabilities to Flink runner. Jun 13, 2018
@robertwb
Copy link
Contributor Author

R: @axelmagn, @angoenka Please take a look.

Copy link
Contributor

@axelmagn axelmagn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!


public static InMemoryJobService create(
Endpoints.ApiServiceDescriptor stagingServiceDescriptor,
Function<String, String> stagingServiceTokenProvider,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe document that this function expects a preparation ID as input.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point.

Copy link
Contributor

@angoenka angoenka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

}

private PipelineResult runPipeline() throws Exception {
LOG.trace("Translating pipeline from proto");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This trace is unnecessary

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.


LOG.info("Translating pipeline to Flink program.");
// Fused pipeline proto.
RunnerApi.Pipeline fusedPipeline = GreedyPipelineFuser.fuse(pipeline).toPipeline();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we pass the fuser Function in constructor parameter?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Until we want/have more than one fuser, I think it's better to leave it internal for now.

// batch translation
FlinkBatchPortablePipelineTranslator translator =
FlinkBatchPortablePipelineTranslator.createTranslator();
FlinkBatchPortablePipelineTranslator.BatchTranslationContext context =
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we only create the context in the if-else block and do the remaining things outside?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually wanted to do this, but the problem is that the (Flink-defined) streaming/batch execution environments don't share any common baseclass.

synchronized (this) {
setState(Enum.STARTING);
invocationFuture = executorService.submit(this::runPipeline);
setState(Enum.RUNNING);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should set the Status to running once we have submit to flink.
Should we set the status to running in runPipeline?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could defer it until after the pipeline translation, but that doesn't seem to be a significant difference, and it's cleaner to have all the state transitions locally here. I added a TODO to actually do this right (which we can't do from runPipeline alone).

new FutureCallback<PipelineResult>() {
@Override
public void onSuccess(
@Nullable PipelineResult pipelineResult) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should check the pipeline.getState to make sure pipeline was successfully done.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

return new FlinkJobServerDriver(configuration, executor, serverFactory);
}

private final ListeningExecutorService executor;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should move these variables to the top.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

ArtifactApi.ProxyManifest.Builder builder = ArtifactApi.ProxyManifest.newBuilder();
JsonFormat.parser().merge(Channels.newReader(
FileSystems.open(FileSystems.matchNewResource(retrievalToken, false /* is directory */)),
StandardCharsets.UTF_8.name()), builder);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shall we standardize the characterset for all BeamFileSystemArtifact**** ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, just like we're standardizing on Json (and Json is always supposed to be UTF-8.)

@@ -60,17 +60,36 @@

public static InMemoryJobService create(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we remove this method?

}
});

return stagingTokenHolder[0];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should wait for the commit call to finish before returning.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a direct call, nothing asynchronous to wait on.

@Override public void onCompleted() {
}
});
return contents.toString();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should wait for the call to finish before returning the contents.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same.

@angoenka
Copy link
Contributor

LGTM
Please make sure that the checks are green.

@angoenka
Copy link
Contributor

@robertwb Based on the discussion in the chat thread, should we remove BeamFileSystemArtifactSource as ArtifactRetrivalService is meant to do the same job.
If you want we can keep it as it is as I can clean it up when I go about removing ArtifactSource interface.

robertwb and others added 6 commits June 14, 2018 14:20
This implements job invocation wrappers for the Flink runner, as well as
a standalone driver for a JobService daemon.  Together these complete
the job submission story for the portability framework on the Flink
runner.
@robertwb
Copy link
Contributor Author

It's just hitting org.apache.beam.runners.direct.portable.ReferenceRunnerTest.pipelineExecution which is unrelated and flaky in head too.

@angoenka
Copy link
Contributor

In that case we can go ahead with the merge.

@robertwb robertwb merged commit 01e9213 into apache:master Jun 14, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants