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

Conheça o Apache Airflow – a solução perfeita para orquestrar fluxos de dados

Um dos principais desafios para as empresas que trabalham com dados hoje em dia é garantir que a execução e manutenção dos fluxos de dados ocorra da forma mais harmônica possível. É essencial que se mantenha dentro dos horários previstos e que todos os usuários responsáveis sejam alertados e tenham visibilidade caso algum problema ocorra. E é exatamente isso que o Airflow veio resolver.

O projeto do Apache Airflow se iniciou como um piloto dentro do Airbnb, em 2015, e desde então vem sendo adotado pelas maiores empresas do mundo todo, se tornando hoje a principal referência em ferramentas de orquestração no universo de dados. No final de 2020, a versão 2.0 foi oficialmente lançada, mostrando a maturidade do projeto e contínua evolução com apoio da comunidade, incluindo diversas melhorias tanto na experiência do usuário (melhorias na UI, Task Flow API, etc.), quanto em segurança e infraestrutura.

 

Utilização

Uma das maiores dificuldades para os iniciantes do Airflow é definir qual será o ambiente e infraestrutura para rodar sua aplicação. Por se tratar de uma ferramenta open-source, com grande apoio da comunidade, existem muitas alternativas para rodá-la. 

É claro que essa escolha vai depender sempre dos requisitos técnicos e financeiros que você dispõe no momento. Porém, os casos mais comuns hoje são instâncias virtuais, Kubernetes e ambientes gerenciados. Para esse último, existem algumas opções oferecidas por players de cloud, como GCP Cloud Orchestrator, AWS Managed Workflows, e também SaaS, onde destacamos a empresa Astronomer, grande incentivadora da comunidade e uma importante responsável pela divulgação do Airflow no mercado.

Após definir a infraestrutura e rodar seu ambiente de Airflow, podemos iniciar a criação de nossos fluxos de dados. O projeto todo do Airflow foi desenvolvido em Python; logo, sua utilização pelos usuários também será feita dessa maneira. 

 

Vantagens do Airflow

Embora existam outras opções concorrentes ao Airflow no mercado (como Luigi, Argo e Prefect), pode-se dizer que ela se tornou a solução mais querida e adotada para orquestração e agendamento de tarefas. Aqui estão algumas características pelas quais o Airflow se destaca:

  • Desenvolvimento todo em Python com baixo grau de complexidade
  • Integração com as ferramentas mais importantes do universo de dados
  • Documentação acessível e muito conteúdo produzido pela comunidade
  • Facilidade de criar e alterar fluxos simples e complexos de dados (DAGs, XCom)
  • Interface gráfica para acompanhamento dos jobs
  • Possibilidade de criação de componentes personalizados
  • Disponibilização de logs para auditoria de erros
  • Criar sistema de alertas com integração para Slack, E-mail, entre outros

 

Conceitos principais para entender o Airflow

Para um entendimento rápido de como funciona a arquitetura dos fluxos no Airflow, podemos focar nos principais componentes:

  • DAGs: Abreviação de Direct Acyclic Graph, é a estrutura principal que representa um fluxo de dados. Poderia ser equivalente a um pipeline de dados. Geralmente, dentro de uma empresa, teremos várias DAGs, e cada uma terá uma função específica e geralmente independente (ex: Pipeline Dados A, Pipeline Dados B).
  • Tasks: Tarefas que serão executadas dentro da sua DAG. Uma DAG pode ter uma ou várias tasks atreladas. Alguns exemplos de tarefas são: execuções de scripts em Python, Bash, Spark, entre outras. Para que possamos escolher qual tipo de tarefa a Task irá executar e seus parâmetros, devemos atribuir um Operator para ela. As dependências entre uma task e outra são declaradas via script de maneira prática, formando a lógica do fluxo da DAG.
  • Operators: São os componentes pré-definidos (template) para executar as Tasks. Os componentes mais comuns são o BashOperator, PythonOperator, EmailOperator, entre outros. Existem de centenas a milhares de componentes das mais diversas tecnologias, prontos para serem utilizados. Porém, é possível desenvolver operadores personalizados caso necessário.
  • Executor: É o mecanismo que será responsável por executar as Tasks – o motor de execução. O Airflow só poderá ter um executor definido para seu ambiente. Alguns exemplos são: KubernetesExecutor, SequentialExecutor e LocalExecutor
  • Scheduler: Um dos principais componentes do Airflow, é o responsável por monitorar as execuções das DAGs e iniciar novas tarefas quando elas estiverem disponíveis, nos horários estimados.

 

