Probador de datos grandes y pequeños: tendencias, teoría, mi historia

Hola a todos, mi nombre es Alexander y soy un ingeniero de calidad de datos que verifica la calidad de los datos. Este artículo hablará sobre cómo llegué a esto y por qué en 2020 esta área de pruebas estaba en la cresta de una ola.

Probador de datos grandes y pequeños: tendencias, teoría, mi historia

Tendencia global

El mundo actual está experimentando otra revolución tecnológica, uno de cuyos aspectos es el uso de datos acumulados por todo tipo de empresas para promover su propio volante de ventas, ganancias y relaciones públicas. Parece que la presencia de datos de buena calidad, así como de cerebros capacitados que pueden ganar dinero con ellos (procesar correctamente, visualizar, construir modelos de aprendizaje automático, etc.), se ha convertido en la clave del éxito para muchos hoy en día. Si hace 15 o 20 años las grandes empresas se dedicaban principalmente a un trabajo intensivo de acumulación y monetización de datos, hoy en día esta es la suerte de casi todas las personas cuerdas.

En este sentido, hace varios años, todos los portales dedicados a la búsqueda de empleo en todo el mundo comenzaron a llenarse de vacantes para científicos de datos, ya que todos estaban seguros de que, contratando a un especialista así, sería posible construir un supermodelo de aprendizaje automático. , predecir el futuro y realizar un “salto cuántico” para la empresa. Con el tiempo, la gente se dio cuenta de que este enfoque casi nunca funciona en ninguna parte, ya que no todos los datos que caen en manos de estos especialistas son adecuados para entrenar modelos.

Y comenzaron las solicitudes de los científicos de datos: “Compremos más datos de estos y de aquellos...”, “No tenemos suficientes datos...”, “Necesitamos más datos, preferiblemente de alta calidad...” . A partir de estas solicitudes comenzaron a construirse numerosas interacciones entre empresas propietarias de uno u otro conjunto de datos. Naturalmente, esto requirió la organización técnica de este proceso: conectarse a la fuente de datos, descargarlos, verificar que estuvieran cargados en su totalidad, etc. El número de procesos de este tipo comenzó a crecer y hoy tenemos una gran necesidad de otro tipo de especialistas - ingenieros de calidad de datos - aquellos que monitorearían el flujo de datos en el sistema (canalizaciones de datos), la calidad de los datos en la entrada y salida y sacarían conclusiones sobre su suficiencia, integridad y otras características.

La tendencia de los ingenieros de calidad de datos nos llegó desde los EE. UU., donde, en medio de la furiosa era del capitalismo, nadie está dispuesto a perder la batalla por los datos. A continuación proporciono capturas de pantalla de dos de los sitios de búsqueda de empleo más populares en los EE. UU.: www.monstruo.com и www.dice.com — que muestra datos al 17 de marzo de 2020 sobre el número de vacantes publicadas recibidas utilizando las palabras clave: Calidad de datos y Científico de datos.

www.monstruo.com

Científicos de datos – 21416 vacantes
Calidad de datos – 41104 vacantes

Probador de datos grandes y pequeños: tendencias, teoría, mi historia
Probador de datos grandes y pequeños: tendencias, teoría, mi historia

www.dice.com

Científicos de datos – 404 vacantes
Calidad de datos – vacantes 2020

Probador de datos grandes y pequeños: tendencias, teoría, mi historia
Probador de datos grandes y pequeños: tendencias, teoría, mi historia

Evidentemente, estas profesiones no compiten entre sí. Con capturas de pantalla, solo quería ilustrar la situación actual del mercado laboral en términos de demanda de ingenieros de calidad de datos, de los cuales ahora se necesitan muchos más que científicos de datos.

En junio de 2019, EPAM, respondiendo a las necesidades del mercado de TI moderno, separó la calidad de datos en una práctica separada. Los ingenieros de Calidad de Datos, en el transcurso de su trabajo diario, gestionan datos, verifican su comportamiento en nuevas condiciones y sistemas, monitorean la relevancia de los datos, su suficiencia y relevancia. Con todo esto, en un sentido práctico, los ingenieros de Calidad de Datos realmente dedican poco tiempo a las pruebas funcionales clásicas. PERO Esto depende en gran medida del proyecto (daré un ejemplo a continuación).

Las responsabilidades de un ingeniero de calidad de datos no se limitan solo a comprobaciones manuales/automáticas de rutina de "nulos, recuentos y sumas" en las tablas de la base de datos, sino que requieren una comprensión profunda de las necesidades comerciales del cliente y, en consecuencia, la capacidad de transformar los datos disponibles en información comercial útil.

Teoría de la calidad de los datos

Probador de datos grandes y pequeños: tendencias, teoría, mi historia

