Timeout na Conexão do Azure Data Factory

Olá Pessoal!

Recentemente estive envolvido em um projeto de carga utilizando o Azure Data Factory como orquestrador, tendo como origem o Oracle Database On-premises e destino, o Azure SQL Data Warehouse.

Os dados do Oracle DB estavam distribuídos em dois hosts distintos e percebi que no processo de configuração da fonte de dados de origem, uma instância concluía a conexão com sucesso enquanto a outra constantemente retornava timeout. Esse comportamento também foi observado quando utilizado a ferramenta de teste de conexão presente no Integration Runtime Configuration Manager.

O mais interessante, é que ambas as instâncias estavam acessíveis pelo SQL Developer e ODBC Data Sources, não justificando qualquer tipo de restrição de acesso ou até falta conectividade no host que estava hospedando o Integration Runtime.

Após o contato com o engenheiro de suporte da Microsoft, foi possível identificar que existia um delay maior no tempo de resposta entre as instâncias, sendo o suficiente para uma delas ultrapassar o limite de tempo do processo de validação da conexão no portal do Data Factory e também no processo do teste através do Integration Runtime Configuration Manager.

Para contornar esse comportamento, um parâmetro adicional para controle do timeout teve que ser adicionado nas propriedades da conexão e dessa forma, os limites de timeout substituíram a definição padrão do produto. Note na imagem abaixo que após a aplicação do parâmetro a conexão é feita com sucesso.

Até a próxima!

Consumindo dados do Azure IoT Hub com o Power BI

Olá Pessoal!

Tenho trabalhado cada vez mais com um portfólio extenso de produtos no Azure relacionados a Data Platform e com certa frequência, tenho que fazer algumas apresentações de soluções. Vou mostrar neste artigo um exemplo de como consumir dados com origem no Azure IoT Hub dentro do Power BI Service em tempo real.

Para esse exemplo utilizarei como fonte de dados o Raspberry Pi Web Simulator, que irá basicamente gerar dados de telemetria aleatórios de temperatura e umidade de forma continua. Você pode acessar através do link: https://azure-samples.github.io/raspberry-pi-web-simulator/

Para mais informações acesse o repositório dessa aplicação no Github: https://github.com/Azure-Samples/raspberry-pi-web-simulator

Utilizaremos 4 componentes na solução, a aplicação web do Raspberry Pi, o Azure IoT Hub, Azure Stream Analytics e Power BI Service.

O Azure IoT Hub é um serviço que atua como hub central de mensagens para comunicação entre as aplicações IoT e o dispositivo. Sendo assim, a primeira tarefa a ser feita é criação do serviço no Azure com a camada “F1: Free Tier”, dessa forma será possível enviar até 8 mil mensagens por dia sem custo, ideal para realização de testes.

Após a criação do serviço, devemos criar o “IoT Device” no qual será cadastrado o dispositivo e obtido a string de conexão a ser utilizada dentro do Raspberry Pi Web.

Devemos agora acessar a aplicação web do Raspberry Pi e alterar apenas a linhas 15, na qual é solicitado o “IoT hub device connection string”. Nesse trecho deve ser colocado a string de conexão obtido no IoT Device e ao final selecionado a opção “Run” para iniciar o envio dos dados de telemetria para o Azure IoT Hub.

Após o inicio do envio, as informações estatísticas podem ser consultadas na visão geral do serviço do IoT Hub.

Uma vez que os dados de telemetria estejam chegando no IoT Hub, devemos avançar para a segunda parte. Precisaremos utilizar o serviço do Azure Stream Analytics, que tem como objetivo criar uma “pipeline” para processamento dos eventos que estão sendo carregados no IoT Hub e jogá-los no Power BI Service em tempo real.

Assim como no serviço anterior, deve ser criado o recurso no Azure.

Para esse serviço deve ser configurado a fonte de entrada e saída, sendo assim, a entrada será definida com a origem do IoT Hub e a saída será um Workspace do Power BI Service.

A consulta do Stream Analytics deve ser editada para utilizar como parâmetros as fontes criadas e por último, o serviço precisa ser iniciado.

Após concluir a etapa anterior, os eventos começaram a passar pelo serviço do Stream Analytics e o conjunto de dados “IoTDataset” aparecerá no Power BI Service.

O passo final será criar um relatório e dashboard com os dados que estão chegando no Power BI em tempo real.

Chegamos ao final do processo e foi possível simular um cenário que os dados são consumidos pelo Power BI através de componentes específicos do Azure. Para mais detalhes, seguem as documentações oficiais dos serviços que utilizamos no Azure:

https://docs.microsoft.com/pt-br/azure/iot-hub/

https://docs.microsoft.com/pt-br/azure/stream-analytics/

https://docs.microsoft.com/pt-br/power-bi/

Até a próxima!

Integrando Azure Data Factory com o SSIS

Olá Pessoal!

Feliz Ano Novo…

Para iniciarmos bem o ano, vou falar um pouco sobre um produto que tenho utilizado bastante ultimamente, o Azure Data Factory.

Data Factory é um serviço de integração (ETL/ELT) disponível no Azure, tendo como diferencial a sua facilidade na construção soluções de integrações híbridas. Esse serviço também se destaca pela quantidade de conectores com suporte nativo disponíveis, os quais já passam de 70. Vocês podem conferir os detalhes gerais na página abaixo abaixo:

https://azure.microsoft.com/pt-br/services/data-factory/

Apesar de uma série de benefícios existentes em sua utilização, inclusive em sua nova versão (V2), o Data Factory ainda trás limitações quando comparamos com alguns recursos existentes no SQL Server Integration Services, principalmente na parte das transformações disponíveis.

Fora algumas limitações, o Data Factory trás ganhos na orquestração visual, tendo uma quantidade de conectores grande, além de um throughput elevado e inclusive, permitindo que pacotes On-premises do SSIS sejam executados no serviço.

No exemplo abaixo, será demonstrado como fazer a configuração do Data Factory para pode executar pacotes do SSIS. O seguinte cenário será utilizado como base, existe um pacote do SSIS (On-premises) que faz a carga de dados de um arquivo estruturado em um diretório de rede para o SQL Server local, o objetivo é levar de maneira simples esse pacote para o Data Factory.

Uma vez que o serviço do Data Factory tenha sido criado e essa etapa é relativamente simples, você deve acessar a visão geral do recurso e ir até a página de “Autor e Monitor”.

Nessa tela inicial está disponível acesso as principais funções do Data Factory, além de tutoriais e materiais de apoio para realizar as principais operações no serviço.

A primeira opção é referente a criação de “Pipeline”, que são agrupamentos lógicos de atividades que juntos realizam a tarefa. A segunda opção de “Copy Data” inicia uma atividade de cópia entre dois armazenamento de dados, podendo estar On-premises ou Cloud. A terceira opção de “Configure SSIS Integration Runtime” apoia exatamente na atividade que iremos realizar. Por último temos o “Set up Code Repository” para realizar a associação do repositório de versionamento com o Data Factory.

Avance para seleção da opção “Configure SSIS Integration Runtime”. O “Integration Runtime” é uma estrutura computacional do Data Factory que fornece algumas capacidades de integração de dados entre ambientes de redes diferentes. No Data Factory uma atividade define a ação a ser realizada, um “Linked Service” define o armazenamento de dados de destino e o “Integration Runtime” fornece a ponte entre a atividade e o “Linked Service”. A diferença do “Azure-SSIS Integration Runtime” para as outras opções, se resume a capacidade de executar pacotes nativos do SSIS no Data Factory com recursos do Azure VM em Cluster dedicados para essa tarefa.

Veja que existe a seleção do hardware a ser utilizado, assim como, a quantidade de nodes. Quando comparado a precificação do “SSIS Integration Runtime” com a pipeline sem integração, o custo é muito maior, sendo assim, o custo deve ser um fator importante na decisão na utilização desse tipo de solução integrada.

A próxima etapa no setup é referente a configuração do Azure SQL Database que irá hospedar a base do “SSIS Catalog”. O server já existia na subscrição, sendo assim, só foi necessário preencher as informações de acesso e selecionar o “Tier”.

Se necessário altere as configurações avançadas disponíveis e em caso de dúvida, repare que existe um ícone de exclamação próximo ao item, ao passar o mouse por cima será possível obter mais informações sobre a função de determinada configuração, em nosso caso vou deixar o padrão e finalizar.

O deploy irá demorar alguns minutos e ao concluir será exibido dentro do Data Factory, além da base do SSISDB criada automaticamente no SQL Database.

Ao selecionar a opção “View Runtime Integration Detail” é possível acessar uma página com maior detalhes de configuração, mostrando também informações de consumo dos nodes.

Agora que terminamos essa parte do setup no Data Factory, vamos ao ambiente On-premises. Temos o projeto “CargaDados” já existente no Visual Studio (SSDT) com o pacote “Carga”. No pacote “Carga” temos uma tarefa para extração dos dados de determinado arquivo estruturado e inserção deste em um banco SQL Server On-premises.

