Cómo construir un buen Data Product

En el artículo sobre ¿Cómo aplicar “Datos como un Producto”? Hablamos sobre cómo podemos empezar a construir Data Products y qué consideraciones tomar para decidir si debemos construirlo y por qué es importante hacerlo.

De momento, todavía no hemos hablado cómo construir un Data Product de 0 a 1 ni hemos hablado de qué consideraciones tomar para que el data product sea bueno.

Por bueno, me refiero a que pueda cumplir con ciertos componentes básicos para que pueda cumplir lo que esperamos de un Data Product (ej: fácil de usar).

Cuando pensamos en un Data Product, estamos hablando de cualquier proceso que use los datos para conseguir un resultado pero queremos que este proceso sea independiente y que sea fácil de construir, deployar y manejar.

Por esta definición, cualquier análisis hecho por un equipo de Business Analytics no “necesariamente» va a ser un Data Product.

Esto no quiere decir que un miembro del equipo de Business Analytics no pueda construir un buen Data Product (más de eso en otro artículo).

Entonces, ¿qué necesita un Data Product para ser lo más útil posible para la empresa?

Si pensamos en una startup con pocas fuentes de datos, tal vez esta pregunta no hace sentido.

Pero si asumimos que esta empresa va a crecer en complejidad y cada vez va a tener más fuentes, más productos de datas y más necesidades de análisis entonces sí es importante que tomemos en cuenta algunas consideraciones para no acumular deuda técnica en nuestros productos de datos y podamos escalar de la mejor manera posible.

Vamos a hacer una lista de características que necesitamos considerar y la vamos a separar en dos, en base a lo que no es negociable y lo que, aunque siempre importante, puede esperar a tener una arquitectura de datos más compleja y avanzada .

Lo que debemos tomar en cuenta para construir un buen Data Product es:

1. Calidad:

Los datos deben ser confiables y precisos.

No importa cuál es el Data Product, sí es un modelo analítico o una fuente de datos, tenemos que estar seguros que la data es confiable y que es una fiel representación de lo que los datos quieren describir.

Por ejemplo, si estamos hablando de datos de todos nuestros clientes, queremos que los datos muestren a todos los clientes y no solo a un subconjunto.

Aunque la calidad no es un componente del producto (generalmente puedes tener procesos de QA para validar) siempre es bueno tener controles dentro del producto y encontrar errores antes de procesar los datos.

2. Seguridad:

Tanto cuando los datos están en movimiento como cuando están en reposo, debemos asegurarnos que tenemos controles sobre quiénes pueden acceder a los datos y cómo los pueden acceder.

Es necesario utilizar medidas de seguridad como encriptación de los datos para asegurarnos que datos confidenciales (clase 1, clase 2 y a veces clase 3) no puedan ser leídos por cualquiera y que solo las personas o sistemas que necesitan acceso a ciertos datos puedan acceder.

Con las nuevas regulaciones (ej: GDPR, CCPA) y posibles daños a la reputación de la empresa, es muy importante contar con seguridad para los datos.

3. Esquema:

Si pensamos en una base de datos, el esquema puede estar implícito porque hay que definirlo antes de guardar los datos.

Pero si estamos pensando en otras fuentes como archivos de datos o eventos de clientes, etc.

Es muy importante que definamos el esquema de los datos.

Esto incluye la cantidad de atributos (piensa en las columnas de la base de datos) por registro (piensa en las filas) y sus nombres, el tipo o formato de datos (ej: números, fechas, texto, etc) o identificadores únicos.

Es importante que tengamos un registro del esquema y que este esquema no cambie (más sobre esto más adelante).

4. Gobernanza:

Me gusta mucho esta definición de gobernanza de datos: “Maximizar acceso a datos de alta calidad pero minimizando el riesgo”.

Muchos de los conceptos que estamos mencionando en este listado son parte de la gobernanza de datos pero para este artículo vamos a limitar un poco la definición de gobernanza.

El tema de gobernanza de datos se resume en darle a los dueños de la data o data products la libertad de definir las políticas de su producto pero siempre manteniendo ciertas reglas globales de la compañía.

Un buen ejemplo es cómo nombramos los eventos o registros y sus propiedades o atributos.

Queremos que los dueños de los datos puedan tener autonomía sobre cómo nombrar estos eventos, en base a sus necesidades, pero también manteniendo una constancia en la empresa.

Por ejemplo, si tenemos una tabla de usuarios y llamamos una columna “país residencia” esperaríamos que en otras tablas, por ejemplo tabla de clientes potenciales, también la columna se llame “país residencia” y no “país origen”.

