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

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

  • Статья

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

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

Происхождение агрегируется во всех рабочих областях, подключенных к хранилищу метаданных каталога Unity. Это означает, что происхождение данных, собранное в одной рабочей области, отображается в любой другой рабочей области из этого хранилища метаданных. У пользователей должны быть правильные разрешения на просмотр данных происхождения. Данные о происхождении хранятся в течение 1 года.

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

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

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

Требования

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

  • Рабочая область должна включать каталог Unity.

  • Таблицы должны быть зарегистрированы в хранилище метаданных каталога Unity.

  • В запросах должны использоваться кадры данных Spark (например, функции Spark SQL, возвращающие кадры данных) или интерфейсы Databricks SQL. Примеры запросов Databricks SQL и PySpark см. здесь.

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

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

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

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

  • Для отслеживания происхождения столбцов для рабочих нагрузок Delta Live Tables требуется Databricks Runtime 13.3 LTS или более поздней версии.

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

Примеры

Примечание.

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

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

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

Сбор и изучение происхождения данных

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

  1. Перейдите на целевую страницу Azure Databricks, щелкните Значок "Создать " на боковой панели и выберите "Записная книжка " в меню.

  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 найдите lineage_data.lineagedemo.dinner таблицу и выберите ее.

  2. Перейдите на вкладку "Происхождение". Откроется панель происхождения и отображает связанные таблицы (например, это 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 найдите lineage_data.lineagedemo.price таблицу и выберите ее.

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

    Расширенный граф происхождения

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

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

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

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

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

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

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

    SELECT * FROM lineage_data.lineagedemo.menu

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

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

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

  8. На вкладке "Линия происхождения" щелкните "Рабочие процессы" и выберите вкладку "Внизу". Имя задания отображается в разделе "Имя задания" в качестве потребителя menu таблицы.

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

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

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

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

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

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

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

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

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

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

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

Для графов происхождения используется та же модель разрешений, что и для каталога Unity. Если у пользователя нет BROWSE прав или SELECT привилегий в таблице, они не могут изучить происхождение. Кроме того, пользователи могут просматривать только записные книжки, задания и панели мониторинга, которые у них есть разрешение на просмотр. Например, если для пользователя 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, отличному от администратора:

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

userB теперь можно просмотреть график происхождения для любой таблицы в схеме lineage_data .

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

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

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

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

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

Запрос данных происхождения с помощью системных таблиц

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

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

Response

{
  "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.

Response

{
  "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"
    }
  ]
}

Ограничения

  • Так как происхождение вычисляется в однолетнем скользящей окне, происхождение, собранное более одного года назад, не отображается. Например, если задание или запрос считывает данные из таблицы А и записывается в таблицу B, связь между таблицей A и таблицей B отображается только в течение одного года. Данные о происхождении можно фильтровать по временным интервалам в течение одного года.
  • Задания, использующие запрос API runs submit заданий, недоступны при просмотре происхождения. Происхождение на уровне таблицы и столбца по-прежнему собирается при использовании запроса runs submit, но ссылка на выполнение не входит в сбор.
  • Unity Catalog регистрирует происхождение на уровне столбца, когда это возможно. Однако в некоторых случаях не удается зарегистрировать происхождение данных на уровне столбца.
  • Происхождение столбцов поддерживается только в том случае, если источник и целевой объект ссылаются по имени таблицы (пример: select * from <catalog>.<schema>.<table>). Происхождение столбцов невозможно записать, если источник или целевой объект устранен путем (пример: select * from delta."s3://<bucket>/<path>").
  • Если таблица или представление переименованы, строка происхождения не фиксируется для переименованной таблицы или представления.
  • Если схема или каталог переименованы, строка происхождения не фиксируется для таблиц и представлений в переименованном каталоге или схеме.
  • Если вы используете контрольные точки для набора данных Spark SQL, данные о происхождении не записываются.
  • Каталог Unity записывает происхождение из конвейеров разностных динамических таблиц в большинстве случаев. Однако в некоторых случаях полное покрытие происхождения невозможно гарантировать, например, когда конвейеры используют API APPLY CHANGES или ВРЕМЕННЫЕ таблицы.
  • Lineage не записывает функции стека.
  • Глобальные временные представления не фиксируются в происхождении.
  • Таблицы под system.information_schema не фиксируются в происхождении.