Esse projeto teve seu deploy feito para o Integration Services Catalogs da mesma instância do SQL Server On-premises.

Precisamos agora partir para segunda etapa, na qual faremos o deploy do projeto para o Azure SQL Database que está hospedando a estrutura do Integration Services Catalogs (SSISDB). A etapa é igual a qualquer outro procedimento de deploy, na tela de publicação do Integration Services dentro do Visual Studio (SSDT), deve ser selecionado o servidor e avançar para o deploy.

Uma vez concluído a estrutura do Integration Services Catalogs no Azure SQL Database será criada.

Por último, faremos o agendamento para execução periódica do pacote, essa etapa pode ser feita também por dentro do SSMS ao clicar com o botão direito no pacote e ir até a opção “Schedule”.

O recurso de agendamento pelo SSMS criará a “Pipeline”, Atividade e “Trigger” dentro do Data Factory, seguindo os parâmetros passados na configuração.

A execução da “Trigger” pode ser monitorada na guia “Monitor” na opção “Trigger Runs”.

Concluímos todos os passos da solução! Vale ressaltar que, não são todos os caso que a utilização do Data Factory com o SSIS é vantajoso, existem restrição não abordadas aqui e que devem ser vistas na documentação, apesar disso, é um recurso que funciona muito bem, além de ter uma fácil configuração. Devemos também lembrar que, o Data Factory fornece outros 2 tipos de “Integration Runtime”, não discutidos nesse artigo, um para uso com atividades no Azure e outro redes privadas.

Seguem alguns links complementares que irão ajudar na utilização do Azure Data Factory, inclusive relacionado a funcionalidade de integração com o SSIS.

https://docs.microsoft.com/pt-br/azure/data-factory/concepts-integration-runtime

https://www.blue-granite.com/blog/the-right-tool-for-the-job-azure-data-factory-v2-vs.-integration-services

https://azure.microsoft.com/pt-br/pricing/details/data-factory/

https://docs.microsoft.com/en-us/azure/data-factory/create-azure-ssis-integration-runtime

https://docs.microsoft.com/pt-br/sql/integration-services/lift-shift/ssis-azure-connect-to-catalog-database?view=sql-server-2017

Até a próxima!

AMBIENTE HÍBRIDO – AZURE SQL DATABASE COM SQL SERVER ON-PREMISES

Olá Pessoal!

O processo de adoção de soluções na nuvem esta mais natural e transparente a cada dia, sendo assim, os clientes estão optando por estender o ambiente local (On-premises) e integrá-lo como parte da arquitetura Cloud cada vez mais, transformando em uma solução híbrida. Esse tipo de solução pode ser alcançada de maneiras diferentes dependendo do tipo de plataforma de dados escolhida no ambiente da nuvem, nesse artigo vamos abordar o funcionamento de uma solução entre Azure SQL Database (Platform as a Service) e o SQL Server 2017 On-Premises.

Temos o seguinte cenário para trabalhar, o cliente deseja migrar o banco de dados SQL Server para o Azure SQL Database, levando em consideração principalmente o custo/benefício do serviço, além disso tem intenção de manter os dados replicados em sua instância de origem no SQL Server 2017 On-Premises, funcionando como uma espécie de Disaster Recovery.

Essa integração entre o SQL Database e o SQL Server depende do serviço Azure SQL Data Sync que está incorporado no Azure SQL Database. O Azure SQL Data Sync pode ser utilizado para distribuição de dados entre SQL Server, Azure SQL VM e Azure SQL databases, tanto unidirecional quanto bidirecional. Para nosso cenário, utilizaremos esse serviço para sincronização dos dados entre o Azure SQL Database e SQL Server on-premises.

Veja na topologia abaixo o modelo que utilizaremos:

A primeira etapa dessa solução envolve a migração da base para o Azure SQL Database, no qual pode ser feito através do Microsoft Data Migration Assistant (DMA). Vou considerar que essa etapa foi concluída com sucesso e sem restrições, sendo assim, o ambiente no Azure (PaaS) já está preparado.

Veja na imagem acima que uma das opções disponíveis no menu de configurações do Azure SQL Database é o “Sync to other databases” e após acessar essa opção pode ser visto as categorias “Sync Group” e “Sync Agent“.

O Data Sync é baseado no conceito do Sync Group, que é o grupo de bases que você deseja sincronizar. Dentro do Sync Group é definido a base que servirá como “Hub” e as restantes são definidas como membro, dessa forma a comunicação ocorre apenas entre o “Hub” e os membros individuais.

