Desde a crise de software na década de 1970 (veja aqui), foram desenvolvidas  metodologias de desenvolvimento, como SCRUM e Kanban, que servem para gerenciar melhor a equipe e assim evitar atrasos, sobrecarga de função e prazos curtos.

Além dessas metodologias, surgiram também convenções nos módulos de um projeto de software. Por exemplo, as regras para a criação de tabelas de banco de dados e gerenciamento destes arquivos (como CRUD,); Formas de esquematizar as páginas de um site web ou as telas de um aplicativo (MVC); Em questão de código, há também uma vasta literatura sobre como escrevê-los de forma clara e como documentá-los  (PEP-8 para o Python, por exemplo).

Essas e outras melhorias, se implementadas, convergem para um software preparado para durar muitos anos depois de desenvolvido, pois elas previnem a perda total de um módulo simplesmente pela ausência de explicação de sua função dentro do código como um todo. Consequentemente, previnem também  uma situação muito temida por todos os integrantes do projeto: o retrabalho.

Na área de ciência de dados, esses problemas também aparecem. Um notebook escrito na plataforma Jupyter por uma equipe de ciência de dados, se mal explicado ou negligenciada a documentação do mesmo, pode levar modelos, gráficos e até mesmo um dataset inteiro a ser descartado.

Portanto, neste texto serão descritas algumas dicas simples sobre o que não deixar de colocar em um notebook para garantir sua legibilidade e aplicabilidade, que chamaremos de Notebook Limpo - derivado do conceito de Clean Code de Robert C. Martin (Tio Bob).

Criando um notebook limpo

Nomenclatura e localização do documento

Vamos primeiro descrever um cenário: recebemos uma tarefa dos nossos superiores para que encontrássemos o melhor modelo para os dados referentes ao dataset do Titanic. Sim, sabemos que você já decorou as análises deste dataset, mas que tal ver ele bem documentado?

Então vamos abrir um notebook:

jupyter notebook

Dica: procure o local certo da pasta que você vai colocar este notebook, porque se não, irá se aventurar nos diretório do seu computador toda vez que abrir este notebook, ou seja:

Agora execute este comando. Surgirá um link no terminal que dá acesso a esta pasta no navegador. Crie um notebook com um nome bem intuitivo, pois é provável que este não seja o único que você fará. Não deixe notebooks importantes nomeados como Untitled.ipynb! Nomeie-o de forma clara para que quem acessá-lo saiba o que será encontrado nele. Um bom nome seria, por exemplo: procurando_o_modelo_para_o_dataset_titanic.ipynb. Feito isso, teremos:

Contextualização

Criado nosso notebook, o próximo passo é descrever os nossos objetivos nele, ou melhor, responder perguntas importantes com base na tarefa que foi passada:

• Do que se trata o dataset que será utilizado?
• Qual é o significado de cada coluna deste dataset?
• Quais tipos de problemas que tentaremos resolver? Classificação, regressão ou  ranqueamento, etc ?
• Quais modelos vamos testar?
• Como serão testados?
• Quais métricas usaremos para escolher o melhor modelo?

Sem nenhuma exploração dos dados, já surgiram seis perguntas!  Quanto mais perguntas forem feitas, melhor será o entendimento do problema e mais preciso serão nossos insights sobre o modelo a ser criado e seus resultados. Com as perguntas organizadas, podemos respondê-las no início do notebook.

Mas como fazer isso? Notebooks são estruturados em células, podendo ser tratadas como código (seja em qualquer linguagem), texto em markdown, ou outras formas. Então, a dica ao iniciar o notebook é: comente o que será feito. No nosso exemplo, é respondendo as perguntas listadas acima:

Sendo assim,  caso haja um novo integrante na equipe, ou se esse notebook for repassado para o cliente, todo o contexto do trabalho estará explicitado logo de início.

Configuração de ambiente

Feito isso, vamos ao código. Normalmente colocam-se os principais imports de bibliotecas e configurações na primeira célula de código, logo depois da descritiva do propósito do notebook, pois fica claro como o ambiente foi configurado. Por exemplo, nesta célula podemos colocar a semente dos valores aleatórios ou também desabilitar warnings (se eles forem realmente desnecessários).

Vale ressaltar que a medida que seu notebook se estende em conteúdo, é interessante dividi-lo em seções e/ou subseções. No nosso caso, já temos duas. Podemos nomeá-las como: “0. Sobre o notebook” e “1. Configurando o ambiente”.

Configuração de ambiente

Feito isso, vamos ao código. Normalmente colocam-se os principais imports de bibliotecas e configurações na primeira célula de código, logo depois da descritiva do propósito do notebook, pois fica claro como o ambiente foi configurado. Por exemplo, nesta célula podemos colocar a semente dos valores aleatórios ou também desabilitar warnings (se eles forem realmente desnecessários).

Vale ressaltar que a medida que seu notebook se estende em conteúdo, é interessante dividi-lo em seções e/ou subseções. No nosso caso, já temos duas. Podemos nomeá-las como: “0. Sobre o notebook” e “1. Configurando o ambiente”.

Modelagem e testes

Com o contexto definido, o dataset explicado e  o ambiente configurado, agora é mão na massa! De acordo com nossos objetivos, testamos os seguintes algoritmos: Random Forest, Gaussian Naive Bayes e LDA. Visando a organização, é recomendado colocar cada um deles numa subseção dentro de  “3. Testando os modelos”, nomeadas com os respectivos algoritmos empregados.

Além disso, quando houverem procedimentos que se repetem ao longo do notebook (como a divisão do dataset entre treino e teste ou o instanciamento dos modelos e seus hiperparâmetros), podemos colocá-los em funções bem comentadas de acordo com a PEP-8, como mostrado o exemplo abaixo:

Outro ponto muito importante: durante o processo de desenvolvimento é bastante provável que surgirão insights sobre os resultados, outros modelos e métricas. Não deixe de registrar suas descobertas, anote-as no notebook! Lembre-se que os leitores  não estarão na sua mente para entender os pormenores de suas ideias ao desenvolver o documento!

Além disso, coloque todas as métricas que utilizou de forma padronizada. Assim você, sua equipe e/ou o cliente já saberá por onde começar a comparar. Por exemplo:

A padronização auxilia tanto na produção dos estudos quanto no seu entendimento. Dessa forma, todos os modelos que foram estudados possuem o mesmo formato de saída, não necessitando de uma outra tratativa de saídas para comprar os resultados mais facilmente.

Conclusões

Para finalizar a documentação, coloque uma sessão como “4. Considerações finais” ou “4. Conclusões”, trazendo os resultados finais do estudo - no nosso exemplo, qual foi o melhor modelo e o porquê dele ser o melhor. Busque a clareza e a objetividade!

Com isso, revise os seus feitos (como se estivesse finalizando uma prova ou uma redação) para não deixar nada passar. Por fim, mostre os resultados à sua equipe e seus superiores.

Conclusões sobre o que aprendemos

Vimos que documentar bem um notebook facilita a leitura do código que foi desenvolvido e as conclusões obtidas dele, tornando-o um material de referência para estudos e desenvolvimentos futuros ou um entregável de valor ao seu cliente!

Caso todo este texto não tenha lhe convencido da importância da documentação, faça um teste: pegue algum notebook que você comentou pouco ou nada e compare com outro que esteja bem escrito. Verá que o último servirá para você por muito tempo (na escala de anos!) por simplesmente descrever cada ideia e pensamento que você teve nele.

Lidar com quantidades massivas de dados é uma das tarefas mais intensas que existem na Ciência de Dados.  Tratar os dados, criar novas variáveis e filtragens são operações que quando aplicadas em um 'oceano' de informações podem custar muito tempo.

Um paralelo que podemos fazer para o processo de filtragem de dados, por exemplo, é imaginar que em uma fila existem 10 pessoas e gostaríamos de separar das demais aqueles indivíduos que têm cabelo longo, olhos castanhos e idade entre 12 e 20 anos. Então, selecionamos um recrutador para realizar essa seleção de indivíduos. Ele irá em cada uma das dez pessoas  da fila saber quais condizem com as características que serão selecionadas. Quando temos um recrutador nesse processo de avaliação, nós nomeamos a ação de seleção como ‘operação em serial’.

Quando esse processo é feito com 10 pessoas é algo simples, mas quando queremos realizar a mesma ação em 100 mil pessoas esse processo pode demorar bastante. Para trabalhar com tantas pessoas assim, a melhor forma é separar as pessoas em outras filas, para que mais recrutadores possam trabalhar ao mesmo tempo, chamamos essa estratégia de PARALELIZAR.

A ideia de PARALELISMO vem de realizar operações SIMULTANEAMENTE com o objetivo de reduzir o tempo de processamento da tarefa em questão. Neste artigo apresentamos apenas uma das forma de se organizar o fluxo de instruções no paralelismo, Single Instruction Multiple Data - SIMD, outra abordagens existem :  `Multiple Instruction Multiple Data` - MIMD, `Single Instruction Single Data` - SISD e  `Multiple Instruction Single Data` - MISD. Essa é uma taxonomia simples apresentada por Flynn no artigo para classificar o fluxo de instruções em unidades de processamento que podem trabalhar em paralelo..

Operações em `chunks`

Umas das maneiras mais intuitivas de entender o paralelismo é a partir da técnica de separação em \textit{chunks} ou pedaços. Para explicar isso vamos buscar formalizar um pouco mais esse conhecimento.

Dados que `a` é uma constante, `x` e `y` são dois vetores com `N` elementos cada, podemos realizar a operação `a*x + y` que combina multiplicação por escalar e soma. Realizar essa operação em serial é o mesmo que executar os comandos de multiplicação por escalar e soma elemento a elemento.

Na computação, quem realiza todos os tipos de comando do Sistema Operacional (SO) são os núcleos do processador (CPU). No caso da operação em questão, podemos distribuir os elementos dos vetores `x` e `y` entre os núcleos de processamento, ou seja, cada núcleo será responsável por executar `a*x + y`, simultaneamente, em diferentes partes dos vetores, e ao final reconstruir o vetor que é resultante da operação (figura 2).

É importante notar que otimizar o tempo de processamento é organizar os núcleos de processamento de forma que todos recebam a mesma quantidade de trabalho ('Load balancing').

Quando Não realizar o paralelismo ?

É notória a vantagem de realizar paralelismo, mas em que condições é possível de se realizá-lo ? O paralelismo vem como alternativa quando diferentes elementos podem ser tratados separadamente. Retomando o exemplo anterior, podemos realizar a operação em um laço de repetição abaixo, onde `z` é um vetor de tamanho N e `i` é o índice do elemento dos vetores :

z[i] = a*x[i] + y[i]

Nessa operação os elementos de memória podem ser separados independentemente, ou seja, a posição um do vetor `x`  (x[0]) não é alterada por nenhuma outra operação.

Para a operação abaixo:

z[i] = z[i-1] + x[i] + y[i-1]

Neste caso, existe uma dependência entre elementos `z`, ou seja, só é possível executar em z[i] se z[i-1] já tenha sido calculada. Neste caso, não é possível realizar o paralelismo em operações deste tipo.

Como começar a realizar o paralelismo

Umas das maneiras mais simples de realizar operações em paralelo é utilizando a biblioteca `PYTORCH`. Esse pacote simplifica e evita que o usuário tenha necessidade de realizar comandos em APIs destinadas a computação paralela como : `CUDA`, `OpenMP` e `MPI`.

Após a instalação do PYTORCH, o primeiro passo é definir o  tipo do dispositivo que será utilizado para realizar as operações :

device = torch.device('cuda' if torch.cuda.is_available() else 'cpu')

Neste caso, estamos decidindo entre dois tipos de dispositivos, o primeiro seria o `cuda` que engloba placas de vídeo de propósito geral (GPGPU) e o segundo seria o `cpu` que é o processador convencional. Uma vez definido em qual tipo de dispositivo serão realizadas as operações, podemos enviar as informações e instruções para os dispositivos a partir da propriedade dos objetos `.to()`. Para exemplificar usaremos a operação z[i] = a*x[i] +y[i] em um loop de repetição. Inicialmente, preenchemos `a` ,`x` e `y` com valores aleatórios:

a = torch.tensor(2.0).to(device)

x = torch.rand(50).to(device)

y = torch.rand(50).to(device)

Assim, enviamos `a`, `x` e `y` para o dispositivo e assim a operação :

a*x+y

Essa operação será distribuída pelas unidades de processamento disponíveis.

Considerações Finais

O paralelismo é uma ferramenta espetacular quando lidamos com a necessidade de operar em uma massa de dados. Agora que passamos pelos princípios do paralelismo, pelas operações que podem ser paralelizadas e qual a biblioteca em Python que é possível realizar paralelismo de forma simples, abrimos espaço para a criatividade e aplicações nas mais diversas áreas do conhecimento, além de conseguir entender qual a verdadeira utilidade do GPU para Ciência de dados.

Créditos

Negócio vetor criado por freepik - br.freepik.com

Primeiramente, o que é uma cultura de dados?

Alexandra é uma analista de marketing de uma rede de restaurantes com foco em cortes nobres. Foi pedido a ela que analisasse a possibilidade de abrir uma filial em um shopping nobre numa das maiores capitais do país.

