Просмотр происхождения данных с помощью каталога Unity

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

Обзор происхождения данных

Каталог Unity фиксирует происхождение данных среды выполнения в запросах, выполняемых в Azure Databricks. Родословная поддерживается для всех языков и фиксируется на уровне столбца. Данные о происхождении включают записные книжки, задания и панели мониторинга, связанные с данным запросом. Родословную можно визуализировать в Catalog Explorer почти в реальном времени и получать программно с использованием системных таблиц родословной и REST API Databricks.

Линейность собирается во всех рабочих областях, подключенных к метахранилищу Unity Catalog. Это означает, что родословная, зафиксированная в одной рабочей области, видна в любой другой рабочей области, которая разделяет это хранилище метаданных. В частности, таблицы и другие объекты данных, зарегистрированные в хранилище метаданных, видны пользователям, имеющим по крайней мере BROWSE разрешения на эти объекты во всех рабочих областях, подключенных к хранилищу метаданных. Однако подробные сведения об объектах на уровне рабочей области, таких как записные книжки и панели мониторинга в других рабочих областях, маскируются (см. ограничения происхождения и разрешения на происхождение).

Данные о происхождении сохраняются в течение одного года.

На следующем рисунке представлен пример графика происхождения.

Сведения об отслеживании происхождения модели машинного обучения см. в статье Отслеживание происхождения данных модели в каталоге Unity.

Требования

Для записи происхождения данных с помощью каталога Unity:

• Таблицы должны быть зарегистрированы в хранилище метаданных каталога Unity.
• Запросы должны выполняться с использованием Spark DataFrame (например, функций Spark SQL, возвращающих DataFrame) или интерфейсов SQL Databricks, таких как записные книжки и редактор запросов SQL.

Чтобы просмотреть происхождение данных, выполните приведенные действия.

• У вас должна быть привилегия BROWSE как минимум в каталоге-родителе таблицы или представления. Родительский каталог также должен быть доступен из рабочей области. См. раздел Ограничение доступа к каталогу для определенных рабочих областей.
• Для записных книжек, заданий или панелей мониторинга необходимо иметь разрешения на эти объекты, как определено параметрами управления доступом в рабочей области. Дополнительные сведения см. в разделе "Разрешения происхождения".
• Для конвейера с поддержкой Unity Catalog необходимо иметь разрешение CAN VIEW на конвейер.

Требования к вычислениям:

• Для отслеживания происхождения потоков данных между таблицами Delta требуется Databricks Runtime 11.3 LTS или новее.
• Для отслеживания связи столбцов для рабочих нагрузок DLT требуется Databricks Runtime 13.3 LTS или выше.

Требования к сети:

• Возможно, потребуется обновить правила исходящего брандмауэра, чтобы разрешить подключение к конечной точке Центров событий в плоскости управления Azure Databricks. Обычно это актуально, если рабочая область Azure Databricks развертывается в собственной виртуальной сети (также известной как инъекция виртуальной сети). Чтобы получить конечную точку Пакетов событий для вашего региона рабочего пространства, см. раздел хранилище метаданных, хранилище артефактов BLOB, хранилище системных таблиц, хранилище журналов BLOB и IP-адреса конечных точек Пакетов событий. Сведения о настройке определяемых пользователем маршрутов (UDR) для Azure Databricks см. в разделе Пользовательские параметры маршрутизации для Azure Databricks.

Просмотр происхождения данных с помощью обозревателя каталогов

Чтобы использовать обозреватель каталогов для просмотра происхождения таблиц:

1. В рабочей области Azure Databricks щелкните значок .

2. Найдите или просмотрите вашу таблицу.

3. Перейдите на вкладку "Происхождение". Откроется панель происхождения и отображает связанные таблицы.

4. Чтобы просмотреть интерактивный граф происхождения данных, нажмите Просмотреть график происхождения данных.

   По умолчанию в графе отображается один уровень. Щелкните значок на узле, чтобы отобразить дополнительные подключения, если они доступны.

5. Щелкните стрелку, соединяющую узлы в графе связей, чтобы открыть панель подключения Lineage.

   Панель подключения родословной отображает детали соединения, включая исходные и целевые таблицы, записные книжки и задания.

   

6. Чтобы отобразить записную книжку, связанную с таблицей, выберите записную книжку на панели Lineage connection или закройте граф происхождения и щелкните "Записные книжки".

   Чтобы открыть записную книжку на новой вкладке, щелкните имя записной книжки.

