Как стать автором
Обновить

Лучшие вопросы средней сложности по SQL на собеседовании аналитика данных

Время на прочтение 14 мин
Количество просмотров 84K
Всего голосов 29: ↑27 и ↓2 +25
Комментарии 17

Комментарии 17

собеседовании аналитика данных
Что бы стать/быть Аналитиком данных достаточно быть DB разработчиком?
Ну, очевидно, он на SQL срезался, поэтому и решил уделить именно ему внимание.
interval '1 month'

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

Альтернативное решение с использованием оконной функции (более эффективное!):

А в оригинале плана запроса не было приложено? Болееэффективность оконных функций надо проверять перед продакшном.

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

Так это у DBA спросят, аналитик, по-хорошему, и доступа на их создание не должен иметь.

анализ планов запросов
EXPLAIN + головной мозг никто не отменял. В этом случае не надо быть DBA. Обычных разработчиков про такое всегда спрашивают, а иногда и аналитиков.
И тут я понял, что совсем не знаю SQL…
CONCATENTATE(STR(bin_label*5),
Ни гугл, ни я, не знаем функцию CONCATENTATE, но знаем функцию CONCAT. CONCATENATE (без T) — это функция в англоязычном Excel. Сразу видны «ноги» аналитика данных из ошибки оригинала)
Обратите внимание, что эту проблему можно решить также с помощью соединений LEFT или RIGHT.
Изначально речь в оригинале идет про решение на FULL. Из примерно тысячи ETL-джобов на работе только в 1-м используется RIGHT JOIN, во всех остальных LEFT/INNER. Не грузите голову тем, что не используется в production. Более того, некоторые СУБД налету, при выполнении, переписывают RIGHT на LEFT для целей оптимизации.

По большому счету, для того чтобы хорошо выглядеть на любом собеседовании достаточно:

  • уметь во все JOIN подчеркивая, что в работе используется только INNER и LEFT
  • уметь в подзапросы
  • уметь в оконные функции
  • писать простой код на ANSI SQL с комментариями не упарываясь в отдельные нотации и переусложнения

И вообще я бы рекомендовал, заканчивать разговор с теми кто настойчиво просит пояснить разницу между LEFT и RIGHT JOIN, либо написать код на листочке бумаги. Понимаю, что пока ты не разработчик, а аналитик данных — выбор небольшой и приходится на таких работодателей смотреть, но надо стремиться к лучшему.

В качестве тегов к статье переводу есть leetcode, однако авторы не упомянули, что там лишь небольшая часть упражнений доступна бесплатно. Как вариант — codewars, но про него я тоже не уверен.
Интересно, так ли уж востребованы решения подобных задач именно на SQL?
Мне кажется, что в реальной работе из-за постоянных смен постановок задач, эффективнее пользоваться более гибким языком, а из всего богатства возможностей SQL использовать лишь селекты с джоинами, и сортировку + группировку.
PS: к комментарию ниже: тот же Python.
а какие языки лучше подходят для отчетов чем sql?
Интересно, так ли уж востребованы решения подобных задач именно на SQL?
Пока ничего лучше не придумали для обращения к данным, хранящимся в строчных и колоночных БД (только на них делают DWH) — без SQL никуда. Python, конечно же более гибок и функционален, но сравните производительность в подобных задачах Python (любой иной язык) vs SQL и ответ Вам будет очевиден. Да и порог входа в SQL все-таки ниже.
Порог входа в SQL ниже, чем в Python? Весьма спорное утверждение. Нынче питону детей обучают.
Посоветуйте, пожалуйста, хорошие библиотеки на SQL для аналитики посерьезнее скользящего среднего. Например, те же MACD/Renko, или из другой области — та же кластеризация типа k-mean, mean-shift и т.д + построение графиков + вывод результатов в pdf/html?
Единственное что нашёл — встроенные функции регрессии/стандартного отклонения для PostgreSQL.
Вы путаете теплое (хранение данных и обращение к ним) с мягким (инструментарий Data Mining & Machine Learning). Как перестанете путать, перечитайте еще раз мой комментарий на который возразили.

PS: PG, как и любая строчная РСУБД, не лучший вариант для DWH и тем более для Data Mining. Гуглите нормальные колоночные СУБД. Вот встроенный ML-функционал любимой мной Вертики, который Вы искали. Понятно, что он беден, по сравнению с норм инструментами для DM&ML (R, Python). Поэтому каждой задаче — свой инструмент.
Я так и не понял, вы пытаетесь оспорить мой тезис: в реальной работе лучше пользоваться более гибким языком, а SQL использовать лишь для выборки данных. Или согласны с ним?
Видимо, не быть мне аналитиком :)
Я так и не понял
Для Вас оконные функции — колдунство из мира Data-Mining) А вообще — это стандартный функционал любой аналитической задачи на информации из БД. И конечно использование SQL намного предпочтительнее Python (любого иного языка) если такое использование возможно.
Видимо, не быть мне аналитиком :)
Заметьте, с этим никто не спорит)))
А колдовство оконных функций может выручить в случае,
если уже написана сотня-другая индикаторов на готовом SQL инструменте типа Vertica,
но поступает задача сделать всё то же самое не только по исходным данным, но и по их функции, которой в стандартном пакете нет, и на SQL это написать проблемно?
Как устроено у нас:

  • есть целый отдел простых смертных аналитиков данных, занимающимися задачами уровня, что Вы описали
  • есть же (именно в моем, BI-отделе разработчиков) ML-архитектор и ML-инженер, умеющие в машинное обучение и решающие задачи иного уровня

Потребности 1-х на 100% покрываются возможностями SQL самой Vertica (даже описанный Вами кейс — штатная ситуация, хотя Вам и сложно поверить:)

Вторые же, используют ТОЛЬКО SQL для подготовки данных, и ТОЛЬКО R/Python для формирования и тюнинга своих моделей, где юзают вариации градиентного бустинга, k-medoids и пр. новомодных ML-хреновин. Вы ведь разделяете подготовку данных и формирование гипотез? Если да, то вопросы должны бы уже исчерпаться)))
Зарегистрируйтесь на Хабре , чтобы оставить комментарий