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

Progress Bar Estimate #19814

Merged
merged 13 commits into from
Nov 29, 2022
Merged

Progress Bar Estimate #19814

merged 13 commits into from
Nov 29, 2022

Conversation

davinchia
Copy link
Contributor

@davinchia davinchia commented Nov 26, 2022

What

Implement estimate message processing allowing the platform to hold on to estimate message counts in memory.

image

The estimate message is protocol message connectors can choose to emit to provide support for progress bar calculations. There are two kinds of estimates, per-Sync or per-Stream. Sources cannot emit both types in a single sync.

Per-stream estimates are what we usually expect. Per-sync estimates are for sources that cannot provide more granular estimates for whatever reasons e.g. CDC sources.

In a follow up PR, the platform will periodically save these messages through the save stats api.

How

  • add getStreamToEstimatedRecords, getStreamToEstimatedBytes, getTotalRecordsEstimated and getTotalBytesEstimated to the MessageTracker interface.
  • implement the above methods.
  • add tests.

Also took the chance to clean up some of the testing code.

Recommended reading order

  1. MessageTracker.java and AirbyteMessageTracker.java for the interface changes.
  2. AirbyteMessageTrackerTest.java for tests.
  3. All other files.

🚨 User Impact 🚨

Are there any breaking changes? What is the end result perceived by the user? If yes, please merge this PR with the 🚨🚨 emoji so changelog authors can further highlight this if needed.

Pre-merge Checklist

Expand the relevant checklist and delete the others.

New Connector

Community member or Airbyter

  • Community member? Grant edit access to maintainers (instructions)
  • Secrets in the connector's spec are annotated with airbyte_secret
  • Unit & integration tests added and passing. Community members, please provide proof of success locally e.g: screenshot or copy-paste unit, integration, and acceptance test output. To run acceptance tests for a Python connector, follow instructions in the README. For java connectors run ./gradlew :airbyte-integrations:connectors:<name>:integrationTest.
  • Code reviews completed
  • Documentation updated
    • Connector's README.md
    • Connector's bootstrap.md. See description and examples
    • docs/integrations/<source or destination>/<name>.md including changelog. See changelog example
    • docs/integrations/README.md
    • airbyte-integrations/builds.md
  • PR name follows PR naming conventions

Airbyter

If this is a community PR, the Airbyte engineer reviewing this PR is responsible for the below items.

  • Create a non-forked branch based on this PR and test the below items on it
  • Build is successful
  • If new credentials are required for use in CI, add them to GSM. Instructions.
  • /test connector=connectors/<name> command is passing
  • New Connector version released on Dockerhub by running the /publish command described here
  • After the connector is published, connector added to connector index as described here
  • Seed specs have been re-generated by building the platform and committing the changes to the seed spec files, as described here
Updating a connector

Community member or Airbyter

  • Grant edit access to maintainers (instructions)
  • Secrets in the connector's spec are annotated with airbyte_secret
  • Unit & integration tests added and passing. Community members, please provide proof of success locally e.g: screenshot or copy-paste unit, integration, and acceptance test output. To run acceptance tests for a Python connector, follow instructions in the README. For java connectors run ./gradlew :airbyte-integrations:connectors:<name>:integrationTest.
  • Code reviews completed
  • Documentation updated
    • Connector's README.md
    • Connector's bootstrap.md. See description and examples
    • Changelog updated in docs/integrations/<source or destination>/<name>.md including changelog. See changelog example
  • PR name follows PR naming conventions

Airbyter

If this is a community PR, the Airbyte engineer reviewing this PR is responsible for the below items.

  • Create a non-forked branch based on this PR and test the below items on it
  • Build is successful
  • If new credentials are required for use in CI, add them to GSM. Instructions.
  • /test connector=connectors/<name> command is passing
  • New Connector version released on Dockerhub and connector version bumped by running the /publish command described here
Connector Generator
  • Issue acceptance criteria met
  • PR name follows PR naming conventions
  • If adding a new generator, add it to the list of scaffold modules being tested
  • The generator test modules (all connectors with -scaffold in their name) have been updated with the latest scaffold by running ./gradlew :airbyte-integrations:connector-templates:generator:testScaffoldTemplates then checking in your changes
  • Documentation which references the generator is updated as needed

Tests

Unit

Put your unit tests output here.

Integration

Put your integration tests output here.

Acceptance

Put your acceptance tests output here.

@octavia-squidington-iv octavia-squidington-iv added area/platform issues related to the platform area/worker Related to worker labels Nov 26, 2022
.withType(io.airbyte.protocol.models.AirbyteTraceMessage.Type.ERROR)
.withEmittedAt(emittedAt)
.withError(new AirbyteErrorTraceMessage().withMessage(message));
return createErrorTraceMessage(message, emittedAt, null);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

