Введение: Trino, Data Lakehouse и Iceberg — базовые контексты

Data Lakehouse представляет собой архитектурное представление, объединяющее гибкость и масштабируемость Data Lake с управляемостью и консистентностью Data Warehouse. В этом подходе данные остаются в древовидной иерархии хранилища объекта, но приобретают свойства надежной структуры для аналитики: транзакционные гарантии, схемы версионирования, управление качеством данных и поддержка эффективных запросов. В современном стеке основными двигателями являются федеративные SQL-платформы, такие как Trino, и форматы таблиц нового поколения, например Iceberg, которые позволяют безопасно и быстро изменять схемы, управлять версиями файлов и строить консистентные снимки данных.

Trino выступает как распределенный SQL-движок, способный выполнять запросы над различными источниками данных: файловыми системами в объектном хранилище, таблицами Iceberg, реляционными базами, кэшами и системами метаданных. Его достоинство — возможность объединять данные из разных источников в единый SQL-план без перемещения данных в отдельный warehouse. Iceberg, в свою очередь, обеспечивает управляемость метаданными и транзакционный доступ к данным, поддерживает схема-эволюцию, скрытое партиционирование и atomicity при операциях чтения и записи. Совместно они дают продуктивную основу под федеративные запросы с единым логическим представлением данных в рамках Lakehouse.

Цель данной главы — заложить базовый контекст для последующего курса: объяснить, как Trino и Iceberg работают в рамках Data Lakehouse, какие архитектурные принципы управляют федеративными запросами, какие данные и какие операции поддерживаются и каковы практические шаги внедрения в реальных проектах. Мы избегаем избыточной теории в угоду конкретным инженерным паттернам, но сохраняем достаточную глубину по вопросам архитектуры, протоколов взаимодействий и управляемости.

Ключевые концепты и цепочки: что такое Data Lakehouse и какие проблемы он решает; роль Trino как федеративного SQL-слоя; роль Iceberg как формата таблиц и слоя метаданных; принципы реализации федеративных запросов и интеграции между компонентами; сценарии внедрения и операционные практики.
Фокус на баланс: мы рассмотрим как технические аспекты, так и продуктовые и управленческие требования, чтобы обеспечить целостную картину внедрения в реальной организации.
Зачем это важно для профессионалов: понимание базовых контекстов позволит выстроить стратегию миграции, выбрать подходящие паттерны моделирования данных и обеспечить надлежащий уровень качества и управляемости данных в распределенных окружениях.
Структура главы: далее мы последовательно рассмотрим архитектурные основы, роль Iceberg, принципы федеративных запросов в Trino, интеграции и экосистему, а затем перейдем к практическим аспектам внедрения и операционной эксплуатации.
В завершение — дорожная карта для перехода к Lakehouse-подходу: на каких этапах фокусироваться на архитектуре, на каких — на процессах и управлении данными.

Краткое содержание главы

Понимание базовых концепций Data Lakehouse, Trino и Iceberg, их роли и взаимосвязей.
Архитектура федеративных запросов: как планируются и выполняются запросы в распределенной среде.
Управление метаданными Iceberg и принципы транзакций, версионирования и согласованности.
Интеграции и экосистема: коннекторы, источники данных, безопасность и управляемость.
Практические паттерны внедрения и операционные аспекты: миграция, тестирование, мониторинг и эволюция архитектуры.

Архитектурный контекст: Trino в Data Lakehouse и Iceberg

Data Lakehouse объединяет преимущества хранения больших объемов данных в object-сторе с управлением качеством, структурой и скоростью аналитических запросов, свойственными Data Warehouse. В этой модели данные остаются в формате, удобном для скейлинга, но поддерживают ACID-операции, схему и версии таблиц, что упрощает управление изменениями и поддерживает согласованность запросов across эпохами. Ключевые составляющие такие: объектное хранилище (S3, HDFS, ADLS), слой метаданных, таблицы Iceberg и вычислительный слой, предоставляющий SQL-API.

Trino реализует роль распределенного SQL-движка, состоящего из координатора и воркеров. Координатор отвечает за планирование запросов, распределение задач по воркерам, обработку кросс-джойн-запросов и слияние результатов. Воркеры исполняют части плана, читая данные из источников через коннекторы, писать данные на целевые хранилища и передавать результаты между узлами. У Интеграции Trino с Iceberg реализованы через Iceberg-коннектор: он читает и пишет таблицы Iceberg, опираясь на метаданные Iceberg, включая manifest-файлы, snapshots и схемы. Iceberg выступает не столько как слой, где данные «хранятся» отдельно, сколько как договоренность о порядке, версиях и доступности данных внутри object-store. Это обеспечивает транзакционную целостность на уровне таблиц, поддержку time travel через снимки и эффективную сортировку и фильтрацию данных.

