No post anterior (clique aqui) eu mostrei como fazer o consumo de APIs de forma dinâmica pelo Data Factory. Agora o objetivo é mostrar como fazer o consumo de APIs pelo Databricks utilizando o Pyspark. Por ser bem simples (confiem em mim é muito simples mesmo rs) trarei aqui um ranking com 3 bibliotecas que nos auxiliam no consumo de APIs onde vou comentar os prós e contras de cada um segundo minha experiencia de uso. Ao final farei também uma comparação com o consumo de APIs no Data Factory e vamos então avaliar qual a melhor ferramenta para o consumo de APIs levando em consideração alguns fatores como:
Tempo de desenvolvimento
Dificuldade
Custo
Este último item da lista com certeza é o que mais pesa na decisão de qual ferramenta utilizar...
Para os testes que iremos fazer utilizaremos uma API aberta que retorna um Json de produtos cosméticos:
https://makeup-api.herokuapp.com/
Ranking
Pesquisando na internet encontrei várias bibliotecas usadas para o consumo de APIs que podem ser utilizadas no Databricks, mas selecionei 3 das quais vou ranquear da “melhor” para a “pior”.
1° Lugar Biblioteca Requests
Visão Geral
Umas das mais populares e utilizadas por desenvolvedores Python, a biblioteca Requests ganhou a medalha de ouro pela sua simplicidade e facilidade de uso. Com apenas 3 linhas de código é possível importar a biblioteca, consumir a API e armazenar o retorno:
Implementação
Importação da biblioteca
Código básico para o consumo de uma API
Além de fazer um decode automático, ou seja, decodificar o conteúdo do servidor sem a necessidade de termos de explicitamente faze-lo, ele também tem uma função que converte o resultado para JSON, desta forma não precisamos chamar a biblioteca “Json” para transformar o conteúdo como vemos em outras bibliotecas de API.
Temos aqui o resultado da consulta trazendo todos os produtos.
A partir do resultado podemos verificar qual o status da chamada
Suporte
A biblioteca requests dá suporte a todos os verbos Rest HTTP e também para passagem de parâmetros, autenticação e headers nas chamadas.
Abaixo estamos utilizando um header (Content-Type) e dois parâmetros (price-greater_than e brand).
Para passar os valores utilizamos os argumentos params, e headers dentro da requisição get.
Podemos ver abaixo que ele gerou o link com os parâmetros no formato correto.
Agora, mostrando o resultado, percebemos que ele trouxe apenas o que solicitamos nos parâmetros, neste caso apenas um registro.
Conclusão
Como pudemos observar a biblioteca é incrivelmente simples e intuitiva o que facilita e muito no desenvolvimento do consumo de APIs.
No Git Hub ela tem no momento em que este post foi escrito mais de 9k forks, o que mostra como ela é realmente utilizada.
Para mais informações sobre a biblioteca clique aqui
2º Lugar Biblioteca httplib2
Visão Geral
Uma biblioteca “modesta” porem ainda sim fácil e poderosa. A biblioteca httplib2 leva a medalha de prata também por sua facilidade de desenvolvimento e implementação. Vamos entender logo em seguida o motivo de ter levado o segundo lugar.
Implementação
Temos que instalar esta Biblioteca antes de importa-la
Instalação da biblioteca
Importação da biblioteca
Código básico para o consumo de uma API
O desenvolvimento é muito parecido com o que vimos na biblioteca requests, porém aqui precisamos antes de mais nada instanciar um “client HTTP” (linha 1). A partir disso criamos a requisição utilizando o “.request”.
Notem que duas variáveis foram criadas:
response
Recebe todo o cabeçalho de retorno da requisição
A partir dela podemos verificar qual o status da chamada
content
Armazena o retorno da requisição
É aqui que começamos a ver as diferenças. Esta biblioteca não tem decode automático e também não tem suporte para transformação do conteúdo para JSON, desta forma para conseguirmos transformar o resultado, que é interpretado como um texto, em JSON precisamos do auxílio da função json.loads(“content”) da biblioteca JSON além de termos que informar qual encoding utilizar no momento da leitura do resultado.
Suporte
A biblioteca httplib2 dá suporte a todos os verbos Rest HTTP e também para passagem de autenticação e headers.
Abaixo estamos utilizando um header (Content-Type) e dois parâmetros (price-greater_than e brand).
Para passar os valores utilizamos o argumento headers dentro da requisição get e os parâmetros da url precisam ser passados junto com a url, outro ponto negativo em relação a requests.
Conclusão
Embora não seja tão otimizada quanto a biblioteca requests não podemos dizer que a httplib2 é uma biblioteca complicada. Ela dá as mesmas funcionalidades da primeira, porém o desenvolvimento é um pouco mais "custoso".
No Git Hub ela tem no momento em que este post foi escrito 188 forks, conseguimos aqui notar uma grande diferença de uso e preferência comparando com a requests.
Para mais informações sobre a biblioteca clique aqui
3º Lugar Biblioteca PyCurl
Visão Geral
O PyCurl é uma biblioteca multiprotocolo para transferências de arquivos, ela trabalha com HTTP, FTP, SMTP entre outros protocolos de comunicação. Como o nome já diz ela é baseada nos conhecidos comando Curl, então caso você esteja familiarizado com estes comandos com certeza vai curtir e muito esta biblioteca que leva aqui em nosso ranking a medalha de bronze.
Seu grande ponto positivo é a performance que segundo pesquisas (veja mais aqui) é várias vezes mais rápido que a biblioteca requests quando trabalhando com requisições paralelas e grande volume de dados.
Implementação
Temos que instalar esta Biblioteca antes de importa-la
Instalação da biblioteca
Importação da biblioteca
Código básico para o consumo de uma API
Logo de cara percebemos que o desenvolvimento com esta biblioteca é mais complicado. O que foi bem relevante para deixa-la na terceira posição. As explicações de cada linha estão nos comentários na imagem acima.
***O PyCurl não fornece o armazenamento da resposta das solicitações, para conseguirmos armazena-la precisamos importar da biblioteca io o BytesIO e criar um Buffer (na forma de um objeto StringIO) e então instruir o Pycurl a escrever os dados nele.
Usamos a variável que foi atribuída e aplicamos o decode para vermos o resultado.
Para retornarmos o status HTTP
Suporte
A biblioteca pycurl dá suporte a todos os verbos Rest HTTP e também para passagem de autenticação, parâmetros e headers.
Abaixo estamos utilizando um header (Content-Type) e dois parâmetros (price-greater_than e brand).
Vamos ver logo abaixo que a passagem destes valores é feita de forma diferente das outras bibliotecas que avaliamos anteriormente. Segue abaixo o código com as explicações nos comentários.
Abaixo vemos o retorno dos dados
Conclusão
O Pycurl é mais estruturado e um pouco mais complicado, exige uma certa dedicação para o entendimento de sua estrutura e desenvolvimento. O seu contraponto está justamente na performance que se comparada com a biblioteca requests num cenário de muitas chamadas simultâneas e um grande volume de dados se mostra superior. Caso você já esteja familiarizado com os comandos cURL esta pode ser uma boa escolha para você.
No Git Hub ela tem no momento em que este post foi escrito 288 forks, muito aquém daquilo que vimos na requests.
Para mais informações sobre a biblioteca clique aqui.
Qual a melhor ferramenta para consumo de API?
Como todo bom engenheiro de dados responde... depende. Vamos fazer uma comparação mostrando prós e contras de cada uma.
Data Factory
Prós
Não necessita de código. Como vimos no post anterior todo o desenvolvimento do consumo da API é feito sem código numa interface totalmente gráfica, ou seja, não requer conhecimento em linguagem de programação.
Contras
Exige uma configuração e tempo de desenvolvimentos maiores uma vez que é preciso primeiro criar um Linked Service depois criar um Dataset e então fazer a configuração e passagem de parâmetros na atividade de copy.
Databricks
Prós
Facilidade. Apesar de exigir um conhecimento prévio de linguagem de programação, com apenas 3 linhas de código conseguimos fazer o consumo de uma API simples. Isso torna seu desenvolvimento fácil e rápido.
Contras
Não padronização do código. No Databricks, os desenvolvedores têm a flexibilidade de escrever o código de acordo com suas preferências, o que pode ser benéfico pois, estimula a criatividade e um desenvolvimento fluido. Contudo, a falta de padronização pode gerar problemas futuros, especialmente em notebooks com grande volume de código. Isso porque, sem seguir um padrão de desenvolvimento, a manutenção do código pode se tornar bastante complexa e onerosa.
O Valor. Fiz um orçamento básico na calculadora do Azure para os ambientes Data Factory e Databricks. Simulei as configurações mais simples e baratas de cada um informando que ambos executariam 1 hora por dia durante 30 dias. Abaixo temos os seus respectivos valores:
Total Data Factory R$48,87
Total Databricks R$79,16
Pode até parecer que a diferença é pouca, mas temos que levar em consideração que simulei o uso de apenas 1 hora/dia. Se fizermos o cálculo de porcentagem da diferença de valores descobriremos que o Databricks (neste cenário) fica 38% mais caro. Com certeza isso pode ser um impeditivo para sua adoção no consumo e ingestão de dados via API.
**Observação. Aqui estamos simulando um ambiente onde não temos nenhuma das duas soluções implementadas e por isso faz mais sentido, pensando em custos, utilizar o Data Factory. Este cenário pode mudar completamente caso o ambiente de Databricks já exista previamente e esteja sendo utilizado, neste caso pode ser mais vantajoso adotar o Databricks para o consumo de APIs se você aproveitar algum cluster existente e executar o seu código no momento que o mesmo já esteja ligado.
Após toda esta análise sou compelido a concluir que não existe a melhor solução para todo e qualquer caso, como vimos, tanto o Databricks como o Data Factory são excelentes ferramentas. Precisamos nos abster de preferencias pessoais e avaliar dentro do cenário existente qual a melhor solução para resolver o problema do cliente. É isso que nos torna profissionais diferenciados. Lembre-se, antes de tudo nossa principal função é resolver problemas.
Pense nisso!