7. Чтобы просмотреть происхождение на уровне столбцов, щелкните столбец в графе, чтобы отобразить ссылки на связанные столбцы. Например, щелкая по столбцу full_menu в этом примере графика, выводятся исходные столбцы, из которых был получен данный столбец.

   

Просмотр происхождения рабочего процесса (задания)

Чтобы просмотреть линию рабочих процессов, перейдите на вкладку "Линия" таблицы, щелкните "Рабочие процессы" и выберите вкладку "Нисходящий" . Имя задания отображается под "Имя задания" в качестве потребителя таблицы.

Просмотр истории панели мониторинга

Чтобы просмотреть происхождение панели мониторинга, перейдите на вкладку "Происхождение таблицы" и щелкните "Панели мониторинга". Панель мониторинга отображается в разделе "Имя панели мониторинга " в качестве потребителя таблицы.

Узнайте происхождение таблицы с помощью ассистента Databricks

Помощник по Databricks предоставляет подробные сведения о происхождении таблиц и аналитике.

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

1. На боковой панели рабочей области щелкните каталог.
2. Просмотрите или найдите каталог, щелкните имя каталога, а затем щелкните значок помощника по продукту - цвет в правом верхнем углу.
3. В командной строке помощника введите следующее:
   • /getTableLineages для просмотра вышестоящих и подчиненных зависимостей.
   • /getTableInsights для доступа к аналитическим сведениям на основе метаданных, таким как действия пользователей и шаблоны запросов.

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

Данные о происхождении запросов с использованием системных таблиц

Системные таблицы происхождения можно использовать для программного запроса данных происхождения. Подробные инструкции см. в статье Мониторинг действий учетной записи с помощью системных таблиц и Справочник системных таблиц родословной.

Если рабочая область находится в регионе, который не поддерживает системные таблицы происхождения, вместо этого можно использовать REST API data lineage для получения данных происхождения программным способом.

Получение происхождения данных с помощью REST API происхождения данных

API происхождения данных позволяет получить происхождение таблиц и столбцов. Однако если рабочая область находится в регионе, поддерживающем системные таблицы происхождения, следует использовать системные запросы таблиц вместо REST API. Системные таблицы — это лучший вариант для программного извлечения данных происхождения. Большинство регионов поддерживают системные таблицы происхождения.

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

В этом примере извлекаются данные о происхождении для таблицы dinner.

Запрос

curl --netrc -X GET \
-H 'Content-Type: application/json' \
https://<workspace-instance>/api/2.0/lineage-tracking/table-lineage \
-d '{"table_name": "lineage_data.lineagedemo.dinner", "include_entity_lineage": true}'

Замените <workspace-instance>.

В этом примере используется файл .netrc.

Ответ

{
  "upstreams": [
    {
      "tableInfo": {
        "name": "menu",
        "catalog_name": "lineage_data",
        "schema_name": "lineagedemo",
        "table_type": "TABLE"
      },
      "notebookInfos": [
        {
          "workspace_id": 4169371664718798,
          "notebook_id": 1111169262439324
        }
      ]
    }
  ],
  "downstreams": [
    {
      "notebookInfos": [
        {
          "workspace_id": 4169371664718798,
          "notebook_id": 1111169262439324
        }
      ]
    },
    {
      "tableInfo": {
        "name": "dinner_price",
        "catalog_name": "lineage_data",
        "schema_name": "lineagedemo",
        "table_type": "TABLE"
      },
      "notebookInfos": [
        {
          "workspace_id": 4169371664718798,
          "notebook_id": 1111169262439324
        }
      ]
    }
  ]
}

Получение происхождения столбцов

В этом примере извлекаются данные столбцов для таблицы dinner.

Запрос

curl --netrc -X GET \
-H 'Content-Type: application/json' \
https://<workspace-instance>/api/2.0/lineage-tracking/column-lineage \
-d '{"table_name": "lineage_data.lineagedemo.dinner", "column_name": "dessert"}'

Замените <workspace-instance>.

В этом примере используется файл .netrc.

Ответ

{
  "upstream_cols": [
    {
      "name": "dessert",
      "catalog_name": "lineage_data",
      "schema_name": "lineagedemo",
      "table_name": "menu",
      "table_type": "TABLE"
    },
    {
      "name": "main",
      "catalog_name": "lineage_data",
      "schema_name": "lineagedemo",
      "table_name": "menu",
      "table_type": "TABLE"
    },
    {
      "name": "app",
      "catalog_name": "lineage_data",
      "schema_name": "lineagedemo",
      "table_name": "menu",
      "table_type": "TABLE"
    }
  ],
  "downstream_cols": [
    {
      "name": "full_menu",
      "catalog_name": "lineage_data",
      "schema_name": "lineagedemo",
      "table_name": "dinner_price",
      "table_type": "TABLE"
    }
  ]
}

