Introdução
Um espaço comunitário mantém suas visitas confirmadas em um arquivo histórico do Hive. Uma correção aprovada substitui o conjunto completo de registros confirmados de uma data. Ela não é um complemento a ser acrescentado às linhas anteriores. Uma das datas aprovadas agora tem duas visitas confirmadas; a outra não tem nenhuma. As demais datas, incluindo uma visita adicionada posteriormente, devem permanecer intactas.
Você comparará acréscimo e substituição em tabelas de prática, depois salvará e executará um arquivo SQL com um escopo restrito no arquivo histórico ORC real. Também executará esse mesmo arquivo novamente e fará outra leitura do resultado. O ambiente já executa Hive e HDFS e contém registros originais, candidatos a correção e o arquivo histórico, todos independentes.
Você já deve conhecer tabelas externas do Hive, SELECT com WHERE, colunas de particionamento, ORC e caminhos básicos do HDFS. Este laboratório apresenta partições de destino estáticas e a substituição de uma data inteira. Todo o trabalho usa a aba Terminal. A duração de 65 minutos é uma estimativa do autor que inclui leitura e erros comuns.
Compare acréscimo e substituição com segurança
Nesta etapa, você lerá um dia normal do arquivo histórico e comparará três escopos de escrita em tabelas de prática. Mantenha o arquivo histórico real intacto durante essa comparação.
Abra Terminal. Use o diretório de trabalho preparado durante todo o laboratório:
cd /home/labex/project
O diretório local venue contém arquivos CSV de referência e uma lista de aprovação. cat exibe um arquivo sem editá-lo:
cat venue/approved-days.txt
2026-10-02
2026-10-03
Essas são as únicas datas que você pode substituir no arquivo histórico real. Primeiro, leia um dia normal. Beeline envia SQL ao HiveServer2. No comando abaixo, -u fornece o endereço de conexão JDBC, -n labex fornece o nome de usuário do cliente e -e fornece o texto SQL. As aspas duplas mantêm esse texto como um único argumento do shell; as aspas simples dentro delas delimitam valores SQL. DATE '...' explicita o tipo de data.
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "SELECT * FROM venue_archive.archive WHERE visit_date=DATE '2026-10-04' ORDER BY visit_id;"
Leia as linhas de dados abaixo dos avisos de inicialização. Essa data tem v4 / Music / 4 e v5 / LateWalk / 2. A visita adicionada posteriormente, v5, é válida e deve permanecer. A imagem pode imprimir avisos SLF4J sobre várias associações de logging; eles são diferentes de erros SQL. Espere o comando retornar ao prompt antes de continuar.
Agora examine toda a fonte de candidatos, incluindo os registros cancelados:
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "SELECT * FROM venue_archive.candidate ORDER BY visit_date,visit_id;"
O dia 2 de outubro tem c21 / PrintWorkshop / 5 e c22 / Bookbinding / 2, ambos com status confirmed. O dia 3 de outubro tem uma linha cancelled. O arquivo histórico guarda apenas linhas confirmed, portanto o conjunto correto de substituição de 3 de outubro é vazio. A ausência de uma data no resultado filtrado não significa “deixe os dados antigos dessa data como estão”. A aprovação e o filtro de linhas confirmadas respondem a perguntas diferentes.
Verifique onde as três tabelas reais leem e escrevem. DESCRIBE FORMATTED acrescenta metadados de armazenamento às definições das colunas: encontre Table Type, Location e InputFormat em cada resultado. A saída longa também contém detalhes do mecanismo; concentre-se nesses campos antes de qualquer escrita.
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "DESCRIBE FORMATTED venue_archive.raw; DESCRIBE FORMATTED venue_archive.candidate; DESCRIBE FORMATTED venue_archive.archive;"
As três são objetos EXTERNAL_TABLE. A localização dos dados originais é hdfs://localhost:9000/user/labex/venue-archive/raw; a localização dos candidatos termina em /user/labex/venue-archive/candidate. Ambas usam entrada de texto. A localização do arquivo histórico é hdfs://localhost:9000/warehouse/external/venue_archive.db/archive, e seu formato de entrada termina em OrcInputFormat. Os arquivos locais venue/*.csv são cópias de referência, não o arquivo histórico. Preserve os mapeamentos e os arquivos de origem fornecidos.
Antes de alterar o arquivo histórico real, use duas tabelas de prática: practice_days tem partições por data; practice_whole armazena a data como uma coluna comum. Inicialmente, elas contêm as visitas confirmadas dos dados originais. Os próximos comandos demonstram intencionalmente resultados incorretos apenas nessas tabelas de prática.
INSERT INTO acrescenta linhas. PARTITION(visit_date='2026-10-02') é uma partição de destino estática: a data literal determina para onde vai cada linha selecionada. Portanto, o SELECT deve retornar apenas as três colunas que não são de particionamento. Sua condição WHERE separada seleciona as linhas da fonte. Definir o destino não filtra a fonte automaticamente.
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "INSERT INTO TABLE venue_archive.practice_days PARTITION(visit_date='2026-10-02') SELECT visit_id,activity,visitors FROM venue_archive.candidate WHERE visit_date=DATE '2026-10-02' AND record_status='confirmed'; SELECT * FROM venue_archive.practice_days WHERE visit_date=DATE '2026-10-02' ORDER BY visit_id;"
O resultado tem c21, c22 e o antigo v2. O SQL foi executado com sucesso, mas o contrato de substituição não foi cumprido. Acrescentar a mesma correção novamente criaria mais duplicatas.
INSERT OVERWRITE substitui as linhas existentes do destino. Na tabela não particionada practice_whole, o destino é a tabela inteira. Observe as outras datas desaparecerem:
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "INSERT OVERWRITE TABLE venue_archive.practice_whole SELECT visit_id,activity,visitors,visit_date FROM venue_archive.candidate WHERE visit_date=DATE '2026-10-02' AND record_status='confirmed'; SELECT * FROM venue_archive.practice_whole ORDER BY visit_date,visit_id;"
Restam apenas as duas linhas de 2 de outubro. Uma escrita bem-sucedida na tabela inteira pode eliminar silenciosamente datas não relacionadas. Restaure essa tabela de prática a partir de sua fonte original completa:
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "INSERT OVERWRITE TABLE venue_archive.practice_whole SELECT visit_id,activity,visitors,visit_date FROM venue_archive.raw WHERE record_status='confirmed'; SELECT * FROM venue_archive.practice_whole ORDER BY visit_date,visit_id;"
As cinco linhas originais retornam. Por fim, combine OVERWRITE com uma partição de data estática em practice_days:
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "INSERT OVERWRITE TABLE venue_archive.practice_days PARTITION(visit_date='2026-10-02') SELECT visit_id,activity,visitors FROM venue_archive.candidate WHERE visit_date=DATE '2026-10-02' AND record_status='confirmed'; SELECT * FROM venue_archive.practice_days ORDER BY visit_date,visit_id;"
Há seis linhas: a original de 1º de outubro, as duas corrigidas de 2 de outubro, a original de 3 de outubro e as duas visitas de 4 de outubro. O antigo v2 desapareceu. Esse é o escopo de escrita necessário para o arquivo histórico real.
Se Beeline informar um nome de tabela inválido, o SQL não encontrou o objeto pretendido. Confira a grafia com o comando somente de leitura já conhecido abaixo e execute novamente o comando corrigido. Você pode investigar um erro de caminho com pwd e ls venue; volte com o comando cd acima. Não recrie tabelas nem execute a configuração do ambiente novamente para corrigir um erro de digitação.
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "SHOW TABLES IN venue_archive;"
Antes de verificar esta etapa, confirme que a partição de prática contém exatamente c21 e c22 em 2 de outubro, que a prática de tabela inteira voltou a ter suas cinco linhas originais e que o arquivo histórico real ainda tem seus dados originais.
Substitua a data aprovada com registros confirmados
Nesta etapa, você salvará e executará a substituição real de 2 de outubro. Continue em Terminal, em /home/labex/project.
A tabela real venue_archive.archive é uma tabela ORC externa e não transacional com partições visit_date DATE. Suas fontes original e de candidatos são tabelas externas independentes de texto delimitado por vírgulas. Você pode substituir apenas datas aprovadas do arquivo histórico. Não pode editar arquivos de origem, alterar definições ou localizações de tabelas, remapear partições, criar datas extras ou reconstruir todo o arquivo histórico. Os dias 1º e 4 de outubro devem manter seus dados originais e os arquivos HDFS existentes. Reescrever linhas idênticas também está fora do escopo aprovado.
Examine a lista real de partições e a disposição das colunas antes de escrever. SHOW PARTITIONS lista as partições de data registradas; DESCRIBE mostra as colunas comuns seguidas das informações de particionamento:
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "SHOW PARTITIONS venue_archive.archive; DESCRIBE venue_archive.archive;"
As quatro datas vão de 1º a 4 de outubro. As colunas comuns são visit_id STRING, activity STRING e visitors INT; visit_date DATE é a coluna de particionamento. Mantenha esse mapeamento e o formato ORC intactos.
Salve seu SQL em um arquivo editável para poder examinar, corrigir e repetir a mesma operação. nano é um editor de texto dentro de Terminal. O comando abaixo abre replace-approved-days.sql no diretório de trabalho atual; como este é um arquivo novo, a área de edição inicialmente fica vazia:
nano replace-approved-days.sql
Digite as cinco linhas SQL abaixo no nano, não no prompt do shell. Aspas simples delimitam valores SQL e o ponto e vírgula encerra a instrução. Pare depois do último ponto e vírgula sem acrescentar uma linha vazia extra; nano fornece a quebra de linha final ao salvar:
INSERT OVERWRITE TABLE venue_archive.archive
PARTITION(visit_date='2026-10-02')
SELECT visit_id,activity,visitors
FROM venue_archive.candidate
WHERE visit_date=DATE '2026-10-02' AND record_status='confirmed';
Use as setas para chegar a um caractere que precisa de correção; Home e End levam ao início e ao fim da linha atual. Backspace apaga o caractere à esquerda do cursor; Delete apaga o caractere na posição do cursor. Digite o texto corrigido no lugar. O rodapé do nano usa ^ para indicar Ctrl. Pressione Ctrl+O para salvar: em File Name to Write, mantenha o nome exibido e pressione Enter. Depois pressione Ctrl+X para sair. Espere o prompt do shell voltar; o SQL deve ser digitado no editor, enquanto os comandos seguintes devem ser executados nesse prompt.
Leia o que você salvou antes de executar:
cat replace-approved-days.sql
Confira as duas datas da instrução: o destino estático e o filtro da fonte devem indicar 2 de outubro. A correção é o conjunto confirmado completo, incluindo c21 e c22. Não é necessário combinar IDs de visitas antigos nem atualizar linhas individuais.
O -f do Beeline lê SQL de um arquivo. Execute seu arquivo salvo:
beeline -u jdbc:hive2://localhost:10000/default -n labex -f replace-approved-days.sql
Depois leia todas as quatro datas como um consumidor do arquivo histórico faria:
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "SELECT visit_date,visit_id,activity,visitors FROM venue_archive.archive ORDER BY visit_date,visit_id;"
Espere seis linhas. O dia 2 de outubro contém c21 / PrintWorkshop / 5 e c22 / Bookbinding / 2, sem v2. O dia 3 de outubro ainda tem o antigo v3 por enquanto. O v1 de 1º de outubro e os registros v4 e v5 de 4 de outubro permanecem intactos.
A conexão Beeline identifica você como labex. HiveServer2 realiza as escritas de armazenamento como seu usuário de serviço hive, portanto os novos arquivos ORC podem pertencer a hive:bigdata. Você não precisa alterar a propriedade ou as permissões deles. O NameNode do HDFS é executado com sua própria identidade de serviço hdfs.
Se uma instrução SQL tiver um erro de sintaxe, examine o arquivo salvo com cat e reabra-o com nano replace-approved-days.sql. Use as setas para localizar a instrução indicada no erro do Beeline. Corrija o nome da tabela, as datas, as aspas ou o ponto e vírgula conforme necessário, preservando as outras linhas SQL. Salve com Ctrl+O, Enter e saia com Ctrl+X. Leia o arquivo novamente antes de repetir -f. Se você acrescentou linhas acidentalmente a essa data aprovada, a mesma sobrescrita correta da partição remove as linhas obsoletas e duplicadas. Essa recuperação se aplica à data aprovada; ela não autoriza reconstruir uma data protegida.
Aplique uma substituição por conjunto vazio e repita o arquivo
Nesta etapa, você esvaziará a partição aprovada de 3 de outubro, depois executará seu arquivo completo de correção duas vezes e verificará se o arquivo histórico não acumula linhas. Continue em Terminal, em /home/labex/project.
Um cancelamento também é uma correção. A lista de aprovação inclui 3 de outubro, mas seus candidatos não têm visitas confirmadas. Primeiro execute a seleção da fonte:
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "SELECT visit_id,activity,visitors FROM venue_archive.candidate WHERE visit_date=DATE '2026-10-03' AND record_status='confirmed';"
Não há linhas de dados. O arquivo histórico final correto também não deve ter linhas nessa data. Pular a escrita deixaria o antigo v3 no lugar.
Reabra o mesmo arquivo. Preserve a instrução de 2 de outubro; você acrescentará uma instrução, sem copiar a primeira novamente:
nano replace-approved-days.sql
Use a Seta para baixo para chegar à linha vazia depois do ponto e vírgula da primeira instrução e End se precisar chegar ao fim dessa linha. Nessa linha vazia, pressione Enter uma vez para deixar uma linha em branco entre as instruções. Depois digite apenas as cinco linhas novas abaixo. Pare depois do ponto e vírgula final sem acrescentar uma linha vazia extra. Se estiver retomando uma edição interrompida, primeiro confira se essa instrução de 3 de outubro já existe; corrija-a em vez de acrescentar uma duplicata.
INSERT OVERWRITE TABLE venue_archive.archive
PARTITION(visit_date='2026-10-03')
SELECT visit_id,activity,visitors
FROM venue_archive.candidate
WHERE visit_date=DATE '2026-10-03' AND record_status='confirmed';
Salve com Ctrl+O, Enter e saia com Ctrl+X. Leia o arquivo salvo completo no prompt do shell:
cat replace-approved-days.sql
Confira se ele contém exatamente duas instruções: a original de 2 de outubro seguida da nova de 3 de outubro. Em cada uma, tanto o destino estático quanto o filtro da fonte devem indicar a data aprovada daquela instrução. Se algo estiver errado, reabra o mesmo arquivo no nano, corrija apenas as linhas afetadas, salve e examine novamente.
Execute este arquivo salvo completo pela primeira vez:
beeline -u jdbc:hive2://localhost:10000/default -n labex -f replace-approved-days.sql
Uma sobrescrita estática com uma seleção vazia remove as linhas antigas da partição de destino. Ela mantém a data registrada. O mecanismo de armazenamento decide se uma partição vazia tem arquivos físicos; não crie arquivos CSV ou ORC de preenchimento por conta própria.
Leia as datas registradas e o resultado completo:
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "SHOW PARTITIONS venue_archive.archive; SELECT visit_date,visit_id,activity,visitors FROM venue_archive.archive ORDER BY visit_date,visit_id; SELECT COUNT(*) FROM venue_archive.archive WHERE visit_date=DATE '2026-10-03';"
As quatro partições continuam listadas. O resultado completo tem cinco linhas: v1, c21, c22, v4 e v5. A contagem de 3 de outubro é 0. Uma lista de aprovação com duas datas não implica duas partições não vazias.
Agora execute o mesmo arquivo salvo novamente, sem alterá-lo:
beeline -u jdbc:hive2://localhost:10000/default -n labex -f replace-approved-days.sql
Repita a leitura do arquivo histórico:
beeline -u jdbc:hive2://localhost:10000/default -n labex -e "SELECT visit_date,visit_id,activity,visitors FROM venue_archive.archive ORDER BY visit_date,visit_id; SELECT COUNT(*) FROM venue_archive.archive;"
As mesmas cinco linhas permanecem, e o total é 5. Essa substituição é repetível para as fontes fornecidas: ela não acrescenta duplicatas. Uma repetição pode recriar os arquivos das partições aprovadas; os arquivos originais das datas fora do alvo devem permanecer intocados.
Você pode examinar a fonte original usando comandos HDFS conhecidos. Aqui, -cat lê o arquivo de origem exato; ele não lê o arquivo histórico ORC derivado:
hdfs dfs -cat /user/labex/venue-archive/raw/raw.csv
Ele ainda contém os registros originais v2 e v3. Alterar um arquivo histórico derivado não reescreve seu histórico bruto. Os candidatos e a lista de aprovação também devem permanecer como foram fornecidos. Mantenha seu arquivo SQL no diretório de trabalho. As verificações observam os dados atuais do Hive, as definições, o escopo e os arquivos protegidos; elas não executam SQL salvo arbitrário. A repetição real e as leituras do resultado são sua autoverificação da operação salva.
Resumo
Você comparou acréscimo, substituição da tabela inteira e substituição de partição estática. Depois substituiu um dia aprovado completo, aplicou uma substituição válida por conjunto vazio e repetiu o mesmo SQL salvo sem acumular linhas. O histórico bruto independente e as outras datas do arquivo histórico permaneceram intactos.
