Leituras e escritas em lote de tabelas

Delta Lake suporta a maioria das opções fornecidas por Apache Spark DataFrame ler e escrever APIs para executar leituras e escritas em lotes em tabelas.

Para obter informações sobre os comandos Delta Lake SQL, consulte

Criar uma mesa

Delta Lake suporta a criação de tabelas diretamente com base no caminho que utiliza DataFrameWriter (Scala ou Java e Python). O Delta Lake também suporta a criação de tabelas na meta-loja utilizando o DDL CREATE TABLE padrão. Quando cria uma tabela na meta-loja usando o Delta Lake, armazena a localização dos dados da tabela na metastore. Este ponteiro facilita a descoberta e a referência aos dados por parte de outros utilizadores sem ter de se preocupar exatamente com o local onde está armazenado. No entanto, a metásta não é a fonte da verdade sobre o que é válido na tabela. Essa responsabilidade fica com a Delta Lake.

SQL

-- Create table in the metastore
CREATE TABLE events (
  date DATE,
  eventId STRING,
  eventType STRING,
  data STRING)
USING DELTA

Python

df.write.format("delta").saveAsTable("events")      # create table in the metastore

df.write.format("delta").save("/mnt/delta/events")  # create table by path

Scala

df.write.format("delta").saveAsTable("events")      // create table in the metastore

df.write.format("delta").save("/mnt/delta/events")  // create table by path

No Databricks Runtime 7.0 e acima pode criar tabelas Delta utilizando a DataFrameWriterV2 interface. O SQL também suporta uma mesa de criação num caminho, sem criar uma entrada na metásta de Colmeia.

SQL

-- Create a table by path
CREATE OR REPLACE TABLE delta.`/mnt/delta/events` (
  date DATE,
  eventId STRING,
  eventType STRING,
  data STRING)
USING DELTA
PARTITIONED BY (date);

-- Create a table in the metastore
CREATE OR REPLACE TABLE events (
  date DATE,
  eventId STRING,
  eventType STRING,
  data STRING)
USING DELTA
PARTITIONED BY (date);

Scala

df.writeTo("delta.`/mnt/delta/events`").using("delta").partitionedBy("date").createOrReplace() // create table by path

df.writeTo("events").using("delta").partitionedBy("date").createOrReplace()                   // create table in the metastore

Dados de partição

Pode dividir dados para acelerar consultas ou DML que têm predicados envolvendo as colunas de partição. Para os dados de partição quando criar uma tabela Delta, especifique a partição por colunas. Um padrão comum é a divisão por data, por exemplo:

SQL

-- Create table in the metastore
CREATE TABLE events (
 date DATE,
 eventId STRING,
 eventType STRING,
 data STRING)
USING DELTA
PARTITIONED BY (date)
LOCATION '/mnt/delta/events'

Python

df.write.format("delta").partitionBy("date").saveAsTable("events")      # create table in the metastore

df.write.format("delta").partitionBy("date").save("/mnt/delta/events")  # create table by path

Scala

df.write.format("delta").partitionBy("date").saveAsTable("events")      // create table in the metastore

df.write.format("delta").partitionBy("date").save("/mnt/delta/events")  // create table by path

Localização de dados de controlo

Para controlar a localização dos ficheiros da tabela Delta, pode especificar opcionalmente o LOCATION caminho em DBFS.

As tabelas criadas com um especificado LOCATION são consideradas não geridos pela metastore. Ao contrário de uma tabela gerida, onde não é especificado nenhum caminho, os ficheiros de uma mesa não gerida não são apagados quando você DROP a tabela.

Quando você corre CREATE TABLE com um que LOCATION contém dados armazenados usando Delta Lake, Delta Lake faz o seguinte:

  • Se especificar apenas o nome da tabela e a localização, por exemplo:

    CREATE TABLE events
    USING DELTA
    LOCATION '/mnt/delta/events'
    

    a tabela na metástore da Colmeia herda automaticamente as propriedades do esquema, partição e tabela dos dados existentes. Esta funcionalidade pode ser usada para "importar" dados para a metastore.

  • Se especificar qualquer configuração (propriedades de esquema, divisórias ou tabela), o Delta Lake verifica que a especificação corresponde exatamente à configuração dos dados existentes.

    Importante

    Se a configuração especificada não corresponder exatamente à configuração dos dados, o Delta Lake lança uma exceção que descreve a discrepância.

Leia uma mesa

Pode carregar uma tabela Delta como dataframe especificando um nome de mesa ou um caminho:

SQL

SELECT * FROM events   -- query table in the metastore

SELECT * FROM delta.`/mnt/delta/events`  -- query table by path

Python

spark.table("events")    # query table in the metastore

spark.read.format("delta").load("/mnt/delta/events")  # query table by path

Scala

spark.table("events")      // query table in the metastore

spark.read.format("delta").load("/mnt/delta/events")  // create table by path

O DataFrame devolvido lê automaticamente a imagem mais recente da tabela para qualquer consulta; nunca precisa REFRESH TABLE correr. A Delta Lake utiliza automaticamente a partição e as estatísticas para ler a quantidade mínima de dados quando existem predicados aplicáveis na consulta.

Consultar um instantâneo mais antigo de uma mesa (viagem no tempo)

Nesta secção:

A viagem no tempo do Lago Delta permite-lhe consultar uma imagem mais antiga de uma tabela Delta. A viagem no tempo tem muitos casos de uso, incluindo:

  • Recriando análises, relatórios ou saídas (por exemplo, a saída de um modelo de aprendizagem automática). Isto poderia ser útil para a depuragem ou auditoria, especialmente nas indústrias regulamentadas.
  • Escrever consultas temporais complexas.
  • Corrigir erros nos seus dados.
  • Proporcionando isolamento instantâneo para um conjunto de consultas para mudanças rápidas de mesas.

Esta secção descreve os métodos suportados para consulta de versões mais antigas de tabelas, preocupações de retenção de dados e fornece exemplos.

Syntax

Esta secção mostra como consultar uma versão mais antiga de uma tabela Delta.

Nesta secção:
Sintaxe AS OF SQL
SELECT * FROM table_identifier TIMESTAMP AS OF timestamp_expression
SELECT * FROM table_identifier VERSION AS OF version

em que

  • table_identifier
    • [database_name.] table_name: Nome de mesa, opcionalmente qualificado com nome de base de dados.
    • delta.<>de caminho a mesa: A localização de uma tabela Delta existente.
  • timestamp_expression pode ser qualquer um dos:
    • '2018-10-18T22:15:12.013Z', isto é, uma corda que pode ser lançada a uma hora de tempo
    • cast('2018-10-18 13:36:32 CEST' as timestamp)
    • '2018-10-18', isto é, uma cadeia de encontros
    • Em Databricks Runtime 6.6 e superior:
      • current_timestamp() - interval 12 hours
      • date_sub(current_date(), 1)
      • Qualquer outra expressão que seja ou possa ser lançada a uma hora de tempo
  • version é um valor longo que pode ser obtido a partir da produção de DESCRIBE HISTORY table_spec .

Nem timestamp_expression version nem podem ser subqueries.

SELECT * FROM events TIMESTAMP AS OF '2018-10-18T22:15:12.013Z'
SELECT * FROM delta.`/mnt/delta/events` VERSION AS OF 123
Opções dataFrameReader

As opções DataFrameReader permitem criar um DataFrame a partir de uma tabela Delta que é fixada a uma versão específica da tabela.

df1 = spark.read.format("delta").option("timestampAsOf", timestamp_string).load("/mnt/delta/events")
df2 = spark.read.format("delta").option("versionAsOf", version).load("/mnt/delta/events")

Para timestamp_string , apenas as cordas data ou timetamp são aceites. Por exemplo, "2019-01-01" e "2019-01-01T00:00:00.000Z".

Um padrão comum é usar o estado mais recente da tabela Delta durante a execução de um trabalho de Azure Databricks para atualizar aplicações a jusante.

Uma vez que a atualização automática das tabelas Delta, um DataFrame carregado a partir de uma tabela Delta pode devolver resultados diferentes através de invocações se os dados subjacentes forem atualizados. Ao utilizar a viagem no tempo, pode corrigir os dados devolvidos pelo DataFrame através de invocações:

latest_version = spark.sql("SELECT max(version) FROM (DESCRIBE HISTORY delta.`/mnt/delta/events`)").collect()
df = spark.read.format("delta").option("versionAsOf", latest_version[0][0]).load("/mnt/delta/events")
@ sintaxe