Esto permite que cualquier cliente o servicio que está leyendo los datos pueda saber qué información contiene este registro y no cometer errores, agilizando también modelos de self-service y eliminando la necesidad de tener expertos de cada set de datos.

5. Accesibilidad:

Debemos tomar en cuenta que los productos de datos tienen que ser accesibles. Esto puede sonar un poco básico pero muchas veces no se toma en cuenta quién o cómo se van a consumir los datos y esto ocasiona que no diseñemos bien el producto.

Por ejemplo, si queremos que el data product sea la fuente de un dashboard en Tableau entonces tenemos que asegurarnos que Tableau pueda acceder, leer e interpretar los datos.

Si los datos serán consumidos por un equipo de BI, tal vez es importante que los datos sean consumibles mediante un lenguaje como SQL y que no sean archivos de textos en formato json.

De igual forma, tenemos que pensar cómo van a llegar los datos al Data Product y estar seguros que nuestro Data Product pueda consumir los datos.

Por ejemplo, si los datos se ingestan por medio de un API entonces tenemos que habilitar la manera de escribir datos mediante esa conexión con el API.

6. Descubrimiento:

Los esquemas, metadata, políticas, etc. de cada Data Product deben estar representadas en un catálogo de datos.

Este catálogo es el “one stop shop” para poder encontrar todos los productos de datos de la empresa, qué datos contienen, cómo se accede, etc.

Idealmente el catálogo de datos se actualiza automáticamente sin necesidad de intervención de una persona, aunque esto puede ser tomado en cuenta cuando tu arquitectura esté más avanzada.

Lo más importante es que este catálogo de datos exista desde el día 1.

Estas son las 5 características que considero son básicas para que un Data Product sea lo más útil posible y que cumpla con los requisitos mencionados en el artículo ¿Cómo aplicar “Datos como un Producto”?.

Sin embargo, hay otras características que son importantes pero que puedes esperar a implementarlas al tener un equipo de datos más maduro.

Es bueno implementarlo o al menos tomarlo en cuenta desde el diseño del primer Data Product pero entiendo que no siempre será viable.

Estas características son:

1. Interoperabilidad:

Se refiere a la posibilidad de que cualquier consumidor de los datos los pueda acceder.

Puede ser mediante una consulta de SQL, una consulta mediante un API, una herramienta de datos como MixPanel, otros Data Products, Mensajes en un broker, etc.

Esto aplica tanto para la ingesta como para el consumo de datos. Para esto, es importante que exista una plataforma común (i.e. el mismo broker de datos, el mismo lenguaje de consulta, etc.).

Al inicio es sencillo porque los consumidores son pocos pero conforme tu empresa crece la forma de consumir los datos va a crecer también.

2. Contratos o Registro de Esquema:

Todos los Data Products deben tener un esquema definido y este esquema debe ser consistente.

Cualquier cambio al esquema de los datos puede romper algún proceso que dependa de este data product.

Cualquier cambio al esquema o a los datos debería ser reportado y registrado en el catálogo de datos, idealmente de manera automática.

Si tu empresa es pequeña y tiene uno o dos productos de datos tal vez esto no suena como un gran problema porque alguien puede avisar de cualquier cambio pero cuando hay muchos data products que dependen entre ellos, creo que es claro ver como es muy fácil que se rompa todo tu proceso de datos.

3. Limitado:

Un Data Product debería tener un dueño claro y almacenar datos de un tipo específico. Entre más granular, mejor.

Por ejemplo podemos tener un data product de ‘Usuarios’ pero esto puede contener demasiada información que no necesariamente tiene relación.

Tal vez una mejor opción sería tener, por ejemplo, dos data products, uno de ‘Usuarios Adquiridos’ y otro de ‘Usuarios Potenciales’.

Otro ejemplo podría ser un Data Product de ‘grandes empresas’ y otro de “pequeñas y medianas empresas».

Si estás empezando con tu empresa o Data Products, probablemente no tienes el equipo suficiente para tener un dueño por tipo de datos y tus data products van a tener que representar muchos tipos de datos.

Esto está bien, solo intenta tener en mente cómo podrías ser más granular con cada Data Product e ir implementándolo  poco a poco.

4. Histórico o Temporal:

Deben existir Logs que se publican cada vez que se hacen cambios a un data product.

Esto permite tener claridad sobre qué cambios podrían, potencialmente, romper o haber roto un proceso.

