Современный бизнес генерирует сотни терабайт и часто петабайты разнородных данных: от основных данных, транзакций и логов приложений до сигналов с датчиков, ML и всевозможных их производных. Неправильный выбор целевой архитектуры в быстро меняющемся мире может привести к росту затрат на инфраструктуру, излишним доработкам и переработкам, задержкам в доставке данных и болезненным миграциям при достижении пределов роста. Как итог, проблемы приводят к потере конкурентных преимуществ, что особенно актуально в e-commerce и fintech.
Классический DWH идеален для типовых OLAP-задач, но сегодня часто сталкивается с ограничениями, проблемами роста и излишними затратами. Понимание преимуществ Lakehouse позволит более гибко справляться с типичными проблемами, и перейти к унифицированной платформе, где классическая аналитика может быть расширена до кастомной и продвинутой (ML/AI/скрипты/песочницы), объединяя все данные и инструменты в рамках одной платформы, которая наиболее быстро сможет адаптироваться к постоянно растущим требованиям.
Некоторые из обозначенных вопросов мы разбирали ранее в нашей предыдущей статье об особенностях Lakehouse. Здесь мы сконцентрируемся на отличиях от классического DWH, в качестве которого обычно выступают такие решения, как Greenplum (и его производные/близкие аналоги), Exadata, Vertica, Teradata и пр.
Основные отличия Lakehouse от Data Warehouse
- LH — простота и скорость масштабирования, DWH — накладные расходы при масштабировании выше. LH построен по принципу разделения compute и storage, а в DWH — compute и storage связаны в пределах узла. DWH, как правило, работают в парадигме Massive Parallel Processing (MPP), когда ваш вычислительный кластер состоит из множества одинаковых узлов, каждый со своим набором вычислительных ресурсов (compute, CPU+RAM), и системой хранения (storage), хранящей порцию общих данных. Это обеспечивает быстрый обмен данными в пределах части данных, доступных узлу, но одновременно накладывает ограничения: масштабирование становится дорогой и в некотором роде болезненной операцией, потому что вам требуется каждый раз выполнять затратные балансировку и остановку кластера. Кроме этого, вы не можете гибко балансировать ресурсы compute/storage, когда вам резко нужно нарастить только один из них. Все это приводит к перекосам и излишнему расходованию бюджета. LH лишен описанных недостатков: масштабирование compute и storage можно выполнять независимо. Для compute-кластера масштабирование происходит моментально, без остановки работы, а для storage вам не обязательно наращивать мощности старого кластера — вы можете точно так же сделать новый: без потери эффективности, без остановки работы и без болезненных миграций.
- LH — открытые форматы хранения, DWH — закрытый/vendor-specific формат. DWH ориентирован на работу с только конкретным vendor/product-specific форматом, что сильно ограничивает его использование и приводит к необходимости регулярной загрузки/выгрузки данных в/из DWH, т.к. данные DWH умеет читать только он сам. Как результат, у вас возникают множественные ETL, перекладывающие данные из одного инструмента в другой (например, оперативные данные -> ядро -> витрины -> архив), что ведет к появлению дублей, ошибок и прочих накладных расходов. Открытые форматы хранения в LH лишены данных проблем: один compute-движок легко читает данные другого, без необходимости дорогостоящей перекладки. Сами данные LH может хранить в относительно простом и дешевом объектном хранилище, например S3. Если вы используете в LH такие инструменты, как CedrusData/Trino, то вместе с данными открытых форматов на S3, вам также становятся доступны (в рамках одного SQL-а) и данные из классических DWH. Такой функционал называется федеративны запросами.
- LH — поддержка широкого диапазона инструментов аналитики/ETL, DWH — в основном классические SQL-аналитика и ETL. DWH имеют относительно скромные возможности для распределенной аналитики и ETL, ограничивая пользователей только SQL-запросами. Вы конечно же можете использовать внешние скрипты, передавая туда-обратно данные через SQL, но эффективность подобных регулярных перемещений будет достаточно низкой. В DWH исторически узким местом с точки зрения производительности передачи данных является интеграционный интерфейс SQL/API. LH в этом смысле такими интерфейсами не ограничен, потому что данные можно читать напрямую из файловой системы, используя открытые форматы. Как следствие вы можете применять широкий диапазон инструментов, при этом не ограничивая себя в скорости получения или записи данных — все будет определяться только вашей системой хранения, скоростью сети и объемом выделенных compute-ресурсов. Среди инструментов в LH активно применяются Spark, Flink, RAY и пр., позволяют реализовать практически любой код с применением тех или иных библиотек и выполнять его распределенно. Подобный подход позволяет закрыть широкий набор сценариев:
- распределенный ETL/обработка данных (не ограничиваясь возможностями SQL);
- фреймворки для машинного обучения и inference моделей;
- анализ данных и статистический анализ;
- распределенная потоковая обработка;
- прототипирование и песочницы;
- и т.д.
- LH — работа с любыми форматами данных, DWH — как правило только с реляционными и vendor-specific набором форматов. В значительной степени является следствием предыдущих двух пунктов. В LH используются полностью открытые и управляемые форматы/интерфейсы, как следствие вы можете подобрать (или разработать) движок или скрипт, который прочитает абсолютно любой формат. В DWH как правило такой возможности или нет, или присутствует много ограничений. Как результат вы теряете в эффективности и гибкости, и вам придется использовать дополнительную инфраструктуру и обходные пути.
- LH — гибкая компонентная архитектура, DWH — монолит. Архитектуру DWH вы либо не можете расширять вообще, либо расширение ограничивается подключением UDF или других vendor-specific расширений/модулей. Если что то из того, что вам нужно не поддерживается — вы в большой беде, и, как говорится, «привет, костыли». LH — это набор компонент, взаимодействующих через открытые форматы и протоколы, как следствие такие компоненты легко заменяемы и расширяемы. Через год/два/пять вы можете оказаться в ситуации, что текущий движок/storage/формат вас не устраивает из-за производительности/санкций/ограничений. В этом случае вы легко переезжаете на новый, именно потому что протоколы и форматы открытые, переиспользуемые между движками и доступны в рамках единого слоя. Как следствие совокупные затраты на миграцию будут значительно ниже, чем в случае с DWH, где вам нужно в обязательном порядке перемещать данные физически между гетерогенными средами и обеспечивать работоспособность интеграций и приложений в переходный период.
- LH может быть единым слоем хранения, DWH требует нескольких отдельных решений для каждого слоя. В типичном стеке продуктов работы с данными, DWH как правило является только ETL/аналитической частью ядра. Сырые и неструктурированные данные, потоковые данные, архивы и бекапы, витрины и т.д. обычно выносятся в на отдельные решения — Hadoop, Clickhouse и др. Как следствие, у вас частично дублируются данные на каждом из таких слоев, участвующих в цепочке доставки данных. LH может закрыть собой все обозначенные слои, без необходимости перекладок, дополнительных и интеграций и дублирования данных, но и не ограничивает вас в использовании сторонних решений.
- LH сложнее за счет многокомпонентной архитектуры, DWH проще, как единое интегрированное решение. Для построения LH вам потребуется как минимум 3 компонента: compute-движок, объектное хранилище и метастор (или технический каталог). И когда у вас несколько компонентов, вы должны приложить некоторые усилия для их интеграции, слаживания и обеспечения эффективного функционирования. Это как с покупкой продукта из отдельных, наиболее подходящих вам компонент, против покупки сразу готовой сборки. В случае с LH можно выстроить наиболее подходящее и расширяемое в будущем решение, сэкономить на более эффективном его применении, но потратив какое то время на сборку. Нельзя сказать, что это большая проблема, но нюансы могут возникнуть. В случае с DWH вы получаете готовый продукт быстро, но с вероятностью что его части могут оказаться не непригодны (и заменить их крайне сложно) или функционала будет недостаточно.
Когда имеет смысл мигрировать
Можно выделить следующие симптомы, говорящие о том, что LH станет лучшей заменой DWH:
- Вы ищите более дешевое решение. Как отмечалось ранее, LH выигрывает у DWH в стоимости владения за счет более эффективного расходования инфраструктуры, гибко адаптируясь под конкретную нагрузку.
- Вы планируете уходить в облачную модель потребления «pay-as-you-go». При работе в облачных средах LH выигрывает за счет возможности быстро подстраиваться под изменчивую нагрузку, и, как следствие, экономить на стоимости потребления.
- В условиях неопределенности или частого появления новых технологий вы ищите решение с перспективой гибкого развития/расширения в будущем и отсутствия vendor/technology-lock. Вместо выстраивания неподатливого монолита DWH, в концепции LH за счет использования открытых форматов и протоколов, можно заложить основы и возможности для быстрых и более лёгких изменений в технологическом стеке в будущем, одновременно не уступая по функциональности и производительности DWH.
- Вам нужно заложить возможность эффективного применения продвинутой аналитики в рамках единой платформы данных — ML, статистический анализ, кастомная распределенная обработка данных. Все перечисленное может работать и на DWH, но с эффективностью значительно ниже, т.к. у DWH закрытый внутренний формат и неэффективный интерфейс API/SQL. В LH подобные сценарии работают значительно лучше за счет возможности работы с данными напрямую, через открытые форматы.
- DWH не успевает за ростом бизнеса — интеграционные процессы сильно регламентированы и затратны, а начать работать с данными или проверять гипотезы нужно уже завтра. LH в данном случае позволит гораздо быстрее получить необходимые данные. Как правило, это становится доступно за счет отсутствия излишних перекладок данных и наличия федеративных запросов (они хоть и не относятся напрямую к Lakehouse, но как правило доступны в характерных для LH инструментах, таких как Trino и CedrusData).
Когда лучше остаться на DWH
- TCO не является для вас большой проблемой, и текущее отношение производительности + сложности масштабирования к TCO вас устраивает.
- Вы не готовы управлять более сложным стеком компонентов, или у вас на это нет времени.
- У вас ожидается значительный рост объемов данных, но скорость сети масштабировать затруднительно.
