Mimic-code: Não foi possível o arquivo estatístico chartevents.csv erro desconhecido

Criado em 29 out. 2018  ·  25Comentários  ·  Fonte: MIT-LCP/mimic-code

Pré-requisitos

Quando executo o script Postgres_load_data, as três primeiras tabelas são carregadas e depois disso recebo a mensagem: não foi possível o arquivo stat CHARTEVENTS.csv: erro desconhecido. Alguém tem essa situação e pode ajudar.

Comentários muito úteis

Ok, o could not stat file "CHARTEVENTS.csv": Unknown error é na verdade um bug no PostgreSQL 11. Nos bastidores, ele faz uma chamada para fstat() para ter certeza de que o arquivo não é um diretório e, infelizmente, fstat() é um programa de 32 bits que não pode lidar com arquivos grandes, como eventos gráficos. Testei a compilação no Windows com PostgreSQL 10.5 e não recebi esse erro, então acho que é relativamente novo.

A melhor solução é manter os arquivos compactados (ou seja, mantê-los como .csv.gz arquivos) e usar 7zip para carregar os dados diretamente dos arquivos compactados. Nos testes, isso ainda parecia funcionar. Há um tutorial bem detalhado sobre como fazer isso aqui: https://mimic.physionet.org/tutorials/install-mimic-locally-windows/

A versão resumida acima é que você mantém os arquivos .csv.gz , adiciona o binário 7zip ao caminho do ambiente do Windows e, em seguida, chama o arquivo postgres_load_data_7zip.sql para carregar os dados. Você pode usar o arquivo postgres_checks.sql depois de tudo para se certificar de que carregou todos os dados corretamente.

editar: para o seu erro posterior, onde você está usando esta abordagem 7zip, não tenho certeza por que não está carregando. Tente baixar novamente apenas o arquivo ADMISSIONS.csv.gz e veja se ele ainda gera o mesmo erro. Talvez haja uma nova versão do 7zip que exige que eu atualize o script ou algo assim!

Todos 25 comentários

Você verificou a integridade de sua cópia de chartevents.csv usando os arquivos de soma de verificação fornecidos na página de download do projeto? Talvez tenha sido corrompido durante o download ou descompactação.

Sim, usei o comando md5 checksum_md5_zipped.txt e está tudo OK com todas as tabelas ...

Também tentei com dados compactados e executei postgres_load_data script_7zip. Nesse caso, recebo: nova linha não citada encontrada nos dados. Dicas: use o campo CSV entre aspas para representar a nova linha.

Eu também verifiquei md5 checksum_md5_unzipped.txt e está tudo ok.

Parece que há uma incompatibilidade entre o script que você está executando e os dados que você possui. Eu me certificaria:

  1. Todos os arquivos estão no mesmo diretório
  2. Todos os arquivos têm a mesma extensão de arquivo; por exemplo, eles são todos .csv.gz
  3. Você está executando o arquivo postgres_load_data_7zip.sql (i) da mesma pasta ou (ii) após configurar mimic_data_dir para apontar para o diretório de dados.

Além disso, é realmente difícil depurar remotamente sem mais informações, como uma captura de tela da configuração da pasta, informações do sistema, os comandos exatos que você executou e a mensagem de erro exata.

Olá,

Obrigado pela sua resposta.

  1. Todos os arquivos estão no mesmo diretório
  2. Todos os arquivos têm a mesma extensão csv
  3. Estou executando o arquivo posgres_load_data.sql depois de configurar o mimic_data_dir para apontar para o diretório de dados.
    Aqui estão meus comandos exatos e o erro que recebi.
    step1
    step2
    system_information

Ótimo, isso é muito útil, obrigado pelas informações adicionais. Acho que é tão simples quanto o arquivo não estar na pasta. Você pode verificar se sua pasta C:/Users/Lejla/Desktop/MIMICIII contém o arquivo CHARTEVENTS.csv ?

