Публикуем отчет по зарплатам в ИТ-индустрии на 1-е полугодие 2019. Отчёт построен по данным калькулятора зарплат «Моего круга»: в котором за данный период было собрано более 7000 зарплат. 

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

Данные, представленные в нашем текущем отчёте, а также любые другие, каждый желающий может получить самостоятельно с помощью калькулятора зарплат «Моего круга». Если вам нравится информация, которую мы получаем с помощью калькулятора, и если вы хотите внести свой вклад в формирование более прозрачного рынка труда в ИТ, приглашаем поделиться своей текущей зарплатой, данные о которой мы используем в нашем следующем годовом отчёте.

Сервис зарплат запущен на «Моем круге» в конце 2017 с целью регулярного мониторинга зарплат в ИТ-индустрии. Зарплаты оставляют сами специалисты, мы их собираем и предоставляем всем в открытый доступ в агрегированной и анонимной форме.

Как читать диаграммы отчёта

Все зарплаты указаны в рублях. Это зарплаты, получаемые на руки, за вычетом всех налогов. Точками обозначены конкретные зарплаты. Группа точек по каждой выборке визуализирована с помощью «ящика с усами». Центральной вертикальной чертой показана медианная зарплата (половина зарплат ниже, а половина выше этой точки, можно считать эту зарплату средней), границы ящика — это 25 и 75 перцентили (делят нижнюю и верхнюю половину зарплат ещё раз пополам, в итоге половина всех зарплат лежат между ними). Усы ящика — это 10 и 90 перцентили (условно можно считать их минимальной и максимальной зарплатами). Подробней о том, как устроен калькулятор зарплат и как читать данные: https://moikrug.ru/info/salaries.

Средняя зарплата в ИТ индустрии сейчас 100 000 руб.: в Москве — 136 000 руб., в Санкт-Петербурге — 110 000 руб., в остальных регионах — 75 000 руб.

По сравнению со 2-м полугодием 2018 года наблюдаем общий рост зарплат. В среднем по ИТ индустрии зарплаты выросли на 10% (с 90 000 рублей до 100 000 рублей), в Москве зарплаты увеличились на 13% (с 120 000 рублей до 136 000 рублей), в Санкт-Петербурге — на 10% (с 100 000 рублей до 110 000), в остальных регионах повышение медианной зарплаты составило 7% (с 70 000 рублей до 75 000 рублей). 

Зарплаты по основным ИТ специализациям

Состояние зарплат по основным ИТ специализациям в 1-м полугодии 2019.

В целом по всем регионам за последние полгода наблюдается рост медианы зарплат в сфере аналитики (11%), менеджмента (8%), кадров (7%), разработки (5%) и дизайна (1,3%). Понижение медианы произошло только в маркетинге (-8%). А медианы зарплат в поддержке, администрировании и тестировании остались без изменений.

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

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

Зарплаты аналитиков

Зарплаты дизайнеров

Зарплаты специалистов по качеству

Зарплаты специалистов по эксплуатации

Зарплаты специалистов по кадрам

Зарплаты специалистов по маркетингу

Зарплаты руководителей

Зарплаты разработчиков программного обеспечения

Зарплаты по основным специализациям разработки

В целом по всем регионам видим, что за 1-е полугодие 2019 года выросла медианная зарплата у разработчиков всех специализаций, кроме десктоп-разработчиков, у которых она не изменилась. Особенно сильный рост наблюдаем у разработчиков игр (25%), архитекторов ПО (24%) и мобильных разработчиков (20%).

Теперь посмотрим на динамику зарплат разработчиков по отдельным регионам. У фронтенд- и фулстэк разработчиков повышение медианной зарплаты произошло одновременно во всех регионах, у десктоп- и мобильных разработчиков рост был в Питере и регионах, у эмбед-разработчиков — в Москве и регионах, у бэкенд-разработчиков — в Москве и Питере, у разработчиков игр — в Питере.

Единственная специализация разработки, по которой наблюдаем падение медианной зарплаты — это геймдев в регионах.

Зарплаты разработчиков по языкам программирования

Самые высокие зарплаты у разработчиков Scala, Objective-C и Golang — 150 000 рублей.  Лидер прошлого полугодия Elixir — сейчас занимает только 6 место по зарплате.

Рост медианной зарплаты произошёл практически по всем языкам. Особенно сильным ростом отличились Objective-C (25%), Swift (24%) и Java (20%). Небольшое снижение зарплаты видим у C++ и Delphi. Наибольшее снижение медианной зарплаты наблюдаем у Elixir (-19%).

Зарплаты разработчиков по компаниям

К лидерам среди компаний зарплатам своих разработчиков в этом полугодии присоединился OZON. Luxoft, Лаборатория Касперского, Mail.ru, Альфа Банк и Яндекс по-прежнему сохраняют самые высокие позиции.

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

Зарплаты разработчиков в городах-миллионниках

