Fundamentos de la calidad de datos

Capítulo 1. Por qué la calidad de los datos merece atención, ahora

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Levanta la mano (o escupe el café, suspira profundamente y sacude la cabeza) si te suena este escenario.

Los datos son una prioridad para tu directora general, como suele serlo para las empresas que dan prioridad a lo digital, y domina las últimas y mejores herramientas de inteligencia empresarial. Tu director de tecnología está entusiasmado con la migración a la nube, y envía constantemente a tu equipo artículos que destacan las mediciones de rendimiento con algunas de las últimas tecnologías. Tus consumidores de datos en sentido descendente, incluidos los analistas de productos, los líderes de marketing y los equipos de ventas, confían en herramientas basadas en datos como las plataformas de gestión de relaciones con los clientes/experiencia del cliente (CRM/CXP), los sistemas de gestión de contenidos (CMS) y cualquier otra sigla bajo el sol para hacer su trabajo con rapidez y eficacia.

Como analista de datos o ingeniero responsable de gestionar estos datos y hacerlos utilizables, accesibles y fiables, rara vez pasa un día sin que tengas que atender alguna petición de tus interlocutores. Pero, ¿qué ocurre cuando los datos son erróneos?

¿Has estado alguna vez a punto de cerrar la sesión después de un largo día ejecutando consultas o construyendo canalizaciones de datos, sólo para que tu jefe de marketing te diga que "faltan datos" en un informe crítico? ¿Y un frenético correo electrónico de tu director de tecnología sobre "datos duplicados" en un panel de inteligencia empresarial? ¿O una nota de tu director general, el mismo que es tan entusiasta de los datos, sobre una cifra confusa o inexacta en su último informe?

Si alguna de estas situaciones te resulta familiar, no estás solo.

Este problema, a menudo conocido como "tiempo de inactividad de los datos", les ocurre incluso a las empresas más innovadoras y que dan prioridad a los datos, y, en nuestra opinión, es uno de los mayores retos a los que se enfrentan las empresas en el siglo XXI. El tiempo de inactividad de los datos se refiere a periodos de tiempo en los que faltan datos, son inexactos o erróneos, y se manifiesta en cuadros de mando obsoletos, informes imprecisos e incluso una mala toma de decisiones.

¿La raíz del tiempo de inactividad de los datos? Datos poco fiables, y muchos.

El tiempo de inactividad de los datos puede costar a las empresas más de millones de dólares al año, por no hablar de la confianza de los clientes. De hecho, ZoomInfo descubrió en 2019 que una de cada cinco empresas perdió un cliente debido a un problema de calidad de datos.

Como probablemente sepas, el balance final de tu empresa no es lo único que sufre por el tiempo de inactividad de los datos. La gestión de los problemas de calidad de los datos consume más del 40% del tiempo de tu equipo de datos, que podría dedicarse a proyectos más interesantes o a innovar para la empresa.

Esta estadística probablemente no te sorprenda. A nosotros, desde luego, no.

En su vida anterior, Barr Moses fue Vicepresidenta de Operaciones en una empresa de software de éxito de clientes. Su equipo era responsable de la gestión de informes para la empresa en general, desde la generación de cuadros de mando para que su director general los utilizara durante las reuniones All Hands, hasta el establecimiento de estrategias para reducir la fuga de clientes basándose en las métricas de los usuarios. Era responsable de gestionar las operaciones de datos de su empresa y de asegurarse de que las partes interesadas estuvieran preparadas para el éxito cuando trabajaran con datos.

Barr nunca olvidará el día en que, al volver a su mesa después de una agotadora sesión de planificación de varias horas, encontró una nota adhesiva con las palabras "Los datos están mal" en el monitor de su ordenador. Esta revelación no sólo fue embarazosa; por desgracia, tampoco era infrecuente. Una y otra vez, ella y su equipo se encontraban con estos silenciosos y pequeños, pero potencialmente perjudiciales, problemas con sus datos.

Tenía que haber una forma mejor.

