Упорядочение геопространственных данных с помощью каталога ресурсов SpatioTemporal (STAC)

  • Статья

В этой эталонной архитектуре показана сквозная реализация создания каталога ресурсов SpatioTemporal (STAC) для структуры геопространственных данных. В этом документе мы будем использовать общедоступный набор данных Программы изображений национального сельского хозяйства (NAIP) с помощью геопространственных библиотек в Azure. Архитектура может быть адаптирована для получения наборов данных из других источников, таких как поставщики спутниковых изображений, земная станция Azure (AOGS) или перенос собственных данных (BYOD).

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

Реализация этой архитектуры доступна на сайте GitHub.

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

Подробности сценария

Сбор данных Spaceborne становится все более распространенным. Существуют различные поставщики данных для ресурсов spatiotemporal, таких как Imagery, Искусственный радар диафрагмы (SAR), Point Clouds и т. д. У поставщиков данных нет стандартного способа предоставления пользователям доступа к их spatiotemporal data. Пользователи данных spatiotemporal часто перегружены созданием уникальных рабочих процессов для каждой коллекции данных, которые они хотят использовать. Разработчикам необходимо разработать новые инструменты и библиотеки для взаимодействия с данными spatiotemporal.

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

В нашем примере решения используются открытый код средства, такие как STAC FastAPI, pystac, API планетарных компьютеров Майкрософт и открыты стандартные геопространственные библиотеки (перечисленные в разделе "Компоненты") для запуска решения в Azure.

Потенциальные варианты использования

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

Вот несколько примеров.

  • Компания-поставщик спутниковых данных должна легко обнаруживать и получать доступ к данным. Поставщик создает каталоги STAC для индексирования всех своих исторических архивных наборов данных, а также входящих данных обновления на ежедневной основе. Пользовательский интерфейс веб-клиента построен на основе API-интерфейсов STAC, позволяющих пользователям просматривать каталоги и искать нужные изображения на основе интересующей области (AOI), диапазона даты и времени и других параметров.

  • Компания по анализу геопространственных данных должна создать базу данных данных spaceborne, включая изображения, модель цифрового повышения прав (DEM) и трехмерные типы, полученные из различных источников данных. База данных будет служить своему решению анализа географической информационной системы (GIS) для агрегирования различных наборов данных для анализа объектов на основе модели машинного обучения. Для поддержки стандартного уровня доступа к данным компания решает реализовать интерфейс API STAC, совместимый с открытый код, для решения анализа GIS для взаимодействия с базой данных в масштабируемом и производительном режиме.

Архитектура

Diagram of STAC architecture.

Скачайте файл Visio для этой архитектуры.

Поток данных

STAC dataflow diagram.

Скачайте файл Visio для этого потока данных.

В следующих разделах описаны четыре этапа архитектуры.

Получение данных

Создание метаданных

  • Поставщики данных определяют метаданные, описывающие поставщика, условия лицензии, ключевое слово и т. д. Эти метаданные образуют коллекцию STAC.
  • Поставщики данных могут предоставлять метаданные, описывающие геопространственные ресурсы. В нашем примере мы используем метаданные, предоставляемые NAIP и FGDC. Дополнительные метаданные извлекаются из ресурсов с помощью стандартных геопространственных библиотек. Эти метаданные образуют элементы STAC.
  • Эта коллекция и элементы STAC используются для создания каталога STAC, который помогает пользователям обнаруживать ресурсы spatiotemporal с помощью API STAC.

Каталогизации

  • Каталог STAC

    • Каталог STAC — это объект верхнего уровня, который логически группируется с другими объектами каталога, коллекции и элементов. В рамках развертывания этого решения мы создадим каталог STAC, в котором организованы все коллекции и элементы.

  • Коллекция STAC

    • Это связанная группа элементов STAC, доступная поставщиком данных.
    • Поисковые запросы для обнаружения ресурсов область на уровне коллекции STAC.
    • Он создается для поставщика данных, NAIP в данном случае, и эти метаданные JSON передаются в контейнер служба хранилища Azure.
    • Отправка файла метаданных коллекции STAC запускает сообщение для Служебная шина Azure.
    • Обработчик обрабатывает эти метаданные в кластере Azure Kubernetes и выполняет прием в базу данных каталога STAC (база данных PostgreSQL). Существуют разные процессоры для разных поставщиков данных, и каждый процессор подписывается на соответствующий служебная шина раздел.

  • Элемент и ресурс STAC

    • Ресурс, который необходимо каталогизировать (растровые данные в виде GeoTiff, Cloud Optimized GeoTiff и т. д.). Метаданные, описывающие ресурс и метаданные, извлеченные из ресурса, передаются в учетную запись служба хранилища в соответствующем контейнере хранилища.
    • Затем ресурсы (GeoTiff) отправляются в учетную запись служба хранилища в соответствующем контейнере хранилища после успешной отправки соответствующих метаданных.
    • Каждый ресурс и связанные с ним метаданные, отправленные в учетную запись служба хранилища, активирует сообщение в служебная шина. Эти метаданные образуют элемент STAC в базе данных каталога.
    • Обработчик обрабатывает эти метаданные в кластере Azure Kubernetes и выполняет прием в базу данных каталога STAC (база данных PostgreSQL).

