Привет, Хабр! Меня зовут Кирилл Тарасов, я — инженер данных в K2Tех. Наша команда Big Data & Bi работает с 2006 года, мы активно занимаемся Greenplum, Arenadata Hadoop/Streaming и внедряем собственные наработки, такие как ELT Framework. Также с 2012 года мы создаём аналитические системы и хранилища данных, и за это время моя команда столкнулась с самыми разными ситуациями, которые вызывали различные проблемы для реальной продуктивной эксплуатации СУБД. Некоторые из них были связаны с настройками баз данных, другие — с компонентами защиты, а третьи были настолько необычными, что их причиной оказалось исключительно странное и редкое поведение бизнес-логики, с которым разработчики хранилищ данных почти не сталкиваются. В этой статье вы найдете шесть кейсов, которые могут встретиться на любом проекте. Они помогут избежать попадания «ложки дегтя» в ваше хранилище.
Лайфхак 1: Кто-то должен отвечать за ИБ на каждом этапе
Когда ведется разработка, особенно на начальном ее этапе, мы часто считаем все происходящее «внутренней кухней», ведь ничего пока не попадает в прод, и у систем нет пользователей, кроме «своих». Но даже в этот момент уже нужно заниматься ИБ.
Приведу пример. На одном проекте нам необходимо было обеспечить проектную команду рабочим окружением — предоставить клиенты для СУБД, серверам, ETL и т. д. Чтобы не заниматься многократным развертыванием всего и вся, один из участников процесса предложил «запилить» виртуальную машину (VM) с предустановленными клиентами, чтобы ее можно было копировать внутри команды.
Сказано — сделано. Команда получила VM со всеми установленными клиентами и начала работу. Однако через какое-то время учётные записи стали блокироваться одна за другой. Мы обращались в техподдержку за разблокировкой и списывали все на ошибочные срабатывания. Но в скором времени пришёл комментарий от ИБ: «Со стороны указанных учетных записей осуществлялась DDoS-атака по защищаемым ресурсам в корпоративной сети передачи данных (КСПД). Рекомендация: пользуйтесь антивирусами».
Каково же было наше удивление, когда после установки и запуска антивируса на всех VM были обнаружено вредоносное ПО. Видимо, специалист не проверил версии ПО, которые собрал в образ VM, либо взял его целиком откуда-то. Использование готовых образов VM без проверки категорически запрещено по одной ключевой причине: кибербезопасность. Как мы убедились, в таких образах часто содержится вредоносное ПО, а это создает прямую угрозу для данных наших клиентов, так как вирусы могут украсть конфиденциальную информацию компаний, которым мы предоставляем услуги.
Мораль: пользуйтесь антивирусами, назначайте ответственного за ИБ и внимательно относитесь к настройкам клиентов.
Лайфхак 2. Нюансы синтаксиса иногда дают кратный прирост производительности
Давайте снова затронем тематику Arenadata DB, а точнее — нюансы в работе с партицированными таблицами. Дело в том, что Arenadata DB часто используют в качестве обработчика запросов по парадигме ELT, а значит, речь идет о работе с миллионами строк. В этом случае применяется принцип партицирования (разделения на секции) таблиц. Такой подход позволяет сканировать только нужные партиции и ускорять запросы.
Но много кто не знает о том, что синтаксис этой базы данных позволяет использовать свойства PARTITION ELIMINATION в функциях VOLATILE но не «в лоб» — данный подход работает, но нужно немного пошаманить. То есть вы вроде бы задаете отбрасывание ненужных партиций, но на практике этого не происходит.
В этом примере две функции выбирают данные на определенную дату. В одной запрос выполняется напрямую, а в другой — обёрнут в EXECUTE. Первая сканирует все партиции, вторая — только нужные. Разница в производительности получается просто огромной!
Мораль. Если вы постоянно работаете с какой-то определенной СУБД или хранилищем, собирайте лайфхаки о том, как она себя ведет. Мелкие нюансы и неожиданные приемы могут дать кратный прирост производительности.
Лайфхак 3. Заказчик может сам не знать о своих процессах
Еще один занятный пример из банковского сектора доказывает, что работа с финансовыми данными полна сюрпризов. Мы готовили отчёт с историей начислений по кредитам. Сумма долга в нем вместе со ставкой пени за каждый день должны давать нарастающий итог. Но тестирование показало, что в какой-то момент долг перестал расти.
На анализ этой ситуации была потрачена масса времени — были проверены схемы начислений, скрипты и так далее. А в итоге выяснилось, что ставка пени «превратилась» из 0,5% в 0% по заявке менеджера. Клиент просто пришёл в банк и попросил больше не начислять пени на просрочку, а банк пошел ему навстречу.
Мораль. Когда что-то начисляется не так, особенно в сфере бухгалтерии, и проблема не видна сразу, попробуйте задать вопрос бизнес-пользователям. Может быть, все это «не баг, а фича». Работа с банковскими данными — тема драйвовая, ведь они максимально приближены к реальной жизни, а значит разработчику все равно придется глубоко погружаться в бизнес-процессы.
Лайфхак 4. Когда пользователей «больше одного» — позаботьтесь о блокировках
Когда пользователи работают с одной и той же СУБД, необходимо сразу продумать механизм конкурентного доступа. Например, на одном проекте, где внедрялась Arenadata DB, пользователи днём и ночью гоняли аналитику, ETL-загрузки также шли круглосуточно. В итоге две активные группы одновременно работали с одними и теми же таблицами.
Для того, чтобы быстро вставлять данные в партицированные таблицы в Arenadata DB можно использовать EXCHANGE PARTITION. Но этот метод требует эксклюзивной блокировки: в момент выполнения операции доступ к таблице получает только один пользователь, а все остальные будут заблокированы и перейдут в состояние ожидания до её завершения.
При этом если TRG пользователи читают длительными запросами, ALTER TABLE при обмене партициями встаёт в WAIT, следующие запросы на чтение также встают в очередь. В итоге TRG блокируется и становится недоступной вообще никому.
Мораль: Если к таблице приходит запрос ALTER TABLE, нужно настроить проверку, нет ли в этот момент других активных запросов. И если они есть, просто правильно настроить очередность выполнения задач.
Лайфхак 5. Мигрировать данные нужно аккуратно
Еще один показательный пример появился в мире Arenadata. Сегодня все чаще происходит миграция КХД на Greenplum. Так же поступили и в одном банке. Заказчики решили переместить всё хранилище, но при разработке витрин для отчётов столкнулись с нехваткой данных. Клиент, сменивший фамилию, стал отображаться только в «финальной» редакции.
Оказалось, что при миграции история фамилий была отброшена — просто никто не вспомнил про эту особенность старого хранилища. В этом конкретном случае перезагружать данные никто не стал, все просто смирились. Но в некоторых ситуациях подобные «неточности» могут оказаться критичными для бизнеса или клиентов.
Мораль: Нельзя «с лёгкой руки» отбрасывать данные при миграции. Если кажется, что какие-то данные не понадобятся в новом хранилище, нужно еще раз проверить, все ли было учтено при подготовке и проанализировать требования пользователей.
Лайфхак 6. Очень аккуратно работайте в проде
И последняя на сегодня история из практики разработки ETL. На молодой системе (один контур = разработка и прод) уже был создан MVP, и пользователи работали в системе. Вдруг у них начали пропадать данные. Оказалось, что манипуляции, проводимые разработчиками, влияли и на реальные таблицы.
Типовой процесс загрузки новых данных выглядел следующим образом:
И все было бы хорошо, но для FULL-загрузок TRUNCATE применяется и к TRG. А при инкрементальной загрузке TRUNCATE стирает на TRG все накопленные данные.
Разработчик применил TRUNCATE и, так как всеми загрузками управлял фреймворк, команда «улетела» во все таблицы. Данные из них очень быстро «почистились», и сотрудник казалось бы не виноват…. К счастью, в той ситуации спас бэкап, сделанный накануне.
Мораль. Бэкап — это мастхэв! И вообще в проде лучше не вести разработку, так как всех нюансов, которые могут всплыть, не предусмотреть.
Вместо заключения
Эти шесть историй — только небольшая часть опыта, который мы получили за прошедшие годы создания разнообразных хранилищ данных. Каждый из них в свое время стал для нашей команды уроком. А учитывая, что иногда ошибки стоят заказчикам дорого, и не всегда решения удается найти быстро, нужно приложить максимум усилий, чтобы научиться на имеющемся опыте, своем или чужом.
Внедрение СУБД и построение хранилищ — это всегда сочетание инженерии, бизнес-логики и человеческого фактора. За прошедшие годы мы пришли к тому, что стали совмещать погружение в реальные процессы и глубокую экспертизу по тем СУБД, с которыми мы работаем, с глубоким инженерным подходом, который учитывает эти и многие другие ноу-хау, найденные на различных проектах. Я надеюсь, что эти примеры окажутся вам полезными в работе и помогут избежать некоторых обидных ошибок. Все-таки, опираться на чужой опыт всегда выгоднее!