Por Romeo Kienzler
Publicado em 5 de dezembro de 2018
Agradecimento: Obrigado a Kevin Turner por revisar este documento várias vezes e por suas valiosas contribuições.
Cientistas de dados tendem a usar abordagens ad hoc. Vemos muitos hackeamentos criativos de scripts em diferentes linguagens de programação e em diversas estruturas de machine learning distribuídas em todos os cantos, tanto em servidores quanto em máquinas de clientes. Não estou reclamando da maneira como tais profissionais trabalham. Eu mesmo me encontrei em tais modos extremamente criativos muitas vezes enquanto realizava algo significativo.
Ter total liberdade de escolha com linguagens de programação, ferramentas e estruturas melhora o pensamento criativo e a evolução. Entretanto, no final do dia, os cientistas de dados devem moldar totalmente seus ativos antes da entrega, porque pode haver muitas armadilhas se não o fizerem. Eu descrevo essas armadilhas abaixo.
Cegueira tecnológica
Para um cientista de dados, é senso comum que, do ponto de vista funcional, a tecnologia de fato não importa muito porque os modelos e algoritmos utilizados são definidos matematicamente. Tendo isso em vista, a única fonte da verdade é a definição matemática do algoritmo. Para requisitos não funcionais, essa visão não se sustenta. Por exemplo, a disponibilidade e o custo de especialistas para uma determinada linguagem de programação e tecnologia variam muito. Quando se trata de manutenção, a tecnologia escolhida possui um grande impacto no sucesso de um projeto.
Os cientistas de dados tendem a utilizar linguagens de programação e estruturas nas quais são mais qualificados. Isso começa com tecnologias de código aberto, como R e R-Studio, com seu universo incontrolável de pacotes e bibliotecas e sua sintaxe deselegante e difícil de manter. O runner-up é o Python, com sua sintaxe bem estruturada e bem organizada e estruturas Pandas e Scikit-Learn associadas. Do outro lado do espectro de ferramentas estão as de código aberto "low-code/no-code" completamente visuais, como Node-RED, KNIME, RapidMiner e Weka, e ofertas comerciais, como o SPSS Modeler.
"A tecnologia que eu conheço melhor" é adequada para uma prova de conceito (PoC), um hackathon (evento que reúne programadores e outros profissionais da área de desenvolvimento de softwares) ou um projeto de estilo start-up. No entanto, quando se trata da escala de projetos para indústrias e empresas, algumas orientações arquitetônicas sobre o uso da tecnologia devem estar disponíveis, independentemente de como ela possa se manifestar.
Falta de reprodutibilidade e reutilização
Dada a declaração do problema anterior, pode ser evidente para você que o crescimento descontrolado de ativos de ciência de dados em um ambiente corporativo não pode ser completamente tolerado. Em grandes empresas, muitos cancelamentos podem ocorrer com projetos e recursos humanos, como o caso de consultores externos com habilidades específicas sendo contratados por um curto período e vinculados a um determinado projeto. Normalmente, se alguém sai do projeto, seu conhecimento também desaparece. Portanto, é essencial que os ativos da ciência de dados não sejam apenas coleções de scripts que são implementados em diferentes linguagens de programação em diversos locais e ambientes. Devido à natureza não colaborativa sob a qual muitos ativos da ciência de dados são desenvolvidos, segue-se que a reutilização desses ativos é frequentemente limitada. Documentação ad hoc, código de baixa qualidade, tecnologias complexas e mistas e uma ampla falta de conhecimento são os principais fatores para esse problema. Depois que esses obstáculos são resolvidos, os ativos se tornam reutilizáveis e aumentam drasticamente em valor. Por exemplo, se não coordenado, cada cientista de dados pode recriar o ETL (Extract – Transform – Load, ou Extrair – Transformar – Carregar, em português), a avaliação de qualidade de dados e o pipeline de engenharia de recursos para a mesma fonte de dados, o que pode levar à sobrecarga significativa e à baixa qualidade.
Falta de colaboração
Cientistas de dados são grandes pensadores. O bom senso diz a eles que os cérebros não crescem. Portanto, tendem a trabalhar sozinhos em seu próprio ritmo, à sua maneira. Se estiverem travados, sites como o "stackexchange.com" podem se tornar seus melhores recursos para a obtenção de ajuda. Talvez seja ignorância ou apenas uma falta de colegas igualmente qualificados, mas os melhores cientistas técnicos de dados muitas vezes não se destacam em colaboração. Para quem está de fora, pode parecer que estão seguindo a mentalidade "Après moi, le deluge" (Depois de mim, o dilúvio); os ativos que são criados não são compartilhados e organizados de maneira reutilizável. A documentação deficiente, caso exista, e os componentes dispersos tornam difícil reconstituir e replicar o trabalho anterior. Com isso, um repositório de ativos comum e diretrizes mínimas para a documentação adequada são essenciais.
Decisões arquitetônicas abaixo do ideal
Cientistas de dados costumam ser "hackers" com habilidades em álgebra linear e um certo conhecimento de negócios. Eles geralmente não são engenheiros ou arquitetos de software treinados. Conforme declarado antes, tendem a usar a linguagem de programação e estruturas nas quais são mais qualificados e progridem rapidamente para uma solução sem necessariamente terem requisitos não funcionais (NFRs), como escalabilidade, manutenção e disponibilidade de recursos humanos em mente. Portanto, enfatizo a necessidade de que uma função de arquiteto de soluções ou cientista de dados líder seja atribuída a todos os principais projetos de ciência de dados para garantir que os NFRs sejam devidamente tratados. Apoiar tal função com uma arquitetura predefinida e uma estrutura de processo é muito útil. Porém, primeiramente, vamos ver como uma arquitetura corporativa tradicional se encaixa em projetos de ciência de dados.
O quanto de arquitetura e de processo é bom para um projeto de ciência de dados
Antes de respondermos esta pergunta, vamos começar com uma breve revisão da arquitetura corporativa tradicional e, em seguida, avaliar como uma metodologia de arquitetura e um modelo de processo se encaixam.
Hierarquia da arquitetura (de cima para baixo: corporativa, de soluções, de aplicações e de dados). Fonte: IBM Corporation
No topo da pirâmide está o arquiteto corporativo. O arquiteto corporativo define padrões e diretrizes que são válidos em toda a empresa. Alguns exemplos incluem:
O uso de software de código aberto só é permitido se houver licenças permissivas;
As chamadas REST sempre precisam utilizar HTTPS;
O uso de bancos de dados NoSQL requer aprovação especial do conselho de arquitetura corporativa.
O arquiteto de soluções trabalha dentro da estrutura que o arquiteto corporativo define. Esta função determina quais são os componentes tecnológicos que se encaixam no projeto ou caso de uso. Alguns exemplos são:
Os dados históricos devem ser armazenados em um sistema de gerenciamento de banco de dados relacional Db2 (RDBMS);
Para uma estrutura de alto rendimento em tempo real, o Apache Spark Streaming de dados deve ser utilizado;
Para o processamento de stream de vídeo em tempo real de baixa latência, o IBM Steams deve ser utilizado.
O arquiteto de aplicações, então, define a aplicação dentro da estrutura da arquitetura da solução. Exemplos disso incluem:
A UI é implementada utilizando o padrão Model-View-Controller (MVC);
Para entidades-padrão, um mapeamento objeto relacional é utilizado;
Para consultas complexas, instruções SQL preparadas são utilizadas.
Finalmente, o arquiteto de dados define os componentes relacionados aos dados, como:
Durante o ETL, os dados devem ser desnormalizados em um modelo estrela;
Durante o ETL, todos os campos categóricos e ordinais devem ser indexados.
Então, onde o todo-poderoso e criativo caubói que é o cientista de dados se encaixa aqui? Primeiro, tentamos determinar quais funções definidas acima um cientista de dados pode assumir parcialmente ou com quais funções ele pode interagir.
Vejamos os papéis novamente, de cima para baixo. Para ilustrar, vamos utilizar uma metáfora do design urbano. Um arquiteto corporativo é aquele que projeta uma cidade inteira. É aquele que define os sistemas de esgoto e as estradas, por exemplo. Um arquiteto de soluções seria aquele que projeta casas individuais, enquanto um arquiteto de aplicações projeta a cozinha e um arquiteto de dados supervisiona a instalação elétrica e o sistema de abastecimento de água.
Finalmente, o cientista de dados é responsável por criar a cozinha mais avançada de todos os tempos! Ele não quer apenas uma cozinha pronta para uso. Ele pega componentes individuais prontos, mas também cria peças originais quando necessário, interagindo, principalmente, com o arquiteto de aplicações. Se a cozinha possuir requisitos especiais, o arquiteto de dados pode ser necessário para fornecer a infraestrutura. Mantendo essa metáfora em mente, como seria a cozinha se tivesse sido criada apenas pelo cientista de dados? Seria uma cozinha funcional com muitos recursos, mas provavelmente carecendo de alguma usabilidade. Por exemplo, para ligar o forno, você precisa fazer login no Raspberry Pi e executar um script de shell. Como as peças foram compradas de diferentes fornecedores, incluindo algumas ferragens feitas sob medida, o design da cozinha pode ser feio. Finalmente, haveria muitas funcionalidades, mas algumas delas não seriam necessárias e a maior parte não estaria documentada.
Voltando à TI, este exemplo ilustra a resposta à pergunta original. Onde nosso caubói cientista de dados todo poderoso e criativo se encaixa aqui?
Ele raramente interagiria com o arquiteto corporativo. Ambos se relacionariam com o arquiteto de soluções, mas trabalhariam em estreita colaboração com o arquiteto de aplicações e o arquiteto de dados. Eles não precisariam assumir suas funções, mas deveriam ser capazes de se colocar no lugar deles e de entenderem seus pensamentos. Como a ciência de dados é um campo emergente e inovador, o cientista de dados deve dialogar diretamente com os arquitetos (o que não é o caso de um desenvolvedor de aplicações ou administrador de banco de dados) a fim de transformar e influenciar a arquitetura corporativa.
Vou concluir com um exemplo para ilustrar o que quero dizer com isso. Considere as diretrizes arquitetônicas em que um servidor R-Studio é a plataforma de ciência de dados padrão na empresa e em que todos os projetos de ciência de dados devem utilizar R. Este software foi aprovado pelo arquiteto corporativo, e o portal de autoatendimento R-Studio Server local foi projetado pelo arquiteto de soluções. O cientista de dados encontra um snippet de código Keras em Python utilizando o back-end TensorFlow, que leva o desempenho do modelo para a Lua. Este código é aberto e mantido por um dos cérebros mais inteligentes em inteligência artificial. O cientista de dados só precisa de uma hora para conectar este snippet ao pipeline de processamento de dados em execução em seu notebook (sim, tais profissionais prototipam em seus notebooks porque realmente não gostam da instalação do R-Studio Server fornecida a eles). Então, o que você acha que deveria acontecer aqui?
Nos velhos tempos dos arquitetos todo-poderosos em uma empresa, o cientista de dados seria forçado a portar o código para R (utilizando uma estrutura de machine learning menos sofisticada). Entretanto, aqui está o potencial. Se o cientista de dados quiser utilizar esse trecho de código, ele deve ser capaz de fazer isso. Porém, se isso for feito sem orientação alguma, acabaremos no Velho Oeste da ciência de dados.
Portanto, vamos olhar para os modelos de processo existentes e arquiteturas de referência para ver se e como podemos mesclar o campo tradicional da arquitetura com o campo emergente da ciência de dados.
Uma visão geral dos modelos de processos existentes para ciência de dados
CRISP-DM
CRISP-DM, que significa Processo Padrão Inter-Indústrias para Mineração de Dados (Cross-industry Standard Process for Data Mining, em inglês), é o modelo de processo de padrão aberto mais utilizado – se um modelo de processo for utilizado, é claro. O CRISP-DM define um conjunto de fases que constituem um projeto de ciência de dados. Mais importante ainda, as transições entre essas fases são bidirecionais e todo o processo é iterativo. Isso significa que, depois de atingir o estágio final, você apenas inicia todo o processo novamente e refina o seu trabalho. A figura a seguir ilustra esse processo.
Na minha opinião, esse modelo de processo já é um bom começo. Entretanto, por ser apenas um modelo de processo, ele presume que as decisões arquitetônicas sobre a tecnologia usada e os NFAs já foram abordadas. Isso torna o CRISP-DM um modelo muito bom em ambientes tecnologicamente estabelecidos, como no armazenamento de dados corporativos tradicionais ou em projetos de inteligência de negócios.
Em um campo em rápida evolução como a ciência de dados, ele não é flexível o suficiente.
ASUM-DM
Devido a deficiências no CRISP-DM, a IBM lançou em 2015 o Método Unificado de Soluções Analíticas para Mineração de Dados/Análise Preditiva (ASUM-DM – Analytics Solutions Unified Method for Data Mining/Predictive Analytics, em inglês). Ele é baseado no CRISP-DM, mas o estende para tarefas e atividades em infraestrutura, operações, projeto e implantação, além de adicionar modelos e diretrizes a todas as tarefas.
O ASUM-DM é parte de uma estrutura mais genérica chamada Analytics Solutions Unified Method (ASUM), que fornece roteiros de implementação específicos de produto e solução que abrangem todos os produtos IBM Analytics.
O ASUM-DM pega emprestado o modelo de processo da ASUM, que é ilustrado abaixo.
Modelo de processo Analytics Solutions Unified Method (ASUM). Fonte: IBM Corporation
Detalhe do processo Analytics Solutions Unified Method (ASUM) . Fonte: IBM Corporation
Método IBM Cloud Garage
Quando o Manifesto para Desenvolvimento Ágil de Software foi publicado em 2001, processos pesados como o Waterfall ou o V-Model saíram de moda. A principal razão para essa mudança de paradigma foi a crise de desenvolvimento de software na década de 1990, durante a qual a ação simplesmente não conseguiu acompanhar as expectativas crescentes das partes interessadas de negócios em relação ao tempo de colocação no mercado e flexibilidade.
Como clientes corporativos muitas vezes possuem dificuldade em fazer a transição para processos ágeis, a IBM criou o IBM Cloud Garage Method, um método de arquitetura de software ágil que é feito sob medida para a transformação corporativa. Novamente, este método é organizado em diferentes etapas, conforme mostrado na imagem a seguir.
Método IBM Cloud Garage. Fonte: IBM Corporation
Uma coisa importante a se notar é que a mudança cultural está no centro desse hexágono. Isso significa que, sem mudança cultural, o método está condenado ao fracasso. É importante ter isso em mente. No contexto da ciência de dados, temos uma vantagem inicial porque os cientistas de dados tendem a favorecer modelos de processos leves, no caso de serem usados.
Aqui está um resumo de todas as seis fases em torno da mudança cultural.
Pense
O design thinking é a nova engenharia de requisitos. Teve suas raízes na década de 1960, mas a IBM foi um dos principais contribuintes na aplicação desse método ao setor de TI. Embora geralmente expresso em termos mais complexos, o design thinking, na minha opinião, tem apenas um propósito: colocar seu cérebro no modo criativo. Com isso, escrever e desenhar são ações aplicadas em vez de falar e digitar. Ao dar um passo para trás, você será capaz de ver, entender e criar uma imagem maior.
O design thinking tem em mente a experiência do usuário e uma ênfase clara no negócio por trás da oferta. Portanto, essas perguntas-chave são respondidas:
Quem: para quem desenvolvemos a oferta?
Qual problema estamos tentando resolver?
Como vamos resolver o problema?
O resultado de cada fase de pensamento é a definição de um produto mínimo viável (MVP).
Codifique
A revolução da cloud de plataforma é o principal habilitador da prototipagem rápida. Você pode fazer seu protótipo funcionar em horas, em vez de dias ou semanas. Isso permite reduzir o ciclo de iteração em uma ordem de magnitude. Dessa forma, o feedback do usuário pode ser coletado diariamente. Algumas práticas recomendadas para esta fase incluem:
Reuniões diárias em pé;
Programação em pares e desenvolvimento orientado a testes;
Integração contínua;
Teste automatizado;
Refatoração para microsserviços.
Entregue
Os pré-requisitos para entrega diária são duas coisas. Primeiro, a construção e a implantação devem ser totalmente automatizadas por meio de uma cadeia de ferramentas. Em segundo lugar, cada confirmação para o repositório de código-fonte deve resultar em um produto totalmente pronto para produção que pode ser testado pelos usuários a qualquer momento. As soluções baseadas em cloud estão lidando com esse requisito e permitem que os desenvolvedores se concentrem na codificação.
Integração contínua e entrega contínua. Fonte: IBM Corporation
Execute
Ao utilizar um sistema de tempo de execução em cloud, os aspectos operacionais de um projeto são tratados por serviços em cloud. Dependendo dos requisitos, isso pode acontecer em clouds públicas, privadas ou híbridas e em uma infraestrutura, plataforma ou nível de serviço. Dessa forma, muitas vezes a equipe de operações pode se tornar obsoleta e os desenvolvedores podem se concentrar em agregar valor ao projeto. Algumas práticas recomendadas para esta fase incluem:
Prontidão para alta disponibilidade;
Dark launches e feature toggles;
Escalonamento automático.
Alta disponibilidade, escalonamento automático e tolerância a falhas em uma implantação de cloud intercontinental. Fonte: IBM Corporation
Administre
Havendo como premissa sistemas de tempo de execução em cloud totalmente gerenciados, adicionar alta disponibilidade/failover intercontinentais, monitoramento contínuo e escalonamento dinâmico não é mais um desafio e pode ser simplesmente ativado. Algumas práticas recomendadas para esta fase incluem:
Monitoramento automatizado;
Recuperação rápida e automatizada;
Resiliência.
Aprenda
Devido a ciclos de iteração muito curtos e feedback contínuo do usuário, as hipóteses podem ser testadas imediatamente para gerar decisões informadas e conduzir descobertas que podem ser adicionadas ao backlog para pivotagem posterior. Algumas práticas recomendadas para esta fase incluem:
Testes A/B;
Desenvolvimento baseado em hipóteses;
Análise do comportamento do usuário em tempo real.
Exemplo de teste de hipótese baseada em evidências. Fonte: IBM Corporation
Método IBM DataFirst
Embora geralmente vinculado a um cliente IBM, o compromisso incluído nas Ofertas de Engajamento de Design do Método DataFirst (o Método IBM DataFirst é uma instância do Método IBM Cloud Garage) visa especificamente a transformação de TI a fim de preparar a infraestrutura, os processos e os funcionários para a IA.
Modelo de processo Método IBM DataFirst. Fonte: IBM Corporation
A Arquitetura de Referência de Dados e IBM Data
Cada projeto é diferente e cada caso de uso precisa de componentes técnicos diferentes. Entretanto, todos eles podem ser descritos em termos abstratos. A lista a seguir enumera e explica isso.
Fonte de dados: uma fonte de dados interna ou externa que inclui bancos de dados relacionais, páginas da web, arquivos CSV, arquivos JSON, arquivos de texto, vídeo e dados de áudio.
Dados corporativos: soluções baseadas em cloud que tendem a estender o modelo de dados corporativos. Portanto, pode ser necessário transferir continuamente subconjuntos de dados corporativos para a cloud
Análise de streaming: o estado da arte atual é o processamento em lote. Porém, às vezes, o valor de um produto de dados pode ser aumentado com a adição de recursos de análise em tempo real, porque a maioria dos dados do mundo perde valor em segundos. Pense nos dados do mercado de ações ou no fato de que a câmera de um veículo captura um pedestre atravessando uma rua.
Integração de dados: os dados são limpos, transformados e, se possível, são adicionados recursos downstream.
Repositório de dados: o armazenamento persistente de seus dados.
Descoberta e exploração: uma ideia de quais dados você possui e como eles se parecem.
Insights acionáveis: onde a maior parte do seu trabalho se encaixa. Aqui, você cria e avalia seus modelos de machine learning e deep learning.
Aplicações/produtos de dados: os modelos são bons, mas seu valor aumenta quando podem ser consumidos pelo usuário de negócios comum. Portanto, você deve criar um produto de dados. Os produtos de dados não precisam necessariamente permanecer na cloud. Eles podem ser enviados para aplicações móveis ou corporativas.
Segurança, governança de informações e gerenciamento de sistemas: uma etapa importante que é facilmente esquecida. É importante controlar quem tem acesso a quais informações para muitos regulamentos de conformidade. Um usuário corporativo faz parte da arquitetura porque seus requisitos podem ser diferentes de um usuário público. Os requisitos de um usuário da cloud podem ser diferentes daqueles dos usuários corporativos
Conclusão
Como agora você tem uma visão geral dos atuais métodos e modelos de processo de última geração para ciência de dados na cloud, é hora de se concentrar em um método que seja útil para cientistas de dados individuais que almejam melhorar suas metodologias e desejam minimizar a sobrecarga arquitetônica e influenciar positivamente a arquitetura corporativa de baixo para cima. Eu chamo isso de Lightweight IBM Cloud Garage Method of DataScience (Método IBM Cloud Garage leve de DataScience). Explicarei melhor método em meu próximo artigo. Então, fique ligado!
...
Quer ler mais conteúdo especializado de programação? Conheça o IBM Blue Profile e tenha acesso a matérias exclusivas, novas jornadas de conhecimento e testes personalizados. Confira agora mesmo, consiga as badges e dê um upgrade na sua carreira!
…..
Quer dar o próximo grande passo na sua jornada profissional? Participe do Cloud Training, um curso online e gratuito que vai te preparar para o exame da certificação IBM Cloud Foundations. Inscreva-se já!
Categorias
