Привет, Хабр! Я Станислав Габдулгазиев, архитектор департамента поддержки продаж Arenadata. Кажется, ещё вчера мы радовались возможностям Apache Spark 3.0, разбирались с Adaptive Query Execution и наслаждались улучшениями Pandas API. Но мир больших данных не стоит на месте, и вот уже на подходе Apache Spark 4.0. Новый мажорный релиз — это всегда событие: он обещает новые фичи, прирост производительности и, конечно же, новые вызовы при миграции.

Apache Spark де-факто стал стандартом для распределённой обработки данных. От классических ETL-пайплайнов и SQL-аналитики до сложного машинного обучения и стриминга — Spark так или иначе задействован во многих современных data-платформах. Поэтому каждый новый релиз вызывает живой интерес у комьюнити: что там под капотом? Какие проблемы решены? Не сломается ли то, что работало годами?

Привет, Хабр! Наверняка каждый разработчик или администратор сталкивался с ситуацией, когда для проверки гипотезы или нового функционала срочно нужна «чистая» база данных. Приходится либо искать свободный сервер, либо разворачивать всё локально, тратя время на установку и настройку. А если таких тестовых баз нужны десятки для команды или разных команд? У наших клиентов мы видели целый зоопарк из PostgreSQL разных версий и конфигураций, поддержка которых превращалась в головную боль. Именно эту проблему — создание «одноразовых» и легковесных баз по одному клику — мы и решили. Меня зовут Сергей Гонцов, я занимаюсь развитием СУБД, основанной на PostgreSQL, которая совсем недавно перешла «под крыло» Arenadata и называется теперь Arenadata Prosperity (ADP). В этой статье расскажу нашу историю, как мы готовили свой DBaaS-сервис.

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

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

Привет, Хабр! Меня зовут Алексей Быков, я занимаюсь развитием cloud-native-платформы для обработки данных Arenadata One (AD.ONE). В этой статье мы поговорим о neon-kubernetes-реализации PostgreSQL, её устройстве, особенностях и о том, почему классический подход к Postgres в Kubernetes не позволяет в полной мере использовать преимущества гибкой облачной инфраструктуры.

Тема не новая и активно развивается: уже давно существуют операторы (Zalando, Crunchy Data, CloudNativePG) для автоматизации развёртывания Postgres в Kubernetes. Однако они сохраняют монолитность базы, когда данные по-прежнему жёстко связаны с узлами, а горизонтальное или вертикальное масштабирование требует ручной настройки и остаётся непростым процессом. Подход Neon основан на полном разделении вычислений (compute) и хранилища (storage), что даёт нам возможность взглянуть на использование PostgreSQL в облаке по-новому, как на сервис с возможностью динамического масштабирования, мгновенного запуска инстансов, изолированных веток (branching) и других возможностей без необходимости в сложной инфраструктурной обвязке.

Хабр, привет! В этой статье расскажем, как команда банка ВТБ построила собственную аналитическую систему на базе открытых технологий и с использованием решений Arenadata. Мы рассмотрим архитектуру платформы, разберём её сильные и слабые стороны, а также заглянем «под капот» — покажем, как устроены процессы внутри банка и почему ВТБ решил идти своим путём, а не использовать готовые вендорские системы.

Привет, Хабр! Я Станислав Габдулгазиев, архитектор департамента поддержки продаж Arenadata. В этой статье рассмотрим, как большое количество мелких файлов влияет на производительность различных систем хранения, таких как HDFS и объектные хранилища с S3 API.

Разберём, какие технологии хранения лучше всего подходят для работы с мелкими файлами в архитектурах Data Lake и Lakehouse. Сравним производительность HDFS и объектных хранилищ с S3 API. На конкретных тестах покажем, почему именно HDFS эффективнее справляется с большим количеством небольших файлов. Обсудим также случаи, когда мелкие файлы становятся не просто нежелательной ситуацией, а неизбежной необходимостью, например в подходах типа Change Data Capture (CDC).

Привет, Хабр! Сегодня мы расскажем, как «Национальная Лотерея» — компания, обрабатывающая сотни миллионов транзакций ежегодно, полностью перестроила свою работу с данными. Изначально инфраструктура данных опиралась на Excel-отчёты, ручные выгрузки и разнородные базы — подход, типичный для старта аналитических процессов. Однако со временем такие методы стали сдерживать скорость и масштабируемость аналитики.

Привет, меня зовут Костя Осипов, и я занимаюсь разработкой СУБД. На Хабре есть несколько моих статей про MySQL, Tarantool и про всякое-разное. Кроме того, я веду Telegram-канал, где делюсь инсайтами в области управления базами данных. Сегодня я выступаю в роли основателя компании Picodata, создающей одноимённую открытую СУБД, и управляющего директора ПАО Arenadata по исследованиям и разработке. Ниже — вольный пересказ моего недавнего доклада на HighLoad. Он про то, что нас ждёт в мире СУБД завтра, и, в частности, про место резидентных СУБД в архитектурах будущего.

Хабр, привет! И добро пожаловать на прямую текстовую трансляцию конференции ArenaDAY 2025! Да, сегодня на официальном сайте идёт прямая видеотрансляция мероприятия, но мы решили провести ещё и текстовую — специально для тех, кто не может смотреть онлайн. Следите за обновлениями: мы оперативно публикуем самые интересные моменты, главные тезисы выступлений и цитаты спикеров!

Корпоративное хранилище данных (КХД) — один из ключевых компонентов любой ИТ-системы, который необходим для безопасного хранения и использования всех данных компании. Но построение КХД нередко превращается в «задачу со звездочкой» еще на этапе выбора платформы для развертывания: многим компаниям сложно определить, какой из вариантов будет не только надежнее, но и дешевле. 

В этой статье попробуем в деталях и на примерах разобрать, какой вариант развертывания экономически рентабельнее и что стоит учитывать при выборе платформы для построения КХД.

Материал подготовлен директором центра бизнес-решений VK Tech Константином Дудниковым и директором по развитию облачного бизнеса Группы Arenadata Антоном Близгаревым @beton55.

Хабр, привет! Меня зовут Алексей Быков, и я занимаюсь развитием Cloud Native платформы для обработки, хранения, анализа и управления данными Arenadata One в компании Arenadata. Современные высоконагруженные системы требуют гибкого масштабирования и отказоустойчивости для обеспечения стабильной производительности в условиях постоянно растущих объёмов данных. Когда речь идёт о PostgreSQL, развёрнутом в Kubernetes, перед инженерами встают особые вопросы: как упорядочить реплики для отказоустойчивости, каким образом настроить бэкапы и мониторинг, а главное — как корректно масштабироваться в облачной среде.

В этой статье мы рассмотрим, почему «ванильный» PostgreSQL в контейнерной среде может работать ненадёжно и какие механизмы применяются сегодня, чтобы сделать базу данных по-настоящему Cloud Native. Разберём ключевые аспекты классических инсталляций Postgres, проанализируем, в чём заключаются основные сложности их переноса в Kubernetes.

Хабр, привет! Современные высоконагруженные системы требуют точной настройки и регулярного мониторинга, чтобы обеспечить стабильную производительность в условиях постоянно растущих объёмов данных. Когда речь идёт о крупной аналитической базе данных, развёрнутой в облачной среде, оптимизация её работы становится критически важной задачей. В прошлой статье мы уже рассказывали о типичных ошибках при работе с Arenadata DB (ADB), о том, как их избежать и значительно повысить производительность кластера. Сегодня же поделимся реальным опытом на примере компании «Комус» — лидера в области B2B-ритейла, которая обратилась к Arenadata за проведением комплексного аудита своего кластера ADB.

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

Привет, Хабр! Меня зовут Алексей Струченко, я работаю архитектором информационных систем в Arenadata. Сегодня хотелось бы поговорить о хранилищах данных — их видах, ключевых особенностях и о том, как выбрать подходящее решение. В эпоху цифровой трансформации данные стали одним из самых ценных активов для компаний любого масштаба и сферы деятельности. Эффективное хранение, обработка и анализ больших объёмов данных помогают организациям принимать обоснованные решения, повышать операционную эффективность и создавать конкурентные преимущества.

Однако с ростом объёмов данных и усложнением их структуры традиционные методы хранения сталкиваются с ограничениями. В этой статье мы подробно рассмотрим подходы к хранению данных: Data Warehouse (DWH), Data Lake и относительно новую концепцию Lakehouse. Разберем их особенности, различия, преимущества и недостатки, а также предложим рекомендации по выбору каждого подхода.

История, связанная с этой задачей, началась для нас в мае 2024 года. Один из крупных пользователей Greenplum/Arenadata DB обратился к нам с запросом реализовать возможность отслеживания изменения размеров файлов данных таблиц. Эта функциональность стала бы составной частью, источником событий для системы мониторинга пользовательских кластеров. Задача показалась нам крайне интересной и перспективной. Однако пользователю, как это часто бывает, решение требовалось уже вчера.

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

Добрый день. Меня зовут Иван Клименко, я архитектор в департаменте поддержки продаж компании Arenadata. Основное направление моей работы — продукт Arenadata Streaming (ADS), масштабируемая и отказоустойчивая система для потоковой обработки данных в режиме реального времени, предназначенная для корпоративного использования и построенная на базе Apache Kafka и Apache NiFi.

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

Greengage Database — наш форк Greenplum Database. Основная идея — оставить исходный код открытым и продолжить разработку и совершенствование базы данных. Мы собираемся перенести Greengage Database на более новую версию Postgres, предоставив более богатый набор функций всем пользователям сообщества и нашим клиентам.

Но эта задача сложнее, чем может показаться. Ранее для реализации функций массивно-параллельных вычислений Greenplum Database основная функциональность Postgres была существенно переработана. Таким образом, обновление версии Postgres создавало огромные сложности. Например, переход с Postgres 9 на Postgres 12 потребовал огромных усилий — между мажорными релизами было почти 5 лет разработки.

Имея это в виду, мы начали масштабный рефакторинг ядра Greengage Database. Мы собираемся разделить ядро ​​Postgres и специфичные функции Greengage Database, используя стандартные существующие средства Postgres для расширений.

Привет, Хабр! Меня зовут Станислав Габдулгазиев, и я архитектор департамента поддержки продаж Arenadata. В этом материале поделюсь впечатлениями от использования Kyuubi — инструмента, который значительно упрощает работу пользователей с SQL, а также затрону вопросы его сравнения с другими решениями для обработки больших данных.

Kyuubi — это сервис, предоставляющий механизмы для распределённого выполнения SQL-запросов поверх различных вычислительных движков, таких как Apache Spark, Hive, Flink и Impala. Он часть дистрибутива Arenadata Hadoop (ADH), который включает эти движки для обработки и анализа данных.

Привет, Хабр! Меня зовут Александр Тарасов, я архитектор департамента поддержки продаж Arenadata. Уход крупных зарубежных вендоров, таких как Oracle и Microsoft, заставил нас переосмыслить подходы к управлению данными и освоить альтернативные решения. Если с транзакционной нагрузкой всё относительно ясно благодаря PostgreSQL, то в аналитике дела обстоят сложнее, и здесь особенно важно адаптироваться к новым инструментам. Сейчас на первый план выходят системы с открытым исходным кодом, которые не только поддерживаются сообществом, но и открывают новые возможности для роста и экспериментов, оставаясь актуальными в условиях меняющегося рынка.

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

Привет, меня зовут Георгий Ломакин, и я инженер по нагрузочному тестированию в компании Picodata — разработчике одноимённой NewSQL СУБД. В этой статье я поделюсь своим опытом нагрузочного тестирования и расскажу, как мы строили эту практику с нуля.

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

Привет, Хабр! Меня зовут Дмитрий Капралов, я работаю в команде консалтинга компании Arenadata. Одной из наших задач является проведение аудита кластеров СУБД Arenadata DB (ADB). Проектирование физической модели данных и настройка квотирования ресурсов кластера проводятся на этапе разработки хранилища. Однако при переходе системы в продуктивный режим профиль нагрузки кардинально меняется, и первоначальные настройки СУБД и архитектура данных нередко оказываются не готовы к такой нагрузке. В процессе эксплуатации могут возникнуть узкие места, замедляющие работу системы. В этой статье я хочу поделиться опытом нашей команды по выявлению и оптимизации подобных проблем.