Alexandra iniciou sua análise consultando uma série de informações:

• Renda per capita da região;
• Faturamento de restaurantes da rede em pontos semelhantes;
• Pesquisas de Percepção de marca;

A decisão dela, cruzando os dados foi : “Deveriam abrir o restaurante, sim”.

Entretanto, seu chefe, que é o diretor de marketing, optou por não abrir. Ele acha que Alexandra fez um bom trabalho, mas alegou que já fora em diversos restaurantes desse shopping e não acha que tenha espaço para eles lá, que as pessoas que frequentavam o local  procuram ‘outra coisa para comer’. Dois meses depois, o maior concorrente da rede deles abriu uma filial nesse mesmo shopping, e acabou virando um dos melhores pontos da marca rival.

Alexandra tomou a sua decisão baseada em uma série de dados, enquanto o seu chefe seguiu o feeling e a experiência pessoal; baseou-se em um achismo no qual estava 100% convicto (e também, muito errado).

Quando somente uma pessoa ou um setor específico de toda a empresa usa informações para embasar as suas escolhas, não temos uma cultura de dados, ou seja, um ambiente corporativo que incentiva o uso de evidências comprovadas para a tomada de decisão.  Entende-se que numa organização com uma cultura de dados, times de diversos níveis hierárquicos usam as análises para ações. Desde o presidente cuidando de indicadores do negócio até vendedores usando informações e dados para definirem a sua abordagem.

Alexandra não trabalha em uma organização que tem uma cultura de dados,  e o  problema pode ir muito além da liderança não ter um perfil analítico. Uma série de pontos corroboram para esse cenário acontecer em diversas empresas, e vamos passar por alguns deles.

Ausência de liderança

Janeiro é uma época de planejamento estratégico do ano que está por vir em muitas empresas. Esse cenário não é diferente para Maria, coordenadora da área de analytics de um hospital particular. A Diretoria traçou um objetivo macro de “Ser uma organização que toma mais decisões com dados”.

Até aqui, tudo parece fácil - Definição clara de onde queriam chegar. Com a ajuda da TI para a exportação de dados, seria tranquilo. Maria sabia o que fazer.

Chegando no mês de entrega, a API que forneceria os dados não tinha sido concluída, a equipe de TI acabou priorizando outros projetos e não conseguiu entregar a tempo. Maria teria que baixar localmente os dados(muitos deles!), sua equipe teria que fazer o input na mão, porém ela não tinha escolha, era necessário fazer dessa forma, mesmo que não fosse uma prática recomendada.

A equipe de analytics não conseguiu ter todos os dados na reunião de entrega. seu painel estava incompleto, no máximo um MVP. Na mesma reunião, o coordenador da TI apresentou uma outra solução -  “Temos essa opção aqui, ainda faltam dados, mas está integrado até no aplicativo do celular”. Longe de ser o que a diretoria esperava, o projeto fracassou.

Era necessário que a diretoria não somente traçasse o objetivo, e sim, que liderasse, garantido que as áreas estivessem se comunicando, que o projeto fosse priorizado e que não houvesse conflitos entre os times.

Uma cultura de dados só terá sucesso na sua implementação se existir coordenação de uma liderança apta em unir os times, não somente exigindo o uso para a tomada de decisão, mas incentivando-as com políticas da empresa. Como mostrado neste artigo sobre ações que devem partir dos superiores, é destacado como os chefes precisam ser exemplos a serem seguidos, e também a elaboração de políticas que estimulem o uso de dados.

Coordenadores dos setores da empresa, como marketing e RH, também precisam de uma liderança. Se os setores não conversarem e tiverem alguém orientando a suas ações para um um objetivo em comum, acabará que cada parte da empresa terá seus próprios dados, com chances de outro setor já ter recolhido essa informação, gerando um sentimento de ‘nós contra eles’, como citado nesse artigo da MIT Sloan.

Os dados são da empresa, não de setores.

Um dos maiores problemas que uma organização pode ter para implementar uma cultura de dados é quando um setor específico acha que é dono dos dados da empresa.

Ilustramos com um exemplo: um analista pede uma tabela com um pouco mais de 100 linhas de informação, algo que pode ser gerado e enviado em minutos. Contudo, acaba que essa tabela só é entregue quinze dias depois e mediante a ordem de um superior. Não existe outra maneira do analista requisitar a informação, ele depende desse setor que demora no fornecimento de dados.

Esse problema se dá por silos de dados.

Segundo esse artigo da Harvard Business Review, os silos podem não virar somente o maior custo da operação de analytics da empresa. Eles podem acabar impossibilitando qualquer iniciativa na área!

Não existe uso de dados sem considerar a visão do usuário.

Um produto ou serviço de dados utilizado por uma organização se for criado apenas pelo propósito de “ter uma tecnologia implementada”, provavelmente irá fracassar.

Para o desenvolvimento de uma cultura de dados, decisões arbitrárias não podem ser tomadas. Se uma equipe de diretores necessitam acompanhar indicadores das suas fábricas semanalmente, é necessário antes de mais nada, consultar que tipo de decisão eles tomam, quais são os indicadores estratégicos e táticos que necessitam de acompanhamento.

Não adianta nada desenvolver um painel de BI que se atualiza automaticamente com integração no app do celular, se o usuário final não usar.  Ou até mesmo, se a aplicação teve um bom engajamento de uso no início da sua implementação, sem um acompanhamento e feedback de necessidades ao longo do tempo, nada impede que ela vire obsoleta.

O Processo importa mais que o resultado.

Okay, você deve estar pensando “Como algo burocrático, que muitas vezes é perda de tempo, vai ser mais importante que entregar um resultado?” A resposta é simples: o processo permite auditar o resultado, permite garantir que ele não é fruto do acaso ou que possa passar no teste do tempo.

Não existe uma cultura de dados sem a confiança no que está sendo gerado.

Pensar em tecnologia antes de pessoas é o erro que antecede muitos outros.

Nossa intuição leva a crer que para implementar uma cultura de dados em uma empresa, é necessário investir na melhor tecnologia possível. Porém, não adianta nada ter a melhor infraestrutura, o BI mais robusto, máquinas com as melhores GPUs do mercado se não existe o investimento em pessoas e lideranças.

Quem vai operar o algoritmo que permite prever vendas são pessoas. Quem vai garantir que as áreas estão conversando e operando em conjunto para atingir os objetivos da organização são lideranças (que também são pessoas).

Uma cultura voltada à tomada de decisão através de dados não surge em semanas ou poucos meses. Se conquista no longo prazo. Um time de futebol vencedor dificilmente será o campeão com uma temporada boa somente: é um trabalho de anos para ter uma equipe sólida. A equipe do Palmeiras não vem conquistando diversos títulos sem antes ter tido uma reformulação. É um esforço de quase uma década.

Ao fim do dia, a implementação da cultura analítica em qualquer empresa depende intimamente das pessoas envolvidas no processo, e não das máquinas que elas operam.

Otimizar um modelo de machine learning é um dos temas mais debatidos na área de ciência de dados. Somente escolher um conjunto de algoritmos e analisar qual possui a melhor performance para o problema, não entregará o melhor resultado. Sempre que falamos de treino e otimização de modelos de machine learning, falamos de Hiperparâmetros. Mas o que são eles e por que são tão importantes?

O que são hiperparâmetros e qual a sua importância?

Hiperparâmetros são atributos que controlam o treinamento do modelo de machine learning: com eles podemos tornar o modelo mais preparado para resolver um determinado problema da vida real. Fazendo a comparação com um carro, podemos associar os  parâmetros com o motor e a gasolina e os hiperparâmetros são como a direção, o sensor de velocidade e retrovisores. O carro funciona somente com motor e gasolina. Contudo, sem os outros equipamentos, podemos levar o veículo a um desastre porque não teríamos o controle dele.

Por isso que os hiperparâmetros são tão importantes para um algoritmo! Eles previnem o modelo de aprender apenas com os dados mostrados (overfitting e underfitting), tornando-o capaz de generalizar para outras situações possíveis.
Muitas vezes, eles são deixados de lado, pois os frameworks deixam os seus valores em defaults nas suas funções. Uma situação bem clara é o RandomForest do sklearn:

Percebam que todos os hiperparâmetros estão com valores pré-estabelecidos.

Sabendo que todos os modelos possuem hiperparâmetros, então, como encontrar o melhor? Esta resposta não é fácil, pois varia de algoritmo para algoritmo, do tipo de dados, das versões dos frameworks, da linguagem de programação e da plataforma (seja local ou cloud). Modelos de deep learning são ainda mais complexos nesse aspecto, já que  são formados por camadas e cada uma delas possui células com hiperparâmetros:

Retirado do site da documentação: https://www.tensorflow.org/api_docs/python/tf/keras/layers/LSTM

À medida que aumentamos esses hiperparâmetros, tanto o tempo treinamento e de teste aumentará. Segundo o livro, The Elements of Statistical Learning: Data Mining, Inference, and Prediction, se você regular o `max_depth` ou `n_tree` o modelo terá um desempenho melhor, porém, não adiantaria ter um algoritmo de alta performance enquanto a inferência demora mais tempo. Seria um fiasco colocá-lo em produção.

Como escolher os melhores Hiperparâmetros?

Para essa escolha, não é recomendado alterar os valores um de cada vez e ir computando os melhores resultados. Isso não seria eficiente em tempo e provavelmente não seria encontrado o melhor valor possível para o problema.

Por isso utilizamos técnicas como Grid Search ou Random Search aliados ao K-Fold, que são métodos específicos para trabalhar com o problema de forma programática - ou seja, o algoritmo encontrará a melhor solução.

O Grid Search testará todas as combinações a partir de um grid de hiperparâmetros pré-definido pela equipe para mais informações vejam este link). O Random Search, por sua vez, não testará todas as combinações, estando limitado a um valor  de testes dos hiperparâmetros estipulado pela equipe antes de rodá-lo (para mais informações vejam este link). O objetivo é encontrar o melhor modelo ou um caminho de como equilibrar os hiperparâmetros.

Por fim, o K-Fold é uma forma de dividir os dados em K conjuntos para treinar e testar com estas diferentes partes. Se for escolhido K = 10, haverá 10 partições no conjunto de dados, sendo uma para treino e as outras nove para teste.

Após uma etapa de treino e teste, o algoritmo roda novamente, mas com uma nova partição de teste e treino. O objetivo do K-Fold é verificar a capacidade de generalização de um modelo dado um determinado conjunto de hiperparâmetros, assim, é mais provável vermos se há overfit ou não com ele.

Para avaliar a performance de um hiperparâmetro, não se deve levar em consideração somente os valores das métricas de classificação dos modelos. É necessário levar em conta o  tipo de problema (classificação, ranqueamento, clusterização, etc.), o tempo de treino e teste e até mesmo regras específicas de negócio.

Como os hiperparâmetros funcionam na prática?

Para ilustrar melhor as duas técnicas, trouxemos dois exemplos: O primeiro utiliza Grid Search e K-Fold para avaliar o melhor conjunto de hiperparâmetros do modelo Random Forest do sklearn para o dataset íris.O segundo, por sua vez, utiliza Random Search e K-Fold, mas com um modelo diferente, um de deep learning.

O exemplo acima exibe os  valores dos hiperparâmetros  e também o resultado do modelo, que possui uma acurácia de 96%. Logo abaixo, num um modelo simplificado de  deep learning, foram testados os hiperparâmetros de `batch_size` e `n_epochs` (é possível testar com muito mais opções - veja neste link quais outros hiperparâmetros poderiam colocar numa célula de mlp link).

Para conferir com mais detalhes esse código, acesse o nosso repositório no Github.

O que aprendemos sobre hiperparâmetros?

Quando falamos de algoritmos de machine learning ou deep learning, não podemos deixar de falar de hiperparâmetros. Como foi mostrado, eles são essenciais para direcionar um modelo, melhorando o seu desempenho e evitando que o mesmo aprenda somente os dados que foram treinados (portanto, generalizando para situações da vida real). Contudo, para a identificação do conjunto de hiperparâmetros mais adequado ao problema são necessárias técnicas que otimizem o seu uso testando as suas diversas combinações. Portanto, podemos ser categóricos quanto a isso: Nunca deixem de lado a otimização dos hiperparâmetros!

É bastante comum que para a construção de produtos digitais, estejam eles vinculados a uma startup ou a uma empresa com maior tempo de mercado, precise de uma etapa que faça o alinhamento dos objetivos do produto com o negócio e o problema dos usuários a ser resolvido.

Para isso, diversas técnicas foram criadas baseadas ou no Design Thinking (DT), definido pelo executivo da IDEO como:

Design thinking is a human-centered approach to innovation that draws from the designer’s toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success. (Tim Brown, Executive Chair)

Ou com o uso de ferramentas que facilitam o entendimento do negócio e integram conceitos do DT, como: Business Model Generation e Lean Startup.

A partir desse kit de ferramentas, uma série de dinâmicas foram desenvolvidas para que produtos e serviços possam corresponder às necessidades de seus usuários e, ao mesmo tempo, às metas do negócio. Algumas dessas dinâmicas baseadas em Design Thinking e Business são: Design Sprint (Google) e Lean Inception (Caroli). Não podemos excluir também os métodos tradicionais que iniciaram com as áreas marketing e engenharia de software, como: Focus Groups e Casos de Uso (UML).