Para imaginar mejor el papel de un ingeniero de este tipo, averigüemos qué es la calidad de los datos en teoría.

Calidad de los Datos — una de las etapas de la Gestión de Datos (todo un mundo que te dejaremos para que lo estudies por tu cuenta) y se encarga de analizar los datos según los siguientes criterios:

Probador de datos grandes y pequeños: tendencias, teoría, mi historia
Creo que no es necesario descifrar cada uno de los puntos (en teoría se llaman “dimensiones de datos”), están bastante bien descritos en la imagen. Pero el proceso de prueba en sí no implica copiar estrictamente estas características en casos de prueba y verificarlas. En Calidad de Datos, como en cualquier otro tipo de pruebas, es necesario, en primer lugar, basarse en los requisitos de calidad de datos acordados con los participantes del proyecto que toman las decisiones comerciales.

Dependiendo del proyecto de Calidad de datos, un ingeniero puede realizar diferentes funciones: desde un simple probador de automatización con una evaluación superficial de la calidad de los datos, hasta una persona que realiza un perfilado profundo de los datos de acuerdo con los criterios anteriores.

Una descripción muy detallada de la gestión de datos, la calidad de los datos y los procesos relacionados está bien descrita en el libro llamado "DAMA-DMBOK: Conocimientos sobre gestión de datos: 2.ª edición". Recomiendo encarecidamente este libro como introducción a este tema (encontrará un enlace al final del artículo).

Mi historia

En la industria de TI, ascendí desde probador junior en empresas de productos hasta ingeniero líder de calidad de datos en EPAM. Después de aproximadamente dos años de trabajo como tester, tenía la firme convicción de que había realizado absolutamente todo tipo de pruebas: regresión, funcionales, de estrés, de estabilidad, de seguridad, UI, etc., y había probado una gran cantidad de herramientas de prueba, habiendo Trabajó al mismo tiempo en tres lenguajes de programación: Java, Scala, Python.

Mirando hacia atrás, entiendo por qué mi conjunto de habilidades era tan diverso: estuve involucrado en proyectos basados ​​en datos, grandes y pequeños. Esto es lo que me trajo a un mundo de muchas herramientas y oportunidades de crecimiento.

Para apreciar la variedad de herramientas y oportunidades para adquirir nuevos conocimientos y habilidades, simplemente mire la imagen a continuación, que muestra las más populares en el mundo de “Datos e IA”.

Probador de datos grandes y pequeños: tendencias, teoría, mi historia
Este tipo de ilustraciones las recopila anualmente uno de los famosos capitalistas de riesgo, Matt Turck, que proviene del desarrollo de software. Aquí enlace a su blog y sociedad de capital riesgo, donde trabaja como socio.

Crecí profesionalmente especialmente rápido cuando era el único tester del proyecto, o al menos al principio del mismo. Es en ese momento cuando tienes que ser responsable de todo el proceso de prueba y no tienes oportunidad de retroceder, solo de avanzar. Al principio me dio miedo, pero ahora todas las ventajas de esta prueba me resultan obvias:

  • Comienzas a comunicarte con todo el equipo como nunca antes, ya que no hay ningún proxy para la comunicación: ni el director de pruebas ni los compañeros evaluadores.
  • La inmersión en el proyecto se vuelve increíblemente profunda y tienes información sobre todos los componentes, tanto en general como en detalle.
  • Los desarrolladores no te ven como "ese tipo de pruebas que no sabe lo que está haciendo", sino más bien como un igual que produce beneficios increíbles para el equipo con sus pruebas automatizadas y la anticipación de errores que aparecen en un componente específico del producto.
  • Como resultado, usted es más eficaz, más calificado y más solicitado.

A medida que el proyecto fue creciendo, en el 100% de los casos me convertí en mentor de nuevos evaluadores, enseñándoles y transmitiéndoles los conocimientos que yo mismo había aprendido. Al mismo tiempo, dependiendo del proyecto, no siempre recibí de la gerencia el más alto nivel de especialistas en pruebas automáticas y era necesario capacitarlos en automatización (para aquellos interesados) o crear herramientas para usar en las actividades cotidianas (herramientas para generar datos y cargarlos en el sistema, una herramienta para realizar pruebas de carga/pruebas de estabilidad “rápidamente”, etc.).

Ejemplo de un proyecto específico

Desafortunadamente, debido a obligaciones de confidencialidad, no puedo hablar en detalle sobre los proyectos en los que trabajé, pero daré ejemplos de tareas típicas de un ingeniero de calidad de datos en uno de los proyectos.

