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

Общие сведения о моделях Графа (предварительная версия)

Применимо: ✅Microsoft Fabric✅Azure Data Explorer

Замечание

Эта функция сейчас доступна в общедоступной предварительной версии. Функциональные возможности и синтаксис могут быть изменены до общедоступной доступности.

Модели графов в Azure Data Explorer позволяют определять, управлять и эффективно запрашивать постоянные структуры графов в базе данных. В отличие от временных графов, созданных с помощью оператора make-graph , модели графов хранятся в представлениях, которые можно запрашивать многократно без повторного перестроения графа для каждого запроса, что значительно повышает производительность сложного анализа на основе связей.

Обзор

Модель графа — это объект базы данных, представляющий граф свойств с метками (LPG) в Azure Data Explorer. Он состоит из узлов, также называемых вершинами и ребрами, также называемыми связями. Оба узла и ребра могут иметь свойства, описывающие их. Модель определяет схему графа, включая типы узлов и ребер со своими свойствами. Он также определяет процесс создания графа из табличных данных, хранящихся в таблицах базы данных KQL и из табличных выражений.

Основные характеристики

Предложение моделей Графа:

  • Сохраняемость метаданных. Сохранение спецификаций графа в метаданных базы данных для обеспечения устойчивости и повторного использования
  • Материализованные моментальные снимки: устранение необходимости перестроить графы для каждого запроса, значительно повышая производительность запросов.
  • Определение схемы: поддержка необязательных, но рекомендуемых схем для узлов и ребер, обеспечение согласованности данных
  • Глубокая интеграция KQL: простая интеграция с семантикой графа
  • Оптимизированные обходы: включение специализированного индексирования для эффективных операций обхода графа, что значительно ускоряет сопоставление сложных шаблонов и поиск путей.

Использование моделей графов

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

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

Для более простого однократного анализа графов на небольших наборах данных оператор make-graph может быть более подходящим.

Компоненты модели Graph

Модель графа состоит из двух основных компонентов:

Схема (необязательно)

Схема определяет структуру и свойства узлов и ребер в модели графа. В то время как необязательно, схема служит для нескольких важных целей:

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

Структура схемы

  • Узлы: определяет типы меток узла и их типизированные свойства (например, "Person": {"Name": "string", "Age": "long"})
  • Края: определяет типы меток edge и их типизированные свойства (например, "WORKS_AT": {"StartDate": "datetime", "Position": "string"})

Определение

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

Ключевые характеристики определения:

  • Последовательное выполнение: шаги выполняются в точном порядке, который они отображаются в массиве определений. Этот порядок имеет решающее значение, так как:

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

  • Добавочное построение: каждый шаг добавляется к построению графа, что позволяет:

    • Объединение данных из нескольких таблиц или источников
    • Применение разной логики для разных типов узлов или ребер
    • Постепенное создание сложных структур графов

Типы шагов:

  • AddNodes: шаги, определяющие, как создавать узлы из табличных данных

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

  • AddEdges: шаги, определяющие, как создавать края из табличных данных

    • Может ссылаться на узлы, которые еще не существуют (система создаст узлы-заполнители и обновит их при обработке шагов AddNodes позже)
    • Может создавать связи между узлами из одного или разных шагов AddNodes
    • Свойства edge являются производными от столбцов в результатах запроса
    • Хотя можно добавить ребра перед узлами, рекомендуется сначала добавить узлы для улучшения удобочитаемости и понимания.

Пример потока выполнения:

Step 1 (AddNodes): Create Person nodes from Employees table
Step 2 (AddNodes): Create Company nodes from Organizations table  
Step 3 (AddEdges): Create WORKS_AT edges between Person and Company nodes
Step 4 (AddEdges): Create KNOWS edges between Person nodes

Этот последовательный подход гарантирует, что если шаг 3 создает WORKS_AT края, узлы person (из шага 1) и корпоративные узлы (из шага 2) уже существуют в графе.

Метки в моделях Graph

Метки — это критически важные идентификаторы, которые классифицируют узлы и края в графе, что позволяет эффективно фильтровать и сопоставлять шаблоны. Модели графов Azure Data Explorer поддерживают два дополнительных типа меток:

Статические метки

  • Определяется явным образом в разделе схемы модели графа
  • Представление типов узлов или ребер с предопределенными свойствами
  • Предоставление согласованной схемы для элементов графа
  • Ссылка на массив "Метки" в шагах AddNodes и AddEdges
  • Идеально подходит для известных, стабильных типов сущностей и связей