Essas técnicas já estão tão difundidas no mercado que, hoje em dia, é até difícil encontrar uma empresa que desenvolva produtos ou serviços digitais que não inclua no seu processo alguma parte dessas metodologias com o objetivo de atender melhor ao seu cliente. O interessante dessa vibe human-centered é que parece que ela não chegou aos projetos de ciência de dados. Você sabe responder por quê?

Os projetos de dados ainda estão presos na caixinha da TI das organizações.

É só em falar o nome CIÊNCIA DE DADOS que já vem uma sensação de ser uma "coisa" de outro mundo e que apenas pessoas que conversam com números é que podem atuar nessa área.

E é exatamente ai que os projetos de dados saem perdendo. Uma situação comumente encontrada em empresas, sejam elas do setor público ou privado, pequenas ou grandes organizações, é a seguinte:

Os projetos analíticos muitas vezes são tratados pela liderança como se fossem uma simples geração de relatórios, métricas e algoritmos que ficam exclusivamente sob a responsabilidade do time de BI ou dos cientistas de dados. Por outro lado, os gestores, usuários finais do produto analítico, ou o usam para reafirmar decisões já tomadas ou precisam refazer suas próprias análises para conseguir a informação realmente pertinente à tomada de decisão.

Nesse processo desconexo, perdemos por completo o valor que um insight vindo dos dados pode trazer ao negócio pelo simples fato dele estar totalmente desvinculado dos objetivos da empresa, da tomada de decisão e por serem de difícil interpretação. Ou seja, ainda que a organização tenha um super projeto de IA e que a liderança acredite que essa é uma inovação capaz de transformar o negócio sozinha, na prática o que vemos é um resultado um pouco diferente.

Neste artigo da CIO constam 5 desastres com projetos de IA, perceba que estes são desastres porque estão relacionados à grandes players do mercado. E quanto aos projetos de IA que custaram alguns milhares para sua empresa e acabaram virando um produto que nenhum gestor usa ou confia? Oooops!

Não vincular os dados ao negócio, é uma questão cultural. Ter medo de falar sobre projetos analíticos com os colaboradores, é uma questão cultural. Tratar projetos de dados como se fossem de uma área só, é uma questão cultural. Em uma pesquisa sobre o uso de IA na América Latina feita em parceria com o MIT Tech Review a cultura organizacional é trazida como um dos maiores desafios para esse tipo de projeto:

A cultura é uma preocupação realmente grande dos gestores, sendo que 60% deles têm receio de conversar com os colaboradores sobre a adoção de projetos de IA e seus impactos internos. (Sara Álvarez, editor do MIT Technology LATAM)

É importante lembrar que, normalmente, produtos de dados servem ao público interno das empresas e que em geral o processo de desenvolvimento destes produtos não possui as mesmas preocupações com: definição do problema, conexão aos objetivos do negócio ou experiência do usuário. Por se tratar de um produto interno, também é frequente a percepção de custo alto aliada a dificuldade de conseguir visualizar o retorno sobre esse investimento.

• Quanto custará o desenvolvimento?
• Quantas pessoas vou precisar direcionar?
• Quanto e quando esse produto vai trazer retorno?

Essas são algumas das perguntas presentes na cabeça das lideranças e você sabe como podemos ajudar a respondê-las? Conectando o desenvolvimento dos produtos analíticos com o os objetivos de negócio! Projetos internos precisam de um time multidisciplinar, da definição do problema, da conexão com métricas chave de negócio, da conexão com a tomada de decisão! Um dado precisa ser útil à tomada de decisão, um gestor precisa olhar a informação e conseguir fazer o que precisa ser feito com ela, seja mudar um processo interno, direcionar uma campanha ou redirecionar um time.

É muito fácil se perder na exploração dos dados sem ter um objetivo claro. Assim como é fácil se perder em vieses de confirmação na hora de tomar uma decisão. O processo de conexão do negócio com produtos de dados não deverá ser exatamente o mesmo feito para produtos digitais, mas com certeza podemos fazer o que a ciência vem nos ensinando há centenas de anos: experimentar, aprender e ajustar.

Tem um artigo super interessante da MIT Sloan que fala sobre Moving to Decision-Driven Data Analytics e traz umas dicas de como realizar essa mudança:

To move to a decision-driven data analytics approach, a company must start by identifying the business’s key decisions and the people who make them, and finding data for a purpose rather than finding a purpose for the data at hand. (MIT Sloan)

Quem sabe essa não seria uma ótima oportunidade de começar a desenvolver sua equipe para trabalhar de forma mais colaborativa e multidisciplinar e finalmente responder à liderança da empresa qual o retorno sobre o investimento no desenvolvimento de produtos internos.

Quando ouvimos sobre a potencialidade da aplicação da Inteligência Artificial (IA) para impulsionar a competitividade do negócio, a primeira coisa que pensamos é: Preciso fazer isso na minha empresa! Ainda mais em um mundo cada dia mais VUCA (Volátil, Incerto, Complexo e Ambíguo).

E esse pensamento está correto! Com a quantidade e variedade de informações disponíveis para análise, precisaremos muito dos algoritmos como aliados para trazer insights acionáveis, ou seja, relevantes à tomada de decisão.

Porém, o que precisamos ter em mente é que, para um projeto que tem como objetivo a aplicação da IA ter sucesso, é provável que o caminho percorrido seja extenso e com muitas fases para validação e melhoria contínua.

Para entendermos um pouquinho mais sobre esse processo de desenvolvimento, vou trazer como exemplo uma pirâmide de necessidades para a aplicação da IA. Essa pirâmide traz de forma visual que, para termos insights automatizados, antes precisamos do básico, como uma boa Infraestrutura.

Na base da pirâmide temos a coleta de dados (collect). Muitas vezes não coletamos ou armazenamos dados que podem servir como agregadores na hora de aplicar algoritmos de machine learning. Por exemplo, se tivermos uma base de dados que, por mais que pareça volumosa pode não ter uma boa variedade de informações, é possível que o algoritmo não encontre um padrão nos dados que justifique o uso da IA. É como diz Cassie Kozyrkov, Cientista Chefe da Google, em seu artigo para towards data science:

O aprendizado de máquina é uma abordagem para automatizar decisões repetidas, que envolve encontrar padrões nos dados através do uso de algoritmos e, usá-los para fazer modelos que lidam corretamente com os novos dados. (Cassie Kozyrkov, tradução livre)  

Então, a primeira coisa a fazer é uma análise exploratória dos dados e entender o que de fato podemos definir como padrão ou diferenciação nas informações, além de identificar como podemos enriquece-los com o uso de outras bases. Na DSB, todo projeto de Ciência de Dados inicia com um estudo ou uma análise exploratória, é exatamente nesse momento que identificamos a potencialidade das informações geradas pela empresa.

Em seguida temos armazenamento e transação dos dados (move/store). Para que um produto de dados com base em IA funcione, precisamos ter esses dados armazenados em uma estrutura que de suporte a coleta, o processamento, a transformação e o consumo da informação. Imagine que o algoritmo de machine learning irá receber novas informações ao longo do tempo, e que essas informações vão ter formatos e tempos variados, as definições de Infraestrutura e Governança serão o guia da empresa para realizar as modificações necessárias.

No centro da pirâmide temos exploração e transformação dos dados (explore/transform). É aqui que garantimos a qualidade dos dados consumidos pelos algoritmos e também, a qualidade dos insights gerados pela IA. Em um artigo para MIT Sloan, Langhe e Puntoni trazem isso através do ponto de vista dos executivos:

As empresas têm mais dados do que nunca, mas muitos executivos dizem que suas iniciativas de análise de dados não fornecem insights acionáveis e, no geral, produzem resultados decepcionantes. (Langhe e Puntoni, tradução livre)

Podemos fazer a seguinte analogia, se recebermos um diagnóstico de uma doença errado, não iremos tomar as ações necessárias para melhorar nossa saúde, o mesmo acontece com algoritmos que recebem dados erradas, eles passam resultados igualmente errados e que nos levam a tomar más decisões.

Durante uma fase de exploração dos dados é possível identificar os problemas relativos a qualidade dos dados consumidos para análise, mas principalmente permite definir quais as informações realmente relevantes aos objetivos do negócio.

Em penúltimo lugar, temos agregação e rótulos (aggregate/label). Essa é a fase com maior necessidade de experimentos e validações, é aqui que, entendendo os dados que possuímos, fazemos experimentos utilizando modelos algorítmicos variados e definimos qual desses modelos de machine learning é o ideal para atender aos objetivos propostos.

Gosto de comparar essa fase com o método científico. Conforme vamos fazendo as aplicações das técnicas de machile learning, vamos descobrindo mais sobre os dados e, consequentemente surgem novas hipóteses e testes que precisam ser realizados.

Nessa fase acontece a criação de segmentos através dos padrões encontrados nos dados, como por exemplo a segmentação de clientes féis ao negócio. Também é possível mapear pontos de atenção através da construção de métricas que auxiliam na identificação de gargalos no atendimento ao cliente, onde podemos descobrir que estes gargalos estão causando um abandono (churn) representativo ao negócio.

Por fim, e não menos importante, temos aprendizado e otimização (learn/optimize). Essa é a fase da pirâmide que exemplifica o porquê de um projeto de IA não terminar com um produto e estar em contínuo aprimoramento. Aqui são feitos experimentos e testes em cima dos resultados obtidos pelo algoritmo e, com essas informações, retroalimentamos o algoritmo, para que assim ele possa aprender com seus erros, fazendo uma analogia à nós, seres humanos.  

Para dar continuidade a um projeto de IA a empresa precisa ter profissionais habilitados a trabalhar em todo o processo, desde a coleta até a disponibilização da informação para consumo. Lembrando que ter uma IA trazendo informações relevantes de forma automatizada não inclui uma transformação apenas da área técnica da empresa, mas inclui principalmente uma transformação cultural na tomada de decisão pelos executivos.

Muitas pessoas usam os dados apenas para se sentir melhor sobre as decisões que já tomaram. (Cassie Kozyrkov, tradução livre)

Aqui na DSB auxiliamos na formação de squads multidisciplinares, impulsionando a transformação cultural através de mentorias que acontecem ao longo do desenvolvimento dos projetos. Somos especializados na identificação do potencial dos dados disponíveis nas empresas, acelerando projetos que visam o uso da IA para criação de insights acionáveis.

Podemos perceber que usar técnicas de IA para alavancar as decisões e tornar a empresa mais competitividade é um processo denso, passando pela construção de uma base forte que prevê todas as fases abordadas neste artigo: coleta, armazenamento, transformação, agregação e aprendizado. Apenas depois de passarmos por elas é que poderemos dizer que aplicamos Inteligência Artificial.

Um ponto não  abordado na pirâmide, mas tão relevante quanto, é como a empresa irá consumir esses insights. Desde a definição das áreas que terão acesso até o formato de acompanhamento, como por exemplo através de alertas ou dashboards à vista. O importante nesse ponto é entender qual o melhor formato para facilitar a ação dos gestores.

Se você está se sentindo um pouquinho atrasado, essa é uma boa sensação, agora aproveite ela e vá para ação. Mapeie os conhecimentos da sua equipe, se aprofunde nos detalhes sobre os dados da sua empresa, identifique quais os possíveis gargalos na criação de análises e quais delas estão sendo realmente utilizadas, fale com seus gestores e liste informações que eles sentem falta. Com essas e outras informações em mãos, comece.

Comece pequeno, mas comece hoje!

Fontes: The AI Hierarchy of Needs, Data-Driven? Think again (Hackerenoon); Leading With Decision-Driven Data Analytics (MIT Sloan); When not to use machine learning or AI (towards data science).

Machine learning (do Inglês - Aprendizado de Máquina) é uma área em alta demanda no mercado. Segundo o fórum econômico mundial existe a expectativa de 58 milhões de empregos em IA no mundo até 2022. Porém, de acordo com o Instituto de pesquisa de Tencent, estima-se que em 2017 havia apenas 300 mil engenheiros de IA no mundo, indicando que haverá uma baixa oferta de mão de obra especializada.

Quando desenvolvemos uma aplicação de Machine Learning do início ao fim passamos por várias etapas como limpeza e transformação de dados, engenharia de features, seleção de features e de algoritmos, predição e interpretação do modelo.

Essas etapas exigem diferentes conhecimentos dos especialistas no assunto, sejam eles Engenheiros de IA ou Cientistas de dados, desde conhecimentos gerais como estatística, cálculo e álgebra linear, até conhecimentos mais específicos como as técnicas de seleção de features e algoritmos, conhecimento dos hiperparâmetros de cada algoritmo e como ajustá-los, etc. Na maioria das vezes o ajuste desses hiperparâmetros irá demandar testes exaustivos, muitas vezes sendo encontrados apenas por tentativa e erro de acordo com a tarefa ou conjunto de dados usado.

Dessa forma o AutoML, ou Automated Machine Learning (do Inglês - Aprendizado de Máquina Automatizado) surge como uma opção para uso de Machine Learning por não especialistas no assunto, ou até para “desafogar” especialistas no assunto que necessitem focar em outras tarefas enquanto a automatização de algumas etapas é feita. O AutoML pode ser descrito como o processo de automatizar a aplicação do Aprendizado de Máquina a problemas do mundo real, geralmente cobrindo as etapas de engenharia de features, seleção de algoritmos e otimização de hiperparâmetros.