La mala calidad de los datos y los datos poco fiables han sido un problema para las organizaciones durante décadas, ya sea causado por informes deficientes, información falsa o errores técnicos. Y a medida que las organizaciones aprovechen cada vez más los datos y construyan ecosistemas e infraestructuras de datos cada vez más complejos, este problema no hará sino aumentar.

El concepto de "datos erróneos" y mala calidad de los datos ha existido casi desde que existen los seres humanos, aunque en formas diferentes. En el caso del capitán Robert Falcon Scott y otros de los primeros exploradores de la Antártida, la mala calidad de los datos (o más bien, la toma de decisiones sin información sobre los datos) les llevó a pronosticar de forma inexacta dónde y cuánto tardarían en llegar al Polo Sur, su destino objetivo.

En la memoria más reciente, también destacan varios accidentes. Por ejemplo, el infame accidente del Orbitador Climático de Marte en 1999. El Mars Climate Orbiter, una sonda espacial de la NASA, se estrelló como consecuencia de un error en la introducción de datos que produjo salidas en unidades que no eran del SI (Sistema Internacional) frente a las unidades del SI, lo que la acercó demasiado al planeta. Este accidente costó a la NASA la friolera de 125 millones de dólares. Al igual que las naves espaciales, los conductos analíticos pueden ser extremadamente vulnerables a los cambios más inocentes en cualquier fase del proceso. Y esto sólo araña la superficie.

El desafortunado incidente de la nota adhesiva de Barr le hizo pensar: "¡No puedo estar sola!" Junto con Lior Gavish, Barr se propuso llegar a la raíz del problema del "tiempo de inactividad de los datos". Juntos, entrevistaron a cientos de equipos de datos sobre sus mayores problemas, y una y otra vez, la calidad de los datos encabezaba la lista. Desde el comercio electrónico a la sanidad, empresas de todos los sectores se enfrentaban a problemas similares: los cambios de esquema hacían que se rompieran las canalizaciones de datos, aparecían duplicados de filas o columnas en los informes críticos para la empresa y faltaban datos en los cuadros de mando, lo que les llevaba mucho tiempo, dinero y recursos. También nos dimos cuenta de que tenía que haber una forma mejor de comunicar y abordar los problemas de calidad de los datos como parte de un ciclo iterativo de mejora de la fiabilidad de los datos y de creación de una cultura en torno a la confianza en los datos.

Estas conversaciones nos inspiraron para escribir este libro, con el fin de transmitir algunas de las buenas prácticas que hemos aprendido y desarrollado en relación con la gestión de la calidad de los datos en cada etapa de la cadena de datos, desde la ingesta hasta el análisis, y compartir cómo los equipos de datos en situaciones similares pueden ser capaces de evitar su propio tiempo de inactividad de los datos.

A efectos de este libro, "datos en producción" se refiere a los datos procedentes de sistemas fuente (como CRM, CMS y bases de datos de cualquiera de las otras analogías mencionadas anteriormente) que han sido ingeridos por tu almacén, lago de datos u otras soluciones de almacenamiento y procesamiento de datos, y que fluyen a través de tu canalización de datos (extracción-transformación-carga, o ETL) para que la capa de análisis pueda mostrarlos a los usuarios empresariales. Los conductos de datos pueden manejar tanto datos por lotes como datos en flujo, y a un alto nivel, los métodos para medir la calidad de los datos para cualquiera de los dos tipos de activos son prácticamente los mismos.

El tiempo de inactividad de los datos tiene su corolario en la ingeniería de software y las operaciones de los desarrolladores, un mundo en el que el tiempo de actividad o inactividad de las aplicaciones (es decir, la frecuencia con la que tu software o servicio estaba "disponible" o "activo" o "no disponible" o "inactivo") se mide escrupulosamente para garantizar que el software es accesible y tiene un buen rendimiento. Muchos ingenieros de fiabilidad de sitios web utilizan el "tiempo de actividad" como medida porque se correlaciona directamente con el impacto en el cliente de un mal rendimiento del software en la empresa. En un mundo en el que "cinco nueves" (en otras palabras, 99,999% de tiempo de actividad) de fiabilidad se está convirtiendo en la norma del sector, ¿cómo podemos aplicar esto a los datos?

