Ola a todos, chámome Alexander e son enxeñeiro de calidade de datos que comproba a calidade dos datos. Este artigo falarase de como cheguei a isto e por que en 2020 esta área de probas estaba na crista dunha onda.
Tendencia global
O mundo actual está a vivir outra revolución tecnolóxica, un aspecto da cal é o uso dos datos acumulados por todo tipo de empresas para promover o seu propio volante de vendas, beneficios e RRPP. Parece que a presenza de bos datos (de calidade), así como cerebros cualificados que poden gañar cartos con eles (procesar, visualizar correctamente, construír modelos de aprendizaxe automática, etc.), convertéronse na clave do éxito para moitos hoxe en día. Se hai 15-20 anos as grandes empresas participaban principalmente nun traballo intensivo coa acumulación de datos e a monetización, hoxe é o destino de case todas as persoas sensatas.
Neste sentido, hai xa varios anos, todos os portais dedicados á busca de emprego en todo o mundo comezaron a cubrirse con prazas de Data Scientists, xa que todos estaban seguros de que, tendo contratado a tal especialista, sería posible construír un supermodelo de machine learning. , predecir o futuro e realizar un "salto cuántico" para a empresa. Co paso do tempo, a xente decatouse de que este enfoque case nunca funciona en ningún lugar, xa que non todos os datos que caen en mans deste tipo de especialistas son axeitados para modelos de adestramento.
E comezaron as peticións dos Data Scientists: "Compremos máis datos destes e deses...", "Non temos datos suficientes...", "Necesitamos máis datos, preferiblemente de alta calidade..." . A partir destas solicitudes, comezaron a construírse numerosas interaccións entre empresas propietarias dun ou outro conxunto de datos. Por suposto, isto requiriu a organización técnica deste proceso: conectarse á fonte de datos, descargalo, comprobar que estaba cargado por completo, etc. O número de tales procesos comezou a crecer e hoxe temos unha enorme necesidade doutro tipo de especialistas - Enxeñeiros de calidade de datos - aqueles que supervisarían o fluxo de datos no sistema (canalidades de datos), a calidade dos datos na entrada e na saída, e sacarían conclusións sobre a súa suficiencia, integridade e outras características.
A tendencia dos enxeñeiros de calidade de datos chegounos desde os EE. UU., onde, no medio da era furiosa do capitalismo, ninguén está preparado para perder a batalla polos datos. A continuación proporcionei capturas de pantalla de dous dos sitios de busca de emprego máis populares dos EUA: и — que mostra datos do 17 de marzo de 2020 sobre o número de prazas publicadas recibidas mediante as palabras clave: Data Quality and Data Scientist.
Data Scientists - 21416 prazas
Calidade de datos: 41104 prazas
Data Scientists – 404 prazas
Calidade de datos - prazas 2020
Obviamente, estas profesións de ningún xeito compiten entre si. Con capturas de pantalla só quería ilustrar a situación actual do mercado laboral en canto ás solicitudes de enxeñeiros de Data Quality, dos que agora se necesitan moito máis que Data Scientists.
En xuño de 2019, EPAM, respondendo ás necesidades do mercado de TI moderno, separou Data Quality nunha práctica separada. Os enxeñeiros de Calidade de Datos, no transcurso do seu traballo diario, xestionan os datos, comproban o seu comportamento en novas condicións e sistemas, supervisan a relevancia dos datos, a súa suficiencia e relevancia. Con todo isto, nun sentido práctico, os enxeñeiros de Data Quality realmente dedican pouco tempo ás probas funcionais clásicas, MAS isto depende moito do proxecto (poñerei un exemplo a continuación).
As responsabilidades dun enxeñeiro de calidade de datos non se limitan só ás comprobacións manuais/automáticas rutineiras de "nulos, contas e sumas" nas táboas de bases de datos, senón que requiren unha comprensión profunda das necesidades comerciais do cliente e, en consecuencia, a capacidade de transformar os datos dispoñibles en información comercial útil.
Teoría da calidade dos datos
Para imaxinar máis plenamente o papel deste enxeñeiro, imos descubrir o que é a calidade dos datos en teoría.
Calidade dos datos — unha das etapas da Xestión de Datos (todo un mundo que vos deixaremos para que estudes pola vosa conta) e encárgase de analizar os datos segundo os seguintes criterios:
Creo que non hai que descifrar cada un dos puntos (en teoría chámanse "dimensións de datos"), están bastante ben descritos na imaxe. Pero o proceso de proba en si non implica copiar estrictamente estas funcións en casos de proba e verificalas. En Data Quality, como en calquera outro tipo de probas, é necesario, en primeiro lugar, partir dos requisitos de calidade de datos acordados cos participantes no proxecto que toman decisións empresariais.
Dependendo do proxecto de calidade de datos, un enxeñeiro pode realizar diferentes funcións: desde un probador de automatización ordinario cunha avaliación superficial da calidade dos datos, ata unha persoa que realiza un perfil profundo dos datos segundo os criterios anteriores.
Unha descrición moi detallada da Xestión de Datos, Calidade de Datos e procesos relacionados está ben descrita no libro chamado "DAMA-DMBOK: Corpo de coñecemento de xestión de datos: 2ª edición". Recomendo encarecidamente este libro como introdución a este tema (encontrarás unha ligazón ao final do artigo).
A miña historia
No sector das TI, pasei de ser un probador júnior en empresas de produtos a un enxeñeiro principal de calidade de datos na EPAM. Despois duns dous anos de traballo como probador, tiven a firme convicción de que fixera absolutamente todo tipo de probas: regresión, funcionais, de estrés, estabilidade, seguridade, IU, etc.- e probei un gran número de ferramentas de proba, tendo traballou ao mesmo tempo en tres linguaxes de programación: Java, Scala, Python.
Mirando cara atrás, entendo por que o meu conxunto de habilidades era tan diverso: estiven involucrado en proxectos baseados en datos, grandes e pequenos. Isto é o que me levou a un mundo de moitas ferramentas e oportunidades de crecemento.
Para apreciar a variedade de ferramentas e oportunidades para adquirir novos coñecementos e habilidades, só tes que mirar a imaxe de abaixo, que mostra as máis populares no mundo de "Datos e IA".
Este tipo de ilustración é compilada anualmente por un dos famosos capitalistas de risco Matt Turck, que procede do desenvolvemento de software. Aquí ao seu blog e , onde traballa como socio.
Crecín profesionalmente especialmente rápido cando era o único probador do proxecto, ou polo menos ao comezo do proxecto. É nese momento no que tes que ser responsable de todo o proceso de proba e non tes oportunidade de retirarte, só adiante. Ao principio daba medo, pero agora todas as vantaxes desta proba son obvias para min:
- Comezas a comunicarte con todo o equipo como nunca antes, xa que non hai ningún proxy para a comunicación: nin o responsable da proba nin os compañeiros de proba.
- A inmersión no proxecto faise incriblemente profunda e tes información sobre todos os compoñentes, tanto en xeral como en detalle.
- Os desenvolvedores non te miran como "ese tipo das probas que non sabe o que está a facer", senón como un igual que produce beneficios incribles para o equipo coas súas probas automatizadas e a previsión de que aparezan erros nun compoñente específico do programa. produto.
- Como resultado, é máis eficaz, máis cualificado e máis demandado.
A medida que o proxecto foi medrando, no 100% dos casos convertínme en mentor de novos probadores, ensinándolles e transmitindo os coñecementos que eu mesmo aprendera. Ao mesmo tempo, dependendo do proxecto, non sempre recibín o máis alto nivel de especialistas en probas de automóbiles da dirección e había que formalos en automatización (para os interesados) ou crear ferramentas para o seu uso nas actividades cotiás (ferramentas). para xerar datos e cargalos no sistema, unha ferramenta para realizar probas de carga/estabilidade "rápidamente", etc.).
Exemplo dun proxecto concreto
Desafortunadamente, debido ás obrigas de non divulgación, non podo falar en detalle dos proxectos nos que traballei, pero vou dar exemplos de tarefas típicas dun Enxeñeiro de Calidade de Datos nun dos proxectos.
A esencia do proxecto é implementar unha plataforma para preparar datos para adestrar modelos de aprendizaxe automática baseados nela. O cliente era unha gran empresa farmacéutica dos EUA. Tecnicamente era un cluster , subindo a instancias, con varios microservizos e o proxecto Open Source subxacente de EPAM - , adaptado ás necesidades dun cliente concreto (agora o proxecto renace en ). Organizáronse os procesos ETL utilizando e trasladou datos de sistemas de clientes en Cubos. A continuación, despregouse na plataforma unha imaxe de Docker dun modelo de aprendizaxe automática, que foi adestrada en datos novos e, mediante a interface da API REST, produciu predicións que eran de interese para a empresa e resolveu problemas específicos.
Visualmente, todo parecía algo así:
Houbo moitas probas funcionais neste proxecto e, dada a velocidade de desenvolvemento de funcións e a necesidade de manter o ritmo do ciclo de lanzamento (sprints de dúas semanas), foi necesario pensar de inmediato en automatizar as probas dos compoñentes máis críticos de o sistema. A maior parte da plataforma baseada en Kubernetes estaba cuberta por autotests implementados en + Python, pero tamén foi necesario apoialos e amplialos. Ademais, para a comodidade do cliente, creouse unha GUI para xestionar os modelos de aprendizaxe automática despregados no clúster, así como a posibilidade de especificar onde e onde se deben transferir os datos para adestrar os modelos. Esta ampla adición supuxo unha expansión das probas funcionais automatizadas, que se fixeron principalmente mediante chamadas á API REST e un pequeno número de probas de IU de extremo 2. Ao redor do ecuador de todo este movemento, uniuse a nós un probador manual que fixo un excelente traballo coa proba de aceptación das versións do produto e comunicándose co cliente sobre a aceptación da próxima versión. Ademais, debido á chegada dun novo especialista, puidemos documentar o noso traballo e engadir varias comprobacións manuais moi importantes que eran difíciles de automatizar de inmediato.
E, finalmente, despois de que conseguimos a estabilidade da plataforma e do complemento da GUI sobre ela, comezamos a construír canalizacións ETL usando Apache Airflow DAG. A comprobación automatizada da calidade dos datos realizouse escribindo DAG especiais de fluxo de aire que verificaban os datos en función dos resultados do proceso ETL. Como parte deste proxecto, tivemos sorte e o cliente deunos acceso a conxuntos de datos anónimos nos que probamos. Comprobamos os datos liña por liña para o cumprimento dos tipos, a presenza de datos rotos, o número total de rexistros antes e despois, a comparación das transformacións realizadas polo proceso ETL para a agregación, o cambio de nomes de columnas e outras cousas. Ademais, estas comprobacións escalaron a diferentes fontes de datos, por exemplo, ademais de SalesForce, tamén de MySQL.
As comprobacións finais de calidade dos datos realizáronse xa no nivel S3, onde se almacenaron e estaban listos para usar para adestrar modelos de aprendizaxe automática. Para obter datos do ficheiro CSV final situado no S3 Bucket e validalos, escribiuse o código mediante .
Tamén había un requisito do cliente para almacenar parte dos datos nun S3 Bucket e parte noutro. Isto tamén requiriu escribir comprobacións adicionais para comprobar a fiabilidade desta clasificación.
Experiencia xeneralizada doutros proxectos
Un exemplo da lista máis xeral de actividades dun enxeñeiro de calidade de datos:
- Prepare datos de proba (válido non válido grande pequeno) mediante unha ferramenta automatizada.
- Cargue o conxunto de datos preparado na fonte orixinal e comprobe que está listo para o seu uso.
- Inicie procesos ETL para procesar un conxunto de datos desde o almacenamento de orixe ata o almacenamento final ou intermedio mediante un determinado conxunto de opcións (se é posible, estableza parámetros configurables para a tarefa ETL).
- Verificar a calidade dos datos procesados polo proceso ETL e o cumprimento dos requisitos comerciais.
Ao mesmo tempo, o foco principal das comprobacións debe estar non só no feito de que o fluxo de datos do sistema funcionou, en principio, e chegou a completarse (que forma parte das probas funcionais), senón principalmente na comprobación e validación de datos para cumprimento dos requisitos previstos, identificando anomalías e outras cousas.
Ferramentas
Unha das técnicas para tal control de datos pode ser a organización de verificacións en cadea en cada fase do procesamento de datos, a chamada "cadea de datos" na literatura: control dos datos desde a fonte ata o punto de uso final. Estes tipos de comprobacións implícanse a maioría das veces escribindo consultas SQL de comprobación. Está claro que tales consultas deben ser o máis lixeiras posible e comprobar pezas individuais da calidade dos datos (metadatos das táboas, liñas en branco, NULL, Erros na sintaxe - outros atributos necesarios para a comprobación).
No caso das probas de regresión, que usan conxuntos de datos prefabricados (inmutables, lixeiramente modificables), o código de autotest pode almacenar modelos preparados para comprobar o cumprimento da calidade dos datos (descricións dos metadatos da táboa esperados; obxectos de mostra de filas que se poden seleccionados aleatoriamente durante a proba, etc.).
Ademais, durante as probas, ten que escribir procesos de proba ETL usando marcos como Apache Airflow, ou mesmo unha ferramenta tipo nube de caixa negra , Etcétera. Esta circunstancia obriga ao enxeñeiro de probas a mergullarse nos principios de funcionamento das ferramentas anteriores e, aínda máis eficazmente, realizar probas funcionais (por exemplo, procesos ETL existentes nun proxecto) e utilizalos para comprobar os datos. En particular, Apache Airflow ten operadores preparados para traballar con bases de datos analíticas populares, por exemplo . O exemplo máis básico do seu uso xa foi esbozado , así que non me repetirei.
Ademais de solucións preparadas, ninguén che prohibe implementar as túas propias técnicas e ferramentas. Isto non só será beneficioso para o proxecto, senón tamén para o propio Enxeñeiro de Calidade de Datos, que mellorará así os seus horizontes técnicos e habilidades de codificación.
Como funciona nun proxecto real
Unha boa ilustración dos últimos parágrafos sobre a "cadea de datos", ETL e comprobacións ubicuas é o seguinte proceso dun dos proxectos reais:
Aquí, varios datos (por suposto, elaborados por nós) entran no "funil" de entrada do noso sistema: válido, non válido, mixto, etc., despois fíltranse e acaban nun almacenamento intermedio, despois volven sufrir unha serie de transformacións. e colócanse no almacenamento final, desde o que, á súa vez, realizaranse análises, construción de data marts e busca de coñecementos comerciais. Neste sistema, sen comprobar funcionalmente o funcionamento dos procesos ETL, centrámonos na calidade dos datos antes e despois das transformacións, así como na saída á análise.
Para resumir o anterior, independentemente dos lugares onde traballei, en todos os lugares onde estiven involucrado en proxectos de datos que compartían as seguintes características:
- Só a través da automatización pode probar algúns casos e lograr un ciclo de lanzamento aceptable para a empresa.
- Un probador deste proxecto é un dos membros máis respectados do equipo, xa que aporta grandes beneficios a cada un dos participantes (aceleración das probas, bos datos do Data Scientist, identificación de defectos nas primeiras fases).
- Non importa se traballas no teu propio hardware ou nas nubes: todos os recursos abstrúense nun clúster como Hortonworks, Cloudera, Mesos, Kubernetes, etc.
- Os proxectos están construídos nun enfoque de microservizos, predomina a computación distribuída e paralela.
Gustaríame sinalar que ao facer probas no campo da calidade dos datos, un especialista en probas cambia o seu foco profesional ao código do produto e ás ferramentas empregadas.
Características distintivas das probas de calidade de datos
Ademais, por min mesmo, identifiquei as seguintes características distintivas das probas en proxectos (sistemas) Data (Big Data) (sistemas) e outras áreas (reservarei inmediatamente que son MOI xeneralizadas e exclusivamente subxectivas):
Ligazóns útiles
- Teoría: .
- EPAM
- Materiais recomendados para un enxeñeiro de calidade de datos principiante:
- Curso gratuíto de Stepik: .
- Curso sobre LinkedIn Learning: .
- Artigos:
- ;
- ;
- ;
- Vídeo:
- ;
- ;
Conclusión
Calidade dos datos é unha dirección prometedora moi nova, formar parte da que significa formar parte dunha startup. Unha vez en Data Quality, estarás inmerso nunha gran cantidade de tecnoloxías modernas e demandadas, pero o máis importante, abriranse enormes oportunidades para xerar e implementar as túas ideas. Poderás utilizar o enfoque de mellora continua non só no proxecto, senón tamén por ti mesmo, desenvolvendo continuamente como especialista.
Fonte: www.habr.com