По мере того, как клиенты переходят к модернизации своих архитектур до lakehouse, они стандартизируют открытые форматы, такие как Apache Iceberg, чтобы создать общее хранилище данных, совместимое с различными движками. Это позволяет создавать lakehouse, ориентированные на ИИ, которые преобразуют данные в семантические знания, позволяют принимать проактивные меры и работать в масштабе агентов.
Одним из ключевых компонентов lakehouse является каталог, и в среде Apache Iceberg это обычно означает Iceberg REST Catalog. Каталог Apache Iceberg отвечает за поддержание указателей таблиц, обработку атомарных коммитов и служит единственным источником правды для местоположения таблиц. Однако по мере того, как крупные корпоративные организации переходят к модернизации своих архитектур до lakehouse, они начинают понимать, что им нужен высокомасштабируемый и доступный управляемый каталог в рамках их архитектуры lakehouse. Это становится еще более важным по мере того, как масштабирование запросов происходит с помощью агентов. Для поддержки большого количества повторяющихся небольших запросов от агентов вам потребуется построить систему на базе управляемого каталога, который обеспечивает атомарность, согласованность, доступность и параллелизм в огромных масштабах.
В этом блоге мы исследуем проблемы, с которыми сталкивается управляемый каталог в современных облачных средах в масштабе агентов, и покажем вам, как серверный каталог времени выполнения Lakehouse от Google Cloud может помочь их решить. Работая на базе Spanner — всегда доступной базы данных Google Cloud с практически неограниченным масштабированием и созданной в соответствии со спецификацией открытого каталога Apache Iceberg REST, — каталог времени выполнения Lakehouse является высокомасштабируемой и доступной основой, которая вам нужна для эпохи агентов.
Проблемы, которые должен решить управляемый каталог в Lakehouse
При общении с инженерами данных и руководителями инфраструктуры, которые осуществляют масштабный производственный анализ в Lakehouse, постоянно возникают следующие основные проблемы, которые должны быть решены управляемым каталогом:
Атомарные коммиты и контроль параллелизма: Iceberg гарантирует транзакции ACID с помощью оптимистического контроля параллелизма (OCC). Управляемый каталог должен реализовать надежную атомарную операцию сравнения и замены (CAS) для замены текущего указателя метаданных.
Высокая доступность и оперативное обслуживание: Поскольку запросы немедленно не удаются, если каталог недоступен, управляемый каталог становится критически важной службой уровня Tier-1.
Масштабирование базы данных, поддерживающей каталог: Архитекторы каталогов обычно сталкиваются с трудным выбором, когда выбирают базу данных для поддержки метаданных и состояния таблиц. Традиционные масштабируемые реляционные базы данных обеспечивают SQL и транзакции ACID, но достигают вертикальных ограничений процессора, памяти, хранилища и соединений при высокой нагрузке одновременного чтения/записи, если только их не разделить вручную, что влечет за собой огромные операционные издержки; в то время как масштабируемые базы данных либо являются в конечном итоге согласованными, либо трудными в управлении, либо не готовыми для предприятий, либо всеми вышеуказанными.
Координация обслуживания таблиц: Каталог сам по себе не оптимизирует данные; вам необходимо построить и эксплуатировать вспомогательные конвейеры для компактификации, истечения сроков снимков, переписывания манифестов и очистки орфанных файлов.
Управление и безопасность: Каталог выступает в качестве охранника безопасности. Каталог должен реализовывать и поддерживать:
- Протоколы аутентификации (например, обмен токенами OAuth2, федерация IAM)
Протоколы аутентификации (например, обмен токенами OAuth2, федерация IAM)
- Контроль доступа до уровня пространств имен и таблиц
Контроль доступа до уровня пространств имен и таблиц
- Предоставленные учетные данные для хранилища (например, генерация краткосрочных токенов, чтобы движки запросов не нуждались в широких, прямых учетных данных для хранилища)
Предоставленные учетные данные для хранилища (например, генерация краткосрочных токенов, чтобы движки запросов не нуждались в широких, прямых учетных данных для хранилища)
Каталог времени выполнения Lakehouse
Для решения этих проблем мы создали каталог времени выполнения Lakehouse (GA) с поддержкой Iceberg Rest Catalog. Каталог времени выполнения Lakehouse — это полностью серверный, высокодоступный и единый реестр метаданных, разработанный с нуля для поддержки современных открытых форматов таблиц, таких как Apache Iceberg. Нативно реализуя спецификацию Apache Iceberg REST Catalog, каталог времени выполнения Lakehouse отделяет обнаружение метаданных от вычислительных движков, помогая обеспечить, чтобы несколько совместимых с Iceberg движков могли получить доступ к общему хранилищу данных и позволив вам быстрее вывести ваши рабочие нагрузки в производство. Мы помогли многим клиентам упростить миграцию их управляемых каталогов. Например, Etsy мигрировал свой каталог в Lakehouse runtime catalog, объединив данные на месте, чтобы ускорить запросы конвейера на 60%.
Этот подход предлагает ряд архитектурных преимуществ:
- Открытые API: Поддержка Iceberg Rest Catalog позволяет различным командам использовать свои предпочтительные аналитические инструменты на едином, унифицированном наборе данных.
- Мульти-движковая взаимозаменяемость: После регистрации таблицы немедленно становятся доступными для обнаружения и запросов через Google Cloud Managed Service для Apache Spark, BigQuery и открытые движки через стандартные REST-интерфейсы.
Мульти-движковая взаимозаменяемость: После регистрации таблицы немедленно становятся доступными для обнаружения и запросов через Google Cloud Managed Service для Apache Spark, BigQuery и открытые движки через стандартные REST-интерфейсы.
- Взаимозаменяемость чтения/записи для таблиц Iceberg: Используйте совместимые с Iceberg движки, такие как BigQuery, Managed Spark, для записи в таблицы Iceberg, зарегистрированные в каталоге времени выполнения Lakehouse. Клиенты также могут использовать Managed Spark для записи в таблицы Iceberg в внешних каталогах.
Взаимозаменяемость чтения/записи для таблиц Iceberg: Используйте совместимые с Iceberg движки, такие как BigQuery, Managed Spark, для записи в таблицы Iceberg, зарегистрированные в каталоге времени выполнения Lakehouse. Клиенты также могут использовать Managed Spark для записи в таблицы Iceberg в внешних каталогах.
- Полностью управляемое хранилище Iceberg с корпоративными функциями: Используйте дифференцированную инфраструктуру Google для выполнения аналитики с высокой производительностью на таблицах Iceberg. Это дает вам преимущества гибкости открытого исходного кода, а также производительность, масштабируемость, управление и мультимодальную обработку.
Полностью управляемое хранилище Iceberg с корпоративными функциями: Используйте дифференцированную инфраструктуру Google для выполнения аналитики с высокой производительностью на таблицах Iceberg. Это дает вам преимущества гибкости открытого исходного кода, а также производительность, масштабируемость, управление и мультимодальную обработку.
- Нулевое копирование данных: Определения таблиц указывают напрямую на ваши существующие данные в базовом объектном хранилище. Вы не перемещаете, не переписываете и не дублируете ваши базовые данные.
Нулевое копирование данных: Определения таблиц указывают напрямую на ваши существующие данные в базовом объектном хранилище. Вы не перемещаете, не переписываете и не дублируете ваши базовые данные.
- Двунаправленная федерация каталогов между облаками: Получите доступ к данным из Databricks Unity, Snowflake Horizon и AWS Glue с поддержкой предоставленных учетных данных и обмена токенами OIDC. Это позволяет вам принести Google AI напрямую к вашим данным в AWS и Azure.
Двунаправленная федерация каталогов между облаками: Получите доступ к данным из Databricks Unity, Snowflake Horizon и AWS Glue с поддержкой предоставленных учетных данных и обмена токенами OIDC. Это позволяет вам принести Google AI напрямую к вашим данным в AWS и Azure.
- Безопасный доступ с использованием выдачи учетных данных: каталог поддерживает несколько механизмов авторизации, позволяя выбирать между выдачей учетных данных и учетными данными конечного пользователя. Это означает, что вы можете получать доступ к таблицам с помощью современных механизмов, таких как выдача учетных данных, без необходимости прямого доступа к файлам в базовом объектном хранилище (Cloud Storage, AWS S3, Azure Blob Storage).
Безопасный доступ с использованием выдачи учетных данных: каталог поддерживает несколько механизмов авторизации, позволяя выбирать между выдачей учетных данных и учетными данными конечного пользователя. Это означает, что вы можете получать доступ к таблицам с помощью современных механизмов, таких как выдача учетных данных, без необходимости прямого доступа к файлам в базовом объектном хранилище (Cloud Storage, AWS S3, Azure Blob Storage).
- Контекст и управление на базе ИИ: каталог среды выполнения Lakehouse интегрируется напрямую с Knowledge Catalog и Cloud IAM, что позволяет определять доверенный контекст для ваших агентов и последовательно применять безопасность на уровне таблиц во всех вычислительных движках. Получите готовые функции поиска, отслеживания происхождения данных и аналитики для таблиц Iceberg в каталоге.
Контекст и управление на базе ИИ: каталог среды выполнения Lakehouse интегрируется напрямую с Knowledge Catalog и Cloud IAM, что позволяет определять доверенный контекст для ваших агентов и последовательно применять безопасность на уровне таблиц во всех вычислительных движках. Получите готовые функции поиска, отслеживания происхождения данных и аналитики для таблиц Iceberg в каталоге.
- Атомарные фиксации и контроль параллелизма, высокая доступность и масштабируемость: благодаря инфраструктуре Google планетарного масштаба и Spanner вы получаете высокую доступность, параллелизм и масштабируемость, необходимые для того, чтобы ваши метаданные росли вместе с вашими данными. Поддержка двухрегиональных и мультирегиональных бакетов Cloud Storage позволяет реализовать сценарии аварийного переключения. Это также обеспечивает снижение совокупной стоимости владения (TCO) благодаря бессерверным и не требующим обслуживания средам, а также масштабируемость для рабочих нагрузок любого размера.
Атомарные фиксации и контроль параллелизма, высокая доступность и масштабируемость: благодаря инфраструктуре Google планетарного масштаба и Spanner вы получаете высокую доступность, параллелизм и масштабируемость, необходимые для того, чтобы ваши метаданные росли вместе с вашими данными. Поддержка двухрегиональных и мультирегиональных бакетов Cloud Storage позволяет реализовать сценарии аварийного переключения. Это также обеспечивает снижение совокупной стоимости владения (TCO) благодаря бессерверным и не требующим обслуживания средам, а также масштабируемость для рабочих нагрузок любого размера.
Что лежит в основе каталога среды выполнения Lakehouse?
Каталог среды выполнения Lakehouse — это высокодоступный, параллельный и масштабируемый каталог с гарантиями строгой согласованности, поскольку он построен на базе Spanner. В отличие от традиционных реляционных баз данных с вертикальным масштабированием, которые упираются в ограничения одного узла, Spanner сочетает в себе полную семантику реляционного SQL и транзакции ACID для нескольких таблиц с эластичностью горизонтального масштабирования как для чтения, так и для записи, характерной для систем NoSQL.
Spanner обеспечивает высокую доступность каталога среды выполнения Lakehouse за счет региональных конфигураций с уровнем доступности до 99,99%. Spanner также обеспечивает готовую масштабируемость для каталога среды выполнения Lakehouse: будучи горизонтально масштабируемой базой данных, Spanner не требует ручного шардирования и масштабирует вычислительные ресурсы и хранилище независимо и прозрачно. Spanner динамически отслеживает объем данных и нагрузку на запросы, разделяя и перераспределяя диапазоны данных между узлами. Вычислительные узлы масштабируются динамически на основе использования ЦП и пороговых значений хранилища. Spanner автоматически обнаруживает перегрузку на уровне разделов и перемещает тяжелые разделы с перегруженных узлов. Spanner также позволяет пользователям каталога среды выполнения Lakehouse устранить традиционные компромиссы между реляционной согласованностью и распределенной масштабируемостью, обеспечивая лучшие в отрасли гарантии согласованности. Транзакции Lakehouse являются сериализуемыми — порядок транзакций в базе данных совпадает с порядком, в котором клиенты наблюдают их фиксацию. Эта основа позволяет пользователям Lakehouse работать в масштабах агентов.
Затем, для дальнейшей поддержки агентских сценариев использования, каталог среды выполнения Lakehouse напрямую интегрируется с Knowledge Catalog, что позволяет легко обнаруживать таблицы Iceberg в Lakehouse и предоставлять агентам доверенный контекст. Knowledge Catalog использует эффективную комбинацию полнотекстового поиска и встроенного векторного поиска, предоставляемого Spanner; такой подход обеспечивает более высокую полноту поиска, объединяя лексический поиск по ключевым словам с семантическими эмбеддингами в одном запросе. Поскольку оба типа индексов построены на идентичном базовом наборе данных, они обновляются со строгой транзакционной согласованностью ACID параллельно с операциями DML базовой таблицы. Это устраняет операционные накладные расходы, такие как управление конвейерами синхронизации, а также внешними системами векторного и полнотекстового поиска. Короче говоря, каталог среды выполнения Lakehouse обеспечивает более быстрый вывод ваших агентских решений на рынок.
Объединение аналитических и операционных рабочих нагрузок
С помощью безграничного Lakehouse от Google Cloud на базе Apache Iceberg вы можете объединить свои аналитические данные с операционными рабочими нагрузками. Сценарии использования варьируются от объединения активов данных из вашего Lakehouse с данными OLTP (из Spanner) для аналитики до приложений обслуживания с низкой задержкой, где ваши активы Lakehouse доступны в операционной базе данных, такой как Spanner, и до разговорной аналитики в собственных и сторонних агентах.
Ниже, в примере, вы можете увидеть каталог среды выполнения Lakehouse со Spanner в действии. Здесь мы объединяем аналитические данные о поездках на такси на Манхэттене (на базе Apache Iceberg) с операционными данными о зонах такси в Spanner, чтобы найти наиболее загруженные транспортные маршруты. Пример также показывает, что вы можете использовать агента разговорной аналитики для доступа к тем же данным и получения аналитических выводов второго порядка.
Найдите наиболее загруженные транспортные маршруты на Манхэттене
Модернизация до безграничного Lakehouse
Модернизация до Lakehouse от Google Cloud минимизирует разрозненность данных между аналитическими движками и агентами, унифицирует управление несколькими движками, предоставляет доверенный контекст вашим агентам и сокращает операционные расходы (TCO). Использование каталога среды выполнения Lakehouse на базе Spanner помогает подготовить ваши современные облачные среды к работе в масштабах агентов. Чтобы узнать больше и начать работу с бесплатной пробной версией, посетите
веб-страницу Lakehouse и узнайте больше о Spanner здесь.
- Аналитика данных
- Базы данных