Pode ser que você tenha tentado extrair todos os arquivos compactados, mas falhou em eventos gráficos e, portanto, você só tem um arquivo .csv.gz (os motivos podem ser porque o arquivo extraído tem 33 GB e você ficou sem espaço, ou seu sistema de arquivos é FAT32 (!), ou quem sabe). Nesse caso, você pode querer editar o script de carregamento para carregá-lo diretamente de .csv.gz . Você pode fazer isso substituindo:

\copy CHARTEVENTS from 'CHARTEVENTS.csv' delimiter ',' csv header NULL ''

com

\copy CHARTEVENTS from PROGRAM '7z e -so CHARTEVENTS.csv.gz' delimiter ',' csv header NULL ''

Muito obrigado pela resposta. Tentei desta vez trabalhar com um arquivo zip e executar um script para ele. Desta vez eu peguei outro
zip_file
mensagem ... Talvez ajude.

Importa-se de mostrar o conteúdo do diretório?

Eu não me importo. Há conteúdo da minha pasta
directory

Ok, o could not stat file "CHARTEVENTS.csv": Unknown error é na verdade um bug no PostgreSQL 11. Nos bastidores, ele faz uma chamada para fstat() para ter certeza de que o arquivo não é um diretório e, infelizmente, fstat() é um programa de 32 bits que não pode lidar com arquivos grandes, como eventos gráficos. Testei a compilação no Windows com PostgreSQL 10.5 e não recebi esse erro, então acho que é relativamente novo.

A melhor solução é manter os arquivos compactados (ou seja, mantê-los como .csv.gz arquivos) e usar 7zip para carregar os dados diretamente dos arquivos compactados. Nos testes, isso ainda parecia funcionar. Há um tutorial bem detalhado sobre como fazer isso aqui: https://mimic.physionet.org/tutorials/install-mimic-locally-windows/

A versão resumida acima é que você mantém os arquivos .csv.gz , adiciona o binário 7zip ao caminho do ambiente do Windows e, em seguida, chama o arquivo postgres_load_data_7zip.sql para carregar os dados. Você pode usar o arquivo postgres_checks.sql depois de tudo para se certificar de que carregou todos os dados corretamente.

editar: para o seu erro posterior, onde você está usando esta abordagem 7zip, não tenho certeza por que não está carregando. Tente baixar novamente apenas o arquivo ADMISSIONS.csv.gz e veja se ele ainda gera o mesmo erro. Talvez haja uma nova versão do 7zip que exige que eu atualize o script ou algo assim!

Olá,
Obrigado pela explicação detalhada. Instalei o PostgreSQL 10.5 e agora o processo está em execução. Acho que vai demorar muito para carregar todas as tabelas, mas não recebo mais "Erro desconhecido". Muito obrigado por toda ajuda.

Excelente!

Ok, o could not stat file "CHARTEVENTS.csv": Unknown error é na verdade um bug no PostgreSQL 11. Nos bastidores, ele faz uma chamada para fstat() para ter certeza de que o arquivo não é um diretório e, infelizmente, fstat() é um programa de 32 bits que não pode lidar com arquivos grandes, como eventos gráficos. Testei a compilação no Windows com PostgreSQL 10.5 e não recebi esse erro, então acho que é relativamente novo.

A melhor solução é manter os arquivos compactados (ou seja, mantê-los como .csv.gz arquivos) e usar 7zip para carregar os dados diretamente dos arquivos compactados. Nos testes, isso ainda parecia funcionar. Há um tutorial bem detalhado sobre como fazer isso aqui: https://mimic.physionet.org/tutorials/install-mimic-locally-windows/

A versão resumida acima é que você mantém os arquivos .csv.gz , adiciona o binário 7zip ao caminho do ambiente do Windows e, em seguida, chama o arquivo postgres_load_data_7zip.sql para carregar os dados. Você pode usar o arquivo postgres_checks.sql depois de tudo para se certificar de que carregou todos os dados corretamente.

