Compila productos de datos en una malla de datos

Last reviewed 2022-10-06 UTC

Para garantizar que se cumplan los casos de uso de los consumidores de datos, es esencial que los productos de datos en una malla de datos se diseñen y se compilen con cuidado. El diseño de un producto de datos comienza con la definición de cómo los consumidores de datos usarían ese producto y cómo se expone a los consumidores. Los productos de datos de una malla de datos se compilan sobre un almacén de datos (por ejemplo, un almacén de datos de dominio o un data lake). Cuando creas productos de datos en una malla de datos, hay algunos factores clave que te recomendamos tener en cuenta durante este proceso. Estas consideraciones se describen en este documento.

Este documento forma parte de una serie en la que se describe cómo implementar una malla de datos en Google Cloud. Se supone que leíste y que estás familiarizado con los conceptos descritos en Arquitectura y funciones en una malla de datos y Compila una malla de datos moderna y distribuida con Google Cloud.

La serie tiene las siguientes partes:

Cuando se crean productos de datos desde un almacén de datos de dominio, recomendamos que los productores de datos diseñen con cuidado interfaces de análisis (consumo) para esos productos. Estas interfaces de consumo son un conjunto de garantías sobre la calidad de los datos y los parámetros operativos, junto con un modelo de asistencia de productos y la documentación del producto. El costo de cambiar las interfaces de consumo suele ser alto debido a la necesidad de que el productor de datos y los consumidores de datos múltiples puedan cambiar sus procesos y aplicaciones de consumo. Dado que es más probable que los consumidores de datos estén en unidades organizativas independientes a la de los productores de datos, puede ser difícil coordinar los cambios.

En las siguientes secciones, se proporciona información general sobre lo que debes tener en cuenta cuando creas un almacén de dominios, defines las interfaces de consumo y expones esas interfaces a los consumidores de datos.

Crea un almacén de datos de dominio

No existe una diferencia fundamental entre la compilación de un almacén de datos independiente y la compilación de un almacén de datos del dominio desde el que el equipo del productor de datos crea productos de datos. La única diferencia real entre ambos es que este último expone un subconjunto de sus datos a través de las interfaces de consumo.

En muchos almacenes de datos, los datos sin procesar que se transfieren desde fuentes de datos operativos pasan por el proceso de enriquecimiento y verificación de calidad de los datos (selección). En los data lakes administrados por Dataplex, los datos seleccionados suelen almacenarse en zonas seleccionadas. Cuando se completa la selección, un subconjunto de datos debe estar listo para el consumo externo al dominio a través de varios tipos de interfaces. Para definir esas interfaces de consumo, una organización debe proporcionar un conjunto de herramientas a los equipos de dominios que estén comenzando a adoptar un enfoque de malla de datos. Estas herramientas permiten a los productores de datos crear productos de datos nuevos por autoservicio. Para obtener prácticas recomendadas, consulta Diseña una plataforma de datos de autoservicio.

Además, los productos de datos deben cumplir con los requisitos de administración de datos definidos de forma central. Estos requisitos afectan la calidad de los datos, su disponibilidad y la administración del ciclo de vida. Debido a que estos requisitos crean la confianza de los consumidores de datos en los productos de datos y fomentan el uso de los productos de datos, los beneficios de implementar estos requisitos valen el esfuerzo de respaldarlos.

Define las interfaces de consumo

Recomendamos que los productores de datos usen varios tipos de interfaces, en lugar de definir solo una o dos. Cada tipo de interfaz en las estadísticas de datos tiene ventajas y desventajas, y no hay un tipo de interfaz que se destaque en todo. Cuando los productores de datos evalúan la idoneidad de cada tipo de interfaz, deben considerar lo siguiente:

  • Capacidad de realizar el procesamiento de datos necesario.
  • Escalabilidad para admitir casos de uso de consumidores de datos actuales y futuros.
  • Rendimiento que requieren los consumidores de datos.
  • Costo de desarrollo y mantenimiento.
  • Costo de ejecución de la interfaz.
  • Compatibilidad con los lenguajes y las herramientas que usa tu organización.
  • Compatibilidad con la separación del almacenamiento y el procesamiento.

