Introducción a la carga de datos

En este documento, se proporciona una descripción general de la carga de datos en BigQuery.

Métodos de carga de datos

Puedes cargar (o transferir) datos a BigQuery de varias maneras:

  • Carga por lotes un conjunto de registros de datos.
  • Transmite registros individuales o lotes de registros.
  • Usa consultas para generar datos nuevos y anexar o reemplazar los resultados en una tabla.
  • Usa una aplicación o un servicio de terceros.

Carga por lotes

Con la carga por lotes, debes cargar los datos de origen en una tabla de BigQuery en una sola operación por lotes. Por ejemplo, la fuente de datos puede ser un archivo CSV, una base de datos externa o un conjunto de archivos de registro. Los trabajos de extracción, transformación y carga (ETL) tradicionales se clasifican en esta categoría.

Las opciones para la carga por lotes en BigQuery incluyen las siguientes opciones:

  • Trabajos de carga. Carga datos desde Cloud Storage o desde un archivo local mediante la creación de un trabajo de carga. Los registros pueden estar en formato Avro, CSV, JSON, ORC o Parquet.
  • SQL. La instrucción de SQL LOAD DATA carga datos de uno o más archivos en una tabla nueva o existente. Puedes usar la instrucción LOAD DATA para cargar archivos Avro, CSV, JSON, ORC o Parquet.
  • Servicio de transferencia de datos de BigQuery. Usa el Servicio de transferencia de datos de BigQuery para automatizar la carga de datos desde aplicaciones de software de Google como servicio (SaaS) o aplicaciones y servicios de terceros.
  • API de BigQuery Storage Write. La API de Storage Write te permite procesar por lotes una cantidad arbitraria de registros y confirmarlos en una sola operación atómica. Si la operación de confirmación falla, puedes reintentar la operación de forma segura. A diferencia de los trabajos de carga de BigQuery, la API de Storage Write no requiere que los datos se almacenen en etapa intermedia para el almacenamiento intermedio, como Cloud Storage.
  • Otros servicios administrados. Usa otros servicios administrados para exportar datos desde un almacén de datos externo y, luego, importarlos a BigQuery. Por ejemplo, puedes cargar datos desde exportaciones de Firestore.

Cuando eliges un método de carga por lotes, la mayoría de los patrones basados en archivos deben usar un trabajo de carga o una instrucción de SQL LOAD DATA para cargar datos por lotes. Por lo general, otros servicios deben usar el Servicio de transferencia de datos de BigQuery o exportar datos desde los servicios de Google.

La carga por lotes se puede realizar como una operación única o según una programación recurrente. Por ejemplo, puedes hacer lo siguiente:

  • Puedes ejecutar transferencias del Servicio de transferencia de datos de BigQuery de forma programada.
  • Puedes usar un servicio de organización, como Cloud Composer, para programar trabajos de carga.
  • Puedes usar un trabajo cron para cargar datos de forma programada.

Transmisión

Con la transmisión, envías de forma continua lotes de datos más pequeños en tiempo real, de modo que los datos estén disponibles para consultas a medida que llegan. Las opciones de transmisión en BigQuery incluyen las siguientes:

  • API de Storage Write. La API de Storage Write admite la transferencia de transmisión de alta capacidad de procesamiento con semántica de entrega del tipo “exactamente una vez”.
  • Dataflow. Usa Dataflow con el SDK de Apache Beam para configurar una canalización de transmisión que escriba en BigQuery. Para obtener más información, consulta Conector de E/S de BigQuery en la documentación de Apache Beam y el instructivo Transmite de Pub/Sub a BigQuery.
  • Datastream. Datastream usa la funcionalidad de captura de datos modificados de BigQuery y la API de Storage Write para replicar los datos y las actualizaciones del esquema desde las bases de datos operativas directamente en BigQuery. Sigue esta guía de inicio rápido para ver un ejemplo de replicación desde una base de datos de Cloud SQL para PostgreSQL en BigQuery.
  • Conector de BigQuery para SAP El conector de BigQuery para SAP permite la replicación casi en tiempo real de los datos de SAP directamente en BigQuery. Si deseas obtener más información, consulta la guía de planificación de BigQuery Connector para SAP.
  • Pub/Sub. Pub/Sub es un servicio de mensajería que puedes usar para coordinar análisis de transmisiones y canalizaciones de integración de datos. Puedes usar las suscripciones a BigQuery para escribir mensajes directamente en una tabla de BigQuery existente.

Datos generados

Puedes usar SQL para generar datos y almacenar los resultados en BigQuery. Estas son algunas opciones para generar datos:

  • Usa declaraciones de lenguaje de manipulación de datos (DML) para realizar inserciones masivas en una tabla existente o almacenar los resultados de la consulta en una tabla nueva.

  • Usa una declaración CREATE TABLE ... AS para crear una tabla nueva a partir de un resultado de consulta.

  • Ejecuta una consulta y guarda los resultados en una tabla. Puedes agregar los resultados a una tabla existente o escribir en una tabla nueva. Para obtener más información, consulta Escribe resultados de consultas.

Aplicaciones de terceros

Algunas aplicaciones y servicios de terceros proporcionan conectores que pueden transferir datos a BigQuery. Los detalles de cómo configurar y administrar la canalización de transferencia dependen de la aplicación. Por ejemplo, para cargar datos de fuentes externas al almacenamiento de BigQuery, se puede usar el Cargador de datos de Informatica o las Canalizaciones de datos de Fivetran. Para obtener más información, consulta Carga datos con una aplicación de terceros.

Elige un método de transferencia de datos

Estas son algunas consideraciones que debes tener en cuenta cuando eliges un método de transferencia de datos.

Fuente de datos. La fuente de datos o el formato de datos puede determinar si la carga o transmisión por lotes es más fácil de implementar y mantener. Considera los puntos siguientes:

  • Si el Servicio de transferencia de datos de BigQuery admite la fuente de datos, la transferencia directa de datos a BigQuery puede ser la solución más simple de implementar.

  • Para obtener datos de fuentes de terceros que no son compatibles con el Servicio de transferencia de datos de BigQuery, transforma los datos en un formato compatible con la carga por lotes y usa ese método en su lugar.

  • Si tus datos provienen de Spark o Hadoop, considera usar conectores de BigQuery para simplificar la transferencia de datos.

  • En el caso de los archivos locales, considera cargar los lotes, en especial si BigQuery admite el formato de archivo sin requerir una etapa de transformación o limpieza de datos.

  • Para los datos de aplicación, como eventos de aplicación o una transmisión de registro, puede ser más fácil transmitir los datos en tiempo real, en lugar de implementar la carga por lotes.

Datos que cambian con lentitud en comparación con los datos que cambian con rapidez. Si necesitas transferir y analizar datos casi en tiempo real, considera transmitir los datos. Con la transmisión, los datos están disponibles para consultas en cuanto llega cada registro. Evita usar declaraciones DML para enviar grandes cantidades de actualizaciones o inserciones de filas individuales. En el caso de los datos actualizados con frecuencia, suele ser mejor transmitir un registro de cambios y usar una vista para obtener los resultados más recientes. Otra opción es usar Cloud SQL como base de datos de procesamiento de transacciones en línea (OLTP) y usar consultas federadas para unir los datos en BigQuery.

Si los datos de origen cambian con lentitud o no necesitas resultados actualizados continuamente, considera usar un trabajo de carga. Por ejemplo, si usas los datos para ejecutar un informe diario o por hora, los trabajos de carga pueden ser menos costosos y pueden usar menos recursos del sistema.

Otra situación es la información que llega con poca frecuencia o como respuesta a un evento. En ese caso, considera usar Dataflow para transmitir los datos o usar funciones de Cloud Run para llamar a la API de transmisión en respuesta a un activador.

