Справочник по системным таблицам потомственности

Эта страница содержит ссылку на две системные таблицы происхождения. Эти системные таблицы создаются на основе функции происхождения данных каталога Unity, что позволяет программным способом запрашивать данные о происхождении данных, чтобы подпитывать принятие решений и отчеты. Чтобы получить доступ к таблицам, схемы должны быть включены в каталоге system . Дополнительные сведения см. в разделе "Включение системных таблиц".

Хранение данных

Системные таблицы происхождения сохраняют последовательное 1-летнее окно данных. События старше одного года удаляются на прокатной основе. Для истории происхождения, превышающей один год, используйте обозреватель каталогов или API происхождения, которые бесконечно сохраняют данные о происхождении, захваченные после 1 сентября 2024 года.

Таблица происхождения таблиц

В системе таблиц lineage содержится запись для каждого события чтения или записи в таблице каталога Unity или пути. Это включает, помимо прочего, выполнение заданий, запуски записных книжек и интерактивные панели, обновленные с помощью события чтения или записи.

Путь к таблице: эта системная таблица расположена по адресу system.access.table_lineage.

Схема линейности таблицы

В таблице системы родословной таблицы используется следующая схема.

Таблица происхождения столбцов

Таблица происхождения столбцов не включает события, у которых нет источника. Например, при вставке в столбец с использованием явных значений он не фиксируется. Если вы считываете столбец, он записывается независимо от того, записываете ли вы выходные данные.

Путь к таблице: эта системная таблица расположена по адресу system.access.column_lineage.

схема происхождения столбцов

В системной таблице родословной столбцов используется следующая схема:

Чтение системных таблиц родословной

• Чтобы определить, было ли событие чтением или записью, можно просмотреть исходный тип и целевой тип.
  • Только для чтения: исходный тип не имеет значения NULL, но целевой тип имеет значение NULL.
  • Только запись: целевой тип не является NULL, но исходный тип является NULL.
  • Чтение и запись: исходный тип и целевой тип не равны NULL.

Ссылка на метаданные сущности

У entity_metadata структуры есть следующая схема:

job_info:
  job_id: "string"
  job_run_id: "string"
dashboard_id: "string"
legacy_dashboard_id: "string"
notebook_id: "string"
sql_query_id: "string"
dlt_pipeline_info:
  dlt_pipeline_id: "string"
  dlt_update_id: "string"
genie_space_id: "string"
alert_id: "string"

Azure Databricks записывает события происхождения из Декларативных конвейеров Lakeflow Spark, записных книжек, заданий, запросов Databricks SQL, панелей мониторинга, Genie Spaces и оповещений. События из других сущностей не поддерживаются.

В зависимости от типа события можно заполнить несколько значений. Например, задание, выполняющее задачу в записной книжке, обеспечивает заполнение обоих job_info и notebook_id.

Если все значения в entity_metadata и null равны, это означает, что в событии не участвуют сущности Azure Databricks. Например, это может быть результатом запроса JDBC или действия пользователя, щелкающего на вкладке Sample Data в интерфейсе Azure Databricks.

Пример таблицы системы родословной

В качестве примера того, как записывается происхождение в системных таблицах, представлен пример запроса вместе с записями происхождения, которые создает запрос.

CREATE OR REPLACE TABLE car_features
AS SELECT *,  in1+in2 as premium_feature_set
FROM car_features_exterior
JOIN car_features_interior
USING(id, model);

Запись в system.access.table_lineage будет выглядеть следующим образом:

Запись в system.access.column_lineage будет выглядеть следующим образом:

Устранение неполадок с запросами внешней таблицы

При ссылке на внешнюю таблицу с помощью пути к облачному хранилищу связанная запись происхождения содержит только имя пути, а не имя таблицы. Например, запись происхождения для этого запроса будет содержать имя пути, а не имя таблицы:

SELECT * FROM delta.`abfss://my-container-name@storage-account-name.dfs.core.windows.net/table1`;

Если вы пытаетесь запросить записи происхождения для внешней таблицы, на которую ссылается путь, необходимо отфильтровать запрос с помощью source_path или target_path вместо source_table_full_name или target_table_full_name. Например, следующий запрос извлекает все записи происхождения для внешней таблицы:

SELECT *
FROM system.access.table_lineage
WHERE
  source_path = "abfss://my-container-name@storage-account-name.dfs.core.windows.net/table1" OR
  target_path = "abfss://my-container-name@storage-account-name.dfs.core.windows.net/table1";

Получите записи линейных данных на основе имени внешней таблицы

Если вы не хотите вручную получить путь к облачному хранилищу для поиска происхождения, можно использовать следующую функцию, чтобы получить данные о происхождении с помощью имени таблицы. Вы также можете заменить system.access.table_lineage на system.access.column_lineage в функции, если хотите запросить происхождение столбцов.

def getLineageForTable(table_name):
  table_path = spark.sql(f"describe detail {table_name}").select("location").head()[0]

  df = spark.read.table("system.access.table_lineage")
  return df.where(
    (df.source_table_full_name == table_name)
    | (df.target_table_full_name == table_name)
    | (df.source_path == table_path)
    | (df.target_path == table_path)
  )

Затем выполните следующую команду, чтобы вызвать функцию и отобразить записи происхождения для внешней таблицы:

display(getLineageForTable("table_name"))