Раньше мы говорили о том, какие навыки в Excel наиболее востребованы работодателями. Сегодня – об SQL в аспекте анализа данных.
И это сильно отличается от IT-разработки – где нужны, например, select по ID и вывод всех комментариев на стене, offset и прочие инструменты крайне ограниченного использования данных. Если ваша профессия связана с анализом данных – вам обычно нужны все данные, которые есть в различных разрезах и агрегатах, что накладывает множество ограничений на то, как используется SQL. Язык один, а цель его использования (по сравнению с DBA и разработчиками) совсем иная. Проблема не только в том, что датацентричные запросы в базу строятся по-другому, например, для «тяжелых» запросов в SQL-строке делаются искусственные таблицы с помощью конструкции values(), не используются distinct, offset и проч. Проблема в том, что для того чтобы делать выборки, вам нужно делать 20-30 вложенных Join’ов. Одна невнимательность в группировке или несоответствие ожидаемого количества строк (их уникальности) может дать ошибку на порядок в агрегате, при этом того, кто может проверить качество вашего запроса, в организации может просто не быть.
На собеседовании обычно предлагают довольно простые задачи. Нужно знать, чем Left Join отличается от Right Join, а Inner Join – от Cross Join (синтаксис последнего, правда, поддерживают не все БД), что такое order by, limit, select distinct и пр. Часто работодатели (например, в среднего размера банках) хотят, чтобы вы погрузились в их legacy, но перед этим проверяют, соответствуете ли вы хотя бы минимально тому, на что претендуете. Это базовые элементы языка, очевидные для всех, кто пользуется SQL и даже Excel. Если речь чисто об аналитической должности, то важно владеть оператором select и вложенными конструкциями. Следующая ступень – оконные функции и конструкция row() over(). В теории она осваивается довольно быстро, и на Хабре, да и в других местах, есть полезные туториалы.
А вот чтобы стать незаменимым, вам нужны две вещи.
1. Станьте «собственником данных».
В больших организациях мало кто в курсе, что именно хранится в базах. Звучит странно, но это так. Разработчики не помнят, бизнес-пользователи не знают. Здесь на первое место выходит чистота данных, а вернее ваше умение за счет детального понимания структуры БД и SQL-навыков выдать наиболее адекватную «версию правды», точнее даже просто «правду».
Попробуйте создать улучшенную версию той структуры базы, которой вы пользуетесь, можно просто на локальной машине. Это потребует от вас знания того, как создаются таблицы, какие есть констрейнты на них, как работают ключи и уникальность. Это работа, смежная с профессией DBA, но она позволит вам гораздо лучше узнать ваши данные, с которыми вы работаете каждый день, и разобраться с подкапотьем самой базы.
2. Конструируйте сложные запросы максимально просто.
Когда мы работали над архитектурой нашего продукта BI Wild, который в риал-тайме должен считать обновление цен на весь ассортимент товаров исходя из скользящих средних за динамический временной горизонт, мы решили – «пусть код будет большим и грязным, но данные будут без ошибок». Что это значит? Мы отставили в сторону разработческий перфекционизм и сосредоточились на том, чтобы сложные многошаговые вычисления сошлись с Excel-прототипами. Например, одна из хранимых процедур в бэк-энд расчетах заняла у нас несколько тысяч строк на SQL. Так много – потому что мы максимально упростили исходные селекты за счет объема кода, где-то повторяясь, а где-то выбирая слишком много данных. Но такой подход оправдан для отлавливания ошибок и несоответствий, особенно когда агрегаций много.
Поэтому, возможно, вам будет полезен наш опыт – начать запрос не с группировок, а с максимального количества строк, который легко проверить, выгружая результат в csv или Excel.
Группировать этот понятный результат будет гораздо легче в плане соответствия результатов ожиданиям.
В видео – наглядный пример данного подхода: