Add timestamp precision option to bigquery storage read for TIMESTAMP(12) columns.

[claudevdm]

Add read timestamp precision setting for storage api reads.

The storage API allows reading TIMESTAMP(12) columns with MICRO (default), NANOS or PICOS precision for both AVRO and ARROW formats.

This propagates the read precision setting to the storage API, and adds relevant tests.

Known Issue:
Arrow readTableRows and readTableRowsWithSchema converts arrow records to beam rows via ArrowConversion.java.

ArrowConversion is a generic utility for arrow -> beam schema, it does not take into account the bigquery schema.

Even before this PR, arrow format with readTableRows truncates timestamps to millisecond precision because millis and micro timestamps were historically mapped to FieldType.DATETIME

beam/sdks/java/extensions/arrow/src/main/java/org/apache/beam/sdk/extensions/arrow/ArrowConversion.java

Line 210 in 15b50e2

return FieldType.DATETIME;

For avro readTableRowsWithSchema this is not an issue because we can map timestamp-micros to timestamp logical type if the bigquery schema is TIMESTAMP(12) with read precision micros

beam/sdks/java/io/google-cloud-platform/src/main/java/org/apache/beam/sdk/io/gcp/bigquery/BigQueryUtils.java

Line 415 in 15b50e2

if ((schema.getTimestampPrecision() == null)

---

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

• Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
• 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.

To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI or the workflows README to see a list of phrases to trigger workflows.

[gemini-code-assist]

Summary of Changes

Hello @claudevdm, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the BigQueryIO connector by introducing explicit control over timestamp precision when reading data using the BigQuery Storage Read API. This allows users to specify whether TIMESTAMP(12) columns should be read with nanosecond or picosecond precision, ensuring data fidelity for high-precision timestamp values. The changes involve adding a new configuration option and integrating it into the BigQuery Storage API request generation, along with thorough testing to cover various data formats and precision levels.

Highlights

• Timestamp Precision Configuration: Introduced a new withTimestampPrecision option in BigQueryIO.TypedRead to allow users to specify the desired precision for TIMESTAMP(12) columns when reading via the BigQuery Storage Read API. This option supports nanosecond and picosecond precision.
• BigQuery Storage API Integration: Modified internal BigQuery Storage Source classes (BigQueryStorageQuerySource, BigQueryStorageTableSource, BigQueryStorageSourceBase) to propagate and apply the TimestampPrecision setting to the underlying BigQuery Storage Read Session requests.
• Serialization Options for Precision: The implementation now explicitly configures ArrowSerializationOptions and AvroSerializationOptions to request TIMESTAMP_PRECISION_NANOS or TIMESTAMP_PRECISION_PICOS from the BigQuery Storage API, ensuring that the specified precision is honored during data retrieval.
• Comprehensive Testing: Added extensive unit tests to validate the new TimestampPrecision functionality across different data formats (Avro, Arrow) and read methods (readTableRows, readTableRowsWithSchema), covering default, micros, nanos, and picos precision scenarios.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[claudevdm]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a new option to specify timestamp precision when reading from BigQuery using the Storage Read API. The changes are well-implemented across the relevant classes, and the addition of comprehensive tests is excellent. I have a couple of suggestions: one to correct the default value mentioned in a Javadoc, and another to refactor a new method to improve its structure and reduce code duplication.

[claudevdm]

R: @Abacn

[claudevdm]

R: @ahmedabu98

[github-actions]

Stopping reviewer notifications for this pull request: review requested by someone other than the bot, ceding control. If you'd like to restart, comment assign set of reviewers

[github-actions]

Stopping reviewer notifications for this pull request: review requested by someone other than the bot, ceding control. If you'd like to restart, comment assign set of reviewers

[damccorm]

/gemini review

[damccorm]

Mostly LGTM, just had a naming question

[gemini-code-assist]

Code Review

This pull request introduces a valuable feature for controlling timestamp precision during BigQuery storage reads for TIMESTAMP(12) columns. The implementation is well-structured, propagating the new option from the user-facing API down to the storage read session creation. The accompanying tests are comprehensive and cover a wide range of scenarios. I've identified one critical issue regarding serialization that could break portability, along with a few medium-severity suggestions to improve code robustness and maintainability. Overall, this is a solid contribution.