Pode ter um oleoduto parametrizado, onde o caminho de entrada do seu oleoduto é um parâmetro do seu trabalho. Após a execução do seu trabalho, talvez queira reproduzir a produção em algum momento no futuro. Neste caso, pode utilizar a @ sintaxe para especificar a etiqueta ou a versão. A estada de tempo deve estar em yyyyMMddHHmmssSSS formato. Pode especificar uma versão depois @ de pré-premissar uma v para a versão. Por exemplo, para consultar a versão 123 para a tabela , events especifique events@v123 .

SQL
SELECT * FROM events@20190101000000000
SELECT * FROM events@v123
Python
spark.read.format("delta").load("/mnt/delta/events@20190101000000000") # table on 2019-01-01 00:00:00.000
spark.read.format("delta").load("/mnt/delta/events@v123")              # table on version 123

Retenção de dados

Por defeito, as tabelas Delta mantêm a história do compromisso por 30 dias. Isto significa que pode especificar uma versão de 30 dias atrás. No entanto, existem algumas ressalvas:

  • Não correu o VACUUM na sua mesa Delta. Se VACUUM correr, perde a capacidade de voltar a uma versão mais antiga do que o período de retenção de dados de 7 dias.

Pode configurar períodos de retenção utilizando as seguintes propriedades de tabela:

  • delta.logRetentionDuration = "interval <interval>": controla quanto tempo a história de uma mesa é mantida. Cada vez que um ponto de verificação é escrito, a Azure Databricks limpa automaticamente as entradas de registo mais antigas do que o intervalo de retenção. Se definir este config para um valor suficientemente grande, muitas entradas de registo são mantidas. Isto não deve ter impacto no desempenho, uma vez que as operações contra o registo são tempo constante. As operações na história são paralelas (mas tornar-se-ão mais caras à medida que o tamanho do tronco aumenta). A predefinição é interval 30 days.

  • delta.deletedFileRetentionDuration = "interval <interval>": controla há quanto tempo um ficheiro deve ter sido apagado antes de ser candidato VACUUM a . A predefinição é interval 7 days. Para acesso a 30 dias de dados históricos, definido delta.deletedFileRetentionDuration = "interval 30 days" . Esta definição pode fazer com que os custos de armazenamento suba.

    Nota

    VACUUM não limpa ficheiros de registo; os ficheiros de registo são automaticamente limpos após a escrita dos postos de controlo.

Para viajar no tempo para uma versão anterior, deve reter tanto o registo como os ficheiros de dados para essa versão.

Exemplos

  • Fixar eliminações acidentais a uma tabela para o 111 utilizador:

    INSERT INTO my_table
      SELECT * FROM my_table TIMESTAMP AS OF date_sub(current_date(), 1)
      WHERE userId = 111
    
  • Corrigir atualizações incorretas acidentais numa tabela:

    MERGE INTO my_table target
      USING my_table TIMESTAMP AS OF date_sub(current_date(), 1) source
      ON source.userId = target.userId
      WHEN MATCHED THEN UPDATE SET *
    
  • Consulta o número de novos clientes adicionados na última semana.

    SELECT count(distinct userId) - (
      SELECT count(distinct userId)
      FROM my_table TIMESTAMP AS OF date_sub(current_date(), 7))
    

Escreva para uma mesa

Apêndice

Utilizando append o modo de utilização pode adicionar atomicamente novos dados a uma tabela Delta existente:

SQL

INSERT INTO events SELECT * FROM newEvents

Python

df.write.format("delta").mode("append").save("/mnt/delta/events")
df.write.format("delta").mode("append").saveAsTable("events")

Scala

df.write.format("delta").mode("append").save("/mnt/delta/events")
df.write.format("delta").mode("append").saveAsTable("events")

Overwrite

Para substituir atomicamente todos os dados numa tabela, pode utilizar overwrite o modo:

SQL

INSERT OVERWRITE TABLE events SELECT * FROM newEvents

Python

df.write.format("delta").mode("overwrite").save("/mnt/delta/events")
df.write.format("delta").mode("overwrite").saveAsTable("events")

Scala

df.write.format("delta").mode("overwrite").save("/mnt/delta/events")
df.write.format("delta").mode("overwrite").saveAsTable("events")

Utilizando dataFrames, também pode substituir seletivamente apenas os dados que correspondem a predicados sobre colunas de partição. O seguinte comando substitui atomicamente o mês de janeiro pelos dados df em:

Python