Existem diversos métodos para se aplicar AutoML, podemos dizer que os três mais comuns na literatura são HPO (Hiperparameter Optimization), Meta-learning e NAS (Neural Architecture Searching).

Hiperparameter Optimization

Todos os algoritmos de Machine Learning possuem hiperparâmetros que precisam ser ajustados para que os resultados sejam otimizados, e uma das tarefas mais básicas do AutoML é fazer a configuração automática desses hiperparâmetros. A otimização automatizada de hiperparâmetros possui diversos casos de uso importantes como: reduzir o esforço humano necessário para se aplicar Machine Learning; aumentar a performance de algoritmos de Machine Learning; aumentar a reprodutibilidade e a replicabilidade em estudos científicos, etc.

Dentro do HPO temos o conceito de Combined Algorithm Selection and Hyperparameter Optimization Problem ou CASH, que se resume em, dado um conjunto dados, escolher automaticamente o algoritmo de aprendizado e de forma simultânea configurar seus hiperparâmetros de forma que o desempenho nesta tarefa seja otimizado. Neste tipo de problema, o tuning do pipeline de Machine Learning é feito modelando a escolha entre os diferentes pré-processamentos e algoritmos de ML como hiperparâmetros categóricos.

Meta-learning

Por sua vez, meta-learning, ou aprender a aprender, é a ciência que observa como diferentes abordagens de machine learning são executadas em diversas tarefas de aprendizado, e então buscam aprender a partir dessa experiência para então se ajustar a novas tarefas mais rápido.

Veremos um exemplo de aplicação de meta-learning ao falarmos da primeira etapa da abordagem de AutoML do Auto-Sklearn.

Neural Architecture Searching

O investimento em pesquisas na área de Deep Learning trouxe avanços consideráveis principalmente para tarefas perceptuais como reconhecimento de texto, voz, imagens e machine translation. Um dos motivos do sucesso dessas arquiteturas se dá pelo fato delas automatizarem o processo de engenharia de features, porém elas também trazem uma alta demanda no processo de engenharia de arquitetura, que vem sendo projetadas manualmente mesmo com as arquiteturas neurais cada vez mais complexas.

Nesse contexto vem surgindo as pesquisas em Neural Architecture Searching (NAS, do Inglês busca de arquiteturas neurais), o processo de automatizar a engenharia de arquitetura. Este campo de estudo que tem uma boa interseção com as áreas de HPO e meta-learning e pode ser categorizado em três etapas: I) Search Space (Espaço de busca), II) Search Strategy (Estratégia de busca), e III) Performance Estimation Strategy (Estratégia de estimativa de desempenho).

O espaço de busca define quais arquiteturas podem ser usadas a princípio, enquanto a estratégia de busca detalha como esse espaço de busca será explorado, que pode ser desde o uso de busca aleatória, otimização bayesiana, algoritmos evolucionários, ou até aprendizado por reforço. Já a estratégia de estimativa de desempenho busca validar de forma eficiente as escolhas de arquiteturas, buscando alcançar o objetivo do NAS que é encontrar arquiteturas que tenham alto desempenho em dados não usados durante o treinamento.

Sistemas de AutoML

Existem diversos exemplos de sistemas que implementam o AutoML, iremos citar alguns dos mais populares.

Auto-Weka

O Weka é uma das ferramentas mais populares de Machine Learning feita em Java e que possui uma interface gráfica de fácil utilização. O Auto-Weka foi construído sobre a interface do Weka, sendo incorporado como um dos classificadores a serem escolhidos na sua interface gráfica.

Um ponto importante ao se falar do Auto-Weka é que o artigo publicado referente a sua aplicação foi o primeiro que trouxe o termo CASH citado anteriormente.

Hyperopt-Sklearn

Pensando em trazer a ideia de incorporar o AutoML a uma interface já popular de uso de Machine Learning, mas dessa vez em Python, foi criado o Hyperopt-Sklearn. Esta aplicação foi desenvolvida sobre a API do scikit-learn, biblioteca mais popular de Machine Learning da linguagem Python.

Podemos dizer que o Hyperopt-Sklearn funciona muito mais como um template geral para se aplicar AutoML do que como um sistema de AutoML em si, pois ele traz uma interface bastante flexível e adaptável.

Para usar o Hyperopt-Sklearn devemos definir três coisas: 1) Um domínio de busca; 2) Uma função objetivo; e 3) Um algoritmo de otimização. Alguns classificadores e otimizadores já vem por padrão na biblioteca porém o usuário tem a liberdade de utilizar ou até implementar seu próprio algoritmo.

Auto-Sklearn

Talvez um dos mais populares na literatura, o Auto-sklearn é um sistema de AutoML também baseado na API do scikit-learn. Um diferencial do Auto-Sklearn é sua abordagem de AutoML dividida em três etapas: 1) Meta-learning; 2) Otimização Bayesiana; e 3) Construção de ensembles.

Na primeira etapa, o Auto-Sklearn coleta meta-features sobre o conjunto de dados de entrada e então com base em conjuntos de dados previamente utilizados ele define um espaço de busca já otimizado que obteve bons desempenho em conjuntos de dados similares. Dessa forma, o sistema já passa por uma otimização inicial e vai para a etapa de otimização bayesiana que fará o processo de seleção de algoritmos e hiperparâmetros de forma simultânea. Finalmente, o Auto-sklearn chega na etapa de construção de ensembles, em que ele não apenas seleciona os melhores algoritmos escolhidos a partir da otimização bayesiana mas forma ensembles (ou comitês de algoritmos) a partir deles.

Afinal, o AutoML substituirá o Cientista de dados?

É natural que a medida que o AutoML se desenvolva e ganhe mais adeptos comecem a surgir questionamentos sobre o fato dele possivelmente substituir o trabalho do Cientista de dados, o que não necessariamente será verdade.

Hoje, o AutoML possui diversas limitações, uma delas é o fato dele não alcançar o estado da arte em diversas tarefas, principalmente aquelas que envolvem processamento de texto, imagens e voz. Ou seja, se você quer alcançar melhores desempenhos nestas tarefas é importante ter conhecimento de negócio e dos algoritmos mais utilizados.

O que pode acontecer no futuro é que, com o avanço no desempenho desses algoritmos, o Cientista de dados fique cada vez mais focados em tarefas de limpeza de dados, pré-processamento e interpretação do modelo, enquanto o AutoML fique cada vez mais concentrado em tarefas de seleção de modelos e configuração de hiperparâmetros. Então se hoje o Cientista de dados foca a maior parte do seu tempo nessa etapa inicial de tratamento de dados, a tendência é que foque cada vez mais.

Além disso, algo que o AutoML não possui é o conhecimento de negócio, fator muito importante na modelagem do problema e na etapa de engenharia de features, tornando o trabalho do Cientista de dados essencial. Você pode entender um pouco melhor esse processo de entendimento de negócio e como fazer as perguntas certas aqui.

Caso queira conhecer alguns detalhes a mais sobre AutoML e ver um pouco de código você pode conferir minha palestra na Python Brasil 2020 aqui ou ver os slides e códigos aqui.

Links

• Confira nossa palestra no Python BR 2020 sobre AutoML em Python:

• Slide palestra pybr: https://docs.google.com/presentation/d/1vQB0D1NA7-_YTQPFhA6MVv7bXHc757zw1p_t9if9WNY/edit?usp=sharing
• Veja o código: https://github.com/andradejunior/pybr2020-automl

Referências:

Automated machine learning: methods, systems, challenges. Frank Hutter, Lars Kotthoff, J. Vanschoren.

https://github.com/automl/autoweka

https://hyperopt.github.io/hyperopt-sklearn/

https://automl.github.io/auto-sklearn/master/

Palestra “machine learning made easy(ish)” - Leonardo Bezerra  na Python Brasil [14]: https://www.youtube.com/watch?v=nuRDxYF_35A

https://medium.com/data-hackers/automl-uma-nova-abordagem-de-machine-learning-87a40d866dc1

https://medium.com/data-hackers/automated-machine-learning-automl-70c1eab669ad

https://www.forbes.com/sites/amitchowdhry/2018/09/18/artificial-intelligence-to-create-58-million-new-jobs-by-2022-says-report/#4a5232ae4d4b

https://www.theverge.com/2017/12/5/16737224/global-ai-talent-shortfall-tencent-report

Ontem, dia 17/11/2020, foi o primeiro dia da Mercopar, a feira de inovação industrial que acontece em Caxias do Sul na serra gaúcha, organizada pelo Sebrae RS e FIERGS. E nós da DSB estamos lá marcando presença!

Nosso estande fica bem na entrada do Salão de Inovação do evento e o primeiro dia foi repleto de bate-papos com empresas e visitantes da feira sobre a análise e inteligência de dados. O Leandro Devegilli, sócio co-fundador da DSB, também deu uma palestra no final do dia sobre Cultura Analítica nas empresas, reforçando que a tecnologia nas empresas deve estar sempre alinhada com as estratégias de negócios para ter os melhores resultados possíveis.

Ah, e quem visita nosso estande já pode acompanhar em primeira mão o TiMiT - a nossa ferramenta de análise inteligente e visualização de linhas do tempo! O TiMiT pretende revolucionar a forma como empresas enxergam o ciclo de vida dos seus produtos e acompanha seus clientes. Se quiser entender mais ou ser informado quando o produto for lançado, mande um e-mail para hello@dsbrigade.com :)

A feira vai até dia 19/11, com programação a partir das 13h. Quem conseguir comparecer presencialmente, não esqueça de usar a máscara e respeitar o distanciamento, tem um controle de quantidade de participantes simultâneos na feira e dentro dos salões.

E quem não puder, pode acompanhar as palestras pelo site do evento também: https://mercopar.vpeventos.com/

O Processamento de Linguagem Natural ou NLP (do Inglês - Natural Language Processing) é o campo de estudo focado nas interações entre a linguagem humana e os computadores. Se trata de um campo de característica mista compreendendo um pouco de diversas áreas como Linguística, Ciências da Computação, Inteligência artificial e Linguagem computacional.

Atualmente, tem-se observado um hype em relação a presença cada vez maior da inteligência artificial em diversos segmentos da nossa sociedade. As aplicações desta área podem ser vistas  em nossos smartphones, ferramentas de busca como o Google e sistemas de recomendação que curiosamente entendem, de alguma forma, como temos nos comportado na internet (quem nunca se perguntou: "como o meu celular sabe que eu estou querendo comprar um liquidificador!?"). Isto nos leva a pensar: “mas afinal...como isso ocorre?  e como isto se relaciona com inteligência artificial, machine learning (aprendizado de máquina) ou deep learning (aprendizagem profunda)?” O uso destes termos vem sendo utilizado em uma espécie de "salada" causando confusão entre as pessoas. Entretanto, existe uma ordem de classificação entre estes campos que nos ajuda a compreender suas separações e suas relações.

Vamos diferenciar: NLP é Inteligência Artificial ou Machine Learning ou Deep Learning?

Aparentemente, ainda não existe uma definição ou um encaixe da NLP em alguma destas áreas de forma tão precisa. Ela, na verdade, flutua entre todos os 3 campos. Primeiramente precisamos entender a diferenciação destas áreas e depois verificar onde a NLP se encaixa ou parcialmente se encaixa.

As primeiras concepções sobre inteligência artificial se iniciaram dentro da filosofia na tentativa de descrever o pensamento como um sistema simbólico observando-se seus primeiros usos em meados da década de 50 na Universidade de Hannover por John McCarthy. Hoje em dia se concebe a Inteligência Artificial como um grande campo que contém Machine Learning como subcampo que, por sua vez, possui o deep learning como subcampo. Entende-se assim, a Inteligência Artificial como uma grande área onde estão alocados os campos machine learning e deep learning. Abaixo, vemos uma representação da relação de pertencimento entre estas áreas e suas concepções ao longo do tempo:

Mas e a NLP, aonde fica?

Agora que tivemos uma abordagem sobre a relação dos principais grupos (Inteligência Artificial, Machine Learning e Deep Learning) vamos falar sobre aonde a NLP se encaixa e tentar entender um pouco sobre o processo básico de como as máquinas processam nossas formas de linguagem para nos retornar respostas ou soluções!

Na verdade a NLP é uma combinação de linguística, inteligência artificial e linguagem computacional. Veja bem, a palavra linguagem aqui é extremamente importante pois é através do conhecimento de como o nosso cérebro processa a linguagem e de como funciona a linguagem que o computador usa que humanos e computadores podem "conversar" de  forma parecida. Tentamos neste caso pensar, afinal como um Brasileiro se comunicará com um chinês se nenhum dos dois forem proficientes um no idioma do outro? Este é um exemplo básico de dois humanos tentando se comunicar (ambos usam linguagem humana), entretanto, aqui falamos de uma interação entre linguagem humana x computacional. A figura abaixo representa a interação da área da linguística com a Inteligência artificial, machine learning e deep learning e a NLP sendo fruto desta interação.