En este libro, abordaremos cómo los equipos de datos modernos pueden crear tecnologías, equipos y procesos más resistentes para garantizar una alta calidad y fiabilidad de los datos en sus organizaciones.

En este capítulo, empezaremos por definir qué significa calidad de datos en el contexto de este libro. A continuación, enmarcaremos el momento actual para comprender mejor por qué la calidad de los datos es más importante que nunca para los líderes de datos. Y, por último, examinaremos más detenidamente cómo los mejores equipos pueden lograr una alta calidad de los datos en cada etapa del proceso de datos y qué se necesita para mantener la confianza en los datos a gran escala. Este libro se centra principalmente en la calidad de los datos como una función de la alimentación de los conductos de datos analíticos para la construcción de cuadros de mando de toma de decisiones, productos de datos, modelos de aprendizaje automático (ML) y otros resultados de la ciencia de datos.

¿Qué es la calidad de los datos?

El concepto de calidad de los datos no es nuevo: ¡la "calidad de los datos" existe desde que el ser humano recopila datos!

En las últimas décadas, sin embargo, la definición de calidad de los datos ha empezado a cristalizar como una función de medición de la fiabilidad, integridad y exactitud de los datos en relación con el estado de lo que se informa. Como se suele decir, no se puede gestionar lo que no se mide, y una alta calidad de los datos es la primera etapa de cualquier programa analítico sólido. La calidad de los datos es también una forma muy poderosa de comprender si tus datos se ajustan a las necesidades de tu empresa.

A efectos de este libro, definimos la calidad de los datos como la salud de los datos en cualquier fase de su ciclo de vida. La calidad de los datos puede verse afectada en cualquier fase de la cadena de datos, antes de la ingestión, en producción o incluso durante el análisis.

En nuestra opinión, la calidad de los datos suele tener mala reputación. Los equipos de datos saben que tienen que darle prioridad, pero no suena tan bien como "aprendizaje automático", "ciencia de datos" o incluso "análisis", y muchos equipos no tienen el ancho de banda o los recursos para contratar a alguien a tiempo completo para gestionarla. En su lugar, las empresas con pocos recursos confían en los propios analistas de datos e ingenieros para gestionarlo, desviándolos de proyectos que se perciben como más interesantes o innovadores.

Pero si no puedes confiar en los datos y en los productos de datos que alimentan, ¿cómo pueden los usuarios de datos confiar en que tu equipo aporte valor? La frase "no tener datos es mejor que tener datos malos" es muy utilizada por los profesionales del sector, y aunque sin duda tiene mérito, a menudo no es una realidad.

Los problemas de calidad de los datos (o, el tiempo de inactividad de los datos) son prácticamente inevitables dado el ritmo de crecimiento y consumo de datos de la mayoría de las empresas. Pero si entendemos cómo definimos la calidad de los datos, resulta mucho más fácil medirla y evitar que cause problemas en las fases posteriores.

Enmarcar el momento actual

Los equipos técnicos llevan controlando -y tratando de mejorar- la calidad de los datos tanto tiempo como los datos analíticos, pero hasta la década de 2020 la calidad de los datos no se ha convertido en una prioridad absoluta para muchas empresas. A medida que los datos se convierten no sólo en un producto, sino en un bien financiero para muchas organizaciones, es importante que se pueda confiar en esta información.

Como resultado, las empresas tratan cada vez más sus datos como si fueran código, aplicando a sus organizaciones y arquitecturas de datos marcos y paradigmas que son estándar desde hace tiempo entre los equipos de ingeniería de software. Las operaciones de desarrollo (DevOps), un campo técnico dedicado a acortar el ciclo de vida del desarrollo de sistemas, dieron lugar a buenas prácticas líderes en el sector, como la ingeniería de fiabilidad de sitios (SRE), CI/CD (integración continua / implementación continua) y las arquitecturas basadas en microservicios. En resumen, el objetivo de DevOps es lanzar software más fiable y eficaz mediante la automatización.

