От разработчиков до DevOps: почему всем айтишникам нужно знать SQL

SQL — это язык структурированных запросов, позволяющий хранить и обрабатывать записи в базах данных. Обычно он ассоциируется с аналитиками, непосредственно работающими с данными, но его используют и разработчики, и тестировщики, и DevOps-инженеры, и эксперты по кибербезопасности, и другие специалисты.

robot_dreams расспросил, для каких задач разные IT-специалисты применяют SQL в своей ежедневной работе и насколько глубокие знания этой технологии нужны для Junior-, Middle- и Senior-уровней. Для чего стоит изучать SQL именно вам и какому аспекту языка уделять больше внимания — разбираемся в этом материале.

Содержание:

• Backend-разработка
• Frontend-разработка
• Mobile-разработка
• Manual QA
• Automation QA
• DevOps
• SRE
• Кибербезопасность
• Бизнес-анализ
• Data Science / Machine Learning

Backend-разработка

Рассказывает Артем Верещака, Tech Lead в Bolt, лектор курса «Алгоритмы и структуры данных» в robot_dreams:

«Работа Backend-разработчиков всегда связана с базами данных: любое приложение имеет хранилище данных, с которым нужно взаимодействовать. Существуют хранилища, которые не используют SQL, но абсолютное большинство поддерживают именно эту технологию, поэтому без нее не обойтись.

С помощью SQL Backend-инженер может извлечь данные из базы данных, обновить, добавить — это базовые примеры ежедневных задач. Нередко на основе того же хранилища строят и базисный репортинг, аналитику, потому нужно уметь написать это на SQL.

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

Так что для Backend-разработчиков SQL входит в «базовый набор» навыков, которыми должны обладать все. Расписать требования для Junior-, Middle- и Senior-уровней достаточно сложно, ведь все зависит от хранимого проекта и типа данных. К примеру, я на своей первой работе писал много сложных SQL-запросов — у нас часть репортинга была на этом построена. Сейчас пишу гораздо более простые, так как на текущем проекте совсем другие подходы.

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

Frontend-разработка

Рассказывает Ольга Гнатенко, Data Science/Machine Learning Engineer в DataArt (ранее работала на позициях Frontend Developer и Business Analyst):

«Я считаю, что любому IT-специалисту нужно хорошо понимать основы Computer Science, базы данных и SQL, потому что это фундаментальные знания. Отсутствие понимания базовых принципов может замедлить работу, усложнить взаимодействие с командой или банально привести к неэффективным решениям — особенно там, где потом потребуется масштабирование.

Для Frontend-разработки основательные знания SQL могут не потребоваться. Но понимание того, как могут быть упорядочены данные в SQL- и NoSQL-базах, важно. Нужно понимать схему базы и какие данные представлены, какие связи существуют, чтобы иметь возможность договориться с Backend-инженером о компоновке данных и обработке.

На собеседованиях знания SQL обычно проверяют вместе с общей логикой и теорией Computer Science. Чаще такие вопросы задают Junior-специалистам. Что касается подробных знаний, я считаю, что для Frontend-инженера актуальнее будет владеть, например, запросами в GraphQL.

В реальной работе я нечасто использовала SQL — в среднем 2–3 раза в неделю. Скажем, иногда бывает полезным залезть в базу и сделать несколько запросов, чтобы понять, что реально происходит с данными, — это удобно в процессе поиска причин сложных багов. Например, прилетал баг, похожий на UI-проблему, но вызванный ошибками в данных или неверной сохранностью, или трансформацией данных. Тогда, чтобы направить баг дальше к реальному «адресату», полезно самому проверить, что там реально происходит с данными, что где лежит, в каком формате и т. д. Так что умение сконструировать Select умеренной сложности точно понадобится».

Mobile-разработка

Рассказывает Александр Мазуренко, Senior Android Developer в GlobalLogic, лектор курса Android-разработчик в robot_dreams:

«Для мобильной разработки базы данных используются минимально — для создания определенного кэша и офлайн-режима работы приложения.

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

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

Junior-специалистам будет полезно знать основные команды, Middle — разбираться в типах Join. Относительно Senior в мобильной разработке сложно сказать, ведь все-таки базы данных — это больше специфика Backend-разработчиков».

Manual QA

Рассказывает Сергей Сахненко, Lead QA Engineer в EPAM, лектор курса QA Manual в robot_dreams:

«Использование SQL зависит от типа проекта, есть ли такая необходимость, есть ли доступы в базу данных у тестировщиков и т. д. Например, сейчас я использую SQL довольно часто, но были проекты, где вообще не использовал.

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

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

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

Ожидание уровня знаний у Junior-, Middle- и Senior-тестировщиков:

