В этой главе рассматриваются
- Что такое data lakehouse и чем он отличается от традиционных архитектур данных
- Как Apache Iceberg формирует парадигму lakehouse
- Когда и зачем внедрять lakehouse на Apache Iceberg
Архитектура данных развивалась не столько за счёт инноваций ради инноваций, сколько под давлением постоянных неудач. Организации давно бьются над тем, чтобы обеспечить аналитику, которая была бы быстрой, доступной по цене и заслуживающей доверия на большом масштабе. Системы с хорошей производительностью, как правило, оказывались дорогими и негибкими. Гибкие и дешёвые системы часто были медленными, хрупкими и плохо поддающимися управлению. Каждое новое поколение архитектур обещало устранить эти компромиссы, но привносило новые технические и бизнес-ограничения, сужавшие возможности использования данных.
Хранилища данных давали производительность и управляемость, но запирали данные за высокой стоимостью, проприетарными форматами и жёсткими схемами, из-за которых изменения шли медленно. Data lake снижали стоимость хранения и повышали гибкость, но жертвовали надёжностью, производительностью и согласованностью, превращая аналитику в инженерный проект. Гибридные подходы пытались навести мост, но зачастую добавляли сложность, дублирование и эксплуатационные издержки. В результате возник фрагментированный ландшафт данных, где команды тратили больше времени на перемещение, копирование и починку данных, чем на их использование. Мы увидим, как эти недостатки привели к новым способам определять наборы данных на data lake и управлять ими - подходам, которые объединяют ключевые преимущества хранилищ данных и data lake, порождая data lakehouse.
Один из новейших подходов - Apache Iceberg. Это открытый табличный формат, позволяющий работать с группами файлов в распределённых системах хранения так же, как с традиционными таблицами баз данных, благодаря чему data lake действительно может стать центром вашей аналитической платформы. С Iceberg множество инструментов может эффективно обращаться к аналитическим наборам данных, хранящимся в вашем data lake. Такой открытый доступ облегчает совместную работу команд и сокращает лишнюю работу по извлечению, преобразованию и загрузке (ETL) и репликацию данных, поскольку сохраняется единственная каноническая копия данных.
Lakehouse на Apache Iceberg - это модульная, масштабируемая и экономичная архитектура, которая объединяет лучшие стороны data lake и хранилищ данных, оставаясь при этом открытой и гибкой. Почему такие компании, как Netflix, Apple, Dremio, AWS, Snowflake и Databricks, используют Iceberg и строят вокруг него инструменты? Одна из причин в том, что Iceberg предлагает развиваемый сообществом стандартный формат хранения аналитических наборов данных. Он работает с широким кругом инструментов, при этом обеспечивая гарантии ACID (атомарность, согласованность, изолированность, долговечность) и производительность, которой вы ждёте от проприетарных систем хранилищ данных.
Эта книга покажет, как работает Iceberg и как принимать правильные архитектурные решения для lakehouse на Iceberg под ваши сценарии использования. Мы рассмотрим data lakehouse в целом и Apache Iceberg в частности, с практическими упражнениями, которые можно выполнить локально. Вы загрузите данные из баз данных в свой lakehouse и построите поверх него дашборды бизнес-аналитики. Попутно я помогу вам оценить потребности вашей платформы данных и изучить экосистему вокруг каждого компонента, чтобы вы понимали, из чего выбирать при построении идеальной платформы.
Начнём с того мира, для которого создавался Apache Iceberg: с проблем традиционных архитектур и того, как в ответ на них появился data lakehouse. Затем посмотрим, как Iceberg развивает lakehouse дальше, давая масштабируемое, высокопроизводительное и открытое решение для современных архитектур данных.
1.1 Эволюция от базы данных к data lakehouse
Данные не существуют в вакууме. Они всегда в движении: питают приложения, аналитику и принятие решений с помощью ИИ. Годами организации выстраивали слои инфраструктуры, чтобы справляться с растущей сложностью управления данными. Data lakehouse - новейший шаг на этом пути, стремящийся сбалансировать стоимость, масштабируемость и доступность, оставаясь открытым и совместимым.
Сегодня data lakehouse - доминирующая парадигма. Чтобы понять почему, полезно разобраться в архитектурных проблемах, которые ей предшествовали. Мы проследим эволюцию от баз данных оперативной обработки транзакций (OLTP) к системам, оптимизированным для аналитики, - хранилищам данных, data lake и далее, - чтобы объяснить, почему возник lakehouse и как он разрешает давние компромиссы в управлении данными. На рис. 1.1 показан этот путь от хранилищ данных к data lakehouse; мы будем возвращаться к нему на протяжении всего раздела.
1.2 Подъём хранилищ данных
На заре большинство данных находилось в базах OLTP - традиционных реляционных системах, созданных для взаимодействия с приложениями в реальном времени. Базы данных вроде Oracle, Db2, PostgreSQL, MySQL, NoSQL-хранилищ и SQL Server были оптимизированы для транзакционных операций: вставки, обновления и извлечения отдельных записей. Такие системы обычно применяют построчную раскладку, храня рядом все поля одной записи, что делает их эффективными для точечного поиска и частых мелких обновлений.
Проблемы начались, когда организации взялись анализировать исторические данные, чтобы строить сводные отчёты, аналитические дашборды, агрегаты и сложные соединения на длинных временных интервалах. Такие аналитические запросы сканируют множество строк, но затрагивают лишь несколько столбцов, поэтому построчные системы тратят время на чтение целых строк, хотя большинство полей не нужны. Поколоночная раскладка держит значения одного столбца вместе, поэтому аналитические движки читают и обрабатывают только те данные, которые нужны запросу. Это несоответствие между устройством хранения OLTP и характером аналитического доступа привело к тому, что транзакционные базы данных стали задыхаться по мере роста объёмов данных и аналитических запросов.
Причины были очевидны: OLTP-системы рассчитаны на быстрые транзакционные запросы, а не на сканирование и агрегацию миллионов и даже миллиардов строк. Индексирование и партиционирование помогают оптимизировать некоторые запросы, но аналитические нагрузки всё равно создают серьёзное давление на операционные базы данных, часто замедляя обработку транзакций. Эти системы не создавались для хранения и извлечения данных в огромных масштабах, из-за чего было трудно удерживать исторические данные для долгосрочного анализа.
Так появилось корпоративное хранилище данных (enterprise data warehouse, EDW) - выделенная аналитическая система. Продукты вроде Teradata, IBM Netezza и Oracle Exadata позволяли компаниям извлекать данные из OLTP-систем, преобразовывать их в оптимизированные схемы и загружать в централизованные хранилища для аналитических нагрузок - системы так называемой оперативной аналитической обработки (online analytical processing, OLAP). Подвох - в стоимости и негибкости.
1.3 Переход к облачным хранилищам данных
Традиционные корпоративные хранилища данных были дороги в эксплуатации и трудно масштабировались, поскольку хранение и вычисления были жёстко связаны. Чтобы увеличить пропускную способность по запросам или хранить больше исторических данных, организациям приходилось заранее закупать и разворачивать дополнительное локальное оборудование, зачастую за месяцы. Такая жёсткость делала затраты предсказуемыми, но негибкими, вынуждая закладывать избыточную инфраструктуру под пиковые нагрузки, а большую часть времени держать ресурсы недозагруженными. ETL-конвейеры также требовали времени и денег на сопровождение, ведь данные нужно было преобразовать и загрузить в специфические для хранилища схемы, прежде чем к ним можно было обращаться с запросами.
Облачные хранилища данных, такие как Snowflake, Google BigQuery и Amazon Redshift, принесли более гибкую модель затрат. Поскольку вычисления и хранение разделены, организации могут масштабировать обработку запросов независимо от объёма хранимых данных и платить только за то, что используют. Это упростило эксперименты, снизило первоначальные капитальные затраты и уменьшило эксплуатационную нагрузку по управлению инфраструктурой. Аналитика самообслуживания также стала доступнее: командам больше не требовалось подбирать размер кластеров или заниматься оборудованием, чтобы запускать аналитические задачи.
Даже с этими улучшениями облачные хранилища данных сохранили ряд фундаментальных ограничений. Данные по-прежнему нужно было загрузить в хранилище, прежде чем анализировать, что неэффективно на больших масштабах. Организации регулярно копировали одни и те же данные из операционных систем в несколько хранилищ, увеличивая задержки, разрастание дублированного хранилища и усложняя конвейеры данных. Внутри хранилища данные лежали в проприетарных форматах сериализации, со своими стратегиями индексирования и семантикой запросов, различающимися у разных поставщиков. Из-за этого данные и приложения было трудно перенести, что фактически привязывало организации к одной платформе. По мере роста объёмов данных и числа сценариев бизнес начал сомневаться, что жёстко связанные проприетарные аналитические системы - облачные или нет - подходят как долгосрочный фундамент для крупномасштабной аналитики данных.
1.4 Data lake и эпоха Hadoop
Хранилища данных хорошо справлялись с аналитикой структурированных данных, но организациям всё ещё нужен был способ хранить и обрабатывать быстро растущие объёмы полуструктурированных и неструктурированных данных: событий кликстрима, логов приложений, показаний IoT-датчиков и данных из социальных сетей. Этот пробел привёл к появлению data lake - архитектурного паттерна для хранения больших наборов файлов в распределённом хранилище и выполнения аналитики непосредственно над ними.
Первые data lake появились в середине 2000-х и строились на Hadoop Distributed File System (HDFS) и модели программирования MapReduce. В отличие от современных облачных систем, Hadoop не разделял хранение и вычисления, а намеренно размещал их совместно. Держать вычисления рядом с данными на массовом оборудовании - значит снизить сетевые издержки и сделать крупномасштабную пакетную обработку осуществимой за долю стоимости корпоративных хранилищ данных. Открытая экосистема Hadoop в сочетании с недорогим оборудованием также позволила командам хранить куда больше сырых данных, чем это было экономически возможно в традиционных хранилищах.
Но у data lake на базе Hadoop были компромиссы, снижавшие их эффективность для аналитики. MapReduce отлично справлялся с большими пакетными задачами, но не с интерактивными или итеративными запросами. Ранние SQL-слои, такие как Hive, транслировали запросы в несколько стадий MapReduce, часто записывая промежуточные результаты на диск, что увеличивало задержку и потребление ресурсов. Более поздние движки, такие как Impala и Spark, существенно улучшили производительность, сократив лишний дисковый ввод-вывод и уместив выполнение запроса в меньшее число стадий. Но базовая модель всё равно требовала тщательной настройки и глубокой инженерной экспертизы.
По мере роста data lake проявились новые проблемы. Поскольку данные хранились в слабо организованных файлах, было трудно обеспечивать соблюдение схем, обрабатывать их изменения и поддерживать согласованное представление о данных между командами. Координация между задачами и инструментами по большей части оставалась внешней по отношению к слою хранения, что повышало риск несогласованных или конфликтующих наборов данных. Со временем это привело к так называемым «болотам данных», где данных было много, но запрашивать их, управлять ими и доверять им было сложно.
Одновременно свои компромиссы принесли и облачные хранилища данных. Они разделили хранение и вычисления, но опирались на проприетарные форматы и движки исполнения. В итоге организации сопровождали параллельные системы: data lake на Hadoop для сырой крупномасштабной обработки и облачные хранилища для аналитики и бизнес-аналитики (BI). Данные зачастую приходилось переформатировать или перестраивать под модель исполнения каждой системы, что усложняло архитектуру. Не хватало подхода, который сочетал бы масштабируемость и открытость data lake с надёжностью, производительностью и удобством хранилищ данных, не вынуждая организации выбирать один набор компромиссов вместо другого.
1.5 Apache Iceberg: наделение data lake возможностями хранилищ данных
Netflix разработала Apache Iceberg, чтобы устранить ограничения масштабируемости и корректности, возникающие при управлении большими аналитическими таблицами в data lake. Инженеры Netflix активно опирались на Apache Hive; на меньших масштабах он работал вполне сносно, но начинал буксовать по мере роста числа таблиц, партиций и параллельных нагрузок.
Одним из главных ограничений была масштабируемость метаданных. Hive хранил метаданные о партициях и таблицах в Hive Metastore, обычно поверх реляционной базы данных вроде PostgreSQL или MySQL. На малых масштабах это работало хорошо, но было ненадёжно для организаций, управляющих таблицами с сотнями тысяч или миллионами партиций. По мере роста таблиц и числа использующих их команд операции с метаданными превращались в узкое место.
Другим серьёзным ограничением было управление схемой. В Hive схемы таблиц были жёстко связаны с физической раскладкой файлов. Добавление столбцов обычно обходилось дёшево, но другие типичные операции - переименование или удаление столбцов - были небезопасны или неосуществимы без переписывания данных. Из-за этой жёсткой связи было трудно безопасно развивать долгоживущие наборы данных вслед за изменением бизнес-потребностей.
Эффективность запросов также зависела от того, когда происходило отсечение лишних данных. Hive использовал перечисление содержимого каталогов и чтение футеров файлов, чтобы находить партиции и применять фильтры. В среде HDFS это было относительно дёшево, а вот в облачных объектных хранилищах - значительно дороже и медленнее. Хотя Hive умел отсекать данные, он часто делал это на поздних этапах выполнения запроса, а не при планировании, что на масштабе увеличивало и задержку, и потребление ресурсов.
Apache Iceberg решает эти проблемы с помощью масштабируемого табличного формата и чётко определённой модели метаданных, которая отделяет логическую структуру таблицы от физической раскладки файлов. Iceberg хранит централизованные метаданные о файлах, партициях и статистике, поэтому движки запросов могут отсекать данные на этапе планирования, а не во время выполнения. В облачных средах это означает меньше обращений к листингам объектов и чтений файлов, что снижает затраты и ускоряет запросы.
Iceberg обеспечивает полные гарантии ACID для обновлений таблиц, поэтому несколько писателей и читателей могут безопасно работать с одним набором данных с чётко определённой семантикой изолированности и согласованности. Вместо внешней координации или гарантий «по мере возможности» Iceberg использует транзакции на основе снимков, чтобы параллельные операции оставались корректными.
Вместе эти возможности меняют то, как используются data lake. Apache Iceberg превращает data lake из слабо управляемого файлового хранилища в масштабируемую и надёжную аналитическую систему. Позволяя воспроизводить поведение таблиц уровня хранилища данных прямо поверх дешёвого объектного хранилища, Iceberg делает возможным использование data lake в качестве настоящего аналитического фундамента. Эту эволюцию data lake мы и называем data lakehouse.
1.6 Data lakehouse: лучшее из двух миров
Data lakehouse - следующий этап эволюции архитектуры данных, меняющий то, как организации строят аналитические системы. Вместо того чтобы привязывать команды к одной технологии или одному движку исполнения, lakehouse соединяет экономичность data lake с производительностью и удобством хранилищ данных за счёт открытых табличных форматов, таких как Apache Iceberg. Это позволяет выбирать лучший инструмент под каждый сценарий, работая при этом с общим открытым фундаментом данных. Подход lakehouse решает несколько давних проблем:
- Согласованный доступ к данным для разных команд и инструментов - вместо того чтобы каждая команда загружала и переформатировала одни и те же данные в отдельные проприетарные хранилища, организации могут один раз определить общие продукты данных и позволить разным инструментам обращаться к ним напрямую. Открытый формат Iceberg позволяет BI-инструментам, движкам запросов и фреймворкам обработки работать с одними и теми же наборами данных, снижая фрагментацию и помогая командам выбирать лучший инструмент под каждую нагрузку без потери согласованности.
- Более высокая производительность аналитики без избыточного перемещения данных - lakehouse не отменяет потребность в курируемых наборах данных, материализованных представлениях или предагрегатах, но существенно сокращает необходимость перемещать и переформатировать данные под каждую систему. С Iceberg пакетные и потоковые конвейеры могут писать в одни и те же таблицы, а инструменты ниже по потоку - читать, соединять и анализировать эти данные без дополнительных преобразований. Это упрощает ETL-процессы и снижает издержки на поддержание параллельных представлений одних и тех же данных.
- Меньше дублирования в глобальном масштабе данных - объём данных, которыми управляют организации, растёт с каждым годом: по оценкам, он превышает 150 зеттабайт, а к 2030 году прогнозы приближаются к 2000 зеттабайт. На таком масштабе копирование одних и тех же данных между множеством систем становится слишком дорогим и эксплуатационно неподъёмным. Apache Iceberg не помешает вам делать копии, но облегчает отказ от них: единый набор продуктов данных может обслуживать множество инструментов и сценариев.
Apache Iceberg обеспечивает открытый и совместимый доступ к управляемым наборам данных на дешёвом хранилище, помогая организациям выйти за рамки унаследованных архитектурных ограничений и строить масштабируемые, экономически осознанные платформы данных, готовые к работе с ИИ. В следующей главе мы подробнее рассмотрим, как работает Iceberg и почему он делает архитектуру lakehouse практичной.
Итоги
- Современные архитектуры данных развивались через череду компромиссов. Системы, оптимизированные под производительность и управляемость, были дорогими и негибкими, а оптимизированные под гибкость и стоимость часто испытывали трудности с надёжностью, согласованностью и эксплуатационной сложностью.
- Хранилища данных, data lake и гибридные подходы решали части проблемы, но привносили новые ограничения. Результатом стали фрагментированные платформы, где команды тратили значительные усилия на перемещение, копирование и переформатирование данных вместо их анализа.
- Data lakehouse возник как ответ на эти неудачи: он позволяет вести аналитику в стиле хранилищ данных поверх data lake, определяя управляемые и совместимые наборы данных вместо опоры на сырые файлы или проприетарные системы.
- Apache Iceberg - ключевой элемент, делающий архитектуру lakehouse возможной. Он вводит масштабируемый табличный формат, который отделяет логическую структуру таблицы от физического хранения, обеспечивая эволюцию схемы, путешествия во времени на основе снимков и безопасную параллельную запись.