Как создать масштабируемую и экономически эффективную платформу данных Lakehouse

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

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

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

Почему чистая история больших данных больше не полезна

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

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

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

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

Lakehouse как поворотный момент

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

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

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

Структурные проблемы и проблемы управления при внедрении Data Lakehouse

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

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

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

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

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

Оптимизация затрат как правило номер один

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

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

Храня все данные в одном месте и размещая связанные объекты близко друг к другу, lakehouse устраняет необходимость в чрезмерных соединениях и передачах данных. Когда мы выполняем аналитику, например, создавая модель машинного обучения для анализа клиентов, мы можем использовать как исторические, так и реальные транзакционные данные без копирования или перемещения их между системами.

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

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

Выбор правильного архитектурного подхода

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

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

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

— Последний слой, известный как золотой слой, — это место, где находятся агрегированные данные. Панели инструментов и BI-инструменты, такие как Tableau или Power BI, обычно подключаются к этому слою для доступа к готовым метрикам и визуализациям. Тем не менее, не все можно предварительно рассчитать.

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

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

Инсайты с места

Если бы я проектировал с нуля, я бы сделал несколько вещей иначе, чем отрасль подходила к данным в прошлом.

Ниже приведены уроки, которые я извлек из реальных внедрений, и то, что я теперь рекомендую.

1. Начинайте с малого, предоставляйте быстро

Миграция всего сразу не всегда оптимальна. Компании часто пытаются перенести терабайты данных в новую систему, только чтобы обнаружить, что ее никто не использует. Лучший путь — начать с одного варианта использования, который обеспечивает четкую бизнес-ценность, например, рекомендательная система, динамическое ценообразование или модель удержания клиентов. Успех в этой области обеспечивает как доверие, так и план масштабирования.

1. Переводите бизнес-требования на ранней стадии

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

1. Соответствуйте технологии организационным возможностям

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

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