Los cambios se almacenan en el catálogo de datos.

5. Versiones de los contratos:

Al igual que con los logs de cambios, cada release de un Data Product que incluya cambios al esquema o tipos de datos y por lo tanto impacte el Contrato de Datos de debería tener un versionado que nos permita ser compatibles con versiones anteriores de nuestros productos.

Estas versiones se almacenan en el catálogo de datos.

6. Metadata:

Esto se refiere a datos sobre los datos.

Información como lineaje de datos (mapear las relaciones de dependencia entre Data Products, tanto fuentes como destinos y cómo los datos cambian en el proceso) esquemas, tipos de datos, instrucciones para acceder a los datos, ejemplos de código SQL o similar para usar los datos, a qué hora se actualiza y qué tan actualizados están los datos, etc.

Cada vez que la metadata cambia, se debería registrar el cambio en el Catálogo de Datos.

Luego de describir los componentes de un Data Product, tal vez te puede ayudar este diagrama para imaginar cómo se puede ver un modelo de un data product.

Algunos de estos conceptos pueden sonar como algo inalcanzable, sobre todo si estás iniciando, y tal vez puedas pensar que no son totalmente necesarios.

Si tu empresa es pequeña, tienes pocas fuentes de datos, pocos consumidores y un equipo pequeño entonces esto puede que sea cierto pero si quieres escalar tus datos y tener una arquitectura robusta, te recomiendo tener esto en cuenta.

Otra consideración, es que en todos los artículos en los que hemos hablado de data products, hemos visto diagramas en los que pareciera que los Data Products van en cascada, es decir que un Data Product depende directamente de otros que fueron generados antes que él.

En el ámbito de Analytics se está volviendo común una arquitectura llamada Data Mesh (no vamos a entrar en detalles en este artículo) que es básicamente un ecosistema de productores y consumidores de datos. 

Estos productores y consumidores están interconectados de alguna manera, todos consumen datos entre ellos, puede ser en tiempo real o en batch y todos dependen de contratos de datos para asegurar que los procesos de loss Data Products independientes no se rompan.

Digamos que es una forma asíncrona de consumir datos por los distintos consumidores de datos.

Para que esta arquitectura funcione, necesitamos tener todos los componentes mencionados anteriormente.

Un Data Mesh se podría ver algo así:

Si estamos diciendo que un Data Mesh es una arquitectura para una empresa más grande, ¿por qué lo mencionamos en este artículo?

Aunque el tema de un Data Mesh es un poco más complejo y avanzado, pensemos en un ejemplo muy común que podrías encontrarte en tu empresa.

Tienes una aplicación en tu página web que genera datos de visitantes en tiempo real (S1), algo como Google Analytics, una base de datos (S2) que muestra todos los usuarios que crearon una cuenta y una base de datos (S3) que muestra los usuarios que hicieron una compra.

Luego tienes un Data Product (DP1) que hace la relación entre visitas (S1) y usuarios que crearon una cuenta (S2), tienes un Data Product (DP2) que hace la relación entre usuarios (S2) y compras (S3) y un Data Product (DP3) que determina qué usuarios visitaron el sitio pero no crearon una cuenta.

Los datos de visitas web van a una aplicación de Product Analytics, como MixPanel, los resultados de DP1 y DP2 van a una aplicación de visualización, como Tableau, y los resultados de DP3 van a una aplicación de marketing para tratar de atraer a los usuarios que no crearon una cuenta.

Según esta descripción, los tres Data Products podrían generar datos independientemente del resto de productos y solo van a depender de algunas de las fuentes.

Las aplicaciones que consumen los datos son específicas para cada caso de uso y para los datos generados por cada fuente o Data Product.

Cada fuente y cada Data Product se puede actualizar en momentos distintos siempre y cuando se puedan comunicar efectivamente entre ellos con una plataforma común.

Si la forma en que los datos se generan (el esquema) cambia, los Data Products no se pueden actualizar.

Si alguien quiere crear un reporte usando los datos o construir un nuevo Data Product, puede visitar el catálogo de datos y entender cómo hacer consultas.

Este podría ser un Data Mesh muy sencillo con pocos Data Products y que es un caso de uso de algo básico que podría existir en cualquier empresa.

Espero que con este ejemplo te quede un poco más claro por qué es importante que los Data Products tengan los componentes mencionados anteriormente y por qué es importante tomarlo en cuenta desde que empiezas el desarrollo de tu estrategia de datos.

The post Cómo construir un buen Data Product first appeared on KVERGE.