Learn More

As demandas de segurança em TI e governança de dados crescem diariamente. Por conta dos possíveis riscos à base de dados, como invasões de segurança, erros humanos ou até falhas de equipamentos, é preciso adotar as medidas mais adequadas para proteger essas informações de maneira correta. Como medida de prevenção, os ambientes de produção atualmente devem operar com RTO – Recovery Time Objective e RPO – Recovery Point Objective próximos de zero. 

A proposta deste artigo é demonstrar as várias possibilidades de replicação para PostgreSQL, um banco de dados OpenSource, abordando as alternativas para replicações e elencando as principais vantagens e desvantagens de cada uma.

Como funciona a replicação em PostgreSQL?

A replicação no PostgreSQL é um processo de cópia de um database server para outro. Sendo assim, precisamos considerar dois diferentes bancos de dados: o Master Server, banco de dados principal de origem, e o Replica Server, servidor que recebe a replicação.

Faiolver automático no PostgreSQL:

Quando há um problema no ambiente de produção Source Database, o banco de dados é movido automaticamente para o Replica Server, e existem alguns tipos de replicação que realizam esse procedimento, e que detalharemos melhor no decorrer do artigo.

Bucardo

Trata-se de uma replicação master-master ou master-slave que tem a vantagem do load-balance para sistemas Datawarehouse, com opção de escrita em base slave, onde os dados podem ser replicados automaticamente ou por demanda.

Limitações

• Não replica DDL
• Não replica objetos grandes
• Todas as tabelas devem ter uma chave única, caso contrário, os dados não são replicados
• Há necessidade de um servidor de controle para replicação e execução de rotinas em perl, que se comunica com os outros bancos de dados: master e slave ou múltiplos master

Pgpool

Tipo de replicação de implementação ágil, por funcionar como uma extensão no PostgreSQL.

Recursos

• Possui pool de conexões
• Replicação entre um ou mais slaves
• Load Balance
• Failover automático
• Consultas paralelas

Limitações

• Se for executado um pg_terminate_backend() para finalizar uma sessão no servidor master, isso irá disparar um failover
• Consultas de várias instruções (vários comandos SQL em uma única linha) são sempre enviadas ao nó primário (no modo de replicação de streaming) ou ao nó principal (em outros modos). Normalmente, o Pgpool-II despacha a consulta para o nó apropriado, mas não é aplicado a consultas com várias instruções
• Mínimo de três servidores sendo um master e dois slaves

Repmgr

Recursos

• Monitoramento da replicação
• Servidor slave pode ser promovido sem a necessidade de reiniciar o serviço de banco de dados
• Suporte de switchover para troca de função entre primário e standby

Limitações

• Antes do PostgreSQL 10, os índices hash não eram registrados no WAL e, portanto, não são adequados para uso na replicação de streaming no PostgreSQL 9.6 e anteriores
• Após failover em caso de falha do servidor primário, este modelo, quando reestabelecido, não é iniciado como slave, portanto, esse procedimento tem de ser manual
• Mínimo de dois servidores

Patroni

Recursos

• Cria o cluster;
• Inicia a replicação de streaming;
• Lida com os requisitos de sincronicidade;
• Monitora a vivacidade do primário e da réplica;
• Pode alterar a configuração de todos os membros do cluster, 
• Emite comandos de recarregamento e reinicia os membros do cluster selecionados, 
• Lida com trocas planejadas e failovers não planejados, 
• Retrocede um primário com falha para colocá-lo de volta como slave 
• Reinicia todas as conexões de replicação para apontar para o primário recém-promovido.
• Pode ser implementado em Kubernetes.

Limitações

• Versões PostgreSQL suportadas atualmente: 9.3 a 13.
• Mínimo de dois servidores para o master e slave;

Um servidor para o etcd para gerenciar o Patroni

Learn More

Na era em que vivemos, sabemos da importância de proteger muito bem seus dados, afinal, essas informações são peças essenciais para que as empresas possam adequar seus negócios às demandas da atualidade.

Para que seu banco de dados esteja em plena segurança em caso de riscos, é preciso realizar, frequentemente, o backup dos arquivos existentes, garantindo sua restauração em caso de falha. Esse tipo de falha pode ser decorrente de diversos fatores, sejam eles a corrupção de arquivos, defeitos no hardware, sinistros ou erros de usuários, mas ainda assim, é possível prevenir grandes danos com uma estratégia de backup eficiente. 

Nós, da Rox Partner, conhecemos as soluções mais adequadas para escalar o seu ambiente e proteger os seus dados. Existem muitas soluções com as quais podemos trabalhar, cada uma com suas próprias peculiaridades e vantagens. Neste artigo, vamos apresentar as diferenças entre as opções de backup lógico no Oracle e quais as situações adequadas para cada caso. 

O que é um backup lógico?

Antes de tudo, é preciso ressaltar que o Oracle trabalha com dois diferentes tipos de backups: os backups lógicos e os backups físicos. Diferente dos backups físicos, que contém arquivos físicos do banco de dados, como datafiles, archive logs ou controlfiles, os backups lógicos são uma alternativa mais rápida, simples e que ocupa menos espaço do que um backup completo, contando com dados e definições de objetos. Neste caso, o Oracle conta com o termo “Datapump”, que gera um arquivo binário com as definições de estrutura, índices, grants e muito mais, trazendo, por si só, várias formas de realizar a importação e exportação dos dados, de modo a atender às diversas necessidades do dia a dia do cliente.

EXP e IMP vs. EXPDP e IMPDP

Tanto o EXP, usado para exportar dados, quanto o IMP, seu “parceiro” que auxilia na importação dos dados, são alternativas mais antigas para realizar o backup e, hoje em dia, são bem pouco usadas, tendo se tornado obsoletas. No entanto, o EXPDP e o IMPDP são versões mais atualizadas, tendo sido incluídos na versão 10G, com mais funcionalidades e com uma forma de compactação mais eficaz. 

Para que seu backup seja eficiente, o recomendado é trabalhar com a versão mais atual, porém, a melhor opção sempre será aquela que atende a sua necessidade. O EXPDP é atualmente a melhor forma de realizar o backup lógico, devido a sua forma de compreensão mais precisa e suas variadas funcionalidades, além de ser mais performático e contar com validações que impossibilitam a divergência de dados durante a execução do backup e da importação. 

Exemplos de sintaxe em cada opção

EXP 

• Exportar um usuário completo

exp userid=Usuario/Senha owner=Schema  file=Nome_do_Arquivo.dmp log=nomearquivo.log

• Exportar o Banco completo 

exp userid=Usuario/Senha FULL=y   file=Nome_do_Arquivo.dmp log=nomedoarquivo.log

• Exportar uma ou mais tabelas

exp Usuario/Senha TABLES=(schema.emp,schema.sales) file=Nome_do_Arquivo.dmp

IMP 

• Importar uma Tabela

 Imp Usuário/Senha   FILE=Nome_do_Arquivo.dmp   FROMUSER=schema TABLES=(emp,sales)

• Importar renomeando o usuário

imp Usuário/Senha  FILE= Nome_do_arquivo.dmp    FROMUSER=schema TOUSER=schema_new

• Importar o backup completo

imp Usuário/Senha  FULL=y IGNORE=y FILE=myfullexp.dmp buffer=104.857.600  feedback=100000

A cláusula  Ignore=Y ignora os erros durante a execução da importação, acrescentando um buffer de 100 MB para deixar o import mais rápido.

buffer=104.857.600 

feedback=100000 

Este parâmetro é importante para acompanhar sua execução, neste exemplo, a cada 100.000 linear, um ponto “.” é acrescentado ao terminal.

EXPDP

Para trabalhar com EXPDP e IMPDP, é necessário criar um “diretório” no banco para informar onde os dados serão salvos:

CREATE OR REPLACE DIRECTORY test_dir AS ‘/u01/app/oracle/oradata/’;

• Exportando tabelas de um usuário

expdp Usuário/Senha  tables=schema.EMP,schema.DEPT directory=TEST_DIR dumpfile=EMP_DEPT.dmp logfile=expdpEMP_DEPT.log

• Exportando o Backup Completo

expdp Usuário/Senha full=Y directory=TEST_DIR dumpfile=DB10G.dmp logfile=expdpDB10G.log

• Exportando Incluindo ou excluindo dados do export

Com essa cláusula podemos, por exemplo, incluir as tabelas EMP e DEPT ou mesmo excluir a tabela BÔNUS, como nos modelos abaixo:

expdp Usuário/Senha schemas=SCOTT include=TABLE:”IN (‘EMP’, ‘DEPT’)” directory=TEST_DIR dumpfile=SCOTT.dmp logfile=expdpSCOTT.log

expdp Usuário/Senha schemas=SCOTT exclude=TABLE:”= ‘BONUS'” directory=TEST_DIR dumpfile=SCOTT.dmp logfile=expdpSCOTT.log

• Contents

Com os contents, podemos exportar somente os metadados do banco ou de uma tabela. No exemplo abaixo, estamos exportado somente os metadados do schema scott:

expdp Usuário/Senha schemas=SCOTT directory=TEST_DIR dumpfile=scott_meta.dmp logfile=expdp.log content=METADATA_ONLY

No exemplo abaixo, estamos exportando o banco completo. Porém, as tabelas EMP e DEPT do schema scott estão levando apenas seus metadados

expdp Usuário/Senha full=Y directory=TEST_DIR dumpfile=full.dmp logfile=expdp_full.log query=’SCOTT.EMP:”WHERE deptno=0″,SCOTT.DEPT:”WHERE deptno=0″‘

IMPDP

• Importando as tabelas 

impdp Usuário/Senha tables=schema.EMP,schema.DEPT directory=TEST_DIR dumpfile=EMP_DEPT.dmp logfile=impdpEMP_DEPT.log

• Importando o backup completo 

impdp Usuário/Senha full=Y directory=TEST_DIR dumpfile=DB10G.dmp logfile=impdpDB10G.log  

–

De forma a garantir a integridade dos dados, os exports sempre devem ser feitos com a cláusula FLASHBACK_SCN. De forma crua, essa cláusula pega uma “foto” do banco para usar como modelo ao final do export, com o objetivo de comparar se houve alguma mudança durante a execução do backup, garantindo assim que o banco sempre vai estar íntegro.

expdp Usuário/Senha full=Y directory=TEST_DIR dumpfile=full.dmp logfile=expdp_full.log flashback_time=systimestamp

• Como usar no arquivo de parâmetros.

flashback_time=”to_timestamp(’09-05-2011 09:00:00′, ‘DD-MM-YYYY HH24:MI:SS’)”

• Usando na linha de comando escapando caracteres especiais.

expdp ….. flashback_time=\”to_timestamp\(\’09-05-2011 09:00:00\’, \’DD-MM-YYYY HH24:MI:SS\’\)\”

• Capturando o SCN dentro do banco

SELECT TIMESTAMP_TO_SCN(SYSTIMESTAMP) FROM dual;

SELECT SCN_TO_TIMESTAMP(5474751) FROM dual;

Learn More

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:

 

Learn More

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/

Learn More

SQL Server & Optane

O que é Intel Optane:

Em abril de 2017 a Intel disponibilizou no mercado este novo componente, utilizando de tecnologia 3D Xpoint (memória não volátil) para armazenamento.

Trata-se de um tipo de armazenamento muito mais rápido que os HDs e SSDs disponíveis no mercado, e é utilizado como solução de aceleração de sistemas.

Segue uma imagem da Inter explicando como pode ser utilizada em ambientes produtivos:

https://www.intel.com.br/content/www/br/pt/architecture-and-technology/optane-dc-persistent-memory.html