editar: para o seu erro posterior, onde você está usando esta abordagem 7zip, não tenho certeza por que não está carregando. Tente baixar novamente apenas o arquivo ADMISSIONS.csv.gz e veja se ele ainda gera o mesmo erro. Talvez haja uma nova versão do 7zip que exige que eu atualize o script ou algo assim!

Usar o PostgreSQL 10.11 me ajudou ... obrigado

Ótimo, isso é muito útil, obrigado pelas informações adicionais. Acho que é tão simples quanto o arquivo não estar na pasta. Você pode verificar se sua pasta C:/Users/Lejla/Desktop/MIMICIII contém o arquivo CHARTEVENTS.csv ?

Pode ser que você tenha tentado extrair todos os arquivos compactados, mas falhou em eventos gráficos e, portanto, você só tem um arquivo .csv.gz (os motivos podem ser porque o arquivo extraído tem 33 GB e você ficou sem espaço, ou seu sistema de arquivos é FAT32 (!), ou quem sabe). Nesse caso, você pode querer editar o script de carregamento para carregá-lo diretamente de .csv.gz . Você pode fazer isso substituindo:

\copy CHARTEVENTS from 'CHARTEVENTS.csv' delimiter ',' csv header NULL ''

com

\copy CHARTEVENTS from PROGRAM '7z e -so CHARTEVENTS.csv.gz' delimiter ',' csv header NULL ''

Obrigado, isso funcionou para mim:
\ copie my_table_name do programa 'cmd / c digite input_data.csv' delimitador ',' cabeçalho csv;
input_data.csv como tamanho de 11 GB.

O problema com "não é possível copiar arquivos grandes" é para as versões 11 e 12. Mas para 10 está ok. Como substituí-lo sem compactar os arquivos de dados, mas talvez fazer o upsert / trocar alguns arquivos do programa Postgresql de v.10 para v 11 e 12?
Gambiarra:
copie t (c, d) do programa 'cmd / c "digite x: \ pathto \ file.txt"' com (formatar texto);
-é muito lento para minhas necessidades. Preciso da velocidade do comando de cópia padrão

Você pode considerar o uso de outras ferramentas de linha de comando para dividir o arquivo em vários arquivos e, em seguida, carregar os arquivos individuais um de cada vez. Em sistemas unix, isso pode ser feito usando split e você pode instalar o GNU coreutils para Windows para usá-lo.

Acho que encontrei o mesmo problema que você, mas estou usando a nova versão 12. Existe alguma maneira de resolver isso? Usar arquivos compactados?

Sim, se bem me lembro, os arquivos compactados têm menos de 4 GB e você evita esse erro usando os scripts de carregamento compactados (7z ou gzip).

OK, vou tentar este método agora, muito obrigado pela sua resposta

Portanto, nenhuma solução alternativa SEM usar compactação ou divisão? Uso da versão 10 do comando COPY do Postgresql para o mecanismo 11, 12?
Conforme mencionei:
Preciso da velocidade do comando Copiar padrão, mas para arquivos grandes + versão 12
e isso é vital para minhas necessidades.

Bem, o PostgreSQL é open source, então você pode tentar contribuir com uma correção :)

Aqui está a discussão relevante: https://www.postgresql.org/message-id/20181104000405.GA1743%40paquier.xyz

Caso contrário, você tem as três soluções alternativas propostas neste tópico (alterar a versão, usar arquivos compactados, dividir o arquivo em várias partes). Tenho certeza de que existem outras soluções alternativas.

Não é óbvio migrar a parte funcional do código da versão 10 da funcionalidade do COPY para o 11 e o 12? Ou é tão codificado que causa travamento para todos? :)

@ghYura este é um recurso mantido pela comunidade, então se você tiver sugestões para melhorar a base de código, eu sugiro fazer uma solicitação de pull.

Eu estava recebendo o erro ao carregar os CSVs nas tabelas nas versões 12.X e 13.X, mas funciona perfeitamente no PostgreSQL versão 10.15. Obrigado a todos pela ajuda :)

Esta página foi útil?
0 / 5 - 0 avaliações