Архитектура Lakehouse (включая Iceberg) требует продуманного управления схемами, схемами эволюции и совместимости. Iceberg поддерживает гибкость в части добавления или удаления столбцов, изменения типов и переопределения partitioning без полной миграции данных. Концепция «таблица» в Iceberg включает в себя: данные файловой части, метаданные о схеме и разделах, историю снимков и контекст, позволяющий восстанавливать состояние таблицы на конкретный момент времени. В сочетании с Trino это обеспечивает возможность выполнять сложные аналитические запросы, объединяющие Iceberg-таблицы и другие источники данных в одном SQL-предикате, используя единый план выполнения и кэширование результатов там, где это допустимо.

Федеративные запросы в таком контексте выступают как способ объединить данные из нескольких источников под единым логическим представлением. Планировщик Trino должен распознавать границы источников и минимизировать перерасход сетевых и дисковых ресурсов за счет pushdown-оптимизаций, стратегии объединения и локализации чтения. Основные принципы включают: разделение вычислений и чтение данных, оптимизацию на уровне фильтров и проекции, эффективное использование статистик Iceberg на уровне файлов и манифестов, а также координацию транзакций, где это необходимо. В рамках Iceberg это означает, что чтение таблиц может происходить на уровне конкретной версии снимка, что обеспечивает константность данных в рамках одного запроса и облегчает time travel.

Взаимодействие между компонентами строится на нескольких уровнях: на уровне хранения (данные в объектном хранилище), на уровне метаданных Iceberg (снимки, манифесты, схемы), на уровне планирования и выполнения SQL-запросов в Trino, и на уровне безопасности и доступа к данным. В контексте федеративных запросов особое значение имеет способность Trino элегантно переносить фильтры в источники данных и сводить избыточную передачу данных к минимуму. Это достигается за счет: динамической фильтрации на уровне источников, эффективной загрузки метаданных Iceberg, кэширования улучшенного уровня ожидания и оптимизированной стратегии соединений. Важно помнить, что федеративные запросы потенциально могут приводить к большим затратам, если источники данных не поддерживают агрессивное pushdown-оптимизирование или если данные плохо сегментированы. Поэтому проектирование схематических моделей и выбор форматов должны предусматривать минимизацию таких затрат.

Архитектурные принципы и протоколы взаимодействий

Координатор и воркеры: разделение ролей обеспечивает горизонтальное масштабирование, устойчивость к сбоям и балансировку нагрузки. Координатор следит за планированием и координацией, воркеры исполняют части плана и возвращают частичные результаты.
Коннекторы: каждый источник данных имеет свой коннектор, реализующий специфическую логику чтения и записи, а также доступ к метаданным. Iceberg-коннектор взаимодействует с форматом Iceberg, читает metadata-файлы и формирует физические планы чтения из файлов Parquet/ORC.
Метаданные и согласованность: Iceberg хранит независимую метаданную структуру внутри таблицы, что позволяет поддерживать версионирование и безопасное обновление схем. Trino сообщает о планах и читает статистику по файлам, что помогает оптимизировать выполнение.
Безопасность и доступ: аутентификация и авторизация должны работать на уровне каждого коннектора, а также на уровне общего каталога. Роли, политики и маппинг пользователей к данным дают возможность контролировать доступ к Iceberg-таблицам и другим источникам.
Производительность и cost-efficiency: использование фильтров на уровне файлов и манифестов Iceberg, сорсинг данных по принципу минимального количества файлов, и минимизация пересчета данных. Важной задачей является баланс между полнотой покрытия данных и эффективной пропускной способностью сети.
Эволюция схем: Iceberg поддерживает обратимую и небезопасную эволюцию схем в рамках заданной таблицы. Это требует планирования миграций схем, тестирования обратной совместимости и контроля версий, чтобы избежать состояния несовместимости между источниками и запросами.

Гибридные сценарии и примеры паттернов

