🏠Trino + Apache Iceberg — стандарт современной Data Lakehouse архитектуры (Ч. 1) С развитием аналитической архитектуры крупные компании перестают укладываться в модель «одна большая СУБД на всё» (Greenplum, Oracle, Teradata). По мере зрелости появляются доменные команды, новые источники данных, стриминг, ML-пайплайны, разные типы нагрузок — и архитектура естественным образом начинает распределяться. Часть данных хранится в S3, часть — в CH, часть — в постгре, что-то приходит через Kafka, где-то до сих пор живёт Hive или старый DWH. Всё это — нормальная эволюция сложной системы. Проблема в другом: бизнесу по-прежнему нужен единый SQL-доступ ко всем данным, дешёвое масштабируемое хранение, контроль над инфраструктурой и отсутствие жёсткой привязки к одному вендору или облаку. И вот в этот момент модель «центральная СУБД» перестаёт быть устойчивой. Возникает архитектурный разрыв: данные уже распределены, а инструменты доступа к ним — нет. Нужен слой, который объединит всё это без миграции в одну гигантскую систему, и при этом даст управляемость уровня DWH поверх Data Lake. И именно здесь появляется связка Trino + Apache Iceberg. Что это за связка и почему именно она❓ Trino — это распределённый SQL движок. Он не хранит данные и не является хранилищем в классическом смысле. Это слой выполнения запросов, который может ходить в разные источники (СУБД) через коннекторы и исполнять один SQL поверх разных систем одновременно. Ключевая идея Trino — federation. Один SQL может одновременно читать таблицу в S3, сделать join с CH, подтянуть данные из GP и агрегировать всё в одном запросе. Без физической миграции данных в единое DWH. Trino становится универсальным SQL-слоем компании. Apache Iceberg — это не движок, а формат таблиц для Data Lake. Он добавляет к object storage (S3 / GCS / ADLS) управляемость уровня DWH. Iceberg хранит данные в columnar-форматах (Parquet / ORC / Avro), а поверх них — слой метаданных и snapshot-модель. В чём его разница от обычного S3❓ Коротко — в управлении. Iceberg даёт: ➖ ACID-транзакции поверх S3 ➖snapshot-based commits ➖ schema evolution без поломки старых запросов ➖time travel (чтение таблицы на конкретный snapshot) ➖ manifest-файлы и metadata pruning PS архитектуру Iceberg'а разберем в следующем посте подробнее. Фактически Iceberg превращает папку с файлами в полноценную аналитическую таблицу. Почему именно они в связке❓ Iceberg отвечает за хранение, консистентность и метаданные. Trino отвечает за вычисления и доступ. Iceberg гарантирует, что таблица атомарна и согласована. Trino умеет эффективно читать manifest-файлы, отсекать лишние файлы на этапе планирования, делать file pruning и выполнять запросы распределённо. Это архитектурно совместимые компоненты. Если упростить архитектуру: Object Storage → Iceberg (табличный слой) → Trino (SQL-слой) → BI / аналитика / ML ❤️‍🔥 Подписывайтесь и поддержите канал бустом ↗️ Менторю и помогаю выйти на оффер ❓ Уже работаете с Trino / Iceberg или пока на классическом DWH? @data_driven_bogdan