No dia 07 de março de 2023 a Databricks lançou para todo o publico sua nova feature de consumo de dados do Delta Lake via API chamado “Databricks SQL Statement Execution API”. Segundo a descrição da própria Databricks (veja mais aqui) esta é uma forma de simplificar o acesso aos dados e facilitar a construção de aplicações de dados personalizadas para as suas necessidades. O acesso aos dados é feito por meio de uma API REST assíncrona, o que simplifica a conexão, eliminando a necessidade de gerenciamento de conexões, como ocorre ao utilizar JDBC ou ODBC. Além disso, não é necessário instalar nenhum driver para acessar os dados. Você pode usar esta feature para conectar suas aplicações baseadas em cloud, serviços e dispositivos no Databricks SQL. Neste post vou mostrar como utilizar esta nova feature que além de ser muito útil é bem simples de ser implementada. A API Endpoints A API possui três endpoints: POST /sql/statements – É o responsável por enviar nosso script ao banco. Caso demore para dar um retorno o endpoint devolve um “statment id” que será usado em outro endpoint para trazer o resultado assim que a consulta for finalizada. Se o retorno da consulta for rápido então os dados são retornados em formato JSON. GET /sql/statements/{statement_id} – Busca o retorno de um script enviado passando como parâmetro o statment id da mesma. POST /sql/statements/{statement_id}/cancel – Cancela a execução de um script em andamento. Configuração Precisamos de 3 informações para utilizar a API. 1 - Nome da instância do workspace Databricks Esta informação está disponível na página inicial do Databricks no ambiente Azure no campo URL. Exemplo: https://adb-1234567890123456.7.azuredatabricks.net 2 - Token de acesso pessoal Precisamos gerar este token no Databricks. Ele será utilizado como forma de autenticação quando formos consumir a API. (“Authorization”:”Bearer {TOKEN}”) No workspace do Databricks vá no menu superior do lado direito, clique na seta para baixo e escolha a opção User Settings Na tela que será aberta entre na aba “Access tokens” e clique no botão “Generate new Token” No campo “Comment” de um nome para seu token e no campo “Lifetime” escolha por quanto tempo este token será valido. Caso queira deixar ele valido para sempre deixe o campo vazio. Ao finalizar clique no botão “Generate”. Uma nova tela será aberta com o código token gerado. **Copie-o e guarde em um lugar seguro pois depois que fechar esta tela você não conseguirá mais resgatar este valor. Podemos ver abaixo que nosso token pessoal foi criado. 3 - ID do SQL Warehouse Para o uso desta feature é necessário termos configurado um SQL Warehouse no ambiente de SQL do Databricks. Quando a chamada da API for efetuada ela será endereçada para este ambiente computacional que vai ser iniciado (caso esteja desligado) e será o responsável por processar os scripts SQL enviados nas requisições HTTP. Acessamos o ambiente de SQL do Databricks no menu lateral superior esquerdo clicando em SQL. Dentro do ambiente de SQL voltamos ao menu lateral e clicamos em “SQL Warehouses” Por default o Databricks cria um SQL Warehouse padrão do qual podemos utilizar para o consumo da API. Caso no seu ambiente não exista você pode criar-lo clicando no botão “Create SQL warehouse” Clique no nome do SQL Warehouse que vai ser utilizado Vá na aba “Connection Details” e no campo “HTTP path” copie o código que está depois da última barra. Este código é o id do SQL Warehouse. Com os três itens acima e, mãos já podemos fazer o acesso aos dados via API. Para fins de exemplificação do consumo da API irei usar o Postman, uma ferramenta própria para testes de consumo de APIs. Você pode usar a ferramenta que preferir. Configuração da chamada da API Configuramos a chamada da seguinte forma: Verbo HTTP Post URL URL da instância do workspace Databricks + api/2.0/ + endponint. Exemplo: (http://adb-1234567890123456.7.azuredatabricks.net/api/2.0/statements/) Header Authorization: Bearer {Token de acesso pessoal} Exemplo: Bearer dapi9aaa74b82cf1746dd9143b34g01ea5f9-9 Body Enviamos aqui um JSON simples contendo os seguintes campos: warehouse_id - O Id do SQL Warehouse que pegamos acima no item 2. catalog - Nome do catalogo de dados. schema – Nome do database no delta lake onde será feita a consulta. statement – Script SQL que será enviado. Com tudo configurado então fazemos a chamada da API que nos dá o seguinte retorno: Podemos ver que ela devolveu um status de consulta pendente e também um “statement_id” para que possamos consultar em seguida o retorno do nosso select. Enquanto isso se olharmos no SQL Warehouse podemos ver que automaticamente ele foi iniciado. Esse início pode demorar alguns minutos. Depois que tiver iniciado podemos ver o “State” como Running. Como o primeiro endpoint nos retornou um “statement_id” temos que consumir agora o segundo endpoint passando este valor como parâmetro para obter o resultado. Para isso vamos fazer um novo consumo da API muito parecido com o primeiro que fizemos. As únicas diferenças serão: Verbo GET URL Acrescentaremos no final o “statement_id” Body Não enviamos body Abaixo temos o resultado Segue o JSON completo do resultado { "statement_id": "01edc420-728f-1a8e-8697-785deaca0b47", "status": { "state": "SUCCEEDED" }, "manifest": { "format": "JSON_ARRAY", "schema": { "column_count": 3, "columns": [ { "name": "name", "type_text": "STRING", "type_name": "STRING", "position": 0 }, { "name": "genre", "type_text": "STRING", "type_name": "STRING", "position": 1 }, { "name": "age", "type_text": "INT", "type_name": "INT", "position": 2 } ] }, "total_chunk_count": 1, "chunks": [ { "chunk_index": 0, "row_offset": 0, "row_count": 6 } ], "total_row_count": 6 }, "result": { "chunk_index": 0, "row_offset": 0, "row_count": 6, "data_array": [ [ "João da Silva", "M", "40" ], [ "Maria de Fatima Bueno", "F", "72" ], [ "Marcia Farias", "F", "45" ], [ "Otelo Ribeiro", "M", "18" ], [ "Douglas Poso", "M", "37" ], [ "Helena Poso", "F", "22" ] ] } } Vamos fazer uma nova consulta, só que agora adicionando um pouco mais de complexidade. Faremos um group by por gênero conforme coloco abaixo. Desta vez como o SQL Warehouse já estava no ar e a consulta retornou dados rapidamente,ele nos devolveu o resultado do select ao invés do “statement_id” JSON completo { "statement_id": "01edc422-4337-1211-a0b2-7c479fd69685", "status": { "state": "SUCCEEDED" }, "manifest": { "format": "JSON_ARRAY", "schema": { "column_count": 2, "columns": [ { "name": "genero", "type_text": "STRING", "type_name": "STRING", "position": 0 }, { "name": "quantidade", "type_text": "BIGINT", "type_name": "LONG", "position": 1 } ] }, "total_chunk_count": 1, "chunks": [ { "chunk_index": 0, "row_offset": 0, "row_count": 2 } ], "total_row_count": 2 }, "result": { "chunk_index": 0, "row_offset": 0, "row_count": 2, "data_array": [ [ "F", "3" ], [ "M", "3" ] ] } } Vamos testar agora o ultimo endpoint, aquele que cancela uma consulta enviada. Seguindo o mesmo padrão do primeiro consumo: Verbo POST URL URL da instância do workspace Databricks + api/2.0/ + endponint + statment_id+/cancel. Exemplo (http://adb-1234567890123456.7.azuredatabricks.net+ api/2.0/statements/ /01edc423-2721-1e12-8acc-d4f456a7171d/cancel) Header Authorization Bearer {Token de acesso pessoal} Ele não devolve um JSON, porém podemos ver o Status HTTP 200 que indica que a consulta foi cancelada com sucesso. Mas não pense que este serviço executa apenas selects no Delta Lake... também é possível utilizar os comandos DML. Vamos ver mais alguns exemplos. Inserção de Dados Enviamos um comando de inserção simples para a mesma tabela cliente. O retorno é um JSON informando que a operação foi bem-sucedida (tag “state”), trazendo a quantidade de linhas afetadas (“num_affected_rows”) e inseridas (“num_inserted_rows”). "statement_id": "01edc71a-1d71-1297-93ee-faa1b78988c9", "status": { "state": "SUCCEEDED" }, "manifest": { "format": "JSON_ARRAY", "schema": { "column_count": 2, "columns": [ { "name": "num_affected_rows", "type_text": "BIGINT", "type_name": "LONG", "position": 0 }, { "name": "num_inserted_rows", "type_text": "BIGINT", "type_name": "LONG", "position": 1 } ] }, "total_chunk_count": 1, "chunks": [ { "chunk_index": 0, "row_offset": 0, "row_count": 1 } ], "total_row_count": 1 }, "result": { "chunk_index": 0, "row_offset": 0, "row_count": 1, "data_array": [ [ "1", "1" ] ] } } Vamos conferir se o registro foi mesmo inserido. Faremos agora um select buscando por registros cujo a idade seja igual a 80 anos. Vemos na imagem acima o retorno do nosso cliente João da Souza. Update Vamos aproveitar o mesmo registro e faremos agora um update. Vamos alterar o campo “age” para 90. Algumas vezes ele não consegue retornar diretamente o resultado. Vimos isso lá no começo desta postagem. Mas ele devolve um “statment_id” que usamos para consultar o resultado. Vamos agora fazer um select deste registro porem filtrando agora pela idade igual a 90 anos. Para finalizar, faremos agora a exclusão do registro com um comando delete. Fazendo o select pela idade igual a 90 ele não retorna mais registros. Vemos que o resultado para a seleção retornou vazio, conforme o esperado. O Databricks vem facilitando o acesso aos dados cada dia mais. Esse tipo de conexão deixa o processo muito mais simples e nos abre um grande leque de oportunidades. Espero que tenham gostado e que se aventurem também nessa nova forma de acesso aos dados do Delta Lake!

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!