La esencia del proyecto es implementar una plataforma para preparar datos para entrenar modelos de aprendizaje automático basados ​​​​en ella. El cliente era una gran empresa farmacéutica de EE. UU. Técnicamente era un grupo Kubernetes, subiendo a AWS EC2 instancias, con varios microservicios y el proyecto de código abierto subyacente de EPAM - Legión, adaptado a las necesidades de un cliente concreto (ahora el proyecto ha renacido en odahu). Los procesos ETL se organizaron utilizando Flujo de aire Apache y moví datos de Fuerza de ventas sistemas de clientes en AWS S3 Cubos. A continuación, se implementó en la plataforma una imagen de Docker de un modelo de aprendizaje automático, que se entrenó con datos nuevos y, utilizando la interfaz REST API, produjo predicciones que eran de interés para el negocio y resolvió problemas específicos.

Visualmente todo se veía así:

Probador de datos grandes y pequeños: tendencias, teoría, mi historia
Hubo muchas pruebas funcionales en este proyecto y, dada la velocidad del desarrollo de funciones y la necesidad de mantener el ritmo del ciclo de lanzamiento (sprints de dos semanas), fue necesario pensar de inmediato en automatizar las pruebas de los componentes más críticos de el sistema. La mayor parte de la plataforma basada en Kubernetes estaba cubierta por pruebas automáticas implementadas en Marco de robot + Python, pero también era necesario soportarlos y ampliarlos. Además, para comodidad del cliente, se creó una GUI para administrar los modelos de aprendizaje automático implementados en el clúster, así como la capacidad de especificar dónde y dónde se deben transferir los datos para entrenar los modelos. Esta amplia incorporación implicó una expansión de las pruebas funcionales automatizadas, que se realizaron principalmente a través de llamadas a la API REST y una pequeña cantidad de pruebas de UI de extremo a extremo. Alrededor del ecuador de todo este movimiento, se nos unió un evaluador manual que hizo un excelente trabajo con las pruebas de aceptación de las versiones del producto y comunicándose con el cliente con respecto a la aceptación de la próxima versión. Además, gracias a la llegada de un nuevo especialista, pudimos documentar nuestro trabajo y agregar varias comprobaciones manuales muy importantes que eran difíciles de automatizar de inmediato.

Y finalmente, después de lograr la estabilidad de la plataforma y el complemento GUI, comenzamos a construir canalizaciones ETL utilizando Apache Airflow DAG. La verificación automatizada de la calidad de los datos se llevó a cabo escribiendo DAG de flujo de aire especiales que verificaron los datos en función de los resultados del proceso ETL. Como parte de este proyecto, tuvimos suerte y el cliente nos dio acceso a conjuntos de datos anónimos que probamos. Verificamos los datos línea por línea para verificar el cumplimiento de los tipos, la presencia de datos rotos, el número total de registros antes y después, la comparación de las transformaciones realizadas por el proceso ETL para agregación, el cambio de nombres de columnas y otras cosas. Además, estas comprobaciones se escalaron a diferentes fuentes de datos, por ejemplo, además de SalesForce, también a MySQL.

Los controles finales de calidad de los datos ya se llevaron a cabo en el nivel S3, donde se almacenaron y estaban listos para usar para entrenar modelos de aprendizaje automático. Para obtener datos del archivo CSV final ubicado en el S3 Bucket y validarlo, el código se escribió usando clientes boto3.

También existía el requisito por parte del cliente de almacenar parte de los datos en un S3 Bucket y parte en otro. Esto también requirió realizar controles adicionales para verificar la confiabilidad de dicha clasificación.

Experiencia generalizada de otros proyectos.

Un ejemplo de la lista más general de actividades de un ingeniero de Calidad de Datos:

  • Prepare datos de prueba (válidos, no válidos, grandes, pequeños) a través de una herramienta automatizada.
  • Cargue el conjunto de datos preparado en la fuente original y verifique que esté listo para su uso.
  • Inicie procesos ETL para procesar un conjunto de datos desde el almacenamiento de origen hasta el almacenamiento final o intermedio utilizando un determinado conjunto de configuraciones (si es posible, establezca parámetros configurables para la tarea ETL).
  • Verificar los datos procesados ​​por el proceso ETL por su calidad y cumplimiento de los requisitos comerciales.

Al mismo tiempo, el foco principal de las comprobaciones no debería centrarse sólo en el hecho de que el flujo de datos en el sistema, en principio, haya funcionado y llegado al final (lo que forma parte de las pruebas funcionales), sino principalmente en comprobar y validar los datos. para el cumplimiento de los requisitos esperados, identificación de anomalías y otras cosas.

Instrumentos

Una de las técnicas para dicho control de datos puede ser la organización de controles en cadena en cada etapa del procesamiento de datos, la llamada "cadena de datos" en la literatura: control de los datos desde la fuente hasta el punto de uso final. Estos tipos de comprobaciones se implementan con mayor frecuencia escribiendo consultas SQL de verificación. Está claro que dichas consultas deben ser lo más ligeras posible y verificar la calidad de los datos individuales (metadatos de tablas, líneas en blanco, NULL, errores de sintaxis, otros atributos necesarios para la verificación).