Средняя зарплата разработчиков в Москве — 140 000 руб., в Санкт-Петербурге — 120 000 руб., в Уфе — 100 000 руб., в Новосибирске и Нижнем Новгороде — порядка 90 000 руб., остальных городах-миллионниках — в среднем 80 000 руб. Полгода назад в лидерах по зарплатам разработчиков после Москвы и Питера были Нижний Новгород, Новосибирск и Уфа. В текущем полугодии тройка не изменилась, но города поменялись местами.

За 1-е полугодие 2019 наибольший рост медианной зарплаты у разработчиков Волгограда, Омска и Краснодара. Упали зарплаты в Нижнем Новгороде, Челябинске, Самаре и Перми, а зарплаты разработчиков из Ростова-на-Дону, Воронежа и Екатеринбурга остались прежними.

Основные наблюдения

1. Средняя зарплата в ИТ индустрии сейчас 100 000 руб.: в Москве — 136 000 руб., в Санкт-Петербурге — 110 000 руб., в остальных регионах — 75 000 руб.
2. За 1-е полугодие 2019 года зарплаты в ИТ-индустрии в целом выросли на 10% (с 90 000 руб. до 100 000 руб.).
3. Рост зарплат наблюдается в сфере аналитики (11%), менеджмента (8%), кадров (7%), разработки (5%) и дизайна (1,3%). Без изменений — зарплаты в поддержке, администрировании и тестировании. Снижение зарплат наблюдается в маркетинге (-8%).
4. Средняя зарплата в разработке сейчас 100 000 руб.: в Москве — 140 000 руб., в Санкт-Петербурге — 120 000 руб., в Уфе — 100 000 руб., в остальных регионах — 80 000 руб.
5. В сфере разработки наблюдаем рост зарплат по всем специализациям, кроме десктоп-разработчиков, где зарплаты не изменились. Особенно сильный рост зарплат у разработчиков игр (25%), архитекторов ПО (23%) и мобильных разработчиков (20%).
6. Самые высокие зарплаты по-прежнему у разработчиков на языках: Scala, Objective-C и Golang — 150 000 руб.  Лидер конца 2018 года Elixir — сейчас занимает только 6 место по зарплате — 110 000 руб.
7. Рост зарплат почти по всем языкам программирования. Особенно сильным ростом отличились Objective-C (25%), Swift (24%) и Java (20%). Снижение зарплат по языкам C++, Delphi и Elixir, последний отличился самым сильным снижением. Зарплаты Python-разработчиков остались без изменений.
8. К традиционным лидерам по размеру заработных плат своих разработчиков — Лаборатории Касперского, Mail.ru, Luxoft и Альфа Банку — присоединился OZON со средней медианной зарплатой разработчиков 176 000 руб.

Благодарим всех, кто указывает свои зарплаты на «Моем круге», внося свой вклад в создание более открытого и структурированного рынка ИТ! Если вы ещё не оставляли свою зарплату, то можете сделать это сделать в нашем калькуляторе зарплат.

Смотрите также наш прошлогодний отчёт по зарплатам за 2018 год.

Примерно 4 года назад мы перенесли нашу систему отчётности с Oracle на SAP Hana. Сегодня в ней хранится около 10 000 таблиц, ею пользуется 38 000 человек и в ней ежедневно происходят более 5000 процессов загрузки. На текущий момент наш комплекс, на котором работает система, представляет собой 8 серверов с 14 Тб памяти. Каждый день в системе отчётности обрабатывается 1,5 Пб данных. При этом Hana оказалась примерно в 20 раз производительнее Oracle, DB2 и MySQL. И сегодня я хочу рассказать, как мы в рамках интеграции «М.Видео» и «Эльдорадо» дополнительно повышали производительность системы отчётности, какие оптимизации вносили.

Сегодня из нескольких тысяч отчётов, создаваемых системой, всего 10 генерируют 70% всей нагрузки. Самый тяжелый отчёт в базе данных Hana — Weekly Bussines Review. Он выполняется 30 минут и потребляет 4 Тб памяти. 90% всех отчётов генерирует контактный центр: мы создали сервис, который при звонке клиента по номеру его телефона автоматически открывает отчёт и показывает оператору всю историю покупок звонящего и его взаимодействия с компанией.

Ключевая модель данных, на которой строится основной объем отчётов, содержит 1500 таблиц. Большинство из них — таблицы справочников. С помощью этой модели можно проанализировать любое направление деятельности компании. На примере — визуализация модели данных, созданная с помощью Universe designer. Правда, она отражает только десятую часть нашей системы.

На момент объединения «М.Видео» и «Эльдорадо», объем данных в двух системах отчётности был около 10 Тб: 7 Тб в системе BW on HANA «М.Видео», 2 Тб — в BW on HANA «Эльдорадо» и 1 Тб дополнительных данных в HADOOP (исторические данные). При объединении систем у нас были аппаратные ограничения: комплекс «М.Видео» состоял из 6 нод (по 2 Тб), в том числе одна резервная. Эту систему можно было расширить максимум до 8 нод, из которых одна резервная.