Por ejemplo, si el requisito empresarial es la posibilidad de ejecutar consultas analíticas en un conjunto de datos de tamaño de petabytes, la única interfaz práctica es una vista de BigQuery. Pero si los requisitos son proporcionar datos de transmisión casi en tiempo real, una interfaz basada en Pub/Sub es más apropiada.

Muchas de estas interfaces no requieren que copies o repliques los datos existentes. La mayoría de ellas también te permiten separar el almacenamiento y el procesamiento, una característica fundamental de las herramientas de estadísticas de Google Cloud. Los consumidores de datos expuestos a través de estas interfaces procesan los datos con los recursos de procesamiento disponibles para ellos. No es necesario que los productores de datos realicen un aprovisionamiento adicional de la infraestructura.

Existe una amplia variedad de interfaces de consumo. Las siguientes interfaces son las más comunes que se usan en una malla de datos y se analizan en las siguientes secciones:

La lista de interfaces de este documento no es exhaustiva. También hay otras opciones que puedes considerar para tus interfaces de consumo (por ejemplo, Analytics Hub). Sin embargo, estas otras interfaces están fuera del alcance de este documento.

Vistas y funciones autorizadas

En la medida de lo posible, los productos de datos deben exponerse a través de vistas autorizadas y funciones autorizadas, incluidas las funciones con valores de tabla. Los conjuntos de datos autorizados proporcionan una forma conveniente de autorizar varias vistas de forma automática. El uso de vistas autorizadas evita el acceso directo a las tablas base y te permite optimizar las tablas y consultas subyacentes en ellas, sin afectar el uso de estas vistas por parte del consumidor. Los consumidores de esta interfaz usan SQL para consultar los datos. En el siguiente diagrama, se ilustra el uso de los conjuntos de datos autorizados como la interfaz de consumo.

Interfaces de consumo.

Las vistas y los conjuntos de datos autorizados ayudan a facilitar el control de versiones de las interfaces. Como se muestra en el siguiente diagrama, hay dos enfoques de control de versiones principales que los productores de datos pueden adoptar:

El conjunto de datos y el control de versiones de vistas.

Los enfoques se pueden resumir de la siguiente manera:

  • Control de versiones del conjunto de datos: en este enfoque, creas una versión del nombre del conjunto de datos. No creas una versión de las vistas y las funciones dentro del conjunto de datos. Debes mantener los mismos nombres para las vistas y las funciones, sin importar la versión. Por ejemplo, la primera versión de un conjunto de datos de ventas se define en un conjunto de datos llamado sales_v1 con dos vistas, catalog y orders. Para su segunda versión, se cambió el nombre del conjunto de datos de ventas a sales_v2 y cualquier vista anterior en el conjunto de datos conserva sus nombres anteriores, pero tienen esquemas nuevos. La segunda versión del conjunto de datos también puede tener vistas nuevas agregadas, o puede quitar cualquiera de las vistas anteriores.
  • Control de versiones de vistas: en este enfoque, las vistas del conjunto de datos tienen control de versiones en lugar del conjunto de datos en sí. Por ejemplo, el conjunto de datos de ventas conserva el nombre de sales sin importar la versión. Sin embargo, los nombres de las vistas dentro del conjunto de datos cambian para reflejar cada versión nueva de la vista (por ejemplo, catalog_v1, catalog_v2, orders_v1, orders_v2 y orders_v3).

El mejor enfoque de control de versiones para tu organización depende de las políticas de la organización y la cantidad de vistas obsoletas que se actualizan con los datos subyacentes. El control de versiones del conjunto de datos es mejor cuando se necesita una actualización importante del producto y la mayoría de las vistas deben cambiar. El control de versiones de vistas genera menos vistas con nombres idénticos en diferentes conjuntos de datos, pero puede generar ambigüedades, por ejemplo, cómo saber si una unión entre conjuntos de datos funciona de forma correcta. Un enfoque híbrido puede ser un buen compromiso. En un enfoque híbrido, se permiten los cambios de esquema compatibles dentro de un solo conjunto de datos y los cambios incompatibles requieren un conjunto de datos nuevo.

Consideraciones sobre tablas de BigLake

