Высоконагруженные системы *

Как запустить игровой маркетплейс на 150 000 пользователей в день и не упасть на пиках: кейс Win Solutions х Cloud.ru

👨‍💻 Что за компания
Win Solutions («Вин Солюшенс») — ИТ-интегратор, который разрабатывает и внедряет решения для компаний в России и СНГ, а также берет на себя эксплуатацию продуктов, когда критичны устойчивость и полный контроль инфраструктуры. Win Solutions сотрудничает с Cloud.ru на проектах, где важны предсказуемость продакшена и стабильная работа под высокой нагрузкой.

🚀 Задача
Крупному клиенту интегратора нужен был маркетплейс цифровых игровых товаров, который:

• работает без простоев и деградации на пиках (особенно во время маркетинговых активностей);

• масштабируется по мере роста аудитории;

• удобен в сопровождении: с мониторингом и понятной эксплуатацией. 

Заказчику Win Solutions было критически важно быстро вывести проект в продакшен и гарантировать возможность масштабирования, поэтому выбор провайдера начался незамедлительно. Решающим доводом в пользу Cloud.ru стала оперативная работа технической поддержки и детальная документация.

☁️ Что сделали
Продуктовую среду развернули на облачной платформе Cloud.ru Evolution на пяти виртуальных машинах, изолировав значимые компоненты и распределив роли для минимизации зависимостей между ними.

Суммарная конфигурация: 120 vCPU, 240 ГБ RAM, ~6 ТБ SSD, на ВМ — Ubuntu 24.04.

Эксплуатацию закрыли мониторингом в Zabbix: команда следит за CPU, RAM, дисками и сетью, контролируя динамику нагрузки и заранее планируя масштабирование. Сейчас запас ресурсов — около 30%, масштабирование выполняется за счет увеличения ресурсов ВМ. На этапе запуска были сбои при развертывании, но команда интегратора вместе со специалистами поддержки Cloud.ru быстро выявили и устранили причины. После отладки работа сервисов стабилизировалась, сбои не повторялись.

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

Подробнее читайте на сайте.

Терабайты данных из Teradata в Trino — эффективный способ передачи

В Data Ocean Nova был добавлен новый Trino Teradata Connector, который упрощает ad hoc-доступ к данным из Teradata и позволяет выгружать терабайты данных без кратного роста нагрузки на источник. Коллеги в новой статье объясняют, почему привычная параллельная выгрузка через несколько запросов плохо масштабируется, и показывают более правильный подход: распределять чтение по AMP’ам Teradata так, чтобы каждый из них читался только один раз.

Авторы разбирают архитектуру Teradata, типичные ошибки при многопоточном извлечении данных и принцип работы федеративного доступа через Trino. Отдельно показывают, как коннектор в Data Ocean Nova помогает организовать эффективную многопоточную передачу данных и использовать push-down для фильтрации, агрегаций и join’ов, когда это действительно уменьшает объем выборки.

Как всегда, в статье много полезных советов. Читайте и комментируйте!

Spark SQL Scripting. Новые возможности для инженеров данных

Коллеги в новой статье «Spark SQL Scripting» представили добротный туториал с практическим разбором возможностей Spark SQL Scripting для инженеров данных.

Spark SQL Scripting, появившийся в 4-й версии, представляет собой процедурное расширение классического Spark SQL. Теперь разработчики могут писать полноценные многошаговые сценарии непосредственно на уровне SQL-артефактов, внедряя в них управляющую логику.

Spark SQL Scripting – это не просто синтаксический сахар, а эволюционный шаг в сторону сближения классического функционала аналитических СУБД (таких как Oracle PL/SQL, MS SQL Server T-SQL) с мощью распределенных вычислений Apache Spark. Использование Scripting позволяет инженерам данных собирать пайплайны обработки на «чистом SQL», не прибегая к сторонним компонентам и языкам разработки, тем самым сокращая кодовую базу и снижая барьер входа для дата-аналитиков.

Как это работает в типовых сценариях применения (пакетные DDL/DML-последовательности обработки, подготовка и расчет витрин данных, проверки качества данных, Runbook-операции), читайте по ссылке. Бонус для дочитавших статью до конца – свод практических рекомендаций и архитектурных паттернов при работе со Spark SQL Scripting.

