Современная Lakehouse-платформа данных Data Ocean Nova
Привет. Меня зовут Евгений Вилков. Я занимаюсь системами управления и интеграции данных с 2002 г., а конкретно системами анализа и обработки данных — с 2007 г. Технологии, с которыми я имел дело на протяжении моего профессионального пути, стремительно развивались. Начиная с решений, основанных на стеке традиционных СУБД, таких как Oracle, MS SQL Server, Postgres, постепенно эволюционируя в ставшие уже классическими (а некоторые даже и закрытыми) MPP-системы, такие как Teradata, GreenPlum, Netezza, Vertica, IQ, HANA, Exadata, ClickHouse, в различные решения на базе экосистемы Hadoop и облачные сервисы и платформы.
Меняется мир, меняются технологии, меняются подходы к проектированию, меняются и требования к задачам аналитического ландшафта данных.
Рис. Data Lakehouse (Gemini AI Generated)
Уверен, что многие, кто уже знаком с терминами Data Mesh и Data Lakehouse, задаются вопросом: что может предложить рынок аналитических систем в этих методологиях проектирования и архитектурных подходах. Я хочу рассказать об аналитической платформе данных Data Ocean Nova, владельцем и технологическим идеологом которой я являюсь.
Перед тем как погружать вас в архитектуру, я приведу ряд утверждений, проверенных многолетним практическим проектным опытом в области Big Data / MPP / DWH. На его основе формировались технические требования к нашей Lakehouse-системе.
Утверждение 1. Несколько лет назад стало очевидно, что все задачи аналитического хранилища данных можно решить в экосистеме Hadoop. Важным условием здесь является правильный архитектурный подход, который заключается в выборе или подготовке правильного дистрибутива и правильном выборе движков и фреймворков. Детально на этом останавливаться не буду, так на эту тему уже публиковал в сообществе материал «Как построить современное аналитическое хранилище данных на базе Cloudera Hadoop».
Утверждение 2, выходящее из первого. Стоимость системы, построенной с таким подходом, ниже, чем системы, основанной на классическом MPP стеке (и тем более чем на гетерогенном подходе «Классическая MPP + Hadoop extension»). При этом производительность такой системы выше при одинаковых капитальных затратах.
Сразу (наивно) постараюсь избежать holy war: не бывает хороших или плохих систем. Бывают системы, которые с разной степенью эффективности решают те или иные задачи работы с данными. Какие-то — более эффективно, какие-то — менее, либо требуют бОльших инвестиций в аппаратное обеспечение и дополнительные проектные решения. В данном контексте речь идет про усредненные требования к тому, что должна уметь современная аналитическая система больших данных:
Эффективно загружать данные в пакетном и онлайн режиме;
Эффективно хранить данные;
Решать задачи трансформации данных любой сложности без ограничений (расчет аналитических слоев, витрин, предоставление сервисов данных);
Предоставлять высококонкурентный управляемый пользовательский доступ непосредственно либо с применением сторонних инструментов анализа;
Решать задачу аналитической песочницы;
Эффективно масштабироваться.
Утверждение 3. Архитектура Hadoop имеет свои врожденные недостатки. Одни пороки требуют дополнительных проектных решений, остальные — неотъемлемая часть ДНК.
Попробую далее описать то, что не решается проектным способом.
Совмещенный storage и compute. Практика показала, что очень сложно подобрать конфигурацию так, чтобы она была сбалансированной в течение длительного срока эксплуатации. Либо HDFS забивается, а RAM и CPU еще хватает, либо наоборот. Любое масштабирование симметричной MPP системы — это всегда переплата за неиспользуемые мощности. Само масштабирование — длительный и затратный процесс. Сценарий, предполагающий «увеличение мощности быстро на какое-то время» не реализуем, если нет свободного подходящего по конфигурации оборудования.
Разделяемая нагрузка и изолирование ресурсов между разными группами потребителей. Сложно реализовывать сценарии разделения ресурсов между разными движками и фреймворками для разных задач и пользователей. Приходится настраивать на уровне операционной системы (cgroups), в YARN и на уровне самого движка или фреймворка (Admission control). Такой подход очень усложняет событийное распределение ресурсов и делает невозможным их динамическое распределение вида upscale\downscale, и уж тем более — быстрое создание изолированной по ресурсам области для реализации концепции Data Mesh.
Чувствительность HDFS к операциям online загрузки данных. На практике этот вопрос можно решить, но специфичность настроек при этом отрицательно скажется на аналитических задачах пакетной обработки. Либо задачу приходится выносить в отдельный storage формат, как описано тут («Использование Kudu для решения задач в реальном времени в окружении Hadoop»), либо выделять отдельный HDFS кластер для HBase.
Избыточное хранение для обеспечения отказоустойчивости, которая приводит к потере ⅔ дискового пространства (на практике erasure coding в HDFS почти не применяется).
Hadoop не облачная система, в чистом виде уж точно. HDFS на IaaS будет слишком медленным ввиду особенностей облака (виртуальные сетевые диски) и затратным (резервируем диски под избыточное хранение с фактором репликации или резервируем полностью серверы), HDFS как PaaS вообще не имеет смысла сам по себе ни для оператора облака, ни для потребителя. Хоть та же Cloudera и предлагает свое решение для public cloud провайдеров, оно конкурентно проигрывает как другим участникам рынка вроде Snowflake и Databricks, так и внутренним решениям самих облачных провайдеров.
Архитектура.
При проработке архитектуры перед нашей командой стояла задача сохранить преимущества, указанные в утверждениях 1 и 2, и обойти недостатки из утверждения 3, и как результат получить самую эффективную систему работы с данными. Давайте рассмотрим каждый компонент архитектуры Data Ocean Nova по отдельности.
Рис. Архиектура Data Ocean Nova.
Хранение данных.
В качестве storage вместо HDFS используется хранилище S3 (AWS API спецификации). Это необходимый пререквизит для установки и работы. В облачном окружении рекомендуется использовать S3 сервис от облачного провайдера, а не пытаться его сделать поверх IaaS, кроме частных случаев. В on-premise инсталляции вы можете использовать любое S3 AWS API совместимое решение, будь то готовый appliance или рекомендуемое оборудование с установленным ПО. Главное, о чем следует помнить, — требования к аппаратному обеспечению и характеристикам по нагрузке S3 хранилища должны соответствовать вашим целям.
Особенно когда речь идет о высоконагруженной аналитической системе с высокой конкурентностью за доступ с возможностью загрузки данных в режиме реального времени, а не о хранилище backup«ов или «холодных» архивов.
В данном сценарии очень хорошо себя зарекомендовал сервис на базе minIO, который может поставляться как часть общего решения.
Рекомендуемый, но не обязательный файловый формат хранения данных в объектном хранилище — Parquet, имеющий встроенные оптимизационные техники (storage индексы и page индексы). Они поддерживаются основными движками и фреймворками, входящими в Nova, что позволяет достигать максимальной производительности.
В качестве табличного расширения формата хранения мы используем Iceberg.
Что дает табличный формат Iceberg:
Поддержку требований ACID из «коробки», не прибегая к дополнительным проектным решениям;
Эволюцию
Любая эволюция структуры данных вплоть до изменения ключа секционирования на лету без необходимости пересоздания таблицы и перезагрузки данных;
Эволюцию самих данных, привязанных к их структуре;
Скрытое секционирование без необходимости создания суррогатных вычислительных полей определения ключа секционирования (в том числе явного использования выражений определения ключа для partition pruning);
Time travel на нужную версию данных;
Обеспечивает очень высокие показатели онлайн интеграции данных в связке с S3 (пример сценария использования — Change Data Capture → Kafka → Application → S3 Iceberg);
Поддержку SQL операций Update\Merge\Delete для наших процессинговых движков.
Управление ресурсами, отказоустойчивость, оркестрация
Data Ocean Nova — приложение, работающие в среде управления контейнеризацией.
В качестве подсистемы контейнеризации может использоваться любое специализированное ПО, будь то vanilla Kubernetes, которое может поставляться в качестве общего решения, или российские аналоги, внесенные в реестр отечественного ПО.
Окружение контейнеризации отвечает за разделение и изоляцию ресурсов между компонентами Nova, а также обеспечение их отказоустойчивости.
Метаданные и информационная безопасность
Сервисы, обеспечивающие работу с метаданными и отвечающие за информационную безопасность, интеграцию с LDAP и журналирование всех событий:
Hive Meta Store как технический метакаталог;
Ranger как сервис управления ролевым доступом;
Open Search как единое хранилище всех инфраструктурных и сервисных журналов.
Все компоненты системы, движки и фреймворки работают в общей ролевой модели, управляемой из одного сервиса и интерфейса.
Compute
В качестве процессинговых движков выбор сделан в пользу следующих:
Impala. Один из самых высокопроизводительных MPP движков на рынке, способных выполнять широкий перечень задач обработки и доступа к данным. Практика показала, что Impala быстрее не только аналогов из мира «около Hadoop», но и любой системы из мира классических MPP СУБД вроде Teradata или GreenPlum.
Рекомендуется к использованию как основной ANSI SQL движок для выполнения задач SQL трансформации данных (ETL), аналитического доступа для приложений и BI, пользовательского ad-hoc анализа данных и self-service задач data инженеров.
Причины эффективной работы Impala просты и очевидны: очень селективные чтения за счет использования встроенных в формат Parquet storage и page индексов; активная фильтрация данных на этапе чтения (bloom фильтры, динамические фильтры); управляемый внутриузловой параллелизм (несколько потоков обработки на одном узле для одного оператора). Особенно хорошо Impala себя показывает в высококонкурентной обработке, когда в систему одновременно поступает большое количество обращений, так как имеет продвинутые механизмы управления подобной нагрузкой (Admission Control).
Ни одна из классических систем массивной обработки данных не обладает таким перечнем возможностей. Пока ни один из современных процессинговых движков с перечисленными возможностями не использует их так эффективно в пересчете на выделяемые compute мощности.
Trino. Популярный MPP движок по возможностям во многом схожий с Impala, но все же проигрывающий ему при выполнении задач высококонкурентного (десятки и сотни запросов одновременно) доступа и обработки. Практика показала, что для сопоставимости Impala по производительности Trino требуется больше compute ресурсов, и чем выше конкурентная нагрузка, тем больше разрыв. Увы, Trino — java приложение, работающее внутри JVM, и требует соответствующих накладных расходов, в отличие от C++ с LLVM подходом ядра Impala.
Тем не менее, Trino — часть Data Ocean Nova, так как он незаменим при решении задач гетерогенного доступа, когда часть данных находится в периметре Lakehouse-системы Nova, а часть может находиться в сторонней системе (Oracle, Mongo, Postgres и так далее).
Trino, конечно, может выступать альтернативой для всех SQL задач, где рекомендуется использовать Impala, с учетом поправки на повышенные накладные расходы на ресурсы и более слабые механизмы resource management.
Spark. Тот случай, когда комментарии излишни. Де-факто — стандарт для задач data engineering, в том числе за пределами SQL анализа. Но если у вас есть причина использовать Spark SQL, например, для удаленного клиентского подключения, то Spark Thrift справится с вашими потребностями. За внешние по отношению к системе подключения по Dataframe API в системе отвечает Spark Connect. В качестве ресурсного планировщика spark задач используется YuniKorn.
Все указанные движки и фреймворки, разумеется, не обязательны к установке. Какой движок «поднимать» и какие ресурсы ему выделять — решать только вам.
Клиентские подключения и инструменты анализа
Общепринятой хорошей практикой является предоставление возможности работать с системой «из коробки» без установки дополнительного клиентского ПО. В качестве инструментов «тонкого» клиента есть возможность использовать:
Hue как SQL клиент, поддерживающий наши движки обработки Impala, Trino, Spark и прилагающиеся к ним нативные интеграции. Может работать в режиме notebook«а. Поддерживает режим multi tenancy для движков. Имеет встроенные механизмы импорта\экспорта данных и создания отчетности;
JupyterHub, ставший стандартом в определенном сегменте, как рабочее место специалиста data engineer.
Для любых внешних инструментов, не являющихся частью Nova, есть возможность установки подключения по JDBC или ODBC. Привычное для пользователей ПО вроде DBeaver, FineBi, Apache Superset, PowerBI, SAS, Tableau, Excel, Qlik и так далее тоже работает с нашим Lakehouse решением.
Дополнительные продуктовые сервисы
Помимо функционала, основанного на open source компонентах, в Nova присутствуют внутренние продуктовые сервисы, разработанные нашей командой для решения различных задач внутри целостного решения. Примеры сервисов:
Сервис загрузки и разбора до стандартного вида всех журналов, инфраструктурных компонентов, движков и фреймворков в единое хранилище-индекс;
Сервис реализации словаря данных хранилища с детальной информацией об объектах для визуализации словаря в кластер-менеджере, формирования служебных процедур обслуживания, тепловой карты данных, системы автоматической рекомендации по оптимизации объектов и так далее;
Служба AI рекомендательной оптимизации: предсказание параметров сессии к запросу для повышения пропускной способности системы;
Служба управления обслуживанием объектной файловой подсистемы и встроенные сервисные задания для периодического обслуживания «проблемы мелких файлов», табличного формата Iceberg и так далее.
Cluster Manager
Кластер менеджер — это веб-приложение с графическим интерфейсом, предназначенное для управления системой и ее мониторинга. Задача СМ — предоставить возможность администратору системы выполнять действия в графическом окружении, не прибегая к использованию CLI интерфейса. Помимо этого СМ имеет функционал анализа нагрузки на систему, определения состояния здоровья сервисов Nova, визуальной оценки распределения сервисов и нагрузки по kubernetes машинам, позволяет изменять настройки ресурсных групп, отслеживать пользовательские запросы и оценивать их токсичность, создавать регламентные процессы обслуживания окружения Nova и управлять их выполнением и многое другое.
Рис. Экранные формы Cluster Manager
Рис. Экранные формы Cluster Manager
Преимущества архитектурного подхода, применяемого в Data Ocean Nova
Независимое и динамическое масштабирование Storage и Compute. Архитектурно отсутствует ловушка неугадывания с сайзингом по дисковому хранилищу или вычислительным мощностям. В какое ограничение уперлись, то и масштабируете. Не стоит бояться стереотипа: «Да тут же не data locality!» Если вы используете правильные процессинговые движки, которые обеспечивают селективное чтение и запись, если правильно спланировали сетевую инфраструктуру и если ваш storage не делает лишнюю передачу данных внутри кластера, связанную с обеспечением фактора репликации, то этот риск максимально митигируется. К тому же наши движки прекрасно используют локальное кэширование и не читают из S3 каждый раз блоки, которые не менялись.
У вас появляется возможность прирастать дополнительными вычислительными мощностями, просто добавляя их в kubernetes. Это могут быть как аппаратные мощности, так и виртуальная инфраструктура. Представьте, что вам для обучения модели или проведения функционального тестирования релиза нужно быстро на короткий промежуток времени увеличить мощность системы (реальные use cases наших клиентов). Насколько упрощается такая задача!
Изолированность окружения. У вас появляется возможность иметь отдельные вычислительные кластеры со своими изолированными (по необходимости) ресурсами для решения различных задач или для каждого бизнес-домена, если вы намерены придерживаться концепции Data Mesh.
Пример разделения ресурсов:
Кластер регламентных процессов
Кластер подключения внешних аналитических систем
Пользовательский кластер Бизнес домена 1
Пользовательский кластер Бизнес домена 2
В одном экземпляре Data Ocean Nova для разных доменов и областей compute движков будет единый слой метаданных и единая ролевая модель. При этом вы можете иметь общий слой данных для всех доменов (например, единое аналитическое ядро) и частные области каждого домена для публикации data продуктов.
Под разными вычислительными кластерами в данном контексте подразумевается не просто разный набор движков и сервисов, но и принцип multi tenancy, при котором вы можете иметь, например, более одного изолированного кластера Impala или Trino, каждый из которых содержит свое количество узлов и свои характеристики каждого узла.
Ресурсы между тенантами или сервисами не «прибиты гвоздями». Вы можете их перераспределять, в том числе динамически, по заданным правилам. Имеется возможность создавать вычислительные кластеры событийно, в том числе руководствуясь принципом infrastructure-as-a-code. Создание окружения для бизнес-домена будет занимать минуты, и сам домен будет платить только за свои вычислительные мощности (в случае с облачной установкой буквально, при правильно настроенном биллинге).
Рис. Пример архитектуры Lakehouse с разделением на домены
Реальные case«ы использования multi tenancy:
Case 1. Клиент развернул два тенанта Impala с разными вычислительными мощностями на Kubernetes worker«ах, размещенных на аппаратном обеспечении в одном ЦОД«е, и третий тенант Impala с другими характеристиками узлов на k8s машинах, расположенных на виртуальной инфраструктуре частного облака в другом ЦОД«е.
Case 2. Клиент использует облачную инсталляцию Nova. Три независимых тенанта Impala, каждый из которых со своим количеством узлов и характеристиками:
Impala 1. Для обслуживание загрузки данных и всех регламентных ETL расчетов.
Impala 2. Выделенный тенант для ad-hoc анализа выделенного бизнес подразделения.
Impala 3. Выделенный тенант для ad-hoc анализа другого выделенного бизнес подразделения c возможностью динамического масштабирования.
Две ресурсные изолированные области Spark вычислений:
Процессы загрузки данных;
Процессы регламентного сервисного обслуживания Lakehouse-окружения.
Облачная установка.
Data Ocean Nova может быть установлена как в on-premise окружении, так и в инфраструктуре частного или публичного облака. При этом имеется возможность использовать облачные сервисы, предоставляемые оператором, замещая ими сервисы, поставляемые в составе продукта. В основном, конечно, это применимо к техническим сервисам вроде мониторинга и журналирования.
В качестве примера хочу поделиться клиентской установкой с максимальным использованием SaaS от оператора.
Инсталляция Nova от оператора Yandex.Cloud использует:
Все остальные внутренние сервисы Nova и компоненты работают в окружении managed k8s от облачного провайдера.
Рис. Одна из клиентских установок Nova в облачном окружении Yandex
Такой подход, с одной стороны, требует разделения зоны ответственности администрирования между клиентом и оператором облака, но с другой — дает максимальную гибкость в том числе потреблять и оплачивать ресурсы строго в соответствии с необходимостью и изолировать сервисные функции от основных функций системы.
Становится очевидно, что использование гибридной инсталляции (часть cloud, часть on-prem) зависит лишь от вашего желания. Все архитектурные возможности для этого есть.
Когда вам стоит рассматривать Lakehouse решение Data Ocean Nova
Область применимости нашей системы не только определяется архитектурой, но и подтверждается успешными клиентскими внедрениями.
Nova стоит рассматривать, если вы:
Заинтересованы в приобретении универсальной аналитической платформы данных Lakehouse, способной решать весь спектр задач (одна система-коробка вместо 3х или даже 4х систем):
Real-time ODS, в том числе в режиме Upsert;
Высокопроизводительная пакетная обработка и трансформация данных (сценарий классического аналитического хранилища и построения аналитических слоев и витрин);
Пользовательский доступ для решения любых задач со структурированными и неструктурированными данными;
Back-среда вычислений для аналитических приложений или ML-платформы.
Хотите получить максимальную производительность системы относительно капитальных затрат. Дешевле и быстрее, чем в Hadoop, Teradata, и GreenPlum.
Планируете следовать подходу проектирования Data Mesh, но в едином инфраструктурном окружении.
Не можете на старте предсказать сайзинг системы, соответствующий развитию вашего бизнеса, и вам необходимы гибкость и право на ошибку в масштабировании.
Рассчитываете использовать Multitenancy подход, при котором над общими данными работают несколько вычислительных изолированных кластеров, да еще и с возможностью использования разных версий сервисов одновременно.
Создаете хранилище с потребностью гетерогенного доступа.
Ориентированы на облако, но возможностей облачных сервисов для работы с данными вам недостаточно или же они вовсе отсутствуют в случае частного облака.
Data Ocean Nova в настоящий момент — единственное готовое решение enterprise уровня на российском рынке, позволяющее реализовать концепцию Lakehouse. Проектные решения наших клиентов, реализованные на основе Nova, находятся в промышленной эксплуатации не менее года.
Что делает Nova уникальным продуктом на рынке
Для правильной оценки решения и объема трудозатрат для его самостоятельной разработки, делающих продукт продуктом, помните, что:
Не существует исходного кода или системы сборки завершенного решения класса Lakehouse, из которого аналогичную систему можно собрать самостоятельно внутренней командой;
Spark, запущенный в Kubernetes над S3 или HDFS, — это не Lakehouse и не продукт;
Использование и запуск готовых образов, например, Trino, — это не Lakehouse-платформа и не продукт.
Рис. Состав команды продукта
Для того, чтобы Nova обоснованно могла называться готовым продуктом, наша команда:
Вносит изменения в исходный код opensource компонент для согласованной совместной работы внутри общего решения;
Исправляет в исходном коде компонент неизвестные ранее в сообществе ошибки, выявленные клиентами и нашей командой разработки;
Бэкпортирует исправления по известным ошибкам в исходном коде компонент;
Создает и дорабатывает новый функционал core части движков и библиотек относительно open source (новые функции движков и фреймворков, оптимизация движков, новые возможности движков для работы с S3 и табличным форматом, отсутствующие в opensource);
Подготавливает дистрибутив для установки;
Бэкпортирует новый функционал отдельных компонент с upstream версий open source;
Адаптирует все компоненты для работы в среде Kubernetes (в том числе дорабатывает исходный код приложений);
Оперативно выпускает новые версии при релизе opensource компонент;
Поддерживает требования информационной безопасности enterprise уровня для Kubernetes (например, Kubernetes CIS или другие стандарты);
Самостоятельно или совместно с партнерами обеспечивает совместимость с базовым ПО РФ из реестра Минцифры: ОС (Альт, Астра, РедОС), Kubernetes сборки (Orion Nova, Флант, Альт), PostgreSQL (PostgresPro, Panglin), S3 appliance.
Оказывает полную техническую поддержку.
Наша команда имеет многолетний практический опыт построения высоконагруженных систем обработки данных на тех технологиях, которые используются в нашей системе Data Ocean Nova. Мы входим в группу компаний GlowByte — одну из самых опытных Big Data команд, видение которой основано на гигантском опыте успешной проектной работы на российском и зарубежных рынках, а не на анализе исходного кода в GIT и изучении публикаций в открытом доступе. Мы вкладываем свои знания и опыт в конечный продукт и обеспечиваем высокий уровень сервиса, что создает уникальную добавленную стоимость.
Данная публикация получилась достаточно объемной, хотя еще многие темы остались нераскрытыми. Поэтому в ближайшее время мы планируем продолжить делиться материалами на следующие темы:
Результаты сравнительных тестирований Data Ocean Nova и других систем и сопоставление современных процессинговых движков.
Как правильно проводить тестирование аналитических систем массивной параллельной обработки.
Как оценивать стоимость владения системой. Какие критерии необходимо учитывать.
*****
Lakehouse-платформа данных Data Ocean Nova разработана Data Sapience (входит в группу компаний GlowByte).
