Diseña una plataforma de datos de autoservicio para una malla de datos

Last reviewed 2024-09-03 UTC

En una malla de datos, una plataforma de datos de autoservicio permite que los usuarios generen valor a partir de los datos, ya que les permite compilar, compartir y usar productos de datos de forma autónoma. Para aprovechar al máximo estos beneficios, te recomendamos que tu plataforma de datos de autoservicio proporcione las capacidades que 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 estás familiarizado con los conceptos descritos en Compila una malla de datos moderna y distribuida con Google Cloud y Arquitectura y funciones en una malla de datos.

La serie tiene las siguientes partes:

Los equipos de plataformas de datos suelen crear plataformas de datos de autoservicio centrales, como se describe en este documento. Este equipo compila las soluciones y los componentes que los equipos de dominio (tanto los productores como los consumidores de datos) pueden usar para crear y consumir productos de datos. Los equipos de dominio representan partes funcionales de una malla de datos. Mediante la compilación de estos componentes, el equipo de la plataforma de datos permite una experiencia de desarrollo sin problemas y reduce la complejidad de compilar, implementar y mantener productos de datos interoperables y seguros.

En última instancia, el equipo de la plataforma de datos debería permitir que los equipos de dominio avancen más rápido. Ayudan a aumentar la eficiencia de los equipos de dominio, ya que les proporcionan un conjunto limitado de herramientas que satisfacen sus necesidades. Cuando se proporcionan estas herramientas, el equipo de la plataforma de datos evita que el equipo de dominio tenga que compilar y obtener estas herramientas. Las opciones de herramientas deben personalizarse según las diferentes necesidades y no forzar una forma inflexible de trabajar en los equipos de dominios de datos.

El equipo de la plataforma de datos no debe enfocarse en crear soluciones personalizadas para los organizadores de canalizaciones de datos ni para los sistemas de integración continua y de implementación continua (CI/CD). Las soluciones como los sistemas de CI/CD están disponibles como servicios en la nube administrados, por ejemplo, Cloud Build. Usar los servicios de nube administrados puede reducir las sobrecargas operativas para el equipo de la plataforma de datos y permitirles enfocarse en las necesidades específicas de los equipos de dominios de datos como los usuarios de la plataforma. Con una sobrecarga operativa menor, el equipo de la plataforma de datos puede enfocarse más en abordar las necesidades específicas de los equipos del dominio de datos.

Arquitectura

En el siguiente diagrama, se ilustran los componentes de la arquitectura de una plataforma de datos de autoservicio. En el diagrama, también se muestra cómo estos componentes pueden ayudar a los equipos a medida que desarrollan y consumen productos de datos en la malla de datos.

Componentes de la plataforma de datos de autoservicio, como se describe en el siguiente texto.

Como se muestra en el diagrama anterior, la plataforma de datos de autoservicio proporciona lo siguiente:

  • Soluciones de plataforma: Estas soluciones consisten en componentes componibles para aprovisionar proyectos y recursos de Google Cloud , que los usuarios seleccionan y ensamblan en diferentes combinaciones para cumplir con sus requisitos específicos. En lugar de interactuar directamente con los componentes, los usuarios de la plataforma pueden interactuar con las soluciones de la plataforma para ayudarlos a alcanzar un objetivo específico. Los equipos de dominios de datos deben diseñar soluciones de plataforma para resolver los puntos problemáticos y las áreas de fricción comunes que causan retrasos en el desarrollo y el consumo de productos de datos. Por ejemplo, los equipos de dominios de datos que se integran en la malla de datos pueden usar una plantilla de infraestructura como código (IaC). Usar las plantillas de IaC les permite crear con rapidez un conjunto de proyectos deGoogle Cloud con permisos estándar de Identity and Access Management (IAM), herramientas de redes, políticas de seguridad y APIs de Google Cloud relevantes habilitadas para el desarrollo de productos de datos. Recomendamos que cada solución esté acompañada de documentación, como orientación sobre cómo comenzar y muestras de código. Las soluciones de plataformas de datos y sus componentes deben ser seguros y cumplir con las normativas de forma predeterminada.

  • Servicios comunes: Estos servicios proporcionan visibilidad, administración, uso compartido y observabilidad de los productos de datos. Estos servicios facilitan la confianza de los consumidores de datos en los productos de datos y son una forma eficaz para que los productores de datos alerten a los consumidores de datos sobre problemas con sus productos de datos.

