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

Microsoft Purview — создание пользовательских данных происхождения с помощью REST API

  • Статья

В этой статье описаны действия по созданию записей происхождения данных с помощью REST API в Каталог данных Microsoft Purview. В случаях, когда автоматически создаваемые данные о происхождении в Microsoft Purview являются неполными или отсутствующими, данные о происхождении могут создаваться вручную на портале Microsoft Purview или с помощью ИНТЕРФЕЙСов REST API. В этой статье основное внимание уделяется использованию REST API, которые могут преодолеть известные ограничения происхождения вручную и предоставить дополнительные возможности.

Общие сведения

Возможность отображения происхождения между наборами данных является одной из важных функций платформы Microsoft Purview. Такие системы, как Фабрика данных, Data Share и Power BI, фиксируют происхождение данных при их перемещении. В некоторых ситуациях автоматически создаваемые происхождение данных Microsoft Purview являются неполными или отсутствуют для практической визуализации и создания отчетов на предприятии. В этих сценариях настраиваемые отчеты о происхождении поддерживаются перехватчиками Apache Atlas и REST API.

Использование ИНТЕРФЕЙСов REST API для создания настраиваемого происхождения данных позволяет преодолеть некоторые ограничения происхождения вручную, как описано в следующих статьях:

В оставшейся части этой статьи объясняется использование ИНТЕРФЕЙСов REST API Microsoft Purview для создания и создания отчетов о пользовательском происхождении в Microsoft Purview.

Предварительные условия

Сценарии

Существует два варианта использования, когда требуется создание пользовательской происхождения:

О. Создание созданных сущностей и связывание их с происхождением

Б. Связывание существующих сущностей или происхождения с другой существующей сущностью или происхождением

Например, необходимо сообщать о происхождении данных между сущностями A & B, но & B в настоящее время не существуют.

Чтобы создать сущности A & B, вызовите REST API Microsoft Purview: сущность — массовое создание или обновление — REST API.

POST https://{accountname}.purview.azure.com/datamap/api/atlas/v2/entity/bulk?api-version=2023-09-01

sample_entity_json = '{"entity": {"status": "ACTIVE","version": 0,"name": ENTITY_A"}.......{"entity": ........}}'
#Send POST JSON containing entities to be created
CreateOrUpdateEntitesUrl = 'https://<purview_account_name>.purview.azure.com/datamap/api/atlas/v2/entity/bulk'
EntitiesResponse = requests.post(CreateOrUpdateEntitesUrl, json = json.loads(sample_entity_json) ,headers=headers)
entitiesRes = json.loads(EntitiesResponse.text)

Ответ API "201 Created" указывает, что сущности успешно созданы, а их идентификаторы GUID содержатся в выходных данных JSON.

Теперь, когда сущности A & B созданы, перейдите к шагу B, чтобы связать сущности в цепочке происхождения с помощью того же REST API.

  • Если количество связанных сущностей не является временным или ресурсоемким (например, менее 20–30 сущностей), вы можете подключить происхождение вручную на портале Microsoft Purview. Выполните инструкции по созданию подключений к происхождению данных вручную.
  • Если у вас есть большое количество подключений к происхождению, процесс необходимо автоматизировать или, если вручную с помощью портала Microsoft Purview нецелесообразно, перейдите к процессу API связывания и создания пользовательских данных.

Полезные данные JSON пользовательского происхождения:

Выполните REST API POST /entity/bulkEntity — Массовое создание или обновление — REST API , используя полезные данные, как показано:

POST https://{accountname}.purview.azure.com/datamap/api/atlas/v2/entity/bulk?api-version=2023-09-01

sample_entity_json = '{
  "entities": [
    {
      "status": "ACTIVE",
      "version": 1,
      "typeName": "Process",
      "attributes": {
        "inputs": [
          {
            "guid": "24558fd8-9cdc-47de-9310-56a58108bab0",
            “guid”: “27163581-9aca-212a-782a-213612639abc”
          }
        ],
        "outputs": [
          {
            "guid": "e33c694a-2c4f-4cae-8c27-06f6f6f60000"
          }
        ],
        "qualifiedName": "cassandra://query",
        "name": "query"
      }
    }
  ]
}'

#In this code snippet, we send the JSON as POST request containing the two GUIDs as input and "output" GUID as output. This creates lineage with 2 directional inputs and 1 directional output.
#Note: using the same API and SDK code you can create lineage with any number of inputs, any number of processes in between, any number of typedefs and any number of outputs.
#The API/SDK method is the most flexible and versatile menthod of creating lineage.
 
CreateLineageEntitesUrl = 'https://<purview_account_name>.purview.azure.com/datamap/api/atlas/v2/entity/bulk'
EntitiesResponse = requests.post(CreateLineageEntitesUrl, json = json.loads(sample_entity_json),headers=headers)
entitiesRes = json.loads(EntitiesResponse.text)

Эта полезная нагрузка JSON создает настраиваемую происхождение данных. Он работает для уже существующих ресурсов, идентификаторы GUID которых предоставляются в json-файле inputs. Например, "guid": "24558fd8-9cdc-47de-9310-56a58108bab0" и "27163581-9aca-212a-782a-213612639abc" ссылается на направленные входные данные происхождения, а "guid": "e33c694a-2c4f-4cae-8c27-06f6f6f60000" относится к направленному выходу происхождения, который был существующим ресурсом, автоматически сканируемым Purview. Мы только что создали происхождение между двумя ресурсами.

Примечание.

Если ресурсы еще не существуют, необходимо запустить API создания массовых сущностей перед этим шагом, чтобы создать эти сущности перед созданием связи происхождения. Процесс массового создания сущности с помощью API POST/entity/bulk и фрагмента кода Python описан на шаге A.

Результаты сценария

Ответ API "201 Created" указывает на успешное создание компоновки графа происхождения, а созданные GUID содержатся в выходных данных JSON. Происхождение данных отображается на портале Microsoft Purview:

  • Сценарий A. Настраиваемая сборка происхождения из ресурсов, созданных с помощью API:

    Снимок экрана: сценарий A. Настраиваемая сборка происхождения из ресурсов, созданных с помощью API.

  • Сценарий Б. Настраиваемая сборка происхождения данных из уже существующих ресурсов, связанных с помощью API.

    Примечание.

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

    Снимок экрана: сценарий Б. Настраиваемая созданная линия происхождения из существующих ресурсов, связанных с помощью API.