Las vistas autorizadas se pueden crear no solo en las tablas de BigQuery, sino también en las tablas de BigLake. Las tablas de BigLake permiten que los consumidores consulten los datos almacenados en Cloud Storage a través de la interfaz de SQL de BigQuery. Las tablas de BigLake admiten un control de acceso detallado sin que los consumidores de datos tengan permisos de lectura para el bucket subyacente de Cloud Storage.

Los productores de datos deben considerar lo siguiente para las tablas de BigLake:

  • El diseño de los formatos de archivo y el diseño de los datos influyen en el rendimiento de las consultas. Los formatos basados en columnas, por ejemplo, ORC o Parquet, suelen tener un mejor rendimiento en el caso de las consultas analíticas que los formatos JSON o CSV.
  • Un diseño particionado de subárbol te permite reducir las particiones y acelerar las consultas que usan columnas de partición.
  • En la etapa de diseño, también se debe tener en cuenta la cantidad de archivos y el rendimiento de la consulta preferido para el tamaño del archivo.

Si las consultas que usan tablas de BigLake no cumplen con los requisitos del Acuerdo de Nivel de Servicio (ANS) de la interfaz y no se pueden ajustar, recomendamos las siguientes acciones:

  • Para los datos que se deben exponer al consumidor de datos, convierte esos datos en el almacenamiento de BigQuery.
  • Redefine las vistas autorizadas para usar las tablas de BigQuery.

Por lo general, este enfoque no genera interrupciones en los consumidores de datos ni requiere cambios en sus consultas. Las consultas en el almacenamiento de BigQuery se pueden optimizar con técnicas que no son posibles con las tablas de BigLake. Por ejemplo, con el almacenamiento de BigQuery, los consumidores pueden consultar vistas materializadas con particiones y agrupamiento en clústeres diferentes a las de las tablas base y pueden usar BigQuery BI Engine.

APIs de lectura directa

Aunque no recomendamos en general que los productores de datos brinden a los consumidores de datos acceso directo de lectura a las tablas base, en ocasiones, puede ser práctico permitir ese acceso por motivos como el rendimiento y el costo. En esos casos, se debe tener especial cuidado para garantizar que el esquema de la tabla sea estable.

Hay dos formas de acceder directamente a los datos en un almacén típico. Los productores de datos pueden usar la API de lectura de almacenamiento de BigQuery o las APIs de JSON o XML de Cloud Storage. En el siguiente diagrama, se ilustran dos ejemplos de consumidores que usan estas APIs. Uno es un caso de uso de aprendizaje automático (AA) y el otro es un trabajo de procesamiento de datos.

Casos de uso de AA y procesamiento de datos, que se explican en el siguiente texto.

El control de versiones de una interfaz de lectura directa es complejo. Por lo general, los productores de datos deben crear otra tabla con un esquema diferente. También deben mantener dos versiones de la tabla hasta que todos los consumidores de datos de la versión obsoleta migren a la nueva. Si los consumidores pueden tolerar la interrupción de volver a compilar la tabla y cambiar al nuevo esquema, es posible evitar la duplicación de datos. En los casos en que los cambios de esquema puedan ser retrocompatibles, se puede evitar la migración de la tabla base. Por ejemplo, no es necesario que migres la tabla base si solo se agregan columnas nuevas y los datos de estas columnas se reabastecen para todas las filas.

A continuación, se presenta un resumen de las diferencias entre la API de Storage Read y la API de Cloud Storage. En general, siempre que sea posible, recomendamos que los productores de datos usen la API de BigQuery para aplicaciones analíticas.

  • API de Storage Read: la API de Storage Read se puede usar para leer datos en tablas de BigQuery y leer tablas de BigLake. Esta API admite el filtrado y un control de acceso detallado, y puede ser una buena opción para estadísticas de datos estables o consumidores de AA.

  • API de Cloud Storage: Es posible que los productores de datos necesiten compartir un bucket de Cloud Storage en particular con los consumidores de datos. Por ejemplo, los productores de datos pueden compartir el bucket si los consumidores de datos no pueden usar la interfaz de SQL por algún motivo o si el bucket tiene formatos de datos que no son compatibles con la API de Storage Read.