df.write \
  .format("delta") \
  .mode("overwrite") \
  .option("replaceWhere", "date >= '2017-01-01' AND date <= '2017-01-31'") \
  .save("/mnt/delta/events")

Scala

df.write
  .format("delta")
  .mode("overwrite")
  .option("replaceWhere", "date >= '2017-01-01' AND date <= '2017-01-31'")
  .save("/mnt/delta/events")

Este código de amostra escreve os dados em df , valida que tudo se enquadra nas divisórias especificadas, e executa uma substituição atómica.

Nota

Ao contrário do ficheiro APIs em Apache Spark, Delta Lake lembra-se e impõe o esquema de uma mesa. Isto significa que, por predefinição, os substitutos não substituem o esquema de uma tabela existente.

Para o suporte da Delta Lake para atualizar tabelas, consulte a tabela para eliminar, atualizar e fundir.

Definir metadados de compromisso definidos pelo utilizador

Pode especificar as cordas definidas pelo utilizador como metadados em compromissos escamados por estas operações, utilizando a opção DataFrameWriter userMetadata ou a configuração SparkSession spark.databricks.delta.commitInfo.userMetadata . Se ambos tiverem sido especificados, então a opção toma preferência. Estes metadados definidos pelo utilizador são legíveis na operação de histórico.

SQL


SET spark.databricks.delta.commitInfo.userMetadata=overwritten-for-fixing-incorrect-data
INSERT OVERWRITE events SELECT * FROM newEvents

Python

df.write.format("delta") \
  .mode("overwrite") \
  .option("userMetadata", "overwritten-for-fixing-incorrect-data") \
  .save("/mnt/delta/events")

Scala

df.write.format("delta")
  .mode("overwrite")
  .option("userMetadata", "overwritten-for-fixing-incorrect-data")
  .save("/mnt/delta/events")

Validação do esquema

O Delta Lake valida automaticamente que o esquema do DataFrame que está a ser escrito é compatível com o esquema da tabela. Delta Lake usa as seguintes regras para determinar se uma escrita de um DataFrame para uma tabela é compatível:

  • Todas as colunas DataFrame devem existir na tabela-alvo. Se houver colunas no DataFrame não presentes na tabela, é levantada uma exceção. As colunas presentes na tabela, mas não no DataFrame, são definidas como nulas.
  • Os tipos de dados da coluna DataFrame devem coincidir com os tipos de dados de coluna na tabela-alvo. Se não corresponderem, uma exceção é levantada.
  • Os nomes das colunas DataFrame não podem diferir apenas por caso. Isto significa que não pode ter colunas como "Foo" e "foo" definidas na mesma tabela. Embora possa utilizar o modo Spark no caso de ser sensível ou insensível (predefinido), o Parquet é sensível ao armazenar e devolver informações sobre colunas. Delta Lake é preservando casos, mas insensível ao armazenar o esquema e tem esta restrição para evitar potenciais erros, corrupção de dados ou problemas de perda.

Delta Lake suporta DDL para adicionar novas colunas explicitamente e a capacidade de atualizar o esquema automaticamente.

Se especificar outras opções, partitionBy como, em combinação com o modo apêndice, a Delta Lake valida que correspondem e lança um erro para qualquer incompatibilidade. Quando partitionBy não estiver presente, os apêndices seguem automaticamente a divisão dos dados existentes.

Nota

Em Databricks Runtime 7.0 ou superior, INSERT a sintaxe fornece a aplicação do esquema e suporta a evolução do esquema. Se o tipo de dados de uma coluna não puder ser lançado com segurança para o tipo de dados da sua tabela Delta Lake, então é lançada uma exceção de tempo de execução. Se a evolução do esquema estiver ativada, novas colunas podem existir como as últimas colunas do seu esquema (ou colunas aninhadas) para que o esquema evolua.

Atualizar esquema de tabela

Delta Lake permite-lhe atualizar o esquema de uma mesa. São suportados os seguintes tipos de alterações:

  • Adicionar novas colunas (em posições arbitrárias)
  • Reordenar as colunas existentes

Pode escriminar estas alterações explicitamente utilizando o DDL ou utilizando implicitamente o DML.

Importante

Quando atualizas um esquema de tabela Delta, os fluxos que lêem dessa tabela terminam. Se quiser que o fluxo continue, tem de reiniciá-lo.

Para obter métodos recomendados, consulte o Streaming Estruturado em produção.