Динамические метки

  • Не определено в разделе "Схема"
  • Создан во время выполнения из данных в базовых таблицах
  • Указан с помощью LabelsColumn в шагах AddNodes или AddEdges
  • Может быть одна метка (строковый столбец) или несколько меток (столбец динамического массива)
  • Предоставление более гибких структур графа, адаптируемых к данным
  • Полезно для систем, где с течением времени типы узлов и ребер развиваются

Подсказка

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

Подробные инструкции по определению

Раздел "Определение" модели графа содержит шаги, определяющие способ создания графа из табличных данных. Каждый шаг имеет определенные параметры в зависимости от типа.

Шаги AddNodes

Шаги AddNodes определяют, как создавать узлы в графе из табличных данных:

Параметр Обязательно Описание
Добрый Да Должно быть задано значение AddNodes
Запрос Да Запрос KQL, который извлекает данные для узлов. Результат запроса должен содержать все столбцы, необходимые для свойств узла и идентификаторов.
NodeIdColumn Да Столбец из результата запроса, используемый в качестве уникального идентификатора для каждого узла.
Наклейки нет Массив имен статических меток, определенных в разделе схемы для применения к этим узлам
LabelsColumn нет Столбец из результата запроса, предоставляющий динамические метки для каждого узла. Может быть строковым столбцом (одной меткой) или столбцом динамического массива (несколько меток)

Действия addEdges

Инструкции AddEdges определяют, как создавать связи между узлами в графе:

Параметр Обязательно Описание
Добрый Да Необходимо задать значение AddEdges
Запрос Да Запрос KQL, который извлекает данные для ребер. Результат запроса должен содержать идентификаторы исходного и целевого узла и любые свойства ребра.
Исходный столбец Да Столбец из результата запроса, содержащий идентификаторы исходного узла
TargetColumn Да Столбец из результата запроса, содержащий идентификаторы целевого узла
Наклейки нет Массив имен статических меток, определенных в разделе схемы для применения к этим краям.
LabelsColumn нет Столбец из результата запроса, предоставляющий динамические метки для каждого края. Может быть строковым столбцом (одной меткой) или столбцом динамического массива (несколько меток)

Примеры модели Графа

Базовый пример со статическими и динамическими метками

В следующем примере создается профессиональная модель сетевого графа, которая объединяет статические определения схем с динамической меткой:

.create-or-alter graph_model ProfessionalNetwork ```
{
  "Schema": {
    "Nodes": {
      "Person": {"Name": "string", "Age": "long", "Title": "string"},
      "Company": {"Name": "string", "Industry": "string", "FoundedYear": "int"}
    },
    "Edges": {
      "WORKS_AT": {"StartDate": "datetime", "Position": "string", "Department": "string"},
      "KNOWS": {"ConnectionDate": "datetime", "ConnectionStrength": "int"}
    }
  },
  "Definition": {
    "Steps": [
      {
        "Kind": "AddNodes",
        "Query": "Employees | project Id, Name, Age, Title, NodeType",
        "NodeIdColumn": "Id",
        "Labels": ["Person"],
        "LabelsColumn": "NodeType"
      },
      {
        "Kind": "AddNodes",
        "Query": "Organizations | project Id, Name, Industry, FoundedYear",
        "NodeIdColumn": "Id",
        "Labels": ["Company"]
      },
      {
        "Kind": "AddEdges",
        "Query": "EmploymentRecords | project EmployeeId, CompanyId, StartDate, Position, Department",
        "SourceColumn": "EmployeeId",
        "TargetColumn": "CompanyId",
        "Labels": ["WORKS_AT"]
      },
      {
        "Kind": "AddEdges",
        "Query": "Connections | project PersonA, PersonB, ConnectionDate, ConnectionType, ConnectionStrength",
        "SourceColumn": "PersonA",
        "TargetColumn": "PersonB",
        "Labels": ["KNOWS"],
        "LabelsColumn": "ConnectionType"
      }
    ]
  }
}
```

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

Создание моделей Graph и управление ими

Azure Data Explorer предоставляет полный набор команд управления для работы с моделями графов на протяжении всего жизненного цикла.

Сводка по командам

командование Цель Ключевые параметры
.create-or-alter graph_model Создание новой модели графа или изменение существующей База данных, имя, схема, определение
.drop graph_model Удаление модели графа База данных, имя
.show graph_models Вывод списка доступных моделей графа База данных [необязательно]

Жизненный цикл модели Графа

