Понимание архитектуры локального озера данных (On-Premises Data Lake)

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

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

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

Основные выводы

• Архитектура локального озера данных остается важной для организаций со строгими требованиями к суверенитету данных, задержкам или нормативно-правовому соответствию.
• Современные локальные озера данных используют принципы lakehouse, объединяя открытые форматы таблиц, такие как Apache Iceberg, с разделением хранилища и вычислений.
• Распределенный движок SQL-запросов, такой как Trino, превращает локальное озеро данных в управляемую платформу с возможностью выполнения запросов для аналитики и искусственного интеллекта.
• Благодаря федерации локальные озера данных могут работать наряду с облачными платформами и SaaS-системами без принудительной централизации.
• Такие предприятия, как Lockheed Martin и GEODIS, используют эту архитектуру для сокращения времени простоя и повышения производительности запросов в масштабе.

Что такое архитектура локального озера данных?

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

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

Основные компоненты архитектуры локального озера данных

Современная архитектура локального озера данных надстраивает несколько компонентов поверх «сырого» хранилища. Ваш уровень хранения обычно использует HDFS или локальные системы объектного хранения, включая MinIO, Dell ECS и NetApp, для масштабного хранения структурированных и неструктурированных данных.

Открытые форматы таблиц, включая Apache Iceberg, Delta Lake и Apache Hudi, располагаются поверх необработанного хранилища для добавления транзакций ACID и эволюции схем. Apache Iceberg снижает зависимость от центрального метасторе, одновременно обеспечивая возможность путешествия во времени (time travel) и скрытое партиционирование, что повышает надежность по мере роста объемов данных.

Распределенный SQL-движок запросов, такой как Trino, отделяет вычисления от хранилища, позволяя масштабировать производительность запросов независимо от роста объема данных. Это разделение в сочетании с открытыми форматами таблиц составляет основу архитектуры data lakehouse. Вместе они объединяют недорогое хранилище с производительностью уровня хранилища данных, одновременно решая проблему риска превращения озера в «болото данных», характерного для старых озер данных.

Уровень каталогов и управления контролирует метаданные, контроль доступа и происхождение (lineage) для каждого набора данных в вашем озере. Конвейеры приема и оркестрации, пакетные или потоковые, непрерывно передают новые данные в озеро и поддерживают актуальность форматов ваших таблиц.

Распространенные шаблоны архитектуры локальных озер данных

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

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

Архитектуры от периферии к центру (Edge-to-core) переносят легкие вычисления на производственные предприятия или в развертывания IoT, а затем агрегируют телеметрию обратно в центральное локальное озеро данных для более глубокого анализа.

Преимущества архитектуры локального озера данных

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

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

Проблемы и компромиссы

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

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

Принципы проектирования современного локального озеро-хранилища данных

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

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

Миграция или модернизация локального озера данных

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

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

Как Starburst поддерживает архитектуру локальных озер данных

Starburst Enterprise запускает распределенный движок запросов на базе Trino локально, в облачной платформе или в обеих средах одновременно, поэтому вы храните данные там, где этого требуют правила, и при этом можете выполнять к ним масштабные запросы. С помощью федерации запросов вы можете объединять локальные источники данных с данными облачной платформы в одном операторе SQL, что снижает необходимость копирования данных между средами.

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

Например, компания Lockheed Martin интегрировала машинные данные в единое озеро данных с помощью Starburst Enterprise. В настоящее время развертывание управляет более чем 100 терабайтами данных телеметрии на 60 процентах производственных площадок и более чем 1000 подключенных устройств. Это позволило сократить время простоев.

Аналогичным образом Starburst сообщает, что компания GEODIS модернизировала свою платформу данных с помощью Starburst и добилась 600-процентного прироста производительности запросов, сократив среднее время выполнения запроса до 3,5 секунд. В настоящее время GEODIS обрабатывает 130 000 бизнес-запросов в день.

Когда вы будете готовы спланировать собственную архитектуру локального озера данных, вы можете обратиться к эксперту Starburst по поводу вариантов развертывания.

Дальнейшие действия

Обратитесь к эксперту Starburst по поводу путей миграции, вариантов управления и федерации для вашей среды.

Часто задаваемые вопросы

В чем разница между локальным озером данных и облачным озером данных?

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

Остается ли актуальным локальное озеро данных при падении стоимости облачного хранения?

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

Может ли локальное озеро данных использовать открытые форматы таблиц, такие как Apache Iceberg?

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

Как запрашивать локальные и облачные данные вместе?

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

Могут ли локальные озера данных поддерживать рабочие нагрузки искусственного интеллекта и машинного обучения?

Да, локальное озеро данных поддерживает рабочие нагрузки ИИ и машинного обучения, если оно имеет согласованные метаданные, происхождение и средства контроля доступа для каждого подключенного источника данных. Такие предприятия, как Lockheed Martin и GEODIS, запускают крупномасштабную аналитику на базе архитектуры такого типа, как подробно описано в наших историях успеха клиентов. Управляемые, хорошо каталогизированные локальные данные также поддерживают сценарии использования агентного ИИ, которым требуется надежный и авторизованный доступ к данным.