Объединение Iceberg-таблиц с внешними источниками: например, запросы, которые объединяют Iceberg-таблицы в S3 с данными из реляционных систем через соответствующие коннекторы Trino. Архитектура обеспечивает единое представление данных, сохраняя при этом уникальные требования к консистентности и трансакциям на уровне каждого источника.
Аналитика, требующая времени сверки и исторических версий: time travel в Iceberg позволяет вернуться к конкретной эпохе таблицы. Это особенно полезно в сценариях аудита, контроля качества данных и восстановления после ошибок ETL.
Федеративная аналитика для метаданных: использование Iceberg как основного формата хранения и сторонних источников как дополнительной части данных для комплексного анализа. В таких случаях планировщик Trino должен учитывать различия в доступности и задержках между источниками.
Разделение нагрузок между консолидированными и локальными хранилищами: часть запросов может выполняться полностью в Iceberg, часть — через внешние источники. Эффективная маршрутизация и оптимизация позволяют минимизировать сетевые затраты и увеличить пропускную способность.

Iceberg: управление метаданными, версиями и транзакциями

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

Одной из ключевых особенностей Iceberg является версионирование: каждая запись в таблице сопровождается снимком (snapshot), который фиксирует состояние данных на конкретный момент времени. Это позволяет не только осуществлять time travel, но и выполнять параллельную обработку без конфликтов, поскольку каждый запрос может видеть устойчивую версию данных. Важным элементом является манифестная система: каждый манифест описывает набор файлов и их статистику, что позволяет быстро вычислять, какие файлы необходимы для конкретного снимка и запроса.

Схемы эволюции у Iceberg являются безопасными. Добавление столбца или изменение типа поддерживается без необходимости полного переписывания таблицы. Iceberg сохраняет старые версии схем и файлов, обеспечивая совместимость между версиями. Это облегчает миграцию систем и развитие бизнес-требований без прерывания операций. В контексте Trino Iceberg-коннектор читает и пишет в соответствии с метаданными Iceberg. Чтение может происходить с использованием метаданных и статических статистик, что позволяет планировщику Trino оптимизировать чтение и фильтрацию на уровне файлов, улучшая производительность и сокращая задержки.

Транзакционность Iceberg достигается благодаря контролю над снимками и операциями записи, которые выполняются атомарно в рамках таблицы. Это особенно важно в федеративных сценариях, когда несколько источников данных могут участвовать в сложном запросе. Iceberg обеспечивает консистентность внутри таблицы, а Trino — координацию выполнения запросов в распределенной среде. В результате пользователь получает консистентный набор данных в рамках одного запроса, даже если данные физически разбросаны по различным разделам и файлам.

Управление версиями и время жизни данных в Iceberg тесно связано с политикой хранения и бизнес-требованиями. Возможности архивирования, выбор конкретной версии таблицы и восстановление состояния позволяют строить устойчивые к сбоям аналитические сценарии, а также поддерживать аудит и соответствие регуляторным требованиям. В связке с Trino это означает, что аналитик может писать запросы, не заботясь о том, на каком именно месте лежат данные, — движок с высокой степенью абстракции возьмет на себя оптимизацию и маршрутизацию.

Архитектурные особенности Iceberg

Метаданные на уровне таблиц: снимки, манифесты, manifest-файлы и связанные таблицы, что обеспечивает эффективное чтение и минимизацию количества файлов, которые необходимо просканировать.
Схема и разделение: поддержка гибкой схемы, включая добавление/изменение столбцов, скрытое партиционирование и управление разделами.
Time travel и версия: возможность возвращаться к конкретному снимку таблицы, что полезно для аудита и восстановления после ошибок.
Консистентные операции записи: атомарность изменений на уровне таблицы, предотвращение частичных обновлений.
Интеграция с Trino: оптимизация чтения и записи через Iceberg-коннектор, использование статистик и метаданных для ускорения выполнения.

Федеративные запросы в Trino: принципы и реализация

Федеративные запросы позволяют объединять данные из разных источников в рамках одного SQL-запроса, что существенно упрощает аналитическую работу и уменьшает фрагментацию данных. В контексте Trino и Iceberg федеративность реализуется за счёт аккуратно спроектированного плана выполнения, где будут задействованы коннекторы к Iceberg и к прочим источникам, а логика запроса — единым образом доступна через SQL.

Планировщик Trino формирует физический план на основе статистик, предикатов и доступности источников. Он распознает границы источников и оптимизирует запрос с учетом затрат на сетевой трафик, чтение файлов и вычисления. Важной частью является pushdown фильтров на уровне источников, что позволяет снизить объём читаемых данных до минимума. Для Iceberg это означает использование манифестов и снимков, чтение только необходимых файлов и эффективное применение столбцовых статистик.

