mapeo de datos

Mapeo de datos: 9 estrategias exitosas

Saber dónde existen los datos es la mitad de la batalla.

Si, perdón por el cliché, los datos son el nuevo petróleo, entonces el mapeo de datos se trata de asegurarse de que las cosas realmente fluyan a través de la tubería correctamente y hacia los destinos correctos.

Tradicionalmente, eso se refiere a la asignación de datos de origen a un sistema de destino, como una base de datos o un almacén de datos. Pero con la llegada de leyes como el Reglamento General de Protección de Datos (GDPR), la Ley de Privacidad del Consumidor de California (CCPA) y la nueva Ley de Protección de Datos del Consumidor (CDPA) de Virginia, el mapeo de datos ahora también tiene un contexto de cumplimiento de la privacidad.

Para saber qué datos tiene como organización, también necesita saber cómo se mueven. Por lo tanto, un mapa de flujo de back-end que ayude a una organización a cumplir, por ejemplo, con el RGPD podría parecerse al diagrama de la vieja escuela de flechas que apuntan desde la fuente al campo en los modelos de datos.

“El objetivo del mapeo de datos, en términos generales, es comprender qué tipos de información recopilamos, qué hacemos con ella, dónde reside en nuestros sistemas y cuánto tiempo la tenemos”, dijo Cillian Kieran, director ejecutivo y fundador de Ethyca.

¿Qué es el mapeo de datos?

“El objetivo del mapeo de datos, en términos generales, es comprender qué tipos de información recopilamos, qué hacemos con ella, dónde reside en nuestros sistemas y cuánto tiempo la tenemos”, según Cillian Kieran, director ejecutivo y fundador de Ethyca.

Ya sea que se trate del cumplimiento de la privacidad o simplemente de una buena gestión de la ingestión de datos, algunos buenos mapas pueden ayudar a mejorar mucha confusión.

“¿Cómo nos aseguramos, cuando definimos una política de lo que queremos hacer con la información, que la estamos aplicando en todos nuestros sistemas? Para hacerlo cumplir, tenemos que saber dónde existen los datos”, dijo Kieran.

Pero eso requiere tiempo y esfuerzo.

Los productos de linaje de datos han hecho la vida más fácil, al igual que las herramientas que pueden definir incluso los campos de datos con nombres más extraños. Pero nada reemplazó por completo la tarea de meterse debajo del capó y aprender exactamente cómo se conectan las cosas.

“Solo tiene que tomarse el tiempo para comprender qué representan realmente los datos dentro de ese campo”, dijo David Wilmer, gerente técnico de marketing de productos de Talend. “Si los datos que se supone que deben estar en el campo están ahí, y solo se trata de conectar esos puntos, entonces realmente se trata de tomarse el tiempo para comprender qué datos están, dónde y cómo se relacionan”.

¿Qué más contribuye a un buen mapeo de datos? Le pedimos a tres expertos que registraran lo que se debe y lo que no se debe hacer.

Los expertos:

  • Dimitri Sirota: CEO y cofundador de BigID
  • David Wilmer: director técnico de marketing de productos en Talend
  • Cillian Kieran: CEO y fundadora de Ethyca

La calidad de los datos es clave

mapeo de datos de david wilmerDavid Wilmer : Hay una serie de herramientas que facilitan la elaboración de perfiles de datos: ¿Son estos [campos] ciudades? ¿Son estos primeros nombres? Los diccionarios semánticos ayudan a definir, por ejemplo, el aspecto de una ciudad, el formato de una dirección o, en la forma más sencilla, el aspecto de una dirección de correo electrónico. Y si no coincide con esos criterios muy básicos, entonces no clasifique este campo o este elemento de datos de cierta manera.

De eso se trata realmente: poder profundizar y perfilar los datos. Comienza con la calidad de los datos: basura que entra, basura que sale. Si sus datos son deficientes al principio y no está haciendo nada para solucionarlos, tomará decisiones críticas a partir de datos realmente malos. Entonces, para mí, realmente comienza con la creación de esos datos de calidad, limpiándolos, estandarizándolos. Eso por sí solo también puede ayudar a mejorar y simplificar el proceso de mapeo.

Proporcione los metadatos

mapeo de datos de cilliaan kieranCillian Kieran : Lo que a menudo no sucede en [el proceso de extracción, transformación y carga (ETL)] es definir los metadatos en torno a la transformación. Por ejemplo, mover «Nombre» a un campo llamado «FName» a lo largo de un nuevo conjunto de registros que se identifica de manera diferente: la traducción de etiquetas y campos. Eso es problemático porque rompe el hilo lineal y hace que sea muy difícil identificar la relación con, por ejemplo, los nombres que fluyen desde un servicio de registro a un almacén de datos que se utilizan para enriquecer algunos de los datos de comportamiento.