При подготовке к объединению мы предполагали, что общий объем всех данных достигнет 13 Тб. Поэтому, исходя из рекомендаций SAP, нам необходима была система из 16 нод по 2 Тб, в том числе две резервные. Также один узел нужно было выделить в качестве мастер-ноды, которая при таком объёме информации брала бы на себя функции управления. То есть для корректной работы нужно было развернуть 13 нод.

Как видите, доступных ресурсов категорически не хватало. И это был первый вызов.

Второй главной трудностью до объединения было то, что скорость работы системы часто не удовлетворяла запросам бизнеса. Основной причиной было большое количество параллельных обращений к БД. С точки зрения системы это выглядело как снежный ком, который мог привести либо к зависанию и прерыванию работы части процессов, либо даже к глобальным дампам «out of memory» на узлах.

Было понятно, что без существенных доработок двукратное увеличение объёмов данных в отчётах (для двух брендов) приведёт к примерно двукратному ухудшению ситуации.

Поэтому мы решили оптимизировать систему по следующим направлениям:

• Отчётность. Ускорение наиболее критичных и наиболее ресурсоёмких отчётов и пересмотр модели данных.
• Хранилище. Архивация и оптимизация хранения.
• Загрузки. Оптимизация процедуры и изменение расписания загрузок.

Общий подход к оптимизации был таким:

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

Что мы сделали:

• Изменили конфигурацию серверов приложений ABAP: количество инстанций, эффективное использование технологии NUMA и оптимальное количество рабочих процессов.
• Применили оптимальные параметры HANA и операционной системы Linux.
• Проанализировали снижение потребления ЦПУ.
• Проанализировали потребление ОЗУ во всём наблюдаемом интервале времени.
• Проанализировали возникновение OOM на HANA.
• Проанализировали возникновение блокировок в системе и доступности системных ресурсов по операциям ожидания (wait).
• Проанализировали балансировку данных с учётом редистрибуции и репартицирования данных для решения SCALE-OUT HANA.
• Проанализировали причины ABAP-дампов, влияющих на работу критически важных цепочек.

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

Каких результатов удалось добиться:

Ряд оптимизированных отчётов SAP BO стали работать во много раз быстрее и потреблять в сотни раз меньше памяти.

Вот несколько ярких примеров того, как система некорректно отрабатывает условия выбора, и как нужно правильно строить запросы в HANA.

Выявлены проблемы при фильтрации по нематериализованным объектам, особенно (!) при использовании показателей COUNT DISTINCT (CD может быть прописан как на уровне Universe, так и в функции в CV).

Даже если исключить CD из запроса, первый вариант всё равно будет выполняться в 20 раз медленнее, чем второй, а при CD скорость получается выше более чем в 500 раз.

Частный случай использования нематериализованных объектов в фильтрах: составные фильтры из двух и более объектов, например, склеивание недели и года:

Запросы со склеенными фильтрами работают не так медленно, как преобразование в дату, но всё же сильно замедляют запросы (примерно в 2-3 раза).

Для сбора статистики о работе системы отчётности, процессов загрузки и цепочек мы разработали такую схему:

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

У нас много планов по развитию бизнес-функциональности и существенной переработке инструмента визуализации данных. Глобальный тренд, в котором мы активно участвуем, заключается во встраивании системы отчётности в парадигму цифровой трансформации.

Что имеется в виду?

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

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

А сегодня мы пришли к тому, что пользователи хотят знать точный прогноз чистой прибыли. У нас есть все необходимые данные для разработки алгоритмов прогнозирования, и есть специалисты по анализу данных, способные создавать модели машинного обучения. Как вы понимаете, для этого нужны действительно большие объёмы данных, так что один из главных трендов в развитии нашей системы отчётности — переход к анализу и созданию моделей на основе big data.

Сегодня в крупных компаниях всё чаще внедряют системы прогнозирования, которые построены на алгоритмах машинного обучения, разрабатываемых самой системой. Два года назад у нас появился центр компетенции в сфере анализа данных Digital Retail Data Science Centre, а в этом году у нас появилась группа data-инженеров. Мы внедряем новую систему для обработки и анализа больших данных. И нам в команду нужны люди в отделы поддержки, развития и прикладного анализа данных.

Если вам интересны эти направления, если чувствуете в себе силы — добро пожаловать! Вас ждёт интересная и непростая работа, иногда стрессовая, но всегда творческая.

В пятницу, 19 июля, сервис Hosted Prometheus в Grafana Cloud перестал функционировать примерно на 30 минут. Приношу извинения всем клиентам, пострадавшим от сбоя. Наша задача — предоставлять нужные инструменты для мониторинга, и мы понимаем, что их недоступность усложняет вашу жизнь. Мы крайне серьезно относимся к этому инциденту. В этой заметке объясняется, что произошло, как мы на это отреагировали и что делаем для того, чтобы подобное больше не повторялось.

Предыстория