En los últimos años, cada vez más empresas han aplicado estos conceptos a los datos en forma de "DataOps". DataOps se refiere al proceso de mejorar la fiabilidad y el rendimiento de tus datos mediante la automatización, reduciendo los silos de datos y fomentando una analítica más rápida y tolerante a fallos.

Desde 2019, empresas como Intuit, Airbnb, Uber y Netflix han escrito prolíficamente sobre su compromiso de garantizar datos fiables y de alta disponibilidad para las partes interesadas en toda la empresa mediante la aplicación de las buenas prácticas de DataOps. Además de impulsar la toma de decisiones basada en análisis (es decir, estrategia de producto, modelos financieros, marketing de crecimiento, etc.), los datos producidos por estas empresas impulsan sus aplicaciones y servicios digitales. Los datos inexactos, ausentes o erróneos pueden costarles tiempo, dinero y la confianza de sus clientes.

A medida que estos monstruos de la tecnología arrojan cada vez más luz sobre la importancia y los retos de lograr una alta calidad de los datos, otras empresas de todos los tamaños y sectores empiezan a tomar nota y a replicar estos esfuerzos, desde la implementación de pruebas más sólidas hasta la inversión en buenas prácticas de DataOps, como el monitoreo y la observabilidad de los datos.

Pero, ¿qué ha llevado a esta necesidad de una mayor calidad de los datos? ¿Qué ha cambiado en el panorama de los datos para facilitar el auge de DataOps y, por tanto, el auge de la calidad de los datos? A continuación profundizaremos en estas cuestiones.

Comprender el "Aumento del Tiempo de Inactividad de los Datos"

Con una mayor atención a la monetización de los datos, junto con el deseo siempre presente de aumentar la precisión de los datos, tenemos que comprender mejor algunos de los factores que pueden provocar el tiempo de inactividad de los datos. A continuación examinaremos más detenidamente las variables que pueden afectar a tus datos.

Migración a la nube

Hace veinte años, tu almacén de datos (un lugar para transformar y almacenar datos estructurados) probablemente habría vivido en el sótano de una oficina, no en AWS o Azure. Ahora, con el auge de los análisis basados en datos, los equipos de datos interfuncionales y, lo que es más importante, la nube, las soluciones de almacenamiento de datos en la nube como Amazon Redshift, Snowflake y Google BigQuery se han convertido en opciones cada vez más populares para las empresas que apuestan por los datos. En muchos sentidos, la nube hace que los datos sean más fáciles de gestionar, más accesibles a una mayor variedad de usuarios y mucho más rápidos de procesar.

Poco después de que los almacenes de datos se trasladaran a la nube, también lo hicieron los lagos de datos (un lugar para transformar y almacenar datos no estructurados), dando a los equipos de datos una flexibilidad aún mayor a la hora de gestionar sus activos de datos. A medida que las empresas y sus datos se trasladaban a la nube, la toma de decisiones basada en el análisis (y la necesidad de datos de alta calidad) se convirtió en una prioridad mayor para las empresas.

Más fuentes de datos

Hoy en día, las empresas utilizan entre docenas y cientos de fuentes de datos internas y externas para producir análisis y modelos de ML. Cualquiera de estas fuentes puede cambiar de forma inesperada y sin previo aviso, comprometiendo los datos que la empresa utiliza para tomar decisiones.

Por ejemplo, un equipo de ingenieros puede hacer un cambio en el sitio web de la empresa, modificando así la salida de un conjunto de datos que es clave para los análisis de marketing. Como resultado, las métricas clave de marketing pueden ser erróneas, lo que lleva a la empresa a tomar decisiones equivocadas sobre campañas publicitarias, objetivos de ventas y otros proyectos importantes que impulsan los ingresos.

Canalizaciones de datos cada vez más complejas

