PostGresql para data-warehouse: Melhor abordagem para ETL / extração de dados quase real

Question

Fundo:

Eu tenho um banco de dados PostgreSQL (v8.3) que é fortemente otimizado para OLTP.

Eu preciso extrair dados dele em tempo real (alguns são obrigados a perguntar o que significa em tempo real e a resposta é tão frequentemente quanto eu posso razoavelmente, mas serei pragmático, como uma referência, digamos que digamos que nós esperam a cada 15 minutos) e alimentá-lo em um armazenamento de dados.

Quantos dados? Nos horários de pico, estamos falando de aproximadamente 80-100k linhas por minuto, atingindo o lado OLTP, fora do pico, isso cairá significativamente para 15-20k. As linhas mais frequentemente atualizadas são ~ 64 bytes cada, mas existem várias tabelas, etc., para que os dados sejam bastante diversos e possam variar até 4000 bytes por linha. O OLTP está ativo 24x5.5.

Melhor solução?

Pelo que posso juntar, a solução mais prática é a seguinte:

• Crie um gatilho para escrever toda a atividade DML em um arquivo de log de CSV rotativo
• Execute quaisquer transformações necessárias
• Use a ferramenta de bomba de dados DW nativa para bombear com eficiência o CSV transformado no DW

Por que essa abordagem?

• Os gatilhos permitem que as tabelas seletivas sejam direcionadas, em vez de serem amplas, a saída + é configurável (ou seja, em um CSV) e é relativamente fácil de escrever e implantar. Slony usa abordagem semelhante e a sobrecarga é aceitável
• CSV fácil e rápido de transformar
• Fácil de bombear CSV para o DW

Alternativas consideradas ....

• Usando o registro nativo (http://www.postgresql.org/docs/8.3/static/runtime-config-logging.html). O problema disso é que parecia muito detalhado em relação ao que eu precisava e era um pouco mais complicado para analisar e transformar. No entanto, pode ser mais rápido, pois presumo que haja menos sobrecarga em comparação com um gatilho. Certamente isso tornaria o administrador mais fácil, pois é amplo do sistema, mas, novamente, não preciso de algumas das tabelas (algumas são usadas para armazenamento persistente de mensagens JMS que eu não quero registrar)
• Consultando os dados diretamente por meio de uma ferramenta ETL, como Talend e bombeando-os no DW ... o problema é que o esquema OLTP precisaria ajustar isso para apoiar isso e isso tem muitos efeitos colaterais negativos
• Usando um Slony ajustado/hackeado - Slony faz um bom trabalho de registro e migração de alterações para um escravo, para que a estrutura conceitual esteja lá, mas a solução proposta parece mais fácil e limpa
• Usando o Wal

Alguém já fez isso antes? Quer compartilhar seus pensamentos?

Answer 1

Supondo que suas tabelas de interesse tenham (ou podem ser aumentadas com) uma chave sequencial única, indexada, então você terá um valor muito melhor ao simplesmente emitir SELECT ... FROM table ... WHERE key > :last_max_key com saída em um arquivo, onde last_max_key é o último valor -chave da última extração (0 se a primeira extração.) Este A abordagem incremental e dissociada evita Apresentando Latência de acionar no banco de dados de inserção (Seja gatilhos personalizados ou Slony modificado) e, dependendo da sua configuração, pode escalar melhor com o número de CPUs etc. (no entanto, se você também precisar acompanhar UPDATEs, e a chave seqüencial foi adicionada por você, então seu UPDATE declarações devem SET a coluna chave para NULL Portanto, recebe um novo valor e é escolhido pela próxima extração. Você poderia não ser capaz de rastrear DELETEs sem gatilho.) É isso que você tinha em mente quando mencionou Talend?

Eu poderia não use a instalação de registro, a menos que você não possa implementar a solução acima; O registro provavelmente envolve travando no alto Para garantir que as linhas de toras sejam escritas sequencialmente e não se sobreponham/se substituem quando vários back -ends escreva no log (verifique a fonte do Postgres.) A sobrecarga de travamento pode não ser catastrófica, mas você pode ficar sem ele se puder usar o incremental SELECT alternativo. Além disso, O registro da declaração se afogaria quaisquer mensagens de aviso ou erro úteis e o A análise em si não será instantânea.

A menos que você esteja disposto a analisar WALS (incluindo rastreamento de estado da transação e estar pronto para reescrever o código toda vez que você atualiza o Postgres), eu também não usaria os WALs - a menos que você Tenha o hardware extra disponível, nesse caso, você poderia navio wals para outra máquina para extração (Na segunda máquina, você pode Use gatilhos descaradamente - ou mesmo o registro de declaração- já que o que quer que aconteça, não afeta INSERT/UPDATE/DELETE Desempenho na máquina principal.) Observe que o desempenho (na máquina principal), a menos que você possa escrever os logs em um SAN, você obterá um desempenho comparável (em termos de cache do sistema de arquivos, principalmente do envio de wals para uma máquina diferente, como executar o incremental SELECT.

Answer 2

Se você consegue pensar em uma 'tabela de soma de verificação' que contém apenas o ID e a 'soma de verificação', você não só pode fazer uma seleção rápida dos novos registros, mas também os registros alterados e excluídos.

A soma de verificação pode ser uma função de soma de verificação do CRC32 que você gosta.

Answer 3

A nova cláusula de conflito no PostgreSQL mudou a maneira como faço muitas atualizações. Eu puxo os novos dados (com base em um row_update_timestamp) para uma tabela de temperatura e depois em uma instrução SQL Inserir na tabela de destino na atualização de conflitos. Se sua tabela de destino for particionada, você precisará pular por alguns aros (ou seja, chegue diretamente na tabela de partições). O ETL pode acontecer à medida que você carrega a tabela de temperatura (provavelmente) ou no conflito SQL (se trivial). Comparado a outros sistemas "upsert" (atualizar, inserir se zero linhas etc.), isso mostra uma enorme melhoria de velocidade. Em nosso ambiente DW específico, não precisamos/queremos acomodar exclusão. Confira os documentos de conflito no conflito - ele dá a fusão da Oracle uma corrida pelo seu dinheiro!