Conocimiento

¿Qué es un producto de datos?

Un producto de datos da acceso a datos gestionados y tiene un ownership claro.

Ilustración del producto de datos de artículos sin rotación

Producto de datos frente a data as a product

El término producto viene del enfoque de product thinking que se ha abierto camino en el desarrollo de software en los últimos años. Zhamak Dehghani lo aplicó al segundo principio fundamental del Data Mesh: data as a product. Significa que el software, y ahora también los datos, se diseñan siempre desde el punto de vista de quien los consume, para que tenga la mejor experiencia posible. Igual que un producto físico, deben desarrollarse en función de las necesidades de un consumidor. Se explican al cliente de forma comprensible (de manera intuitiva o mediante un manual de uso), se optimizan para que sean fáciles de encontrar y usar de la forma que mejor le encaje y quizá incluso se promocionan dentro de la organización para mostrar su potencial. Y, en consecuencia, también pueden tener un precio que los consumidores estén dispuestos a pagar. Los datos pasan a verse como algo valioso para la empresa y dejan de ser un simple subproducto del desarrollo de software.

El término producto de datos deriva del principio de data as a product y sigue sus ideas, pero no son sinónimos. Vamos a intentar una definición:

Un producto de datos es una unidad lógica que reúne todos los componentes necesarios para procesar y almacenar los datos de un dominio en casos de uso analíticos o intensivos en datos, y los pone a disposición de otros equipos a través de Output Ports.

Jochen Christ, datamesh-architecture.com

Así que un producto de datos es algo técnico, implementado por Data Product Developers. Usa tecnologías de datos para almacenar y procesar grandes volúmenes, a menudo millones de registros o más. Su tamaño se define para cubrir conceptos de dominio coherentes o casos de uso que tengan valor por sí mismos. El tamaño máximo lo marca el alcance que un solo equipo puede asumir. Los productos de datos se pueden comparar a grandes rasgos con los microservicios o los self-contained systems, pero con tecnologías de datos y al servicio de necesidades analíticas. Pese al término producto, los Data Product Consumers suelen ser otros equipos internos, no clientes externos.

Ejemplos de productos de datos

El equipo Product Search ofrece un producto de datos Search Queries con todas las búsquedas que los usuarios escribieron en la barra de búsqueda, el número de resultados e información sobre el elemento en el que hicieron clic.
El equipo Article Management ofrece un producto de datos Articles con los datos maestros de artículos, tanto el estado actual como el histórico.
El equipo Checkout ofrece un producto de datos Orders con todos los pedidos desde 2020. Tiene dos Output Ports: uno con datos personales y otro con esos datos anonimizados.
El equipo Fulfillment tiene un producto de datos Shelf Warmers con todos los artículos que no se han vendido en los últimos 3 meses.
El equipo Management Support usa otros productos de datos para crear un producto de datos Realtime Business Dashboard para el CEO. No comparte datos y no tiene Output Ports.
El equipo Recommendations usa otros productos de datos para entrenar un modelo de ML de recomendaciones. El modelo se comparte como un directorio SavedModel de Tensorflow en un almacenamiento de objetos. El equipo de Marketing lo usa para hacer recomendaciones personalizadas en la newsletter.

Componentes internos de un producto de datos

Desde el punto de vista de ingeniería y de plataforma, un producto de datos tiene varios componentes que forman una unidad coherente. Este diagrama muestra los componentes típicos de un producto de datos:

Un producto de datos aplica el principio de diseño de ocultación de información. Hay interfaces hacia el exterior y componentes internos. La implementación concreta de cada componente puede variar según el caso de uso y la plataforma de datos.

Output Ports

Los Output Ports son la API principal de un producto de datos: dan acceso de solo lectura a conjuntos de datos estructurados en forma de tablas, ficheros o topics. Un producto de datos puede tener varios Output Ports: pueden ofrecer el mismo conjunto de datos en distintas tecnologías, o conjuntos distintos en la misma tecnología; por ejemplo, un Output Port con datos personales y un segundo Output Port con esos datos anonimizados. También se puede añadir un Output Port nuevo cuando hace falta un cambio estructural para hacer evolucionar el producto de datos con el tiempo.

Ejemplo de un Output Port — Ejemplo de una tabla como Output Port