Confiabilidad de la solución. BigQuery tiene un Acuerdo de Nivel de Servicio (ANS). Sin embargo, también debes considerar la confiabilidad de la solución específica que implementas. Considera los puntos siguientes:

  • Con formatos de tipo poco general, como JSON o CSV, los datos incorrectos pueden hacer que un trabajo de carga completo falle. Considera si necesitas un paso de limpieza de datos antes de la carga y considera cómo responder a los errores. También considera usar un formato con tipo fuerte, como Avro, ORC o Parquet.
  • Los trabajos de carga periódicos requieren la programación, mediante Cloud Composer, cron o alguna otra herramienta. El componente de programación podría ser un punto de falla en la solución.
  • Con la transmisión, puedes verificar el éxito de cada registro y, luego, informar un error rápidamente. Considera escribir mensajes con errores en una cola de mensajes sin procesar para un análisis y un procesamiento posteriores. Para obtener más información sobre los errores de transmisión de BigQuery, consulta Solución de problemas de inserción de transmisión.
  • Los trabajos de transmisión y de carga están sujetos a cuotas. Si deseas obtener más información para manejar los errores de cuota, consulta Soluciona errores de la cuota de BigQuery.
  • Las soluciones de terceros pueden diferir de la configuración, confiabilidad, garantías de orden y otros factores, por lo que debes considerarlas antes de adoptar una solución.

Latencia. Considera cuántos datos cargas y qué tan pronto necesitas que los datos estén disponibles. Streaming ofrece la menor latencia de datos disponibles para el análisis. Los trabajos de carga recurrentes tienen una latencia más alta, porque los datos nuevos solo están disponibles una vez que finaliza cada trabajo de carga.

Los trabajos de carga usan un grupo compartido de ranuras de forma predeterminada. Un trabajo de carga puede esperar en un estado pendiente hasta que haya ranuras disponibles, en especial si cargas una gran cantidad de datos. Si se crean tiempos de espera inaceptables, puedes comprar ranuras dedicadas, en lugar de usar el grupo de ranuras compartidas. Para obtener más información, consulta Introducción a Reservations.

El rendimiento de las consultas de las fuentes de datos externas puede no ser tan alto como el rendimiento de las consultas para los datos almacenados en BigQuery. Si es importante minimizar la latencia de la consulta, te recomendamos cargar los datos en BigQuery.

Formato de transferencia de datos. Elige un formato de transferencia de datos en función de los siguientes factores:

  • Compatibilidad con el esquema. Las exportaciones de Avro, ORC, Parquet y Firestore son formatos autodescriptivos. BigQuery crea el esquema de tabla de forma automática en función de los datos de origen. Para los datos JSON y CSV, puedes proporcionar un esquema explícito o puedes usar la detección automática de esquemas.

  • Datos planos o campos repetidos y anidados. Avro, CSV, JSON, ORC y Parquet admiten datos planos. Las exportaciones de Avro, JSON, ORC, Parquet y Firestore también admiten datos con campos repetidos y anidados. Los datos anidados o repetidos son útiles para expresar datos jerárquicos. Los campos anidados y repetidos también reducen la duplicación de datos cuando se cargan los datos.

  • Saltos de líneas incorporados Cuando cargues datos desde archivos JSON, las filas deben estar delimitadas por saltos de líneas. BigQuery requiere que los archivos JSON delimitados por saltos de líneas contengan un solo registro por línea.

  • Codificación BigQuery es compatible con la codificación UTF-8 para datos anidados o repetidos, y planos. BigQuery es compatible con la codificación ISO-8859-1 para datos planos solo con archivos CSV.

Carga datos anidados y repetidos

Puedes cargar datos en campos anidados y repetidos en los siguientes formatos de datos:

  • Avro
  • JSON (delimitado por saltos de línea)
  • ORC
  • Parquet
  • Exportaciones de Datastore
  • Exportaciones de Firestore

