O procedimento para realizar o backup log também é extremamente simples. Basta que o banco atenda as particularidades mencionadas anteriormente.

1. Para fazermos o backup, temos que selecionar com o botão direito o nome do banco de dados > Tarefas > Fazer Backup
   
2. Será aberta a mesma janela do backup full. Contudo, nesse caso, iremos realizar algumas alterações, ficando dessa forma:
   
3. Em azul – Banco de dados: Neste campo, informamos o nome do banco que será feito o backup.
   Em verde – Tipo de Backup: Neste campo, informamos o tipo de backup que desejamos realizar. Como neste caso iremos realizar o backup log, portanto, iremos selecionar “Log de Transações”
   Em vermelho – Diretório: Neste campo, informamos o local em que queremos armazenar nosso arquivo de backup. Assim como no backup full, iremos armazenar em Program Files\Microsoft SQL Server\MSSQL15.InstanceName\MSSQL\Backup.

IMPORTANTE: Diferente do backup full, a extensão usada para o backup log é a .trn. Assim como exemplo da imagem acima, sublinhado em vermelho.

Dentre os três backups apresentados, o backup diferencial é o que menos é usado. Porém, isso não significa que ele não seja importante e, da mesma forma que os outros, é usado outro cenário. Seu nome já nos dá uma dica de qual é o seu propósito e como ele funciona.

O backup diferencial faz o backup do banco desde o último backup full executado. Isso é chamado de base do diferencial.

Para ficar mais simples de entender, podemos usar a imagem abaixo:

Todo o contorno da linha preta (incluindo as partes em vermelho e verde) – É o nosso banco de dados.

Parte vermelha – É o backup full. Assim como mostrado na imagem abaixo, efetuamos o backup do banco db_sistema no dia 04 de fevereiro de 2022 às 23:57 horas.

Parte verde – É o backup diferencial, que pega a diferença entre o último backup full realizado e o estado recente do banco de dados.

 

Ou seja, o backup diferencial tende a ser mais rápido, isso porque ele não faz o backup do banco de dados inteiro, somente da diferença.

Então, imagine que vamos rodar o backup diferencial às 10:00 horas do dia 05 de fevereiro de 2022. Ele vai fazer o backup do que foi alterado após às 23:57 horas do dia 04 de fevereiro de 2022 até às 10:00 horas do dia 05 de fevereiro de 2022.

Partindo do pressuposto que o seu banco de dados está com os backups full e log, ou até mesmo o diferencial, em dia, não há motivos para se preocupar exceto um, que pode lhe causar uma imensa dor de cabeça e atrapalhar o fluxo do seu negócio.

Como dito anteriormente, o banco de dados está suscetível a erros ou até mesmo situações em que são inseridos, alterados e/ou apagados determinados dados de forma equivocada. Felizmente, o seu banco está com os backups em dia. Então, fique feliz, pois há salvação e é extremamente possível recuperá-lo antes do erro ou ponto de falha, perdendo a menor quantidade de dados possível.

Nesta parte do artigo, vamos aprender como recuperar os backups do banco de dados, conseguindo reverter alguns desastres e erros.

Primeiro, é importante ressaltar que, uma vez que o banco e seus dados foram comprometidos, o mesmo terá que ser sobrescrito, ou seja, revertido para um estado anterior.

Para os exemplos, iremos utilizar o AdventureWorks2019 que é gratuito e disponibilizado pela Microsoft para fins de testes e aprendizados.  Conseguimos baixar o arquivo .bak no seguinte link: Bancos de dados de exemplo do AdventureWorks – SQL Server | Microsoft Docs

1. Na sua instância SQL Server, clique com o botão direito em Bancos de dados > Restaurar Banco de Dados
   
2. Será aberta a seguinte tela.Note que não há nenhum arquivo de backup escolhido. Para escolher o arquivo, basta selecionarmos os componentes marcados em vermelho, conforme as imagens abaixo:
   
   
3. Nesta tela, temos que ter atenção em alguns pontos:
   • Primeiro: É importante informar no campo “Local do Arquivo de Backup” (linha azul) o diretório em que está armazenado o arquivo .bak do banco de dados que você está tentando restaurar. Sem isso, o SQL não saberá qual arquivo será restaurado e o restore falhará. No meu caso, baixei o arquivo do banco AdventureWorks e coloquei no diretório padrão de backups do SQL, mas o local onde irá armazená-lo fica a seu critério.
   • Segundo: Selecionar o arquivo de backup que deseja restaurar (linha vermelha). Para nosso exemplo, iremos selecionar o bak;
   • Terceiro: Concluído os dois passos anteriores, podemos clicar em “OK” (linha verde) e OK novamente na próxima tela;
     

4. Feito isso, você deve receber a tela da seguinte maneira. Note que ele reconheceu o dispositivo em que estamos pegando o arquivo de backup (C:\Program Files\Microsoft SQL Server\MSSQL15.CARLOSMENDES\MSSQL\Backup\AdventureWorks2019.bak), o nome do banco de dados (AdventureWorks) e a data na qual foi feito o backup (segunda-feira, 15 de junho de 2020 às 20:26:36).
   
5. Caso quisessemos, poderíamos alterar o nome do banco de dados e restaurá-lo com outro nome, mas nesse caso não será necessário.
6. Por fim, basta clicar em “OK” e você deve receber a seguinte mensagem de sucesso, conforme a imagem abaixo:
   
7. Agora, conseguimos ver que o banco está em nossa instância SQL foi recuperado com êxito.
   Obs.: Caso não apareça o banco, basta clicar com o botão direito em Banco de dados > Atualizar (Refresh) e ele deverá aparecer.
   

Como falamos antes, a recuperação de um banco de dados visa, acima de tudo, voltar o banco ao estado antes da falha ou do erro que aconteceu. Acontece que, dependendo do tamanho do banco de dados e de quando foi feito o último backup full, a perda de dados pode ser gigante. Para entender melhor, vamos montar o cenário, aplicando com a prática.

Supondo que meu banco restaurado há pouco, AdventureWorks, seja meu banco de produção, extremamente crítico, com diversas transações e processos em execução. Eu faço o backup full dele diariamente, durante a madrugada, pois o banco é grande e demora para concluir o backup. Então, eu executo o backup full do meu banco de dados às 02:00 horas.

Imagine que este banco está recebendo conexões e processos normalmente. Em um dado momento, preciso que seja criada a tabela “funcionário”. Sendo assim, executo a DDL de criação da tabela e começo a popular a mesma, conforme o exemplo abaixo:

 

Agora, iremos dropar a tabela criada anteriormente, com o comando DROP TABLE. Note que ao executar o comando select na tabela “funcionário”, recebemos o erro do Database Engine informando que a tabela não existe no banco.

Ou seja, tínhamos criado uma tabela chamada “funcionário” e populamos ela com dados. Mas, após o drop, ela não existe mais. Você pode até estar pensando: “Ok, só precisamos restaurar o backup full do banco de dados”. Contudo, a tabela “funcionario” foi criada após o backup full. Se restaurássemos, não teríamos a tabela de volta.

Por sorte, fomos precavidos e rodamos o backup log após a criação da tabela e, com ele, conseguimos restaurar o banco de dados até o momento em que o drop table ocorreu. Primeiro, temos que ter em mente que, para restaurar um backup log, devemos primeiro restaurar o último backup full que foi executado, e após isso, aplicar os arquivos de log até o momento em que a tabela foi apagada. Então vamos lá!

Vamos restaurar um backup full, da mesma forma que restauramos o banco AdventureWorks2019, mas dessa vez, ao invés de fazermos via tela gráfica, faremos via script. Isso porque nesse caso, como iremos restaurar um log por cima, precisamos nos atentar em alguns pontos e adicionar alguns comandos.

1. Seguindo o passo a passo para recuperar um backup full, antes de clicar em “OK”, vamos clicar em Script > Janela do Editor de Nova Consulta
   
2. Com isso, teremos o seguinte script:
   
   Segue script:
   USE [master]
   ALTER DATABASE [AdventureWorks2019] SET SINGLE_USER WITH ROLLBACK IMMEDIATE /* –> Estamos alterando o banco de dados para usuário único, fazendo com que asconexões abertas com o banco que será restaurado sejam encerradas, e as transações em andamento sejam revertidas; */
   RESTORE DATABASE [AdventureWorks2019] /* –> Comando para restaurar o banco de dados (Informa o banco de dados que vamos restaurar — banco destino); */
   FROM  DISK = N’Backup Path’ /* –> Informa qual é o backup que está sendo resturado; */
   WITH  FILE = 1, /* –>  Informa a partir de qual datafile será realizado o restore (Quando = 1, significa que será usado o datafile primário (primary) — .MDF); */
   NOUNLOAD,
   NORECOVERY, /* –> Permite que mais sequências de backup sejam restauradas; */
   REPLACE, /* –> Significa que o banco de dados será sobrescrevido; */
   STATS = 5 /* –> Porcentagem de progresso que será informada durante o restore (Quando = 5, significa que o SQL mostrará a porcentagem de progresso do restore de 5 em 5); */
   GO
3. Vale lembrar que é extremamente importante colocar a opção Isso porque ela vai permitir que posteriormente, consigamos restaurar o backup log após o backup full.
   1. Como vimos acima, o restore foi executado com sucesso. Sendo assim, o banco de dados que estamos recuperando, AdventureWorks2019, deverá ficar com o status “Restoring” (Restaurando). Dessa forma:
      
   2. Muito bem, agora temos que restaurar o backup log. Para fazermos isso, temos que clicar com o botão direito em Tarefas > Restaurar > Log de Transações
      
      
   3. Com isso, você deverá ver a seguinte tela. Para escolhermos o arquivo de log que vamos restaurar, devemos marcar o checkbox “Do dispositivo:” e clicar no quadrado marcado em vermelho e depois em “Adicionar” como mostra as imagens abaixo:
      

    

4. Assim como na recuperação do backup full, temos que escolher o arquivo que iremos restaurar. Mas dessa vez, iremos escolher o backup log que fizemos anteriormente, logo após criarmos a tabela “funcionario”. Após selecionado clique em “OK” e depois em “OK” novamente.
   
   1. Feito isso, clicaremos em Script > Ação do Script para a Nova Janela de Consulta
      
   2. Assim, o script deverá aparecer em uma nova janela de edição de query:
      
      Note que foi aberto em uma sessão diferente. É importante que você copie e cole o script na mesma sessão em que você rodou o restore do backup full. Desta vez, sem a opção norecovery. Isso porque queríamos resgatar apenas este backup log. Contudo, quando for restaurado mais de um backup log, sempre deverá ter a opção norecovery, deixando apenas o último arquivo que será restaurado sem essa opção. Dessa forma, o Database Engine entende que não há mais sequências de backup para serem restauradas, e que o banco pode enfim entrar em uso.
   3. Por fim, quando executado com sucesso, deverá receber algo como isto:
      
   4. Se você verificar o banco de dados AdventureWorks2019, ele não está mais com o status “Restoring” (Restaurando), estando finalmente online novamente.
      
   5. Agora, chegou o momento de verificarmos se a tabela “funcionario” que havia sido excluída, está de volta, executando o seguinte script:
      
      USE AdventureWorks2019
      GO
      SELECT *FROM FUNCIONARIO
   6. Podemos notar que a tabela está no banco de dados novamente e com os registros que foram inseridos logo após sua criação.
      
      Assim, podemos ver a importância de sempre estar com o backup full e log em dia. Isso porque, quando esses eventos de desastre no banco de dados surgirem, será possível recuperar o que foi perdido de forma mais assertiva e pontual. Mesmo tendo suas particularidades, todos os tipos de backup (full, log e diferencial) possuem o mesmo objetivo e ajudam a garantir a segurança das informações em caso de comprometimento da integridade do banco de dados. Além disso, também vimos que é possível recuperar estes backups, retornando o estado do banco no momento específico antes de algum erro cometido. Por isso, mantenha sempre seu ambiente SQL Server com os backups em dia, para que em caso de falhas ou outros problemas que interfiram no seu banco de dados, a margem de perda de dados seja a menor possível.

    

Vivemos em uma época em que, com o avanço rápido da tecnologia de um modo geral – e especialmente da tecnologia de coleta de dados -, muito se fala sobre o uso de dados por parte dos mais diversos tipos de empresas. Todos os dias aparecem novas informações, reportagens, eventos e pesquisas sobre esse tema; às vezes, é tanta coisa que fica difícil de acompanhar. Você provavelmente já ouviu falar sobre a importância do uso de dados para o desenvolvimento do seu negócio, mas pode ser que não tenha nem ideia de como começar a utilizá-los como uma ferramenta para o sucesso da tomada de decisões e desenvolvimento de novas estratégias. Para compreender o valor da inteligência de dados, primeiro, é preciso compreender o valor que essas informações podem agregar.

 

Por que dados são tão importantes?

Ainda há pouco tempo, a tomada de decisões de negócios nas empresas era muito mais realizada pelo feeling, pelo achismo. Confiar no achismo pura e simplesmente, mesmo tendo um montante de informações disponíveis, faz com que as resoluções de quaisquer questões sejam realizadas de maneira ineficiente; resultando em tomadas de decisões importantes baseadas em dados imprecisos. As coisas mudaram quando concluiu-se que os dados conseguem dar respostas muito mais precisas para os problemas que a empresa pode ter com seus produtos, atendimento e estratégia, indicando possíveis rumos a serem seguidos. Se muito bem trabalhados e interpretados, os dados conseguem trazer valor para qualquer organização, independente do segmento e porte.

O trabalho de análise, qualificação e seleção  dos dados extraídos pela sua empresa pode fazê-lo encontrar a informação que você precisa para solucionar um problema em seus mais diversos aspectos. Por exemplo, por meio da interação dos clientes por redes como o WhatsApp, LinkedIn, Instagram ou qualquer outro meio de comunicação, é possível aplicar técnicas de mineração de dados; melhorando assim produtos, serviços e, consequentemente, a experiência do cliente. “Por isso que os dados são tão valiosos, principalmente quando respondem perguntas de negócios”, afirmou o Roxpert, Romerito Morais, engenheiro de dados e análise.

 

A Cultura Data Driven

De forma sucinta, a Cultura Data Driven é quando uma empresa incorpora o uso de dados para realizar tomadas de decisões em seus negócios. Baseia-se em uma longa jornada, desde a compreensão do seu negócio, captura dos dados, sua aquisição, integração, aperfeiçoamento e análise completa por parte das mais diversas áreas da empresa. Trata-se de um extenso processo  de transformação cultural de qualquer organização, para que os dados obtidos no dia a dia sejam convertidos  em informações de alta relevância e utilizados estrategicamente. Dessa forma, todas as divisões da sua empresa conseguirão responder às perguntas e tomar as melhores decisões.

Porém, para que a Jornada Data Driven possa agregar os resultados esperados, é preciso compreender suas necessidades para traçar objetivos a serem atingidos e, quando falamos de empresas, inevitavelmente estamos falando de compreender pessoas, processos e tecnologia. É preciso haver um investimento massivo em cada setor para que as pessoas recebam treinamento especializado para saberem lidar com dados em seus mais diferentes aspectos.
Saber identificar esses pontos de melhoria e encontrar as respostas por meio do big data analytics pode ser um grande desafio, devido ao enorme montante de informações que são produzidas diariamente por meio dos mais diversos canais. Portanto, contratar mão de obra especializada o suficiente para extrair os insights necessários é uma operação demorada e de alto custo. Em contrapartida, fazer com que uma ou mais pessoas inexperientes efetuem todo o trabalho de coleta, armazenamento e análise sem ter conhecimento a fundo de processamento de dados, controle de qualidade e business pode levar a empresa a ter prejuízos irreversíveis.

 

 

E é aí que a Rox entra!

A Rox Partner tem como propósito transformar todos os dados das empresas em ativos. Para isso, é garantida a construção de arquiteturas em nuvem ou on-premises com  governança de dados, para que todo o processo de engenharia e ciência de dados sejam suportados. O processo da Jornada Data Driven da Rox é 100% realizado por  especialistas em Big Data e Analytics, divididos em diversas equipes de trabalho específico, para que seus dados sejam perfeitamente transformados nas informações que seu negócio precisa.
De acordo com o Roxpert Romerito Morais, o processo consiste, primeiramente, em um trabalho de investigação. “Estamos sempre falando muito de dados, mas geralmente o maior problema das empresas não é a ausência de dados. O problema é  que esses dados estão todos espalhados pela empresa, sejam em planilhas eletrônicas, ERPs, CRMs, sistemas de e-commerce etc.”, explica. “Por isso, mapeamos os processos, identificamos as métricas de avaliação, quais os principais problemas que ela tem enfrentado e o que ela espera como resultado”.

Após todo o mapeamento dos negócios, é iniciado o trabalho de mapeamento das fontes de dados, conversa com pessoas chave de dentro da organização e definição de quem será o responsável pelo projeto. A equipe de engenharia de dados vai coletar os dados mapeados de todos os locais em que a empresa os consome e os mesmos serão armazenados em data lakes. Então, estes dados são submetidos a um rigoroso processo de controle de qualidade, em que são filtrados, enriquecidos, refinados e catalogados.
Após esse controle, os dados são armazenados em data warehouse e separados por data marts que, por sua vez, são dados organizados pelos setores da empresa na qual vão ser usados para responder às perguntas em questão. Substancialmente, a Rox se dispõe a realizar todo o processo da jornada: aquisição e transformação dos dados até deixá-los ideais para que o cliente possa tomar decisões e encontrar as melhores soluções.

 

Fique por dentro das notícias por meio das nossas redes sociais:

 

 

Ingredientes:

 

• OS Linux (ubuntu, fedora, centos, kubuntu, debian, outros)
• Docker (versão 20.10.2 ou superior)
• Container PostgreSQL (versão 13.1 ou superior)
• Container Streamsets Data Collector (versão 3.13.0 ou superior)
• Navicat (versão 15.0.0 ou superior)
• Arquivos Tabulares (.csv)

 

🍲 Modo de Preparo: Container PostgreSQL (versão 13.1 ou superior)

 

Primeiramente baixe o container pelo terminal:

 

$ docker pull postgres

 

Após baixar a imagem podemos ver ela na sessão de imagens do docker:

 

$ docker images | grep "postgres"

 

Agora vamos iniciar o serviço do postgres

 

$ docker run --name some-postgres -e POSTGRES_PASSWORD=mysecretpassword -d postgres

 

Vamos usar dessa forma, mais caso você queira mudar a senha fique a vontade. para saber se o container ta operativo escreva. o comando abaixo, ele vai mostrar informações de status, portas etc..

 

$ docker ps -a --format "table {{.ID}}\t{{.Image}}\t{{.Names}}\t{{.Status}}\t{{.Ports}}"

Agora vamos procurar o endereço de ip desse container para fazermos a conexão via ferramenta de administração de banco de dados. porém é precisa saber o “CONTAINER_ID” ele é o identificador do container em execução. você consegue descobrir essa informação usando o comando anterior. o próximo comando vai mostrar todas as configurações do container em execução.

 

$ docker inspect CONTAINER_ID

A saida do comando no terminal vai exibir dados no formato .JSON contendo todos os parâmetros do container, localize no final das linhas o IPAddress ou você pode obter de forma rápida usando usando o comando.

 

$ docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' CONTAINER_ID 

Com o ip em mãos vamos nos conectar usando a ferramenta de administração de banco de dados chamada Navicat porém você pode usar outras ferramentas como: dbeaver, pgadmin ou qualquer outra ferramenta na qual você consiga se conectar ao PostgreSQL. então vamos aos dados da conexão com o banco de dados:

 

host: ip CONTAINER_ID
port: 5432
user: postgres
password: mysecretpassword

mais caso você queira entrar via linha de comando você deve matar o container em questão e usar o comando:

 

$ docker run -it --rm --network some-network postgres psql -h some-postgres -U postgres

Dentro da de linha de comando vamos criar nosso usuário, banco de dados e garantir permissão a todos os recursos da instancia. voce pode executar a sequencia de comandos a seguir via linha de comando ou query pelo seu gerenciador favorito.

primeiro vamos criar o nosso banco de dados, vou usar o nome sdc.

 

CREATE DATABASE sdc;

vou definir o mesmo nome que dei ao banco de dados para o usuário.

 

CREATE USER sdc WITH ENCRYPTED PASSWORD '102030';

garantindo altos privilégios.

 

GRANT ALL PRIVILEGES on DATABASE sdc TO sdc;

criando o esquema.

 

CREATE SCHEMA "streamsets";

Por fim vamos criar nossa tabela, essa é uma etapa muito importante pois vamos preparar a tabela para receber os dados dos arquivos. nessa tabela vamos definir a estrutura da mesma forma como está nos arquivos, com o mesmo nomes de campos e quantidades de colunas. vamos criar todos os campos com o tipo de dados varchar,  vou fazer isso para não ter problemas durante a inserção de dados via StreamSets.

 

CREATE TABLE "streamsets"."cardata" (
   "Processing_Date" varchar(255),
   "Car_Name" varchar(255),
   "Year" varchar(255),
   "Selling_Price" varchar(255),
   "Present_Price" varchar(255),
   "Kms_Driven" varchar(255),
   "Fuel_Type" varchar(255),
   "Seller_Tyoe" varchar(255),
   "Transmission" varchar(255),
   "Owner" varchar(255)
 );

bom essas são as configurações necessárias nesse container, agora vamos salvar as alterações  nesse container usando o comando commit.

 

$ docker commit CONTAINER_ID nome:tag

Passamos o CONTAINER_ID e o nome desejado com tag, no meu caso eu coloquei como: docker commit aaeb2b4ef100 postgres-configurado:latest. lembrando que toda alteração que você fizer no container precisa ser comitada para que elas serem permanentes, caso o contrário se você matar o container ou por algum outro motivo ele cair, você perde tudo aqui que alterou dentro dele.

Prontinho agora que fizemos todas as configurações necessárias vamos ao próximo passo.

 

 

 

🍲 Modo de Preparo: Container Streamsets Data Collector (versão 3.13.0 ou superior)

Para essa receita vou usar a versão 3.13.0, mas fique a vontade para testar essa receita em outras versões.

 

$ docker pull streamsets/datacollector:3.13.0-latest

após baixar a imagem podemos ver ela na sessão de imagens do docker:

 

$ docker images | grep "stre"

feito isso vamos iniciar o serviço do sdc com o comando:

 

$ docker run --restart on-failure -p 18630:18630 -d --name sdc streamsets/datacollector:3.13.0-latest

esse serviço vai ficar escutando na porta 18630, se você abrir o navegador e digitar localhost:18630 ele vai abrir na tela de login e senha.

 

usuário: admin
senha: admin

após isso vamos fazer algumas mudanças nesse container para que possamos prosseguir, vamos entrar no modo de linha de comando.

 

$ docker exec -it CONTAINER_ID /bin/bash

o único arquivo que vamos editar fica em /etc/sdc/form-realm.properties abra ele com o vi, após isso localize a linha que é similar a:

 

admin:   MD5:21232f297a57a5a743894a0e4a801fc3,user,admin

vamos adicionar mais 2 permissões a esse usuário, pressione shift + i e adicione creator,manager, deve ficar assim:

 

admin:   MD5:21232f297a57a5a743894a0e4a801fc3,user,admin,creator,manager

 

Lembrando que estamos alterando um usuário existente que é o Admin, mas caso precise adicionar um usuário com o seu nome e senha podemos disponibilizar esse conhecimento em outro material aqui no blog.

 

Após as alterações no arquivo /etc/sdc/form-realm.properties pressione esc para sair do modo de inserção, salve os dados inseridos e saia do arquivo usando as teclas shift + : e digite wq. para sair do modo de linha de comando do container pressione a sequência de teclas ctrl + p + q cuidado para não matar o container, se aparecer assim “read escape sequence” quer dizer que você sai com segurança do container. após essas alterações no container vamos reiniciar ele para validar as alterações que fizemos.

 

$ docker restart CONTAINER_ID

 

após isso vá no navegador e digite: localhost:18630 entre com o usuário e senha: Admin

 

se tudo deu certo você vai cair na interface de trabalho do streamsets. clique em: CREATE NEW PIPELINE

 

 

Coloque um nome de sua preferência para o pipeline e depois clique em Save. agora vamos instalar  o componente responsável pela conexão com o PostgreSQL, clique onde a seleção está na cor vermelha.

 

 

após isso vai aparecer uma lista de componentes procure por jdbc na caixa de pesquisa.

 

1.selecione o checkbox

 

2.instalação

 

 

após clicar em instalar vai aparecer outra opção:

 

Clique em Restart Data Collector vai demorar uns 5 segundos e após isso vai aparecer a tela de login, faça o login novamente.

 

E por último vamos criar uma pasta no diretório /opt chamada /opt/data/input é aqui que nossos arquivos vão residir. vamos mais uma vez entrar via linha de comando no container., vamos usar nesse comando a flag –user root ele é necessário para criarmos a pasta no diretório do linux.

 

$ docker exec -it --user root CONTAINER_ID /bin/bash

Vamos a criação das pastas.

 

$ mkdir /opt/data && mkdir /opt/data/input

 

O diretório input vai ser usando para montarmos um volume externo nele com os arquivos (.csv)

 

após isso vamos sair do modo de linha de comando pressionando as teclas ctrl + p + q cuidado para não matar o container, se aparecer assim “read escape sequence” quer dizer que você sai com segurança do container.

 

vamos gravar as mudanças nesse container usando o comando commit

 

$ docker commit CONTAINER_ID nome:tag

Após isso vamos matar o container e remover ele da lista de execução

 

$ docker stop CONTAINER_ID && docker rm CONTAINER_ID

essa ação foi necessário para podermos criar um novo container. usando a flag -v montamos a pasta externa: /home/romerito/Documents/data na pasta do container /opt/data/input lembrando que voce precisa usar a imagem do container comitada anteriormente, lembre que foi nela que fizemos as alterações.

 

$ docker run --restart on-failure -p 18630:18630 -v /home/romerito/Documents/data:/opt/data/input -d --name sdc nome_imagem_commitada:tag

Vamos saber se a montagem das pastas funcionou, repare que na minha pasta externa tenho 2 arquivos.

 

agora conecte no container via linha de comando e digite: ls -lha /opt/data/input e verás que esses mesmos arquivos vão aparecer no diretório.

 

Fazendo a Ingestão dos arquivos

Abra o pipeline que você criou anteriormente e vamos começar, para essa receita vamos trabalhar com o conjunto de dados https://www.kaggle.com/savitanair/cardata é uma lista de nomes de carros, km rodado, ano etc… a estrutura desses arquivos são similares a nossa tabela criada no PostgreSQL. esses arquivos já se encontram na nossa pasta /home/romerito/Documents/data. então vamos lá.

do lado direito do botão Start tem um ícone, clique nele e vai aparecer uma dock com vários componentes, acima no combobox ta selecionado origins mude para All Stages e procure pelo componente Directory digitando na caixa de pesquisa, ao encontrar segure e arraste para o espaço a esquerda

 

Com esse componente vamos ler os nossos arquivos (.csv) do diretório /opt/data/input muita atenção nessa hora, a seguir vai ter várias imagens com configurações e uma breve explicação de ambas.

Directory: [General] aqui definimos o nome do componente:

 

Directory: [Files] aqui definimos o diretório dos arquivos, a ordem de leitura e a extensão dos arquivos.

 

Directory: [Data Format] aqui definimos o tipo de arquivo se é: JSON,TEXT, Excell etc.. No nosso caso selecionamos DELIMITED, definimos também que a configuração vai ignorar as linhas vazias dos arquivos e que eles têm cabeçalho.

 

É importante lembrar que exibimos apenas as configurações necessárias para essa receita, ao arrastar um novo componente não esquece de conectá-los. você faz isso clicando na bolinha branco do componente e arrastando-a até a bolinha do outro componente, sem essa ligação o fluxo não vai funcionar.

 

adicione outro componente chamado: Expression Evaluator

vamos usá-lo para criar o campo chamado: /Processing_Date que vai ter como finalidade armazenar a hora em que o arquivo foi processado escreva no componente da mesma forma como está na imagem.

 

adicione o componente: Field Type Converter vamos usar ele para converter o campo /Processing_Date de Datetime para String.

 

adicione outro componente chamado: Expression Evaluator vamos usár-lo para modificar os dados do campo /Processing_Date  vamos criar um campo provisório chamado /data e atribuir a ele a data/hora/minuto/segundo advindos do campo /Processing_Date  e depois atribuir os dados do campo /data já modificados para o campo original /Processing_Date.

 

