Поделиться через

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

  • Статья

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

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

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

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

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

Обзор Родословной.

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

Требования

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

  • Рабочая область должна иметь включенный каталог Unity.
  • Таблицы должны быть зарегистрированы в хранилище метаданных каталога Unity.
  • В запросах должны использоваться Spark DataFrame (например, функции Spark SQL, возвращающие DataFrame) или интерфейсы Databricks SQL. Примеры запросов Databricks SQL и PySpark см. здесь.
  • Чтобы просмотреть происхождение таблицы или представления, пользователи должны иметь по крайней мере привилегию BROWSE на родительский каталог таблицы или представления. Родительский каталог также должен быть доступен из рабочей области. См. раздел Ограничение доступа к каталогу для определенных рабочих областей.
  • Чтобы просмотреть информацию о родословной записных книжек, заданий или панелей мониторинга, пользователи должны иметь разрешения на эти объекты, как определено настройками управления доступом в рабочей области. См. разрешения на трассировку данных.
  • Чтобы просмотреть родословную для конвейера с поддержкой каталога Unity , необходимо иметь CAN_VIEW разрешения на конвейер.
  • Для отслеживания происхождения потоков данных между таблицами Delta требуется Databricks Runtime 11.3 LTS или новее.
  • Для отслеживания происхождения столбцов для рабочих нагрузок DLT требуется Databricks Runtime 13.3 LTS или более поздней версии.

Примеры

Примечание.

  • В следующих примерах используется имя каталога lineage_data и имя схемы lineagedemo. Чтобы использовать другой каталог и схему, измените имена, используемые в примерах.

  • Чтобы завершить этот пример, необходимо иметь CREATE и USE SCHEMA привилегии в схеме. Администратор хранилища метаданных, владелец каталога, владелец схемы или пользователь с правами MANAGE на схеме может предоставить эти привилегии. Например, чтобы предоставить всем пользователям в группе разрешение "data_engineers" на создание таблиц в схеме lineagedemo в каталоге lineage_data, пользователь с одним из указанных выше привилегий или ролей может выполнять следующие запросы:

    CREATE SCHEMA lineage_data.lineagedemo;
GRANT USE SCHEMA, CREATE on SCHEMA lineage_data.lineagedemo to `data_engineers`;

Фиксирование и изучение линейности данных

Для записи данных происхождения:

  1. Перейдите на главную страницу Azure Databricks, щелкните New IconNew на боковой панели и выберите Notebook в меню.

  2. Введите имя записной книжки и выберите SQL в язык по умолчанию.

  3. В кластеревыберите кластер с доступом к каталогу Unity.

  4. Нажмите кнопку Создать.

  5. В первой ячейке записной книжки введите следующие запросы:

    CREATE TABLE IF NOT EXISTS
  lineage_data.lineagedemo.menu (
    recipe_id INT,
    app string,
    main string,
    dessert string
  );

INSERT INTO lineage_data.lineagedemo.menu
    (recipe_id, app, main, dessert)
VALUES
    (1,"Ceviche", "Tacos", "Flan"),
    (2,"Tomato Soup", "Souffle", "Creme Brulee"),
    (3,"Chips","Grilled Cheese","Cheesecake");

CREATE TABLE
  lineage_data.lineagedemo.dinner
AS SELECT
  recipe_id, concat(app," + ", main," + ",dessert)
AS
  full_menu
FROM
  lineage_data.lineagedemo.menu

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

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

  1. В поле поиска в верхней строке рабочей области Azure Databricks найдите таблицу и выберите ее.

  2. Перейдите на вкладку «Lineage». Откроется панель родословной, отображающая связанные таблицы (в данном примере это таблица menu).

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

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

    граф происхождения .

  5. Чтобы отобразить записную книжку, связанную с таблицей dinner, выберите записную книжку на панели подключения графа зависимости или закройте граф зависимости и щелкните Записные книжки. Чтобы открыть записную книжку на новой вкладке, щелкните имя записной книжки.

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

    строке столбца полного меню.