La tecnología de interfaz principal de un Output Port es SQL. Permite acceder con facilidad a grandes conjuntos de datos y es compatible con prácticamente todas las herramientas analíticas. Un Output Port se implementa a menudo como una vista SQL, una capa de abstracción que permite cambiar la estructura de datos subyacente sin afectar a los Data Consumers. Otras tecnologías de interfaz para Output Ports son los ficheros o los topics, para procesamiento en streaming o como API asíncrona hacia sistemas operacionales.

Los Output Ports definen el modelo del conjunto de datos que se ofrece. Ese modelo se describe en un esquema con todas las tablas, atributos y tipos. Las tecnologías habituales son SQL DDL, modelos dbt, Protobuf, Avro o JSON Schema. El modelo también puede describirse en una entrada de un catálogo de datos.


  models:
    - name: stock_last_updated_v1
      description: >
        Current state of the stock.
        One record per SKU and location with the last updated timestamp.
      columns:
        - name: sku
          type: string
          description: Stock Keeping Unit (SKU), the business key of an article.
          tests:
            - not_null
        - name: location
          type: string
          description: The ID of the warehouse location.
          tests:
            - not_null
        - name: available
          type: number
          description: The number of articles with this SKU that are available at this location.
          tests:
            - not_null
            - dbt_utils.expression_is_true:
                expression: "col_a >= 0"
        - name: updated_at
          type: timestamptz
          description: The business timestamp in UTC when the available was changed.
          tests:
            - not_null

Ejemplo de una especificación de esquema como modelo dbt

Los Output Ports son opcionales, o pueden ser privados si un producto de datos solo atiende casos de uso analíticos internos del equipo.

El acceso a los Output Ports se gobierna mediante Data Contracts.

Input Ports

Un producto de datos puede tener dos tipos de fuentes de datos: sistemas operacionales u otros productos de datos.

Los equipos que desarrollan los sistemas operacionales también publican los datos relevantes de su dominio en productos de datos. A menudo se hace mediante topics asíncronos, preferiblemente con eventos de dominio bien definidos. En última instancia, sin embargo, es el equipo de dominio quien decide cómo se ingieren sus datos en sus productos de datos.

Un producto de datos también puede consumir otros productos de datos a través de su Output Port, siempre que exista un Data Contract acordado. Esos productos pueden pertenecer al mismo equipo o a otros. Es lo habitual en los productos de datos orientados al consumo o agregados, aunque también los orientados a la fuente pueden enlazar datos de otros dominios cuando resulta útil, por ejemplo para consultar datos maestros.

Discovery Port

Los Data Consumers necesitan encontrar los productos de datos que les resultan relevantes. Como los datos suelen tener un significado propio del dominio, es importante ofrecer una descripción amplia de la semántica del modelo de datos.

Otros metadatos, como los datos de contacto, el nivel de madurez, quién más usa el producto de datos, las pruebas de calidad de datos y los objetivos de nivel de servicio, son importantes para que los Data Consumers puedan decidir si un producto de datos es fiable y adecuado para su caso de uso.

Es buena práctica usar pasos del pipeline de CI/CD para publicar automáticamente los metadatos en un catálogo de datos y en el inventario de productos de datos, como Entropy Data.

Ownership

Un producto de datos lo desarrolla y mantiene un único equipo que entiende el dominio de negocio, los procesos de negocio y los datos. El equipo se responsabiliza de cumplir la calidad de datos y los objetivos de nivel de servicio prometidos. Un producto de datos tiene una persona de contacto dedicada, el product owner del equipo, que es en última instancia responsable del producto de datos y de su calidad.

El product owner se encarga del ciclo de vida y la evolución del producto de datos, recogiendo los requisitos de los consumidores (potenciales) y las necesidades analíticas internas del dominio. También fija el precio que se cobra por su uso.

Código de transformación

Los datos hay que limpiarlos, agregarlos, componerlos y transformarlos para implementar el esquema del Output Port o para responder preguntas analíticas.

Qué tecnología se usa y cómo se organiza el código por dentro son detalles de implementación del producto de datos. Dependen de la plataforma de datos y los deciden los equipos de desarrollo.

En muchos casos se usan consultas SQL para transformaciones sencillas y Apache Spark para pipelines complejos.

Para ejecutar el código de transformación se usa una herramienta de planificación y orquestación, como Airflow.