O ser humano já domina a linguagem dos computadores pois foi ele mesmo que a criou. Portanto o processo se dá com o homem usando a linguagem de programação para que o computador aprenda a linguagem humana. Parece confuso mas algo parecido ocorre quando um professor brasileiro de inglês ensina inglês para um outro brasileiro que não sabe inglês. Ele usa o português para ensinar inglês (usa uma língua para ensinar a outra) e se utiliza de ferramentas de ensino. Na NLP  usamos técnicas de machine learning e deep learning (usando a linguagem da máquina) para facilitar e otimizar o aprendizado da própria máquina sobre a linguagem humana. O algoritmo aqui seria análogo a uma ferramenta de ensino.

Com um entendendo a língua do outro tudo fica mais fácil!

A NLP busca justamente criar uma conexão entre nossa linguagem e a usada pelo computador permitindo que a máquina interprete o que foi dito ou escrito por nós e assim, possa interagir conosco. Para que haja esta interação, precisamos ensiná-la aspectos de nossa linguagem como: sintaxe (gramática), semântica (significado), morfologia (intensidade das palavras) e pragmática (conversação). Como vemos, a tarefa não é nada fácil e exige a aplicação de técnicas como tokenização, lematização entre outras.

A NLP pode ser dividida em Compreensão de Linguagem Natural ou NLU, do Inglês - Natural Language Understanding e Geração de Linguagem Natural ou NLG, do Inglês - Natural Language Generation. Aqui, a informação textual  é fornecida ao computador - processada avaliando ambiguidade léxica, sintática e referencial (NLU) - e então uma resposta por parte da máquina é emitida (NLG) após o planejamento de texto, frases e a estruturação do texto de fato. O esquema abaixo mostra o fluxo da informação e divisões da NLP.

Divisões da NLP e tarefas executadas em cada uma. Data Science Foundation (2020).

Assim, a NLP permite que computadores compreendam conteúdo não estruturado utilizando algoritmos para fazer derivações e dar contexto a linguagem de forma similar ao cérebro humano. Se trata de um mecanismo para analisar e traduzir sinais de nossa linguagem que podem inclusive ajudar organizações a ter uma melhor compreensão do comportamento das pessoas em relação a seus produtos, serviços ou marca comparando, inclusive, com a concorrência.

Abaixo, alguns exemplos de como a NLP pode ser usada:

Como a NLP pode ser usada no reconhecimento de nossa linguagem para aplicação em diversas áreas. Data Science Foundation (2020).

Claro que ainda se enfrentam diversos obstáculos dentro do universo da NLP devido a complexidade da nossa linguagem. Nós não percebemos a quantidade de erros e de modulações/ajustes inconscientes que nossa linguagem falada ou escrita possui. Por exemplo, uma pessoa quando fala ou escreve comete erros de gramática, muda as frases e o sentido das mesmas durante os discursos e ainda mistura termos de outros idiomas (estrangeirismos). Ainda, possuímos diferentes inclinações de pronúncia, dialetos, entre outros. Em virtude disso, muitas vezes, as queridas Alexa e Siri não nos compreendem.

Bom, e a linguagem não verbal? Aquela que não é falada e não é escrita mas sim vista e interpretada? Creio que seja um assunto talvez para uma próxima conversa...

Quem quiser saber mais detalhes sobre este assunto e sobre outras técnicas usadas em NLP, é só acessar este excelente passo a passo publicado pela DataScience Foundation neste ano:

Natural Language Processing (NLP) Simplified : A Step-by-step Guide

As researchers push the boundaries of Natural Language Processing (NLP), the technology is becoming more embedded in our everyday lives. These advances will result in significant changes to the way we live. As an important facet of artificial intelligence, natural language processing is going to con…

Follow (7)Agency

Ou então, acessar o material da própria wikipedia que além de detalhar processos mais complexos de processamento de linguagem natural, nos traz relações, inclusive, da NLP com a cognição humana:

https://en.wikipedia.org/wiki/Natural_language_processing

Já falamos aqui no blog da necessidade de se fazer as perguntas certas em projetos de dados e dos desafios da comunicação do trabalho remoto.

Um outro aspecto mais técnico que faz parte do dia-a-dia dos cientistas de dados que vamos abordar hoje é a importância de garantir que todo código criado em um projeto de dados seja acessível e reprodutível por todos os membros da equipe de cientistas de dados.

Isso significa que cada cientista precisa instalar todas as bibliotecas e dependências de software em sua própria máquina para ser capaz de reproduzir os algoritmos e análises uns dos outros. Se não houver uma estratégia organizada, há o risco de que uma pessoa instale uma versão diferente de alguma biblioteca (ex: numpy e pandas incompatíveis) que quebre todo o código!

Você já deve ter ouvido ou dito a frase "Não sei porque não funciona na sua máquina, na minha funcionou normal!". Pois é, o Docker existe para evitar que isso aconteça.

Primeiro: o que é Docker?

O Docker é a ferramenta mais conhecida e usada atualmente de software de contêineres. Ele permite por meio da virtualização a nível de sistema operacional transformar um conjunto de pacotes diferentes em uma coisa só.  Esses contêneres são isolados e podem se comunicar entre si por canais bem definidos.

Quando começamos um projeto de ciência de dados na DSB, quase sempre precisamos dos seguintes elementos:

1. a possibilidade de executar scripts Python ou bash
2. um banco de dados simples só para armazenar alguns resultados
3. um servidor Spark standalone

Imagine ter que garantir que em cada computador, cada ambiente, todos os pacotes python, jars e afins precisem ser os mesmos... E se parte da equipe usa Ubuntu, outra parte MacOS e uma terceira Windows? Como garantir que a aplicação vai rodar da mesma forma em todos esses ambientes? Se o cliente que vai usar esse código depois possuir um servidor em Windows e a equipe usar Linux, como garantir a integridade da solução?

O Docker resolve esses problemas ao garantir que todos trabalhem exatamente com o mesmo ambiente, mesmas bibliotecas, mesmos serviços e isso sem que se precise instalar manualmente todos os pacotes e linguagens de programação.

Com o Docker, se alguém da equipe desenvolver uma solução nova, basta adicionar as linhas de código necessárias aos contêineres do projeto que essa solução pode ser replicada no ambiente de toda equipe.

Os principais conceitos envolvidos

Para entender como o Docker permite essas facilidades citadas acima, precisamos nos ambientar com alguns termos e conceitos importantes da ferramenta:

Contêiner:

Pense no contêiner como uma máquina virtual que roda no seu computador. O contêiner é uma unidade de software que une todo o código e suas dependências para que a aplicação funcione consistentemente e de forma rápida independente do ambiente de execução. Quando tiver rodando aplicações no Docker, você pode conferir quais contêineres estão ativos com o comando docker stats.

Os contêineres são definidos a partir de uma Imagem.

Imagem:

Uma imagem Docker é um arquivo que define como um contêiner será criado. É como se fosse um template para se criar uma máquina virtual.

Ela é construída a partir de uma série de instruções definidas por meio do arquivo de texto Dockerfile. Nele, deverá constar todas as dependências, instalações de softwares e pacotes de linguagens de programação, enfim tudo o que é necessário para uma aplicação que será executada usando o kernel da máquina de host. Quando uma imagem é instanciada, ela cria um Contêiner.

Como exemplo, o Dockefile abaixo é o que utilizamos para executar Jupyter notebooks nos nossos projetos:

 # Jupyter pyspark image from https://hub.docker.com/r/datasciencebrigade/jupyter-pyspark-image
FROM datasciencebrigade/jupyter-pyspark-image:1.2

USER jovyan

WORKDIR /mnt/code

COPY requirements.txt requirements.txt
RUN pip install --upgrade pip
RUN pip install -r requirements.txt

EXPOSE 8888

O arquivo começa com o comando FROM, indicando que esta imagem herda de uma outra imagem pai - que está disponível no Docker Hub - baseada no Ubuntu e que já tem todas as dependências de Python instaladas. O arquivo completo você pode conferir no nosso Github.

Por padrão, gostamos de usar o /mnt/code como o diretório padrão (WORKDIR) dentro do Docker. Assim, sempre que acessarmos o shell do contêiner, iremos entrar por padrão nesse diretório.

Para copiar arquivos da máquina local para dentro do contêiner, é necessário usar o comando COPY. No exemplo acima, copiamos o arquivo requirements.txt que define as bibliotecas Python que precisamos para as nossas análises.

Um arquivo requirements.txt tipicamente define bibliotecas de análise de dados, visualizações, NLP, etc. Exemplo:

pandas==1.0.0
numpy
plotnine
matplotlib
fasttext==0.9.2
gensim>=3.0.0,<4.0.0

Os trechos do Dockerfile com o comando RUN definem instruções a serem executadas no shell do contêiner. No exemplo acima, há comandos que instalam dependências de bibliotecas Python usando pip install.

Portas para acessar serviços dentro do contêiner são definidos no Dockerfile pelo comando EXPOSE.

Build & Run:

Para usar esse Dockerfile, você precisará primeiro construir essa imagem - e eventualmente lidar com erros caso tenha esquecido de definir a instalação de alguma dependência de código necessária. Para isso, use o comando docker build, atribuindo um nome para essa imagem. Exemplo:

docker build --tag ds-exploratory:latest .

Pronto. Agora a imagem ds-exploratory pode ser utilizada para rodar um contêiner. Faça isso com o comando docker run:

docker run --name ds-exploratory-container ds-exploratory

Ao final, você deverá ver algo do tipo:

Cole essa URL que aparece no terminal (junto com o token) no navegador e pronto, você já poderá usar o Jupyter notebook que está rodando dentro desse contêiner Docker.

A imagem ds-exploratory que criamos com o comando build dá origem ao contêiner que chamamos de ds-exploratory-container.

Se quiser acessar o shell desse contêiner, use o comando docker exec. Deixe o contêiner rodando, abra um outro terminal e digite:

docker exec -ti ds-exploratory-container /bin/bash

O parâmetro -ti te permite acessar o shell e digitar comandos de forma dinâmica.

Para sair da shell, digite exit.

Para parar o contêiner original, dê um Ctrl+C na tela do terminal onde está rodando.

Volume:

O contêiner que criamos acima roda em um ambiente isolado, todo arquivo que for criado lá dentro só fica visível dentro do próprio contêiner. Ao parar ou matar o contêiner, nenhum arquivo ficará visível "do lado de fora". É claro que isso não é prático sempre já que precisamos que os notebooks e outros códigos e arquivos continuem existindo mesmo depois que a gente fechar o contêiner.

Para manter os dados e arquivos, mapeie um diretório dentro do contêiner para apontar para algum outro diretório da sua máquina. Assim, tudo que for feito nessa pasta, permanecerá após o fim da vida do contêiner.

No Docker, faça isso com o parâmetro -v. Por exemplo, para mapear uma pasta local com dados do projeto (/home/user/project/data) para dentro do contêiner no diretório /mnt/data, faça o seguinte:

docker run --name ds-exploratory-container -v /home/user/project/data:/mnt/data ds-exploratory

Redes:

É possível também criar uma rede de contêineres para que os mesmo se conectem entre si. Por padrão a rede em que os contêineres sobem é a bridge

Docker-compose: gerenciamento fácil de imagens e contêineres

Como já deu para perceber, para subir contêineres na mão usando docker "puro", além de instanciar as imagens Docker que servirão de templates, precisamos também muitas vezes expor portas de serviços necessárias (ex: 5000 para um servidor HTTP, 8888 para o Jupyter, 4040 ou 7077 para Spark, etc.), montar volumes de dados e passar variáveis de ambiente para os contêineres.

À medida que o projeto vai se tornando mais complexo, se torna necessário também mapear compartilhar variáveis de ambiente entre vários contêineres, mapear dependência entre serviços diferentes e por consequência, os comandos vão se tornando mais complicados.

docker run -v /home/dsb/dados:/foo -w /foo -i -t --expose 80 -e MYVAR1 --env MYVAR2=foo --env-file ./env.list -itd --network=my-net ubuntu bash

Uma ferramenta muito útil para gerenciar melhor a execução dos contêineres e lidar com essa complexidade natural dos projetos é o Docker Compose. Essa ferramenta te livra de usar o comando acima e facilita a definição e executação de múltiplos contêineres Docker usando para isso apenas um arquivo: o docker-compose.yml.

Segue abaixo o exemplo de configuração de um arquivo docker-compose.yml que usamos em projetos de data science que envolvem tanto análises exploratórias (Jupyter notebooks) bem como módulos e pacotes Python compartilhados:

version: "3.5"

