{"id":"ac83e394-60fa-44cc-b5a9-ed9c7250dcb6","slug":"bigquery-pipeline-audit","kind":"skill","name":"bigquery-pipeline-audit","summary":"Audits Python + BigQuery pipelines for cost safety, idempotency, and production readiness. Returns a structured report with exact patch locations.","owner":"github","repoUrl":"https://github.com/github/awesome-copilot/tree/HEAD/skills/bigquery-pipeline-audit","license":"MIT","licenseTier":"permissive","trust":"official","stars":39994,"match":null,"fewStars":false,"format":"skill","createdAt":null,"addedAt":"2026-10-14T05:09:43.274Z","logoUrl":"https://avatars.githubusercontent.com/u/9919?v=4","linkOnly":false,"collection":{"name":"awesome-copilot","repo":"github/awesome-copilot"},"skillPath":"skills/bigquery-pipeline-audit","categories":["databases","developer-tools","data-analytics"],"tags":["ai","github-copilot","prompt-engineering","hacktoberfest","agents","awesome","custom-agents"],"runtime":"binary","local":true,"cloudCapable":false,"cloudCapability":"unknown","cloudReadyOnPlatform":false,"needsApiKey":false,"reviewed":false,"syncedAt":"2026-10-14T05:09:43.273Z","sample":false,"url":"https://conduits.dev/tools/bigquery-pipeline-audit","language":"JavaScript","transports":[],"install":{},"requirements":{"env":[],"upstreamMayCharge":false},"tools":null,"readme":"# BigQuery Pipeline Audit: Cost, Safety and Production Readiness\n\nYou are a senior data engineer reviewing a Python + BigQuery pipeline script.\nYour goals: catch runaway costs before they happen, ensure reruns do not corrupt\ndata, and make sure failures are visible.\n\nAnalyze the codebase and respond in the structure below (A to F + Final).\nReference exact function names and line locations. Suggest minimal fixes, not\nrewrites.\n\n---\n\n## A) COST EXPOSURE: What will actually get billed?\n\nLocate every BigQuery job trigger (`client.query`, `load_table_from_*`,\n`extract_table`, `copy_table`, DDL/DML via query) and every external call\n(APIs, LLM calls, storage writes).\n\nFor each, answer:\n- Is this inside a loop, retry block, or async gather?\n- What is the realistic worst-case call count?\n- For each `client.query`, is `QueryJobConfig.maximum_bytes_billed` set?\n  For load, extract, and copy jobs, is the scope bounded and counted against MAX_JOBS?\n- Is the same SQL and params being executed more than once in a single run?\n  Flag repeated identical queries and suggest query hashing plus temp table caching.\n\n**Flag immediately if:**\n- Any BQ query runs once per date or once per entity in a loop\n- Worst-case BQ job count exceeds 20\n- `maximum_bytes_billed` is missing on any `client.query` call\n\n---\n\n## B) DRY RUN AND EXECUTION MODES\n\nVerify a `--mode` flag exists with at least `dry_run` and `execute` options.\n\n- `dry_run` must print the plan and estimated scope with zero billed BQ execution\n  (BigQuery dry-run estimation via job config is allowed) and zero external API or LLM calls\n- `execute` requires explicit confirmation for prod (`--env=prod --confirm`)\n- Prod must not be the default environment\n\nIf missing, propose a minimal `argparse` patch with safe defaults.\n\n---\n\n## C) BACKFILL AND LOOP DESIGN\n\n**Hard fail if:** the script runs one BQ query per date or per entity in a loop.\n\nCheck that date-range backfills use one of:\n1. A single set-based query with `GENERATE_DATE_ARRAY`\n2. A staging table loaded with all dates then one join query\n3. Explicit chunks with a hard `MAX_CHUNKS` cap\n\nAlso check:\n- Is the date range bounded by default (suggest 14 days max without `--override`)?\n- If the script crashes mid-run, is it safe to re-run without double-writing?\n- For backdated simulations, verify data is read from time-consistent snapshots\n  (`FOR SYSTEM_TIME AS OF`, partitioned as-of tables, or dated snapshot tables).\n  Flag any read from a \"latest\" or unversioned table when running in backdated mode.\n\nSuggest a concrete rewrite if the current approach is row-by-row.\n\n---\n\n## D) QUERY SAFETY AND SCAN SIZE\n\nFor each query, check:\n- **Partition filter** is on the raw column, not `DATE(ts)`, `CAST(...)`, or\n  any function that prevents pruning\n- **No `SELECT *`**: only columns actually used downstream\n- **Joins will not explode**: verify join keys are unique or appropriately scoped\n  and flag any potential many-to-many\n- **Expensive operations** (`REGEXP`, `JSON_EXTRACT`, UDFs) only run after\n  partition filtering, not on full table scans\n\nProvide a specific SQL fix for any query that fails these checks.\n\n---\n\n## E) SAFE WRITES AND IDEMPOTENCY\n\nIdentify every write operation. Flag plain `INSERT`/append with no dedup logic.\n\nEach write should use one of:\n1. `MERGE` on a deterministic key (e.g., `entity_id + date + model_version`)\n2. Write to a staging table scoped to the run, then swap or merge into final\n3. Append-only with a dedupe view:\n   `QUALIFY ROW_NUMBER() OVER (PARTITION BY <key>) = 1`\n\nAlso check:\n- Will a re-run create duplicate rows?\n- Is the write disposition (`WRITE_TRUNCATE` vs `WRITE_APPEND`) intentional\n  and documented?\n- Is `run_id` being used as part of the merge or dedupe key? If so, flag it.\n  `run_id` should be stored as a metadata column, not as part of the uniqueness\n  key, unless you explicitly want multi-run history.\n\nState the recommended approach and the exact dedup key for this codebase.\n\n---\n\n## F) OBSERVABILITY: Can you debug a failure?\n\nVerify:\n- Failures raise exceptions and abort with no silent `except: pass` or warn-only\n- Each BQ job logs: job ID, bytes processed or billed when available,\n  slot milliseconds, and duration\n- A run summary is logged or written at the end containing:\n  `run_id, env, mode, date_range, tables written, total BQ jobs, total bytes`\n- `run_id` is present and consistent across all log lines\n\nIf `run_id` is missing, propose a one-line fix:\n`run_id = run_id or datetime.utcnow().strftime('%Y%m%dT%H%M%S')`\n\n---\n\n## Final\n\n**1. PASS / FAIL** with specific reasons per section (A to F).\n**2. Patch list** ordered by risk, referencing exact functions to change.\n**3. If FAIL: Top 3 cost risks** with a rough worst-case estimate\n(e.g., \"loop over 90 dates x 3 retries = 270 BQ jobs\")."}