Por lo tanto, un equipo de ingeniería de datos podría hacer mucho para mitigar los problemas si simplemente proporciona metadatos a la estructura de las entradas y salidas. Eso es esencialmente describir cada uno de los campos, los tipos de información que representa cada uno de los campos, en la entrada y en la salida. Una razón por la que es realmente difícil para las empresas es que no existe un estándar universalmente acordado en la comunidad de ingenieros sobre qué es la información personal y cómo se define.

Describir lo que constituye un correo electrónico versus un nombre versus un número de seguro social, eso es obvio. Cuando las empresas ingresan a los datos personalizados, esas definiciones se vuelven realmente difíciles porque no se entienden universalmente. Un ingeniero puede tener problemas para decidir cómo describir los datos que está recopilando para que puedan etiquetarse adecuadamente.

Relacionado: 19 herramientas de modelado de datos que debe conocer

Mantener el diccionario de datos…

Kieran : Necesita una comprensión uniforme de qué son los tipos de datos personales. Un diccionario debe estar disponible para que los ingenieros lo entiendan fácilmente. Eso podría ser como un glosario. También podría ser un servicio, algo que pueden usar mientras codifican para anclar un tipo de datos o tal vez un par de registros de muestra. Luego, el sistema responde con recomendaciones para el tipo de datos que hay.

“Nos envió 100 registros de datos de muestra y creemos, según el análisis, que se parece a los últimos cuatro dígitos de números de tarjetas de crédito”, por ejemplo. Así que el ingeniero no tiene que adivinar: el servicio hace la recomendación.

… pero automatice cuando sea posible

mapeo de datos de dimitri sirotaDimitri Sirota : [Las taxonomías] crearon una enorme carga para las personas que no necesariamente conocen los datos. Están diciendo: «Bueno, vamos a comenzar con la taxonomía y tratar de agrupar todo en ella». ¿Qué pasa si todo no encaja naturalmente dentro de estas barandillas?

Nosotros somos exponentes, y hay otros, de decir: “¿Por qué empezar con algún modelo mítico, casi olímpico: aquí están todos los dioses, y tienen que encajar en esto? [En cambio, estoy] combinando el Dios del vino y el Dios de la guerra porque no creé una separación al principio”. Comencemos con la realidad, la desordenada complejidad de los datos.

Si puede conocer sus datos por adelantado, deje que las máquinas recomienden cuáles deberían ser esas definiciones de datos. Además, reconcilie los lugares donde vea colisiones o posibles discrepancias: m.mail no es lo mismo que correo electrónico, etc.

Para hacer que el gobierno de datos dependa menos de estos administradores de datos sobrenaturales con una habilidad mítica para comprender los datos correctamente, necesitará comenzar con los datos y desarrollarlos, utilizando el aprendizaje automático y otras metodologías para prescribir el conjunto correcto de definiciones de datos. . Verá este tipo de inversión, donde ahora es posible crear realmente un inventario de datos, no solo a nivel de metadatos, sino también a nivel de valor de datos: saber literalmente qué hay en cada base de datos, MongoDB, SQL Server, Salesforce. Será más fácil eliminar esa carga de los administradores de datos para crear estos léxicos. Luego use a esos administradores más para la validación, menos para la creación.

Conviértelo en un hábito

Wilmer : [Agregar nuevas fuentes de datos] definitivamente puede tener más efectos posteriores, [por ejemplo, si] es un campo nuevo que necesita incluir, [debería] proliferar en el [sistema]. El mapeo de datos no es una propuesta única. Tiene que ser una actividad viva, que respira y que evoluciona y que el equipo de integración de datos tiene que seguir haciendo. No puedes simplemente escribirlo en un papel y guardarlo en un archivador. Incluso las fuentes existentes pueden agregar un campo o cambiar la forma en que almacenan los datos. Así que siempre tiene que ser lo más importante.

Mantener el diccionario semántico y el esquema dinámico que automáticamente toman en cuenta ese nuevo campo y pueden ajustar. Esas tecnologías realmente ayudan al mapeador de datos, pero aún deben abordarse de manera regular; no es un ejercicio, sino más bien un hábito.

Relacionado: Lago de datos vs. Almacén de datos: ¿Desaparecerá la línea ya borrosa?

No recopile demasiado demasiado rápido

Wilmer : Espero que la gente sea más consciente del hecho de que no puedes traer todas estas fuentes a la vez. Con un equipo pequeño, no puedes morder más de lo que puedes masticar. Obtenga esa fuente de datos que realmente impulsará su negocio y luego traiga datos complementarios que quizás le brinden más información sobre sus clientes o simplemente ayuden a simplificar la entrega de productos de un extremo a otro. Definitivamente puede ser una llamada de atención para una organización que recién comienza a decir: «Tal vez debamos dar un paso atrás». No puedes simplemente entrar con un equipo de tres y comenzar a traer 12 fuentes de datos diferentes y tratar de mapearlas también.

Kieran : El problema más común es una empresa que no ha pensado en esto porque solo está tratando de escalar y de repente acumula una gran cantidad de datos de clientes. Y ahora tiene que retroceder: una gran cantidad de refactorización para comprender qué ha recopilado y dónde. Al patear, lo conviertes en algo muy difícil de arreglar.