Almacenamiento de datos

Un producto de datos suele necesitar almacenar un volumen considerable de datos en algún tipo de almacenamiento, como tablas o ficheros en un almacenamiento de objetos. La plataforma de datos lo proporciona en modo self-service. Cada producto de datos tiene su propio espacio privado, aislado de los demás.

Qué tecnología se usa y cómo se organizan los datos por dentro son detalles de implementación del producto de datos. Dependen de la plataforma de datos y los deciden los equipos de desarrollo. En muchos casos se recurre a tecnologías de almacenamiento orientadas a columnas.

Pruebas

Los productos de datos ofrecen conjuntos de datos gestionados y de alta calidad, así que, como en cualquier disciplina de ingeniería de software, las pruebas son imprescindibles. Hay varios tipos:

Las pruebas unitarias comprueban el propio código de transformación. Usan datos de entrada fijos y definen los datos de salida esperados.

Las pruebas de expectativas se ejecutan durante el despliegue sobre los modelos de datos reales y verifican que los datos de origen de los Input Ports, los modelos intermedios y el Output Port cumplen las expectativas definidas.

Las pruebas de calidad se ejecutan de forma periódica sobre datos reales para monitorizar los objetivos de nivel de servicio.

Documentación

Cuando los datos de un dominio se comparten con otros equipos, es importante describir su semántica y el contexto de negocio en el que se generaron.

Además de describir los atributos del modelo de datos, una buena documentación explica qué se puede esperar de los conjuntos de datos y da pistas iniciales sobre qué datos pueden resultar interesantes y cómo acceder a ellos.

Una buena forma de resolver la documentación es ofrecer un notebook interactivo (Jupyter, Google Colab, Databricks Notebook) con consultas de ejemplo.

Gestión de costes

Las tecnologías de datos se encarecen rápido cuando se usan a escala. Por eso es importante monitorizar los costes de los productos de datos. Pueden ser la base del precio que se factura a los Data Consumers, según lo acordado en los Data Contracts.

Policies as Code

Las políticas globales son las reglas del juego del Data Mesh, definidas por el grupo de gobernanza federada: por ejemplo, convenciones de nomenclatura, esquemas de clasificación de datos o control de acceso.

Aunque la mayoría de las políticas deberían implementarse a nivel de plataforma de datos, algunas hay que configurarlas a nivel de producto de datos, sobre todo cuando hace falta conocimiento del dominio o cuando los product owners tienen que decidir sobre permisos. Ejemplos: la clasificación a nivel de columna de los datos del dominio, el etiquetado de datos personales y el control de acceso.

Pipeline de CI/CD y planificación

Un producto de datos tiene su propio pipeline de CI/CD y sus propias definiciones de recursos de infraestructura. El pipeline se dispara cuando cambia el código de transformación o el modelo de datos: se ejecutan las pruebas y el producto de datos se despliega en la plataforma de datos conforme a las políticas globales. El equipo de plataforma de datos puede ofrecer módulos o plantillas para que los usen los equipos de producto de datos.

Para ejecutar el código de transformación y las pruebas se usa una herramienta de planificación y orquestación, como Airflow.

Observabilidad

Un producto de datos puede tener puertos y capacidades adicionales que los Data Consumers no usan directamente, pero que son importantes para operarlo. Entre ellos, puertos de monitorización, logging y funciones de administración.

Open Data Product Standard

Ya existe un estándar del sector para definir productos de datos: el Open Data Product Standard (ODPS) de Bitol. Es una especificación basada en YAML que puede usarse junto con su hermano, el Open Data Contract Standard (ODCS).

apiVersion: "v1.0.0"
kind: "DataProduct"
id: "shelf-warmers"
name: "Shelf Warmers"
status: "active"
description:
  purpose: "A list of articles with no sales in last 6 months"
team:
  name: "fulfillment"
tags:
- "demo"
outputPorts:
- name: "snowflake_fulfillment_shelf_warmers"
  version: "1"
  description: "A list of articles with no sales in last 6 months"
  type: "snowflake"
  contractId: "snowflake_fulfillment_shelf_warmers"
  authoritativeDefinitions:
  - type: "Snowflake WebUI"
    url: "https://example.com"
  customProperties:
  - property: "platformRole"
    value: "op_shelf_warmers_snowflake_fulfillment_shelf_warmers_role"
  - property: "status"
    value: "active"
  - property: "autoApprove"
    value: true
  - property: "containsPii"
    value: false
  - property: "server"
    value:
      schema: "SHELF_WARMERS"
      account: "lmtabcd-xn12345"
      database: "FULFILLMENT_DB"
  - property: "environment"
    value: "prod"