Atualizar explicitamente o esquema

Pode utilizar o DDL seguinte para alterar explicitamente o esquema de uma tabela.

Adicionar colunas

ALTER TABLE table_name ADD COLUMNS (col_name data_type [COMMENT col_comment] [FIRST|AFTER colA_name], ...)

Por defeito, a nulidade é true .

Para adicionar uma coluna a um campo aninhado, utilize:

ALTER TABLE table_name ADD COLUMNS (col_name.nested_col_name data_type [COMMENT col_comment] [FIRST|AFTER colA_name], ...)
Exemplo

Se o esquema antes de correr ALTER TABLE boxes ADD COLUMNS (colB.nested STRING AFTER field1) for:

- root
| - colA
| - colB
| +-field1
| +-field2

o esquema depois é:

- root
| - colA
| - colB
| +-field1
| +-nested
| +-field2

Nota

A adição de colunas aninhadas é suportada apenas para structs. Matrizes e mapas não são suportados.

Alterar comentário ou pedido de coluna

ALTER TABLE table_name CHANGE [COLUMN] col_name col_name data_type [COMMENT col_comment] [FIRST|AFTER colA_name]

Para alterar uma coluna num campo aninhado, utilize:

ALTER TABLE table_name CHANGE [COLUMN] col_name.nested_col_name nested_col_name data_type [COMMENT col_comment] [FIRST|AFTER colA_name]
Exemplo

Se o esquema antes de correr ALTER TABLE boxes CHANGE COLUMN colB.field2 field2 STRING FIRST for:

- root
| - colA
| - colB
| +-field1
| +-field2

o esquema depois é:

- root
| - colA
| - colB
| +-field2
| +-field1

Substituir colunas

ALTER TABLE table_name REPLACE COLUMNS (col_name1 col_type1 [COMMENT col_comment1], ...)
Exemplo

Ao executar o seguinte DSL:

ALTER TABLE boxes REPLACE COLUMNS (colC STRING, colB STRUCT<field2:STRING, nested:STRING, field1:STRING>, colA STRING)

se o esquema anterior for:

- root
| - colA
| - colB
| +-field1
| +-field2

o esquema depois é:

- root
| - colC
| - colB
| +-field2
| +-nested
| +-field1
| - colA

Alterar tipo ou nome de coluna

Alterar o tipo ou nome de uma coluna ou deixar cair uma coluna requer reescrever a tabela. Para isso, utilize a overwriteSchema opção:

Alterar um tipo de coluna
spark.read.table(...)
  .withColumn("date", col("date").cast("date"))
  .write
  .format("delta")
  .mode("overwrite")
  .option("overwriteSchema", "true")
  .saveAsTable(...)
Alterar um nome de coluna
spark.read.table(...)
  .withColumnRenamed("date", "date_created")
  .write
  .format("delta")
  .mode("overwrite")
  .option("overwriteSchema", "true")
  .saveAsTable(...)

Atualização automática de esquemas

O Delta Lake pode atualizar automaticamente o esquema de uma tabela como parte de uma transação DML (anexação ou sobreescrita), e tornar o esquema compatível com os dados que estão a ser escritos.

Adicionar colunas

As colunas que estão presentes no DataFrame mas em falta da tabela são automaticamente adicionadas como parte de uma transação de escrita quando:

  • write ou writeStream ter .option("mergeSchema", "true")
  • spark.databricks.delta.schema.autoMerge.enabled é true

Quando ambas as opções são especificadas, a opção a partir da DataFrameWriter precedência. As colunas adicionadas são anexadas ao fim da estrutura em que estão presentes. O caso é preservado quando se anexa uma nova coluna.

Nota

  • mergeSchema não é suportado quando o controlo de acesso à mesa está ativado (uma vez que eleva um pedido que requer a um que requer MODIFY ALL PRIVILEGES ).
  • mergeSchema não pode ser utilizado com INSERT INTO ou .write.insertInto() . .

NullType colunas

Como o Parquet não NullType suporta, NullType as colunas são largadas do DataFrame ao escrever em tabelas Delta, mas ainda são armazenadas no esquema. Quando um tipo de dados diferente é recebido para esta coluna, o Delta Lake funde o esquema com o novo tipo de dados. Se o Lago Delta receber uma NullType coluna existente, o esquema antigo é mantido e a nova coluna é largada durante a escrita.