Neste post vou mostrar como criar um pipeline genérico de consulta de dados em uma API e armazenamento no data lake. Utilizaremos o Data Factory (mas pode ser usando o Synapse Integrate também) para orquestrar, consumir e ingerir os dados. A ingestão será feita num Storage Account Gen 2. Vamos consumir uma API aberta que retorna um Json de produtos cosméticos: https://makeup-api.herokuapp.com/ Como a proposta é fazer um pipeline dinâmico, vamos utilizar uma planilha de Excel com as informações sobre a API de consumo e os containers para ingestão, desta forma qualquer alteração ou inclusão de novos endpoints a serem integrados é feita apenas nesta planilha sem a necessidade de fazer alterações no projeto. Chamaremos esta planilha de “Controller”. Conhecendo o Ambiente Azure Data Lake Local onde está a planilha controller Planilha controller É uma planilha de Excel onde criamos um layout padrão de campos. Nela incluímos as informações pertinentes ao sistema de origem (API) e de destino (Data Lake). Dados sensíveis, como senhas e chaves são armazenados em secrets do Key Vault. Segue um descritivo dos campos que serão utilizados no processo: source_api_url - URL da API source_endpoint_name – Endpoint que sera consultado source_header – Headers utilizados container_target – Nome do container de destino no data lake directory_target – Nome do diretório de destino file_target – Nome do arquivo que vai ser gerado flag_controller – flag que indica se o registro está ativo Esta planilha será consumida no Data Factory e estes valores serão usados como parâmetros de entrada para o consumo da API e a ingestão no Data lake. Data Factory Configuração do projeto Abaixo segue as configurações necessárias para criação do projeto. Linked Sevices Utilizaremos dois linked services: HTTP Data Lake HTTP Aqui vamos configurar a conexão com a API, porém faremos isso de forma dinâmica utilizando parâmetros, pois as informações sobre o consumo da API estão na planilha controller. Acesse o menu lateral Manage>Linked services e clique em “New”: Na caixa de busca digite “HTTP” e clique no botão “continue”. A tela de configuração será aberta: Configuraremos aqui os dados de acesso a API. Deixaremos a configuração o mais dinâmica possível, pois os dados virão da planilha controller. Segue abaixo um passo-a-passo: 1. Name- Nome do linked service, lembre-se de sempre usar um name convention. 2. Connect via integration runtime - Deixamos o Integration runtime padrão do Azure. 3. Base URL - Criamos um parâmetro (será mostrado como criar no item 6 desta lista) chamado “url” e inserimos neste campo. A Url a ser usada virá da planilha controller. 4. Authentication type - A API que estamos consumindo não possui nenhum tipo de autenticação, mas caso esteja utilizando uma que necessite, basta clicar no combo box e escolher entre as opções disponíveis: Ao escolher uma das opções da lista os campos pertinentes a autenticação aparecerão logo abaixo. Para nosso exemplo escolheremos a opção “Anonymous”. 5. Auth Headers - Caso sua API de consumo necessite de um header de autenticação basta clicar em “New” e escolher uma das opções: 6. Parameters - Os parâmetros que utilizamos na configuração do linked service são criados nesta seção. Data Lake Vamos criar mais um linked service, agora para conexão com o Data Lake. Utilizaremos as configurações padrões. No meu caso a configuração ficou da seguinte forma. Datasets Precisaremos de 3 Datasets neste projeto: Dataset Datalake Excel Será utilizado para fazer a leitura do arquivo controller. Utilizaremos o linked service de data lake e o formato de dados será excel. ** Criamos parâmetros para os campos Container, Directory, File Name e Sheet name. Quando formos utilizar este dataset passaremos os valores para estes parâmetros. Dataset Data Lake parquet Será utilizado para fazer a ingestão dos dados lidos da API no data lake em formato parquet. Utilizaremos o linked service de data lake e o formato de dados será parquet. **Note que criamos parâmetros para os campos referentes a container, diretório e nome do arquivo. Estas informações virão na planilha controller. Dataset HTTP JSON Será utilizado para fazer a leitura do JSON retornado pela API. Utilizaremos o linked service de HTTP e formato de dados será JSON. Criamos aqui dois parâmetros (aba Parameters) url e endpoint. Estes parâmetros são apontados nos seguintes campos do dataset: url – É a URL de acesso a API. Este valor será transmitido ao pipeline pelo arquivo controller. Relative URL – É o endpoint da API que também será transmitido ao pipeline pelo arquivo controller. Desenvolvimento do Pipeline O Pipeline criado tem apenas quatro activities: Lookup Responsável por fazer a leitura da planilha controller e a passagem dos valores para as próximas activities. Configuração Escolher o Dataset de excel e preencher os parâmetros manualmente. Estes parâmetros recebem o local onde a planilha controle está armazenada além de qual a aba do arquivo ele vai utilizar. Filter Esta activitie filtra apenas registros prontos para serem integrados o que neste caso são os registros cujo campo “flag_ativo” tem o valor 1 Configuração No campo “Items” escolhemos a saída da activite anterior utilizando a seguinte expressão “@activity('Ler Planilha Controller').output.value” No campo “Condition” Montamos uma expressão lógica que retorna verdadeiro quando o valor do campo “flag_controller” for igual a 1 (@equals(item().flag_controller,'1') ) ForEach Para cada linha existente na planilha controller com o campo flag_ativo = 1 faz a chamada da activitie de cópia passando seus valores como parâmetro. Configuração No campo “Items” escolhemos a saída da activite anterior utilizando a seguinte expressão “@activity('Ativo').output.value” Copy data Efetua o consumo da API e grava o retorno dos dados no data lake em formato parquet Configuração Source Escolher o Dataset JSON e nas propriedades do dataset apontar os valores de url e endpoint da planilha controller. @item().source_api_url @item().source_endpoint_name Em “Request method” escolher o método GET e em “Additional headers” apontar o valor dos headers que vem da planilha controller. @{item().source_header} Configuração Sink Escolher o dataset de parquet e nas propriedades do dataset apontar os valores de container, directory e file name da planilha controller. @item().container_target @item().directory_target @concat(item().file_target,'.parquet') O pipeline ao final ficará desta forma: Resultado Agora é hora de testar!! Sucesso!!! Como podemos ver na imagem acima um arquivo foi criado no Data lake. Verificando agora diretamente no container transient... O arquivo .parquet foi criado. Podemos fazer um preview dos dados no Data lake Podemos pensar em nosso dia-a-dia de desenvolvimento e encaixar esta dica dentro da nossa realidade. Como o processo é dinâmico poderíamos colocar mais linhas na planilha controller apontando para outros endpoints e este pipeline iria fazer a execução sem precisar de nenhuma alteração.