Conclusão

O Airflow se tornou quase uma unanimidade no universo de dados hoje em dia, sendo utilizado por empresas como Airbnb, Walmart, Facebook, Adobe, entre outras. A Rox é especializada na implementação de projetos de dados com Airflow, e tem vários clientes que já se beneficiam dessa ferramenta, além de contar com profissionais certificados. 

Se você está interessado em saber mais, entre em contato com nosso time ou consulte o site oficial do projeto aberto.

Learn More

Gerenciamento de disco e volume group no Linux

O gerenciamento de disco é uma ferramenta extremamente útil em qualquer sistema operacional, que permite executar tarefas avançadas em relação ao armazenamento e gerenciar as unidades que estão instaladas em um computador. Esse utilitário apresenta uma série de tarefas, como adicionar storage device, criar e estender partição, criar sistemas de arquivo, reconhecer discos, gerar volume de grupo etc.

Apesar de ser executável em praticamente todos os sistemas operacionais, é preciso mencionar que cada ferramenta possui suas próprias peculiaridades. Neste tutorial, abordaremos o uso de disco especificamente em Linux, testado em sistemas CentOS, RedHat e Oracle Linux, mas facilmente adaptável para outros sistemas Linux. 

Principais comandos de gerenciamento de disco em Linux

lsblk

Esse comando mostra os dispositivos físicos, lógicos, device manager, tipo e ponto de montagem.

É bastante usado para identificar novos discos ou LUNs, que são entregues para o servidor e que ainda não foram usados, e para evitar o erro de usar discos que já estão em uso, como o RAW, usado pelo Oracle.


blkid

Programa usado para identificação do sistema de arquivo usado pelo bloco de disco ou partição.


fdisk

Usado para criação de partição para discos de no máximo de 2TB.

parted 

Trata-se de um programa para particionar discos. Geralmente, é usado para discos maiores que 2TB, mas pode ser usado para discos menores também.

Agrupamento de discos e Volume Group

Volume Group é uma feature do Linux, que possibilita agrupar múltiplos discos em um único volume. No caso de partições cheias, essa ferramenta também habilita a expansão de volume lógico. Os Volume Groups podem ser, basicamente, divididos em 3 itens: 

Physical Volume

 É o disco ou a LUN usado para criar o VG. São usados os comandos pvscan e pvdisplay para visualização. 

Volume Group

Usado para configurar um ou mais discos ou LUNs, formando um só volume.

São usados os comandos vgscan e vgdisplay para visualização.


Logical Volume 

Usado para configurar as partições lógicas. São usados os comandos lvscan e lvdisplay para visualização. 


Como fazer a configuração de um VG

Aqui, vamos mostrar como fazer a configuração de um Volume Group e cada uma de suas etapas, desde o reconhecimento do disco, criação de uma partição com fdisk, configuração do PV, VG, LV, criação do filesystem, montagem e, por fim,a expansão do LV.

Reconhecimento do Disco

Essa etapa é importante, pois há risco de utilização de discos que já estão em uso; portanto, estes precisam ser bem identificados. Serão usados os comandos lsblk para identificar o disco, e blkid para confirmar que não há sistema de arquivos ou RAW nesse disco.


Criar a partição LVM

  1. Com o comando fdisk /dev/sdf, temos acesso ao disco para criar a partição. Digitar a letra p, para mostrar informações do disco, e certificar que não há partição criada.

2. Nesse caso, vamos usar todo o disco para criar a partição.Usar o comando n e. Depois, apertar a tecla enter três vezes.

3. Para alterar o tipo de partição para LVM, usar o comando t, depois 8e e teclar Enter.

4. Usar o comando p novamente para mostrar a partição que foi criada.

5. Usar o comando w para salvar e sair.


Configurar o VG

  1. Para configurar o physical volume: pvcreate /dev/sdf1

2. Para configurar o volume group: vgcreate teste-vg /dev/sdf1

3. Para configurar o logical volume com 50GB: lvcreate -L+50G teste-vg -n dados

4. Verificando as configurações realizadas

5. Criando o filesystem XFS

6. Montando a partição

7. Verificando a partição montada 

8. Para expandir a partição no VG e no filesystem em 15GB: lvextend -L+15G /dev/teste-vg/dados

9. xfs_growfs /dev/teste-vg/dados

10.  Verificando que a partição que antes tinha 50GB agora está com 65GB

Learn More

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

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

As diferentes sintaxes de um Backup Lógico

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

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