[Bug]: BigQueryIO taking a long time to initialize when using STORAGE_API_WRITE_INCONSISTENT with CREATE_IF_NEEDED and many tables

[reuvenlax]

What happened?

With STORAGE_API_WRITE_INCONSISTENT every table is written from every worker. The current implementation of CREATE_IF_NEEDED uses GetTable to determine if a table doesn't exist, however GetTable has a default quota of 100 QPS. If writing to 1000 tables on 360 workers, it will take an hour just for all the workers to determine whether the tables exist!

Suggested fix: instead of preemptively checking the table, we should go ahead with the normal Storage API write stream calls and detect errors that indicate the table doesn't exist.

Issue Priority

Priority: 2 (default / most bugs should be filed as P2)

Issue Components

• Component: Python SDK
• Component: Java SDK
• Component: Go SDK
• Component: Typescript SDK
• Component: IO connector
• Component: Beam examples
• Component: Beam playground
• Component: Beam katas
• Component: Website
• Component: Spark Runner
• Component: Flink Runner
• Component: Samza Runner
• Component: Twister2 Runner
• Component: Hazelcast Jet Runner
• Component: Google Cloud Dataflow Runner

[damccorm]

Per my comment here #25113 (comment) I don't think this is a release blocker so I'm going to remove the milestone in preparation for the cut next Wednesday. If you disagree, please readd the blocker and we can discuss

[kennknowles]

@reuvenlax @Abacn is this expected to be resolved by the associated pull requests? do we have reliable reproduction and proof of resolution?

[Abacn]

From #25113 this is fixed

note - the associated test has observed flaky: #27314 - though appeared to be infrequent