Las canalizaciones de datos se han vuelto cada vez más complejas, con múltiples etapas de procesamiento y dependencias no triviales entre varios activos de datos, como resultado de herramientas más avanzadas (y dispares), más fuentes de datos y la creciente diligencia concedida a los datos por la dirección ejecutiva. Sin embargo, sin visibilidad de estas dependencias, cualquier cambio realizado en un conjunto de datos puede tener consecuencias imprevistas que afecten a la corrección de los activos de datos dependientes.

En resumen, en una canalización de datos ocurren muchas cosas. Los datos de origen se extraen, ingieren, transforman, cargan, almacenan, procesan y entregan, entre otros posibles pasos, con muchas API e integraciones entre las distintas etapas de la canalización. En cada coyuntura, existe la posibilidad de que se produzca un tiempo de inactividad de los datos, al igual que existe la posibilidad de que se produzca un tiempo de inactividad de la aplicación cada vez que se fusiona el código. Además, las cosas pueden ir mal incluso cuando los datos no están en una coyuntura crítica, por ejemplo, cuando los datos se migran entre almacenes o se introducen manualmente en un sistema fuente.

Equipos de datos más especializados

A medida que las empresas confían cada vez más en los datos para tomar decisiones inteligentes, contratan cada vez más analistas de datos, científicos de datos e ingenieros de datos para construir y mantener las canalizaciones de datos, los análisis y los modelos de ML que impulsan sus servicios y productos, así como sus operaciones empresariales.

Mientras que los analistas de datos son los principales responsables de recopilar, limpiar y consultar los conjuntos de datos para ayudar a las partes interesadas funcionales a producir perspectivas ricas y procesables sobre el negocio, los ingenieros de datos son responsables de garantizar que las tecnologías y los sistemas subyacentes que impulsan estos análisis sean eficaces, rápidos y fiables. En la industria, los científicos de datos suelen recopilar, manejar, aumentar y dar sentido a los datos no estructurados para mejorar el negocio. La distinción entre analistas de datos y científicos de datos puede ser un poco vaga, y los títulos y responsabilidades suelen variar en función de las necesidades de la empresa. Por ejemplo, a finales de la década de 2010, Uber cambió todos los títulos de los analistas de datos a científicos de datos tras una reestructuración organizativa.

A medida que los datos sean cada vez más fundamentales para la empresa, los equipos de datos no harán más que crecer. De hecho, las empresas más grandes pueden apoyar funciones adicionales, como administradores de datos, líderes de gobernanza de datos, analistas de operaciones e incluso ingenieros de análisis (una función híbrida de ingeniero de datos y analista muy popular entre las nuevas empresas y las empresas medianas que pueden no tener los recursos para apoyar a un gran equipo de datos).

Con todos estos usuarios diferentes tocando los datos, la falta de comunicación o la coordinación insuficiente son inevitables y harán que estos complejos sistemas se rompan cuando se hagan cambios. Por ejemplo, un nuevo campo añadido a una tabla de datos por un equipo puede hacer que falle la canalización de otro equipo, con la consiguiente falta de datos o datos parciales. En sentido descendente, estos datos erróneos pueden suponer millones de dólares en ingresos perdidos, erosión de la confianza de los clientes e incluso riesgo de cumplimiento.

Equipos de datos descentralizados

A medida que los datos se convierten en un elemento central de las operaciones empresariales, cada vez más equipos funcionales de toda la empresa se han implicado en la gestión y el análisis de datos para agilizar y acelerar el proceso de recopilación de información. En consecuencia, cada vez más equipos de datos están adoptando un modelo distribuido y descentralizado que imita la migración en todo el sector de las arquitecturas monolíticas a las de microservicios, que tomó por asalto el mundo de la ingeniería de software a mediados de la década de 2010.

¿Qué es una arquitectura de datos descentralizada? No debe confundirse con la malla de datos, que es un paradigma organizativo que aprovecha un diseño distribuido y orientado al dominio, una arquitectura de datos descentralizada está gestionada por un equipo central de plataforma de datos, con equipos analíticos y de ciencia de datos distribuidos por toda la empresa. Cada vez son más los equipos que se inclinan por el modelo de analista de datos incrustado que se apoyan en este tipo de arquitectura.