Las soluciones de plataforma de datos y los servicios comunes pueden incluir lo siguiente:

  • Plantillas de IaC para configurar entornos de espacio de trabajo de desarrollo de productos de datos fundamentales, que incluyen lo siguiente:
    • IAM
    • Registro y supervisión
    • Herramientas de redes
    • Protecciones de seguridad y cumplimiento
    • Etiquetado de recursos para la atribución de facturación
    • Almacenamiento, transformación y publicación de productos de datos
    • Registro de productos de datos, catalogación y etiquetado de metadatos
  • Plantillas de IaC que siguen las protecciones de seguridad y las prácticas recomendadas de la organización que se pueden usar para implementar recursos de Google Cloud en espacios de trabajo de desarrollo de productos de datos existentes.
  • Plantillas de canalización de datos y aplicaciones que se pueden usar para iniciar proyectos nuevos o como referencia para proyectos existentes. Estos son algunos ejemplos de esas plantillas:
    • Uso de bibliotecas y frameworks comunes
    • Integración en las herramientas de registro, supervisión y observabilidad de la plataforma
    • Herramientas de compilación y prueba
    • Administración de configuración
    • Empaquetado y canalizaciones de CI/CD para la implementación
    • Autenticación, implementación y administración de credenciales
  • Servicios comunes para proporcionar observabilidad y administración de productos de datos, que pueden incluir lo siguiente:
    • Verificaciones de tiempo de actividad para mostrar el estado general de los productos de datos.
    • Métricas personalizadas para brindar indicadores útiles sobre los productos de datos.
    • Asistencia operativa del equipo central para que los equipos de consumidores de datos reciban alertas sobre los cambios en los productos de datos que usan.
    • Tarjetas de puntuación de productos para mostrar el rendimiento de los productos de datos.
    • Un catálogo de metadatos para descubrir productos de datos.
    • Un conjunto de políticas de procesamiento definidas de forma centralizada que se pueden aplicar de forma global en la malla de datos.
    • Un mercado de datos para facilitar el uso compartido de datos entre los equipos de dominio

En Crea componentes y soluciones de plataforma con plantillas de IaC, se analizan las ventajas de las plantillas de IaC para exponer e implementar productos de datos. En Proporciona servicios comunes, se analiza por qué es útil proporcionar a los equipos de dominios componentes de infraestructura comunes que compiló y administra el equipo de plataforma de datos.

Crear componentes y soluciones de plataforma con plantillas de IaC

El objetivo de los equipos de plataformas de datos es configurar plataformas de datos de autoservicio para obtener más valor de los datos. Para compilar estas plataformas, crean y proporcionan a los equipos de dominio plantillas de infraestructura verificadas, seguras y de autoservicio. Los equipos de dominio usan estas plantillas para implementar sus entornos de desarrollo y consumo de datos. Las plantillas de IaC ayudan a los equipos de plataformas de datos a lograr ese objetivo y habilitar el escalamiento. El uso de plantillas de IaC verificadas y confiables simplifica el proceso de implementación de recursos para los equipos de dominio, ya que les permite reutilizar las canalizaciones de CI/CD existentes. Este enfoque permite que los equipos de dominio comiencen con rapidez y se vuelvan productivos dentro de la malla de datos.