Конец микросервисного угара: как Amazon, Uber и Netflix внедряли монолиты

Весной 2023 года Prime Video (Amazon) выкатил кейс, который для многих стал страшным сном: они слили красивую микросервисную оркестрацию и снизили стоимость инфраструктуры более чем на 90%.

Что они сделали? Перестали гонять данные через S3 между десятком серверлесс-функций ради банальной обработки видео. Они собрали те же самые компоненты (медиаконвертер, детекторы) в один контейнер. Вызов функции в памяти оказался быстрее и на порядок дешевле, чем "облачная магия".

Шок-контент? Только для тех, кто перечитал умных книг. Остальные просто кивнули.

Скрытый налог, о котором не пишут в книжках

Мы все прочитали «Чистую архитектуру» и умеем рисовать квадратики. Мы научились резать монолиты вдоль и поперек. Но в лучших практиках почему-то обходят главный вопрос: во что это реально обходится бизнесу?

Распределенные системы — это не бесплатный апгрейд. Это класс расходов, которого физически нет в монолите.

Вы платите за:

1. Пересылку данных по сети вместо вызова method() в памяти.

2. Отладку ада, когда для исследования бага нужно поднять логи 7 разных сервисов.

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

В итоге мы получаем внешне технически совершенную систему, которую никто не может окупить. Бывает, что переход в микросервисы — это не инженерное решение, а следование вере.

Опыт Uber

У тебя 5 сервисов — ты держишь их в голове. У тебя 500 сервисов — ты не инженер, ты -- смотритель в зоопарке.

В 2016 году в компании Uber поймать баг означало пройти по 50 сервисам из 12 разных команд. Инженеры тратили больше времени на синхронизацию в слаке, чем на написание кода.

Решение Uber (DOMA) для многих стало интересным: они не стали переписывать код в монолит. Они сгруппировали этот зоопарк по реальным доменам и прикрыли их общими шлюзами.

Монолит 2.0: как было в Netflix

В 2012-м Netflix тушил каскадные отказы через Hystrix. Но для длинных бизнес-процессов (прием контента, кодирование, раскатка по CDN) это было как пластырь на переломе. Инженеры собирали логи руками.

В 2016-м они выкатили решение Conductor — оркестратор. По сути, это монолитный движок с UI для визуализации потоков своих микросервисов. В Netflix не побороли сложность, а переупаковали её. Теперь им нужна отдельная команда, чтобы поддерживать монолит который оркестрирует микросервисы.

Прежде чем пилить новый сервис или склеивать старый, ответьте себе на три вопроса.

• Может ли одна команда выкатить фичу без согласования с пятью другими? Если для баг-фикса нужна координация 10+ команд — границы проведены неверно. Вы строите самый худший в мире архитектурный паттерн: распределенный монолит. Вы получите все минусы микросервисов и все минусы монолита одновременно.

• Какая доля бюджета уходит на бизнес-логику, а какая — на то, чтобы сервисы могли просто "договориться"? Готовы ли вы содержать сложный слой оркестрации (как Prime Video) только ради того, чтобы система технически работала?

• Есть ли у вас цифры, по которым вы поймете, что архитектура перестала окупаться? Prime Video начали с серверлесса и слепили всё в один процесс под реальной нагрузкой.

Выводов не будет, вы сделаете их сами.
Послушать расширенную версию статьи как сказку на ночь без донатов и рекламы можно на Яндекс.Музыке, Звуке и Apple Podcasts.

tg https://t.me/i_am_analyst

На чем стоит облако? GoCloud 2026: трек «Инфраструктура»

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

А вот что разберут в докладах:

• Эволюция облачных сетей: обзор новых функций и сервисов — сценарии сетевой архитектуры, защита через Anti-DDoS и анонс новых возможностей.

• Наблюдаемость продуктов Cloud.ru Evolution — мониторинг, логирование, аудит и дашборды, включая наблюдаемость для частного и гибридного облака.

• Как легко переехать в Cloud.ru Evolution из других облаков — подходы к миграции, перенос виртуальных машин, хранение и защита данных.

• Эффективно и сертифицировано: хит-парад гибридных облачных решений — как получить облачные сервисы в своей инфраструктуре, соблюдая требования регуляторов.