En general, no recomendamos que los productores de datos permitan el acceso directo a través de las APIs de almacenamiento, ya que el acceso directo no permite el filtrado y el control de acceso detallado. Sin embargo, el enfoque de acceso directo puede ser una opción viable para conjuntos de datos estables de tamaño pequeño (gigabytes).

Permitir el acceso de Pub/Sub al bucket brinda a los consumidores de datos una manera fácil de copiar los datos en sus proyectos y procesarlos allí. En general, no recomendamos copiar los datos si se puede evitar. Varias copias de datos aumentan el costo de almacenamiento e incrementan la sobrecarga de mantenimiento y linaje.

Datos como transmisiones

Un dominio puede exponer los datos de transmisión si los publica en un tema de Pub/Sub. Los suscriptores que desean consumir los datos crean suscripciones para consumir los mensajes publicados en ese tema. Cada suscriptor recibe y consume datos de forma independiente. En el siguiente diagrama, se muestra un ejemplo de estos flujos de datos.

Flujos de datos para recibir y consumir datos.

En el diagrama, la canalización de transferencia lee los eventos sin procesar, los enriquece (selecciona) y guarda estos datos seleccionados en el almacén de datos analíticos (tabla base de BigQuery). Al mismo tiempo, la canalización publica los eventos enriquecidos en un tema dedicado. Varios suscriptores consumen este tema, cada uno de los cuales puede filtrar estos eventos para obtener solo los que son relevantes para ellos. La canalización también agrega y publica estadísticas de eventos en su propio tema para que otro consumidor de datos las procese.

A continuación, se muestran algunos ejemplos de casos de uso para las suscripciones a Pub/Sub:

  • Eventos enriquecidos, como proporcionar información completa del perfil del cliente y datos sobre un pedido específico de un cliente
  • Notificaciones de agregación casi en tiempo real, como las estadísticas de pedidos totales de los últimos 15 minutos.
  • Alertas a nivel empresarial, como la generación de una alerta si el volumen de pedidos disminuyó en un 20% en comparación con un período similar del día anterior.
  • Notificaciones de cambios en los datos (similares al concepto para las notificaciones de captura de datos modificados), como un estado de cambio de orden específico.

El formato de datos que usan los productores de datos para los mensajes de Pub/Sub afecta los costos y la forma en que se procesan estos mensajes. Para las transmisiones de gran volumen en una arquitectura de malla de datos, los formatos Avro o Protobuf son buenas opciones. Si los productores de datos usan estos formatos, pueden asignar esquemas a temas de Pub/Sub. Los esquemas ayudan a garantizar que los consumidores reciban mensajes con el formato correcto.

Debido a que una estructura de datos de transmisión puede cambiar constantemente, el control de versiones de esta interfaz requiere coordinación entre los productores de datos y los consumidores de datos. Los productores de datos pueden adoptar varios enfoques comunes, como los siguientes:

  • Se crea un tema nuevo cada vez que cambia la estructura del mensaje. Este tema suele tener un esquema explícito de Pub/Sub. Los consumidores de datos que necesitan la interfaz nueva pueden comenzar a consumir los nuevos datos. La versión del mensaje está implícita por el nombre del tema, por ejemplo, click_events_v1. Los formatos de los mensajes se escriben de forma sólida. No hay variaciones en el formato del mensaje entre los mensajes en el mismo tema. La desventaja de este enfoque es que puede haber consumidores de datos que no puedan cambiar a la suscripción nueva. En este caso, el productor de datos debe continuar publicando eventos en todos los temas activos durante algún tiempo, y los consumidores de datos que se suscriben al tema deben lidiar con un intervalo en el flujo de mensajes o anular la duplicación los mensajes.
  • Los datos siempre se publican en el mismo tema. Sin embargo, la estructura del mensaje puede cambiar. Un atributo de mensaje de Pub/Sub (separado de la carga útil) define la versión del mensaje. Por ejemplo, v=1.0. Este enfoque quita la necesidad de lidiar con brechas o duplicados. Sin embargo, todos los consumidores de datos deben estar listos para recibir mensajes de un nuevo tipo. Los productores de datos tampoco pueden usar esquemas de temas de Pub/Sub para este enfoque.
  • Un enfoque híbrido. El esquema del mensaje puede tener una sección de datos arbitraria que se puede usar para nuevos campos. Este enfoque puede proporcionar un equilibrio razonable entre los datos datos escritos de forma sólida y los cambios frecuentes y complejos de la versión.