En el caso de las pruebas de regresión, que utilizan conjuntos de datos ya preparados (inmutables, ligeramente modificables), el código de prueba automática puede almacenar plantillas ya preparadas para comprobar el cumplimiento de la calidad de los datos (descripciones de los metadatos esperados de la tabla; objetos de muestra de filas que pueden ser seleccionados aleatoriamente durante la prueba, etc.).

Además, durante las pruebas, debe escribir procesos de prueba ETL utilizando marcos como Apache Airflow, Apache Spark o incluso una herramienta tipo nube de caja negra Preparación de datos de GCP, Flujo de datos de GCP Etcétera. Esta circunstancia obliga al ingeniero de pruebas a sumergirse en los principios de funcionamiento de las herramientas anteriores y, de manera aún más efectiva, realizar pruebas funcionales (por ejemplo, procesos ETL existentes en un proyecto) y utilizarlas para verificar los datos. En particular, Apache Airflow tiene operadores listos para trabajar con bases de datos analíticas populares, por ejemplo BigQuery de GCP. El ejemplo más básico de su uso ya ha sido descrito. aquí, así que no me repetiré.

Aparte de las soluciones ya preparadas, nadie le prohíbe implementar sus propias técnicas y herramientas. Esto no sólo será beneficioso para el proyecto, sino también para el propio ingeniero de calidad de datos, quien mejorará así sus horizontes técnicos y sus habilidades de codificación.

Cómo funciona en un proyecto real

Una buena ilustración de los últimos párrafos sobre la "cadena de datos", ETL y comprobaciones ubicuas es el siguiente proceso de uno de los proyectos reales:

Probador de datos grandes y pequeños: tendencias, teoría, mi historia

Aquí, varios datos (por supuesto, preparados por nosotros) ingresan al “embudo” de entrada de nuestro sistema: válidos, inválidos, mixtos, etc., luego se filtran y terminan en un almacenamiento intermedio, luego nuevamente sufren una serie de transformaciones. y se colocan en el almacenamiento final, desde donde, a su vez, se realizarán análisis, construcción de data marts y búsqueda de insights de negocio. En un sistema de este tipo, sin comprobar funcionalmente el funcionamiento de los procesos ETL, nos centramos en la calidad de los datos antes y después de la transformación, así como en el resultado para análisis.

Para resumir lo anterior, independientemente del lugar donde trabajé, en todos lados estuve involucrado en proyectos de Datos que compartían las siguientes características:

  • Sólo mediante la automatización se pueden probar algunos casos y lograr un ciclo de lanzamiento aceptable para la empresa.
  • El evaluador de un proyecto de este tipo es uno de los miembros más respetados del equipo, ya que aporta grandes beneficios a cada uno de los participantes (aceleración de las pruebas, buenos datos del científico de datos, identificación de defectos en las primeras etapas).
  • No importa si trabaja en su propio hardware o en la nube: todos los recursos se abstraen en un clúster como Hortonworks, Cloudera, Mesos, Kubernetes, etc.
  • Los proyectos se basan en un enfoque de microservicios, predomina la computación distribuida y paralela.

Me gustaría señalar que al realizar pruebas en el campo de la calidad de datos, un especialista en pruebas cambia su enfoque profesional al código del producto y las herramientas utilizadas.

Características distintivas de las pruebas de calidad de datos.

Además, para mí, he identificado las siguientes características distintivas de las pruebas en proyectos (sistemas) de datos (Big Data) (sistemas) y otras áreas (inmediatamente haré una reserva de que son MUY generalizadas y exclusivamente subjetivas):

Probador de datos grandes y pequeños: tendencias, teoría, mi historia

Enlaces de interés

  1. Teoría: DAMA-DMBOK: Conocimientos sobre gestión de datos: 2.ª edición.
  2. Centro de entrenamiento EPAM 
  3. Materiales recomendados para un ingeniero principiante en calidad de datos:
    1. Curso gratuito sobre Stepik: Introducción a las bases de datos
    2. Curso sobre LinkedIn Learning: Fundamentos de la ciencia de datos: ingeniería de datos.
    3. Artículo:
    4. Vídeo:

Conclusión

Calidad de los Datos es una dirección muy joven y prometedora, ser parte de la cual significa ser parte de una startup. Una vez en Data Quality, se verá inmerso en una gran cantidad de tecnologías modernas y demandadas, pero lo más importante es que se le abrirán enormes oportunidades para generar e implementar sus ideas. Podrá utilizar el enfoque de mejora continua no sólo en el proyecto, sino también en usted mismo, desarrollándose continuamente como especialista.

Fuente: habr.com

Añadir un comentario