adicione o componente: Field Remover vamos usár-lo para remover o campo provisório /data

 

adicione o componente: Field Order vamos usár-lo para deixar os dados na ordem desejada. para adicionar os campos basta você clicar no campo que ele vai mostrar uma lista de campos. você vai clicando e deixando na ordem desejada.

 

adicione o componente: JDBC Producer vamos usár-lo para pegar os dados tratados e inserir na tabela cardata que criamos anteriormente no PostgreSQL.

JDBC Producer: [JDBC] aqui definimos a String de conexão, onde passamos o IP do nosso container, porta e banco de dados. definimos também o nome do esquema que criamos e o nome da tabela

 

JDBC Producer: [Credentials] aqui adicionamos o usuário e senha do banco de dados

 

Se seu pipeline estiver assim:

 

Você fez tudo certinho, perceba que todas as caixinhas estão conectadas isso é necessário pois cada componente desse é responsável por uma etapa do processo de adequação quando o dado passa por ele. agora vamos debugar o nosso pipeline para ver se as regras aplicadas estão corretas. clique em Preview

 

ao clicar vai aparecer outra janela, deixa as opções como na janela e click em Run Preview

 

Vai demorar uns 5 segundos e vai aparecer essa tela.

 

perceba que o primeiro componente está em azul e abaixo exibe os dados desse componente,  a medida que você vai clicando na setinha selecionada em vermelho os dados vão sendo exibidos de acordo com o componente, repare agora que avançamos para o estágio de ordenação dos dados, os dados abaixo à esquerda ficam em vermelho indicando como os dados eram antes, e verde como estão agora passando pelo componente.

 

Caso apareça algum erro vai aparecer um ícone em vermelho no componente indicando o número de erros. aparentemente está tudo correto, para sair do modo de debug clique onde está selecionado em vermelho.

 

Antes de iniciarmos o pipeline para que ele faça o processo completo, vamos adicionar alguns componentes para que quando ele terminar de carregar os dados ele finalize o pipeline, sem essa configuração ele vai ficar rodando para sempre. antes de arrastar os componentes marque a opção Produce Events do componente Directory

adicione o componente: Stream Selector clique e arraste da bolinha (E) do componente Directory até a bolinha do Stream Selector com ele vamos definir algumas regras:

 

Clicamos no + da caixinha do lado direito e adicionamos uma condição, quando não houver mais dados para processar ele vai fazer uma ligação a outro componente, para isso procure pelo componente Pipeline Finisher Executor  e arraste ele para a área de desenvolvimento e agora clique em cima de (1) do componente Stream Selector  e arraste até a bolinha do componente Pipeline Finisher Executor adicione também um componente chamado Trash, click em cima do número (2) do componente Stream Selector  e arraste até a bolinha do componente Trash, pronto finalizamos assim a configuração e deve ficar assim:

 

Agora sim vamos executar o nosso pipeline, procure pelo botão Start e clique nele. após isso vai aparecer essa janela.

 

Perceba nos gráficos que temos o numero 303 esse é o número registros carregados pelo componente Discovery, e temos 303 registros processados e inseridos a tabela cardata do PostgreSQL. assim que todos os dados forem processados o pipeline vai parar a execução. os arquivos processados não serão mais processados da próxima vez pois o streamsets guarda os metadados dos arquivos processados e só processa linhas de arquivos adicionados no diretório.

Agora vamos olhar nossa tabela pela Navicat e ver se os dados foram inseridos.

 

Prontinho! temos todos os dados inseridos de todos os arquivos do nosso diretório e toda vez que iniciarmos o pipeline ele vai inserir os dados nessa mesma tabela e com a data que os dados foram processados.

Espero que tenham gostado, o Streamsets é uma excelente ferramenta de Ingestão de dados. esse foi apenas um exemplo de como fazer ingestão de arquivos (.csv) mais é possível adaptar esse modelo para a leitura de arquivos  TXT ,JSON, Excell etc.. Caso queiram saber mais sobre o Streamsets da uma olhada aqui https://streamsets.com/