С точки зрения транзакций и консистентности, федеративные запросы требуют осторожного управления операциями чтения и записи, особенно если в сценарии участвуют внешние источники. Iceberg обеспечивает консистентность и версионирование на своей стороне, тогда как Trino обеспечивает согласованное планирование и выполнение across источников. Очевидно, что сложные джойны между Iceberg-таблицами и, скажем, JDBC-источниками требуют внимательного проектирования схемы данных и распределения нагрузки, чтобы не превысить лимиты по памяти и сетевым ресурсам.

Оптимизация федеративных запросов включает в себя:

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

Паттерны интеграции и сценарии

Интеграция Iceberg с другими источниками через единый SQL-профиль: сценарий, в котором Iceberg-таблица служит основным источником для части данных, а другие источники — дополнительными слоями. Это позволяет аналитикам работать с единым данным слоем без необходимости сложной подготовки.
Аналитика с временными версиями: использование Time Travel в Iceberg в рамках федеративного запроса для сравнения показателей между версиями таблиц или для аудиторской проверки.
Безопасность и соответствие: в федеративной среде важно реализовать согласованные политики доступа на уровне Trino и на уровне каждого источника. Это может потребовать совместной настройки ролей и правил доступа между коннекторами.
Эволюция схем: при добавлении новых атрибутов в Iceberg и подключении новых источников следует учитывать влияние на существующие запросы и процессы ETL. Планирование миграций должно учитывать обратную совместимость и тестирование.

Интеграции и экосистема: источники данных и коннекторы, безопасность

Ключ к успешной реализации Lakehouse-подхода — наличие продуманной экосистемы коннекторов и механизмов безопасности. Trino поддерживает широкий набор коннекторов к Iceberg и другим источникам: облачные объекты, реляционные БД, NoSQL, файло- и потоковые источники. Iceberg интегрируется через свой коннектор, предоставляющий доступ к данным в формате столбцов, с сохранием возможностей эволюции схем и версий.

Безопасность и управляемость в федеративной среде требуют сочетания подходов: аутентификации и авторизации на уровне клиента и коннекторов, использования централизованных решений по управлению доступом (Role-Based Access Control), аудита и мониторинга. Важным аспектом является поддержка политики соответствия: например, ограничение чтения чувствительных полей, контроль доступа к конкретным таблицам Iceberg и координация надежных политик между источниками.

Работа с конфигурацией и операционная устойчивость включают: управление версиями коннекторов и Iceberg, тестирование совместимости, мониторинг задержек и черезмерной загрузки, а также планирование обновлений. Важной практикой является отделение окружений: разработка, интеграционные тесты, внедрение в продакшн с постепенным переходом, поддержка rollback и миграционных сценариев. Продуктовые аспекты — это, прежде всего, понятные интерфейсы и единое пользовательское восприятие данных, сопоставимые с ожиданиями аналитиков и бизнес-пользователей.

Примеры производственных сценариев

Гибридная аналитика, объединяющая Iceberg-таблицы и внешние источники для единых дашбордов. Такой подход снижает количество ETL-процессов и упрощает управление данными.
Многофункциональные конвейеры, где Iceberg обеспечивает версионирование таблиц, а Trino — единый слой доступа и агрегацию. Это позволяет командам быстро адаптироваться к изменению бизнес требований без полной переработки инфраструктуры.
Архитектура миграции: постепенный переход к Iceberg-подходу с сохранением существующих источников данных, обеспечение совместности на каждом этапе и минимизация риска для бизнеса.

Практические аспекты внедрения: планирование, операционное обслуживание, мониторинг

Внедрение Trino в Lakehouse на базе Iceberg требует системного подхода, охватывающего архитектуру, процессы и командную культуру. Основные шаги включают:

Планирование архитектуры: определить набор источников данных, таблиц Iceberg, требования к скорости выполнения и политики безопасности. Проектирование схем данных и правил миграции. Важно учитывать не только текущие, но и будущие потребности, таким образом закладывая запас для роста.
Миграция и эволюция данных: выстраивать план миграции постепенно, обеспечивая обратную совместимость и тестируя на минимальном наборе данных. Включать тесты на качество данных, регрессию запросов и целостность транзакций.
Разработка и тестирование: внедрять практики CI/CD для конфигураций коннекторов, схем Iceberg и запросов. Включать тесты производительности и устойчивости под различными нагрузками.
Мониторинг и инфраструктура: строить механизмы мониторинга производительности запросов, задержек, пропускной способности, ошибок коннекторов и состояния Iceberg-таблиц. Наблюдение за временем жизни данных и за временем доступности снимков.
Операционная устойчивость: обеспечение резервного копирования и восстановления, управление версиями коннекторов и Iceberg, плановые обновления без остановки сервиса. Важным элементом является поддержка аварийного восстановления на уровне проекта, включая rollback изменений и восстановление данных до конкретной точки времени.
Управление качеством данных: в рамках Lakehouse необходимо внедрить проверки качества данных, политики соответствия и аудит. Инструменты в экосистеме должны быть согласованы и поддерживать требования бизнеса.
Обучение команд: развитие навыков инженеров по работе с Trino и Iceberg, обеспечение единых стандартов разработки запросов, безопасного доступа и мониторинга. Обучение должно включать как технические аспекты, так и процессы управления данными и соответствия требованиям.

Key takeaways

Data Lakehouse сочетает гибкость Data Lake и управляемость Data Warehouse за счет Iceberg и федеративного SQL-движка, такого как Trino.
Iceberg обеспечивает версионирование таблиц, безопасную схему эволюцию и time travel, что упрощает управление данными в динамических условиях.
Trino реализует федеративные запросы через координацию планирования и исполнения между коннекторами и источниками, обеспечивая единое SQL-API.
Эффективность федеративных запросов достигается за счет pushdown-оптимизаций, фильтров на уровне источников, оптимальной стратегии объединения и использования статистик.
Безопасность, политика доступа и аудит должны быть встроены в архитектуру на всех уровнях: от коннекторов до Iceberg-таблиц и координации запросов.
Миграция к Iceberg требует поэтапного подхода, тестирования совместимости, контроля версий схем и Time Travel для аудита и восстановления.
Практические паттерны внедрения включают постепенную миграцию, единое представление данных, мониторинг и обучение команд.

FAQ

Что такое Data Lakehouse и чем он отличается от Data Lake и Data Warehouse?

Data Lakehouse — это архитектурная концепция, которая объединяет преимущества Data Lake (масштабируемость, хранение полуструктурированных данных) и Data Warehouse (консистентность, транзакции, схемы). В Lakehouse данные сохраняются в объектном хранилище, но обеспечиваются ACID-операции, управление схемами и эффективный доступ через слои форматов таблиц, таких как Iceberg. В отличие от классического Data Lake, Lakehouse поддерживает единый SQL-взаимодействие и целевые аналитические сценарии без полной миграции данных в отдельный Data Warehouse.

Как Trino реализует федеративные запросы?

Trino осуществляет федеративные запросы через координацию планирования на уровне координатора и распределения вычислений по воркерам, работающим с коннекторами к разнородным источникам. Планировщик разделяет задачу на части, которые выполняются локально на узлах, а результаты обкочиваются и сводятся в единый набор. Фильтры и проекции PUSH- DOWN применяются к источникам данных, где это возможно, что снижает объем данных, передаваемых по сети. Iceberg-коннектор обеспечивает доступ к таблицам Iceberg и их метаданным, позволяя планировщику оптимизировать чтение файлов и использовать версии таблиц.

Какие преимущества даёт Iceberg как формат таблиц?

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

Какие ограничения и риски связаны с федеративными запросами?

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

Как организована архитектура планирования и выполнения в Trino?

Архитектура включает координатор, который принимает входной SQL-запрос, формирует логический план и распределяет задачи по воркерам. Воркеры читают данные через коннекторы и выполняют вычисления, возвращая частичные результаты координатору, который объединяет их в итоговый ответ. Планировщик учитывает фильтры, статистику и распределение данных, оптимизируя план выполнения и минимизируя сетевой tráfego.

Как Iceberg обеспечивает транзакции и версионирование?

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

Какие паттерны интеграции с Iceberg в Trino наиболее эффективны?

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

Как организовать безопасность и доступ к данным в федеративной среде?

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

Какие этапы миграции к Iceberg и к Lakehouse-подходу являются приоритетными?

Приоритеты включают: (1) аудит текущих источников данных и архитектуры; (2) проектирование целевых Iceberg-таблиц и план миграции; (3) выбор пилотного набора таблиц для перехода и тестирования совместимости; (4) внедрение CI/CD для коннекторов и схем; (5) мониторинг производительности и корректности результатов; (6) постепенная миграция оставшихся источников и функций.

В чем заключаются различия между версиями Iceberg и как это влияет на совместимость?

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

Следующая статья →

Терминология и ключевые концепты федеративных запросов