• Junior — достаточно иметь базовые знания SQL для выполнения таких задач, как проверка данных в базе, вставка или обновление тестовых данных и проверка простых запросов. В основном это работа с оператором SELECT.
• Middle — понадобится умение формировать сложные запросы, способность находить и исправлять ошибки в запросах, производить сбор данных для тестирования, а также тестировать сохраненные процедуры и функции базы данных.
• Senior — ожидается, что такие специалисты обладают высокими навыками SQL и могут быть ответственны за оптимизацию запросов, проектирование тестовых данных, внедрение автоматизированных тестов на уровне базы данных и анализ результатов».

Automation QA

Рассказывает Максим Богун, Senior QA Automation Engineer:

«В автоматизации тестирования SQL используется для Backend-автотестов: сервисных или интеграционных. С помощью запроса в базу данных автотест проверяет, что значения там действительно верны.

Например, рассмотрим автотест, который проверяет Endpoint/checkout корзины онлайн-магазина. Наш тест должен проверить логику, в которой пользователь заказал 5 яблок по 10 грн/шт. со скидкой 10 %:

• Отправляем POST API запрос / checkout с данными, после которого в базе в поле «сумма заказа» должно быть значение 45 грн (50 – 10 % = 45).
• Далее наш тест делает SQL-запрос в базу и получает условный объект «заказ», где общая сумма составляет 0. Итак, есть баг. Очевидно, разработчик, писавший функционал корзины, при подсчете забыл учесть скидку.

Кстати, Manual QA может использовать аналогичный подход в White Box тестировании. Ситуация такая же, только заказ QA-инженер делает на сайте вручную, после чего с помощью специального инструмента выполняет SQL-запрос вроде SELECT * FROM checkout.cart WHERE id = 123456 и смотрит, чтобы у этого заказа сумма была 45.

Отже, для Backend-тестувальників знання SQL — обов’язкова навичка. Якщо ж вакансія AQA потребує тільки написання GUI-автотестів на умовному Selenium, то з SQL стикатися не доведеться. Проте все одно знання цієї технології буде плюсом. Вміння перевірити базу — чи вручну, чи автотестом — свідчить про глибший технічний рівень кандидата.

По уровням распределение такое:

• Junior AQA нужно понимать, что такое база данных вообще и как работает SQL. Дальше всегда можно научиться на примерах, которые есть в коде.
• Middle-кандидату стоит иметь базовые знания SQL: как подключиться к базе, какие есть способы (например, через connection string), как написать простой SELECT-запрос и т. д.
• Для Senior знание SQL обязательны — независимо от того, что требует вакансия».

Рассказывает Виктор Максименко, Senior QA Automation Engineer, AQA Manager в AB Soft:

«Сейчас я не использую в работе SQL. По моему опыту, на большинстве проектов мы взаимодействовали с продуктом либо через UI, либо через API.

Исключением из этого правила стала моя работа в Electric Cloud, где продуктом была CI/CD-система, которую клиенты инсталлировали на железо и подключали к базе данных (MySQL, MSSQL или Oracle). Соответственно, одним из этапов настройки тестового окружения было создание «свежей» базы данных, которую после окончания тестирования нужно было удалить. Также для некоторых тестов нужно было найти те или иные записи в базе. Самым сложным и интересным, что я там делал из SQL, было написание stored procedure для генерирования большого количества входных данных. Создание сотен тысяч записей через API потребовало бы часов, в то время как через SQL это занимало минуты.

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

Рассмотрим более подробно варианты использования SQL в автоматизации:

• Проверка состояния объектов системы напрямую через базу данных. Эта проверка более надежна по сравнению с API или UI, где результат операции может не соответствовать действительности. Например, UI показывает баннер Success или сервер возвращает код 201 Created, хотя объект в базе данных не сохранен. Вместе с тем схема базы данных может измениться (названия таблиц, полей, связи между таблицами и т. п.) и запросы нужно будет обновлять. API в этом смысле является контрактом, поэтому структура запросов и ответов более устоявшаяся. Поэтому для проверки данных я в основном использую именно API. Также для проверки данных в базе необходимо открыть доступ к подключению к хранилищу (что не всегда можно сделать по юридическим причинам) и настроить доступ на режим только для чтения.
• Генерация тестовых данных и подготовка окружения. С помощью генерирования дампа базы или ее отдельных таблиц и последующего развертывания этого дампа мы можем быстро приводить систему в ожидаемое состояние. Однако этот подход имеет все недостатки, описанные выше, которые становятся более явными. К примеру, при изменении схемы наш дамп станет неактуальным и его нужно будет либо обновлять, либо заменять на новый. В лучшем из вариантов развертывания неактуального дампа мы получим ошибку, в худшем — наши данные будут неполными (например, была добавлена ​​новая колонка в таблицу). В результате мы можем получить ложноотрицательный тест, исследование которого займет время (потому что программа выдает некорректный результат, хотя проблема не в ней, а в тестовых данных).
• База данных как хранилище тестовых данных. Такой подход применяется, например, при использовании пула аккаунтов несколькими потоками тестов при параллельном исполнении. В этом случае знание SQL требуется именно для разработки и использования базы данных. Стоит отметить, что разработка дополнительных инструментов для автоматизации требует затрат как на разработку, так и на дальнейшую поддержку.
• Тестирование базы данных. База данных является составной частью нашего продукта, которая также реализует бизнес-логику, поэтому ее тестирование имеет смысл. Вместе с тем в своем опыте я не сталкивался с этим видом тестирования, хотя иногда встречался с требованиями к автоматизаторам по умению тестирования базы данных. По-моему, эта область довольно специфична. Отдельно следует выделить, что, хотя в большинстве своем мы думаем о базах данных в контексте взаимодействия с серверным кодом, СУБД вроде SQLite могут использоваться непосредственно в клиентских приложениях, например, в приложениях Android.
• Прохождение собеседований. Здесь все просто. Часто вопросы по SQL используют для проверки эрудированности кандидата или качества подготовки к собеседованию. Лично я не спрашиваю у кандидатов о SQL, если им не нужно будет с ним работать. Однако советую повторить перед собеседованием, что такое SELECT, ORDER BY, GROUP BY, виды JOIN и чем они отличаются.

Таким образом, AQA-специалистам будет полезно знать SQL для общей эрудиции, но вероятность ее использования в условиях проекта достаточно низка. Даже для вариантов применения, описанных выше, запросы можно относительно легко загуглить или сгенерировать с помощью искусственного интеллекта. Плюс непосредственная работа с базами данных в большинстве своем не является вариантом использования системы, поэтому не тестируется.

Я встречал это требование в основном как вопрос в анкете на технических собеседованиях в крупных аутсорсах. Фактически, это одна из опций для решения проблем тестовых данных и проверки состояния объектов. Большее количество опций дает больше возможностей для выбора подходящего решения».

DevOps

Рассказывает Олег Заревич, DevOps-инженер:

«Реляционные базы данных используются практически в каждом проекте. С точки зрения DevOps-инженера работа больше заключается в поддержке именно сервера баз данных — создания, настройки, администрирования. В таких задачах я использую запросы SQL достаточно редко.

Но иногда бывает актуально проверить корректность выполненных задач (есть ли данные в таблице) либо добавить/обновить определенную запись в таблице. Например, переключить feature flag из одного состояния в другое. Для этого следует знать основные команды SQL DML: SELECT, INSERT, UPDATE, DELETE.

Также иногда приходится производить подчистку каких-то тестовых баз или удалять ненужные таблицы. Здесь используется уже другая часть SQL — DDL, и такие команды, как TRUNCATE и DROP.

Создавать новые таблицы на реальных проектах мне не приходилось. По крайней мере пока.

Хотя я не скажу, что мне часто приходится использовать SQL, но я считаю эти знания необходимыми для DevOps-инженеров. Для Junior-специалистов стоит знать, что такое SELECT*FROM. Специалисты уровня Senior должны знать не только запросы SQL, но и хорошо понимать CAP-теорему и какие Constraints бывают в таблицах».

SRE (Site Reliability Engineering)

Рассказывает Денис Васильев, Senior Site Reliability Engineer в GfK - An NIQ Company:

«99 % продуктов — это обработка данных, поэтому для SRE системы баз данных являются обязательной темой для изучения. Приведу несколько примеров использования SQL на личном опыте.

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

Это позволяет нам выполнять сложные запросы в базу данных, которые используются для анализа и визуализации данных. К примеру, нам как SRE важно обеспечить observability, когда мы имеем возможность определить тенденции и выявить проблемы, которые могут возникнуть в будущем. Например, динамику и топ-25 репозиториев, у которых появилось больше секретов за последнюю неделю и только по последним коммитам.

Система хранения данных хотя и использует отдельную базу данных под капотом, но не предоставляет возможности прямого доступа к ней — только через веб-интерфейс с фиксированным набором параметров, не подходящий для задач автоматизации. Но предоставляет API. Итак:

• Запрашиваем API и получаем raw-данные за определенный период в формате JSON.
• Преобразуем формат JSON в CSV.
• Инициализируем базу данных SQLite.
• Создаем таблицы и импортируем данные.
• Выполняем SQL-запросы в базу данных и получаем результат.

Три последних пункта требуют от инженера понимания принципов работы SQL и умения создавать структуру базы, писать и оптимизировать сложные запросы. Пример пайплайна и запросов.