• ИИ-инфраструктура на выделенных серверах: от инференса до обучения на уровне суперкомпьютера — как построить ИИ-платформу полного цикла и объединить GPU-узлы через InfiniBand в кластер.

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

Если еще не зарегистрировались, сейчас самое время.

Принимаем заявки на доклады infra.conf 2026 до 1 апреля 

Команда Yandex Infrastructure приглашает докладчиков на большую конференцию по инфраструктуре — infra.conf 2026. В этом году мы встретимся 4 июня уже в третий раз и обсудим ключевые темы, которые касаются обеспечения высоких нагрузок и не только: 

• инструменты разработки и практики управления разработкой, 

• базы данных и стораджи, 

• принципы и практики обеспечения надёжности и доступности, 

• управление инцидентами 

• и многое другое. 

Отдельное внимание уделим построению и особенностям эксплуатации инфраструктуры в эпоху ML.

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

Надоело ждать квантовый компьютер? Включите видеокарту

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

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

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

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

Так родился AGIQ Solver Enterprise. Солвер, который не ждет квантового будущего, а просто берет и решает задачи здесь и сейчас, на вашей GPU.

Почему GPU, а не коробка с кубитами?

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

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

Мы не строим «квантовый компьютер в видеокарте». Мы говорим: «Ребята, давайте использовать квантовую логику как инженерный прием, а считать всё будет добрый старый GPU».

AGIQ: Эволюция на стероидах

Наш солвер берет NP-трудную задачу (будь то SAT, MaxSAT, расписание или логистика) и начинает с ней работать не как классический алгоритм, который бредет по дереву решений, спотыкаясь на каждом шаге.

Классика — это как идти по лабиринту с ниточкой. Надежно, но медленно.
AGIQ — это выпустить в лабиринт тысячу мышей одновременно. Они шумят, мешаются, находят тупики, но те, кто нашел сыр, передают сигнал остальным.

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

Честный разговор: Это не магия, это инженерия

Давайте без стартап-трепа. Мы не доказали P=NP. Мы не умеем сворачивать пространство в трубочку. Если вы дадите нам задачу, где вариантов больше, чем атомов во вселенной, за секунду мы её не решим.

Бенчмарк, чтобы было не скучно
Возьмем классическую задачу Max-3SAT. Допустим, 64 переменные и 20 тысяч условий.
На RTX 3090 AGIQ перемалывает это примерно за 45 секунд.
Можно ли быстрее? Можно. Но тут как с супом: если греть на максимальном огне, можно и пригореть. Мы подбираем параметры так, чтобы баланс скорости и качества был честным.

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

Как масштабировать NGFW до сотен Гбит трафика в секунду без потери сессий

Производительность современных NGFW давно перестала измеряться «гигабитами в идеальных условиях». В реальной инфраструктуре устройство одновременно выполняет SSL-инспекцию, IDS/IPS, контроль приложений, антивирусную проверку и другие функции — и всё это под высокой нагрузкой, без потери пакетов и без разрыва пользовательских сессий.

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

• как обеспечить симметричную обработку трафика в обоих направлениях;

• как сохранить пользовательские сессии при изменении состава кластера;

• как организовать контроль состояния узлов и корректную реакцию на сбои;

• как избежать появления единой точки отказа;

• как корректно встроить решение в существующую инфраструктуру.

5 марта в 11:00 совместно с инженерами UserGate обсудим архитектурный подход к масштабированию производительности NGFW, принципы интеграции UserGate NGFW 7 и DS Proxima, а также результаты тестирования и практический опыт внедрения.

Ссылка на регистрацию

Экономия памяти со __slots__

В Python атрибуты классов по-умолчанию хранятся в специальном dunder-атрибуте __dict__. В описании класса его задавать не надо, он есть неявно и доступен для просмотра при необходимости. Каждый экземпляр класса также имеет свой __dict__:

class Standard:
	def __init__(self, x, y):
		self.x = x
		self.y = y
		
std = Standard(100, 200)
std.__dict__ # {'x': 100, 'y': 200}

