«Мы даем клиентам возможность быстрее получать качественно размеченные метаданные и сокращать затраты на ручную работу»

CNews: В последние годы многие компании переходят от классических хранилищ данных к архитектуре Lakehouse. В чем вы видите ключевые преимущества этого подхода для бизнеса и в какой момент имеет смысл задумываться о такой миграции?

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

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

Еще один важный момент — поддержка транзакционности и согласованности данных. Например, на базе Apache Hadoop нельзя было изменять данные. Из-за этого инженерам по работе с данными приходилось обходить ограничения и усложнять процессы. Это была серьезная проблема. В Lakehouse она в значительной степени решается.

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

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

CNews: С какими основными барьерами компании сталкиваются при переходе на отечественные аналитические и data-платформы и какие из этих барьеров сегодня оказываются наиболее критичными?

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

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

Что касается облачных решений, мы часто видим недоверие со стороны компаний, связанное с вопросами безопасности при необходимости одновременно работать и с внутренними системами, и с облаком. Наш партнер по коммерческому ИТ-кластеру «Ростелекома» «Турбо Облако» предлагает защищенное соединение между инфраструктурой заказчика и облачной платформой: трафик шифруется, а гибкие модели администрирования позволяют заказчику сохранить контроль над своим контуром, доверив нам управление каналом и облачной частью, которая имеет необходимые аттестации по безопасности.

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

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

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

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

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

CNews: Вопрос безопасности остается одним из ключевых при работе с данными. Как сегодня выстраивается подход к защите данных в облачных и гибридных средах?

Андрей Телюков: Безопасность включает несколько составляющих. Прежде всего — гибкая настройка прав доступа и правил, которые определяют, кто и к какой информации может иметь доступ. Далее — аудит и логирование действий в системах. Эти задачи одинаково актуальны для Lakehouse, Data Lake, аналитических контуров или DWH.

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

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

CNews: Как компании на практике разделяют данные между облачной и локальной инфраструктурой с учетом регуляторных требований и рисков?

Андрей Телюков: На практике это решается достаточно просто. Сначала нужно определить, какие данные ни в коем случае нельзя выводить за пределы компании, а какие менее чувствительные — их можно деперсонализировать, зашифровать или замаскировать.

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

CNews: В архитектуре Lakehouse часто используется подход с несколькими слоями данных (бронза, серебро, золото). С какими техническими сложностями сталкиваются компании при организации таких слоев в российских условиях, особенно на этапе работы с сырыми данными?

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

Дополнительно возникает проблема стремления сохранять все «как есть», что приводит к появлению так называемого «болота данных», с которым затем невозможно работать и решать задачи.

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

CNews: Сейчас активно обсуждаются открытые форматы таблиц вроде Apache Iceberg. Какие проблемы с управлением данными они помогают решить и насколько это критично для построения современной аналитической платформы?

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

«Бизнес думает о данных своими терминами»

CNews: Как должна меняться архитектура Lakehouse, чтобы нормально работать с задачами машинного обучения и ИИ? Не превращается ли все это в излишне сложный «зоопарк» технологий?

Андрей Телюков: Классический Lakehouse изначально оптимизирован для SQL-аналитики и пакетной обработки. Это не всегда подходит для задач ИИ, где требуется случайный доступ к отдельным сэмплам данных.

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

Например, формат Lance способен заменить Parquet и обеспечить быстрый доступ к случайным данным. Риск «зоопарка» технологий действительно существует, но его можно контролировать на этапе проектирования: важно заранее понимать, как будет использоваться хранилище, и, если задачи ИИ будут ключевыми, закладывать это в архитектурное решение и последовательно ему следовать.

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

Андрей Телюков: Действительно, классическая защита по периметру уже не отвечает современным требованиям. Мы предлагаем использовать унифицированный каталог данных, который позволяет управлять правами доступа и политиками независимо от инструмента, используемого пользователями ,будь то SQL-движок, Python или Spark,. Такой каталог хорошо вписывается в архитектуру Lakehouse.

Дополнительно может применятся динамическое маскирование данных: чувствительные данные автоматически выявляются и подменяются безопасными значениями.

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

CNews: С развитием самообслуживания в аналитике часто возникает разрыв между тем, как бизнес видит данные, и тем, как они реально хранятся. Как современные платформы решают проблему единого семантического слоя, чтобы бизнес-пользователи работали с привычными терминами, а не с именами колонок в БД?

Андрей Телюков: Эта проблема встречается почти всегда: бизнес думает о данных своими терминами, например «выручка за вчера», а для аналитика это SQL-запрос, причем у разных специалистов такие запросы могут отличаться даже для одного показателя. Решается это с помощью инструментов управления данными, таких как RT.DataGovernance и RT.MDM, а также через создание бизнес-глоссариев.

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