Para obtener más información sobre cómo especificar campos anidados y repetidos en un esquema cuando cargas datos, consulta Especifica campos anidados y repetidos.

Carga datos desde otros servicios de Google

Algunos servicios de Google exportan datos a BigQuery mediante consultas, exportaciones o transferencias programadas. Para obtener más información sobre los servicios que admiten exportaciones a BigQuery, consulta Carga datos desde servicios de Google.

Otros servicios de Google son compatibles con las exportaciones de datos iniciadas desde el Servicio de transferencia de datos de BigQuery. Para obtener más información sobre los servicios que admiten las exportaciones que inicia el Servicio de transferencia de datos de BigQuery, consulta Servicio de transferencia de datos de BigQuery.

Cuotas

Para obtener información sobre las cuotas, consulta las siguientes secciones:

Alternativas a la carga de datos

En las siguientes situaciones, no es necesario que cargues datos antes de que ejecutes las consultas:

Conjuntos de datos públicos
Los conjuntos de datos públicos son conjuntos que se almacenan en BigQuery y se comparten con el público. Si quieres obtener más información, consulta la página sobre los conjuntos de datos públicos de BigQuery.
Conjuntos de datos compartidos
Puedes compartir conjuntos de datos almacenados en BigQuery. Si alguien compartió un conjunto de datos contigo, puedes realizar consultas en él sin necesidad de cargar los datos.
Fuentes de datos externas
BigQuery también puede ejecutar consultas en ciertos tipos de datos externos sin cargar los datos en el almacenamiento de BigQuery. Este enfoque te permite aprovechar las capacidades analíticas de BigQuery sin mover datos que se almacenan en otra parte. Si deseas obtener información acerca de los beneficios y limitaciones de este enfoque, consulta Introducción a las fuentes de datos externas.
Archivos de registro
Cloud Logging proporciona una opción para exportar archivos de registro en BigQuery. Consulta Configura y administra receptores para obtener más información.

Supervisa el uso de trabajos de carga

Puedes supervisar el uso de los trabajos de carga de las siguientes dos maneras:

  • Usa Cloud Monitoring. Para obtener más información, consulta Métricas de BigQuery. Específicamente, puedes supervisar la cantidad de datos y de filas que se suben a una tabla específica. Si tus trabajos de carga suben datos a una tabla específica, esto puede ser un proxy para supervisar el uso de datos de carga de trabajos.

  • Usa INFORMATION_SCHEMA.JOBS_BY_PROJECT. Puedes usar la vista INFORMATION_SCHEMA.JOBS_BY_PROJECT para obtener la cantidad de trabajos de carga por tabla por día.

Ejemplo de caso de uso

En los siguientes ejemplos, se explica qué métodos se deben usar en función de tu caso de uso y cómo usarlos con otras soluciones de análisis de datos.

Transmite datos con la API de Storage Write

Supongamos que hay una canalización que procesa datos de eventos de registros de extremos. Los eventos se generan de forma continua y deben estar disponibles para realizar consultas en BigQuery lo antes posible. Dado que la actualidad de los datos es fundamental para este caso de uso, la API de Storage Write es la mejor opción para transferir datos a BigQuery. Una arquitectura recomendada para mantener estos extremos eficientes es enviar eventos a Pub/Sub, desde donde los consume una canalización de Dataflow de transmisión que se transmite de forma directa a BigQuery.

