Práce s historií tabulek

U tabulek Apache Iceberg a Delta Lake každá operace, která upravuje tabulku, vytvoří novou verzi tabulky. Pomocí informací historie můžete auditovat operace, vrátit tabulku zpět nebo dotazovat tabulku v určitém časovém okamžiku pomocí časového cestování.

Note

Databricks nedoporučuje používat historii tabulek jako dlouhodobé řešení zálohování pro archivaci dat. Pokud jste nenastavili konfiguraci uchovávání dat i protokolů na větší hodnotu, použijte pouze posledních 7 dnů pro operace časového cestování.

Získat historii tabulky

Spuštěním DESCRIBE HISTORY příkazu načtěte informace, včetně operací, uživatele a časového razítka pro každý zápis do tabulky. Operace jsou řazeny v obráceném chronologickém pořadí.

Uchovávání historie tabulek je určeno nastavením logRetentionDurationtabulky, což je ve výchozím nastavení 30 dnů.

Note

Pohyb v čase a historie tabulky jsou řízeny různými prahovými hodnotami uchovávání dat. Viz Časová cesta.

DESCRIBE HISTORY table_name       -- get the full history of the table

DESCRIBE HISTORY table_name LIMIT 1  -- get the last operation only

Podrobnosti o syntaxi Spark SQL najdete v tématu DESCRIBE HISTORY.

Podrobnosti o syntaxi Scala, Java a Python najdete v dokumentaci k rozhraní Delta Lake API.

Průzkumník katalogu zobrazuje historii tabulek vizuálně na kartě Historie .

Schéma historie

Výstup operace history má následující sloupce.

Column	Typ	Description
verze	`long`	Verze tabulky vygenerovaná operací.
časové razítko	`timestamp`	Když byla tato verze potvrzena.
userId	`string`	ID uživatele, který operaci spustil.
uživatelské_jméno	`string`	Jméno uživatele, který operaci spustil.
operace	`string`	Název operace.
operační parametry	`map`	Parametry operace (například predikáty).)
úloha	`struct`	Podrobnosti úlohy Lakeflow, která operaci spustila. Vyplní se pouze u commitů zapsaných úlohou Lakeflow. V opačném případě `null`.
poznámkový blok	`struct`	Podrobnosti o poznámkovém bloku Databricks, ze kterého byla operace spuštěna. Vyplní se pouze pro commity vytvořené v poznámkovém bloku Databricks. V opačném případě `null`.
clusterId	`string`	ID clusteru, na kterém byla operace spuštěna.
readVersion	`long`	Verze tabulky, která byla přečtená k provedení operace zápisu.
isolationLevel	`string`	Úroveň izolace použitá pro tuto operaci.
isBlindAppend	`boolean`	Určuje, jestli tato operace připojila data.
operationMetrics	`map`	Metriky operace (například počet řádků a souborů upravených))
userMetadata	`string`	Metadata potvrzení definovaná uživatelem, pokud byla zadána.

+-------+-------------------+------+--------+---------+--------------------+----+--------+---------+-----------+-----------------+-------------+--------------------+
|version|          timestamp|userId|userName|operation| operationParameters| job|notebook|clusterId|readVersion|   isolationLevel|isBlindAppend|    operationMetrics|
+-------+-------------------+------+--------+---------+--------------------+----+--------+---------+-----------+-----------------+-------------+--------------------+
|      5|2019-07-29 14:07:47|   ###|     ###|   DELETE|[predicate -> ["(...|null|     ###|      ###|          4|WriteSerializable|        false|[numTotalRows -> ...|
|      4|2019-07-29 14:07:41|   ###|     ###|   UPDATE|[predicate -> (id...|null|     ###|      ###|          3|WriteSerializable|        false|[numTotalRows -> ...|
|      3|2019-07-29 14:07:29|   ###|     ###|   DELETE|[predicate -> ["(...|null|     ###|      ###|          2|WriteSerializable|        false|[numTotalRows -> ...|
|      2|2019-07-29 14:06:56|   ###|     ###|   UPDATE|[predicate -> (id...|null|     ###|      ###|          1|WriteSerializable|        false|[numTotalRows -> ...|
|      1|2019-07-29 14:04:31|   ###|     ###|   DELETE|[predicate -> ["(...|null|     ###|      ###|          0|WriteSerializable|        false|[numTotalRows -> ...|
|      0|2019-07-29 14:01:40|   ###|     ###|    WRITE|[mode -> ErrorIfE...|null|     ###|      ###|       null|WriteSerializable|         true|[numFiles -> 2, n...|
+-------+-------------------+------+--------+---------+--------------------+----+--------+---------+-----------+-----------------+-------------+--------------------+

Note

Pokud do tabulky zapíšete následující metody, některé sloupce nejsou k dispozici:
Sloupce přidané v budoucnu se vždy přidají za poslední sloupec.

Porozumění `partitionBy` provozním parametrům

Pole partitionBy v historii tabulek je smysluplné pouze pro operace CREATE a OVERWRITE, které definují nebo mění schéma oddílů tabulky.

Pro operace připojení k existujícím tabulkám (APPEND, INSERT, , UPDATEDELETE, MERGE) může toto pole zobrazovat prázdné pole [] nebo sloupce oddílů v závislosti na použité metodě zápisu (.save() vs .saveAsTable(). ).

Tato nekonzistence je očekávané chování a nemá vliv na způsob zápisu dat do oddílů. Neměli byste ho používat k ověření operací připojení.

Example

Zvažte tabulku dělenou podle date sloupce. Když vytvoříte tabulku, partitionBy se vyplní:

df.write.format("delta") \
  .partitionBy("date") \
  .saveAsTable("sales_data")

Operace CREATE v historii ukazuje:

operationParameters: {
  "mode": "ErrorIfExists",
  "partitionBy": "[\"date\"]"
}

Když k této tabulce připojíte data, partitionBy zobrazí se prázdné pole:

new_df.write.format("delta") \
  .mode("append") \
  .saveAsTable("sales_data")

Operace APPEND ukazuje:

operationParameters: {
  "mode": "Append",
  "partitionBy": "[]"
}

Očekává se prázdná partitionBy hodnota. Data jsou stále zapisována do správných oddílů na základě existujícího schématu oddílů tabulky. Všimněte si, že u .save() cesty se v tomto poli mohou zobrazovat sloupce oddílů, ale tento rozdíl je pouze detailem implementace a nemá vliv na chování při zápisu.

Metriky operací

Operace history vrátí kolekci metrik operací v mapě operationMetrics sloupců.

Následující tabulky uvádějí definice klíčů mapování podle operace.