O termo DataOps surgiu pela primeira vez em junho de 2014, em um post do blog IBM Big Data & Analytics Hub com o título “3 reasons why DataOps is essential for big data success” (3 razões pelas quais DataOps é essencial para o sucesso de big data, na tradução literal), de Lenny Liebmann. Lenny definiu, então, DataOps como sendo o conjunto de melhores práticas para facilitar a coordenação de Ciência de Dados e Operações.
Talvez a melhor forma de entender o que é DataOps seja pelo seu objetivo, que é o de acelerar a entrega de dados, garantindo a qualidade e a acuracidade das informações. Uma organização data-driven, que toma decisões baseadas em dados, precisa de respostas rápidas e precisas para atender ao timing do negócio.
Nos últimos anos, vimos o surgimento do conceito de Data Lake, muito em consequência da redução de custos e preço de hardware para armazenamento dos dados e ao armazenamento em nuvem. Em razão disso, mudou-se todo um paradigma de armazenar somente o necessário para armazenar tudo o que é possível. Isso fez com que a demanda por habilidades e ferramentas relacionadas a administração e mineração de dados aumentasse significativamente.
Para facilitar a explicação, ilustro com um exemplo: imagine que em sua organização exista uma equipe de cientistas de dados e esses profissionais tenham a função de extrair as informações e insights que suportem tomadas de decisão dentro da empresa a partir dos dados. Eles, muitas vezes, possuem conhecimento do negócio, os chamados domain skills, mas não necessariamente sabem o lado técnico de como os dados serão integrados a partir de um ambiente transacional, que tecnologias serão utilizadas e/ou como tudo isso será automatizado. Esse é o papel de um engenheiro de Dados.
É fundamental que, não somente as duas equipes do exemplo acima, e sim todas as envolvidas no processo estejam trabalhando em conjunto e tendo o mesmo alvo para obter sucesso na implantação de Big Data. Pegando emprestado do DevOps a adoção de ferramentas colaborativas e a prática ágil, é possível colocar todos os envolvidos na mesma página e direcioná-los em busca do mesmo objetivo, diminuindo o tempo de entrega em produção.
Como, então, distinguir DevOps de DataOps? A começar pelo escopo, o DevOps busca acelerar a integração e entrega contínua de software, enquanto DataOps foca em acelerar a entrega e a análise de dados. Além disso, os pipelines, por onde os dados entram brutos e são refinados a cada fase, precisam ser gerenciados e monitorados afim de garantir a disponibilidade e qualidade ao final do processo.
Outro aspecto importante de DataOps é a utilização de orquestradores e pipelines que permitem o desacoplamento entre os componentes (jobs, bases de dados, storage, etc). Essa capacidade, hoje em dia, que é fundamental para qualquer sistema em processo de melhoria contínua, torna possível a substituição de cada componente de forma rápida para ser inovadora e disruptiva, e transparente para não causar indisponibilidade dos dados para o negócio.
Isso permite, inclusive, que a organização seja independente de tecnologias específicas, não importando mais se os dados estão em um Data Lake ou em um Data Warehouse. Com um processo maduro de gerenciamento desses pipelines, os dados podem estar em qualquer um dos dois (ou até mesmo em ambos), tendo o mínimo de alterações no pipeline ao invés de refatorar todo um processo.
Além disso, a qualidade dos dados entregues ao final de cada pipeline torna-se crítica. Perguntas como “os dados chegaram?”, “os dados estão corretos?” são fundamentais para garantir a qualidade ao final do pipeline.
Aqui vai mais um exemplo: suponha um processo ETL dentro de um pipeline que ao final de todos os dias faça a leitura de uma tabela de um banco de dados transacional e uma cópia para um Data Warehouse. No caso de algum acidente que limpe a tabela na origem, as análises e relatórios que dependam dos dados copiados pelo pipeline serão diretamente afetados.
Apenas monitorar se o pipeline foi executado com sucesso não resolveria, afinal, ele foi executado com sucesso e carregou 0 linhas. Uma abordagem eficiente para resolver esse problema é a de statistical process control (SPC). Esse método se baseia na utilização de dados estatísticos para monitorar o resultado de cada pipeline. Neste cenário, seria possível comparar o número de linhas carregadas no dia anterior com uma variação estipulada de 10%, por exemplo. Caso esse número de execução corrente esteja fora dessa variação, um alarme é disparado para que a equipe verifique e atue no problema.
0 comentário