Обнаружение данных

  • API STAC основан на открытый код STAC FastAPI.
  • Уровень API STAC реализуется на Служба Azure Kubernetes, а API предоставляются с помощью службы Управление API.
  • API STAC используются для обнаружения геопространственных данных в каталоге. Эти API основаны на спецификациях STAC и понимают метаданные STAC, определенные и индексированные в базе данных каталога STAC (сервер PostgreSQL).
  • На основе критериев поиска можно быстро найти данные из большого набора данных.
    • Запрос коллекции STAC, элементов и ресурсов:
      • Запрос отправляется пользователем для поиска одной или нескольких коллекций STAC, элементов и ресурсов через STAC FastAPI.
      • STAC FastAPI запрашивает данные в базе данных PostgreSQL для получения коллекции STAC, элементов и ссылок на ресурсы.
      • Результат возвращается пользователю с помощью STAC FastAPI.

Компоненты

В этой архитектуре используются следующие службы Azure.

  • Key Vault хранит секреты, такие как токены, пароли и ключи API, а также управляет доступом к ним. Key Vault также создает и контролирует ключи шифрования и управляет сертификатами безопасности.
  • служебная шина является частью более широкой инфраструктуры обмена сообщениями Azure, которая поддерживает очереди, публикацию и подписку и более сложные шаблоны интеграции.
  • Azure Data Lake служба хранилища предназначен для аналитики больших данных и основан на Хранилище BLOB-объектов Azure.
  • Виртуальная сеть Azure позволяет ресурсам Azure безопасно взаимодействовать друг с другом, с Интернетом и локальными сетями.
  • Гибкий сервер Базы данных Azure для PostgreSQL — это полностью управляемая служба базы данных, которая обеспечивает более детализированный контроль и гибкость функций управления базами данных, а также параметрами конфигурации. Она имеет более широкие возможности, такие как устойчивость зоны высокой доступности (HA), прогнозируемая производительность, максимальный контроль, пользовательское окно обслуживания, элементы управления оптимизацией затрат и упрощенное взаимодействие разработчика, подходящее для рабочих нагрузок предприятия.
  • службы Управление API предлагают масштабируемую платформу управления API с несколькими облаками для защиты, публикации и анализа API.
  • Служба Azure Kubernetes предлагает самый быстрый способ начать разработку и развертывание облачных приложений с встроенными конвейерами кода в облако и охранниками.
  • Реестр контейнеров для хранения образов контейнеров и связанных артефактов и управления ими.
  • Виртуальная машина обеспечивает гибкость виртуализации для широкого спектра вычислительных решений. В полностью защищенном развертывании пользователь подключается к виртуальной машине через Бастион Azure (описанный в следующем элементе ниже), чтобы выполнить ряд операций, таких как копирование файлов в учетные записи хранения, выполнение команд Azure CLI и взаимодействие с другими службами.
  • Бастион Azure позволяет безопасно и легко RDP и SSH работать с виртуальными машинами в виртуальной сети Azure без необходимости общедоступного IP-адреса на виртуальной машине непосредственно из портал Azure и без необходимости любого другого клиента или агента или любого программного обеспечения.
  • Приложение Аналитика обеспечивает расширяемое управление производительностью приложений и мониторинг динамических веб-приложений.
  • Log Analytics — это средство для редактирования и выполнения запросов журналов из данных, собранных журналами Azure Monitor и интерактивного анализа результатов.

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

  • GDAL — это библиотека инструментов для управления данными пробелов. GDAL работает с типами растровых и векторных данных. Это хороший инструмент, чтобы узнать, работает ли вы с данными spaceborne.
  • Rasterio — это модуль для обработки растровых данных. Его можно использовать для чтения и записи нескольких различных форматов растров в Python. Rasterio основан на GDAL. При импорте модуля Python автоматически регистрирует все известные драйверы GDAL для чтения поддерживаемых форматов.
  • Фигурная форма — это пакет Python для набора теоретических анализов и манипуляций с планарными функциями. Он использует функции (с помощью модуля ctypes Python) из широко развернутой библиотеки GEOS.
  • pyproj выполняет картографические преобразования. Он преобразуется из долготы и широты в собственную проекцию карты x, координаты y и наоборот, используя PROJ.