Сервис Grafana Cloud Hosted Prometheus основан на Cortex — проекте CNCF по созданию горизонтально масштабируемого, высокодоступного, мультитенантного (multi-tenant) сервиса Prometheus. Архитектура Cortex состоит из набора отдельных микросервисов, каждый из которых выполняет свою функцию: репликацию, хранение, запросы и т.д. Cortex активно разрабатывается, у него постоянно появляются новые возможности и повышается производительность. Мы регулярно деплоим новые релизы Cortex в кластеры, чтобы клиенты могли воспользоваться этими возможностями — благо, Cortex умеет обновляться без простоев.

Для беспростойных обновлений сервис Ingester Cortex’а требует дополнительную реплику Ingester’а во время процесса обновления. (Прим. перев.: Ingester — базовый компонент Cortex’а. Его задача — собирать постоянный поток sample’ов, группировать их в chunk’и Prometheus и сохранять в базе данных вроде DynamoDB, BigTable или Cassandra.) Это позволяет старым Ingester’ам пересылать текущие данные новым Ingester’ам. Стоит отметить, что Ingester’ы требовательны к ресурсам. Для их работы необходимо иметь по 4 ядра и 15 Гб памяти на pod, т.е. 25 % процессорной мощности и памяти базовой машины в случае наших кластерах Kubernetes. В целом у нас обычно гораздо больше неиспользованных ресурсов в кластере, нежели 4 ядра и 15 Гб памяти, поэтому мы можем легко запускать эти дополнительные Ingester’ы во время обновлений.

Однако часто бывает так, что во время нормальной работы ни на одной из машин нет этих 25% невостребованных ресурсов. Да мы и не стремимся: CPU и память всегда пригодятся для других процессов. Для решения этой проблемы мы решили воспользоваться Kubernetes Pod Priorities. Идея в том, чтобы присваивать Ingester’ам более высокий приоритет, чем другим (stateless) микросервисам. Когда нам нужно запустить дополнительный (N+1) Ingester, мы временно вытесняем другие, меньшие pod’ы. Эти pod’ы переносятся в свободные ресурсы на других машинах, оставляя достаточно большую «дыру» для запуска дополнительного Ingester’а.

В четверг, 18 июля, мы развернули четыре новых уровня приоритетов в своих кластерах: критический, высокий, средний и низкий. Они тестировались на внутреннем кластере без клиентского трафика примерно одну неделю. По умолчанию pod’ы без заданного приоритета получали средний приоритет, для Ingester’ов был установлен класс с высоким приоритетом. Критический был зарезервирован для мониторинга (Prometheus, Alertmanager, node-exporter, kube-state-metrics и т.д.). Наш конфиг — открытый, и посмотреть PR можно здесь.

Авария

В пятницу, 19 июля, один из инженеров запустил новый выделенный кластер Cortex для крупного клиента. Конфиг для этого кластера не включал новые приоритеты pod’ов, поэтому всем новым pod’ам присваивался приоритет по умолчанию — средний.

В кластере Kubernetes не хватило ресурсов для нового кластера Cortex, а существующий production-кластер Cortex не был обновлен (Ingester’ы остались без высокого приоритета). Поскольку Ingester’ы нового кластера по умолчанию имели средний приоритет, а существующие в production pod’ы работали вообще без приоритета, Ingester’ы нового кластера вытеснили Ingester из существующего production-кластера Cortex.

ReplicaSet для вытесненного Ingester’а в production-кластере обнаружил вытесненный pod и создал новый для поддержания заданного количества копий. Новому pod’у по умолчанию был присвоен средний приоритет, и очередной «старый» Ingester в production лишился ресурсов. Результатом стал лавинообразный процесс, который привел к вытеснению всех pod’ов с Ingester для production-кластеров Cortex’а.

Ingester’ы сохраняют состояние (stateful) и хранят данные за предыдущие 12 часов. Это позволяет нам более эффективно сжимать их перед записью в долгосрочное хранилище. Для этого Cortex проводит шардинг данных по сериям, используя распределенную хэш-таблицу (Distributed Hash Table, DHT), и реплицирует каждую серию на три Ingester’а с помощью кворумной согласованности в стиле Dynamo. Cortex не пишет данные в Ingester’ы, которые отключаются. Таким образом, когда большое число Ingester’ов покидают DHT, Cortex не может обеспечить достаточную репликацию записей, и они «падают».

Обнаружение и устранение

Новые уведомления Prometheus на основе «бюджетных ошибок» (error-budget-based — подробности появятся в будущей статье) стали бить тревогу через 4 минуты с момента начала отключения. В течение следующих примерно пяти минут мы провели диагностику и нарастили нижележащий кластер Kubernetes для размещения как нового, так и существующих production-кластеров.

Еще через пять минут старые Ingester’ы успешно записали свои данные, а новые — запустились, и кластеры Cortex снова стали доступны.

Еще 10 минут ушло на диагностику и исправление out-of-memory (OOM) ошибок от обратных прокси-серверов аутентификации, расположенных перед Cortex. ООМ-ошибки были вызваны десятикратным ростом QPS (как мы полагаем, из-за чрезмерно агрессивных запросов с серверов Prometheus клиента).

