Лабораторная работа 3: Раскрытие информации о потерянном грузе с помощью анализа графов BigQuery и разговорной аналитики.

1. Введение

Добро пожаловать на заключительный этап расследования «Потерянного груза»! После отслеживания украденного контейнера с фигурками андроидов от Лондона до Сиднея, след затерялся. Отключив транспондер, интеллектуальная система безопасности контейнера активировала автоматическую аварийную блокировку .

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

Чтобы найти пропавший контейнер и обеспечить сохранность груза, вам потребуется построить граф свойств BigQuery для отслеживания пути отправления. Затем вы выполните запросы к этой сети на естественном языке с помощью Conversational Analytics и завершите процесс, выполнив семантический поиск по метаданным ваших данных с помощью Knowledge Catalog , чтобы найти коды переопределения.

💡 Пропустили лабораторную работу 1 или 2 ? Не волнуйтесь! Эта лабораторная работа полностью автономна. Шаги по настройке среды обеспечат все необходимое, чтобы вы могли сразу же приступить к ее самостоятельному выполнению.

Что вы будете делать

• Клонируйте репозиторий и запустите скрипт настройки в Google Cloud Shell.
• Создайте в BigQuery граф свойств , связывающий данные о компании, судне и грузовом манифесте.
• Используйте разговорную аналитику для запроса к графу на естественном языке, отслеживая путь груза, чтобы определить ответственного оператора.
• Найдите таблицу с окончательными кодами переопределения, используя Каталог знаний .
• Используйте управление доступом на уровне столбцов BigQuery , чтобы раскрыть и показать окончательный код.

Что вам понадобится

• Веб-браузер, например Chrome.
• Проект Google Cloud с включенной функцией выставления счетов.
• Доступ к Google Cloud Shell

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

Стоимость ресурсов, созданных в рамках этого практического занятия, должна составлять менее 5 долларов.

Ориентировочная продолжительность: выполнение этого практического задания займет приблизительно 45 минут.

2. Прежде чем начать

Создайте проект в Google Cloud.

1. В консоли Google Cloud на странице выбора проекта выберите или создайте проект Google Cloud .
2. Убедитесь, что для вашего облачного проекта включена функция выставления счетов.

Запустить Cloud Shell

Для загрузки кода, запуска скриптов настройки и развертывания приложения вы будете использовать Google Cloud Shell .

1. Откройте Cloud Shell в новой вкладке браузера :

2. После подключения укажите идентификатор проекта и подтвердите свою среду:

gcloud config set project <<YOUR_PROJECT_ID>>
export PROJECT_ID=$(gcloud config get-value project)
export REGION=us-central1

Вы должны увидеть сообщение, похожее на следующее:

Your active configuration is: [cloudshell-####]
Updated property [core/project]

Включить необходимые API

Для включения необходимых API выполните следующую команду в Cloud Shell:

gcloud services enable \
 bigquery.googleapis.com \
 aiplatform.googleapis.com \
 datacatalog.googleapis.com  \
 geminidataanalytics.googleapis.com \
 cloudaicompanion.googleapis.com 

После успешного выполнения вы должны увидеть сообщение, похожее на следующее:

Operation "operations/..." finished successfully.

3. Настройте свою среду.

В предыдущих лабораторных работах этой серии мы заложили основу для нашего исследования.

1. Клонируйте репозиторий.

Клонируйте репозиторий codelab в свою среду Cloud Shell:

cd ~/
git clone --filter=blob:none --no-checkout https://github.com/GoogleCloudPlatform/devrel-demos.git
cd ~/devrel-demos
git sparse-checkout init --cone
git sparse-checkout set codelabs/bigquery-graph-analytics
git checkout main
cd codelabs/bigquery-graph-analytics/

2. Настройте базовые таблицы и теги политик.

Запустите скрипт настройки, чтобы заполнить ваш набор данных BigQuery и применить метки безопасности на уровне столбцов для ограничения доступа к конфиденциальным данным:

bash setup_lab.sh

Убедитесь, что в терминале отображается сообщение об успешной инициализации:

🚀 Provisioning foundational tables and deploying Policy Tag security bindings...
🎯 Active Project: your-project-id
...
🎉 Success! Foundational tables initialized and Column-Level Policy Tags fully mapped out of the box!

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

4. Объедините ваши данные с помощью BigQuery Graph.

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

1. Как графы свойств моделируют взаимосвязи

В BigQuery для моделирования сетей используется граф свойств, основанный на следующих принципах:

• Узлы : Сущности в сети. В этой лабораторной работе узлы представляют компании (которые хранят контактные данные напрямую), манифесты и суда .
• Ребра : Связи, соединяющие узлы между собой. Например:
  • Ребро соединяет объект Manifest с объектом Vessel (посредством связей в таблице manifests ).
  • Ребро соединяет Судно с Компанией (посредством связей в таблице vessels ).
• Свойства : Метаданные, хранящиеся в узлах или ребрах. Например, узел «Компания» имеет столбцы типа company_name и phone_number , а узел «Манифест» — seal_integrity_status и координаты ( last_ping_lat , last_ping_long ).
• Метки : Имена тегов, присваиваемые узлам (например, Company , Vessel , Manifest ) и ребрам (например, CARRIED_BY , OPERATED_BY ), чтобы инструменты запросов могли распознавать типы узлов и отношений.

2. Разверните граф свойств в BigQuery.

Файл setup_graph.sql содержит SQL-скрипт для определения и создания графа свойств, но в настоящее время он неполный. Перед компиляцией и развертыванием необходимо определить метки ребер (связи) в этом файле схемы:

1. Откройте редактор Cloud Shell.

2. Откройте файл setup_graph.sql в редакторе Cloud Shell.

3. Найдите заполнители для меток границ:
   • Строка 22 : Замените `EDGE_TABLE_PLACEHOLDER` на содержательный тег, указывающий, как манифесты соотносятся с судами (например, CARRIED_BY ).
   • Строка 27 : Замените `EDGE_TABLE_PLACEHOLDER` тегом, указывающим, как суда соотносятся с компаниями (например, OPERATED_BY ).
4. Сохраните файл.

Теперь вернитесь в терминал Cloud Shell и разверните обновленный граф свойств, используя готовый скрипт:

bq query --use_legacy_sql=false < setup_graph.sql

Вы должны увидеть сообщение о завершении задания:

Waiting on bqjob_r... ... (0s) Current status: DONE

Подробную информацию о графе свойств можно просмотреть в консоли BigQuery :

Найдите набор данных lost_cargo_dataset и выберите «Графики»:

После успешного составления графа свойств, давайте перейдем к BigQuery Studio, чтобы выполнить запросы и визуализировать связи!

5. Выполните запрос к вашему графу.

Вы можете запрашивать данные из графа и визуально исследовать его, используя встроенный язык запросов к графам (GQL) непосредственно в BigQuery Studio.

1. Выполните поиск по цепочке контейнер -> судно -> компания.

Давайте рассмотрим GQL-запросы, чтобы определить, кто управляет судами, перевозящими грузы. Для поиска оператора необходимо пройти по трем отдельным узлам сущностей в нашей логистической сети:

1. Начните с узла Manifest контейнера.
2. Следуйте по реберу связи CARRIED_BY , чтобы найти транспортное Vessel .
3. Проследите по реберной связи OPERATED_BY от этого судна к ответственной Company и получите ее идентификатор.

Для начала выполним запрос для визуализации всей сети (без каких-либо фильтров), чтобы увидеть полный граф.

1. Откройте новую вкладку в редакторе SQL BigQuery Studio, вставьте следующий GQL-запрос и нажмите « Выполнить» :

   SELECT * FROM GRAPH_TABLE(
     `lost_cargo_dataset.logistics_network`
     MATCH p = (m:Manifest)-[:CARRIED_BY]->(v:Vessel)-[:OPERATED_BY]->(comp:Company)
     RETURN TO_JSON(p) AS path
   );
   

2. После завершения запроса в нижней панели результатов запроса щелкните вкладку «График» (расположенную рядом с вкладкой «Таблица результатов »).

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

Анатомия GQL-запроса

Давайте разберем только что выполненный нами GQL-запрос:

• GRAPH_TABLE : Указывает BigQuery выполнить запрос к графу свойств на основе графа logistics_network .
• MATCH : Объявляет шаблон многошагового обхода. Мы начинаем с Manifest ( m ), сопоставляем ребро :CARRIED_BY , указывающее на Vessel ( v ), затем сопоставляем ребро :OPERATED_BY , указывающее на Company ( comp ).
• GQL заменяет сложную логику объединения интуитивно понятными, читаемыми человеком стрелками связей в стиле ASCII-графики ()->[]->() , что значительно упрощает написание и оптимизацию многошаговых запросов.
• RETURN : Возвращает свойства или JSON-путь к найденным элементам.

2. Фильтрация результатов GQL-запроса

Теперь давайте отфильтруем запрос, чтобы он отображал только путь к скомпрометированному контейнеру MV-CAPYBARA-003 .

1. Вставьте следующий запрос в редактор SQL и нажмите «Выполнить» :

   SELECT * FROM GRAPH_TABLE(
     `lost_cargo_dataset.logistics_network`
     MATCH p = (m:Manifest {shipment_id: 'MV-CAPYBARA-003'})-[:CARRIED_BY]->(v:Vessel)-[:OPERATED_BY]->(comp:Company)
     RETURN TO_JSON(p) AS path
   );
   

2. В разделе «Результаты» нажмите вкладку «График» .

3. Теперь в окне просмотра отображается только активный маршрут обхода для MV-CAPYBARA-003 . Увеличьте масштаб, чтобы увидеть узлы и соединения:
   • Дважды щелкните узел Company , чтобы открыть панель свойств. В разделе «Свойства» вы увидите оператора company_id : 103 (Davy Jones Shipping). Запишите этот идентификатор компании — он понадобится вам позже для получения кода доступа из реестра безопасности!
   • Дважды щелкните по узлу Vessel , чтобы убедиться, что это « Flying Dutchman .

Проверка статуса :

• Что мы достигли : Мы использовали наш сетевой граф недвижимости для определения оператора судна, перевозившего пропавший груз ( company_id: 103 / Davy Jones Shipping ).
• Что нам нужно сделать дальше : более детально изучить наш график, чтобы определить, куда направляется поврежденное судно.

6. Общайтесь со своим графом, используя аналитику диалогов.

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

1. Запустите сессию анализа диалогов.

1. В консоли Google Cloud перейдите в консоль BigQuery и разверните панель ресурсов, чтобы найти свой набор данных ( lost_cargo_dataset ).
2. Щелкните по ресурсу Property Graph: logistics_network .
3. В панели инструментов вверху, на вкладке с подробной информацией, нажмите кнопку «Чат» . Это откроет сессию анализа разговоров, предварительно загруженную контекстом вашего графика.

Совет : Агент анализа диалогов автоматически считывает структуру вашего графа, предварительно загружая его контекст при нажатии кнопки «Чат».

2. Определите ближайший порт стыковки угнанного контейнера.

Морской патрульный самолет только что обнаружил судно, соответствующее описанию нашего грузового судна, которое отчаливает вдали от берега (с деактивированным транспондером) по координатам POINT(-122.48 37.55) . Чтобы перехватить груз, нам необходимо найти ближайший порт, где действует теневой синдикат Davy Jones Shipping .

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

1. В окне чата «Аналитика разговоров» введите следующую подсказку:

   Find all ports associated with Davy Jones Shipping vessels. Which port is closest to coordinate POINT(-122.48 37.55), show the distance in km, and display it on a map.
   

2. Внимательно посмотрите на ответ. Агент обходит граф и возвращает ближайшую стыковочную станцию ​​и расстояние до неё:
   • Порт швартовки : Mountain View Terminal
   • Расстояние : 39.42 kilometers
3. Благодаря тому, что система анализа разговорных данных работает на платформе Gemini с интеграцией геопространственных данных (ГИС), она может интерпретировать географические координаты и использовать свои знания о мире для проверки местоположения: «Судно находится примерно в 39,42 километрах от терминала Маунтин-Вью, Калифорния, что указывает на то, что оно направляется туда для швартовки».

Это подтверждает, что наш груз направляется прямо в Маунтин-Вью!

В основе: язык запросов к графам (GQL) и геопространственные ГИС.

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

SELECT port_id, port_name, country, latitude, longitude, distance_km 
FROM GRAPH_TABLE(
  `lost_cargo_dataset.logistics_network`
  MATCH (c:Company)<-[]-(v:Vessel)-[]->(p:Port)
  WHERE LOWER(c.company_name) = 'davy jones shipping'
  COLUMNS (
    p.port_id, 
    p.port_name, 
    p.country, 
    p.latitude, 
    p.longitude, 
    ROUND(ST_DISTANCE(ST_GEOGPOINT(p.longitude, p.latitude), ST_GEOGPOINT(-122.48, 37.55)) / 1000, 2) AS distance_km
  )
)
ORDER BY distance_km ASC;

Благодаря сочетанию встроенных геопространственных (ГИС) функций ( ST_DISTANCE , ST_GEOGPOINT ) с сопоставлением графа свойств GQL , BigQuery динамически определяет операционную зону синдиката и вычисляет реальную физическую близость в одном запросе!

Проверка статуса :

• Что мы сделали : Используя анализ разговорной речи, мы отследили порты стыковки флота теневого оператора ( Manifest ➔ Vessel ➔ Company ➔ Docks ) и рассчитали, что подозрительное судно направляется прямо к терминалу Маунтин-Вью (всего около 39 км).
• Что нам нужно сделать дальше : найти реестр данных, содержащий код ручного разблокирования, чтобы наша местная группа тактического реагирования могла перехватить груз и вручную разблокировать контейнер после его прибытия на терминал Маунтин-Вью!

7. Найдите недостающие данные с помощью Каталога знаний.

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

В реальной корпоративной среде с сотнями наборов данных и таблиц поиск этой информации может быть затруднительным. Мы воспользуемся Knowledge Catalog для выполнения семантического поиска и нахождения нужной таблицы.

1. Семантический поиск в каталоге знаний

1. В консоли Google Cloud найдите и перейдите в раздел «Каталог знаний» ➔ «Поиск» .
2. В столбце фильтра поиска в разделе «Системы» установите флажок «BigQuery» , чтобы сузить результаты поиска.
3. В поле поиска введите следующий запрос:

   container override codes
   

4. Щелкните по ресурсу таблицы maritime_security_registry , который отобразится в результатах поиска:

При изучении схемы метаданных вы увидите, что таблица содержит столбцы с данными о безопасности контейнеров, такие как co_id компании-координатора, токен хранителя cust_tok и, что наиболее важно, столбец с паролем для переопределения безопасности контейнера: clc_ovr_cd .

Мы успешно обнаружили и стол, и именно ту надежную опору, которая нам нужна для извлечения груза!

Внутренняя структура: Семантическое сопоставление : Название таблицы ( maritime_security_registry ) и название её ключевого столбца ( clc_ovr_cd ) совершенно неясны. Без семантического поиска в Knowledge Catalog, анализирующего описание столбца («Secure container override passcode»), найти эту таблицу, выполнив поиск по запросу «override codes», было бы практически невозможно.

🔓 Реальное управление : В производственной корпоративной среде команды по безопасности и управлению также используют:

• Аспекты и шаблоны тегов : для прикрепления бизнес-метаданных (таких как владелец данных , срок хранения или классификация персональных данных ) к схемам таблиц.
• Отслеживание происхождения данных : Автоматическое создание визуальных блок-схем, отображающих, как таблицы, такие как maritime_security_registry , запрашиваются и используются нижестоящими системами.

2. Проверка безопасности столбцов в BigQuery

1. Вернитесь в консоль BigQuery .
2. На вкладке «Проводник» выберите lost_cargo_dataset и щелкните таблицу maritime_security_registry .
3. Перейдите на вкладку «Схема» .

4. Обратите внимание, что столбец clc_ovr_cd защищен тегом политики с именем MaskShippingDetails (указан в столбце «Теги политики»).
5. Откройте новую вкладку редактора SQL в BigQuery и попробуйте просмотреть коды переопределения реестра, выполнив следующий запрос:

   SELECT * FROM `lost_cargo_dataset.maritime_security_registry` 
   WHERE co_id = 103;
   

6. Поскольку у вашей учетной записи пока нет разрешений на чтение столбцов, помеченных тегом MaskShippingDetails , запрос немедленно завершится ошибкой безопасности базы данных «Доступ запрещен» :

Проверка статуса :

• Чего мы достигли : Нашли защищенную таблицу ( maritime_security_registry ) и столбец ( clc_ovr_cd ), содержащие код переопределения.
• Что нам нужно сделать дальше : Предоставьте вашей учетной записи права на чтение для защищенного столбца.

8. Взлом защиты столбцов для получения пароля

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

1. Политика предоставления прав доступа. Разрешения для тегов.

1. В левой панели навигации консоли BigQuery перейдите к разделу «Теги политик» .
2. Выберите таксономию с названием LostCargoSecurity_ .
3. В списке тегов нажмите MaskShippingDetails .
4. В панели «Информация» в правой части экрана нажмите «Добавить субъект» . (Если панель скрыта, нажмите «Показать панель информации» в правом верхнем углу).
5. В поле «Новые участники» введите адрес электронной почты вашего активного пользователя Google Cloud.
6. В раскрывающемся списке «Выберите роль» найдите и выберите «Продвинутый читатель» , затем нажмите «Сохранить» .

2. Запрос кода переопределения.

Вернитесь в редактор рабочей области BigQuery. Поскольку теперь у вас есть детальный доступ для чтения, мы сможем снова запустить запрос и увидеть данные без маскировки:

SELECT *  FROM `lost_cargo_dataset.maritime_security_registry` 
WHERE co_id = 103;

🔓 Результат

Запрос возвращает незамаскированный код переопределения:

SHIVER-ME-TIMBERS-888

Миссия выполнена! 🚢

Поздравляем! Объединив графы свойств BigQuery и аналитику диалогов с каталогом знаний и безопасностью на уровне столбцов , вы успешно отследили теневой парк и извлекли код безопасного переопределения контейнеров!

Группа тактического перехвата направлена ​​к терминалу в Маунтин-Вью ! Вооружившись расшифрованным кодом доступа, они готовы открыть контейнер «Капибара», обеспечить сохранность груза и успешно вернуть наши потерянные активы.

9. Уборка

Во избежание дополнительных расходов, очистите ресурсы песочницы, созданные в ходе этой лабораторной работы.

Вернитесь в терминал Cloud Shell и удалите набор данных BigQuery , содержащий таблицы логистики:

bq rm -r -f -d lost_cargo_dataset

Удалите клонированные файлы репозитория:

cd ..
rm -rf data-cloud-roadshow-26

10. Поздравляем!

Вы успешно завершили расследование и получили код разрешения на доступ!

Что вы узнали

• Как построить граф свойств в BigQuery для представления сложных сущностей и связей.
• Как настраиваются узлы , ребра , свойства и метки для захвата соединений с данными.
• Как выполнять запросы к графам свойств с использованием естественного языка в BigQuery Conversational Analytics .
• Как структурируются выражения языка запросов к графам (GQL) для обхода реляционных путей.
• Как обнаруживать защищенные активы с помощью каталога знаний и получать доступ к данным с ограниченным доступом на уровне столбцов с помощью тегов политик.

Ссылки на ресурсы

• Обзор разговорной аналитики BigQuery
• Справочник по синтаксису графов свойств BigQuery
• Интеграция с каталогом знаний