Рекомендации

  • В примере решения демонстрируется базовая поддержка JSON STAC, необходимая для взаимодействия с любой геопространственной коллекцией данных. Хотя STAC стандартизирует поля метаданных, соглашения об именовании, язык запросов и структуру каталога, пользователи также должны учитывать расширения STAC для поддержки полей метаданных, относящихся к их ресурсам.

  • В примере реализации компоненты, обрабатывающие ресурс для извлечения метаданных, имеют определенное количество реплика. Масштабирование этого компонента позволяет быстрее обрабатывать ресурсы. Однако масштабирование не является динамическим. Если требуется каталогировать большое количество ресурсов, рассмотрите возможность масштабирования этих реплика.

Добавление нового источника данных

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

  • Определите коллекцию STAC для источника данных. Поисковые запросы область на уровне коллекции STAC. Рассмотрим, как пользователь будет искать элементы и ресурсы STAC в коллекции.
  • Создайте метаданные элемента STAC. Дополнительные метаданные могут быть производными от геопространственных ресурсов с помощью стандартных средств и библиотек. Определите и реализуйте процесс для сбора дополнительных метаданных для ресурсов, которые будут полезны при использовании элементов STAC и, в свою очередь, упрощают обнаружение данных с помощью API.
  • После того как эти метаданные (в форме коллекции STAC и элементов STAC) доступны для источника данных, этот пример решения можно использовать для создания каталога STAC с помощью одного потока. Данные после каталогизации будут запрашиваться с помощью стандартных API STAC.
  • Компонент процессора этой архитектуры расширяем, чтобы включить пользовательский код, который можно разрабатывать и запускать как контейнеры в кластере Azure Kubernetes. Он предназначен для предоставления способа для различных представлений геопространственных данных, которые будут каталогизуться в качестве активов.

Безопасность

Безопасность обеспечивает гарантии от преднамеренного нападения и злоупотребления ценными данными и системами. Дополнительные сведения см. в разделе "Общие сведения о компоненте безопасности".

Оптимизация затрат

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

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

Пользователи также могут настраивать конфигурации в соответствии с рабочей нагрузкой и масштабированием. Например, вы можете заменить диски HDD уровня "Стандартный" для SSD уровня "Премиум" в кластере AKS или масштабировать службы Управление API на номера SKU уровня "Премиум".

Оптимизация производительности

Уровень производительности — это способность вашей рабочей нагрузки эффективно масштабироваться в соответствии с требованиями, предъявляемыми к ней пользователями. Дополнительные сведения см. в разделе "Общие сведения о эффективности производительности". Кроме того, приведенные ниже рекомендации могут быть полезны при повышении эффективности производительности.

Развертывание этого сценария

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

На высоком уровне это развертывание выполняет следующие действия.

  • Развертывает различные компоненты инфраструктуры, такие как Служба Azure Kubernetes, сервер Azure PostgreSQL, Azure Key Vault, учетная запись служба хранилища Azure, Служебная шина Azure и т. д. в частной сети.

  • Развертывает службу azure Управление API и публикует конечную точку для STAC FastAPI.

  • Упаковывает код и его зависимости, создает образы контейнеров Docker и отправляет их в Реестр контейнеров Azure.

    Diagram of STAC deployment services.

Скачайте файл Visio для этой реализации.

Следующие шаги

Если вы хотите начать создание этого, мы собрали пример решения, рассмотренного кратко выше. Ниже приведены некоторые полезные ссылки для начала работы с реализацией STAC и модели.

Глоссарий

Термин STAC Определение
Актив Любой файл, представляющий данные пробела, захваченные в определенном пространстве и времени.
Спецификация STAC Позволяет описать геопространственные данные, чтобы его можно было легко индексировать и обнаруживать.
Элемент STAC Основная атомарная единица, представляющая один ресурс spatiotemporal как функцию GeoJSON, а также метаданные, такие как datetime и ссылочные ссылки.
Каталог STAC Простой гибкий JSON, который предоставляет структуру и упорядочивает метаданные, такие как элементы STAC, коллекции и другие каталоги.
Коллекция STAC Предоставляет дополнительные сведения, такие как экстенты, лицензия, ключевое слово, поставщики и т. д., описывающие элементы STAC в коллекции.
STAC API Предоставляет конечную точку RESTful, которая обеспечивает поиск элементов STAC, указанных в OpenAPI.