services:
  research:
    build:
      context: research
      args:
        JUPYTER_EXTERNAL_PORT: ${JUPYTER_EXTERNAL_PORT}
    volumes:
      - ./research:/mnt/code
      - ${DATA_VOLUME}:/mnt/data
    environment:
      TIMEZONE: America/Sao_Paulo
      SPARK_PUBLIC_DNS: ${SPARK_PUBLIC_DNS}
      SPARK_MASTER_PORT: ${SPARK_MASTER_PORT}
      SPARK_WORKER_WEBUI_PORT: ${SPARK_WORKER_PORT}
    ports:
      - ${SPARK_WORKER_PORT}:8081
      - ${SPARK_APPLICATION_PORT}:4040
      - ${JUPYTER_EXTERNAL_PORT}:8888
      - ${SPARK_MASTER_WEBUI_PORT}:8080
      - ${SPARK_MASTER_PORT}:7077
    image: research
    container_name: research-${CONTAINER_TAG}

  processing:
    build: processing
    env_file:
      - .env
    environment:
      TIMEZONE: America/Sao_Paulo
      SPARK_CONF_DIR: /conf
      SPARK_PUBLIC_DNS: ${SPARK_PUBLIC_DNS}
      SPARK_MASTER_PORT: ${SPARK_MASTER_PORT}
      SPARK_WORKER_WEBUI_PORT: ${SPARK_WORKER_PORT}
      SPARK_PUBLIC_DNS: ${SPARK_PUBLIC_DNS}
    volumes:
      - ./processing:/mnt/code
      - ${DATA_VOLUME}:/mnt/data
      - ./processing/conf/worker:/conf
    image: processing
    container_name: processing-${CONTAINER_TAG}

Neste arquivo dois contêineres são declarados: research e processing. Neles são definidos volumes, portas que serão mapeadas,  variáveis de ambiente (environment), além de um arquivos com algumas variáveis de ambiente, além da imagem que será usada pelo build e o nome que será gerado para o contêiner.

Repare que existem duas formas de declarar variáveis de ambiente, no arquivo .env ou direto, dentro da seção environment. As variáveis definidas no .env ficam disponíveis dentro do contêiner - acessadas usando a sintaxe ${} - e podem ser utilizadas também para redefinir outras variáveis como por exemplo o uso de ${CONTAINER_TAG} acima para personalizar o nome dos contêineres.

Com isso, ao invés de executar os comandos com docker build e docker run cheios de parâmetros, é possível compilar e subir os dois contêineres definidos acima simultaneamente com os comandos:

docker-compose build 

docker-compose up

É possível também rodar somente uma das aplicações:

docker-compose up research

Vale a pena conferir a documentação completa com todas as capacidades da ferramenta no site do Docker Compose.

Templates para projetos de dados

No nosso Github, você pode encontrar templates de estrutura Docker que usamos como ponto de partida nos nossos projetos de ciência de dados, tanto de imagens Dockers que adaptamos para nosso uso quanto estrutura de diretórios para uso nos projetos:

• dsb-images: https://github.com/Data-Science-Brigade/dsb-images
• dsb-templates: https://github.com/Data-Science-Brigade/dsb-templates

Vantagens do Docker

Resumindo, existem várias vantagens de se usar Docker em um projeto de ciência de dados:

• Portabilidade: É fácil reproduzir e portar a solução desenvolvida por uma pessoa para outros dentro da equipe.
• Deploy simplificado: Ao portar uma solução para o ambiente de produção, não será preciso instalar bibliotecas, pacotes de software, etc. Geralmente, basta configurar as variáveis do ambiente
• Consistência: Garantia de que o código do modelo ou script funcione exatamente da mesma forma independente de sistema operacional que está sendo utilizado.
• Independência de componentes: É fácil substituir partes de uma solução por outras ferramentas. Por exemplo,

Quando uma empresa entra em contato conosco para iniciar um projeto de ciência de dados, geralmente a primeira coisa que fazemos é um diagnóstico das necessidades estratégicas da empresa, seguida ou combinada por uma análise exploratória.

Essa etapa do projeto tem como propósito organizar e limpar as bases de dados disponíveis e identificar padrões de comportamento que só se tornam aparentes quando olhamos diretamente para os dados. Essas descobertas irão validar - ou contradizer - suposições que a empresa tem sobre o comportamento de seus clientes e dos seus próprios processos internos, além de produzir insights para embasar melhor suas decisões estratégicas.

A análise exploratória é o momento ideal para experimentar visualizações, testar hipóteses e, de uma forma geral, exercitar a curiosidade.

Esse tipo estudo exige sim uma boa dose de matemática, estatística, computação, conhecimentos de negócios mas é acima de tudo um processo criativo e colaborativo. E há aqui o risco de que a equipe envolvida no projeto acabe descambando para uma busca aleatória e não consiga fazer descobertas de qualidade.

Quando as possibilidades de exploração são infinitas, saber a direção do caminho a seguir se torna uma ferramenta mais poderosa do que qualquer algoritmo avançado.

O que determina o sucesso de um estudo?

Os projetos de exploração em ciência de dados muitas vezes são confundidos com entregas de software ou a confirmação de uma crença, ou seja, a expectativa é de que o resultado obtido seja palpável (como a inclusão de botão em uma tela) ou valide uma hipótese.

O que acontece muitas vezes é que esse processo pode não validar a hipótese formulada e, definitivamente, a saída não será um botão funcional. Então como sabemos que a fase de estudos obteve sucesso?

Assim como outros tipos de projetos, precisamos de objetivos bem estabelecidos já desde a fase inicial. Para que isso ocorra, temos alguns pontos importantes a determinar:

• Que perguntas de negócio queremos responder/analisar?
• De que forma respondemos estas perguntas atualmente?
• Quantas pessoas/áreas de negócio estas perguntas atendem dentro da empresa?
• Estas pessoas/áreas de negócio respondem as perguntas da mesma forma (mesmos cálculos)?
• Os conceitos e termos utilizados internamente estão alinhados em todas as áreas de negócio? Por exemplo, a palavra performance pode conter diversos significados e variáveis dependendo da área/setor da empresa.
• Que dados estão disponíveis para responder as perguntas feitas?
• Esses dados podem ser acessados por todos os setores da empresa envolvido no projeto? Há alguma limitação de privacidade e segurança?
• Confiamos nestes dados? Se não confiamos, o que podemos fazer para mudar o cenário?

O ponto mais relevante da lista acima é o primeiro, perguntas de negócio. É através delas que orientamos as definições das próximas perguntas listadas.

Além de termos os objetivos bem definidos, precisamos também de métricas relacionadas ao desenvolvimento do projeto. Algumas delas fazem parte das métricas tradicionais de gestão, e envolvem: prazo, tempo, equipe, riscos e orçamento. Mas outras métricas podem ser relevantes para a análise exploratória:

• Que métricas (índices ou indicadores) já possuímos internamente? Como são calculadas? São métricas tradicionais do mercado?
• Queremos incluir novas métricas? O que pretendemos medir?

E como saber se estou fazendo as perguntas certas?

Uma das partes mais desafiadoras do trabalho dos cientistas de dados, bem como de vários pesquisadores, é a formulação de perguntas, mas por quê? Nas áreas de negócio é comum encontrarmos perguntas muito amplas, ou seja, elas não tem um recorte que possa ser respondido de forma eficiente em uma análise de dados. Compare, por exemplo, as perguntas amplas e específicas abaixo:

Perguntas amplas

1. Qual o perfil dos clientes?
2. Qual o comportamento dos clientes?
3. Qual a performance dos colaboradores?

Perguntas específicas

1. Que fatores motivam o abandono dos clientes no processo de assinatura?
2. Quais características socioeconômicas são predominantes nos clientes que assinam o produto?
3. As entregas geradas pelo trabalho dos colaboradores estão relacionadas aos objetivos da empresa?

Se observarmos bem as perguntas específicas, conseguimos identificar quais variáveis serão relevantes para a execução da análise, ou o tipo de informações que serão necessárias. Elas fazem um papel importante, orientando os cientistas durante a captura dos dados e exploração.

Já as perguntas mais amplas, ao invés de servirem de orientação, muitas vezes acabam deixando mais dúvidas e podem resultar em análises que não abrangem as variáveis esperadas pelos gestores de negócio. Esse processo também acaba abrindo margem para interpretações setoriais ou não vinculadas ao objetivo inicial podendo gerar bastante retrabalho.

E se travar no meio do caminho?

Vamos supor que o projeto contém a seguinte pergunta de negócio:

   P: Quais os fatores que diferenciam os clientes assinantes dos não assinantes?

Após o estudo, é possível que cheguemos na resposta abaixo:

   R: nenhuma diferença significativa no padrão de comportamento destes clientes foi encontrada.

E agora? O que tentar em seguida?

Podemos utilizar um novo conjunto de dados ou aplicar algum novo método de coleta em uma nova iteração da análise de dados para confirmar esse resultado negativo. Se há fortes indícios - fora dos dados - de que deveria haver uma diferença no padrão de comportamento, o ideal é que essa solução entre para o desenvolvimento de longo prazo, e que o time revisite as explorações feitas no estudo inicial com os novos dados.

Fazer isso, porém, apresenta riscos ao projeto quando olhamos para as métricas de prazo, tempo, custos e equipe. Um caminho para esta situação seria avaliar outras perguntas que precisam ser respondidas e fazer uma re-priorização do estudo, dando foco à outras questões tão relevantes quanto a primeira. A velocidade com que essa re-priorização é feita afeta diretamente os resultados finais do projeto.

Se esgotar as ideias de testes e novas análises para fazer, há também uma outra possibilidade que, apesar de amarga, precisamos aceitar. Muitas vezes um resultado negativo é só isso mesmo: um resultado negativo. Talvez realmente não haja diferença significativa entre os grupos, talvez não existam clusters nos dados e tudo bem. O importante é ver se isso pode impulsionar novas perguntas de negócios.

Resumindo: quando algum resultado não sai como o esperado, avalie se vale a pena repetir o estudo com novos dados mas, acima de tudo, re-priorize.

Olhando pro futuro

O conhecimento adquirido em um estudo inicial é o que servirá de insumo para traçar os novos caminhos do projeto. E isso geralmente se manifesta em forma de novas perguntas:

• Se o estudo expôs fragilidade no modelo de negócios ou na própria organização dos dados, que ações devo tomar para minimizar esses riscos?
• Surgiram novas perguntas a serem exploradas com os dados existentes? Ou seria melhor coletar mais dados para fazer outras validações?
• A empresa se beneficiaria se esses insights se tornasse um relatório recorrente? Quem sabe até um dashboard?
• Com os dados já bem organizados, seria agora o momento de explorar algoritmos de Machine Learning? Com qual propósito?

A análise de dados é um processo contínuo, dinâmico e iterativo. Os objetivos da empresa, os tipos de dados disponíveis bem como as necessidades do mercado no país ou no mundo podem mudar com o tempo. É importante ficar atento a estes fatores e ir se adequando às mudanças.

Lembre-se, são as perguntas que orientam o desenvolvimento e as descobertas na exploração dos dados. Elas servem de norte para a definição do produto a ser desenvolvido. Muito mais do que perguntas certas, precisamos definir perguntas que possam ser respondidas com dados.

Se ao final do seu projeto de dados você e sua equipe estiverem cheios de novas perguntas, não se preocupe, esse pode ser um sinal de que estão no caminho certo.

Senta que lá vem a história…

Neo4j é um banco NoSQL (banco de dados não relacional), ele é Open Source, está há mais de 10 anos no mercado. E finalmente, é um Graph Databases (Banco de Dados de Grafos), um dos mais populares desse tipo senão o mais popular...

Segundo o próprio site do Neo4j, o banco de dados oferece suporte oficial para as seguintes linguagens de programação: .Net, Java, JavaScript, Go and Python. E sua comunidade suporta as seguintes: PHP, Ruby, R, Erlang, Clojure e C/C++.

Tanto o Neo4j como outros graph databases como Infinite Graph, InforGrid, HyperGraphDB, etc, abrangem uma ampla gama de possibilidades de armazenamento de informações e são considerados fundamentais para ecossistemas de BigData. Ao pensar em uma quantidade vasta de relacionamentos, o modelo relacional ficaria com o desempenho comprometido, pois precisaria de queries muito complexas com vários joins, o banco de grafos resolve isso de uma forma mais simples e direta.

O modelo orientado a grafos possui três componentes básicos:

• Os nodes - também chamados de nós, nodos ou vértices do grafo - são responsáveis por guardar os dados de uma entidade. É super indicado dar nomes (labels) para os nodos, pois com os Labels fica mais fácil fazer consultas, visualizar os dados além de tornar a modelagem de dados mais "bonita";
• Os relacionamentos - ou links ou edges ou ainda arestas - representam os relacionamentos (!) entres os nodes. Esses links possuem uma direção e isso é uma das características mais importantes dos relacionamentos, por exemplo um link Node 01 aponta para o Node 02, mas não necessariamente o inverso (Node02 -> Node 01);
• As propriedades, ou atributos, dos nós e relacionamentos.

Nada de tabelas, campos e índices, que maravilha não?!

Ah! Mas então eu vou deixar de usar um banco relacional e só utilizar grafos? Não! Como tudo na vida, saber qual tipo de banco usar na sua aplicação, precisa de análise, critérios e equilíbrio. Senão o que seria uma vantagem pode virar um enorme problema.

E antes de partir para um exemplo bem legal (para quem curte Game of Thrones principalmente), vamos falar um pouco sobre o Cypher.

Neo4j e Cypher

Cypher é a linguagem oficial de consultas do Neo4j, com ela podemos criar, modificar e procurar os dados em uma estrutura baseada em um conjunto de grafos e seus relacionamentos. Entenda Cypher como um substituto do SQL.

Aspectos Chaves do Cypher:

1 — É uma linguagem Declarativa, diga o que você quer e não como;

