Авторский взгляд Павла Савченко, presale-архитектора CedrusData. В материале представлен анализ концепции и ее ключевых принципов, основанный на экспертизе и практическом опыте.
В данной статье я хочу развеять сомнения относительно систем класса Lakehouse, а также расставить все точки, проанализировать принципы и сделать концептуальные заключения относительно данного тренда. В дальнейшем для простоты будем сокращать термин до «LH».
Когда я сам первый раз попробовал разобраться для себя что же такое Lakehouse, одной из первых попал на статью от Databricks 2020 года, где раскрывалась данная концепция (Databricks считается в некоторой степени основоположником данного тренда, хотя сам термин стал мелькать с 2017 года). Из подобных статей понятно только, что есть некий набор критериев, но почему именно они и какие преимущества дают — было не очевидно. Сейчас ситуация стала получше, но если пробежаться по доступным материалам (особенно в РФ), то аспекты тоже раскрыты весьма поверхностно, ключевые принципы никак не выделены, преимущества не видны. Что уже говорить, если такие материалы читает человек далёкий от понимания основ Data Lake.
Забегу немного в историю чтобы объяснить как появились данные термины. Data Lake (в подавляющем количестве случаев это был Hadoop) стал массово приходить на смену классическим СУБД и MPP-системам в 2010-2020 гг. Происходило это в связи с тем, что первые как правило плохо масштабировались, а вторые были очень дорогими решениями со своими особенностями. Еще одним фактором был бурный рост собираемых и обрабатываемых данных на предприятиях («Big Data»), вызванный удешевлением комплектующих и одновременно с осознанием дополнительной ценности, которую можно извлекать из накопленных данных. В сравнении с MPP-системами, Data Lake давал иногда кратное удешевление (обычно измеряемое в TCO на терабайт хранимых данных), но одновременно с этим создавал дополнительные трудности:
- эффективная работа только на больших объемах данных, мелкие изменения давали большой overhead;
- отсутствие удобных и привычных механизмов обновления данных (не говоря уже про транзакции и другие доступные в СУБД механизмы);
- привычный и удобный мир СУБД распался на куски — нужно было как то дружить между собой разные компоненты, изобретать как обходить трудности с обновлениями данных, придумывать как синхронизировать данные и метаданные, как делать бекапы/репликацию и т.п. — готовых механизмов как правило не было.
Но часто дешевизна вместе с гибкостью и разнообразием инструментов перевешивали все недостатки, и как итог Data Lake занял свою устойчивую нишу.
Концепция Lakehouse сформировалась на базе Data Lake и с одной стороны вокруг его недостатков, а также других лучших практик, которые опишем ниже. Аспекты LH не являются строгими, т.е. есть некоторое «скорее обязательное ядро», и есть ряд «скорее опциональных аспектов», которые могут отсутствовать в некоторых статьях (вероятно в силу собственных интересов/стратегии тех или иных вендоров). К примеру, Microsoft в своем определении LH вообще не упоминает про такой важный аспект, как ACID, ну и подобных примеров множество.
Итак, начнём с типового списка, который встречается практически во всех определениях Lakehouse. В начале пробежимся коротко по наиболее важным, и далее раскроем интересные элементы более подробно. К основным особенностям Lakehouse относят:
- Объединение Data Lake и Data Warehouse (DWH) в рамках единой платформы. Data Lake закрывает паттерны, не специфичные для DWH, в том числе обработку неструктурированных/слабоструктурированных данных, разнообразные compute-движки, ML-задачи, открытость форматов, и пр.
- Единый слой хранения под все данные (как правило, недорогое S3-подобное объектное хранилище или их совокупность).
- Открытые стандартизированные форматы хранения. Обеспечивают независимость от вендора и технологии, а также привносят дополнительные возможности, например поддержку транзакций и Time Travel.
- Поддержка транзакций (ACID).
- Отделение compute от storage (дезагрегированное хранение). Слой хранения един и отделен от вычислительных движков на уровне компонент (инфраструктуры).
- Интероперабельность для compute-движков (следствие п.3 и 5), т.е. вы можете подобрать движок под соответствующий тип рабочей нагрузки.
- Поддержка разнообразных рабочих нагрузок (следствие п.6), т.е. не только классических аналитических нагрузок DWH, но и алгоритмов data science/machine learning (в общем можно сказать что это поддержка инструментов/библиотек разработки прикладного кода с распределенным исполнением).
Следующие особенности также выделены некоторыми вендорами (не всеми), но на мой взгляд не столь существенные:
- Совместимость с BI и прямые запросы к данным. Больше определяется движком и доступным/совместимым интерфейсом к нему, а не самим Lakehouse.
- Поддержка real-time/streaming обработки данных. Аналогично, хоть и большой плюс, но это скорее вспомогательный/опциональный сценарий, но не основной. В некотором смысле следствие п.6 и 7.
- Эффективный Data Governance. Тут часто упоминают много всего: эволюция схем/данных, выделение слоя метаданных, эффективный data quality, lineage, безопасность, разнообразие поддерживаемых типов данных, и наличие механизмов для управления метаданными. По совокупности я бы отметил, что вниманию к метаданным и их управлению в LH уделяется заметно больше, чем это было в Data Lake.
Как краткий итог, можно отметить, что многие перечисленные критерии также присущи и для развитого Data Lake. Теперь разберем перечисленные аспекты более подробно.
Единый слой хранения под все данные
S3 в настоящее время уже практически стал индустриальным стандартом для как для недорогого и надежного хранения как обычных файлов, так и для построения хранилищ класса Data Lake/Lakehouse. Под единым слоем подразумевается именно единая технология (S3, HDFS, облачные хранилища и т.п.), но не обязательно единый endpoint/бакет/кластер. Для гибкого масштабирования Lakehouse удобно, когда при достижении пределов роста слоя хранения, вы можете быстро подключить новый S3-кластер/endpoint и размещать новые объекты (таблицы) уже там, без необходимости миграций, downtime или ребалансировки (как это обычно бывает в классических DWH/MPP).
Открытые стандартизированные форматы хранения и поддержка транзакций
Один из наиболее важных пунктов. Пройдемся немного по истории форматов для понимания контекста. С появлением Data Lakes стали активно развиваться открытые форматы, такие как Parquet, ORC и прочие, которые очень хорошо работали с аналитической нагрузкой. Но у данных форматов были свои недостатки:
- иммутабельность — файл который вы записали уже нельзя расширить, только переписать целиком;
- отсутствие встроенных механизмов консистентности/ACID, т.е. compute-движки как правило не умели определять что происходит с файлами таблицы в текущий момент (например, идет ли запись), как следствие это вызывало ошибки конкурентного доступа («чтение-запись» или «запись-запись»).
В результате на смену открытым форматам пришли открытые табличные форматы, призванные решить описанные проблемы и добавить других полезных функций. Сейчас на рынке наиболее широко представлены Iceberg и Delta Lake: внутри они могут работать поверх всё тех же Parquet и ORC, но при этом через специальные внутренние механизмы позволяют пользователю работать с консистентным состоянием таблицы. Существует разные варианты реализации управления изменениями в данных (например Copy on Write или Merge on Read), в упрощенном виде их можно представить следующим образом:
В итоге, появляется функционал, ранее недоступный в обычных форматах:
- Механизм транзакций. Каждое изменение, которое вы производите с таблицей, сохраняется как отдельный snapshot (аналог commit). Данные в snapshots накапливаются инкрементально, т.е. старые версии данных не удаляются, а дополняются новыми. По достижении некоторой разумной границы рекомендуется выполнять удаление старых snapshots, высвобождая место. Стоит отметить, что пока поддерживаются только single-statement транзакции (один DML-оператор в рамках одной таблицы).
- Механизм Time Travel (ретроспективные запросы). За счет хранения истории snapshots на заданную глубину вы можете получить состояние таблицы на определенный момент в прошлом или получить журнал изменений между двумя состояниями, или откатиться к нужной версии в прошлом.
- Хранение метаданных внутри ФС и эволюция схемы. В ранних Data Lake структура таблиц исторически хранилась в каталоге metastore (Hive Metastore или аналогичном), что работало не очень гибко из за отсутствия версионности. Открытые табличные форматы добавили хранение собственных метаданных внутрь файловой системы (рядом с данными таблицы), обеспечивая гибкость эволюции схемы/партиций, доступность истории и состояния таблицы в текущий момент времени для всех использующих текущий табличный формат compute-движков.
- Наличие дополнительных статистик или вспомогательных структур/указателей в метаданных, оптимизирующих работу с таблицей.
Таким образом, открытые табличные форматы открыли дорогу к развитию потоковых загрузок и значительно расширили сценарии использования данных. Сейчас уже появляются более интересные и более быстрые для конкретных сценариев форматы, такие как Paimon, Lance, Vortex, Fluss и пр. Еще одним важнейшим преимуществом использования открытых форматов является независимость от конкретного вендора/технологии (т.е. нет зависимости от конкретного compute-движка и связанного с ним storage-формата, который не совместим с другими движками). Если формат открытый (и распространен на рынке, например тот же Parquet или Iceberg), он поддерживается множеством различных движков и инструментов, а значит в будущем вам будет гораздо проще произвести миграцию на целевую технологию и добавить новый compute-движок или инструмент, чем если бы вы пользовались форматом, работающим только с конкретным compute-движком или еще хуже проприетарным.
Отделение compute от storage
Это еще один важнейший аспект, призванный сделать ваше хранилище максимально гибким, эффективным и дешевым. Здесь можно выделить сразу несколько преимуществ:
- Гибкость и простота масштабирования. Т.к. у вас общий слой storage, вы можете очень быстро добавлять compute-узлы в ваш кластер, например Trino позволяет вам это сделать без остановки его работы. Новые узлы могут использовать вообще другой compute-движок, т.к. вы работаете с открытыми форматами данных. Балансировка данных соответственно тоже не требуется. Так же быстро вы можете исключить неиспользуемые узлы из кластера. Часто применяется механизмы autoscaling, например через HPA в Kubernetes.
- Адаптивность под разные рабочие нагрузки. В парадигме раздельных compute и storage вы можете гибко выделять ровно столько ресурсов compute или storage, сколько вам требуется. К примеру, для архивного хранения очевидно что вам требуется большой storage, и совсем небольшой compute. Для горячего слоя данных в высоконагруженном BI (например, данные за последний месяц) вам требуется совсем небольшой storage и сильный compute. Если вы работаете с классическими DWH/MPP, вы вынуждены выделять ресурсы гранулярностью 1 типовой узел (связанные compute + storage), как следствие у вас может оказаться недозагружен либо compute, либо storage. Проблема особенно актуальна для ПАК (программно-аппаратные комплексы), когда вы вынуждены покупать сервера типовых конфигураций, а также в проектах/организациях с часто меняющимися требованиями.
- Снижение TCO. Следствием предыдущего пункта является снижение стоимости владения за счет более эффективной адаптации под рабочие нагрузки, избавление от перекосов, и возможности быстрого раздельного наращивания compute или storage именно в тех местах, где в процессе эксплуатации становится узко.
Интероперабельность для compute-движков
Так или иначе данный функционал уже был упомянут выше, осталось сделать лишь выводы. Очевидно, что не бывает универсальных движков. Один compute-движок лучше работает с массивными аналитическими запросами, другой лучше справляется с небольшими фильтрующими выборками, третий предназначен для потоковой обработки, четвертый хорошо работает с кастомными трансформациями через собственный DSL API/фреймворк распределенной обработки. В Lakehouse всех их объединяет единый открытый табличный формат, с которым умеют работать все compute-движки. В таком подходе мы закрываем весь перечень задач, подбирая движок под наш профиль нагрузки и требования, и одновременно получая данные доступные в одной платформе.
Недостатки Lakehouse
Несмотря на многочисленные преимущества, у Lakehouse, данная статья не была бы полной, если не упомянуть и о недостатках/особенностях, которые важно учитывать при проектировании.
- Повышенная нагрузка на сеть. Поскольку технологически в Lakehouse compute и storage разнесены, это выбрасывает значительный объем данных интерконнекта в сеть, поэтому рекомендуется подходить к данному вопросу изначально с запасом. Для крупных инсталляций стараться минимизировать число узлов кластера. При достижении пределов роста могут помочь следующие техники:
- Применение локального кэширования горячих данных. Многие compute-движки так или иначе поддерживают данную технологию.
- Оптимизировать работу запросов в части pushdown, т.е. стараться применять максимум предварительной фильтрации на ранних стадиях работы запроса, чтобы избежать пересылки неиспользуемых в итоговом результате данных.
- Постепенно переходить в Data Mesh (выделение доменов с отдельными кластерами compute и storage в каждом). В этом случае, основная часть трафика интерконнекта будет локализована внутри доменных кластеров.
- Применять масштабированием самой сети (расширение каналов передачи).
- Большая сложность инфраструктуры. В Lakehouse (впрочем, так же как и в Data Lake) у вас становится больше отдельных компонент, ответственных каждый за свою задачу (аналогия с «разделением труда»). С одной стороны, это дает нам большую гибкость и эффективность, с другой, — усложняет экосистему в целом, т.е. вам потребуется больше времени чтобы всё подружить, обеспечить единой безопасностью, управлением, мониторингом.
- Ограниченная поддержка ACID-транзакций. Как уже упоминалось выше, транзакции как правило поддерживаются только одностейтментовые и однотабличные. Высокая частота или высокая конкурентность транзакций — пока что не очень хороший паттерн для средне-крупных систем Lakehouse.
Заключение
В CedrusData мы хорошо понимаем описанные выше особенности, поэтому чтобы проект вашего Lakehouse развивался наиболее успешно, мы разработали следующий функционал:
- Локальный дисковый кэш. Позволяет закреплять выбранные таблицы или партиции в кэше (в том числе можно динамически закрепить N последних партиций через правила). Кэш ускоряет работу запросов, а также значительно снижает нагрузку на сеть.
- Кэш результатов запросов. Аналогично, снижение нагрузки на сеть и ускорение запросов.
- Мы разрабатываем собственные коннекторы (Greenplum, Vertica, Teradata), или улучшаем работу существующих, как правило в части pushdown (больше всего улучшений доступно для коннекторов Clickhouse и Postgres). В совокупности это позволяет снизить сетевую нагрузку и ускорить работу запросов.
- Улучшенная поддержка транзакций. В CedrusData реализована возможность выполнения multi-statement транзакций в Iceberg.
- CedrusData Platform — платформа данных, включающая слаженный и готовый к продуктивному использованию набор компонентов, упрощающий порог входа. Платформа функционирует в среде Kubernetes и поддерживает автоматизированное развертывание компонентов, управление компонентами через Cluster Manager Web UI, мониторинг, дашборды, и прочие типовые функции и операции.
- Другие оптимизации (оптимизации JOIN, планирования запроса, материализованные представления с авто-переписыванием запросов и т.п.).
- CedrusData Catalog — современный бесплатный технический каталог для Iceberg. Включает Web UI, механизмы обслуживания Iceberg, RBAC-модель безопасности для всех подключенных compute-движков и многое другое. С основными возможностями можно ознакомиться в нашей релизной публикации. Также в одной из недавних статей мы рассказываем почему безопасность в Lakehouse это непростой вопрос и почему именно каталог тут играет ключевую роль.
В заключении хочется отметить, что Lakehouse — обоснованная конкретными преимуществами современная архитектура, занявшая устойчивую нишу в качестве центральной платформы данных во многих компаниях. Это доказывает опыт российских компаний, например Авито, Сбер, Лемана Тех, Азбука Вкуса, S7, Островок, а также зарубежных. Как и любой новый инструмент, применяйте данную технологию с умом и ваша дата-платформа получит новый импульс развития на многие годы вперед.