consolidate the various trace message creation into one function to avoid duplication.

@davinchia davinchia marked this pull request as ready for review November 26, 2022 18:55
@davinchia davinchia temporarily deployed to more-secrets November 26, 2022 18:58 Inactive
@davinchia davinchia temporarily deployed to more-secrets November 26, 2022 18:58 Inactive
@davinchia davinchia temporarily deployed to more-secrets November 26, 2022 19:10 Inactive
@davinchia davinchia temporarily deployed to more-secrets November 26, 2022 19:10 Inactive
@davinchia davinchia temporarily deployed to more-secrets November 28, 2022 19:56 Inactive
@davinchia davinchia temporarily deployed to more-secrets November 28, 2022 19:56 Inactive
@davinchia davinchia temporarily deployed to more-secrets November 28, 2022 20:05 Inactive
@davinchia davinchia temporarily deployed to more-secrets November 28, 2022 20:05 Inactive
@davinchia davinchia temporarily deployed to more-secrets November 28, 2022 20:57 Inactive
@davinchia davinchia temporarily deployed to more-secrets November 28, 2022 20:57 Inactive
@davinchia
Copy link
Contributor Author

I have updated the logic and tests to account for the difference between Stream and Sync estimates!

@davinchia davinchia temporarily deployed to more-secrets November 28, 2022 21:17 Inactive
@davinchia davinchia temporarily deployed to more-secrets November 28, 2022 21:17 Inactive
@davinchia davinchia temporarily deployed to more-secrets November 28, 2022 21:32 Inactive
@davinchia davinchia temporarily deployed to more-secrets November 28, 2022 21:34 Inactive
Copy link
Contributor

@gosusnp gosusnp left a comment

Choose a reason for hiding this comment

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

Looks good in principle, left some questions.

private final StateDeltaTracker stateDeltaTracker;
private final StateMetricsTracker stateMetricsTracker;
private final List<AirbyteTraceMessage> destinationErrorTraceMessages;
private final List<AirbyteTraceMessage> sourceErrorTraceMessages;
private final StateAggregator stateAggregator;
private final boolean logConnectorMessages = new EnvVariableFeatureFlags().logConnectorMessages();

// These variables support SYNC level estimates and are meant for sources where stream level
// estimates are not possible e.g. CDC sources.
private Long totalRecordsEstimatedSync;
Copy link
Contributor

Choose a reason for hiding this comment

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

Looks like we are adding a new concept of Sync vs Stream, instead, would it make sense to use STREAM vs GLOBAL?

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'm following from the AirbyteTraceEstimateMessage type. Slight preference to keep the names consistent though happy to change the name within this file to Global.

With the AirbyteTraceEstiamteMessage, I do think STREAM vs SYNC are decent names for now.

Copy link
Contributor

Choose a reason for hiding this comment

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

I am thinking about consistency for the near future, Sync feels very coupled to how we current run the replication. For STREAM, I think we want to modify our current replication model to be able to replicate data at stream level rather than connection. If we are running per stream replication in parallel, Sync mode for progress looks outdated.

It probably feels more like future-proofing, I don't have reasons to feel strongly either way at this moment.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Agree with your thoughts. Honestly, not 100% how the stream-as-first-class citizen refactor will play with CDC w.r.t the stats here.

In that case, I'm guessing we will be able to do away with the SYNC field. I'm inclined to keep this as is for now and revisit when we cross that. How does that sound?

Copy link
Contributor

Choose a reason for hiding this comment

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

Sounds good to me, conceptually, I think we are tracking the right way, we can address the naming later on.

@davinchia davinchia temporarily deployed to more-secrets November 29, 2022 00:11 Inactive
@davinchia davinchia temporarily deployed to more-secrets November 29, 2022 00:11 Inactive
@davinchia davinchia temporarily deployed to more-secrets November 29, 2022 00:30 Inactive
@davinchia davinchia temporarily deployed to more-secrets November 29, 2022 00:30 Inactive
@davinchia davinchia merged commit a1b9db5 into master Nov 29, 2022
@davinchia davinchia deleted the davinchia/progress-bar-estimate branch November 29, 2022 05:16
@davinchia davinchia mentioned this pull request Dec 1, 2022
37 tasks
davinchia added a commit that referenced this pull request Dec 3, 2022
Follow up from ##19814, where we introduced the StreamStats object to consolidate/simplify some of the stats memory objects.

In this PR, we extend the StreamStats object to also include the emitted records and bytes.

- Make StreamStats into a proper object. We cannot use a record as record fields are immutable. We need mutable fields to count.
- Consolidate the emitted records into StreamStats.
- Take the chance to move all the stats/metrics related classes into a book_keeping package to keep things clean.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/platform issues related to the platform area/worker Related to worker
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants