Logotipo Rox Partner colorido
  • ROX Partner
    • Sobre Nós
    • Experts
  • Serviços
    • Banco de Dados
      • Consultoria
      • DBA Remoto 24×7
      • Migração
      • Gestão 24×7
      • DOC 24X7
    • Analytics
      • Plataformas de Analytics
      • Migração de Plataformas
      • Engenharia de Dados
      • Inteligência Artificial
      • DOC 24×7
      • Squads de Analytics
    • Infraestrutura
      • Consultoria
      • Sustentação
      • Virtualização
      • Segurança
      • DOC 24×7
    • Cloud
      • Migração on-premise
      • Cloud Híbrida
      • Cloud Pública
      • Custo Cloud
      • DOC 24×7
  • Soluções
    • Banco de Dados
      • Oracle
      • Microsoft SQL Server
      • IBM DB2
      • MySQL
      • PostGreSQL
      • MongoDB
      • Progress
      • Elastic
      • Apache Solr
      • Apache HBase
      • Apache Cassandra
    • Analytics
      • Hadoop
      • AWS RedShift
      • Azure SQL Datawarehouse
      • Google BigQuery
    • Cloud
      • Microsoft Azure
      • Google Cloud
      • Oracle Cloud
    • Infraestrutura
      • Dell
      • Aruba
      • Oracle Enterprise Linux
      • VMWare
      • VEEAM
      • Fortinet
  • Parcerias
  • Recursos
    • ServiceDesk
    • Rox Mon
    • White Paper
    • Webinar
    • Podcast
  • Blog
  • Contato
Logotipo Rox Partner colorido
  • ROX Partner
    • Sobre Nós
    • Experts
  • Serviços
    • Banco de Dados
      • Consultoria
      • DBA Remoto 24×7
      • Migração
      • Gestão 24×7
      • DOC 24X7
    • Analytics
      • Plataformas de Analytics
      • Migração de Plataformas
      • Engenharia de Dados
      • Inteligência Artificial
      • DOC 24×7
      • Squads de Analytics
    • Infraestrutura
      • Consultoria
      • Sustentação
      • Virtualização
      • Segurança
      • DOC 24×7
    • Cloud
      • Migração on-premise
      • Cloud Híbrida
      • Cloud Pública
      • Custo Cloud
      • DOC 24×7
  • Soluções
    • Banco de Dados
      • Oracle
      • Microsoft SQL Server
      • IBM DB2
      • MySQL
      • PostGreSQL
      • MongoDB
      • Progress
      • Elastic
      • Apache Solr
      • Apache HBase
      • Apache Cassandra
    • Analytics
      • Hadoop
      • AWS RedShift
      • Azure SQL Datawarehouse
      • Google BigQuery
    • Cloud
      • Microsoft Azure
      • Google Cloud
      • Oracle Cloud
    • Infraestrutura
      • Dell
      • Aruba
      • Oracle Enterprise Linux
      • VMWare
      • VEEAM
      • Fortinet
  • Parcerias
  • Recursos
    • ServiceDesk
    • Rox Mon
    • White Paper
    • Webinar
    • Podcast
  • Blog
  • Contato
  • ROX Partner
    • Sobre Nós
    • Experts
  • Serviços
    • Banco de Dados
      • Consultoria
      • DBA Remoto 24×7
      • Migração
      • Gestão 24×7
      • DOC 24X7
    • Analytics
      • Plataformas de Analytics
      • Migração de Plataformas
      • Engenharia de Dados
      • Inteligência Artificial
      • DOC 24×7
      • Squads de Analytics
    • Infraestrutura
      • Consultoria
      • Sustentação
      • Virtualização
      • Segurança
      • DOC 24×7
    • Cloud
      • Migração on-premise
      • Cloud Híbrida
      • Cloud Pública
      • Custo Cloud
      • DOC 24×7
  • Soluções
    • Banco de Dados
      • Oracle
      • Microsoft SQL Server
      • IBM DB2
      • MySQL
      • PostGreSQL
      • MongoDB
      • Progress
      • Elastic
      • Apache Solr
      • Apache HBase
      • Apache Cassandra
    • Analytics
      • Hadoop
      • AWS RedShift
      • Azure SQL Datawarehouse
      • Google BigQuery
    • Cloud
      • Microsoft Azure
      • Google Cloud
      • Oracle Cloud
    • Infraestrutura
      • Dell
      • Aruba
      • Oracle Enterprise Linux
      • VMWare
      • VEEAM
      • Fortinet
  • Parcerias
  • Recursos
    • ServiceDesk
    • Rox Mon
    • White Paper
    • Webinar
    • Podcast
  • Blog
  • Contato
Rox Partner
  • ROX Partner
    • Sobre Nós
    • Experts
  • Serviços
    • Banco de Dados
      • Consultoria
      • DBA Remoto 24×7
      • Migração
      • Gestão 24×7
      • DOC 24X7
    • Analytics
      • Plataformas de Analytics
      • Migração de Plataformas
      • Engenharia de Dados
      • Inteligência Artificial
      • DOC 24×7
      • Squads de Analytics
    • Infraestrutura
      • Consultoria
      • Sustentação
      • Virtualização
      • Segurança
      • DOC 24×7
    • Cloud
      • Migração on-premise
      • Cloud Híbrida
      • Cloud Pública
      • Custo Cloud
      • DOC 24×7
  • Soluções
    • Banco de Dados
      • Oracle
      • Microsoft SQL Server
      • IBM DB2
      • MySQL
      • PostGreSQL
      • MongoDB
      • Progress
      • Elastic
      • Apache Solr
      • Apache HBase
      • Apache Cassandra
    • Analytics
      • Hadoop
      • AWS RedShift
      • Azure SQL Datawarehouse
      • Google BigQuery
    • Cloud
      • Microsoft Azure
      • Google Cloud
      • Oracle Cloud
    • Infraestrutura
      • Dell
      • Aruba
      • Oracle Enterprise Linux
      • VMWare
      • VEEAM
      • Fortinet
  • Parcerias
  • Recursos
    • ServiceDesk
    • Rox Mon
    • White Paper
    • Webinar
    • Podcast
  • Blog
  • Contato

Category: banco de dados

10 de maio de 2022
banco de dados

Como ativar e configurar um Replica Set no seu servidor com MongoDB

Quando se trabalha com alto volume de dados, uma das maiores preocupações é na possibilidade de algum problema, ou na armazenagem ou na transferência, causar a perda deles. Por isso, é necessário montar um sistema com a redundância em mente. Ou seja, os servidores precisam realizar cópias do arquivo principal, o qual sempre estará em comunicação com as partes replicantes. No caso em que o dado principal não estiver disponível, a cópia pode ser usada, garantindo a integridade do que é armazenado.

De fato, há diversas variantes que os Data Centers precisam se atentar, como software, hardware, questões de rede elétrica, temperatura da sala dos servidores e assim por diante. Porém o passo primordial é conseguir fazer com que o processo de replicação de dados esteja efetivamente operacional no sistema da empresa. Por isso, montamos um tutorial de como você pode configurar este mecanismo utilizando o software open source MongoDB.

Tutorial: Configurando o seu Replica Set

Em termos técnicos, vamos ensinar como converter uma instância Standalone em Replica Set, mantendo dois Nodes: um principal e um secundário. Meus servidores já estão com o MongoDB instalado e o principal já possui alguns Databases (dbs) criados. Focaremos em converter o MongoDB principal em Replica Set e em adicionar o Node secundário na replicação.

Para isso, temos dois servidores que vamos chamar de mongodb01 (Primário) e mongodb02 (Secundário).

Versão do sistema operacional: CentOS 8

Versão do MongoDB: 5.0.8

Primeiro passo é criar uma chave no servidor primário e compartilhar com o secundário.

openssl rand -base64 756 > /home/mongodb/keyFile/mongo-key
chmod 400 /home/mongodb/keyFile/mongo-key
scp /home/mongodb/keyFile/mongo-key root@xxx.xxx.xx.x:/home/mongodb/keyFile/

Lembrando que o diretório no qual será criada a chave deve ser feito previamente, tanto no servidor principal, quanto no secundário.

mkdir -p /home/mongodb/keyFile/

Após isso, precisamos colocar a chave nos arquivos de configuração do MongoDB primário e secundário.

Abaixo o arquivo de configuração que estou utilizando:

# mongod.conf
# for documentation of all options, see:
# http://docs.mongodb.org/manual/reference/configuration-options/
# where to write logging data.
systemLog:
destination: file
logAppend: true
path: /var/log/mongodb/mongod.log
# Where and how to store data.
storage:
dbPath: /var/lib/mongo
journal:
enabled: true
# engine:
# wiredTiger:
# how the process runs
processManagement:
fork: true # fork and run in background
pidFilePath: /var/run/mongodb/mongod.pid # location of pidfile
timeZoneInfo: /usr/share/zoneinfo
# network interfaces
net:
port: 27017
bindIp: 127.0.0.1,192.168.15.6 # Enter 0.0.0.0,:: to bind to all IPv4 and IPv6 addresses or, alternatively, use the net.bindIpAll setting.
security:
authorization: enabled
keyFile: /home/mongodb/keyFile/mongo-key
#transitionToAuth: true
#operationProfiling:
#replication:
# replSetName: replicaset01
#sharding:
## Enterprise-Only Options
#auditLog:
#snmp:

IMPORTANTE: Para que nossa replicação funcione, não podemos esquecer dos seguintes parâmetros:

bindip: com o ip da máquina local, no exemplo da minha instância primária ficou bindIp: 127.0.0.1,192.168.15.6.

authorization: enabled = Habilitar a autenticação obrigatória no MongoDB, assim não sendo possível conectar sem passar usuário e senha.

keyFile: /home/mongodb/keyFile/mongo-key = Nossa chave de autenticação

replSetName: replicaset01 = O nome da nossa replicação, manter comentado com um # por enquanto.

Após configurar no MongoDB primário e secundário, vamos criar um usuário admin no nosso MongoDB primário, pois, como ativamos a opção de autenticação, será necessário a criação deste.

use admin
db.createUser(
{
user: ‘admin’,
pwd: ‘admin’,
roles: [ { role: ‘root’, db: ‘admin’ } ] }

No meu caso, criei o usuário “admin” com senha “admin” na role “root” dentro do db “admin”.

IMPORTANTE: Lembrando que meu ambiente é de teste. Na realidade, configurar um usuário e uma senha com maior complexidade.

Após isso, realizar o reinício da instância.

Para conectar, passar usuário e senha e o authenticationDatabase.

mongo -u “admin” -p “admin” –authenticationDatabase “admin”

Listar os bancos para validar se está tudo certo com o acesso.

show dbs

Validei que o acesso está funcionando no meu caso.

Agora que a mágica acontece! Vamos converter nossa instância do servidor mongodb01 em Replica Set. No arquivo de configuração, descomentaremos as linhas replication: e replSetName: replicaset01 e realizar o reinício da instância.

Conectado com o usuário admin, execute:

rs.initiate()

Pronto, já temos um primário.

Agora, vamos validar os membros do Replica Set.

rs.status().members

E validar também a configuração do Replica Set.

rs.config()

Neste momento, adicionaremos o secundário.

rs.add(“IP da máquina réplica”)

Neste caso, você pode adicionar o IP e a porta da seguinte maneira:

rs.add(“IP da máquina réplica:porta”)

Vamos validar os membros do Replica Set.

Observe que a replicação já adicionou meu secundário, porém apresenta uma mensagem de falha de conexão. Isso ocorreu pois ainda tenho que descomentar os parâmetros de chave e replicação na instância mongodb02 e reiniciá-la.

Após isto, a replicação conectou nos dois Nodes.

Não temos mais o erro. Agora vamos validar se replicou os dbs do primário para o secundário.

Observe que, no secundário, eu executei o rs.slaveOk() (que está sendo substituído pelo rs.secondaryOk()), já que, por se tratar de um secundário, não conseguimos executar os mesmos comandos que na instância primária, a não ser que você mesmo execute.

Nossa replicação já está funcionando, mas, dessa forma, podemos ter chaveamento entre primário e secundário. No meu caso, eu quero manter o mongodb01 como primário e o mongodb02 como secundário. Sendo assim, vamos executar os seguintes comandos no primário.

cfg = rs.conf()
cfg.members[0].priority = 1
cfg.members[1].priority = 0.5
cfg.members[0].votes = 1
rs.reconfig(cfg,{force: true})

Com isso, nossa replicação está configurada com sucesso. Você pode testar o sincronismo criando dbs.

Aqui executei o comando para criação do db que no exemplo chamei de roxdb.

use roxdb
db.user.insert({nome: “MySQL”, tipo: “banco de dados”})

E está feito! Espero que tenham gostado e contem para gente como foi sua experiência configurando seu Replica Set.

Learn More

Rodrigo Rabaço
30 de março de 2022
banco de dados

Tipos de Backup e Recuperação de Banco de Dados no SQL Server

Nos dias atuais, uma das maiores riquezas de uma empresa ou negócio, seja de  pequeno, médio ou grande porte, é a informação. Entender como um negócio funciona, ter as informações corretas e saber como elas se relacionam é algo fundamental para o sucesso nas tomadas de decisão.

Com a necessidade de armazenar uma quantidade grande de dados, e poder acessá-los de forma mais dinâmica, o tempo se encarregou de transferir essas informações de simples papéis para locais mais seguros e eficientes: um

banco de dados.

O conceito de banco de dados cresceu muito ao longo dos anos e a forma de se trabalhar com ele se aprimora dia após dia. Um banco de dados é um ambiente que permite armazenar dados de forma mais organizada e estruturada, gerando conjuntos de arquivos. Ele permite que, além de armazenar informações, possamos alterar, atualizar, consultar, apagar e até mesmo inserir novos dados com mais agilidade e praticidade.

Contudo, quanto maior a manipulação desses dados, maior o risco de acabar cometendo erros ou até mesmo danificar a integridade de um banco. Por isso, existe uma maneira de evitar esses riscos, recuperando dados importantes, informações alteradas, apagadas acidentalmente ou por conta de qualquer outra falha.

Essa forma é chamada de backup.

O que é backup e qual sua importância?

O backup é um termo que vem originalmente do inglês e que significa cópia de segurança. Como seu significado sugere, é um método utilizado para gerar a cópia de segurança dos dados (informações) de um dispositivo de armazenamento (celulares, tablets, computadores etc.) ou sistemas (aplicativos, softwares, jogos etc.).

Neste caso, o backup é utilizado para restaurar um banco em um determinado estado ou antes de algum ponto de falha. Pensamos no seguinte cenário: sua empresa armazena diversas informações sobre funcionários, usuários, renda, gastos, produtos e outros elementos importantes em um banco de dados.

Agora, imagine que por algum descuido, alguém acaba apagando essas informações ou apaga a tabela inteira que armazenava dados sobre seus funcionários. Ou pior, por um motivo qualquer, alguém apaga o banco de dados inteiro, e todas as informações da sua empresa que estavam armazenadas nele simplesmente não “existem” mais.

É justamente essa a importância de sempre ter um backup do banco de dados. Em cenários de desastre e recuperação de um banco, o backup é uma parte crucial. Com ele, conseguimos trazer essas informações de volta em um estado anterior ao ponto de falha. Sem ele, não conseguimos recuperar as informações.

Quais os tipos de backup de um Banco de Dados?

Trazendo o conceito de backup para o lado do banco de dados, pode-se dizer que temos diferentes tipos de backup que podem atender diferentes cenários. Basicamente, todos possuem o mesmo propósito de recuperar o banco em um determinado estado.

Contudo, a depender do cenário, precisamos recuperar o banco de dados em um ponto extremamente específico. Por isso, nós temos 3 tipos distintos de backup com o SQL Server. São eles: 

  • Backup full 
  • Backup log
  • Backup diferencial. 

A diferença entre eles é o modo com que o backup é feito, o tempo de realização do processo e a maneira como acontecerá a restauração dos dados que fizeram backup.

Backup Full

O backup full ou backup completo, é o backup de todo o banco de dados (configurações, atributos, objetos, páginas de dados, procedures etc.). Esse tipo de backup é o mais utilizado e recomendado para ambientes com criticidade alta. Isso porque, ao fazer o backup do banco inteiro, conseguimos aumentar a taxa de sucesso ao recuperar um banco e suas informações. É extremamente recomendado que um banco possua um backup full.

Como fazer um backup full?

Bom, aposto que de tanto ouvir falar, você quer aprender a realizar um backup full. Na verdade, o procedimento é simples. Contudo, é necessário sempre ter atenção no momento de realizar o procedimento. O primeiro passo é localizar o banco que desejamos fazer o backup.

  1. Dentro do seu ambiente SQL Server, clique com o botão direito em cima do banco de dados > Tarefas > Fazer Backup
  2. Será aberto uma janela parecida com essa:
  3. Em vermelho – 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 full, podemos deixar da forma que está selecionado em “completo”.Em azul – Diretório: Neste campo, informamos o local em que queremos armazenar nosso arquivo de backup. Por padrão, o SQL armazena no diretório Program Files\Microsoft SQL Server\MSSQL15.InstanceName\MSSQL\Backup, mas você pode alterar para onde desejar.
  4. Feito isso, basta clicar em “OK” e o backup do banco será feito. Para saber se foi concluído com sucesso, basta verificar se essa mensagem de sucesso apareceu:
  5. Por fim, podemos acessar o local em que alocamos o backup e verificar se o arquivo .bak foi gerado com sucesso. Note que foi gerado, e agora o banco db_sistema possui um backup full.

Backup Log

O backup log faz o backup apenas do log de transações do banco de dados. Esse backup grava só o que é obtido pelo LSN (Log Transaction Number). Neste tipo de backup, conseguimos minimizar nossa exposição à perda de trabalho. Além disso, realizando o backup log, conseguimos truncar o log de transações, o que consequentemente impede que o log do banco fique cheio e o banco não faça mais transações, além de recuperar o espaço em disco.

Diferente do backup full, o backup log deve seguir algumas particularidades simples. Como:

  • Só conseguimos fazer o backup log de um banco, se ele possuir um backup full
  • Para fazer o backup log, é necessário que o banco de dados possua o parâmetro Recovery Model como Caso esteja em SIMPLE, não conseguimos fazer o backup log.

O backup log também é extremamente recomendado para ambientes com criticidade alta. Em geral, sua frequência depende de alguns fatores, como: a importância dos dados, o tamanho do banco e a quantidade de transações que ocorrem no banco.

Como fazer um backup log?

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.

Backup Diferencial

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.

Recuperação de Banco de dados

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.

Recuperação de um backup full

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

Para restaurar um backup full, você deve seguir os seguintes passos:

  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;
  1. 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).
  2. 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.
  3. Por fim, basta clicar em “OK” e você deve receber a seguinte mensagem de sucesso, conforme a imagem abaixo:
  4. 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.

Recuperação de um backup log

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:

Após isso, iremos executar o backup log do banco de dados.

 

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.

     

Learn More

Carlos Mendes
4 de março de 2022
banco de dados

Entenda o ciclo de vida de uma Query no SQL Server: Parte 2

Anteriormente, no último artigo, nós havíamos percorrido “todo” caminho de uma Query, da sua execução à entrega ao solicitante. Mas, será que algo além acontece nos bastidores? A resposta é, como quase sempre será, sim!

Neste artigo, vamos nos aprofundar no Storage Engine, Buffer Pool, Access Methods e Transaction Log. Pegue o café e venha desvendar mais uma etapa sobre a execução de processos DDL e DML.

Storage Engine – Access Methods

Como falamos anteriormente, nesta etapa há diferenças entre processos DDL e DML. Vamos começar pela primeira: DDL é uma abreviação de Data Definition Language (Linguagem de Definição de Dados), ou seja, uma linguagem que cria ou modifica estrutura de objetos no banco de dados. Um exemplo rápido são comandos do tipo CREATE, ALTER E DROP.

Neste caso, quando o procedimento chega no Query Executor há uma interação com o Storage Engine através do Access Methods, que é quem fornece as estruturas de armazenamento dos dados e índices, bem como a interface pela qual os dados são recuperados e modificados. Ele é responsável por armazenar operações de linha, índice, alocação de páginas e versionamento. Apesar de conter todo o código da operação, ele não executa, pois, neste ponto ele passa a requisição ao Buffer Manager.

Storage Engine – Buffer manager

Você se lembra que, no primeiro artigo, comentamos que na etapa do Command Parser, o SQL analisa se há um plano de execução pronto para aquela requisição? Pois esta é justamente uma das funções do Buffer Manager:

Ele é responsável por gerenciar o Buffer Pool, ou seja, ele cuida de toda parte de recebimento, armazenagem e entrega de dados. Se você precisar ler algumas linhas de uma página de dados, ele verificará se esta página já está na cache de memória e, caso não esteja, ele buscará esta página no disco, armazenará na cache e só então devolve o resultado ao Access Methods. É nesta última etapa que acontece o famoso Wait_Type PAGEIOLATCH, que representa o tempo  necessário para ler uma página do disco e guardar em memória.

Ele também é responsável por gerenciar funções de I/O de disco para trazer páginas de dados e índices para a cache de memória e compartilhar com os usuários, além de assegurar que o Transaction Log seja escrito antes que cada alteração de banco seja executada, garantindo que essas informações guardadas no Transaction Log tenham uma ordem específica e deixando claro quais blocos de registro devem ser processados em caso de falha de sistema, independentemente de quando ou onde houve a falha.

Storage Engine – Data Cache

Bom, já sabemos que existe Buffer Pool e que quem “gerencia” essa casinha é o Buffer Manager. Contudo, neste Pool não existe apenas a Plan Cache (aliás, esta é a menor parte), existe também o Data Cache e nós vamos falar um pouco mais sobre ele agora.

O Data Cache é a partição do Buffer Pool que ocupa mais espaço. É nele que todas (sim, todas) as páginas de dados são lidas a partir do disco antes de serem usadas. E quando eu digo disco, são os datafiles dos bancos. O tempo que as páginas permanecem em cache é determinado por uma política LRU, para a qual precisamos abrir um parênteses: LRU-K (Last Recently Used) é um algoritmo que mantém “fresco na memória” uma página que é referenciada K vezes.

Cada página de dados possui em seu cabeçalho detalhes das duas últimas vezes em que a página foi acessada e é feita uma varredura periódica para determinar se essa página deve ou não continuar em Cache. Essa varredura também é efetuada pelo Buffer Manager. Sempre que uma varredura é feita, um contador é colocado na página e é incrementado toda vez que a página não é acessada por um determinado período de tempo e quando o SQL Server precisa liberar espaço em cache. Então, as páginas com o contador mais baixo são retiradas da Cache. Um tempo recomendado para que todo esse processo deva ocorrer é de 1000s.

Storage Engine – Transaction Manager / Transaction Log

Agora vamos falar sobre comandos do tipo DML. DML é uma abreviação de Data Modification Language (Linguagem de modificação de Dados). Esta é uma linguagem que resgata, guarda, modifica, insere, deleta e atualiza dados no banco de dados. Exemplo disso são comandos do tipo SELECT, UPDATE, INSERT, DELETE e etc.

O que difere os processos de DML dos processos de DDL, é que, no DML, em paralelo atua também o Transaction Manager. Quando o Buffer Manager recebe uma requisição de alteração, ela encaminha antes ao Transaction Manager para que este guarde um log desta transação para que só então guarde as páginas em cache.

O Transaction Manager possui dois componentes para garantir a consistência da requisição: O Lock Manager e o Log Manager. O Lock Manager gerencia a concorrência de dados através de locks e o Log Manager armazena de fato o log da transação no logfile. Esse tipo de processo é chamado de WAL (Write-ahead Logging).

Mas, neste processo, ainda falta alguém. De maneira análoga, o Buffer Manager está para o Buffer Pool assim como o Transaction Manager está para o Transaction Log! O Transaction Log, utiliza o logfile através dos VLF’s (Virtual Log Files) para armazenar e ordenar esses dados “recuperáveis”. Essa arquitetura é relativamente simples e a receita que o SQL Server usa é basicamente o seguinte:

 

  • Se o próximo crescimento for menor que 1/8 do tamanho físico do log atual, crie 1 VLF que abranja o tamanho do crescimento (começando com SQL Server 2014 (12.x))
  • Se o próximo crescimento for maior que 1/8 do tamanho atual do log, use o método pré-2014:
  • Se o crescimento for menor que 64 MB, crie 4 VLFs que abranjam o tamanho do crescimento (por exemplo, para um crescimento de 1 MB, crie quatro VLFs de 256 KB)
  • Se o crescimento for de 64 MB a 1 GB, crie 8 VLFs que abranjam o tamanho do crescimento (por exemplo, para um crescimento de 512 MB, crie oito VLFs de 64 MB)
  • Se o crescimento for maior que 1 GB, crie 16 VLFs que abranjam o tamanho do crescimento (por exemplo, para um crescimento de 8 GB, crie dezesseis VLFs de 512 MB)

E com isso, finalizamos mais um artigo. Os métodos de Recovery (recuperação) serão abordados em outra ocasião, pois é um processo um tanto quanto extenso.

Então, fique atento ao Blog da Rox, pois em breve será publicada a parte 3 deste conteúdo superinteressante.

Até a próxima e se inscreva em nossa newsletter!

Learn More

Igor Paixão
2 de fevereiro de 2022
banco de dados

Entenda o ciclo de vida de uma Query no SQL Server: Parte 1

Tão importante quanto ter um modelo de troubleshooting desenhado, é entender o que levou a acontecer o incidente. Muito se pode entender do problema, olhando todos os pontos da execução da requisição, e esse é o intuito deste artigo: explorar todo o ciclo de vida de uma query. Entre a solicitação do usuário e a entrega do resultado, muita coisa acontece no SQL Server e é o que veremos a seguir.

Protocol Layer

Tudo começa quando um usuário envia uma solicitação via SNI( SQL Server Network Interface) ao banco de dados a partir de uma query, e aqui vamos utilizar o exemplo de uma instrução do tipo SELECT. Esta solicitação é encaminhada ao SBGD através de um protocolo denominado TDS (Tabular Data Stream) que fica responsável por “desembrulhar” este pacote no client e analisar o que está sendo solicitado. Este mesmo protocolo é o responsável por retornar o resultado ao solicitante ao fim da execução.

Relational Engine – Command Parser

O próximo componente é o Command Parser e é onde a “mágica” começa. Nesta camada, o SQL lida com eventos de T-SQL, analisando sua sintaxe e devolvendo caso haja quaisquer erros de volta à camada do solicitante. Com a sintaxe validada, o próximo passo é criar um plano de execução ou reaproveitar um plano ja existente no Plan Cache. Neste caso é criado uma hash do T-SQL para verificar nesta partição do Buffer Pool se há um plano adequado. se houver, a instrução é designada diretamente ao Query Executor, e falaremos mais sobre ele logo abaixo.

Relational Engine – Query Optimizer

“Beleza, mas e se não houver um plano adequado para a solicitação?”, Neste caso o CMD Parser gerará uma árvore de consulta baseado no T-SQL e enviará à camada do Query Optimizer. Esta camada é uma das mais complexas e “misteriosas” do SQL Server. ele avalia a árvore baseando-se em custos e o objetivo é encontrar o plano mais eficiente, ou seja, um plano que terá o menor custo de execução. Em um plano, cada operador tem um custo de linha de base, que é então multiplicado pelo tamanho da linha e pelo número estimado de linhas para obter o custo desse operador — e o custo do plano é o custo total de todos os operadores. Este “Custo” é apenas um número arbitrário utilizado para representar o custo de recurso do plano em questão.

Esta otimização ocorre em 3 fases e são elas:

  • Fase 0 — Durante esta fase, o otimizador analisa os NESTED LOOP JOINS e não considerará operadores de paralelismo. O otimizador vai parar aqui se o custo do plano que encontrou for < 0.2. Um plano gerado nesta fase é conhecido como um processo de transação, ou TRIVIAL PLAN (Plano Trivial).
  • Fase 1 — A Fase 1 usa um subconjunto das possíveis regras de otimização e procura padrões comuns para os quais já possui um plano. O otimizador vai parar aqui se o custo do plano que encontrou for < 1.0. Planos gerados nesta fase são chamados de QUICK PLAN (planos rápidos).
  • Fase 2 — Esta fase final é onde o otimizador puxa todas as paradas e é capaz de usar todas as suas regras de otimização. Ele também olha para o paralelismo e as visualizações indexadas (se você estiver executando a Enterprise Edition) – FULL PLAN (otimização TOTAL).

Relational Engine – Query Executor

E assim chegamos ao Query Executor. Este componente é o responsável por de fato executar a query, trabalhando por cada etapa do plano e devolvendo o resultado ao usuário. Nesta parte do ciclo, há uma interação com o mecanismo de armazenamento para recuperar ou modificar dados. E nesta parte há diferenças entre instruções DML e DDL. Iremos explorar esta diferença no próximo artigo com mais detalhes.

 

Com isso, chegamos ao fim deste artigo. Espero que tenham gostado e nos vemos no próximo capitulo.

Learn More

Igor Paixão
10 de dezembro de 2021
banco de dadosCloud

Conheça o Delta Lake

O mundo de dados está em constante evolução e, por vezes, alguns conceitos já estabelecidos – como por exemplo, o armazenamento em nuvem e Data Warehouses – precisam ser revistos com a chegada de novas tecnologias. O Delta Lake é exatamente um desses casos. Mas, afinal, o que é o Data Lake e quais são suas vantagens? Confira essas informações e muito mais neste artigo! 

 

O que é Delta Lake?

Criado pelo time da Databricks, Delta Lake é um projeto opensource para armazenamento de arquivos, baseado no formato delta, persistidos no HDFS ou em Data Lakes (AWS, Azure, GCP), utilizando o Spark como motor de transformação e persistência. Esse formato trará algumas vantagens que veremos a seguir no artigo, como transações ACID e versionamento dos dados. 

 

Como funciona o Armazenamento no

Delta Lake?

Embora à primeira vista o “delta” se pareça um novo formato de armazenamento, de fato, ele nada mais é do que uma mescla de armazenamento físico em Parquet (compressão Snappy) -que é um formato colunar muito utilizado no mundo dos dados – junto à uma camada adicional de metadados/logs transacionais. Aqui cabem duas observações importantes: 

  1. Os metadados/logs são persistidos no mesmo diretório da tabela Delta que está sendo manipulada, portanto não é necessário nenhuma infraestrutura adicional para armazenar esses arquivos. Abaixo vemos um exemplo da estrutura do diretório de uma tabela chamada my_table, particionada pelo campo date:
  2.  Essa camada de logs (_delta_log) irá registrar todas as alterações realizadas na tabela, salvando o histórico de transformações em arquivos json/parquet e mantendo sempre a versão mais recente das alterações como padrão, porém permitindo acessar versões anteriores da tabela também.Com base nesses arquivos que o Delta nos permite viajar no tempo, pois nos permite acessar versões antigas da tabela para consultar ou até restaurar a tabela inteira para uma versão anterior.

Quais as Vantagens do Delta Lake?

Listamos aqui algumas grandes vantagens que o Delta Lake nos traz:

  • Transações ACID (atomicidade, consistência, isolamento e durabilidade) para as tabelas
  • Escalabilidade: por se utilizar de Data Lakes nativos da Cloud, ela permite escalabilidade de petabytes
  • Viagem no tempo e auditoria dos registros: possível ver versões antigas da tabela e também os registros da sessão que  a modificou
  • Reforço e evolução dos schemas da tabela
  • Suporte à operações de Updates, Merges e Deletes
  • Funciona tanto para jobs batch quanto para streaming
  • Estratégia eficaz para múltiplas leituras e escritas concorrentes nas tabelas Delta 
  • APIs de fácil acesso, podendo ser utilizado em Python, SQL ou Scala por meio do Spark
  • Permite remover arquivos antigos com o comando VACUUM

Utilização do Delta Lake

A utilização do formato delta é bem simples e está disponível por meio das APIs do Spark em Python (Pyspark), SQL e Scala. Abaixo alguns exemplos simples de como é possível utilizar o formato com SQL:

  • Criar tabela
CREATE TABLE tabela
date DATE
id INTEGER)
USING DELTA
PARTITION BY date
LOCATION "/delta"
  • Ver detalhes da tabela
DESCRIBE DETAIL tabela;
  • Ver histórico da tabela (últimas 5 versões)
DESCRIBE HISTORY tabela LIMIT 5;
  • Apagar versões históricas da tabela (maiores de 200 horas)
VACUUM tabela RETAIN 200 hours
  • Viajando no tempo (versão antiga número 4)
SELECT * FROM tabela VERSION AS OF 4
  • Operações DML

São permitidos comandos INSERT, UPDATE, MERGE e DELETE   Todas as possibilidades de Delta Lake para os times de dados!  Conforme visto, a tecnologia do Delta Lake e seu formato delta trazem inúmeros benefícios para os times de dados que já fazem utilização do Spark ou que gostariam de começar a utilizá-lo. Embora tenha sido desenvolvido pelo Databricks, o Delta Lake é open source e pode ser utilizado em diversos outros tipos de aplicações Spark como o EMR (AWS), Dataproc (Google Cloud), Kubernetes e On-premises.  A possibilidade de ter tabelas ACID em seu Delta Lake permitiu a criação de um novo conceito no mundo de dados, o Data Lakehouse, que se propõe a ser a fusão do Data Lake com o tradicional Data Warehouse (que será tema de um próximo artigo, fique ligado!).  Esperamos que esse artigo tenha ajudado a entender melhor os conceitos do Delta Lake e como ele pode ajudá-lo em seus projetos. Caso tenha interesse em implementar um projeto ou saber mais, entre em contato com nossos Roxperts , ficaremos felizes em ajudá-lo!

Learn More

Rox Partner
27 de setembro de 2021
banco de dados

O que é MLOps e como ele pode ser útil para sua empresa?

O termo MLOps surgiu recentemente no cenário do universo de dados, e está cada vez mais em pauta; principalmente nas discussões sobre quais caminhos uma empresa Data Driven deve seguir para se tornar competitiva. Embora a discussão seja pertinente, ainda existem muitas dúvidas sobre o que é exatamente o MLOps e como ele pode ser implementado.

Antes de mais nada, podemos começar esclarecendo uma confusão comumente feita: o MLOps não é uma tecnologia específica, mas sim uma metodologia. A ideia é combinar as práticas já comuns do DevOps com o campo de Machine Learning. Ela surgiu da necessidade de resolver alguns problemas específicos, relacionados à dificuldade de colocar modelos de Machine Learning em produção, além de sua manutenção e garantia de que a qualidade dos resultados se mantenha ao longo do tempo.

O primeiro estudo relevante a trazer luz sobre o tema foi o sempre citado paper do time da Google apresentado no jornal NeurIPS, que trata sobre o tema do débito técnico escondido nos sistemas de Machine Learning. Como é possível verificar na imagem abaixo, o código/script criado para treinar os modelos e servir, que costuma ser o maior foco de estudo dos Cientistas de Dados hoje em dia – principalmente apresentados nos cursos online -, é apenas um pequeno pedaço do quebra-cabeças de como montar um sistema de Machine Learning:

Quais as vantagens de adotar o MLOps?

Em termos gerais, o MLOps traz uma série de benefícios. Além de combinar as vantagens já conhecidas do DevOps (melhorar a qualidade e velocidade das entregas durante o ciclo de desenvolvimento), ele mantém uma maior organização sobre os dados, permitindo o treino contínuo de modelos e o monitoramento destes. Citamos aqui mais algumas vantagens:

  • Encurtar o ciclo de criação e produtização do modelo (começo ao fim)
  • Fornecer mais tempo para o Cientista de Dados gastar com exploração e desenvolvimento do modelo
  • Padronizar os fluxos de criação de novos modelos
  • Reutilizar dos componentes do pipeline de treino do modelo
  • Monitorar a qualidade do modelo ao longo do tempo
  • Conseguir maior controle sobre os custos relacionados ao ciclo de vida do sistema de ML