Vamos tratar aqui neste post especificamente como esta tecnologia pode ajudar a otimizar ambientes com SQL Server.

Como utilizar Intel Optane com SQL Server:

Além das configurações e otimizações a nível de infraestrutura que não trataremos aqui, podemos ainda utilizar a Optane apresentando como disco no Servidor:

Após apresentar, precisamos formatar o disco como DAX:

Assim o ambiente estará preparado para que o SQL Server utilize esta partição como logbuffer persistente:

ALTER DATABASE [Nome_do_Database] ADD LOG FILE (NAME = [DAXlog],

FILENAME = ‘F:\MSSQL\DATA\DAXlog.ldf’, SIZE = 20 MB)

Link: https://docs.microsoft.com/pt-br/sql/relational-databases/databases/add-persisted-log-buffer?view=sql-server-ver15

Além disso, podemos ainda habilitar o SQL Server para trabalhar com a memória híbrida (Disponível a partir da versão SQL Server 2019):

ALTER SERVER CONFIGURATION SET MEMORY_OPTIMIZED HYBRID_BUFFER_POOL = ON;

Este comando faz com que o SQL Server trabalhe da melhor forma com a nova memória:

Link: https://docs.microsoft.com/pt-br/sql/database-engine/configure-windows/hybrid-buffer-pool?view=sql-server-ver15

Podemos conferir a configuração:

Benchmark:

A Dell disponibilizou para a Rox Partner um ambiente de testes, com dois servidores idênticos, com a única diferença de termos o Intel Optane apresentada a uma delas, onde tivemos o privilégio de poder interagir com esta tecnologia e avaliar melhor o comportamento e ganhos disponíveis:

Desta forma criamos um database de teste em um Servidor, depois copiamos o mesmo database através de backup para o outro.

Assim fizemos um teste simples de uma query mal otimizada para avaliar somente o tempo de resposta de cada um deles, seguem resultados:

Sem optane:

Com Optane:

Seguem também vídeos da query em execução:

Sem Optane:

 

Com Optane:

 

Tivemos um ganho aproximado de 33% no tempo de resposta da query, somente utilizando o Intel Optane no ambiente:

Ainda temos a possibilidade de alocar o TempDB no disco Optane e assim otimizar mais ainda ambientes produtivos.

Um outro Benchmark muito interessante com mais detalhes está disponível pela Intel no seguinte link:

https://optanedifference.intel.com/?lang=en_us&demo=mssql

Conclusão:

Realmente comprovamos em nossos testes que esta solução pode auxiliar as empresas a impulsionar ainda mais seus ambientes produtivos, como uma opção que a cada ano fica mais viável financeiramente.

Hoje a Rox Partner, juntamente com a Dell, desenvolveu um Bundle de infraestrutura onde disponibilizamos Servidor mais licença do SQL Server de forma que a conta final para nossos clientes fique muito mais atraente e assim entregamos melhor custo x benefício.

Entrem em contato para mais detalhes.

Learn More

Segundo pesquisa anual da ASG Technologies Group, empresa líder no fornecimento de soluções de gerenciamento de informações e sistemas de TI, quase metade das instituições que lidam com dados não conseguem utilizá-los de maneira eficiente …

Learn More

A ideia aqui é introduzir os conceitos de particionamento, exibir os recursos disponíveis no MySQL e passar um exemplo prático de como uma tabela pode ser particionada e quais os benefícios dessa prática. Futuramente abordarei o “subparticionamento”…

Learn More

É comum a necessidade de integração entre diferentes SGBD para finalidades diversas, tais como relatórios, DW, iteração de sistemas secundários, entre outras. O Oracle disponibiliza um recurso chamado DBLINK que proporciona a conexão a databases remotos, sendo esses Oracle ou NON-ORACLE…

Learn More

A ideia aqui é mostrar uma rotina de backup lógico alternativa ao convencional mysqldump, realizando um backup lógico na menor janela de disponibilidade possível se comparado ao dump convencional.

Learn More