Sobre BI, Ciência e Engenharia de Dados: Um olhar de perto, um olhar de longe
De tudo o que se disser, inda não se sabe bem, antes que se possa ver bem mais de perto. De tudo o que se disser, inda não se sabe bem, antes que se possa ver, olhar de longe. Paulo Nazareth e Marcos Almeida.
Alguns dizem que para conhecer algo, é preciso olhar de perto, conhecer as minúcias dos mínimos detalhes. Há algum tempo percebi a importância do olhar de longe na construção do saber. Como o ajuste de foco para enquadrar a cena completa, é na junção desses olhares de perto e de longe que está o conhecimento pleno. Em outras palavras, conhecer profundamente de perto um sistema, processo ou função não basta, é preciso conhecer as interfaces e relações desse com o “mundo externo”, olhar de longe a figura completa. Se você domina algo, precisa saber como esse “algo” colabora com o resto do “mundo” para gerar valor.
O primeiro, segundo e terceiro olhar
Considero que minha historia no mundo dos dados pode ser dividida em três olhares, diferentes e complementares.
O primeiro não mirou a Engenharia de Dados, nem o segundo. Apesar de ter tido bastante contato com SQL quando era “webdev juninho”, tudo começou de verdade na área de Business Intelligence (BI), entre ETLs e data marts, reports e dashboards, entregando produtos aos analistas do negócio. Durante bons anos, quase tudo correu em paz na bolha BI em que eu vivia, até que tive contato com os primeiros artigos sobre Ciência de Dados, o meu segundo olhar estourou a bolha da ilusão, espalhando disciplinas pelo espaço.
Me assustei à primeira vista. Como poderia haver tanto assunto e conhecimento relacionado à análise e estudo dos dados, aqui do lado de “casa”, sem que eu soubesse. Eu não sabia nada. Senti talvez o que fossem os primeiros sintomas da síndrome do impostor. Como poderia não ter domínio sobre esse conteúdo e continuar trabalhando em uma área cuja matéria prima é o dado? Comecei a procurar por cursos, inferi que alguém haveria de ter criado uma graduação para isso, afinal era muito assunto.
Não achei a graduação, mas acabei tendo a sorte de topar com esse texto da Caitlin Hudon: Imposter Syndrome in Data Science. Recomendo para aliviar a pressão de qualquer um que esteja iniciando na Ciência de Dados.
Continuei minha busca, agora sem a culpa de não saber. Entre cursos on-line, bootcamps, MOOC e outros bichos disponíveis, acabei matriculado em uma pós de Ciência de Dados e Big Data. Após algumas aulas já não enxergava a Ciência de Dados como um unicórnio a ser domado, ela acontece na comunicação e colaboração entre as várias disciplinas, entre papéis e pessoas, falo disso mais adiante. Ali também veio o terceiro olhar, Engenharia de Dados sua linda! Foi a primeira vez que vi um diagrama que relacionasse Engenharia e Ciência de Dados. A identificação foi rápida e óbvia. Dentre todas as interações e interseções de disciplinas, essa era a evolução natural do que eu fazia, tinha achado minha turma. Digo que entre Ciência de Dados e Big Data, o “e” é de Engenharia.
Olhar de perto
Contei essa história, a minha história, para mostrar como conheci o BI, a Ciência e a Engenharia de Dados. Meu objetivo agora é olhar mais de perto, ilustrando o que são cada um desses caras:
Business Inteligence, ou BI, ou Inteligência de Negócio: Processo de coleta, modelagem, análise, compartilhamento e monitoramento de informações para suportar a gestão de negócios. Você vai ver ele nas empresas na forma de data warehouses, data marts, reports, dashboards, indicadores, KPIs, metas.
Responde o que (what) aconteceu, podendo também ajudar a responder o porquê (why) aconteceu.
— Qual o total de vendas do mês?
— Qual o lucro do trimestre?
Data Science, Ciência de Dados: Um guarda-chuva de disciplinas que colaboram entre si para estudo e análise dos dados, identificando padrões, gerando predições, recomendações, insights (buzzword detected). Envolve matemática, estatística, análise de dados avançada, programação, inteligência artificial, machine learning, conhecimento do negócio, domínio do problema, entre outros. Ela pode estar em um storytelling, na análise descritiva dos dados, no sistema de recomendação, em uma API, no reconhecimento de voz ou corretor ortográfico do seu celular. O céu é o limite.
Busca dizer o que está por vir (what’s next), e ajuda a responder o que deve ser feito (what to do) a partir dos dados, padrões históricos.
— Qual será o lucro do próximo trimestre?
— Qual o preço de venda ideal para aumentar meu lucro no próximo trimestre?
Segundo Jesse Anderson, o cientista de dados é alguém que potencializou seu background em matemática e estatística, usando programação para analisar dados e criar modelos matemáticos aplicados.
Vai mais além. Conforme ouvi recentemente em uma palestra do professor Nívio Ziviane, os avanços no campo da ciência de dados e inteligência artificial tem forte impacto na forma como desenvolvemos software, de um paradigma imperativo, onde ordenamos o que a maquina deve fazer, para paradigmas apoiados em padrões e probabilidades, onde a maquina aprende, sugere e até decide o que deve ser feito. Estamos falando de softwares mais adaptáveis, com menos código. Ao desenvolver um software de forma imperativa, você precisa mapear todas as condições possíveis e definir o que deve ser feito em cada uma (if — then). Já em um modelo que usa aprendizado de maquina por exemplo, podem surgir condições e ações que um programador humano nunca seria capaz de prever. O paradigma imperativo carrega a herança das nossas limitações. Não conseguimos, por exemplo, analisar e correlacionar muitas variáveis simultaneamente, talvez 4 ou 5. Não conseguimos traduzir e transmitir tudo que sabemos, explique para alguém como se faz para andar de bicicleta, mantendo o equilíbrio. O aprendizado de maquina pode nos ajudar nessas questões.
Data Engineering ou Engenharia de Dados: Outro guarda-chuva de disciplinas que colaboram para a ingestão, armazenamento e processamento de dados, estruturados ou não. Tem suas raízes na programação, engenharia de software, bancos de dados, sistemas distribuídos, computação em larga escala. Projeta, implementa e mantém datalakes, data warehouses e outros data repositories. Define a arquitetura de todo um ambiente de dados, composto por integrações, fluxos, repositórios e ferramentas, muitas ferramentas. Falando em ferramentas, busca saber o que existe disponível, qual tecnologia utilizar para cada caso de uso, afinal não existe bala de prata, nem tudo é NoSQL, bancos relacionais resolvem e ainda vão resolver muitos problemas. Se preocupa com os aspectos de confiabilidade, escalabilidade, e manutenibilidade desse ambiente, de ponta à ponta. Ah, não pode se esquecer da parte de governança de dados, qualidade, linhagem, acessos, autorizações, metadados, dicionário de dados técnicos, de negócio, e por aí vai.
Uma definição no estilo Marvin, do Guia do Mochileiro das Galáxias, seria: o primo pobre da Ciência de Dados, discreto, nada sexy. Por vezes na sombra dos bastidores, lembrado quando a comida demora a chegar na mesa, o típico garçom. Vive para dar a assistência aos que vão fazer o gol e gerar o resultado final. Dificilmente vai pedir música no fantástico.
À parte o exagero, quase um Batman, me identifico.
Misturando os três: Definições ou descrições nos ajudam a entender, porém a vida real não é divida em caixinhas, existem sobreposições na execução desses papéis, cientistas de dados que constroem pipelines, engenheiros de dados que desenvolvem e automatizam processos de machine learning. Da junção desses papéis podem surgir novos, como o Engenheiro de Machine Learning. Em grandes empresas, ou para grandes desafios, creio ser melhor contar com a colaboração de funções especializadas.
Uma outra visão que compartilho é de que a Engenharia e a Ciência de Dados especializaram e estenderam de ponta a ponta as capacidades do BI tradicional. Onde o BI por exemplo tratava dados estruturados em processos batch, a Engenharia de Dados trouxe a opção dos dados não estruturados e processos de streaming. Onde o BI permitia a análise do histórico, a Ciência de Dados trouxe a descoberta de padrões para predição, prescrição.
Se o BI acelerou negócios, a ED e a CD estão fazendo com que eles decolem.
Olhar de longe
Quero encerrar esse post falando sobre o olhar de longe. A figura abaixo é apenas para ilustrar, peguei emprestada desse artigo bem bacana do Andre Casimiro.
Com essa visão panorâmica quero destacar que o cara que está no centro não é necessariamente uma pessoa, muito menos vai dominar cada disciplina ou função desse diagrama. Aliás, se fosse uma pessoa, seria com certeza a mais dependente de colaboração. O centro desse diagrama nos diz que Ciência de Dados é uma função fundamentalmente multidisciplinar, nasceu da colaboração e dependerá sempre de colaboração. Só se realiza bem BI, Engenharia ou Ciência de Dados com colaboração. Para exemplificar, na mesma palestra do professor Nívio que citei anteriormente, pude ver a plateia deslumbrada com várias aplicações, cases e resultados de IA. Poucos perceberam, pelo que pude notar, uma frase que o professor falava ao apresentar cada case:
— É possível, tendo dados em quantidade e qualidade suficiente.
Pense em uma empresa, por onde os dados trafegam, desde os sistemas fontes. Pense nos profissionais que inputam dados, outros que coletam, limpam, transformam, relacionam, armazenam, disponibilizam, analisam. Pense na colaboração necessária para que um Cientista de Dados desenvolva um modelo que faça uma predição útil, que gere valor para o negócio. Aqui vale a máxima, garbage in, garbage out.
Quando falei do olhar de perto, falei dos papéis em particular, falei um pouco de tecnologia. Quando falo do olhar de longe, falo do “todo” em colaboração, falo de cultura. Esse ciclo virtuoso, cultura influenciando na tecnologia que influencia na cultura. Você está começando errado se vive a cultura do herói. A sua empresa não vai muito longe em Ciência de Dados com a cultura do herói. É contra a natureza do que é a área de dados hoje, ela emergiu da colaboração, do open, do paradigma de escala horizontal. Como Daniel Kimble escreve no artigo Six Ways Your Company’s Hero Culture Is Killing Productivity, Heróis não escalam. Na minha opinião, pode até ser que escale, mas é verticalmente, acaba em burnout. Precisamos escalar horizontalmente.
Por hora é só. Até a próxima.
Bônus
A metáfora do olhar de perto e longe vem de um poema musicado, obra dos compositores Paulo Nazareth e Marcos Almeida. Arte faz bem, é cultura, é tecnologia. Para quem quiser ouvir:
https://open.spotify.com/track/23OY7IIl6bLZy7xkfuFNWk
Referências