2 — Totalmente Expressiva, se você consegue descrever o que quer de forma simples, ou seja numa linguagem natural, dá pra fazer no Cypher;

3 — Conceitos simples e bem similares aos de linguagens de consultas já conhecidas usadas com bancos SQL. Se você está acostumado com SQL, vai enxergar vários paralelos mas já deixo avisado que apanhei um pouco para acostumar com a linguagem!

4 — E é óbvio, Orientada a Grafos, ou seja, foi feita para banco de dados grafos.

Cypher Query Language — Bora entender um pouco como funciona?

Abaixo você encontrará os principais comandos do Cypher. E é claro que para maiores informações, ver comandos mais avançados e a diversas funções que ele suporte, é sempre bom verificar a documentação oficial.

• MATCH: É o SELECT do mundo SQL. É com ele que fazemos consultas no Neo4j. O padrão principal de um MATCH é ()-[]-(). Ou seja, MATCH (um node)-[relacionado]->(com outro node), ou ainda, MATCH (um node {com filtro de atributo})-[relacionado]->(com outro node).
• RETURN: Podemos dizer que ele é responsável por trazer as informações que queremos. É tipo quando fazemos o SELECT * FROM xxxxx ou SELECT tabela.campo, tabela.campo1 FROM xxxxx. É o RETURN que indica o que queremos trazer do MATCH, se é o node ou o relacionamento ou ambos, por exemplo.
• CREATE: É com este comando que você cria nodes e relacionamentos.
• MERGE: É a união do CREATE com MATCH em um só comando. Você consegue criar nodes e relacionamentos, principalmente com um grande número de dados. E caso o item já existir não será criado novamente e sim feita uma fusão das informações.
• SET: Utilizado para alterar as propriedades (atributos) de um node ou relacionamento.
• REMOVE: Com este comando é possível remover as propriedades (atributos) de um node ou relacionamento.
• DELETE: Responsável por apagar os nodes e as relações.
• WITH: O resultado de um MATCH pode gerar uma nova informação, uma nova query, que vai ser usada um novo MATCH ou em um RETURN. É utilizado em queries mais complexas para ajudar a expor um resultado de forma simples e mais rápido.
• OPTIONAL MATCH: É o mesmo conceito do MATCH porém o retorno não é obrigatório, pode ter valores nulos. Pode ser comparado ao outer join do SQL.
• COLLECT: É uma função de agregação que retorna uma lista contendo os valores retornados por uma outra expressão.

Que tal um exemplo com GoT? Sim, Game of Thrones…

E porque não?! Game of Thrones é um exemplo perfeito para aprender Neo4j já que cada personagem pode se relacionar com outros de diversas formas e podem ter atributos diferentes.

SPOILER ALERT: A partir deste ponto, contém spoilers de toda a série

Vamos usar duas casas: Stark e Targaryen, e os personagens: Jon Snow, Ned Stark e Daenerys Targaryen. E os relacionamentos? Vixe! Vários e por esse motivo fazer essa estrutura não ficaria nada performática em um banco relacional.

Primeiro vamos criar as duas casas e os personagens e relacioná-los:

// Cria os personagens com o comando MERGE
MERGE (p1 : Personagem {nome: 'Jon Snow', titulo: 'Rei do Norte', animal_estimacao: 'Lobo - Ghost'})
MERGE (p2 : Personagem {nome: 'Ned Stark', titulo: 'Lorde de Winterfell', frase: 'The Winter is Coming'}) 
MERGE (p3 : Personagem {nome: 'Daenerys Targaryen', titulo: 'Khaleesi, A Não-Queimada, Mãe de Dragões...' })

// Cria as duas casas dos personagens, com seus atributos 
MERGE (c1 : Casa {nome: 'Stark', simbolo: 'Lobo' })
MERGE (c2 : Casa {nome: 'Targaryen', simbolo: 'Dragao Vermelho de 3 cabeças' }) 

// Cria os relacionamentos entre personagens e suas casas
MERGE (p1)-[r1: PERTENCE_A_CASA]->(c1)
MERGE (p2)-[r2: PERTENCE_A_CASA]->(c1)
MERGE (p3)-[r3: PERTENCE_A_CASA]->(c2)

// Elementos retornados pela consulta
RETURN p1, p2, p3, c1, c2

E o resultado:

Agora podemos continuar criando mais relacionamentos com propriedades. Por exemplo, podemos incluir um atributo de "Temporada" ao relacionamento, já que  Jon Snow no inicio da série era Filho Bastardo de Ned Stark, e quase no final descobrimos que na verdade ele era Sobrinho (eu avisei que tinha spoiler).

// Encontrar os registros já criados e dar um nome (como se fosse atribuir um valor a uma variável para usar depois) e fazer o MERGE para criar os relacionamentos
MATCH (p1 : Personagem {nome: 'Jon Snow'}), (p2 : Personagem {nome: 'Ned Stark'}), (p3 : Personagem {nome: 'Daenerys Targaryen'}), (c1 : Casa {nome: 'Targaryen'})
MERGE (p1)-[:FILHO_BASTARDO {Temporadas:'1 - 6'}]->(p2)
MERGE (p1)-[:SOBRINHO {Temporadas:'6 - 8'}]->(p2)
MERGE (p1)-[:SOBRINHO {Temporadas:'6 - 8'}]->(p3)
MERGE (p1)-[:SE_APAIXONOU]->(p3)
MERGE (p1)-[:DOBROU_O_JOELHO]->(p3)
MERGE (p3)-[:TIA {Temporadas:'6 - 8'}]->(p1)
MERGE (p2)-[:PAI {Temporadas:'1 - 6'}]->(p1)
MERGE (p2)-[:TIO {Temporadas:'6 - 8'}]->(p1)
MERGE (p1)-[:PERTENCE_A_CASA]->(c1)

O que resultaria nessa estrutura:

Para não alongar muito aqui no post, colocamos alguns exemplos de queries Cypher no GitHub. Lá você vai encontrar todos os scripts para simular esse exemplo de GoT com Neo4j, e muitos outros. Fique a vontade para conferir o repositório: blogpost_neo4j_got.

E olha só como ficou o schema final desse primeiro teste:

Que tal modelar as relações, batalhas, mortes e traições de Game of Thrones? Bom, isso fica para um próximo post. Em breve deve pintar por aí outro artigo e repositório cheio de informações sobre GoT, com várias dicas sobre Neo4j e Cypher, além de alguns insights baseados em análises dos dados.

E quem sabe no futuro brincar um pouco com a série alemã Dark do Netflix.

Banco de Grafos e AWS

Como eu sou apaixonada por Cloud, o que seria de mim sem um blog post que não falasse sobre algum serviço da AWS.

Segundo a AWS: "O Amazon Neptune é um serviço de banco de dados gráfico rápido, confiável e totalmente gerenciado que facilita a criação e a execução de aplicativos que trabalham com conjuntos de dados altamente conectados. O núcleo do Amazon Neptune é um mecanismo de banco de dados gráfico com projeto específico e alta performance, otimizado para armazenar bilhões de relacionamentos e consultar os gráficos com latência de milissegundos. O Amazon Neptune oferece suporte aos modelos de gráficos comuns Property Graph e RDF do W3C, bem como a suas respectivas linguagens de consulta TinkerPop Gremlin e SPARQL.".

Principais características:

• Totalmente gerenciado;
• Alta Disponibilidade e Resiliência;
• Réplicas de leitura. É Multi-AZ;
• Backups são feitos continuamente no S3 (são automáticos, incrementais e contínuos, e não afetam a performance do banco de dados);
• Seguro. Principalmente, se utilizar dos artifícios que a AWS oferece como VPC, KMS (Criptografia), e recursos do IAM — sempre bem configurados e abusando das melhores práticas.

Em breve devo fazer uma POC com o Amazon Neptune e compartilho minha opinião a respeito e monto um Hands-On bem legal. E é claro, fazendo uma breve comparação com o Neo4j. Que tal?!

Aqui na DSB nós trabalhamos de forma remota desde que nascemos como empresa e apesar de termos um escritório lindo, a maior parte do time está espalhado pelo Brasil <3 . Por isso, é no remoto que a maior parte do trabalho acontece. E a parte mais linda é que nossos clientes passam por essa transformação digital com a gente.

Durante o mês de Julho fizemos um DSBinar - forma como chamamos a troca de conhecimento entre o time -  para falar sobre as diferenças entre os perfis das pessoas, as formas de se comunicar e como tudo isso impacta na compreensão das informações entre outros fatores.

Para abordarmos esses assuntos, trabalhamos com as diferenças entre as personalidade das pessoas, bem como as diversas formas de se comunicar e entender uma mensagem. É importante lembrar que todos nós trabalhamos home-office, por isso, também foi explorado as especificidades da comunicação no trabalho remoto.

Pessoas e suas diferenças

Cada ser humano considerado como individualidade física e espiritual, e dotado de atributos como racionalidade, autoconsciência, linguagem, moralidade e capacidade para agir.

Nossas características pessoais influenciam na forma como nos comunicamos e interagimos com o mundo e as pessoas. Por isso, trouxemos algumas ferramentas conhecidas no mercado para que identifiquemos algumas das nossas características mais marcantes.

Para compreender essas características pessoais, existem uma série de ferramentas que nos auxiliam pela busca do autoconhecimento e de traços que se destacam em nossa personalidade. Abaixo, seguem alguns dessas ferramentas, todas com origem no mundo científico, ou seja, passaram por revisões, testes e análises, porém a busca pelo autoconhecimento pode seguir vários caminhos. A ideia deste post não é explicar cada uma delas, mas sim, expô-las como uma das infinitas ferramenta possíveis.

Análise DISC

Avaliação DISC é uma teoria postulada pelo psicólogo Dr. William Moulton Marston em seu livro "Emotions of Normal People" (1928), que determina alguns padrões de comportamento. A partir desta teoria, foram elaboradas ferramentas para análise de perfil comportamental, sendo o primeiro instrumento de mensuração desenvolvido por Walter Clarke (1945).

16 tipos de personalidade

A teoria dos 16 tipos de personalidades parte dos estudos sobre 8 Tipos Psicológicos de Carl G. Jung, e posteriormente desenvolvida por Katharine Cook Briggs junto com sua filha Isabel Briggs Myers para 16 tipos psicológicos. Ela foi moldada a partir da publicação Os Tipos Psicológicos em 1921.

Para além das características pessoais, outros fatores são importantes na hora de comunicar. Estes, diretamente relacionados à forma como aprendemos ou retemos uma informação. Mas o que é Comunicação? Uma das definições que achei foi esta: "comunicação é a ação de transmitir uma mensagem e, eventualmente, receber outra mensagem como resposta."

E quais são as formas pelas quais estamos habilitados a consumir informação? Pela teoria VAC desenvolvida por Fernald e Keller e Orton- Gilingham, temos que a aprendizagem ocorre por meio dos sentidos: visual, auditivo ou tátil, ou seja, a maioria das pessoas possui um estilo que domina para aprender e reter conteúdos.

Estilo visual: Neste grupo estão as pessoas que possuem habilidades de conhecer, interpretar e diferenciar os estímulos recebidos visualmente. A partir da visualização das imagens, é possível estabelecer relações entre ideias e abstrair conceitos.

Estilo auditivo: Pessoas com estilo auditivo possuem habilidades de conhecer, interpretar e diferenciar os estímulos recebidos pela palavra falada, sons e ruídos, organizando suas ideias, conceitos e abstrações a partir da linguagem falada.

Estilo cinestésico: Encontramos neste grupo pessoas que possuem habilidades de conhecer, interpretar e diferenciar os estímulos recebidos pelo movimento corporal.

Legal, então temos formas diferentes de armazenar as informações e isso depende de qual é o nosso estilo "preferencial". Porém, a comunicação é muito mais complexa, e foi exatamente isso que mostrou o neurocientista Uri Hasson em uma palestra no TED, onde ele fala como é o funcionamento das ondas do nosso cérebro enquanto nos comunicamos.

Neste TED Hasson falou sobre como nossas ondas cerebrais se sintonizam na mesma frequência enquanto ouvimos alguém e como os termos específicos de uma região podem interferir na compreensão da mensagem passada. Ele também fala sobre como é importante as pessoas que se comunicam terem crenças compartilhadas, ou seja, dividirem o mesmo entendimento sobre determinado assunto.

Juntando essa explanação com os dados de um artigo escrito pela a equipe Officeless - Officeless é a empresa que fala sobre a cultura do trabalho remoto - "O lado humano da comunicação em times remotos", é possível perceber o quanto o sistema de crenças compartilhadas é relevante para que o time realmente tenha um sentimento não só de pertencimento, mas para que o trabalho também possa acontecer de forma equilibrada, levando em conta as características de trabalhar cada um.

Para além destes fatores, outro ponto que se destaca na comunicação, principalmente no trabalho remoto, é a confiança. A Teoria dos Jogos aborda sobre a confiabilidade e como nosso comportamento influencia no resultado final do "jogo", ou seja, das relações.

Este site confianca.etica.ai aborda sobre a teoria dos jogos e traz isso no formato de um joguinho explicativo, demonstrando os vários resultados possíveis de acordo em como decidimos nos relacionar com os outros. A conclusão é muito interessante e nos trás três ações que precisariam ser desenvolvidas para chegarmos a um ambiente de confiança entre as pessoas, são elas: construir relacionamentos, encontrar a lógica do ganha-ganha, comunicar-se com clareza.

