Apache Iceberg и lakehouse

В этой главе рассматриваются

• Что такое табличный формат Apache Iceberg?
• Преимущества Apache Iceberg
• Компоненты data lakehouse на основе Apache Iceberg

Apache Iceberg - развиваемый сообществом табличный формат, который определяет, как большие аналитические наборы данных организуются, версионируются и становятся доступны на data lake. Он не меняет то, как данные хранятся на уровне файлов. Вместо этого он добавляет поверх файлов, обычно хранящихся в формате Apache Parquet, стандартный слой метаданных, благодаря которому наборы файлов можно рассматривать как цельные реляционные таблицы, оставляя их при этом в дешёвом объектном хранилище. В этой главе мы разберём архитектуру и ценность Apache Iceberg как открытого табличного формата для data lakehouse.

2.1 Что означает, что Iceberg - это табличный формат?

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

Iceberg определяет свою табличную абстракцию независимо от какого-либо конкретного движка исполнения. Это значит, что вы можете обращаться к одному и тому же набору данных из широкого круга инструментов, включая Dremio, Spark, Flink, Trino, Snowflake, Qlik и графовые движки вроде PuppyGraph. Имея общее представление о структуре таблицы и метаданных, команды могут оставаться со своими привычными инструментами, работая с одними и теми же данными.

2.2 Зачем нужен табличный формат

По своей сути data lake - это набор файлов данных, хранящихся в распределённой системе, обычно в объектном хранилище вроде Amazon S3, Azure Blob Storage или Google Cloud Storage. Файлы часто пишутся в поколоночных форматах, таких как Apache Parquet или ORC, но распространены и построчные форматы, например CSV. Эти файловые форматы отлично подходят для хранения и сканирования данных, но они не определяют таблицы так, как это делает реляционная система.

Файловые форматы описывают, как записи хранятся внутри файла, но не определяют наборы данных, охватывающие множество файлов. В результате движки запросов не могут рассматривать многофайловый набор данных как единую версионируемую таблицу с транзакционными гарантиями, эволюцией схемы или согласованными снимками. Системы вроде Apache Hive пытались закрыть этот пробел табличной абстракцией на основе Hive Metastore, который отслеживал схемы, партиции и расположение файлов. Такой подход давал SQL-доступ к файлам, но обеспечивал ограниченные транзакционные гарантии и не масштабировался при управлении метаданными по мере роста наборов данных.

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

Оптимизация производительности тоже ограничена. Без централизованных метаданных, ориентированных на запросы, движки часто вынуждены полагаться на перечисление содержимого каталогов и осмотр отдельных файлов, чтобы найти данные. Из-за этого сложнее отсекать файлы при планировании запроса. Эти проблемы типичны для файловых data lake и не связаны конкретно с Parquet, ORC или CSV. Именно поэтому современные табличные форматы - Apache Iceberg, Delta Lake и Apache Hudi - сегодня необходимы. Они превращают наборы файлов в надёжные, высокопроизводительные и хорошо управляемые аналитические таблицы.

Как показано на рис. 2.2, таблица lakehouse состоит из файлов данных, хранящих сам набор данных, и файлов метаданных, которые помогают движкам запросов сканировать данные эффективнее.

2.3 Как Apache Iceberg управляет метаданными

Одно из главных нововведений Apache Iceberg - способ организации метаданных, помогающий сохранять быстроту и эффективность lakehouse. Но что такое метаданные и почему они так важны в data lakehouse?

Представьте большую кухню, полную ящиков и шкафчиков. Если вам нужна ложка, вы можете перебирать ящик за ящиком, пока не найдёте её, но это займёт время. А теперь вообразите планшет на стене, на котором указано, где именно что лежит. Вместо того чтобы всё перерывать, вы сверяетесь с планшетом и идёте прямо к нужному месту. Этот планшет и есть метаданные: структурированный указатель, помогающий эффективно находить и извлекать информацию.

В традиционных data lake движкам запросов часто приходится «обыскивать всю кухню», сканируя тысячи и даже миллионы файлов в поисках нужных записей. Партиционирование помогает, но движки всё равно сильно полагаются на перечисление каталогов и осмотр отдельных файлов, чтобы понять, что читать. Iceberg меняет эту модель за счёт структурированной многоуровневой системы метаданных, которая работает как хорошо организованный планшет, направляя запросы прямо к нужным файлам.

Вместо того чтобы держать всё в одной монолитной структуре метаданных, Iceberg организует метаданные таблицы по слоям. Например, он отделяет метаданные уровня таблицы от метаданных уровня файлов. Каждый слой играет свою роль в описании структуры и содержимого таблицы, как показано на рис. 2.3. Каталог отслеживает эти слои метаданных и даёт движкам запросов стабильную точку входа, чтобы те могли быстро находить определения таблиц и решать, какие файлы данных сканировать.

Такие послойные метаданные позволяют движкам запросов отсекать данные на этапе планирования, а не во время выполнения. Они также поддерживают эволюцию схемы и масштабируются на очень большие таблицы без централизованных узких мест. В результате Iceberg делает аналитические запросы быстрее и надёжнее и стал ключевым элементом современного data lakehouse.

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

• metadata.json (метаданные уровня таблицы)
• Отслеживает версии таблицы (снимки)
• Хранит определения схемы и стратегии партиционирования
• Позволяет движкам запросов понимать структуру таблицы
• Обеспечивает такие возможности, как эволюция схемы, путешествия во времени и согласованность данных
• Списки манифестов (метаданные уровня снимка)
• Представляют один снимок таблицы
• Перечисляют группы файлов (манифесты) и сводную статистику, помогающую сократить лишние сканирования файлов
• Манифесты (метаданные уровня файлов)
• Перечисляют отдельные файлы Parquet внутри набора данных
• Хранят расположение файлов и статистику, помогая движкам запросов отфильтровать ненужные данные до сканирования

Организуя метаданные таким образом, Iceberg позволяет движкам запросов пропускать ненужные файлы при выполнении запросов, повышая производительность без сложных систем индексирования. Например, если запросу нужны данные только за январь 2024 года, Iceberg может по статистике из списка манифестов пропустить ненужные партиции. Затем файлы манифестов позволяют отфильтровать отдельные файлы Parquet, не соответствующие условиям запроса, ещё до чтения данных. Такое интеллектуальное отсечение существенно сокращает объём сканируемых данных, повышая производительность и снижая затраты на вычисления. На рис. 2.4 показан процесс отсечения по метаданным.

2.4 Ключевые возможности Apache Iceberg

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

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

Многие из самых характерных возможностей Iceberg связаны с доступом к данным и управлением ими на большом масштабе. Устройство на основе снимков обеспечивает путешествия во времени, так что запросы могут читать исторические версии данных таблицы для аудита, отладки или восстановления. Путешествия во времени распространяются на изменения данных, зафиксированные в снимках таблицы; они не отменяют разрушительных операций со схемой, таких как удаление столбцов. Насколько далеко можно заглянуть назад, определяют политики удержания снимков.

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

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

2.5 Apache Iceberg: открытый стандарт

Apache Iceberg не контролируется одним поставщиком - и это одна из ключевых причин, по которым он стал базовой технологией современных архитектур данных. Подобно таким стандартам, как TCP, REST или Kubernetes, Iceberg задаёт общий контракт, который независимые системы могут реализовать, не передавая контроль какой-либо одной платформе. Эта нейтральность помогает организациям строить долгоживущие архитектуры данных, где табличный формат остаётся стабильным, даже когда меняются инструменты, движки и поставщики.

Iceberg - проект верхнего уровня Apache Software Foundation, в который вносят вклад Netflix, Apple, Dremio, Snowflake, AWS, Databricks и многие другие. Ни одна компания не задаёт дорожную карту или направление проекта единолично. Вместо этого Iceberg формируется широким сообществом пользователей и поставщиков с разнообразными потребностями. Это помогает формату оставаться совместимым, масштабируемым и полезным для множества сценариев и сред развёртывания.

Благодаря столь широкой поддержке отрасли он глубоко интегрирован во множество инструментов и движков, включая следующие:

• Dremio - федеративный SQL, а также нативное ускорение запросов и рефлексии для быстрой работы BI поверх таблиц Iceberg
• AWS - крупный облачный поставщик с растущим числом интеграций с Apache Iceberg
• PuppyGraph - выполняет графовые запросы к наборам данных Iceberg
• Apache Spark и Flink - крупномасштабные ETL- и потоковые нагрузки
• Kafka Connect - потоковый приём данных в таблицы Iceberg
• Qlik Talend Cloud - полнофункциональное решение для интеграции данных и управления ими с использованием Iceberg

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

2.6 Преимущества Apache Iceberg

Apache Iceberg способен повысить производительность и гибкость, но чтобы раскрыть его потенциал полностью, нужна аккуратная интеграция с движками запросов и системами каталогов. Организациям также приходится переосмыслить традиционные практики работы с data lake, потому что Iceberg меняет способ работы с данными озера: от работы с сырыми файлами (набор данных о продажах - вот эта папка с файлами Parquet) к отношению к данным как к управляемым таблицам (мои данные о продажах - вот эта таблица, которую я вижу в каталоге). Рассмотрим ключевые преимущества Apache Iceberg и то, как они решают давние проблемы управления данными.

2.6.1 ACID-транзакции

В data lake, когда несколько задач пишут в один набор данных без транзакционных гарантий, можно получить конфликтующие обновления, дублирующиеся записи и недостоверные результаты запросов. Без координации команды часто прибегают к сложным обходным путям: пишут временные файлы, используют внешние механизмы блокировок или расставляют задачи по расписанию, чтобы уменьшить число конфликтов. Такие решения добавляют эксплуатационных издержек и всё равно не предотвращают несогласованность.

Apache Iceberg решает эту проблему, предоставляя полные гарантии ACID, благодаря которым изменения в наборе данных применяются контролируемо и предсказуемо. ACID расшифровывается как атомарность, согласованность, изолированность и долговечность, и каждое из этих свойств играет свою роль в поддержании корректности при параллельном доступе:

• Атомарность означает, что каждая операция записи фиксируется по принципу «всё или ничего», не допуская частичных обновлений, которые оставили бы таблицу в неопределённом состоянии.
• Согласованность гарантирует, что каждое зафиксированное изменение переводит набор данных из одного корректного состояния в другое, сохраняя заданные инварианты (например, правила схемы и ограничения таблицы) во всех инструментах и фреймворках обработки.
• Изолированность обеспечивает, что параллельные писатели видят изменения друг друга и учитывают их благодаря чётко определённому порядку и обнаружению конфликтов. Если запись опирается на устаревшее представление таблицы и конфликтует с другим зафиксированным изменением, она отклоняется, а не перезаписывает данные молча.
• Долговечность означает, что после фиксации изменение остаётся записанным и может быть восстановлено даже после сбоев.

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

2.6.2 Как эволюционируют таблицы

В традиционных data lake менять схемы и партиции громоздко: зачастую приходится перезагружать или переписывать наборы данных даже ради простого структурного изменения. Такая жёсткость подталкивает организации принимать проектные решения заранее, а они могут не выдержать роста по мере изменения потребностей бизнеса. Со временем эти ограничения порождают неэффективность, дублирование данных и сложные обходные пути, замедляющие аналитические и инженерные процессы.

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

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

2.6.3 Путешествия во времени и запросы на основе снимков

В традиционных data lake, если данные перезаписаны, они потеряны. Нет простого способа восстановить предыдущие версии для исторического анализа или отменить ошибки. Отсутствие контроля версий усложняет аварийное восстановление и исторический анализ, часто вынуждая команды создавать дублирующие наборы данных или полагаться на ручные резервные копии. Без структурированного способа отслеживать изменения даже небольшая ошибка при приёме данных может обернуться необратимой потерей данных или испорченными записями.

Apache Iceberg меняет это благодаря путешествиям во времени. Они позволяют запрашивать более старые версии таблицы ровно в том виде, в каком они существовали в определённый момент. Если приняты плохие или неполные данные, вы можете откатиться к предыдущему снимку и восстановить набор данных без сложных процедур восстановления. Iceberg также поддерживает версионированную аналитику, поэтому можно анализировать исторические тренды, не дублируя данные и не поддерживая множество копий одного набора. Это помогает в управлении данными, соблюдении требований и отладке, облегчая восстановление после человеческих или системных ошибок. На рис. 2.5 показано, как работают путешествия во времени: список файлов данных, с которым идёт работа, зависит от того, какой снимок сканируется.

2.6.4 Скрытое партиционирование для сокращения случайных полных сканирований таблиц

Партиционирование способно ускорить запросы, но традиционные таблицы в стиле Hive требуют вручную указывать столбцы партиционирования в запросах. Если в предложении WHERE нет фильтра по партиции, движкам запросов приходится сканировать большие объёмы ненужных данных, что замедляет запросы и расходует ресурсы впустую. Такой ручной подход усложняет жизнь пользователям и повышает риск неоптимальных запросов, не использующих отсечение партиций.

Apache Iceberg снимает это бремя за счёт скрытого партиционирования. Логика партиционирования задаётся в метаданных таблицы, а не выставляется наружу в виде физических столбцов или имён каталогов. Вам не нужно самим создавать столбцы партиционирования и обращаться к ним в запросах: Iceberg применяет преобразования партиционирования на этапе планирования запроса.

Например, таблица может хранить исходный столбец event_timestamp типа TIMESTAMP, при этом сама таблица партиционируется преобразованием вроде hour(event_timestamp) или day(event_timestamp). В схему не добавляются дополнительные столбцы партиционирования, и никакая структура каталогов это партиционирование не отражает. Когда запрос фильтрует по event_timestamp, Iceberg по метаданным определяет подходящие партиции и соответственно отсекает файлы - даже если в запросе ни разу не упоминается ключ партиционирования.

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

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

2.6.5 Экономичность и производительность запросов

Организации нередко держат несколько копий одних и тех же данных в data lake, хранилищах данных и витринах данных ниже по потоку (курируемых подмножествах данных, созданных для конкретных команд или отчётных задач). Это может упростить потребление, но повышает эксплуатационные затраты и сложность. Каждая дополнительная копия требует отдельного приёма, преобразования, хранения и постоянного сопровождения.

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

Распространённый паттерн - загрузить сырые данные в озеро, прогнать их через одну или несколько стадий ETL, а затем загрузить в хранилище или витрину данных для аналитики. Каждый шаг по отдельности может быть оправдан, но вместе они складываются в затраты, которые трудно нести на масштабе. Со временем организации начинают тратить очень много просто на то, чтобы поддерживать данные синхронизированными между системами, вместо создания новой аналитической ценности.

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

Iceberg упрощает ETL-процессы, позволяя принимать и потоковые, и пакетные данные в одну таблицу, так что не приходится перегонять данные между разными средами. Когда вы перемещаете меньше данных, создаёте меньше копий и оптимизируете запросы, высокопроизводительная аналитика обходится в разы дешевле. Например, компания Insider сократила свои затраты на S3 на 90% с помощью Apache Iceberg (см. «Apache Iceberg Reduced Our S3 Cost by 90%» [Medium, 28 сентября 2022 г.], https://mng.bz/PwQ2).

2.7 Компоненты lakehouse на Apache Iceberg

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

Традиционные монолитные хранилища данных зачастую запирают организации в экосистеме одного поставщика. Модульная же архитектура lakehouse позволяет бизнесу

• масштабировать каждый компонент независимо в соответствии с меняющимися потребностями;
• снижать привязку к поставщику за счёт открытых стандартов, таких как Apache Iceberg;
• оптимизировать производительность и стоимость, подбирая подходящие инструменты для приёма данных, федерации и потребления.

Разделив lakehouse на пять ключевых компонентов, вы сможете подобрать лучшие инструменты под свои задачи и избежать привязки к поставщику:

• Слой хранения - экономично хранит данные в объектном хранилище
• Слой приёма данных - передаёт данные в таблицы Iceberg потоково или пакетами
• Слой каталога - отслеживает все метаданные Iceberg и управляет ими
• Слой федерации - моделирует и ускоряет данные для аналитики
• Слой потребления - обеспечивает работу BI, ИИ и приложений реального времени

Разберём пять ключевых компонентов lakehouse на Apache Iceberg и то, как они сочетаются, как показано на рис. 2.6. В части 2 этой книги мы подробно рассмотрим каждый компонент.

2.7.1 Слой хранения: фундамент вашего lakehouse

Слой хранения содержит ваши сырые данные и метаданные. Обычно это распределённое объектное хранилище или файловая система, спроектированные для масштабируемости, надёжности и экономичности.

Где хранятся данные:

• Облако - Amazon S3, Azure Blob Storage, Google Cloud Storage
• Локальная инфраструктура - HDFS, MinIO, Ceph
• Гибрид - сочетание обоих вариантов, когда этого требуют бизнес-требования

Что хранится:

• Файлы данных - как правило, Apache Parquet (может быть ORC или Avro), оптимизированные для аналитики
• Файлы метаданных - метаданные таблиц Iceberg, манифесты и снимки

Почему это важно

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

2.7.2 Слой приёма данных: наполнение таблиц Iceberg

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

Пакетный приём:

• Apache Spark - принимает крупномасштабные ETL-нагрузки в Iceberg
• Fivetran - управляет приёмом данных для ETL-нагрузок

Потоковый приём:

• Apache Flink - выполняет обработку данных в реальном времени с записью в Iceberg
• Kafka Connect - обеспечивает потоковый приём из топиков Kafka в таблицы Iceberg
• Estuary - управляемая платформа для приёма данных в реальном времени и пакетами
• Qlik Talend Cloud - поддерживает пакетные и потоковые нагрузки

Это лишь несколько вариантов. Гораздо больше вы увидите в главе 6 второй части.

Почему это важно

Гибкий слой приёма данных помогает эффективно записывать в таблицы Iceberg и пакетные, и потоковые данные. Благодаря модульности вы можете поддерживать данные более свежими и снижать задержки для сценариев аналитики и ИИ.

2.7.3 Слой каталога: точка входа в ваш lakehouse

Каталог lakehouse делает Iceberg пригодным для запросов и управляемым на большом масштабе. Он выступает интерфейсом между слоем хранения и движками запросов, отслеживая таблицы и расположение их метаданных.

Варианты каталогов lakehouse:

• Hive Metastore - поддержка по наследству, но для Iceberg он не идеален
• AWS Glue Data Catalog - облачный вариант для управления таблицами Iceberg
• Project Nessie - версионируемый каталог в духе Git, обеспечивающий путешествия во времени и подход «данные как код»
• Apache Polaris - каталог lakehouse с открытым исходным кодом и развитыми возможностями ролевого управления доступом (RBAC)
• Apache Gravitino - геораспределённый каталог lakehouse
• Lakekeeper - каталог Iceberg, созданный для обеспечения соблюдения политик управления данными
• Iceberg REST Catalog - открытый стандарт для каталогов, совместимых с Iceberg

Почему это важно

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

• атомарные обновления таблиц, не мешающие пользователям;
• совместимость между инструментами, благодаря которой Dremio, Spark, Flink, Trino, Snowflake и другие движки видят одни и те же таблицы;
• переносимые правила управления доступом между вашими инструментами.

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

2.7.4 Слой федерации: моделирование и ускорение данных

Слой федерации - это место, где сырые данные моделируются, обогащаются и оптимизируются для аналитики, ИИ и отчётности. Здесь команды определяют бизнес-логику, объединяют данные из разных источников и оптимизируют производительность запросов. Обсудим, какие возможности делают слои федерации особенно полезными в работе с данными.

Ключевые возможности:

• Семантический слой - задаёт согласованные метрики в масштабе организации
• Федеративные движки запросов - позволяют выполнять запросы к Iceberg и внешним базам данных
• Ускорение запросов - ускоряет аналитику без дублирования данных

Примеры инструментов:

• Dremio - объединяет Iceberg, базы данных и хранилища со встроенным семантическим слоем и механизмом ускорения Reflections.
• Trino - предоставляет объединение данных из множества источников на основе SQL с открытым исходным кодом. Может потребовать внешнего семантического слоя и средств ускорения.

Почему это важно

Слой федерации не даёт таблицам Iceberg оказаться в изоляции. У организаций данные обычно разбросаны по разным местам и форматам:

• реляционные базы данных (PostgreSQL, MySQL, SQL Server);
• облачные хранилища данных (Snowflake, Redshift, BigQuery);
• другие форматы lakehouse (Delta Lake, Apache Hudi).

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

2.7.5 Слой потребления: создание бизнес-ценности

Данные ценны ровно настолько, насколько ценны результаты, которые они делают возможными. Слой потребления - это место, где данные используются для аналитики, ИИ и операционных процессов.

Сценарии использования:

• Бизнес-аналитика (BI) - питает дашборды и отчётность
• ИИ и машинное обучение (ML) - обучение моделей и работа ИИ-приложений и ИИ-агентов
• Встроенная аналитика - доставка инсайтов прямо в бизнес-приложения
• API данных и приложения - построение клиентских приложений поверх данных Iceberg

Примеры инструментов:

• BI и дашборды - Tableau, Power BI, Looker, Preset (Superset)
• ИИ и ML - Databricks, Sagemaker, Bedrock, Hugging Face, Jupyter, LangChain
• API данных - GraphQL, REST API для интеграции с приложениями

Почему это важно

Lakehouse модульны, а Iceberg - открытый стандарт, поэтому ваши данные остаются доступными разным инструментам без дублирования ETL. Это избавляет от

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

С lakehouse на Iceberg вы можете определить продукты данных один раз и использовать их везде. Это даёт всему бизнесу единый источник истины, которому можно доверять.

В следующей главе мы перейдём к практике, чтобы вы увидели data lakehouse в действии. Затем, в части 2 этой книги, мы изучим пять компонентов для проектирования вашего lakehouse на Apache Iceberg. Цель - дать вам лучше почувствовать, что такое lakehouse, прежде чем мы погрузимся в проектную работу.

Итоги

• Apache Iceberg - современный табличный формат, обеспечивающий высокопроизводительную аналитику, эволюцию схемы, ACID-транзакции и масштабируемость метаданных. Он превращает data lake в структурированные, изменяемые и управляемые платформы хранения.
• Iceberg решает ключевые болевые точки OLTP-баз данных, корпоративных хранилищ данных и data lake на Hadoop: высокую стоимость, жёсткие схемы, медленные запросы и несогласованное управление данными.
• Благодаря таким возможностям, как путешествия во времени, эволюция партиционирования и скрытое партиционирование, Iceberg снижает затраты на хранение, упрощает ETL и оптимизирует вычислительные ресурсы, делая аналитику данных эффективнее.
• Iceberg интегрируется с движками запросов, такими как Trino, Dremio и Snowflake, фреймворками обработки, такими как Spark и Flink, и открытыми каталогами lakehouse, такими как Nessie, Polaris и Gravitino, обеспечивая модульные и независимые от поставщика архитектуры.
• Lakehouse на Apache Iceberg состоит из пяти ключевых компонентов: хранения, приёма данных, каталога, федерации и потребления.