标签：#bigquery

El 12 de junio de 2026, Google Cloud publicó el Open Knowledge Format (OKF) , una especificación abierta que intenta resolver un problema que suena aburrido pero es carísimo: cómo darle a un agente de IA el contexto que necesita para no inventar. La propuesta es tan simple que da un poco de desconfianza —una carpeta de archivos Markdown con un encabezado YAML— y esa simpleza es, al mismo tiempo, su mayor virtud y el blanco de todas las críticas. Vale la pena entender qué anuncian, porque detrás del formato aparentemente trivial hay una apuesta bastante ambiciosa sobre cómo van a compartir conocimiento las empresas en la era de los agentes. El problema: el conocimiento vive en silos En casi cualquier organización, lo que un modelo necesita saber está desparramado y encerrado en formatos incompatibles: catálogos de metadatos con APIs propietarias, wikis internas, comentarios de código, docstrings, celdas de notebooks y —el clásico— la cabeza de dos o tres ingenieros senior. Cuando un agente tiene que responder algo tan concreto como "¿cómo calculo los usuarios activos semanales a partir del stream de eventos?" , tiene que ensamblar la respuesta juntando pedacitos de superficies que no se hablan entre sí. El resultado: cada equipo que arma un agente resuelve el mismo rompecabezas desde cero, y el conocimiento queda preso del sistema que lo generó. No hay portabilidad. La propuesta: un formato, no una plataforma La respuesta de Google no es "otro servicio de conocimiento en la nube" —y ese es el punto que más recalcan—. Es un formato . OKF v0.1 representa el conocimiento como: Solo Markdown : legible en cualquier editor, renderizable en GitHub, indexable por cualquier buscador. Solo archivos : se transporta como un tarball, se hospeda en cualquier repo git, se monta en cualquier filesystem. Solo frontmatter YAML : campos consultables como type , title , description , resource , tags y timestamp . Cada "concepto" (una tabla, un dataset, una métrica, un runbook) es un arc

It's important to monitor Dataform - jobs executed by Dataform can be the primary source of BigQuery costs in a modern data platform. Forgetting to incrementalise a table, using a table instead of a view in the wrong place or performing complex window functions on a large table can all incur large costs and long run times. Using the WorkflowInvocationAction for each job we can extract its BigQuery Job ID, then extract key metadata for each BigQuery job by querying INFORMATION_SCHEMA.JOBS_BY_PROJECT , before writing the output back to BigQuery so that it can be analysed (maybe even by transforming it in Dataform). from google.cloud import dataform_v1 from google.cloud import bigquery from datetime import datetime # ------------------------------------------------------------ # CONFIG # ------------------------------------------------------------ PROJECT_ID = " my-project " REGION = " europe-west2 " REPOSITORY_ID = " analytics " WORKFLOW_INVOCATION_ID = " 123456789 " BQ_REGION = " region-europe-west2 " OUTPUT_TABLE = " my-project.raw_dataform_monitoring.raw_dataform_bigquery_metrics " # ------------------------------------------------------------ # CLIENTS # ------------------------------------------------------------ dataform = dataform_v1 . DataformClient () bq = bigquery . Client ( project = PROJECT_ID ) repository = dataform . repository_path ( PROJECT_ID , REGION , REPOSITORY_ID ) invocation_name = f " { repository } /workflowInvocations/ { WORKFLOW_INVOCATION_ID } " # ------------------------------------------------------------ # 1. GET WORKFLOW INVOCATION ACTIONS → EXTRACT JOB IDS # ------------------------------------------------------------ job_ids = set () actions = dataform . list_workflow_invocation_actions ( parent = invocation_name ) for action in actions : # only BigQuery actions contain job metadata if hasattr ( action , " bigquery_action " ) and action . bigquery_action : if action . bigquery_action . job_id : job_ids . add ( action . bigquery_action