Последствия

Общая продолжительность простоя составила 26 минут. Данные не были потеряны. Ingester’ы успешно загрузили все in-memory-данные в долговременное хранилище. Во время отключения Prometheus-серверы клиентов сохраняли в буфер удаленные (remote) записи с помощью нового API remote_write на основе WAL (за авторством Callum Styan из Grafana Labs) и повторили неудачные записи после сбоя.

Операции записи production-кластера

Выводы

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

Оглядываясь назад, следует признать, что нам не следовало задавать по умолчанию средний приоритет, пока все Ingester’ы в production не получили высокий приоритет. Кроме того, следовало заранее позаботиться об их высоком приоритете. Теперь все исправлено. Надеемся, что наш опыт поможет другим организациям, рассматривающим возможность использования приоритетов pod’ов в Kubernetes.

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

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

Пережитый сбой имел и некоторые позитивные последствия: получив в распоряжение необходимые ресурсы, Cortex автоматически восстановился без дополнительного вмешательства. Мы также получили ценный опыт работы с Grafana Loki — нашей новой системой агрегации логов, — которая помогла убедиться, что все Ingester’ы должным образом повели себя во время и после сбоя.

P.S. от переводчика

Читайте также в нашем блоге:

• «Автомасштабирование и управление ресурсами в Kubernetes (обзор и видео доклада)»;
• «Kubernetes-приключение Dailymotion: создание инфраструктуры в облаках + on-premises»;
• «Переход Tinder на Kubernetes»;
• «Истории успеха Kubernetes в production. Часть 10: Reddit».

Реляционная модель потеряла свою исключительность

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

Первая проблема – низкая эффективность для больших данных (big data). Источниками больших данных являются социальные сети, системы видеонаблюдения, пространственные сенсоры, биллинг и т.п. Реляционная БД (РБД) хорошо работает, если схема данных точно определена заранее, до запуска прикладного приложения. Но большие данные по своей сути трудно поддаются структурированию на этапе проектирования БД. Только по мере сбора информации, постепенно, ее структура проявляется более очевидно.

Второе – поиск, вычисление запросов в РБД с таблицами огромных размеров – это задача высокой алгоритмической сложности. Использование индексирования и хеширования хорошо работает в более-менее статичных РБД, которые в значительной степени заполняются еще до запуска системы в эксплуатацию. А в условия быстрого поступления новых массивов данных в реальном времени, преимущества этих методов нивелируются, так как накладные затраты резко возрастают.

Третий недостаток РБД вытекает из жестких требований к схемам данных в рамках канонических «нормальных форм». Нужда в огромном количестве самых разнообразных приложений требует значительных усилий по созданию моделей данных, а неровный уровень квалификации программистов и сжатые сроки приводят к ошибкам, требующим исправлений и переделок. Но любое изменение уже «живой», наполненной РБД («миграция») – это еще более сложная и трудоемкая задача, которая в некоторых случаях вообще не имеет другого решения, как полная замена старой БД на новую.

«Красота» и строгость реляционной модели, реализуемой на SQL, на протяжении 3-х десятков лет восхищали программистов. «Старые» модели: сетевая или иерархическая были почти забыты. Да программных продуктов таких почти не осталось, за исключением, пожалуй, «почти бессмертной» IDMS [1].

В последнее десятилетие идет активная работа по созданию альтернативных систем управления БД (СУБД), которые так просто и называются – NoSQL. Под это понятие сейчас подпадают очень разные системы, которые сильно отличаются между собой. Интересно, что «старые» сетевая и иерархическая модели в понятие NoSQL не входят! Хорошие обзоры в этой области можно найти в [2,3,4].

В категорию NoSQL включают «графовые» БД [5], которые абстрактно близки к канонической сетевой модели CODASYL [6]. Как и следует из самого названия, такие системы представляют собой два неорганизованных множества – узлы (вершины) и ребра (дуги). Главное преимущество сетевых БД – навигация «определяется» не в момент обработки запроса, как в РБД, а в момент добавления новых данных (для графов — вершин и ребер), полностью справедливо и для графовых систем. Но графовая БД не структурирована до начала ее наполнения, в отличие от БД по CODASYL.

Другие самые популярные классы NoSQL БД – «ключ-значение» (пример — Redis [7]) и «хранилище документов» (пример — MongoDB [8]). Так как детальный обзор подобных систем не есть цель настоящей статьи, важно отметить только следующее.

NoSQL системы, как правило, работают на базе распределенных файловых систем, обеспечивающих масштабируемость и надежность [9]. Но задача, которая математически строго решается в рамках реляционной модели – целостность и непротиворечивость базы данных (при условии, конечно, профессионально грамотного проектирования нормализованной схемы) в большинстве NoSQL систем вообще не ставится.

В итого на сегодня ситуация примерно следующая: 75% БД – реляционные, NoSQL в чистом виде используются в узко специализированных системах, а комбинации различных моделей БД применяют в высоконагруженных глобальных сетевых проектах: Google, Facebook, Instagram, WhatsApp и подобных.

