Что такое локальное озеро данных (on-premises data lake)?

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

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

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

• Локальное озеро данных хранит необработанные данные различных форматов в их исходном виде на инфраструктуре, которой ваша организация владеет и управляет самостоятельно, обычно используя HDFS или локальное объектное хранилище.
• Локальные озера данных разделяются на уровень хранения и уровень вычислений. Движки запросов, такие как Trino, могут затем анализировать данные на месте, не копируя их предварительно в отдельную систему.
• Локальные развертывания дают вам больше контроля над местоположением данных и задержками, но они также требуют больших эксплуатационных расходов, чем облачные озера данных; многие организации в итоге используют и то, и другое.
• Распространенные проблемы включают управление инфраструктурой Hadoop и HDFS, разрозненный доступ между кластерами и подключение локальных данных к облачным инструментам аналитики и ИИ.
• Вы можете модернизировать локальное озеро данных с помощью открытого табличного формата, такого как Apache Iceberg, или расширить его до гибридной или мультиоблачной настройки. Третий вариант — выполнять запросы на месте с помощью федеративного движка, вместо того чтобы сначала переносить всё.

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

Локальное озеро данных — это репозиторий для необработанных данных различных форматов, хранящихся на инфраструктуре, которой ваша организация управляет самостоятельно. Примеры включают локальные серверы, распределенную файловую систему Hadoop (HDFS) и локальное объектное хранилище. Облачное озеро данных, напротив, использует провайдера, такого как Amazon Web Services или Microsoft Azure, для владения и управления базовым хранилищем.

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

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

Как работают локальные озера данных

Локальное озеро данных разделяется на два уровня: хранение и вычисления. Более ранние проекты часто объединяли их, и понимание этого изменения помогает объяснить, почему локальные озера данных сегодня выглядят именно так.

Уровень хранения

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

Уровень запросов и вычислений

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

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

Локальные озера данных против облачных

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

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

На практике немногие организации работают исключительно локально или исключительно в облаке. Производственная компания может хранить свою основную инфраструктуру локально и в Amazon Web Services. Затем она может расширить локальное озеро данных (data lakehouse) до облака для нужд размещения данных в конкретном регионе. Такая гибридная настройка является обычной, как только у организации появляются значимые данные с обеих сторон.

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

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

Разрозненность данных (data silos) представляет собой вторую проблему. Команды часто выделяют отдельные кластеры для разных проектов, и средства контроля доступа, схемы и политики управления могут различаться в этих кластерах. Кроме того, подключение локальных данных к облачным инструментам аналитики и ИИ часто требует пользовательских конвейеров, которые копируют данные между средами. Эти конвейеры увеличивают задержку и создают больше копий одних и тех же данных, которые нужно защищать и контролировать.

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

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

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

Второй путь расширяет среду до гибридной или мультиоблачной конфигурации. Собственное руководство Starburst по миграции с Hadoop на современный data lakehouse предлагает три направления в зависимости от того, к каким изменениям готова организация:

• Обновление SQL-движка для немедленного повышения производительности без полной миграции
• Модернизация локальной инфраструктуры «под ключ» для регулируемых или чувствительных к задержкам рабочих нагрузок
• Переход на полностью управляемую облачную платформу data lakehouse

Третий путь позволяет полностью избежать миграции и выполнять запросы к локальным данным на месте с помощью федеративного движка. Этот подход позволяет запрашивать локальное озеро данных как один из нескольких источников. В сочетании с открытым форматом таблиц такая настройка объединяет недорогое хранилище озера данных с гарантиями уровня хранилища данных (data warehouse). Результатом является архитектура data lakehouse без необходимости проведения полноценного проекта по миграции.

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

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

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

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

Дальнейшие шаги

Хотите узнать больше о модернизации локальных озер данных? Ознакомьтесь с руководством покупателя по Data Lakehouse.

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

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

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

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

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

Какие технологии обеспечивают работу локального озера данных?

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

Каковы основные проблемы при эксплуатации озера данных локально?

К основным проблемам относятся операционные накладные расходы на исправление и масштабирование инфраструктуры Hadoop и HDFS, а также информационные разрозненности (data silos), возникающие, когда команды создают отдельные кластеры. Подключение локальных данных к облачной аналитике и инструментам ИИ также часто требует создания пользовательских конвейеров. Каждая из этих задач отнимает время, которое могло бы быть потрачено на задачи, непосредственно приносящие пользу бизнесу.

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

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

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

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