Типичный рабочий процесс для управления моделями графов включает в себя:

  1. Разработка . Создание начальной модели графа с схемой и определением, которое сопоставляется с данными
  2. Проверка — запрос модели для проверки правильной структуры и ожидаемых результатов
  3. Обслуживание — периодическое обновление модели по мере развития структуры данных
  4. Управление моментальными снимками . Создание и прекращение моментальных снимков для балансировки производительности и свежести

Подсказка

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

Моментальные снимки графа

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

Ключевые аспекты моментальных снимков графа:

  • Каждый моментальный снимок связан с определенной моделью графа
  • С одной моделью графа может быть связано несколько моментальных снимков.
  • Моментальные снимки создаются с помощью .make graph_snapshot команды
  • Моментальные снимки включают метаданные, такие как время создания и исходная модель графа
  • Моментальные снимки позволяют запрашивать граф по мере его существования в определенный момент времени

Дополнительные сведения о работе с моментальными снимками графа см. в обзоре моментальных снимков Graph.

Запрос моделей Graph

Модели графов запрашиваются с помощью graph() функции, которая предоставляет доступ к сущности графа. Эта функция поддерживает получение последнего моментального снимка графа или создания графа во время запроса, если моментальные снимки недоступны.

Базовая структура запросов

graph("GraphModelName")
| graph-match <pattern>
    where <filters>
    project <output fields>

Примеры запросов

1. Базовый шаблон node-edge-node

// Find people who commented on posts by employees in the last week
graph("SocialNetwork") 
| graph-match (person)-[comments]->(post)<-[authored]-(employee)
    where person.age > 30 
      and comments.createTime > ago(7d)
    project person.name, post.title, employee.userName

2. Несколько шаблонов связей

// Find people who both work with and are friends with each other
graph("ProfessionalNetwork") 
| graph-match (p1)-[worksWith]->(p2)-[friendsWith]->(p1)
    where labels(worksWith) has "WORKS_WITH" and labels(friendsWith) has "FRIENDS_WITH" and
      labels(p1) has "Person" and labels(p2) has "Person"
    project p1.name, p2.name, p1.department

3. Пути переменной длины

// Find potential influence paths up to 3 hops away
graph("InfluenceNetwork") 
| graph-match (influencer)-[influences*1..3]->(target)
    where influencer.id == "user123" and all(influences, labels() has "INFLUENCES")
    project influencePath = influences, 
         pathLength = array_length(influences), 
         target.name

Функция graph() предоставляет согласованный способ доступа к данным графа, не требуя явного создания графа для каждого запроса.

Замечание

Ознакомьтесь с операторами Graph для полной ссылки на синтаксис и возможности запросов графа.

Часто задаваемые вопросы

Кто отвечает за обновление графа?

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

Как можно обновить граф?

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

  1. Создание нового моментального снимка с помощью асинхронной операции (.make graph_snapshot)
  2. После создания входящие запросы графа автоматически используют новый моментальный снимок
  3. Необязательно. Удаление старого моментального снимка для освобождения ресурсов (.drop graph_snapshot)

Что делать, если различные шаги создают повторяющиеся края или узлы?

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

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

  • Узлы: "Дубликаты" автоматически объединяются на основе значения NodeIdColumn. Система предполагает, что они представляют одну и ту же сущность. Если несколько шагов создают узлы с одинаковым идентификатором:

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

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

Как модели графов обрабатывают изменения схемы?

При изменении схемы базовых данных:

  1. Изменение модели графа .create-or-alter graph_model с помощью команды для обновления схемы или определения
  2. Чтобы материализовать эти изменения, создайте новый моментальный снимок
  3. Старые моментальные снимки остаются доступными до явного удаления

Можно ли запрашивать несколько моделей графов?

Да, можно запросить несколько моделей графов в одном запросе с помощью композиции:

  • Использование выходных данных одного graph() оператора в качестве входных данных другому оператору graph()
  • Обработка и преобразование результатов из одного графа перед добавлением в другой запрос графа
  • Цепочка нескольких операций графа для междоменного анализа без создания единой модели

Пример:

// Query the first graph model
graph("EmployeeNetwork") 
| graph-match (person)-[manages]->(team)
    where labels(manages) has "MANAGES" and labels(person) has "Employee"
    project manager=person.name, teamId=team.id
// Use these results to query another graph model
| join (
	graph("ProjectNetwork")
	| graph-match (project)-[assignedTo]->(team)
        where labels(assignedTo) has "ASSIGNED_TO"
	    project projectName=project.name, teamId=team.id
) on teamId

Какова разница между метками и свойствами?

  • Метки: классификация узлов и ребер для сопоставления структурных шаблонов
  • Свойства: хранение значений данных, связанных с узлами и краями (используется в фильтрации и выходных данных)

Связанный контент