Реляционные базы данных без SQL

Кроме приведенных выше практических проблем использования РБД в последнее время стали заметны и другие важные тенденции.

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

Объектно-ориентированное программирование (ООП) в языках стало стандартом, но SQL – процедурный язык и очень плохо «дружит» с ООП. Вследствие этого популярность приобрело решение задачи стыковки программного кода приложений с запросами на SQL на основе библиотеки классов под названием ORM (Object-Relational Mapping — объектно-реляционное отображение (преобразование) [9]).

Использование классов ORM позволяет программисту обходится без SQL при использовании РБД. ORM автоматически генерирует запросы на SQL к РБД для создания таблиц и манипулирования данными. Большинство ORM имеют интерфейсы с различными популярными СУБД – SQLite, MySQL, PostgreSQL и другими, что дает выбор без модификации программного кода.

Реализаций ORM имеется масса, даже по несколько для каждого языка программирования. Все они похожи, поэтому для определённости в дальнейшем под ORM будем понимать соответствующую библиотеку (пакет) models класса Model фреймворка Django [10] на языке Python [11].

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

Поиск данных в ORM реализуется применением цепочек методов, например, “objects.all()”, “objects.get(…)”, “objects.filter(…)” в Django. Просто, красиво и удобно, но к какой алгоритмической сложности исполнения SQL-запросов, сгенерированных ORM, это приведет, не видно «невооруженным» взглядом.

Когда SQL-запрос пишет человек, предполагается, что он думает и понимает затраты вычислительных ресурсов. ORM вуалирует эту задачу.

Гипертаблица как база данных нового поколения

Нами разработана новая концепция, методы и практические способы объединить реляционную и сетевую модели БД с преимуществами идеи ORM – отказ от использования специальных языков запросов, что позволило создать новую модель и технологию баз данных.

Ключевым понятием является гипертаблица (ГТ) – это база данных, как совокупность отношений(таблиц), в которой используются:

1. «реляционные» атрибуты (домены данных), значениями которых, как в РБД, являются поля строк с самоопределенными данными по соответствующим столбцам таблиц
2. «сетевые» атрибуты (домены ссылок). Будем называть их АТС – атрибут типа «ссылка»

Значениями полей АТС в строках таблицы являются явные ссылки на любые строки в любых таблицах, входящих в гипертаблицу.

Понятие гипертаблицы, введённое нами, никак не связано с проектом [13], который был свернут в 2016 году.

Имеется действующий прототип — комплекс инструментальных средств на языке Python – система управления гипертаблицами HTMS (Hyper Table Management System), в которую входят следующие уровни (сверху вниз):

• редактор (клиент) гипертаблиц HTed – технологический вспомогательный сервис, реализованный как веб-сайт на фреймворке Django, который может подключаться к любому серверу с гипертаблицей независимо от приложений (до некоторой степени функционально близок к утилите PgAdmin для PostgeSQL);
• библиотека утилит и классов логического уровня – API для создания БД и манипулирования данными на прикладном уровне программирования (замена ORM);
• библиотека утилит и классов физического уровня работы с БД, на которой основаны утилиты и классы логического уровня (как API может использоваться опытными системными программистами);
• класс Cage, который предназначен для создания на стороне клиента (приложения) «виртуального» слоя кэшированного удаленного доступа к файлам БД;
• файл-сервер CageServer – программное обеспечение, работающее в мультипрограммном и многопоточном режиме, реализующее функции для многопользовательского удаленного доступа к файлам на сервере по протоколу ftp.

Принципиально возможно вместо Cage использовать обычную локальную файловую подсистему ОС для управления файлами, а также использовать API Cage и ПО CageServer как независимый от HTMS инструмент для реализации удаленного распределенного файлового доступа в любых системах.

В дальнейших статьях планируется подробнее познакомить читателей с системой HTMS.

Как видно из картинки, в комплексное решение для SAP HANA входят:

• Veeam Backup & Replication — для бэкапа серверов SAP HANA на уровне образа или на уровне файлов, с поддержкой восстановления.

  Если ваш сервер виртуализован — то лучшие бэкаповеды рекомендуют Veeam Backup & Replication; для физического же сервера есть Veeam Agent for Linux. У обоих имеется достаточно подробная документация, плюс статьи в нашем блоге здесь.

• Плагин Veeam — для бэкапа и восстановления баз SAP HANA с учетом транзакций.

  Этот плагин умеет задействовать SAP Backint (нативный API) для бэкапа баз и журналов транзакций и сохранять бэкапы в репозиторий Veeam (включая и масштабируемый репозиторий — SOBR). Об этом плагине я сегодня и расскажу.

Рассматриваем плагин поближе

Как было сказано выше, плагин задействует SAP Backint API для работы непосредственно с базой SAP HANA. HANA поддерживает свой собственный каталог резервных копий с настраиваемыми политиками хранения и интервалами создания. Так что Veeam Backup & Replication только и остается, что взять данные из дата-пайпов и положить их в репозиторий.
В ходе восстановления SAP HANA указывает Veeam Backup & Replication, какие данные необходимо восстановить, и Veeam достает их из репозитория.

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

Если рисовать картинку про взаимодействие компонентов, то она будет выглядеть так:

1. Когда вы запускаете процесс резервного копирования базы, то SAP HANA Backint тут же запускает сервисы плагина Veeam Plug-in.
2. Veeam Plug-in подключается к серверу Veeam Backup & Replication и создает там объект задания резервного копирования — backup job object, благодаря чему резервные копии SAP HANA становятся видны админу Veeam backup.
3. Затем Veeam Plug-in запускает агентов Veeam Transport Agent на сервере SAP HANA и на репозитории. Каждый из этих агентов создает отдельный канал для потоков данных резервного копирования.
4. Veeam Transport Agents передают данные в репозиторий.

Примечание: Надо иметь в виду, что SAP HANA Backint работает только с базой данных, выполняя разные виды бэкапа — полный, дифференциальный, инкрементальный — и журналов. Он же (Backint) используется и для восстановления. Вдобавок, кроме собственно данных, имеются также установочные и конфигурационные файлы SAP HANA, и крутится всё это на операционной системе Red Hat или SUSE. Об этом тоже не надо забывать. Так что если вам нужен бэкап собственно сервера или файлов, то для этого потребуется уже другой инструментарий.

Да, сам плагин входит в Veeam Backup & Replication 9.5 Update 4 (или 4a) в редакции Enterprise Plus.

Начинаем установку

Сначала, конечно же, проверяем соответствие системным требованиям. Поддерживаемые ОС:

• SUSE Linux Enterprise Server for SAP Applications 12 SP1/SP2/SP3/SP4 (x86_64)
• SUSE Linux Enterprise Server for SAP Applications 15 (x86_64)
• Red Hat Enterprise Linux for SAP Applications 7.2/ 7.3/7.4/7.5 (x86_64)

Поддерживаются SAP HANA 2.0 SPS 02/SPS 03/SPS 04. Редакция Express Edition не поддерживается.

Для выполнения тестовой установки плагина, бэкапа и восстановления базы вам понадобятся:

• Настроенный Veeam backup репозиторий (без шифрования!) и необходимыми правами доступа к нему.
• Для репозитория Veeam и для вашей системы HANA должно поддерживаться разрешение имен с помощью DNS (как для forward, так и для reverse).
• Система HANA версии 2.0 SPS02 или выше, работающая на x86.
• Поддержка товарища — если вы Veeam-админ, то желательно иметь рядом коллегу с опытом работы с SAP Basis, и наоборот.

Файлы установки хранятся на Veeam Backup & Replication ISO в каталоге /Plugins/SAP HANA/x64.

1. Монтируем ISO, идем в каталог /Plugins/SAP HANA/x64. Копируем нужный файл (.rpm или tar.gz) на сервер SAP HANA.
2. Запускаем на этом сервере соответствующую команду, например:

   sudo rpm -i VeeamPluginforSAPHANA-X.X.X.XXXX.x86_64.rpm

   Примечание: Для подключения к системе можно использовать Putty или любой другой ssh-клиент. Для установки вам потребуется аккаунт с правами sudo.

3. Ждем завершения установки и приглашения запустить визард конфигурации SapBackintConfigTool —wizard.

Полезно: Вообще-то установка проходит довольно бодро, но на всякий случай для любителей еще более высоких скоростей, у которых стоит Veeam Backup & Replication 9.5 Update 4a, есть вот такой специализированный performance patch for HANA.

Переходим к настройке

Важно! Для настройки Veeam Plug-in понадобится учетная запись пользователя с правами админа БД на всех инстансах SAP HANA данного сервера. Режим SAP HANA High Level Isolation не поддерживается.

1. С правами root запускаем SapBackintConfigTool —wizard.

   

2. Тут нам нужно будет указать:
   • Имя или IP-адрес сервера Veeam backup
   • Порт для связи с этим сервером — по умолчанию 10006
   • Имя пользователя и пароль для доступа к этому же серверу — учетку и права доступа должен организовать администратор, ответственный за работу Veeam Backup & Replication
   • Репозиторий, куда будут сохраняться бэкапы — если с правами всё в порядке, то отобразится список всех доступных репозиториев. Они будут перенумерованы, надо ввести номер нужного вам. В данном примере был выбран репозиторий под номером 2 в списке (его имя SOBR1).
3. Все остальное визард делает автоматически, а именно — сохраняет настройки в файл /opt/veeam/VeeamPluginforSAPHANA/veeam_config.xml и активирует SAP Backint через soft link.

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

Делаем первый бэкап

Проще всего использовать для этого SAP HANA Studio, но можно также и любой другой инструмент, например, SAP HANA Cockpit, DBA planer или какой-либо внешний шедулер.