Las plantillas de IaC se pueden crear con una herramienta de IaC. Aunque existen varias herramientas de IaC, incluidas Cloud Config Connector, Pulumi, Chef yAnsible, en este documento, se proporcionan ejemplos de Terraform basadas en IaC. Terraform es una herramienta de IaC de código abierto que permite que el equipo de la plataforma de datos cree de forma eficiente componentes y soluciones de plataforma componibles para los recursos deGoogle Cloud . Con Terraform, el equipo de la plataforma de datos escribe código que especifica el estado final elegido y permite que la herramienta determine cómo alcanzar ese estado. Este enfoque declarativo permite que el equipo de la plataforma de datos trate los recursos de infraestructura como artefactos inmutables para la implementación en entornos. También ayuda a reducir el riesgo de que surjan inconsistencias entre los recursos implementados y el código declarado en el control de código fuente (lo que se conoce como desvío de configuración). El desvío de configuración causado por cambios ad hoc y manuales en la infraestructura impide la implementación segura y repetible de los componentes de IaC en los entornos de producción.

Las plantillas de IaC comunes para los componentes de la plataforma compuestas incluyen el uso de módulos de Terraform para implementar recursos como un conjunto de datos de BigQuery, un bucket de Cloud Storage o una base de datos de Cloud SQL. Los módulos de Terraform se pueden combinar en soluciones de extremo a extremo para implementar proyectos de Google Cloud completos, incluidos los recursos relevantes implementados con los módulos componibles. Puedes encontrar módulos de Terraform de ejemplo en los planos de Terraform para Google Cloud.

Cada módulo de Terraform debe cumplir de forma predeterminada con las barreras de seguridad y las políticas de cumplimiento que usa tu organización. Estas protecciones y políticas también se pueden expresar como código y automatizarse con herramientas de verificación de cumplimiento automatizadas, como la herramienta de validación de políticas de Google Cloud.

Tu organización debe probar de forma continua los módulos de Terraform que proporciona la plataforma, con las mismas protecciones de cumplimiento automatizadas que usa para promover los cambios en la producción.

Para que los componentes y las soluciones de IaC sean detectables y consumibles para los equipos de dominio que tienen una experiencia mínima con Terraform, te recomendamos que uses servicios como catálogo de servicios. Los usuarios que tienen requisitos de personalización significativos deben poder crear sus propias soluciones de implementación a partir de las mismas plantillas de Terraform componibles que usan las soluciones existentes.

Cuando uses Terraform, te recomendamos que sigas las prácticas recomendadas de Google Cloud, como se describe en Prácticas recomendadas para usar Terraform.

Para ilustrar cómo se puede usar Terraform para crear componentes de plataforma, en las siguientes secciones, se analizan ejemplos de cómo se puede usar Terraform para exponer interfaces de consumo y consumir un producto de datos.

Expón una interfaz de consumo

Una interfaz de consumo para un producto de datos es un conjunto de garantías sobre la calidad de los datos y los parámetros operativos que proporciona el equipo de dominio de datos para permitir que otros equipos descubran y usen sus productos de datos. Cada interfaz de consumo también incluye un modelo de asistencia de productos y la documentación del producto. Un producto de datos puede tener diferentes tipos de interfaces de consumo, como APIs o transmisiones, como se describe en Compila productos de datos en una malla de datos. La interfaz de consumo más común puede ser un conjunto de datos, una vista o una función autorizados de BigQuery. Esta interfaz expone una tabla virtual de solo lectura, que se expresa como una consulta en la malla de datos. La interfaz no otorga permisos de lector para acceder directamente a los datos subyacentes.

Google proporciona un módulo de Terraform de ejemplo para crear vistas autorizadas sin otorgar permisos a los equipos para los conjuntos de datos autorizados subyacentes. El siguiente código de este módulo de Terraform otorga estos permisos de IAM en la vista autorizada dataset_id:

module "add_authorization" {
  source = "terraform-google-modules/bigquery/google//modules/authorization"
  version = "~> 4.1"

  dataset_id = module.dataset.bigquery_dataset.dataset_id
  project_id = module.dataset.bigquery_dataset.project

  roles = [
    {
      role           = "roles/bigquery.dataEditor"
      group_by_email = "ops@mycompany.com"
    }
  ]

  authorized_views = [
    {
      project_id = "view_project"
      dataset_id = "view_dataset"
      table_id   = "view_id"
    }
  ]
  authorized_datasets = [
    {
      project_id = "auth_dataset_project"
      dataset_id = "auth_dataset"
    }
  ]
}