NullType no streaming não é suportado. Uma vez que deve definir esquemas ao utilizar o streaming, este deve ser muito raro. NullType também não é aceite para tipos complexos como ArrayType e MapType .

Substituir esquemas de tabelas

Por predefinição, a sobreescrita dos dados numa tabela não substitui o esquema. Ao sobrepor uma tabela mode("overwrite") replaceWhere sem, poderá ainda querer substituir o esquema dos dados que estão a ser escritos. Substitui o esquema e a divisão da tabela, definindo a overwriteSchema opção true para:

df.write.option("overwriteSchema", "true")

Vistas em tabelas

A Delta Lake apoia a criação de vistas em cima das tabelas Delta, tal como você pode ter com uma tabela de fontes de dados.

Estas vistas integram-se com o controlo de acesso à mesa para permitir a segurança do nível das colunas e das linhas.

O principal desafio quando se opera com vistas é resolver os esquemas. Se alterar um esquema de tabela Delta, deve recriar vistas derivadas para explicar quaisquer adições ao esquema. Por exemplo, se adicionar uma nova coluna a uma tabela Delta, deve certificar-se de que esta coluna está disponível nas vistas apropriadas construídas em cima da tabela base.

Propriedades de tabelas

Pode armazenar os seus próprios metadados como uma propriedade de mesa usando TBLPROPERTIES CREATE dentro e ALTER .

TBLPROPERTIES são armazenados como parte dos metadados da tabela Delta. Não é possível definir novo TBLPROPERTIES em comunicado se uma tabela Delta já existe num dado CREATE local. Consulte a criação de mesas para mais detalhes.

Além disso, para personalizar o comportamento e o desempenho, a Delta Lake suporta certas propriedades da tabela Delta:

  • Bloquear elimina e atualizações numa tabela Delta: delta.appendOnly=true .

  • Configure as propriedades de retenção de viagens no tempo: delta.logRetentionDuration=<interval-string> e delta.deletedFileRetentionDuration=<interval-string> . Para mais informações, consulte a retenção de dados.

  • Configure o número de colunas para as quais são recolhidas estatísticas: delta.dataSkippingNumIndexedCols=<number-of-columns> . Esta propriedade tem impacto apenas para novos dados que estão escritos.

Nota

  • Estas são as únicas delta. propriedades de mesa pré-fixas suportadas.
  • Modificar uma propriedade de mesa Delta é uma operação de escrita que entrará em conflito com outras operações de escrita simultâneas,fazendo com que falhem. Recomendamos que modifique uma propriedade de mesa apenas quando não houver operações de escrita simultâneas na mesa.

Também pode definir delta. propriedades pré-fixas durante o primeiro compromisso com uma tabela Delta usando configurações Spark. Por exemplo, para inicializar uma tabela Delta com a delta.appendOnly=true propriedade, desaperte a configuração Spark spark.databricks.delta.properties.defaults.appendOnly para true . Por exemplo:

SQL

spark.sql("SET spark.databricks.delta.properties.defaults.appendOnly = true")

Scala

spark.conf.set("spark.databricks.delta.properties.defaults.appendOnly", "true")

Python

spark.conf.set("spark.databricks.delta.properties.defaults.appendOnly", "true")

Metadados de tabelas

Delta Lake tem características ricas para explorar metadados de mesa.

Apoia SHOW [PARTITIONS | COLUMNS] DESCRIBE TABLE e. Consulte

Também fornece os seguintes comandos únicos:

DESCRIBE DETAIL

Fornece informações sobre esquema, divisórias, tamanho da mesa, e assim por diante. Para mais detalhes, consulte os detalhes da tabela 'Recuperar Delta'.

DESCRIBE HISTORY

Fornece informações de proveniência, incluindo a operação, o utilizador, e assim por diante, e métricas de operação para cada um escrever para uma mesa. A história da mesa é mantida por 30 dias. Para mais detalhes, consulte a história da tabela 'Recuperar Delta'.

A barra lateral de dados fornece uma visão visual desta informação detalhada da tabela e histórico para as tabelas Delta. Além do esquema de tabela e dos dados da amostra, pode clicar no separador Histórico para ver o histórico da tabela que exibe DESCRIBE HISTORY .

Bloco de Notas

Para um exemplo dos vários comandos de metadados da tabela Delta, consulte o final do seguinte caderno:

Delta Lake lote comanda caderno

Obter o bloco de notas