Чтобы просмотреть происхождение с помощью другого языка, например Python:

  1. Откройте созданную ранее записную книжку, создайте новую ячейку и введите следующий код Python:

    %python
from pyspark.sql.functions import rand, round
df = spark.range(3).withColumn("price", round(10*rand(seed=42),2)).withColumnRenamed("id","recipe_id")

df.write.mode("overwrite").saveAsTable("lineage_data.lineagedemo.price")

dinner = spark.read.table("lineage_data.lineagedemo.dinner")
price = spark.read.table("lineage_data.lineagedemo.price")

dinner_price = dinner.join(price, on="recipe_id")
dinner_price.write.mode("overwrite").saveAsTable("lineage_data.lineagedemo.dinner_price")

  2. Запустите ячейку, щелкнув ячейку и нажав клавиши SHIFT+ВВОД или щелкнув Меню запуска и выбрав "Выполнить ячейку".

  3. В поле поиска в верхней строке рабочей области Azure Databricks найдите таблицу и выберите ее.

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

    развернутый график происхождения.

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

Сбор и просмотр сведений о происхождении рабочих процессов

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

  1. Щелкните Новый значокНовый на боковой панели и выберите Записная книжка в меню.

  2. Введите имя записной книжки и выберите SQL в язык по умолчанию.

  3. Нажмите кнопку Создать.

  4. В первой ячейке записной книжки введите следующий запрос:

    SELECT * FROM lineage_data.lineagedemo.menu

  5. На верхней панели щелкните Расписание. В диалоговом окне расписания выберите Manual, выберите кластер с доступом к каталогу Unity Catalog, и нажмите Создать.

  6. Щелкните Запустить сейчас.

  7. В поле поиска в верхней строке рабочей области Azure Databricks найдите таблицу и выберите ее.

  8. На вкладке нажмите Рабочие процессыи выберите вкладку Downstream. Имя задания появляется под Job Name как потребитель таблицы menu.

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

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

  1. Перейдите на целевую страницу Azure Databricks и откройте обозреватель каталогов, щелкнув каталог на боковой панели.

  2. Щелкните имя каталога, щелкните lineagedemoи выберите таблицу menu. Вы также можете использовать поле поиска в верхней строке для поиска таблицы menu.

  3. Нажмите кнопку "Открыть" на панели мониторинга.

  4. Выберите столбцы, которые нужно добавить на панель мониторинга, и щелкните Создать.

  5. Опубликуйте панель мониторинга.

    Только опубликованные панели мониторинга учитываются в родословной данных.

  6. В поле Поиск в верхней панели найдите таблицу lineage_data.lineagedemo.menu и выберите её.

  7. На вкладке Lineage щелкните Панели. Панель мониторинга отображается в разделе Имя панели мониторинга в качестве потребителя таблицы меню.

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

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

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

GRANT USE SCHEMA on lineage_data.lineagedemo to `userA@company.com`;
GRANT SELECT on lineage_data.lineagedemo.menu to `userA@company.com`;

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

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

GRANT BROWSE on lineage_data to `userB@company.com`;

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

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

Удаление данных о происхождении

Предупреждение

Следующие инструкции удаляют все объекты, хранящиеся в каталоге Unity. Используйте их только при необходимости. Например, для соответствия требованиям.

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

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

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

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

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

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

Помощник Databricks предоставляет информацию о родословной таблиц и аналитическую информацию.

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

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

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

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

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

Внимание

Чтобы получить доступ к REST API Databricks, необходимо пройти проверку подлинности.

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

В этом примере извлекаются данные о происхождении для таблицы 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, сведения об объектах рабочего пространства, таких как ноутбуки и панели мониторинга, отображаются только в том рабочем пространстве, в котором они были созданы.

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

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

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

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

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

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

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

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

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

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

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

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

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