Una preocupación principal de confiabilidad de esta arquitectura es cómo lidiar con el fallo de insertar un registro en BigQuery. Si cada registro es importante y no se puede perder, los datos se deben almacenar en búfer antes de intentar insertarlos. En la arquitectura recomendada anterior, Pub/Sub puede desempeñar la función de un búfer con sus capacidades de retención de mensajes. La canalización de Dataflow debe estar configurada para reintentar las inserciones de transmisión de BigQuery con una retirada exponencial truncada. Después de que se agota la capacidad de Pub/Sub como un búfer, por ejemplo, en el caso de una falta de disponibilidad prolongada de BigQuery o de una falla de la red, los datos se deben conservar en el cliente y el cliente necesita un mecanismo para reanudar la inserción de registros persistentes una vez que se restablece la disponibilidad. Para obtener más información sobre cómo manejar esta situación, consulta la entrada de blog de la Guía de confiabilidad de Google Pub/Sub.

Otro caso de falla que se debe controlar es el de un registro tóxico. Un registro tóxico es un registro que BigQuery rechazó porque no se puede insertar con un error que no se puede reintentar o un registro que no se insertó de forma correcta después de la cantidad máxima de reintentos. Ambos tipos de registros se deben almacenar en una “cola de mensajes no entregados” a través de la canalización de Dataflow para una investigación más detallada.

Si se requiere una semántica de una y solo una vez, crea una transmisión de escritura en tipo confirmado, con compensaciones de registros proporcionadas por el cliente. Esto evita los duplicados, ya que la operación de escritura solo se realiza si el valor de desplazamiento coincide con el desplazamiento de anexo siguiente. Si no se proporciona un desplazamiento, se agregan los registros al extremo actual de la transmisión y, si se reintenta una operación fallida, es posible que el registro aparezca más de una vez en la transmisión.

Si no se requieren garantías de una sola vez, escribir en la transmisión predeterminada permite una capacidad de procesamiento mayor y no se considera en el límite de cuota sobre la creación de transmisiones de escritura.

Estima la capacidad de procesamiento de tu red y asegúrate con anticipación de que tengas una cuota adecuada para entregar la capacidad de procesamiento.

Si tu carga de trabajo genera o procesa datos a una tasa muy desigual, intenta disminuir los picos de carga en el cliente y transmitir a BigQuery con una capacidad de procesamiento constante. Esto puede simplificar la planificación de capacidad. Si eso no es posible, asegúrate de estar preparado para controlar errores 429 (recursos agotados) en caso de que tu capacidad de procesamiento supere la cuota durante aumentos cortos.

Procesamiento de datos por lotes

Supongamos que hay una canalización de procesamiento por lotes nocturna que se debe completar antes de una fecha límite fija. Los datos deben estar disponibles para este plazo a fin de que otro proceso por lotes los procese de modo que genere informes para enviarlos a un regulador. Este caso de uso es común en sectores regulados, como las finanzas.

La carga por lotes de datos con trabajos de carga es el enfoque correcto para este caso de uso, ya que la latencia no es una preocupación, siempre que se cumpla el plazo. Asegúrate de que tus buckets de Cloud Storage cumplan con los requisitos de ubicación para cargar datos en el conjunto de datos de BigQuery.

El resultado de un trabajo de carga de BigQuery es atómico; se insertan todos los registros o no se inserta ninguno. Como práctica recomendada, cuando insertes todos los datos en un solo trabajo de carga, crea una tabla nueva usando la disposición WRITE_TRUNCATE del recurso JobConfigurationLoad. Esto es importante cuando se reintenta un trabajo de carga con errores, ya que es posible que el cliente no pueda distinguir entre los trabajos que fallaron y la falla que causó el error, por ejemplo, cuando se comunica el estado de éxito al cliente.

Si suponemos que los datos que se transferirán ya se copiaron correctamente en Cloud Storage, basta con reintentar con una retirada exponencial para abordar las fallas de transferencia.

Se recomienda que un trabajo por lotes nocturno no alcance la cuota predeterminada de 1,500 cargas por tabla por día, incluso con reintentos. Cuando se cargan datos de forma incremental, la cuota predeterminada es suficiente para ejecutar un trabajo de carga cada 5 minutos, y queda cuota para al menos 1 reintento por trabajo en promedio.

¿Qué sigue?