Представим, что ваш продукт разработан с использованием целой группы больших и сложных баз данных Postgres в облаке. И как всегда каждую пятницу разработчики идут отдыхать, а вам прилетает какой-то траблшут. Вы открываете консоль и видите, что база данных после пятничного мержа отказывается запускаться. Что делать? Как понять, что произошло? Как восстановить работу базы? Иногда сами разработчики не могут ответить на это. Поэтому именно ваши уникальные знания со стороны инфраструктуры и основ SQL и баз данных помогут решить проблему. Иногда это будет просто восстановление из резервной копии, а иногда — долгий процесс анализа и восстановления данных.

Уровень знаний SQL, необходимый Junior-, Middle- и Senior-специалистам, зависит от конкретной роли и требований должности. Можно ориентироваться на следующие параметры:

Junior SRE:

• понимание основных понятий и принципов баз данных;
• способность создавать простые запросы SELECT для выборки данных из таблиц;
• знание основных операторов SQL: SELECT, INSERT, UPDATE и DELETE;
• понимание фильтрации данных посредством условных выражений (WHERE);
• способность объединять данные из нескольких таблиц с помощью JOIN-операторов.

Middle SRE:

• более глубокое понимание архитектуры базы данных и реляционной модели;
• умение создавать более сложные запросы, включая подзапросы и вложенные запросы;
• знание и использование агрегатных функций, таких как COUNT, SUM, AVG, MAX, MIN;
• понимание и использование индексов для улучшения производительности запросов;
• умение оптимизировать и управлять исполнением запросов с помощью планировщиков.

Senior SRE:

• глубокое понимание реляционных баз данных и опыт работы со сложными структурами данных;
• умение проектировать и оптимизировать схемы баз данных;
• знание и использование продвинутых возможностей SQL;
• опыт работы с высоконагруженными базами данных и оптимизацией производительности;
• умение делать анализ данных, создавать сложные запросы для отчетности и аналитики».

Полезная ссылка для изучения SQL — sqlbolt.com.

Кибербезопасность

Рассказывает Дмитрий Терещенко, Head of Information Security Department в Sigma Software:

«Большинство (99,9 %) Cyber ​​Security Analyst в своей работе не используют SQL.

Знания SQL могут пригодиться тем, кто работает в домене Application Security, например, для эксплуатации (или, наоборот, анализа) такой уязвимости, как SQL injection».

Бизнес-анализ

Рассказывает Ольга Гнатенко, Data Science / Machine Learning Engineer у DataArt (ранее работала на позициях Frontend Developer и Business Analyst):

«Я встречала два мнения о бизнес-аналитиках и степени их погружения в технические детали:

• BA не должен лезть в технические детали;
• или наоборот, BA должен хорошо знать данные и следить за порядком в проекте и требованиях.

Я склоняюсь ко второму варианту, особенно если проект большой, а знаний и квалификации бизнес-аналитика хватает.

Поэтому считаю, что бизнес-аналитик должен хорошо понимать принципы построения SQL- и NoSQL-баз данных, владеть SQL как минимум на уровне построения сложных SELECT-запросов, уметь делать разные агрегации и вычисления. А также знать типы данных, констрейнты, связи между таблицами. Для Senior-уровня я бы добавила необходимость понимания процессов ETL.

Зачем бизнес-аналитику эти знания и умения?

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

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

Итак, преимущества знания SQL для бизнес-аналитика — это возможность писать значительно лучшие и более устойчивые к изменениям требования, эффективно реагировать на изменения, вместе с клиентом изучать результаты использования программного продукта.

Я, как бизнес-аналитик, использовала SQL 3–4 раза в неделю в проекте, который был в активном девелопменте. Также у меня был кейс менторства по BA-направлению, когда я помогла уже опытной коллеге разобраться с нюансами SQL и построения баз данных — это ей очень помогло, когда пришли следующие требования от клиента.

Кстати, можно выделить также отдельные специализации в рамках бизнес-анализа, требующие досконального знания SQL — это Data Business Analyst (собирает требования именно к данным) и System Analyst (занимается требованиями к системам)».

Data Science / Machine Learning

Рассказывает Ольга Гнатенко, Data Science / Machine Learning Engineer в DataArt:

«В Data Science SQL может потребоваться на очень высоком уровне или не потребоваться вообще — зависит от проекта. Лично я в последнее время почти не использую в работе SQL, потому что процессингом данных занимается отдельная команда.

Но в большинстве своем для этой специальности нужны хорошие навыки SQL, причем не только SELECT, но и DDL/DML, умение «чистить» данные, трансформировать их под свои потребности. Кроме того, очень часто может потребоваться работа с NoSQL-базами, а также облаком и данными в нем.

К тому же вопросы по этим темам часто встречаются на собеседованиях. Что касается требований работодателей, если посмотреть вакансии на DOU, на середину октября 2023 года SQL упоминается в 38 % вакансий Data Science Engineer (23 из 60)».