Помимо того, что и класс и экземпляры отдельно занимают своими __dict__ место в памяти, хранение данных в словарях само по себе несет большие накладные расходы. Хеш-таблица в основе словаря хранит служебные структуры и растёт скачками при увеличении числа атрибутов, поэтому на больших количествах объектов затраты памяти ощутимы:

from sys import getsizeof

std_size = getsizeof(std) + getsizeof(std.__dict__)
std_size # 344 байта

Один из эффективных способов сэкономить память, это реализовать в классе специальный атрибут __slots__ и объявить в нем последовательность атрибутов экземпляра. Тогда вместо __dict__, Python будет использовать альтернативную структуру хранения атрибутов с помощью дескрипторов. __slots__ для экземпляров классов отдельно не создается и хранится только на уровне класса:

class Slot:
	__slots__ = ('x', 'y') # Неизменный кортеж из имен атрибутов
	
	def __init__(self, x, y): # Остальное – без изменений
		self.x = x
		self.y = y
		
slt = Slot(100, 200)
slt.__dict__ # **AttributeError**: 'Slot' object has no attribute '__dict__'. Did you mean: '__dir__'?

slt_size = getsizeof(slt)
slt_size # 48 байтов

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

---
Важные ограничения

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

   std.z = 300
   std.__dict__ # {'x': 100, 'y': 200, 'z': 300}
   
   slt.z = 300 # **AttributeError**: 'Slot' object has no attribute 'z' and no __dict__ for setting new attributes
   

2. Важно, не забывать расширять слоты, если мы добавляем в код класса новые атрибуты:

   class PartialSlots:
   	__slots__ = ('x', 'y') # Не добавили атрибут экземпляра 'z'
   	
   	def __init__(self, x, y, z):
   		self.x = x
   		self.y = y
   		self.z = z
   
   p = PartialSlots(100, 200, 300) # **AttributeError**: 'PartialSlots' object has no attribute 'z' and no __dict__ for setting new attributes
   

3. В подклассах от класса со __slots__ наследование этого атрибута проходит лишь частично. Для полноценного использования, его стоит определить еще раз, включив новые атрибуты подкласса:

   # Подкласс без доп. логики
   class InheritSlot(Slot):
       pass
   
   
   inh_slt = InheritSlot(100, 200)
   
   inh_slt.__dict__ # {}, атрибут снова доступен
   inh_slt.z = 300 # Нет ошибок при динамическом расширении атрибутов
   inh_slt.__dict__ # {'z': 300}, словарь подкласса снова занимает память
   
   # Поправим
   class InheritSlot(Slot): 
        __slots__ = ('z', ) # Слоты суперкласса добавятся в начало кортежа. В конце не забываем запятую, так как это кортеж из одного элемента.
   
   
   inh_slt2 = InheritSlot(100, 200, 300)
   inh_slt2.__dict__ # AttributeError ... теперь слоты используются корректно в подклассе
   

Kubernetes: правда такой сложный, каким кажется?

В новом выпуске подкаста «В SREду на кухне» разбираем Kubernetes — честно, по фактам и без лишней теории. Говорим о главном:

• как выбирать между опенсорсным Kubernetes и вендорскими платформами;

• из чего складывается реальная стоимость владения;

• когда команда действительно готова к своим кластерам.

И пытаемся понять, почему Kubernetes постепенно становится стандартом инфраструктуры, но при этом универсального решения до сих пор не существует.

Ведущие:

• Михаил Савин, SRE Community Lead в Авито;

• Андрей Волхонский, руководитель юнита System в Центре разработки инфраструктуры Авито;

• Александр Глухих, TeamLead в юните Incident & Problem Managment в Авито.

Гость:

• Юрий Лосев, технический директор в команде Deckhouse во «Флант».

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Друзья, 12 февраля проведём открытый вебинар по следам нашего ESB-исследования в «Кругах Громова».

Если коротко — за последний год мы оценили 18 российских интеграционных платформ по единой методологии: 12 категорий, 1 000 баллов. Такого раньше на рынке не было. Результаты местами предсказуемые, местами — неожиданные.

На вебинаре поговорим:

— Почему компании до сих пор путают Kafka, ESB и data pipeline — и платят за это дважды
— 5 классов интеграционных решений: когда какой работает, а когда — категорически нет
— Как мы строили матрицу зрелости и кто в итоге получил номинацию
— Что планируем исследовать дальше — и как повлиять на приоритеты

Будет живой эфир с интерактивом, не просто «говорящая голова».

Кто работает с интеграциями, выбирает платформу или просто в теме — приходите, будет интересно.

📅 12 февраля 2026, 11:00 МСК
📍 Онлайн, бесплатно

👉 Нужна регистрация: тут

Что с Релизом ?!

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

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

За 15 лет в разработке я участвовал на разных ролях в создании совершенного разного типа продуктов, как по способу запуска(десктоп, веб и тд), типу поставки(desktop, saas, onprem) так и по зрелости продукта(прототип, mvp, плановое развитие зрелого продукта, полное переписывание внутренней системы крупного банка и тд и тп).

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

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

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

Часть, относящаяся к менеджменту релиза также удивляла как ни странно своим отсутствием и незримостью и непрозрачностью для большей части команды разработки.
Все это происходило из за сочетания типа поставки: saas (вернее отсутствия onprem поставки и строгих проверок на стороне клиентов, как говорится "все свое" ) и факта сосредоточения функций релиза в умах 1.5 человек, 0.5 из которых уже давно не относилось к отделу разработки.

Назовем такой тип релиз-менеджмента "one man release managment". Он неплохо работал, пока разработка шла по привычному процессу в рамках небольших изменений логики. Все быстро и удобно. Один человек знает и код и деплой, описывать ничего не надо, планов развертывания строить не надо, планов отката также. И ответственность тоже шарить не надо ;)

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

Всем добра и тихих релизов !

Open Table Formats — Iceberg vs Paimon — практика использования

В блоге партнеров GlowByte вышла новая статья.

Автор рассказывает об опыте работы с новым открытым табличным форматом (OTF) Paimon от разработчиков Apache Flink, представляет практические выводы, которые были сделаны на промышленных средах; а также проводит репрезентативное тестирование, где иллюстрирует ключевые практические сценарии.

Появление open table formats исполнило вековую мечту data-инженеров: совместило эффективность хранения и чтения Apache Parquet с возможностью обновления данных без полной их перезаписи. Достигается это за счет парадигмы Merge-On-Read и «отложенного удаления», когда информация об удалении старых версий записи пишется в deletion-файлы. Для фреймворков потоковой обработки, например Flink, это открывает возможности по обновлению данных прямо в Data Lake в режиме, близком к реальному времени, а для движков пакетной обработки — Spark, Impala, Trino, StarRocks — сокращает расход ресурсов на MERGE новых порций данных в витрины.

Читать статью полностью по ссылке.

Всё зелёное — значит, всё ок?

В новом выпуске подкаста «В SREду на кухне» обсуждаем суть мониторинга и причины его хронических сбоев. В фокусе — метрики и алерты: как не утонуть в потоке предупреждений, отсеять ложные сигналы и выстроить эффективную систему. Говорим о том, как SRE анализируют графики, какие показатели бизнес считает ключевыми, и развенчиваем миф о том, что «зелёный» статус всегда означает успех.

Ведущие:

• Михаил Савин, SRE Community Lead в Авито;

• Андрей Волхонский, руководитель юнита System в Центре разработки инфраструктуры Авито;

• Евгений Харченко, руководитель отдела по развитию практик в разработке и эксплуатации в Райффайзен Банк.

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Процедурное SQL-расширение в Lakehouse-платформе — новые возможности для работы с данными

В блоге технологического партнера GlowByte вышла новая статья. Команда Data Sapience рассказала о реализации процедурного расширения для работы с MPP-движками Lakehouse-платформы данных Data Ocean Nova, которое стало доступным для пользователей.

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

Открываем доступ по запросу к Yandex Managed Service for Sharded PostgreSQL — сервису на базе технологии SPQR для горизонтального масштабирования PostgreSQL

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

Однако у такого подхода множество недостатков: сложность миграций, проблемы с масштабированием метаданных и балансировкой и не только. 

Сегодня мы открываем доступ по запросу к управляемому сервису Yandex Managed Service for Sharded PostgreSQL. Новый инструмент создан на базе SPQR (Stateless Postgres Query Router) — это опенсорс‑решение для горизонтального масштабирования PostgreSQL, которое разработано инженерами из команды платформы данных Yandex Cloud и оптимизировано под OLTP‑нагрузки и плавные миграции. 

Управляемый сервис на основе SPQR позволит клиентам облачной платформы Yandex Cloud ускорить обработку миллионов транзакций: так, с Sharded PostgreSQL банки и компании из сферы электронной коммерции могут запускать новые ИТ‑продукты в 3–4 раза быстрее. Надёжность технологии шардированного PostgreSQL проверена на проектах Яндекса.

Подробная история о том, что стало отправной точкой для создания SPQR, какие задачи он помогает решать, на чём основано решение и что помогает ему быть довольно простым в эксплуатации — в статье разработчика команды Managed Sharded Postgres Дениса Волкова на Хабре.

Команда активно развивает технологии PostgreSQL: каждый год в релиз базы данных попадает множество доработок от контрибьюторов из Yandex Cloud:

Инкрементальное улучшение любой популярной технологии зачастую имеет негативные последствия. Построить что‑то новое, ничего не сломав, бывает трудно и в чистом поле, а ядро PostgreSQL в этом смысле — лабиринт с граблями.

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

Андрей Бородин, руководитель команды разработки СУБД с открытым исходным кодом Yandex Cloud, Major Contributor PostgreSQL

Читайте статью Андрея о том, как не получилось сделать PostgreSQL лучше (и почему это нормально)

Пришлось недавно серьёзно повозиться со сложным обновлением, давно такое интересное не попадалось.

Открытий и интересных решений по дороге получилось несколько, но пока не дошло до обновления рабочей, поэтому всё рассказывать не буду.
Пока про один аспект - ускорение выполнения обработчиков.

В семействе ЕРП регулярно случаются длинные обработчики обновления. Например, при переходе с 17 на 22 в регистр сведений "Реестр документов" добавили измерение с уникальным идентификатором, которое обработчик и заполняет - для всех записей. В моём случае записей было 9 млн, и выполнение обработчика занимало больше суток.

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

Так вот, попробовал я взять этот обработчик обновления, вынести код в обработку/расширение, самостоятельно распараллелить и запустить. Код там простой, изолированный, никаких зависимостей ни до ни после его выполнения я не нашёл.

И случилось чудо - обработчик выполнился часа за 4-5 (вместо 24+). Попробовал с другими обработчиками, которые столь же изолированные - результат по ускорению тот же.

Я думал, проблема в типовом распараллеливании, которое как-то не очень эффективно распределяет задания между потоками. Пошёл смотреть чужой опыт на партнёрке, нашёл относительно свежую тему (https://partners.v8.1c.ru/forum/t/2259464/m/2259464), где автор нашёл больше меня - дело и в распараллеливании, и в записи статистики. Правда, гарантированного и надёжного решения там найти не получилось - ребята из 1С сказали, что могут быть последствия, если просто отключить статистику. Но обещали что-нибудь придумать со скоростью обновлений.

А пока можете пользоваться тем же способом, что и я, коли возникнет схожая проблема.

https://t.me/ywhite

Нагрузочное тестирование YMatrix

В партнерском материале расширяются результаты нагрузочного тестирования из статьи «Нагрузочное тестирование GP6 vs GP7 vs Cloudberry» и презентуются результаты тестирования YMatrix. Это дополнение к предыдущей статье, призванное сформировать понимание сравнимости результатов различных форков GreenPlum.

Оптимизации функционала Apache Iceberg в задачах real-time загрузки и обработки данных

В блоге Data Sapience, технологического партнера GlowByte, вышла новая статья.

Технические лидеры направления разработки Apache Spark в составе платформы Data Ocean рассказывают:

• С какими проблемами можно столкнуться при реализации Upsert Streaming в Iceberg;

• Что такое equality delete;

• Почему они создают нагрузку при чтении таблиц в Apache Iceberg;

• Как оптимизировали Apache Spark, чтобы снизить потребление памяти и ускорить чтение данных.

Нагрузочное тестирование YMatrix

Привет, друзья! Мой коллега Марк, ведущий архитектор GlowByte, поделился в новой статье результатами тестирования YMatrix.

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

Добро пожаловать в статью! Комментарии приветствуются.