Si necesitas otorgar acceso a los usuarios a varias vistas, otorgar acceso a cada vista autorizada puede llevar mucho tiempo y ser más difícil de mantener. En lugar de crear varias vistas autorizadas, puedes usar un conjunto de datos autorizado para autorizar automáticamente cualquier vista creada en el conjunto de datos autorizado.

Consume un producto de datos

En la mayoría de los casos de uso de estadísticas, la aplicación en la que se usan los datos determina los patrones de consumo. El uso principal de un entorno de consumo proporcionado de forma centralizada es la exploración de datos antes de que se usen dentro de la aplicación de consumo. Como se analiza en Descubre y consume productos en una malla de datos, SQL es el método más usado para consultar productos de datos. Por este motivo, la plataforma de datos debe proporcionar a los consumidores de datos una aplicación de SQL para explorar los datos.

Según el caso de uso de estadísticas, es posible que puedas usar Terraform a fin de implementar el entorno de consumo para los consumidores de datos. Por ejemplo, la ciencia de datos es un caso de uso común para los consumidores de datos. Puedes usar Terraform para implementar notebooks administrados por el usuario de Gemini Enterprise Agent Platform que se usarán como un entorno de desarrollo de ciencia de datos. Desde los notebooks de ciencia de datos, los consumidores de datos pueden usar sus credenciales para acceder a la malla de datos y explorar los datos a los que tienen acceso, así como desarrollar modelos de AA basados en estos datos.

Si quieres obtener información para usar Terraform con el objetivo de implementar y ayudar a proteger un entorno de notebook en Google Cloud, consulta Crea e implementa modelos de IA generativa y aprendizaje automático en una empresa.

Proporcionar servicios comunes

Además de los componentes y las soluciones de IaC de autoservicio, el equipo de la plataforma de datos también puede tomar la propiedad de la compilación y la operación de servicios comunes de plataforma compartida que usan varios equipos de dominios de datos. Los ejemplos habituales de servicios de plataforma compartida incluyen software de terceros autoalojados, como herramientas de visualización de inteligencia empresarial o un clúster de Kafka. En Google Cloud, el equipo de la plataforma de datos puede elegir administrar recursos como los receptores de Knowledge Catalog y Cloud Logging en nombre de los equipos de dominio de datos. La administración de recursos para los equipos de dominios de datos permite que el equipo de la plataforma de datos facilite la auditoría y la administración centralizadas de políticas en toda la organización.

En las siguientes secciones, se muestra cómo usar Knowledge Catalog para la administración y el control centralizados dentro de una malla de datos en Google Cloud, y la implementación de funciones de observabilidad de datos en una malla de datos.

Knowledge Catalog para la administración de datos

Knowledge Catalog proporciona una plataforma de administración de datos que te ayuda a crear dominios de datos independientes dentro de una malla de datos que abarca toda la organización. Knowledge Catalog te permite mantener controles centrales para administrar y supervisar los datos en todos los dominios.

Con Knowledge Catalog, una organización puede organizar de forma lógica sus datos (fuentes de datos compatibles) y artefactos relacionados, como código, notebooks y registros, en un lake de Knowledge Catalog que representa un dominio de datos. En el siguiente diagrama, un dominio de ventas usa Knowledge Catalog para organizar sus recursos, incluidas las métricas y los registros de calidad de los datos, en zonas de Knowledge Catalog.

Recursos organizados por Knowledge Catalog.