Considere, digamos, un pequeño sitio web de comercio electrónico que recopila datos de usuarios registrados y un poco de información analítica. Se escala, incorpora un equipo de inteligencia empresarial y quiere recopilar más datos de eventos a través del flujo de pago. Entonces comienza a recopilar la ubicación del usuario, tal vez la ubicación del mouse en la pantalla y la propensión a hacer clic en ciertos productos. Combina eso con algún otro almacén de datos, lo enriquece con datos que tal vez provengan de un proveedor externo. Tienes todas estas fuentes de datos.

El negocio de comercio D2C promedio en los EE. UU. tiene más de 60 fuentes de datos que fluyen hacia su almacén de datos.

ETL y linaje de datos

Sirota : Históricamente, intentaría obtener un linaje de cómo progresan sus datos examinando el ETL. Esto se remonta a los días de Informatica, cuando innovaron por primera vez en torno a la carga y la transformación. El problema con eso era doble. Uno, no siempre hay un ETL. En la empresa, a veces los archivos simplemente se mueven de un sistema a otro sin un proceso ETL formalizado. Lo hace si se muda a un almacén de datos y varios almacenes de datos. Pero eso no es universal. Y, por lo general, cuando piensa en el mapeo de datos, desea algo más completo.

El otro problema con ETL es que [las organizaciones son] muy dependientes de quien construye ese ETL, por lo que no todos pueden extraer esos sistemas para comprender exactamente lo que están haciendo. Ha habido intentos y esfuerzos para mejorar el linaje de datos. Yo diría que todavía es un trabajo en progreso.

Hay productos de linaje de datos que intentan hacer una variedad de cosas como extraer ETL. Algunos se basan en metadatos. ASG tiene un producto que extrae código para probar e interpretar [linaje]. Presentaremos un producto la segunda mitad del año que hace algo completamente diferente en torno a los algoritmos genéticos.

Limite el acceso y enmascare la información de identificación personal

Wilmer : Lo primero y más simple es implementar algún tipo de responsabilidad basada en roles. Limite el número de personas con acceso a esa información importante. Esa es su primera línea de defensa.

A continuación, sugeriría asegurarse de tener algún tipo de capacidad para enmascarar esos datos, de modo que pueda dárselos a su científico de datos, y ellos pueden hacer el análisis que necesitan hacer sin saber [información de identificación personal (PII)]. Esas son las dos cosas básicas, bastante fáciles de implementar.

Desde nuestro punto de vista en Talend, creemos que el mejor enfoque sería implementar un catálogo de datos. Eso le brinda la amplitud completa de esas capacidades: le brinda el linaje de los datos, lo que sucede, quién los toca, hacia dónde se dirigen. Esos son los tres grandes. Y a medida que crece como organización y obtiene más datos, esa es la progresión natural de abordar la gobernanza.

Kieran : La forma en que tratamos de ayudar a las empresas que intentan asimilar el cumplimiento de la privacidad de datos por primera vez es dividirlo en un conjunto de módulos simples. Lo primero que desea hacer es el mapeo de datos. Una vez que tenga ese mapa, querrá mantenerlo. Debido a que tiene eso en su lugar, entonces desea poder ofrecer a un usuario sus derechos sobre su información: solicitudes de derechos del sujeto de datos.

Lo segundo es implementar un proceso o herramientas automatizadas para simplificar eso, ya sea una solución automatizada o al menos un proceso que esté documentado que pueda respaldar y escalar según lo solicitado.

Y lo tercero es el consentimiento. Esta es la idea de que el estado puede decidir que un usuario tiene derecho a participar o no. Si alguien opta por no realizar un análisis de comportamiento en sus datos, la empresa que lo está haciendo debe identificar dónde están sus datos, cómo fluyen hacia esas herramientas de almacenamiento y análisis y eliminarlos de esos procesos. Eso no son banners de consentimiento de cookies, eso es una integración técnica profunda.

Date cuenta de que podrías tener más PII de lo que crees

Kieran : Es muy fácil suponer ingenuamente que una empresa no recopila mucha información personal. Los datos impulsan la ventaja competitiva, por lo que le sorprendería la cantidad de empresas que asumen que han acumulado una cantidad relativamente pequeña de información personal y, por lo tanto, una pequeña exposición al riesgo.

La verdad es que la mayoría de las empresas, ya sea que solo usen Google Analytics o marketing por correo electrónico, en realidad están acumulando una cantidad sustancial de información personal. Es posible que no se den cuenta del grado de riesgo al que eso los expone. Y eso es común a todos. La mayoría de las empresas, aparte de las empresas o empresas tecnológicas muy grandes y en etapa avanzada, no están bien educadas [sobre] ese riesgo.

Relacionado: Hadoop gobernó la era temprana de Big Data. ¿Puede subir de nuevo?