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-4374] Shortids for the Go SDK #11231

Merged
merged 3 commits into from
Mar 30, 2020
Merged

[BEAM-4374] Shortids for the Go SDK #11231

merged 3 commits into from
Mar 30, 2020

Conversation

lostluck
Copy link
Contributor

A quick unblocker for current proto changes. Adds Short ID handling for the Go SDK.

There are likely some performance improvements that can go in around the single lock, either moving them to a RW lock or a sync.Map, but this should be fine for Batch cases at present, until we measure differently.


Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

  • Choose reviewer(s) and mention them in a comment (R: @username).
  • 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.
  • Update CHANGES.md with noteworthy changes.
  • If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

Post-Commit Tests Status (on master branch)

Lang SDK Apex Dataflow Flink Gearpump Samza Spark
Go Build Status --- --- Build Status --- --- Build Status
Java Build Status Build Status Build Status
Build Status
Build Status
Build Status
Build Status
Build Status Build Status Build Status
Build Status
Build Status
Python Build Status
Build Status
Build Status
Build Status
--- Build Status
Build Status
Build Status
Build Status
Build Status
--- --- Build Status
XLang --- --- --- Build Status --- --- Build Status

Pre-Commit Tests Status (on master branch)

--- Java Python Go Website
Non-portable Build Status Build Status
Build Status
Build Status Build Status
Portable --- Build Status --- ---

See .test-infra/jenkins/README for trigger phrase, status and link of all Jenkins jobs.

@lostluck
Copy link
Contributor Author

Run Go Postcommit

@lostluck
Copy link
Contributor Author

R: @lukecwik

@lostluck
Copy link
Contributor Author

This code drifts slightly from #11184, which removes the OneOf in favour of always using the payload format. This version still uses the oneof, but only populates payload.

// sync.Map might have lower contention for this read heavy load.
var (
shortMu sync.Mutex
labels2ShortIds map[metrics.Labels]string
Copy link
Member

Choose a reason for hiding this comment

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

This won't be enough as the key. There are things that have the same labels but different URNs, e.g start/process/finish msecs

I would suggest using the MonitoringInfo with the payload field "blanked" as the key of the map.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah good to know. Thanks!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah good point.
Can't use protos as Go Map keys, because of all the magic fields they have, but I can use other things.

I've put in aligned constants, types, and string arrays for the proto specified strings, so these lookups don't end up hashing the strings every time (and instead use a uint32, which is very fast for go maps to deal with.) There's still the hashing of the fields in metrics.Labels, but we can do the same hashing in the metrics code at a later time, to allow for faster lookups for those instead.

@lostluck
Copy link
Contributor Author

A rather large refactoring occurred. For one, I wasn't initializing the maps properly which correctly caused postcommit failures.

Now I've moved that verification to tests, and made the cache easier to test.

@lostluck
Copy link
Contributor Author

Run Go Postcommit

@lostluck
Copy link
Contributor Author

Just as a note, I'll wait until #11184 is in, and resolve the merge conflicts on my end before we merge this one.


// TODO: Pull these from the protos.
var sUrns = []string{
"beam:metric:user:v1",
Copy link
Member

Choose a reason for hiding this comment

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

heads up that this has now been exploded so that each MonitoringInfoSpec has a unique urn meaning that you'll see:
beam:metric:user:sum_int64:v1, beam:metric:user:sum_double:v1, ...

"TestingSentinelType", // Must remain last.
}

const (
Copy link
Member

Choose a reason for hiding this comment

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

Since the urns uniquely identify the type now, you don't need this anymore and a monitoring info is uniquely described by urn + labels.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ack. I've kept the extra marker type around for the moment, but I might collapse things into the function to simplify some thing.

}{
{
id: "1",
urn: urnUser,
Copy link
Member

Choose a reason for hiding this comment

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

Can you add the case where the same urn but unique labels are used gets a different short id?

@lostluck
Copy link
Contributor Author

Run Go Postcommit

@lostluck
Copy link
Contributor Author

Run Go Postcommit

@lostluck
Copy link
Contributor Author

R: @youngoli @lukecwik

I can't wait to get rid of both of the legacy stuff and the older monitoring info listing. That function is becoming crufty.

@lukecwik lukecwik merged commit 65c8426 into apache:master Mar 30, 2020
@lostluck lostluck deleted the shortids branch March 30, 2020 21:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants