Integration Runtime: Self-Hosted na prática
Meu primeiro artigo de Data Factory, olha só, quem diria eu falando de Microsoft! Nesse vamos falar sobre o processo de cópia de dados fora da rede Azure (nesse caso simulo com uma rede AWS mas poderia ser um ambiente On Premises para sua migração de dados pra Cloud), e com Data Factory e sua ferramenta parceira o Integration Runtime vamos trazer pra dentro do Lake Cloud, dados de uma tabela Oracle.
Antes de continuar, já deixa a palminha no post ae, compartilha e ajuda a gente, teve custo esse material viu, se puder dar essa força agradeço muito!
Estou com o conteúdo de Azure apurado no momento, passei algumas semanas estudando para a prova DP-203 da Microsoft e sou oficialmente um Certified Data Engineer Associate…
Acho que dá pra falar sobre o assunto com uma propriedade, então vamos nessa. Nesse cenário eu queria simular o mais próximo possível de uma cópia de dados do ambiente On Premisses para a Cloud, usei a AWS para simular o ambiente On Premisses e Azure pra Azure mesmo…
Não vou entrar em muitos detalhes de como criar os ambientes, só vou mostrar o desenho de arquitetura, caso contrário esse post ficaria grande pra c… Segue abaixo o desenho vou dar uma explicada nele.
Desculpem se o desenho estiver pequeno mas é mais ou menos o seguinte o cenário:
Lado Azure
Foram configurados basicamente 6 coisas:
- Uma VNET que no meu caso usei a rede 10.0.0.0/16
- Uma subnet nessa mesma VNET com a classe de rede 10.0.0.0/24
- Um internet Gateway para essa rede sair pra internet
- Um Network security group onde libero a porta 8050 do Datafactory para acessos externos (na subnet criada)
- Um Storage Account ADLS Gen2 (na subnet criada)
- Um container chamado "names" nesse Storage Account citado acima.
Lado AWS (Simulando On Premisses)
Também configurei pouquissimas coisas a fim de realizar só o teste de comunicação mesmo.
- Uma VNET que no meu caso usei a rede 192.168.0.0/16 até pra que não ficasse parecido com a da Azure
- Uma Subnet nessa VNET de cima usando a rede 192.168.0.0/24
- Um internet Gateway para essas maquinas sairem pra internet
- Um Network security group onde libero o que vem da Azure na porta 8060 (que é a porta do Integration Runtime) a porta do Oracle 1521 (vindo da minha maquina mesmo) e a porta do Remote Desktop 3389 (também vindo da minha maquina)
- Um servidor Windows Server 2019 onde configurarei o Integration Runtime, ele precisa ter no minimo 4 cores e 8 GB de RAM. (Na subnet criada)
- Um servidor RDS Oracle Standard basicão mesmo, com a menor configuração possível. (Na subnet criada)
Como disse vou partir do princípio que você sabe configurar ambos os lados, o papo aqui é o Integration Runtime
Um Overview Rápido de Data Factory
O Data Factory é uma ferramenta da Azure onde consigo fazer Pipelines de dados, de diversas fontes tendo mais de 70 conectores, Oracle, Hadoop, Sales Force, IBM, Cassandra e muitos outros. Ele pode fazer o tratamento desses dados de forma muito parecida com o Apache Nifi, já realizando a fase de transformação do dado, tanto que a Microsoft não diz que as atividades dele são de ETL e sim de ELT (Extract, Load and Transform).
O ponto bem diferente do Apache Nifi que é uma ferramenta que geralmente eu uso pra fazer isso, é que ele precisa meio que de um agente intermediário pra fazer o trampo esse é o Integration Runtime, vou tentar explicar de forma rápida o caminho usando de exemplo o Oracle que é o nosso caso:
- Você tá no Data Factory e precisa pegar os dados do Oracle
- Você vai precisar de um Linked Service que vai se conectar ao destino ou origem (no caso do Oracle origem)
- Esse Linked Service precisa de um agente intermediário chamado Inegration Runtime que otimiza as requisições do Data Factory, usa meio que uma conexão com o destino otimizada também debaixo dos panos e traz o dado. Porem esse integration RunTime pode ser de 4 formas (falo delas mais a diante)
- Com essas dependências criadas eu crio meu pipeline, no caso do nosso exemplo vamos usar o "copy data", a ideia é usar o "source" Oracle e o "Sink" o ADLS Gen 2 (que por sua vez também precisa de um linked service, mas não precisa de um Integration Runtime, ele é mais usado em ferramentas que não são Azure como o caso do Oracle)
- Manda o play no cara e se tudo estiver OK a magica acontece e o conteúdo da tabela do Oracle vira um Parquet no ADLS gen 2 como sugere o exemplo.
Dei um overview meio que já explicando o que vamos fazer, então vamos mostrar onde entra o Integration Runtime nesse rolê.
Instalando o Self Hosted Integration Runtime
Como disse anteriormente, o Integration Runtime tem 3 modos:
- AutoResolve: Sempre que criamos o Data Factory por padrão esse cara é criado, ele não tem nenhum tipo de maquina atrelada a ele (serverless)e seu uso é pago AD-HOC, ou seja, conforme você usa-lo. Usado para executar fluxos de dados, movimentação de dados, atividades externas e de pipeline em uma computação sem servidor totalmente gerenciada no Azure.
- Self-Hosted: É configurado um Servidor, podendo estar internamente na Azure ou na rede remota, depende da topologia de rede criada, por exemplo, uma interligação de redes on-premisses e cloud com expressRoute onde a rede destino é a continuidade da rede origem, por isso não precisa estar localizado remotamente.
- Linked Self-Hosted: Você pode usar um tempo de Integration Runtime auto-hospedado existente em outro recurso. Dessa forma, você pode reutilizar sua infraestrutura existente onde o tempo de execução de integração auto-hospedado está configurado. Vamos supor que já tenho um host Windows que tem um IIS por exemplo e quero usa-lo também como IR.
- Azure SISS: Caso eu vá extrair dados de um SQL Server essa é uma boa opção pois já fala no protocolo do banco, pode trazer uma otimização considerável.
No print abaixo tenho 2 dos tipos, o AutoResolve e o Self-Hosted configurados.
Vou mostrar agora como rescue-ir como mostra o print acima.
- No Data Factory vá no icone da maletinha (Manage) em seguinda no menu da lateral clique em 'Integration Runtime' e clique em New.
- Ele vai exibir 2 meios possíveis de IR inicialmente, o SISS e o Self-Hosted
- Agora sim ele vai abrir os outros possíveis modos listados pra você
- Agora devemos atribuir um nome ao IR (no meu caso chamei de oracle-ir), coloque uma descrição se quiser e clique em continuar.
- Agora ele vai mostrar um link de download e 2 chaves
AGORA UM PONTO IMPORTANTE E QUE TALVEZ DE DEIXE PUTO É: O INTEGRATION RUNTIME SÓ RODA EM WINDOWS!
O Integration Runtime precisa de uma maquina com pelo menos 4 cores e 8GB de RAM e pode rodar (segundo a documentação Microsoft) nos seguintes sistemas Operacionais:
- Windows 8.1
- Windows 10
- Windows Server 2012
- Windows Server 2012 R2
- Windows Server 2016
- Windows Server 2019
- Windows Server 2022
No meu caso Instalei um Windows Server 2019 na AWS (Não achei um Windinho básico), então sem sofrer, vamos pro Next, Next, Finish! O ultimo passo te gerou uma tela assim:
Copia o link do "Download and Install" vai lá no Windows onde você vai instalar cola no navegador e clica pra fazer o Download.
Conforme você for instalando, sem muita novidade, uma hora você chegara nessa tela aqui:
- Pegue uma das chaves que foram geradas no Datafactory e clique em Register. Vai aparecer seu registro com sucesso conforme exibido abaixo
- O Serviço vai ser inicializado e e vai escutar na porta 8060, como falei lá em cima é necessário liberar o acesso, no meu caso liberei na porta publica, mas numa simulação real de ExpressRoute bastaria liberar a rede privada desde que origem e destino se falem.
Agora com o cara configurado vamos ver no lado do Data Factory
Fazendo uso do Integration Runtime no Data Factory
Agora com nosso amigo configurado vamos botá pra torá! Vou usar um Pipeline básico onde coloquei uma tabela chamada names em um schema chamado TRESCUE em um Oracle RDS, se liga.
Vou agora mostrar como criei o Linked Service com o Oracle usando o Integration Runtime "oracle-ir".
Tenho também um Storage Account onde vou gravar os caras, criei um Linked Service, nem vou entrar no esquema da configuração pois não vem ao caso, é bem simples e só ia tomar tempo, ela vai ser nosse destino.
Configurando o Pipeline de Copia
Com os Linked Services setados (Oracle e Storage Account) vou trazer os dados em 2 formatos, um em CSV e outro em Parquet, ambos vão estar no mesmo diretório do Storage Account.
No data factory criei 3 Datasets:
- namesCSV: Saída do arquivo no formato CSV no Storage Account
- NamesOracle: Origem da Tabela Oracle TRESCUE.NAMES no banco RDS Oracle
- NamesParquet: Saída do arquivo no formato Parquet no Storage Account configurado.
É bom configurar os Datasets antes porque depois você só os seta no "Source" e "Sink" dos Modulos "Copy data" e falando neles seguem o exemplo do Parquet:
OBSERVAÇÃO IMPORTANTE: A geração do CSV por se tratar de um arquivo texto comum vai de boa, a geração do Parquet, por ser tratar de um binário precisa do Java (JRE/JDK). Eu fiz a instalação do JRE da Oracle e como agora os recursos são pagos, não funcionou. Optei por instalar o OpenJDK no servidor Windows do Integration Runtime e cantou lindão.
Não coloquei nenhuma firula ou transformação, é apenas trazer o conteúdo da tabela para o ADLS. Com tudo configurado rode o debug e veja a magica acontecer:
Agora vamos ver nossos arquivos gerados no ADLS Gen2, mandei gerar os 2 arquivos no container "names".
É bem legal ver a otimização que o Parquet gera, pois além de uma performance melhor que o CSV, ele ficou com 104MB contra 296MB do CSV.
Bom por hoje era isso, espero que tenham curtido, deixa a palminha ae, compartilha pra dar uma fortalecida, e logo vem um próximo falando sobre Life Cycle Management no ADLS Gen2.
Abraços e até o próximo!
Anselmo Borges!