API de acceso a los datos

Los productores de datos pueden compilar una API personalizada para acceder directamente a las tablas base en un almacén de datos. Por lo general, estos productores exponen esta API personalizada como una API de REST o de gRPC y se implementan en Cloud Run o en un clúster de Kubernetes. Una puerta de enlace de API como Apigee puede proporcionar otras funciones adicionales, como la regulación del tráfico o una capa de almacenamiento en caché. Estas funcionalidades son útiles cuando se expone la API de acceso a los datos a consumidores fuera de una organización de Google Cloud. Los posibles candidatos para una API de acceso a datos son consultas sensibles a la latencia y de simultaneidad alta, que muestran un resultado relativamente pequeño en una sola API y se pueden almacenar en caché de manera eficaz.

Los siguientes son algunos ejemplos de una API personalizada para el acceso a datos:

  • Una vista combinada de las métricas del ANS de la tabla o el producto.
  • Los 10 registros principales (que pueden almacenarse en caché) de una tabla en particular.
  • Un conjunto de datos de estadísticas de tablas (cantidad total de filas o distribución de datos dentro de las columnas de claves).

Cualquier guía y administración que tenga la organización en torno a la compilación de API de aplicaciones también se aplica a las APIs personalizadas creadas por los productores de datos. Los lineamientos y la administración de la organización deben abarcar problemas, como el hosting, la supervisión, el control de acceso y el control de versiones.

La desventaja de una API personalizada es el hecho de que los productores de datos son responsables de cualquier infraestructura adicional necesaria para alojar esta interfaz, así como de la codificación y el mantenimiento de la API personalizada. Recomendamos que los productores de datos investiguen otras opciones antes de decidir crear APIs de acceso a datos personalizados. Por ejemplo, los productores de datos pueden usar BigQuery BI Engine para disminuir la latencia de respuesta y aumentar la simultaneidad.

Bloques de Looker

Para productos como Looker, que se usan en gran medida en herramientas de inteligencia empresarial (IE), puede ser útil mantener un conjunto de widgets específicos de la herramienta de IE. Debido a que el equipo del productor de datos conoce el modelo de datos subyacente que se usa en el dominio, ese equipo está mejor posicionado para crear y mantener un conjunto de visualizaciones compilado previamente.

En el caso de Looker, esta visualización podría ser un conjunto de bloques de Looker (modelos de datos de LookML compilados previamente). Los bloques de Looker se pueden incorporar fácilmente en paneles alojados por consumidores.

Modelos de AA

Debido a que los equipos que trabajan en dominios de datos tienen una comprensión profunda y un conocimiento de sus datos, a menudo son los mejores equipos para compilar y mantener modelos de AA que están entrenados con los datos de dominio. Estos modelos de AA se pueden exponer a través de varias interfaces diferentes, incluidas las siguientes:

  • Los modelos de BigQuery ML se pueden implementar en un conjunto de datos dedicado y se pueden compartir con los consumidores de datos para las predicciones por lotes de BigQuery.
  • Los modelos de BigQuery ML se pueden exportar a Vertex AI para usarlos en predicciones en línea.

Consideraciones sobre la ubicación de los datos para las interfaces de consumo

Un aspecto importante cuando los productores de datos definen las interfaces de consumo para los productos de datos es la ubicación de datos. En general, para minimizar los costos, los datos deben procesarse en la misma región en la que se almacenan. Este enfoque ayuda a prevenir cargos de salida de datos entre regiones. Este enfoque también tiene la latencia de consumo de datos más baja. Por estos motivos, los datos almacenados en ubicaciones multirregionales de BigQuery suelen ser el mejor candidato para exponerse como un producto de datos.

Sin embargo, por razones de rendimiento, los datos almacenados en Cloud Storage y expuestos a través de tablas de BigLake o APIs de lectura directa deben almacenarse en buckets regionales.