Por ejemplo, tu empresa de 200 personas puede contar con un equipo de 3 ingenieros de datos y 10 analistas de datos, con analistas distribuidos en equipos funcionales para apoyar mejor las necesidades de la empresa. Estos analistas dependerán de los equipos operativos o de los equipos de datos centralizados, pero serán propietarios de conjuntos de datos y funciones de elaboración de informes específicos. Múltiples dominios generarán y aprovecharán datos, lo que conduce a la inevitabilidad de que los conjuntos de datos utilizados por múltiples equipos se dupliquen, desaparezcan o se queden obsoletos con el tiempo. Si estás leyendo este libro, probablemente no te resulte extraña la experiencia de utilizar un conjunto de datos que ya no es relevante, ¡sin que tú lo sepas!

Otras tendencias del sector que contribuyen al momento actual

Además de los factores antes mencionados, que con frecuencia provocan la inactividad de los datos, también se están produciendo varios cambios en la industria como resultado de la innovación tecnológica, que están impulsando la transformación del panorama de los datos. Todos estos cambios contribuyen a esta mayor atención a la calidad de los datos.

Malla de datos

Del mismo modo que los equipos de ingeniería de software pasaron de las aplicaciones monolíticas a las arquitecturas de microservicios, la malla de datos es, en muchos sentidos, la versión de la plataforma de datos de los microservicios. Es importante señalar que el concepto de malla de datos es incipiente, y hay mucho debate en la comunidad de datos sobre cómo (o si tiene sentido) ejecutarlo tanto a nivel cultural como técnico.

Tal y como la definió por primera vez Zhamak Dehghani, consultor de Thoughtworks y artífice original del término, una malla de datos, ilustrada en la Figura 1-1, es un paradigma sociotécnico que reconoce las interacciones entre las personas y la arquitectura y las soluciones técnicas en organizaciones complejas. La malla de datos adopta la ubicuidad de los datos en la empresa aprovechando un diseño de autoservicio orientado al dominio. Utiliza la teoría de Eric Evans del diseño orientado al dominio, un paradigma de desarrollo de software flexible y escalable que hace coincidir la estructura y el lenguaje de tu código con su correspondiente dominio empresarial.

A diferencia de las infraestructuras de datos monolíticas tradicionales, que gestionan el consumo, el almacenamiento, la transformación y la salida de datos en un lago de datos central, una malla de datos admite consumidores de datos distribuidos y específicos de cada dominio, y visualiza los "datos como un producto", en el que cada dominio gestiona sus propios conductos de datos. El tejido que conecta estos dominios y sus activos de datos asociados es una capa de interoperabilidad universal que aplica la misma sintaxis y normas de datos.

Las mallas de datos federan la propiedad de los datos entre los propietarios de los datos del dominio, que son responsables de proporcionar sus datos como productos, al tiempo que facilitan la comunicación entre los datos distribuidos en distintas ubicaciones.

Mientras que la infraestructura de datos es responsable de proporcionar a cada dominio las soluciones con las que procesarlos, los dominios se encargan de gestionar la ingestión, limpieza y agregación de los datos para generar activos que puedan utilizar las aplicaciones de inteligencia empresarial. Cada dominio es responsable de ser propietario de sus pipelines, pero hay un conjunto de capacidades aplicadas a todos los dominios que almacena, cataloga y mantiene los controles de acceso a los datos brutos. Una vez que los datos han sido servidos y transformados por un dominio determinado, los propietarios del dominio pueden aprovecharlos para sus necesidades analíticas u operativas.

Figura 1-1. La malla de datos, promovida por Zhamak Dehghani, impulsa una arquitectura de datos descentralizada y orientada a los dominios, que se basa en datos fiables de alta calidad y en una gobernanza universal.

El paradigma de la malla de datos sólo tiene éxito si los datos son fiables y dignos de confianza, y si esta "capa de interoperabilidad universal" se aplica en todos los ámbitos. ¿La única forma de que los datos sean fiables y dignos de confianza? Prestando mucha atención a la calidad de los datos mediante pruebas, monitoreo y observabilidad.