Como se muestra en el diagrama anterior, Knowledge Catalog se puede usar para administrar los datos de dominio en los siguientes recursos:

  • Knowledge Catalog permite que los equipos de dominios de datos administren de forma coherente sus recursos de datos en un grupo lógico llamado lake de Knowledge Catalog. El equipo de dominio de datos puede organizar sus recursos de Knowledge Catalog dentro del mismo lake de Knowledge Catalog sin mover físicamente los datos ni almacenarlos en un solo sistema de almacenamiento. Los recursos de Knowledge Catalog pueden hacer referencia a buckets de Cloud Storage y conjuntos de datos de BigQuery almacenados en varios proyectos de Google Cloud que no sean el proyecto deGoogle Cloud que contiene el lake de Knowledge Catalog. Los recursos de Knowledge Catalog pueden ser estructurados o no estructurados, o pueden almacenarse en un data lake o almacén de datos analíticos. En el diagrama, se incluyen data lakes para el dominio de ventas, el dominio de cadena de suministro y el dominio de productos.
  • Las zonas de Knowledge Catalog permiten que el equipo de dominio de datos organice aún más los recursos de datos en subgrupos más pequeños dentro del mismo lake de Knowledge Catalog y agregue estructuras que capturen aspectos clave del subgrupo. Por ejemplo, las zonas de Knowledge Catalog se pueden usar para agrupar recursos de datos asociados en un producto de datos. Agrupar los recursos de datos en una sola zona de Knowledge Catalog permite que los equipos de dominios de datos administren las políticas de acceso y de administración de datos de forma coherente en toda la zona como un solo producto de datos. En el diagrama, se incluyen zonas de datos para ventas físicas, ventas en línea, almacenes de cadena de suministro y productos.

Las zonas y los lakes de Knowledge Catalog permiten que una organización unifique datos distribuidos y los organice en función del contexto empresarial. Esta disposición constituye la base para actividades como la administración de metadatos, la configuración de políticas de administración y la supervisión de la calidad de los datos. Estas actividades permiten que la organización administre sus datos distribuidos a gran escala, como en una malla de datos.

Observabilidad de los datos

Cada dominio de datos debe implementar sus propios mecanismos de supervisión y alertas, idealmente con un enfoque estandarizado. Cada dominio puede aplicar las prácticas de supervisión descritas en Conceptos de la supervisión de servicios y realizar los ajustes necesarios en los dominios de datos. La observabilidad es un tema extenso y está fuera del alcance de este documento. En esta sección, solo se abordan los patrones que son útiles en las implementaciones de malla de datos.

En el caso de los productos con varios consumidores de datos, proporcionar información oportuna a cada consumidor sobre el estado del producto puede convertirse en una carga operativa. Las soluciones básicas, como las distribuciones de correo electrónico administradas de forma manual, suelen ser propensas a errores. Pueden ser útiles para notificar a los consumidores sobre interrupciones planificadas, próximos lanzamientos de productos y bajas, pero no proporcionan conocimiento operativo en tiempo real.

Los servicios centrales pueden desempeñar un rol importante en la supervisión del estado y la calidad de los productos en la malla de datos. Aunque no es un requisito para una implementación exitosa de la malla de datos, la implementación de funciones de observabilidad puede mejorar la satisfacción de los consumidores y los productores de datos, y reducir los costos operativos y de asistencia generales. En el siguiente diagrama, se muestra una arquitectura de observabilidad de malla de datos basada en Cloud Monitoring.

Observabilidad de la malla de datos

En las siguientes secciones, se describen los componentes que se muestran en el diagrama, que son los siguientes:

Verificaciones de tiempo de actividad

Los productos de datos pueden crear aplicaciones personalizadas sencillas que implementen verificaciones de tiempo de actividad. Estas verificaciones pueden servir como indicadores de alto nivel del estado general del producto. Por ejemplo, si el equipo de productos de datos descubre una disminución repentina en la calidad de los datos de su producto, el equipo puede marcar ese producto como en mal estado. Las verificaciones de tiempo de actividad que se realizan casi en tiempo real son especialmente importantes para los consumidores de datos que tienen productos derivados que dependen de la disponibilidad constante de los datos en el producto de datos de la etapa anterior. Los productores de datos deben compilar sus verificaciones de tiempo de actividad para incluir la verificación de sus dependencias ascendentes, lo que proporciona una imagen precisa del estado de su producto a sus consumidores de datos.