Algumas considerações importantes:

  • A base de dados “Hub” precisa ser um Azure SQL Database;
  • As bases de dados member podem ser SQL Databases, on-premises SQL Server databases ou instâncias SQL Server em Azure virtual Machines;
  • A base de dados Sync contém o metadado e log do Data Sync, sendo necessário ser um Azure SQL Database localizado na mesma região que a base de dados “Hub”;
  • Se uma base de dados on-premises for definida como membro, obrigatoriamente deve ser instalado e configurado o “Local Sync Agent“.

Como pode ser visto nas considerações, em nosso cenário será necessário instalar o “Local Sync Agent“, entretanto iniciaremos pela configuração do “Sync Group“.

Selecione a opção de “New Sync Group” dentro do menu “Sync to others databases“, como pode ser visto na imagem anterior. Deve ser preenchido o nome do “Sync Group“, a base de dados que irá receber os metadados, sendo que, é recomendado que uma nova base seja criada exclusivamente para armazenar esses dados, também deve ser selecionado na opção “Automatic Sync“, que define a frequência de atualização dados dados e por último, o “Conflict Resolution” que tem duas opções, “Hub Win” e “Member Win“, caso seja escolhido o primeiro, se algum conflito ocorrer na sincronização os dados da origem (“Hub”) substituem os dados conflitados no destino (“Member”), na segunda opção, ocorre exatamente o inverso.

Após finalizar essa etapa, o Azure vai iniciar o processo de implantação do “Sync Group” e em seguida avançar para a inclusão dos membros no menu “Add sync members“. Nessa etapa o usuário e senha de acesso devem ser preenchidos para a base de dados atual selecionada como “Hub“. Logo abaixo temos disponível a seleção do “Member Database“, que pode ser um Azure Database ou um On-Premises Database, para nosso cenário irei selecionar a segunda opção.

A primeira opção dentro da etapa do “Configure On-Premises” é para fazer a configuração do “Sync Agent Gateway“, sendo assim, vemos criar um novo e para isso devemos fazer o download do SQL Azure Data Sync Agent. A instalação é bem simples e apenas requer um usuário com privilégios para rodar o serviço no Windows.

Após a instalação, devemos retornar ao Azure e preencher o nome do agente para que possa ser gerado a chave de registro do “Sync Agent“.

Retorne ao “Sync Agent” e selecione “Submit Agent Key“, em seguida preencha o “Agent Key” com a chave copiada e também as credenciais de acesso do Azure SQL Database criado anteriormente para os metadados.

O próximo passo será registar o acesso ao SQL Server On-Premises através da opção “Register” no “Sync Agent“.

Uma vez que as configurações foram finalizadas, podemos retornar ao Azure e selecionar “OK” no menu “Select Sync Agent” e retornar ao “Configure On-Premises“. Seguiremos para a opção “Select the Database“, na qual temos que preencher o nome no campo “Sync Member Name“, selecionar o “Sync Agent” recém configurado e o “Sync Directions“. O “Sync Directions” determina a direção que os dados serão sincronizados, no nosso caso utilizaremos o “From the Hub“, ou seja, a base de dados no Azure SQL Database que está configurada como “Hub” será a origem dos dados a serem sincronizados.

Finalize essa configuração através do botão “OK” no menu “Select the Database“, “Configure On-Premises” e “Select sync members“, em seguida o Azure vai iniciar as implementações. Por último, iremos ao menu “Configure sync group” para selecionar as tabelas que serão sincronizadas. Repare que existe um alerta informando que apenas as tabelas com chave primária são suportadas, felizmente a tabela “SalesOrderDetailEnlarged” atende esse requisito.

Após salvarmos a configuração, o Azure irá processar as alterações e retornar para o menu inicial do “Sync to other databases“.

Ao verificar via SSMS as bases do Azure SQL Database, perceba que além da “AventureWorks2017” que já existia, foi adicionada a base de dados “dbsyncmetadata” com os metadados, também foram criados novas tabelas de apoio da solução dentro da base “AventureWorks2017“. Essas mesmas tabelas foram criadas no SQL Server On-Premises.

Agora a solução para atender o cliente está pronta, restando apenas testar o seu funcionamento. Podemos acessar o “Sync Group” e acompanhar os logs para identificar as notificações de erro e sincronização.

Apesar de serem etapas simples, existem muitas limitações que impossibilitam que essa solução seja utiliza para qualquer cenário, é importante que seja feita a leitura de toda documentação do produto, assim como, os devidos testes antes da utilização em produção.

Seguem as referências:

https://docs.microsoft.com/pt-br/azure/sql-database/sql-database-get-started-sql-data-sync

https://docs.microsoft.com/pt-br/azure/sql-database/sql-database-sync-data

https://azure.microsoft.com/pt-br/blog/azure-sql-hybrid-data-movement/

Até a próxima!

BACKUP AUTOMATIZADO DO SQL SERVER COM AZURE VIRTUAL MACHINE

Olá Pessoal!

Um dos benefícios de criar uma instância do SQL Server em uma máquina virtual no Microsoft Azure são as integrações nativas disponíveis no painel do Azure, como é o caso do recurso de Backup Automatizado (Automated Backup). Vamos explorar melhor esse recurso com a demonstração abaixo utilizando uma máquina virtual com o SQL Server 2017.

O SQL Server também está disponível no Azure como IaaS (Infrastructure as a Service), sendo assim, existem alguns modelos para contratação e dentre eles, a opção de criar a máquina virtual a partir de uma imagem que contém a edição desejada do produto.

No processo de criação da máquina virtual, diversos itens devem ser preenchidos até chegar a etapa de configuração do SQL Server, na qual iremos configurar o Backup Automatizado pelo painel do Azure.

Antes de avançar no recurso do Backup Automatizado, vamos relembrar quais opções a Microsoft disponibiliza atualmente para realização do backup em instâncias SQL Server rodando em Azure Virtual Machines (IaaS):

Como foi citado acima, é possível que backups regulares do banco de dados sejam configurados utilizando o armazenamento do Azure Blob Storage, entretanto, para que esse recurso funcione é necessário que a extensão do SQL Server IaaS Agent esteja instalada no host que contém a instância do SQL Server e essa extensão só é compatível para deploys de VMs a partir das imagens disponíveis na galeria de recursos do Azure. A extensão do SQL Server IaaS Agent não será compatível se você instalar o SQL Server em uma máquina virtual do Windows Server somente com o sistema operacional ou se for utilizado um VHD de uma VM do SQL Server personalizada.

Veja na imagem abaixo a extensão SqlIaasExtension.

Voltando a tela de configuração do Backup Automatizado, essa opção deve ser habilitada no menu de configurações do SQL Server ainda no processo de setup do host.

É possível perceber que as seleções disponíveis são bem simples e existe uma opção bem relevante, a “Janela de tempo de backup (horas)”, na qual é definido o tempo máximo disponível para que o backup seja realizado.

Uma vez que a configuração foi concluída, um resumo é apresentado antes de iniciar o processo de criação do host, que deve demorar alguns minutos. Note que uma nova conta de armazenamento foi criada no processo de configuração do host.

Com a máquina criada e a instância do SQL Server em funcionamento, é só uma questão de tempo até que recurso do Backup Automatizado comece a realizar os backups e armazenar os arquivos no Azure Blob Storage. Para verificar os arquivos de backup, vá até a conta de armazenamento utilizada no processo de criação do host e selecione a opção do armazenamento de Blobs.

O contêiner com o nome “backupcontainer” será criado no processo de configuração do Backup Automatizado, é nele que os arquivos de backup do SQL Server são armazenados.

Para leitura dos dados do Azure Storage também pode ser utilizado a ferramenta Microsoft Azure Storage Explorer, que permite uma melhor visão e gerenciamento do armazenamento.

Vamos ao SSMS para buscar através de uma Query as informações dos backups que foram realizados até o momento, veja na imagem abaixo as informações relacionadas ao armazenamento.

Caso deseje alterar as configurações do Backup Automatizado após a host estar criado, basta acessar a opção “Configuração do SQL Server” no painel da máquina virtual.

Ao acessar esse menu, uma série de opções de configuração da instância do SQL Server estarão disponíveis e dentre elas, o Backup Automatizado.

 

Existem limitações e requisitos não abordados aqui que devem ser atendidos para utilização do Backup Automatizado, vejam na documentação oficial todos esses importantes pontos antes da implementação.

Informações adicionais:

https://docs.microsoft.com/pt-br/azure/virtual-machines/windows/sql/virtual-machines-windows-sql-server-iaas-overview#get-started-with-sql-vms

https://docs.microsoft.com/pt-br/sql/relational-databases/backup-restore/sql-server-backup-and-restore-with-microsoft-azure-blob-storage-service?view=sql-server-2017

Até a próxima!