Muchas empresas están adoptando el paradigma de la malla de datos, sobre todo las grandes organizaciones que necesitan múltiples dominios de datos. Por ejemplo, en un artículo de blog de enero de 2021 escrito por el antiguo vicepresidente de Ingeniería de Datos de Intuit, Mammad Zadeh, y Raji Arasu, vicepresidente senior de Servicios y Experiencias Básicas de Intuit, Intuit se posiciona como una "empresa de plataformas expertas impulsada por la IA", cuya plataforma "recopila, procesa y transforma un flujo constante de datos en una malla conectada de datos de alta calidad". Otro ejemplo es JPMorgan Chase, que construyó una arquitectura de malla de datos para ayudarles a delimitar la propiedad de los datos entre funciones analíticas discretas y mejorar la visibilidad del intercambio de datos en toda la empresa.

Sea cual sea tu punto de vista sobre la malla de datos, lo cierto es que ha tomado por asalto a la comunidad de datos y ha suscitado grandes conversaciones -y artículos de blog- sobreel futuro de nuestras arquitecturas de datos distribuidos y estructuras de equipo.

Transmisión de datos

El streaming de datos se refiere al proceso de transmitir un flujo continuo de datos a tu pipeline para generar rápidamente perspectivas en tiempo real. Tradicionalmente, la calidad de los datos se reforzaba probando los datos por lotes antes de que entraran en los conductos de producción, pero cada vez más, las empresas buscan más análisis en tiempo real. Aunque esto tiene el potencial de agilizar las perspectivas, también abre mayores interrogantes y retos relacionados con la calidad de los datos, ya que los datos en flujo son datos "en movimiento".

Cada vez más, las organizaciones adoptan tanto el procesamiento por lotes como el procesamiento por flujos, lo que obliga a los equipos de datos a replantearse su enfoque de las pruebas y la observación de sus datos.

El auge del lago de datos

¿Almacén de datos o lago de datos? Esa es la cuestión, al menos si preguntas a un ingeniero de datos. Tanto los almacenes de datos, un repositorio de datos estructurados, como los lagos de datos, una reserva de datos brutos no estructurados, se basan en datos de alta calidad para su procesamiento y transformación. Cada vez más, los equipos de datos optan por utilizar tanto almacenes de datos como lagos de datos para dar cabida a las crecientes necesidades de datos de su empresa. Conoce: el lago de datos.

Los lagos de datos aparecieron por primera vez en escena cuando los proveedores de almacenes en la nube empezaron a añadir funciones que ofrecen ventajas de estilo lago, como Redshift Spectrum o Databricks Lakehouse. Del mismo modo, los lagos de datos han ido añadiendo tecnologías que ofrecen prestaciones al estilo de los almacenes, como la funcionalidad y el esquema SQL. Hoy en día, las diferencias históricas entre almacenes y lagos se están reduciendo, de modo que puedes acceder a lo mejor de ambos mundos en un solo paquete.

Esta migración al modelo lakehouse sugiere que los pipelines son cada vez más complejos, y mientras que algunos podrían elegir un proveedor dedicado para abordar ambos, otros están migrando los datos a múltiples capas de almacenamiento y procesamiento, lo que conduce a más oportunidades para que los datos del pipeline rompan el equilibrio con amplias pruebas.

Resumen

El auge de la nube, las arquitecturas y los equipos de datos distribuidos y la tendencia a la producción de datos han hecho recaer en los responsables de datos la responsabilidad de ayudar a sus empresas a conseguir datos más fiables (que conduzcan a análisis más fiables). Conseguir datos fiables es un maratón, no un sprint, e implica muchas etapas de tu canal de datos. Además, comprometerse a mejorar la calidad de los datos es mucho más que un reto técnico; también tiene mucho de organizativo y cultural. En el próximo capítulo, hablaremos de algunas tecnologías que tu equipo puede utilizar para evitar que se rompan los conductos y crear procesos y marcos repetibles e iterativos con los que comunicar, abordar e incluso evitar mejor los tiempos de inactividad de los datos.