- name: "s3_fulfillment_shelf_warmers"
  version: "1"
  description: "A list of articles with no sales in last 6 months"
  type: "s3"
  contractId: "snowflake_fulfillment_shelf_warmers"
  authoritativeDefinitions:
  - type: "AWS Console"
    url: "https://example.com"
  customProperties:
  - property: "platformRole"
    value: "op_shelf_warmers_s3_fulfillment_shelf_warmers_role"
  - property: "status"
    value: "active"
  - property: "autoApprove"
    value: true
  - property: "containsPii"
    value: false
  - property: "server"
    value:
      location: "s3://my-bucket"
  - property: "environment"
    value: "prod"
customProperties:
- property: "platformRole"
  value: "dp_shelf_warmers_role"
- property: "type"
  value: "consumer-aligned"

Una especificación formal de producto de datos puede servir de base para automatizar procesos y para alimentar de metadatos a otros sistemas, como un catálogo de datos o un marketplace de datos.

Implementación de un producto de datos

Veamos ahora un ejemplo de cómo se puede implementar un producto de datos real. Según la plataforma de datos, hay distintas maneras de hacerlo:

Databricks: un producto de datos debería implementarse como un Databricks Asset Bundle
Snowflake: un producto de datos suele ser un proyecto dbt
BigQuery: un producto de datos suele ser un proyecto dbt
AWS S3 y Athena: un producto de datos se gestiona a menudo como un proyecto Terraform
Kafka: un proyecto Java

En este ejemplo usamos un stack tecnológico de AWS S3 y Athena. El equipo de plataforma de datos proporciona un módulo de Terraform que aprovisiona todos los servicios necesarios en la plataforma para ejecutar un producto de datos, conforme a las políticas y convenciones definidas por el grupo de gobernanza.

Los Data Product Developers tienen un repositorio Git por producto de datos. Usan el módulo de Terraform que se les proporciona y lo configuran para su producto de datos. En el mismo repositorio definen el código de transformación como una consulta SQL y un fichero JSON Schema con el modelo del Output Port y una descripción detallada del modelo de datos.

# dataproduct.tf
module shelf_warmers {
  source = "git@github.com:datamesh-architecture/terraform-dataproduct-aws-athena.git"
  version = "0.2.1"

  domain   = "fulfillment"
  name     = "shelf_warmers"
  description = "Shelf warmers are products that are not selling for 3 months and are taking up space on the shelf."

  schedule = "0 0 * * ? *" # Run at 00:00 am (UTC) every day

  transform = {
    query = "sql/transform.sql"
  }

  output = {
    format   = "PARQUET"
    schema   = "schema/shelf_warmers.schema.json"
    roles_allowed = ["coo"] # Policy as code
  }
}

Con terraform apply, normalmente lanzado desde el pipeline de CI/CD, se aprovisionan todos los recursos necesarios: buckets de S3, recursos de AWS Athena y funciones lambda. También se crean los permisos en AWS IAM.

El pipeline envía además los metadatos al catálogo de datos y al inventario de productos de datos.

Puedes ver un ejemplo de implementación de un módulo de Terraform en GitHub.

Entropy Data

Entropy Data es un software para gestionar productos de datos y Data Contracts y convertirlos en un marketplace de datos fácil de usar. Usa el estándar ODPS para construir un inventario completo de productos de datos. Los productos de datos se pueden importar desde plataformas de datos y catálogos de datos, y los metadatos se enriquecen sin esfuerzo mediante una interfaz web, un editor YAML, APIs e incluso editores de Excel. Los Data Consumers pueden explorar el inventario, encontrar los productos de datos que les interesan y solicitar acceso.

Ejemplo de un producto de datos en Entropy Data

A través de su API REST, Entropy Data se integra con todas las plataformas de datos y dispara la creación automática de permisos IAM en la plataforma en cuanto se crea o se actualiza un Data Contract.

Regístrate gratis o explora la demo interactiva de Entropy Data.