Разрешения на происхождение данных

Графики происхождения используют ту же модель разрешений, что и Unity Catalog. Таблицы и другие объекты данных, зарегистрированные в хранилище метаданных каталога Unity, видны только пользователям, имеющим по крайней мере BROWSE разрешения на эти объекты. Если у пользователя нет прав BROWSE или SELECT в таблице, они не могут изучить его происхождение. Графы происхождения отображают объекты каталога Unity во всех рабочих областях, связанных с метахранилищем, если у пользователя есть соответствующие разрешения на объекты.

Например, выполните следующие команды для userA:

GRANT USE SCHEMA on lineage_data.lineagedemo to `[email protected]`;
GRANT SELECT on lineage_data.lineagedemo.menu to `[email protected]`;

Когда userA просматривает график происхождения для таблицы lineage_data.lineagedemo.menu, они увидят таблицу menu. Они не смогут просматривать сведения о связанных таблицах, например нижестоящей lineage_data.lineagedemo.dinner таблице. Таблица dinner отображается в виде узла masked на экране для userA, и userA не может развернуть граф, чтобы отобразить подчиненные таблицы из тех, к которым они не имеют разрешения на доступ.

При выполнении следующей команды для выдачи BROWSE разрешения userB пользователю, он сможет просматривать граф для любой таблицы в схеме lineage_data.

GRANT BROWSE on lineage_data to `[email protected]`;

Аналогичным образом пользователи родословной данных должны иметь определенные разрешения для просмотра объектов рабочей области, таких как панели мониторинга, задания и блокноты. Кроме того, они могут просматривать только подробные сведения об объектах рабочей области при входе в рабочую область, в которой были созданы эти объекты. Подробная информация об объектах уровня рабочей области в других рабочих областях скрывается в графе родословной.

Дополнительные сведения об управлении доступом к защищаемым объектам в каталоге Unity см. в статье Управление привилегиями в каталоге Unity. Дополнительные сведения об управлении доступом к объектам рабочей области, таким как записные книжки, задания и панели мониторинга, см. списки управления доступом.

Ограничения происхождения

Происхождение данных имеет следующие ограничения:

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

• Поскольку линейность вычисляется в однолетнем скользящем окне, данные, собранные более одного года назад, не показываются. Например, если задание или запрос считывает данные из таблицы А и записывается в таблицу B, связь между таблицей A и таблицей B отображается только в течение одного года. Данные о происхождении можно фильтровать по временным интервалам в течение одного года.

• Задания, запрашиваемые через API заданийruns submit, недоступны в представлениях происхождения. Происхождение на уровне таблицы и столбца по-прежнему фиксируется при использовании runs submit запроса, но ссылка на выполнение не фиксируется.

• Если таблица или представление переименованы, цепочка связи не сохраняется для переименованной таблицы или представления.

• Если схема или каталог переименованы, происхождение данных не фиксируется для таблиц и представлений в переименованном каталоге или схеме.

• Если вы используете контрольные точки набора данных Spark SQL, родословная не записывается.

• Каталог Unity фиксирует происхождение данных из конвейеров DLT чаще всего. Однако в некоторых случаях полное покрытие трассировки невозможно гарантировать, например, когда конвейеры используют API APPLY CHANGES или ЧАСТНЫЕ таблицы.

• Lineage не записывает функции стека.

• Глобальные временные представления не фиксируются в линейности.

• Таблицы в system.information_schema не фиксируются в линейности.

• Каталог Unity фиксирует происхождение данных до уровня столбца настолько, насколько это возможно. Однако в некоторых случаях невозможно записать происхождение на уровне столбцов. К ним относятся:

  • Не удается зафиксировать происхождение столбцов, если источник или целевой объект указан как путь (пример: select * from delta."s3://<bucket>/<path>"). Линейность столбцов поддерживается только в том случае, если и источник, и приемник ссылаются по имени таблицы (пример: select * from <catalog>.<schema>.<table>).

  • Полный линейдж на уровне столбцов по умолчанию не отслеживается для операций MERGE.

    Вы можете включить запись происхождения для MERGE операций, задав для свойства Spark значение spark.databricks.dataLineage.mergeIntoV2Enabledtrue. Включение этого флага может замедлить производительность запросов, особенно в рабочих нагрузках, включающих очень широкие таблицы.