E como consequência, não só da boa comunicação, mas também da confiança e cultura estabelecidas, temos como resultado final que, na minha visão, é o mais importante para times, remotos ou não, a AUTONOMIA.

Esse tema também é abordado pelo time da Officeless neste vídeo, onde eles trazem as diferenças entre o trabalho remoto e presencial e como estes líderes precisaram se adaptar a este novo modelo. Aqui é legal salientar que o trabalho remoto exige das pessoas: autonomia, responsabilidade, gestão do tempo entre outras características. Por isso, a autonomia e a comunicação são fatores super relevantes para quem está à distância.

Vamos retomar? A comunicação depende primeiro de quais são os nossos pontos fortes e fracos identificados na nossa atuação como profissionais, além disso, a forma como processamos e entendemos uma mensagem influencia em como armazenamos e aprendemos.

Vimos  também que ter crenças compartilhadas são parte importante na interpretação das informações que recebemos e que a confiança não é só uma consequência da boa comunicação, da construção de relacionamentos e trocas de ganhos, como faz parte relevante dos projetos a distância.

Por fim, entendemos a lógica da construção da autonomia e como a confiança esta relacionada a este processo.

O AWS S3 ou Amazon Simple Storage Service, é um dos serviços mais conhecidos e antigos da AWS e é claro que vocês já devem estar cansados de saber disso. Este artigo tem a intenção de dar uma introdução um pouco diferente sobre o S3, além de falar um pouco sobre as classes de armazenamento que existem, suas diferenças e onde podem ser aplicados. Afinal, é possível encontrar vários tutoriais ensinando como criar buckets e setar permissões, e muitos deles inclusive tratam de alguma frente especifica.

E que tal começarmos com "O que o S3 não é?"

Ou melhor para que ele não serve? Ele não é indicado para nada que dependa de armazenamento em bloco, por exemplo, não é possível instalar e rodar um sistema operacional e/ou banco de dados nele. Quem faz esse papel é o Amazon Elastic Block Store (EBS). Ou ainda, ele não é indicado para aplicações que depende de muito IOPS* e/ou Throughput**, o correto seria utilizar o Amazon Elastic Block Store (EBS) e/ou Amazon Elastic File System (EFS).

*IOPS (Input Output Operations Per Second ou Operações de Entrada e Saída por Segundo) - é o tempo em segundos que se leva para completar um operação de entrada e saída de dados - read/write.

**Throughput - pode ser traduzido como a taxa de transferência efetiva de um sistema - é a quantidade em Kbps, Mbps ou Gbps de dados transferidos de um lugar a outro, ou a quantidade de dados processados em um determinado espaço de tempo.

Agora que já sabemos o que ele não é, que tal entendermos o que significa ser um Object-Storage ou serviço de armazenamento de objetos?

É basicamente um local onde podemos armazenar objetos, ou seja, arquivos - imagens, arquivo de texto, vídeos, documentos, entre outros.

O tamanho de cada arquivo pode variar entre 0 bytes até 5TB. É possível ter um número ilimitados de objetos (arquivos) dentro de um único bucket S3 e o AWS S3 pode armazenar praticamente uma quantidade ilimitada de dados. Não há taxa mínima, você paga pelo que usar.

E o que são buckets S3?

Nada mais que pastas onde armazenamos nossos arquivos. O nome do bucket S3 é universal - devem ser únicos globalmente - na verdade eles devem ser exclusivos de uma partição***.

***"Uma partição é um agrupamento de regiões. A AWS atualmente tem três partições: aws (regiões Standard), aws-cn (regiões da China) e aws-us-gov (regiões GovCloud [EUA] da AWS)."

Sempre devemos escolher uma região no momento da criação dos buckets que irá armazenar os dados, pois o console do AWS S3 é global, permite a visualização de N buckets que temos em N regiões, mas os buckets são criados em regiões específicas.

Os nomes dos buckets podem conter de 3 até 63 caracteres - sempre letras minúsculas e podem ter números, hífens(-), pontos(.). Por padrão, podemos criar até 100 buckets por conta, são os famosos Soft Limits da AWS ou AWS service quotas, mas se necessário, esse limite pode ser aumentado até 1.000.  

Consistência de dados do Amazon S3

• Dados consistentes para leitura após a escrita (PUTS) - Assim que incluir um arquivo no bucket ele estará imediatamente disponível.
• Dados eventualmente consistentes após alteração ou deleção de arquivos ou delete (PUTS ou DELETES) - Pode-se levar um tempo para replicação do dado, e enquanto isso você poderá consumir dados antigos.

Quais são as Storage Classes ou Classes de Armazenamento?

Apesar de não ser o foco, mas antes de falar sobre as classes, acho interessante saber o que compõe o custo do S3, onde você pode pagar: pelo Armazenamento (por GB), por Requisições (Requests - PUT,LIST, GET, etc) e Recuperação de dados, por Transferencia de Dados e pelo Gerenciamento e Replicação.

• Amazon S3 Standard (S3 Standard) - É o mais conhecido. Pode ser definido como de Uso Geral, ou seja, é para qualquer tipo de dado que é acessado frequentemente. Durável, acessível de imediato, "mais caro" dentre os 6. Armazena dados no mínimo em três Zonas de Disponibilidade (AZs). É adequado para uma grande variedade de casos de uso (aplicativos na nuvem, sites dinâmicos, distribuição de conteúdo, aplicativos móveis e de jogos e dados analíticos de Big Data, etc).
• Amazon S3 Standard-Infrequent Access (S3 Standard-IA) - Pode ser definido como de Acesso Infrequente. O armazenamento é mais barato porém paga-se pelo resgate do dado. Armazena dados no mínimo em três Zonas de Disponibilidade (AZs). É adequado para arquivos que são armazenados por um período longo de tempo sem acesso, como backups e dados que são usados em caso de um desastre (disaster recovery). O que se deve ter em mente quando se pensa em S3 IA é: Dados que exigem acesso relativamente raro, mas, se necessário, devem ser acessados rapidamente. É mais barato que o S3 Standard.
• Amazon S3 Intelligent-Tiering (S3 Intelligent-Tiering) - É o inteligente da turma. Pode ser definido como de Acesso Desconhecido, Imprevisíveis ou Dinâmico. Armazena dados no mínimo em três Zonas de Disponibilidade (AZs). Ele é um misto do S3 com o S3 - IA, e por uma pequena taxa mensal (automação e monitoramento por objeto) a AWS usa machine learning para identificar quais objetos não foram utilizados num período e move esses dados para uma camada de acesso infrequente e com isso o custo do dado armazenado cai, já os dados que são acessados com frequência ficam na camada Standard, ou seja, o dado fica transitando entre as camadas dependendo do tanto que é acessado e você não precisa fazer nada para tal. O custo acaba sendo menor.
• Amazon S3 One Zone-Infrequent Access (S3 One Zone-IA) - Pode ser definido como de Acesso Infrequente. Possui as mesmas características do Amazon S3 Standard-Infrequent Access (S3 Standard-IA), só que armazena os dados em apenas uma AZ (Zona de Disponibilidade) e por esse motivo é mais barato que o S3 IA. É adequado para dados acessados com pouca frequência, mas que não precisam da disponibilidade e da resiliência S3 Standard ou S3 IA. É uma excelente opção para armazenar cópias de backup secundária de dados locais ou de dados que possam ser recriados com facilidade.
• Amazon S3 Glacier (S3 Glacier) - É mais barato que todos os anteriores. É para Arquivamento de dados. Armazena dados no mínimo em três Zonas de Disponibilidade (AZs). Nos dá três opções de recuperação, que podem levar de alguns minutos a várias horas para disponibilizar os dados (Expedited - 1 a 5 minutos, Standard - 3 a 5 horas, Bulk - 5 a 12 horas). Exemplos de uso: Arquivos de recursos de mídia (boletins de notícias), Arquivos de organizações que trabalham na área da saúde (informações dos pacientes), Dados obtidos durante pesquisas científicas, Cópias de backup de bancos de dados com armazenamento longo, Substituição de mídia analógica, etc.
• Amazon S3 Glacier Deep Archive (S3 Glacier Deep Archive) - É o mais barato de todos. É para Arquivamento de dados. Armazena dados no mínimo em três Zonas de Disponibilidade (AZs). Pode levar até 12 horas para recuperar os dados. Foi projetado para clientes que mantêm conjuntos de dados por mais de 7 ou 10 anos para cumprir requisitos de conformidade normativa, especialmente em setores altamente regulados como serviços financeiros, saúde e setores públicos.

Portanto, o Amazon S3 é muito mais do que um simples serviço de armazenamento de dados, que tem como principais vantagens: escalabilidade, disponibilidade de dados, segurança e performance. Além de tornar possível "armazenar e recuperar qualquer volume de dados, a qualquer momento, de qualquer lugar na web".

Possui uma interface web muito simples e intuitiva no console da AWS. Pode e deve ser usado para diversas frentes (sites, análises de big data, data lakes, backup e restore, entre outros), inclusive nós construímos um pipeline de dados utilizando o S3 e você pode ver um pouco sobre as ferramentas utilizadas neste artigo.

Ah! E não esqueça de proteger muito bem os seus buckets!!!

O serviço AWS S3 pode ser considerado peça chave em diversas arquiteturas e não devemos esquecer de dar aquela atenção especial às políticas de acesso e segurança de cada bucket S3. Só assim seu bucket estará protegido, evitando que informações sejam expostas desnecessariamente.

Espero em breve escrever um outro artigo para falar sobre outros itens interessantes no Amazon S3 como buckets policies, ACL's, across account, cross-region replication, entre outros. Que tal?!

Recentemente publicamos um artigo em nosso blog sobre como construir uma pipeline de dados utilizando uma arquitetura na AWS, e todos os serviços utilizados (exceto Athena) fazem parte do free tier. O AWS free tier nada mais é que o nível gratuito da AWS, onde novos usuários podem utilizar durante um ano diversos serviços da AWS de forma gratuita, sempre se atentando aos limites que determinados serviços oferecem.  

Você pode encontrar maiores detalhes neste link, e você consegue encontrá-lo em português também.

A AWS tem 3 tipos de free tier:

• Gratuito por 12 meses - Contas novas tem acesso aos serviços por 12 meses a partir do cadastro na AWS. Cada item tem um limite de uso, normalmente mensal e um valor em horas ou GB, é bom sempre conferir.
• Sempre Gratuito - Os serviços não expiram e estão disponíveis para todos os clientes da AWS, mas é bom ficar atento ao limite de uso caso tenha.
• Trials - Alguns serviços oferecem um teste gratuito de curto prazo e começam na data que você ativa o serviço.  Sempre confira o limite de uso, seja de tempo ou "valor".

Para conseguir criar a conta é necessário um cartão de crédito, vai ser efetuada uma cobrança de $1, que é estornada logo em seguida (dependendo da operadora do cartão poderá demorar alguns dias) e caso você fique muito tempo sem utilizar a conta, eles validam novamente o cartão efetuando uma nova cobrança, e o estorno em seguida.

Algumas dicas importantes:

• Muitos dos serviços que não precisem ficar 100% do tempo no ar, você pode desligar e só ligar quando for utilizar, por exemplo, máquinas EC2, você pode dar um stop na instância e ela deixará contar as horas ligadas no mês, mas "cobrará" o disco EBS - 30GB/mês de uso.
• Habilitar para receber alertas para quando estiver prestes a estourar o free tier no Billing Preferences.

Clique na setinha que aparece depois do nome que definiu para sua conta no menu superior a direita e escolha My Billing Dashboard.

No menu lateral escolha Billing preferences.

• Monitorar o uso pelo seu Billing Dashboard.

• E pode criar também um Budget que vai avisar quando seu “orçamento definido estourar”. E a criação de até dois Budgets não tem custo.

Abaixo está um resuminho sobre o nível gratuito da Microsoft Azure e da Google Cloud Platform. E quem sabe num futuro próximo não falamos com detalhes mais sobre essas Clouds também.  

Nível Gratuito Microsoft Azure - Ao criar uma conta nova na Azure você tem 12 meses de alguns serviços "gratuitos" (alguns itens tem limitação de uso por mês, seja em horas no ar ou espaço utilizado e tipo de serviço) + créditos de $200 por 30 dias. É preciso um cartão de crédito para criar a conta.

Nível Gratuito Google Cloud Platform - Ao criar uma conta nova na GCP você ganha um crédito de $300 para usar durante 12 meses. E eles disponibilizam mais de 20 com o conceito de sempre gratuito, desde que você se atente as regras de uso e aos limites, não importa se sua conta tem 1 mês ou 1 ano. É preciso um cartão de crédito para criar a conta.

Aproveitem o nível gratuito das principais clouds e iniciem sua jornada na nuvem. Vale muito a pena criar uma conta e utilizar o free-tier da AWS, dá pra testar diversos serviços em diversas frentes. Prestem atenção em nossas dicas e arregacem as mangas.

Ah! E ao criar a conta na AWS não esqueçam de aplicar as boas práticas de segurança, deem uma olhada nesse artigo para saber mais a respeito.