1. Запускаем SAP HANA Studio и подключаемся к нужному инстансу SAP HANA в режиме Multiple containers → System database. (Тут вы вправе рассчитывать на дружескую помощь админа SAP Basis — он укажет имя хоста и инстанс.)
2. Выбираем аутентификацию с использованием учетки пользователя — Authentication by database user. Вводим имя пользователя и пароль для SAP HANA (в нашем примере это system — но это необязательно, вы можете создать учетку специально для операций бэкапа и восстановления с правами на backup и catalog rights. Про это написано в документации HANA).

   

3. Если с настройками все хорошо, то после прохождения визарда вы увидите в окне консоли примерно такую структуру:

   

   Если кликнуть по узлу SYSTEMDB@SID (SYSTEM) — откроется окно с подробными свойствами.

4. А мы кликаем по этому узлу правой кнопкой и выбираем пункт меню Backup and Recovery → Open Backup Console:

   

5. Переходим на вкладку Сonfiguration и там кликаем на Backint settings. Если в поле Backint Agent видим /opt/Veeam/VeeamPluginforSAPHANA/hdbbackint — значит, все настройки сделаны как надо.

Обратите внимание на несколько моментов в настройках:

• Поскольку Veeam не использует файлы Backint Parameter files, соответствующие поля должны быть пустыми. Если в них что-то есть, очистите их.
• Настройки бэкапа логов Log Backup Settings дают возможность хранить логи на файловой системе (опция File) либо задействовать Backint для отправки логов в Veeam Backup & Replication. Второй вариант (опция Backint) предпочтительнее, но только после подтверждения со стороны вашего SAP Basis-админа.
• Если вы поменяли какие-либо настройки, не забудьте их сохранить.

Наконец всё проверено, запускаем резервное копирование.

1. Кликаем правой кнопкой по узлу нашей базы SYSTEMDB@DEV и выбираем команду Backup and Recovery → Back Up System Database (и затем также будет Backup Tenant Database).
2. Выбираем тип бэкапа, который планируем создать. В качестве Destination type выбираем Backint, жмем Next.

   

3. Еще раз просматриваем все параметры и жмем Finish.
4. Наблюдаем за ходом процесса.
5. Когда все закончится, проверяем, на месте ли логи — в Backup Execution Summary кликаем по ссылке Open Log File.

   

6. Возвращаемся в диалог Backup System DB и открываем каталог бэкапов Backup Catalog. Там должно быть детальное описание только что созданного бэкапа, наподобие вот такого:

   

7. Повторяем аналогичную процедуру для tenant-а: запускаем резервное копирование базы, проверяем логи, смотрим, что в каталоге.

Если вы теперь откроете консоль Veeam Backup & Replication, то там вы увидите следующее:

• Под узлом Jobs появилось новое задание с именем такого вида “hostname SAP backint backup (repository name)»
• Под узлом History появилась новая папка Plug-ins (для Sap HANA & Oracle RMAN).

  

Сработало! С чем вас и поздравляю, а теперь переходим к восстановлению.

Восстанавливаем базу

Важно! Все тестовые процедуры, как та, что описана ниже, должны выполняться только в тестовой инфраструктуре и рядом с вашим коллегой — SAP Basis-админом. Никогда не выполняйте тестовые и учебные процедуры на продакшене! (Ваш Капитан Очевидность:)

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

1. Кликаем по нашему узлу SYSTEMDB@DEV и выбираем команду меню Backup and Recovery — Recover Tenant Database.

   

2. Выбираем tenant-а, жмем Next.
3. Выбираем вариант Recover the database to its most recent state (восстановить базу на новейшее состояние). Также есть вариант и восстановления на выбранный момент времени.
4. Если вы выполняли резервное копирование на Backint (то бишь через Backint на репозиторий) – выбираете опцию поиска бэкапов в соответствующем каталоге: Search for the backup catalog in Backint only. Если на файловую систему — то Search for the backup catalog in the file system only.

   

   Внимание! При восстановлении для DB будет выполнен shutdown!

5. Из списка бэкапов выбираем нужный. Если надо удостовериться в его наличии — нажимаем Check Availability.

   

6. Затем (после того, как рядом с нашим бэкапом после загорелся зеленый индикатор availability check) переходим на шаг Locate Log Backups и снова жмем Next.
7. Далее на шаге Other Settings указываем, что надо брать логи из того места, куда мы их сохранили через Backint. (Вообще все настройки на этом шаге нужно сверять с SAP Basis-админом.)

   

8. Жмем Next, просматриваем еще раз описание всех настроек и кликаем Finish.

Процесс пошёл! Когда он завершится, вы увидите примерно такой диалог:

Итак, резервное копирование и восстановление завершились. Свою незаметную на первый взгляд, но важную роль в этих процессах сыграл плагин Veeam Plug-in for SAP HANA (кстати, он сертифицирован SAP). Продолжение следует!

Дополнительные ссылки

• Руководство пользователя (на англ.языке)
• Страница решения (на русском языке)
• Запись вебинара (на русском языке)