Los consumidores de datos pueden incluir verificaciones del tiempo de actividad del producto en su procesamiento. Por ejemplo, un trabajo de Composer que genera un informe basado en los datos que proporciona un producto de datos puede, como primer paso, validar si el producto está en el estado "en ejecución". Te recomendamos que tu aplicación de verificación de tiempo de actividad devuelva una carga útil estructurada en el cuerpo del mensaje de su respuesta HTTP. Esta carga útil estructurada debe indicar si hay un problema, la causa raíz del problema en un formato legible por humanos y, si es posible, el tiempo estimado para restablecer el servicio. Esta carga útil estructurada también puede proporcionar información más detallada sobre el estado del producto. Por ejemplo, puede contener la información de estado de cada una de las vistas del conjunto de datos autorizado expuesto como un producto.

Métricas personalizadas

Los productos de datos pueden tener varias métricas personalizadas para medir su utilidad. Los equipos de productores de datos pueden publicar estas métricas personalizadas en sus proyectos de Google Cloud designados por el dominio. Para crear una experiencia de supervisión unificada en todos los productos de datos, se puede otorgar acceso a un proyecto de supervisión de la malla de datos central a esos proyectos específicos de dominio.

Cada tipo de interfaz de consumo de productos de datos tiene diferentes métricas para medir su utilidad. Las métricas también pueden ser específicas del dominio empresarial. Por ejemplo, las métricas de las tablas de BigQuery expuestas a través de vistas o de la API de Storage Read pueden ser las siguientes:

  • El número de filas.
  • Actualidad de los datos (expresada como la cantidad de segundos antes de la hora de medición)
  • Es la puntuación de calidad de los datos.
  • Los datos disponibles Esta métrica puede indicar que los datos están disponibles para consultas. Una alternativa es usar las verificaciones de tiempo de actividad mencionadas antes en este documento.

Estas métricas se pueden ver como indicadores de nivel de servicio (SLI) para un producto en particular.

Para las transmisiones de datos (implementadas como temas de Pub/Sub), esta lista pueden ser las métricas de Pub/Sub estándar, que están disponibles a través de temas.

Asistencia operativa prestada por el equipo central de plataforma de datos

El equipo central de la plataforma de datos puede exponer paneles personalizados para mostrar diferentes niveles de detalles a los consumidores de datos. Un panel de estado simple que enumere los productos de la malla de datos y el estado de tiempo de actividad de esos productos puede ayudar a responder varias solicitudes de los usuarios finales.

El equipo central también puede funcionar como un centro de distribución de notificaciones para informar a los consumidores de datos sobre varios eventos en los productos de datos que usan. Por lo general, este centro se crea con políticas de alertas. Centralizar esta función puede reducir el trabajo que debe realizar cada equipo de productores de datos. La creación de estas políticas no requiere conocimiento de los dominios de datos y debería ayudar a evitar cuellos de botella en el consumo de datos.

Un estado final ideal para la supervisión de la malla de datos es que la plantilla de etiquetas del producto de datos exponga los SLI y los objetivos de nivel de servicio (SLO) que admite el producto cuando esté disponible. Luego, el equipo central puede implementar automáticamente la alerta correspondiente con la supervisión de servicios con la API de Monitoring.

Cuadros de evaluación de productos

Como parte del acuerdo de administración central, las cuatro funciones de una malla de datos pueden definir los criterios para crear cuadros de evaluación de los productos de datos. Estas tarjetas de puntuación pueden convertirse en una medición objetiva del rendimiento de los productos de datos.

Muchas de las variables que se usan para calcular los cuadros de evaluación son el porcentaje de tiempo que los productos de datos cumplen con su SLO. Los criterios útiles pueden ser el porcentaje de tiempo de actividad, las puntuaciones promedio de calidad de los datos y el porcentaje de productos con una actualidad de los datos que no sea inferior a un umbral. Para calcular estas métricas automáticamente con el lenguaje de consulta de Prometheus (PromQL), las métricas personalizadas y los resultados de las verificaciones de tiempo de actividad del proyecto de supervisión central deberían ser suficientes.

¿Qué sigue?

  • Más información sobre BigQuery
  • Lee acerca de Dataplex.
  • Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.