Schemat historii tabeli i metryki operacji

Dowództwo DESCRIBE HISTORY zwraca 14 kolumn dla tabel Apache Iceberg i Delta Lake, które opisują historię operacji tabelowych. Użyj tego odniesienia, aby zinterpretować każdą kolumnę.

Aby uzyskać wskazówki dotyczące odzyskiwania historii tabeli, zapytań do wcześniejszych wersji tabeli oraz przywracania tabeli, zobacz Praca z historią tabeli.

Schemat historii

Dane wyjściowe history operacji zawierają następujące kolumny.

Column	Typ	Description
wersja	`long`	Wersja tabeli wygenerowana przez operację.
sygnatura czasowa	`timestamp`	Kiedy ta wersja została zatwierdzona.
userId	`string`	Identyfikator użytkownika, który uruchomił operację.
userName	`string`	Nazwa użytkownika, który uruchomił operację.
operacja	`string`	Nazwa operacji.
parametry operacji	`map`	Parametry operacji (na przykład predykaty). W przypadku `OPTIMIZE` operacji te parametry identyfikują typ operacji. Zobacz Identyfikowanie typu `OPTIMIZE` operacji.
zadanie	`struct`	Szczegóły zadania Lakeflow, w ramach którego uruchomiono operację. Jest wypełniane tylko dla commitów utworzonych przez zadanie Lakeflow. W przeciwnym razie `null`.
notes	`struct`	Szczegóły notesu Databricks, z którego uruchomiono operację. Jest wypełniane tylko dla commitów utworzonych w notesniku Databricks. W przeciwnym razie `null`.
clusterId	`string`	Identyfikator klastra, na którym uruchomiono operację.
odczytajWersję	`long`	Wersja tabeli odczytanej w celu wykonania operacji zapisu.
isolationLevel	`string`	Poziom izolacji używany dla tej operacji.
isBlindAppend	`boolean`	Czy ta operacja dołączała dane.
operationMetrics	`map`	Metryki operacji (na przykład liczba wierszy i plików zmodyfikowanych).
userMetadata	`string`	Metadane zatwierdzenia zdefiniowane przez użytkownika, jeśli zostały określone.

+-------+-------------------+------+--------+---------+--------------------+----+--------+---------+-----------+-----------------+-------------+--------------------+
|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...|
+-------+-------------------+------+--------+---------+--------------------+----+--------+---------+-----------+-----------------+-------------+--------------------+

Uwaga / Notatka

Jeśli zapisujesz w tabeli przy użyciu następujących metod, niektóre kolumny nie są dostępne:
Kolumny dodane w przyszłości będą zawsze dodawane po ostatniej kolumnie.

Opis `partitionBy` parametrów operacji

Pole partitionBy w historii tabeli ma znaczenie tylko w przypadku operacji CREATE i OVERWRITE, które definiują lub zmieniają schemat partycji tabeli.

W przypadku operacji dołączania do istniejących tabel (APPEND, INSERT, , UPDATEDELETE, MERGE) to pole może wyświetlać pustą tablicę [] lub kolumny partycji w zależności od używanej metody zapisu (.save() vs .saveAsTable()).

Ta niespójność jest oczekiwanym zachowaniem i nie wpływa na sposób zapisywania danych w partycjach. Nie należy jej używać do weryfikowania operacji dołączania.

Przykład

Rozważ podzielenie tabeli na partycje według kolumny date . Po utworzeniu tabeli partitionBy zostanie wypełniona:

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

Operacja CREATE w historii pokazuje:

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

Po dołączeniu danych do tej tabeli partitionBy zostanie wyświetlona pusta tablica:

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

Operacja APPEND pokazuje:

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

Oczekuje się, że wartość partitionBy będzie pusta. Dane są nadal zapisywane we poprawnych partycjach na podstawie istniejącego schematu partycji tabeli. Pamiętaj, że w przypadku ścieżki .save() w tym polu mogą być wyświetlane kolumny partycjonowania, ale ta różnica jest szczegółem implementacyjnym i nie wpływa na działanie zapisu.

Metryki operacji

Operacja history zwraca zbiór metryk operacji w mapie kolumnowej operationMetrics .

W poniższych tabelach wymieniono definicje kluczy mapy według operacji.