Si los datos expuestos en un producto residen en una región y necesitan unirse con datos en otro dominio en otra región, los consumidores de datos deben considerar las siguientes limitaciones:

  • No se admiten las consultas entre regiones que usan SQL de BigQuery. Si el método de consumo principal para los datos es BigQuery SQL, todas las tablas en la consulta deben estar en la misma ubicación.
  • Los compromisos de tarifa plana de BigQuery son regionales. Si un proyecto usa solo un compromiso de tarifa plana en una región, pero consulta un producto de datos en otra región, se aplican los precios según demanda.
  • Los consumidores de datos pueden usar las APIs de lectura directa para leer datos de otra región. Sin embargo, se aplican cargos de salida de red interregionales y es probable que los consumidores de datos experimenten latencia para las transferencias de datos grandes.

Los datos a los que se accede con frecuencia en todas las regiones se pueden replicar en esas regiones para reducir el costo y la latencia de las consultas que generan los consumidores de productos. Por ejemplo, los conjuntos de datos de BigQuery se pueden copiar a otras regiones. Sin embargo, los datos solo se deben copiar cuando sean necesarios. Recomendamos que los productores de datos solo pongan a disposición de un subconjunto de los datos de productos disponibles para varias regiones cuando copies datos. Este enfoque ayuda a minimizar la latencia de replicación y el costo. Este enfoque puede provocar la necesidad de proporcionar varias versiones de la interfaz de consumo con la región de ubicación de datos llamada de forma explícita. Por ejemplo, las vistas autorizadas de BigQuery se pueden exponer a través de nombres, como sales_eu_v1 y sales_us_v1.

Las interfaces de transmisión de datos que usan temas de Pub/Sub no necesitan ninguna lógica de replicación adicional para consumir mensajes en regiones que no sean la misma que la ubicación en la que se almacena el mensaje. Sin embargo, en este caso, se aplican cargos de salida adicionales entre regiones.

Expón las interfaces de consumo a consumidores de datos

En esta sección, se analiza cómo hacer que los consumidores potenciales puedan detectar las interfaces de consumo. Data Catalog es un servicio completamente administrado que las organizaciones pueden usar para proporcionar los servicios de administración de metadatos y descubrimiento de datos. Los productores de datos deben hacer que las interfaces de consumo de sus productos de datos se puedan buscar y anotarlas con los metadatos adecuados para permitir que los consumidores de productos accedan a ellos por autoservicio. Mié

En las siguientes secciones, se analiza cómo se define cada tipo de interfaz como una entrada de Data Catalog.

Interfaces de SQL basadas en BigQuery

Los metadatos técnicos, como un nombre de tabla o un esquema de tabla completamente calificados, se registran de forma automática para las vistas autorizadas, las vistas de BigLake y las tablas de BigQuery que están disponibles a través de la API de Storage Read. Recomendamos que los productores de datos también proporcionen información adicional en la documentación del producto de datos para ayudar a los consumidores de datos. Por ejemplo, para ayudar a los usuarios a encontrar la documentación del producto para una entrada, los productores de datos pueden agregar una URL a una de las etiquetas que se aplicaron a la entrada. Los productores también pueden proporcionar lo siguiente:

  • Conjuntos de columnas agrupadas en clústeres, que se deben usar en los filtros de consulta.
  • Valores de enumeración para los campos que tienen un tipo de enumeración lógica, si el tipo no se proporciona como parte de la descripción del campo.
  • Uniones compatibles con otras tablas.

Flujos de datos

Los temas de Pub/Sub se registran de forma automática con Data Catalog. Sin embargo, los productores de datos deben describir el esquema en la documentación del producto de datos.

API de Cloud Storage

Data Catalog admite la definición de entradas de archivo de Cloud Storage y su esquema. Si Dataplex administra un conjunto de archivos de data lake, el conjunto de archivos se registra de forma automática en Data Catalog. Los conjuntos de archivos que no están asociados con Dataplex se agregan con un enfoque diferente.

Otras interfaces

Puedes agregar otras interfaces que no tengan compatibilidad integrada con Data Catalog mediante la creación de entradas personalizadas.

¿Qué sigue?