Por outro lado, apesar das muitas vantagens da adoção desse framework de trabalho, por se tratar de um campo novo e ainda em evolução, a implementação de projetos desse tipo não é nada fácil para marinheiros de primeira viagem.

 

Estágios de evolução do MLOps

 

Uma das maiores referências sobre o assunto, como já vimos antes, é a Google. O time de Cloud publicou um artigo muito esclarecedor sobre os estágios de evolução do MLOps dentro de uma empresa, separando em 3 níveis. Vamos resumir as principais características de cada um, para auxiliá-los a entender melhor onde sua empresa se encontra atualmente:

  • Nível 0: Processo Manual

Nessa etapa, a empresa ainda depende do esforço dos times para todas as fases da cadeia. Todo o processo de análise de dados, preparação dos dados para o modelo, treino e validação é realizada pelo cientista de dados; enquanto, geralmente, o time de engenharia é responsável por reaproveitar o modelo criado e colocá-lo em produção para apresentar os resultados. 

Outra característica comum dessa etapa é a falta de monitoramento do modelo em produção, trazendo diversos problemas como baixa performance e até tomadas de decisões erradas.

  • Nível 1: Automação do Pipeline

Nesse nível, a empresa já dispõe de um sistema automatizado de treino do modelo, no qual todos os passos necessários, como: validação e transformação dos dados de entrada, treino do modelo, medição de sua performance e validação do modelo final; que são automaticamente executados, assim que forem acionados por um gatilho externo (como um orquestrador, por exemplo). Existem alguns componentes novos que irão servir de base para o processo funcionar, como a Feature Store, por exemplo, que abordaremos mais a fundo em um próximo artigo.

Esse modelo permite uma rápida experimentação por parte dos cientistas de dados, além de uma maior confiabilidade do sistema devido ao seu treinamento contínuo (mantendo a qualidade) e também apresenta garantias do modelo ter sido testado em ambientes pré-produtivos. Outra grande vantagem é que os componentes do pipeline são modularizados por código, permitindo a independência dos pipelines, seu reaproveitamento em outros módulos (visto que cada componente pode ser composto de uma imagem diferente) e acelerando o seu desenvolvimento. 

Uma outra característica interessante é que o monitoramento dos sistemas de ML em produção geram estatísticas que, por si só, podem acionar um novo ciclo de treinamento. Isso garante que modelos com baixa performance, devido a mudanças de comportamento, serão novamente treinados e comparados com a versão anterior, que permite avaliar se o modelo terá uma melhor performance com dados atuais ou se será necessário uma análise mais detalhada de seu desempenho.

  • Nível 2: Automação do Pipeline com CI/CD

Esse nível traz uma evolução importante em relação ao anterior, que é a adição do pipeline de CI/CD (Continuous Integration/Continuous Delivery) ao nosso sistema de ML. Essa mudança pode ser percebida tanto no começo do ciclo – com um fluxo de testes e build dos módulos que serão utilizados no pipeline (validação, treino, etc.) -, quanto no meio e final, onde os modelos serão automaticamente colocados em produção para servir no produto ou aplicação que está sendo utilizado. Assim, todo o ciclo é automatizado do começo ao fim, com uma maior robustez e velocidade de implementação de projetos.

O código dos componentes e do seu modelo deverá ser guardado em um repositório de códigos (Git, Bickbucket, etc), que irá acionar o pipeline de CI/CD em qualquer alteração. Dessa forma, os componentes e o código do modelo serão testados e construídos nos ambientes específicos, garantindo que sua implementação esteja adequada, atualizando o pipeline para sua versão mais recente. Após entrar em produção, os modelos seguirão sendo treinados continuamente, conforme forem acionados por gatilhos do CI/CD, de orquestração ou de performance, garantindo que sua melhor versão (após validação) seja colocada em produção para servir à aplicação. 

 

Próximos Passos

 

Esperamos que esse artigo tenha ajudado a entender um pouco melhor o que é MLOps, suas vantagens e em qual estágio de evolução sua empresa se encontra. 

Em caso de qualquer dúvida ou para mais detalhes sobre o tema e os projetos que já implementamos, a Rox está pronta para te ajudar! 

Learn More

Rox Partner
23 de julho de 2021
banco de dados

Conheça o Kubernetes — Orquestração de aplicações em Contêiner

O Kubernetes – também conhecido como K8s (com o 8 representando o número de letras entre o “K” e o “S”) –  é um produto Open Source para implantar, escalonar e gerenciar aplicativos dentro de contêineres em qualquer lugar.

 

Um pouco da história

O projeto se baseia em 15 anos de experiência em execução de contêineres com a Borg – uma plataforma interna da Google. A plataforma Borg foi a predecessora do Kubernetes. As lições aprendidas com ela ao longo dos anos se tornaram a principal influência por trás de grande parte da tecnologia do Kubernetes.

 

Voltando no tempo para explicar a arquitetura

  • Implantação Tradicional: Se trata da execução de aplicações em servidores físicos. Com o tempo, essa arquitetura apresentou dificuldade de escalabilidade, pois a única forma de separar as aplicações e evitar problemas de concorrência de recursos seria executar cada aplicação em um servidor físico diferente. Na implantação tradicional, não havia como definir limites de recursos para aplicações; por isso existia a necessidade de manter muitos servidores, gastando muito mais dinheiro.
  • Implantação Virtualizada: A solução de virtualização foi introduzida como alternativa para a Implantação Tradicional. Nesse modelo, podemos executar diversas máquinas virtuais (VMs) em uma única CPU de um servidor físico. A virtualização permite isolar as aplicações entre as VMs – o que fornece segurança, pois não há compartilhamento livre de dados entre as aplicações. Também podemos aproveitar melhor os recursos de um servidor físico, solucionar o problema de escalabilidade, reduzir custos de hardware e muito mais – isso tudo porque cada VM é uma máquina completa, que possui o seu próprio sistema operacional, e executa todos os componentes necessários.
  • Implantação de Contêineres: Os contêineres trabalham em uma arquitetura semelhante ao modelo de máquinas virtuais, mas com um detalhe importante: eles permitem compartilhar o sistema operacional (SO) entre as aplicações, por isso são considerados “leves”. Um contêiner tem seu próprio sistema de arquivos e compartilhamento de memória CPU. Além disso, os contêineres são portáveis entre nuvens e distribuições de sistema operacional, pois na arquitetura eles estão separados da infraestrutura subjacente.

 

O que faz o Kubernetes?

O Kubernetes é o “capitão” que irá controlar (gerenciar) os contêineres, garantindo que o sistema continue funcionando como foi planejado. É responsável por transportar e entregar os contêineres com segurança para os locais onde possam ser usados. A plataforma agrupa os contêineres que compõem uma aplicação para facilitar o gerenciamento e escalonamento. Além disso, é possível definir o estado completo de um sistema, seguindo boas práticas de infraestrutura (como código), permitindo alta disponibilidade, balanceamento de carga, atualizações em lote, “rollbacks” e muito mais.

Vale ressaltar que existe um orquestrador concorrente chamado Docker Swarm, que também tem a proposta de gerenciar contêineres dentro de um cluster – mas, neste artigo, o nosso foco será o Kubernetes.

 

O que você precisa saber para começar a trabalhar com Kubernetes:

  • POD — É a unidade de contêiner dentro de um cluster Kubernetes. Um POD é um grupo de um ou mais contêineres, com recursos de armazenamento e de rede compartilhados.
  • Deployment (réplica) — É o que garante que os PODs/Contêineres funcionem. Permite identificar o estado desejado em uma implantação e o controlador altera do estado real, para o estado desejado da aplicação naquele momento.
  • Service — Fornece os endereços IP de cada POD e um único nome (DNS) para um conjunto de PODs. Este objeto é importante para viabilizar acesso externo e fazer o balanceamento de carga entre os PODs.

 

Alguns benefícios da plataforma:

  • Aumento da velocidade de desenvolvimento.
  • No mundo DevOps, o Kubernetes permite a separação de interesses entre Desenvolvimento e Operações.
  • Orquestramento os contêineres com aplicações através dos PODs, mantendo controle e o gerenciamento dos clusters de forma automatizada.
  • Flexibilidade para implantar aplicativos em qualquer lugar, permitindo implantações On-Premise, Cloud Pública ou até Cloud Híbrida.
  • Execução serviços eficientes, ajustando automaticamente o tamanho e/ou quantidade de Nós do cluster, permitindo escalonamento com base na demanda.
  • Monitoramento do funcionamento do serviço, executando verificações contínuas de integridade e reiniciando os contêineres que falharam.
  • Disponibilização dos serviços aos usuários quando a plataforma confirma que eles estão em execução.

Obs.: O monitoramento automático da plataforma não é baseado apenas nas informações e métricas no nível do sistema operacional, mas também na integridade da aplicação e outros sinais.

 

Breve demonstração dos componentes

Nesta etapa, vamos explicar de forma superficial alguns componentes da infraestrutura do Kubernetes.

Um cluster Kubernetes é um conjunto de máquinas chamadas de Nós (nodes), que executam os contêineres. Cada cluster tem, no mínimo, um Nó – também conhecido como “worker node”.

  • Os Nós hospedam os PODs, que são os componentes da carga de trabalho do aplicativo.
  • O plano de controle gerencia os Nós e os PODs no cluster.
  • O plano de controle normalmente é executado em vários computadores. Geralmente, um cluster executa vários Nós, fornecendo tolerância a falhas e alta disponibilidade.

 

Mas, afinal, qual a diferença entre Kubernetes e Docker?

As dúvidas surgem quando começamos a estudar contêineres e nos deparamos com tecnologias diferentes, mas com algo em comum. Portanto, neste artigo, vamos esclarecer uma das principais dúvidas sobre esse tema.

Algumas vezes interpretados como uma escolha entre um ou outro, o fato é que Kubernetes e Docker são tecnologias diferentes, mas complementares. A principal diferença é que o Kubernetes deve ser executado em um cluster, enquanto o Docker é executado em um único Nó.

Ok, mas isso eu já sabia! E quando usar um ou outro?

Vamos começar falando um pouco sobre o Docker. Podemos dizer que o Docker é a ferramenta padrão para implantar uma aplicação usando contêineres. Com a capacidade de empacotar uma aplicação, é a engine mais utilizada atualmente. O Docker permite empacotar todas as dependências necessárias para execução, como bibliotecas e o código da aplicação, em uma imagem que pode ser facilmente “versionada”. Depois de começar a empacotar os aplicativos, precisamos encontrar uma maneira de gerenciá-los, e é isso que o Kubernetes veio fazer.

 

Kubernetes como serviço em Cloud Computing

 

 

Os principais provedores de computação em nuvem fornecem o Kubernetes como serviço, também conhecido como CaaS (Container as a Service).

No formato CaaS, o objetivo é eliminar a necessidade de instalar e operar seu próprio plano de controle ou Nós de cluster, bem como os servidores de API e a camada de back-end.

O desenho acima demonstra que as camadas de Hardware, Virtualização e Sistema Operacional são gerenciadas pelo provedor do serviço. Ou seja: o cliente começa a operar a partir do contêiner. Na concorrência entre os provedores deste tipo de serviço, alguns fornecem facilidades e/ou diferenças dentro de cada ambiente – por isso vale um estudo específico antes de iniciar a implantação.

 

Alguns provedores que fornecem CaaS baseado em Kubernetes

  • Amazon Elastic Kubernetes Service (EKS)
  • Google Kubernetes Engine (GKE)
  • Azure Kubernetes Service (AKS)

 

Conclusão

Neste artigo, esclarecemos o funcionamento do Kubernetes, sem aprofundar muito na parte técnica da plataforma. Explicamos a importância do Kubernetes para a “Era” de implantação de contêineres, e como ele trabalha em conjunto com o Docker, que é fundamental para começar a trabalhar com essa tecnologia.

O Kubernetes pode ser útil para diversas soluções dentro de uma empresa, vem sendo muito utilizado para solucionar problemas de integração entre aplicações, viabilizar execução de aplicativos de micro serviços, automatizar captura de dados com robôs que são executados em contêineres e muito mais. Tudo isso utilizando os recursos computacionais de forma eficiente, para evitar gastos desnecessários com infraestrutura de TI.

Caso tenha interesse em saber mais, entre em contato com a nossa equipe ou consulte o site oficial do projeto.

 

Escrito por Kaique Vitiello, Engenheiro de Dados na Rox Partner.

Learn More

Rox Partner
21 de maio de 2021
banco de dados

Conheça os tipos de Cluster PostgreSQL Open Source

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 e é aí que contamos com o Cluster PostgreSQL. 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 Cluster 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 Cluster 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 Cluster 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.

RubyRep

Recursos

  • Replicação assíncrona, ou seja, os dados são “commitados” primeiro no Master Server e depois no slave de maneira independente
  • Capacidade suportar vários masters 
  • Baseada em em triggers

Desvantagens

  • Os comandos DDL (Data Definition Language), de criação de usuários e grants não são replicados
  • Mínimo de dois servidores

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 Cluster 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

Rox Partner
4 de maio de 2021
banco de dados

As diferentes sintaxes de um Backup Lógico

Se você presa por segurança, o backup lógico é uma das maneiras mais seguras de copiar seus dados.

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;

Nós cuidamos dos seus dados: Rox Partner

A Rox Partner é uma integradora de soluções e serviços com especialização em consultoria, sustentação e projetos de TI; com foco na entrega de soluções mais adequadas às necessidades de seus clientes.

Vamos conversar sobre a proteção da sua empresa? Entre em contato!

 

 

Learn More

Rox Partner
23 de março de 2021
Analyticsbanco de dadosCloudInfraestrutura

A Jornada Data Driven e como aplicá-la a sua empresa

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

Rox Partner
  • 1
  • 2
Posts recentes
  • Como ativar e configurar um Replica Set no seu servidor com MongoDB
  • Tipos de Backup e Recuperação de Banco de Dados no SQL Server
  • Entenda o ciclo de vida de uma Query no SQL Server: Parte 2
  • Entenda o ciclo de vida de uma Query no SQL Server: Parte 1
  • Conheça o Delta Lake
Soluções

Categorias
  • Analytics (2)
  • banco de dados (16)
  • Cloud (2)
  • Infraestrutura (4)
Tags
app Armazenamento de arquivos backup diferencial backup full backup log banco de dados bigdata cloud database data driven data engineering Delta Lake DML engenharia de dados etl ingestion mobile monitoramento mydumper nifi optane retenção script Spark SQL sqlserver sql server Storage Engine streamsets wallet

White Papers

Baixe Aqui
Localização
Av. Dr. Chucri Zaidan, 1550
conjunto 2105 | CEP 04711-130
São Paulo - Brasil
Contato
   contato@roxpartner.com
   +55 11 4040-8250
Newsletter

    Copyright © 2022 ROX Partners by lab212. All Rights Reserved

    #softlab_soc_icon_wrap_628d2aacc4b73 a{ background: #fcb813; border-color: #fcb813; }#softlab_soc_icon_wrap_628d2aacc4b73 a:hover{ background: #57a5be; border-color: #57a5be; }.softlab_module_social #soc_icon_628d2aacc4bb81{ color: #ffffff; }.softlab_module_social #soc_icon_628d2aacc4bb81:hover{ color: #ffffff; }.softlab_module_social #soc_icon_628d2aacc4bb81{ background: #fcb813; }.softlab_module_social #soc_icon_628d2aacc4bb81:hover{ background: #57a5be; }.softlab_module_social #soc_icon_628d2aacc4bd52{ color: #ffffff; }.softlab_module_social #soc_icon_628d2aacc4bd52:hover{ color: #ffffff; }.softlab_module_social #soc_icon_628d2aacc4bd52{ background: #fcb813; }.softlab_module_social #soc_icon_628d2aacc4bd52:hover{ background: #57a5be; }.softlab_module_social #soc_icon_628d2aacc4be83{ color: #ffffff; }.softlab_module_social #soc_icon_628d2aacc4be83:hover{ color: #ffffff; }.softlab_module_social #soc_icon_628d2aacc4be83{ background: #fcb813; }.softlab_module_social #soc_icon_628d2aacc4be83:hover{ background: #57a5be; }.softlab_module_social #soc_icon_628d2aacc4bf74{ color: #ffffff; }.softlab_module_social #soc_icon_628d2aacc4bf74:hover{ color: #ffffff; }.softlab_module_social #soc_icon_628d2aacc4bf74{ background: #fcb813; }.softlab_module_social #soc_icon_628d2aacc4bf74:hover{ background: #57a5be; }@media only screen and (max-width: 768px){ #softlab_spacer_628d2aacc56ba .spacing_size{ display: none; } #softlab_spacer_628d2aacc56ba .spacing_size-tablet{ display: block; } }
    Usamos cookies em nosso site para oferecer uma experiência mais relevante, lembrando suas preferências e visitas repetidas. Ao clicar em “Aceitar Tudo”, você concorda com o uso de TODOS os cookies. No entanto, você pode acessar as "Configurações de Cookies" para fornecer um consentimento controlado. Para mais detalhes acesse nossa Política de Privacidade.
    CONFIGURAÇÕES DE COOKIESACEITAR TODOS
    Política de Privacidade & Cookies

    Privacidade & Cookies

    Este site usa cookies para melhorar sua experiência de navegação. Destes, os cookies categorizados como Necessários são armazenados no seu navegador, pois são essenciais para o funcionamento de funções básicas do site. Também usamos cookies de terceiros que nos ajudam a analisar e entender como você usa este site e esses cookies serão armazenados no seu navegador apenas com o seu consentimento. Você também tem a opção de desativar esses cookies, mas a desativação de alguns deles pode afetar sua experiência de navegação.
    Necessário
    Sempre ativado
    Os cookies necessários são absolutamente essenciais para o bom funcionamento do site. Esses cookies garantem funcionalidades básicas e recursos de segurança do site, anonimamente.
    CookieDuraçãoDescrição
    _GRECAPTCHA5 meses e 27 diasEste cookie é definido pelo serviço de recaptcha do Google para identificar bots para proteger o site contra ataques de spam maliciosos.
    cookielawinfo-checkbox-advertisement1 anoEste cookie é usado para registrar o consentimento do usuário para os cookies na categoria "Anúncio", caso existam.
    cookielawinfo-checkbox-analytics11 mesesEste cookie é usado para armazenar o consentimento do usuário para os cookies na categoria "Analytics", caso existam.
    cookielawinfo-checkbox-functional11 mesesEste cookie é usado para armazenar o consentimento do usuário para os cookies na categoria "Funcionais", caso existam.
    cookielawinfo-checkbox-necessary11 mesesEste cookie é usado para armazenar o consentimento do usuário para os cookies na categoria "Necessário", caso existam.
    cookielawinfo-checkbox-others11 mesesEste cookie é usado para armazenar o consentimento do usuário para os cookies na categoria "Outros", caso existam.
    cookielawinfo-checkbox-performance11 mesesEste cookie é usado para armazenar o consentimento do usuário para os cookies na categoria "Performance", caso existam.
    viewed_cookie_policy11 mesesO cookie é usado para armazenar se o usuário consentiu ou não o uso de cookies. Ele não armazena nenhum dado pessoal.
    Analytics
    Os cookies analíticos são usados para entender como os visitantes interagem com o site. Esses cookies ajudam a fornecer informações sobre métricas de número de visitantes, taxa de rejeição, origem de tráfego, etc.
    CookieDuraçãoDescrição
    _ga2 anosO cookie _ga, instalado pelo Google Analytics, armazena informações anonimamente e atribui um número gerado aleatoriamente para reconhecer visitantes únicos.
    _ga_4RLBM0693H2 anosEste cookie é instalado pelo Google Analytics.
    _gat_gtag_UA_172713136_11 minutoDefinido pelo Google para distinguir usuários.
    _gid1 diaInstalado pelo Google Analytics, o cookie _gid armazena informações sobre como os visitantes usam um site, além de criar um relatório de análise de desempenho. Alguns dos dados coletados incluem o número de visitantes, sua fonte e as páginas que eles visitam anonimamente.
    _rdtrk9 anos 10 meses 14 dias 11 horas e 3 minutosUtilizado pelo RD Station para manter uma lista de todas as páginas que um visitante acessou dentro do domínio.
    CONSENTIMENTO2 anosO YouTube define esse cookie por meio de vídeos do youtube incorporados e registra dados estatísticos anônimos.
    rdtrk1 anoUtilizado pelo RD Station para manter uma lista de todas as páginas que um visitante acessou dentro do domínio.
    UID2 anosA Scorecard Research define esse cookie para pesquisa de comportamento do navegador.
    Anúncio
    Os cookies de publicidade são usados para fornecer aos visitantes anúncios e campanhas de marketing relevantes. Esses cookies coletam informações para fornecer anúncios personalizados.
    CookieDuraçãoDescrição
    VISITOR_INFO1_LIVE5 meses e 27 diasUm cookie definido pelo YouTube para medir a largura de banda que determina se o usuário obtém a interface do player nova ou antiga.
    YSCsessãoO cookie YSC é definido pelo Youtube e é usado para rastrear as visualizações de vídeos incorporados nas páginas do Youtube.
    yt-remote-connected-devicesnão expiraO YouTube define esse cookie para armazenar as preferências de vídeo do usuário usando o vídeo incorporado do YouTube.
    yt-remote-device-idnão expiraO YouTube define esse cookie para armazenar as preferências de vídeo do usuário usando o vídeo incorporado do YouTube.
    Outros
    São cookies não categorizados, aqueles que estão sendo analisados e ainda não foram classificados em uma categoria específica.
    CookieDuraçãoDescrição
    __trf.src1 anoUtilizado pelo RD Station, esse cookie guarda a referência da origem da visita do usuário ao site.
    SALVAR E ACEITAR
    Desenvolvido por CookieYes Logo
    Preencha os campos abaixo para realizar o download