Pull to refresh

Comments 17

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

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

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

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

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

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

анализ планов запросов
EXPLAIN + головной мозг никто не отменял. В этом случае не надо быть DBA. Обычных разработчиков про такое всегда спрашивают, а иногда и аналитиков.
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-хреновин. Вы ведь разделяете подготовку данных и формирование гипотез? Если да, то вопросы должны бы уже исчерпаться)))
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Россия
Website
miran.ru
Employees
51–100 employees
Registered