Блиииин… как круто! Всегда думал, что пока не познаешь SQL, Python, статистику, алгоритмы …. нечего даже соваться на должность продуктового аналитика. А тут человек с опытом говорит, что что-то не знать или забывать это нормально. Я прям заряжен после этого видео. Большое спасибо 🙏🏻
Это реально крутой совет, помню как устраивался аналитиком после sql-ex и реально я знал только синтаксис SQL, а не его практическое применение. На 9:30 решение не только извращённое, оно ещё и по производительности плохое - 2 раз в таблицу нужно ходить. Но это скорее разрабам полезно знать, аналитикам пофиг)) Благодарю за видео! Новичкам буду рекомендовать этот сайт, после 20-30 задач на sql-ex
У меня никогда в основной работе не было задачи оптимизировать запросы по производительности. Поэтому какой костыль написал и нормально))) Но это действительно может быть важно - хорошее замечание. Спасибо :)
Спасибо за выпуск, очень интересно! SQL начала изучать недавно, с удовольствием решаю всякие задачки) А вашу задачку попробовала решить так: если у нас только ежемесячная подписка (то есть отмена возможна только в течение месяца после покупки), то в новой таблице (t1) даты отмены привести к датам как из таблицы (t2) с датами appstore. А потом посмотреть какие данные из таблиц не пересекаются. Примерно так: with sub_1 as (select user_id, to_char(app_store_date, 'YYYY-MM-DD')::date as app_store_date from( SELECT event, created_at, user_id, lag(created_at) over (partition by user_id order by created_at asc)+interval '1 month' as app_store_date FROM public.t1) as sub where event='canceled') select t2.user_id, t2.date, sub_1.app_store_date, sub_1.user_id from public.t2 t2 full outer join sub_1 on t2.user_id=sub_1.user_id and t2.date=sub_1.app_store_date where countevent='canceled' and ((t2.user_id is NULL and t2.date is NULL) or (sub_1.user_id is NULL and sub_1.app_store_date is NULL))
Не знал про stratascratch, спасибо) Во втором задании все-таки решение через case выглядит элегантнее: меньше кода, проще читается, но это субъективно) Сразу о нем подумал, еще до открытия решений) И без форматирования кода сложновато читается в моментах как на 17:18, например. Без отступов всё превращается в кашу, особенно новичкам может быть сложно понять такой код.
Спасибо за комментарий! Да, по разному можно решить, я если есть возможность лучше лишний раз заджойню, хотя может быть ресурсозатратно. Про форматирование да, это точно! Учту
Большое спасибо за выпуск! как раз то что я искал последнее время. Я учусь на Системного аналитика на курсах sk**********(знаю знаю это никому не нужно итд. мне так удобно) сейчас пытаюсь проглотить книгу по SQL от Алексанрова вы вроде еще в каком то видео советовали одну книгу , но я забыл в каком. Пытался решать задачки сам, но мне там так на сували, что я обратился к литературе, надеюсь поможет, смотрю ваши видео по нескольку раз очень интересно. По аналитике их к сожалению не много интересных от других тоарищей. У меня фарм. образование , хочу стать аналитиком в фарм индустрии надеюсь потяну, честно, для гуманитария это непросто но профессия жуть как интересная очень расширяет рамки познаваемого. Ваши видео очень помогли с мотивацией, не бросайте! Анализирую что 100к подписчиков у вас будет
Спасибо большое за такое комментарий! И удачи с обучением. В будущем обязательно будет больше видео про аналитику и разбор основных понятий/инструментов и задач. Рад, что видео полезны :)
Последняя задача непонятна: "Хорошо ли, для всех ли пользователей приходят отмены". Что значит хорошо, а что значит плохо? Как они могут не приходить и каким образом это можно отловить?
@@ivani3237 да, я уже глянул гайдлайн по собеседованимя, действительно спрашивают. Когда проводишь интервью у обычных SDE не особо знаешь, что там у других направлений :-)
Оконные функции это полный капец и мозговыверт! Абсолютно непонятный синтаксис и логика. В вот заджоинить таблицу с собой и разницу дат указать в условии джоин очевидное решение как по мне. Интересно, какой вариант быстрее
На первый взгляд именно так и кажется, но... как всегда есть нюансы. Во первых, синтаксис оконных функций только на первый взгляд кажется непонятным. После того как вы нагуглите где нибудь картинку схематично показывающую смысл определения окна поверх вашей выборки-все резко прояснится. Во вторых, использование концепции окна позволяет избежать избыточной выборки данных. Когда вы делаете JOINT-ы даже той самой таблицы на себя же саму - сервер по факту извлекает и повторно обрабатывает данные, шарит по ключам, индексам, выполняет сравнения и сопоставления условий в ON секции. Попробуйте выполнить EXPLAIN для вашего сложносоставного запроса и посмотреть что по факту делает сервер чтобы его обработать. При использовании оконных функций - данные извлекаются только один раз, при первом считывании таблицы, а оконные функции манипулируют все тем же набором данных, просто "тасуют" его так, как вы определите в условиях разбивки на фреймы и правилах упорядочивания внутри окна. Т.е. вы избавляете сервер от лишних операций выборки и соответственно экономите ресурсы. Ну и еще, эти функции позволяют например легко вычислить разницу между какими то значениями, переместив логику предварительной обработки данных на сторону сервера, это может быть критично для систем где высока стоимость пересылки данных, или их последующей обработки на стороне приложения(например написанного на "тяжелом" скриптовом языке который работает медленно, и неэффективно расходует память для хранения переменных). В этих случаях обычно становится выгодно максимально предварительно обработать данные уже на этапе SQL запроса, чтобы получить компактную "выжимку" именно тех данных которые нужны вашему приложению, а не извлекать вагон и тележку значений, гонять их по сети, а потом их обрабатывать в приложении порождая кучу объектов и тратя под это память.
Автор конечно странный, оценивать запросы с точки зрения "красивости". Как по мне единственный правильный критерий - скорость выполнения. Толку от красивости , если он выполняется в разы дольше "некрасивого"
Ну вот когда в собственном же проекте вернешься к супер-оптимальному монстр-запросу, и, побившись об него часик-другой, вскинешь руки к небу и спросишь, кто же тебе "в штаны насрал" - поймешь, какой толк от "красивости".
@@АндрейУшаков-ж9м когда у тебя несколько тысяч юзеров и каждый хочет ,чтобы запросы летали , то глубоко наплевать на красивость. а для читабельности запроса есть такая хрень как комментарии. нормально закомментированный код с документацией может быть любой сложности.
Ресурс интересный и полезный, но есть замечание по первой задаче от амазона, запрос провалился, но решение не верное. В концовке должно быть select distinct user_id from preptable where next_purchase_at-created_at
О, решение задач! То, что нужно. Спасибо за видео!
Блиииин… как круто! Всегда думал, что пока не познаешь SQL, Python, статистику, алгоритмы …. нечего даже соваться на должность продуктового аналитика. А тут человек с опытом говорит, что что-то не знать или забывать это нормально. Я прям заряжен после этого видео. Большое спасибо 🙏🏻
Так забыть можно, но совсем не знать нельзя, а знать надо очень хорошо
@@freedomtv2295 согласен
Не знаю у кого как, мне хватает select * чтобы потом зафильтровать данные в query и запихать их в pivot
Но изучить питон хочется, да
Это реально крутой совет, помню как устраивался аналитиком после sql-ex и реально я знал только синтаксис SQL, а не его практическое применение.
На 9:30 решение не только извращённое, оно ещё и по производительности плохое - 2 раз в таблицу нужно ходить. Но это скорее разрабам полезно знать, аналитикам пофиг))
Благодарю за видео! Новичкам буду рекомендовать этот сайт, после 20-30 задач на sql-ex
У меня никогда в основной работе не было задачи оптимизировать запросы по производительности. Поэтому какой костыль написал и нормально))) Но это действительно может быть важно - хорошее замечание. Спасибо :)
Андрей, спасибо, смотрю твои видосы с удовольствием. Так доходчиво и по-доброму)
Спасибо огромное. Очень интересно . Можешь продолжить такие разборы делать 🙏👋🏿👍👏
Спасибо за выпуск, очень интересно!
SQL начала изучать недавно, с удовольствием решаю всякие задачки)
А вашу задачку попробовала решить так:
если у нас только ежемесячная подписка (то есть отмена возможна только в течение месяца после покупки), то в новой таблице (t1) даты отмены привести к датам как из таблицы (t2) с датами appstore. А потом посмотреть какие данные из таблиц не пересекаются. Примерно так:
with sub_1 as
(select
user_id,
to_char(app_store_date, 'YYYY-MM-DD')::date as app_store_date
from(
SELECT event, created_at, user_id,
lag(created_at) over (partition by user_id order by created_at asc)+interval '1 month' as app_store_date
FROM public.t1) as sub
where event='canceled')
select
t2.user_id,
t2.date,
sub_1.app_store_date,
sub_1.user_id
from public.t2 t2 full outer join sub_1 on t2.user_id=sub_1.user_id and t2.date=sub_1.app_store_date
where countevent='canceled' and ((t2.user_id is NULL and t2.date is NULL) or (sub_1.user_id is NULL and sub_1.app_store_date is NULL))
Спасибо за видео! Доступно и понятно.
Спасибо вам за комментарий!)
Не знал про stratascratch, спасибо)
Во втором задании все-таки решение через case выглядит элегантнее: меньше кода, проще читается, но это субъективно) Сразу о нем подумал, еще до открытия решений)
И без форматирования кода сложновато читается в моментах как на 17:18, например. Без отступов всё превращается в кашу, особенно новичкам может быть сложно понять такой код.
Спасибо за комментарий! Да, по разному можно решить, я если есть возможность лучше лишний раз заджойню, хотя может быть ресурсозатратно. Про форматирование да, это точно! Учту
Крутой канал. Сейчас увидел в ТГ ссылку, сразу подписался! Тоже хочется стать продуктовым аналитиком
Спасибо за комментарий!) И удачи в освоении профессии :)
Отличные реккомендации, сайты классные! Спасибо!
Очень крутой формат! Спасибо!
самое полезное видео на всем канале, ладно, одно из)
Очень полезные видео снимаешь 👍 Спасибо ☺️
Было бы здорово, если бы разбирались задачи с собеседований по статистике
Обязательно будет! И по терверу тоже разбор будет
Отличное видео! Спасибо
Спасибо за видео, хотелось бы побольше подобных с решениями задач!
Спасибо за Ваш труд
Даешь, больше SQL!!!
Даже очень круто, где-то бы поднатаскаться по SQL, и поиску в массиве и сортировках
Я человек простой. Вижу новое видео от Андрея - ставлю лайк
Спасибо Timo
Только начинаю
Спасибо за труд!
Лайк и подписка прибыли! )) успеха!
Очень полезно!
Подсяду на Ваши видосы, полезно
Рубашка огонь, сам на ex тренируюсь
Большое спасибо за выпуск! как раз то что я искал последнее время. Я учусь на Системного аналитика на курсах sk**********(знаю знаю это никому не нужно итд. мне так удобно) сейчас пытаюсь проглотить книгу по SQL от Алексанрова вы вроде еще в каком то видео советовали одну книгу , но я забыл в каком. Пытался решать задачки сам, но мне там так на сували, что я обратился к литературе, надеюсь поможет, смотрю ваши видео по нескольку раз очень интересно. По аналитике их к сожалению не много интересных от других тоарищей. У меня фарм. образование , хочу стать аналитиком в фарм индустрии надеюсь потяну, честно, для гуманитария это непросто но профессия жуть как интересная очень расширяет рамки познаваемого. Ваши видео очень помогли с мотивацией, не бросайте! Анализирую что 100к подписчиков у вас будет
Спасибо большое за такое комментарий! И удачи с обучением. В будущем обязательно будет больше видео про аналитику и разбор основных понятий/инструментов и задач. Рад, что видео полезны :)
@@Noukash было бы круто, я буду очень ждать
Спасибо!
системно, подробно, интересно расписаны выпуски
лайк+коммент+подписка
желаю тебе как можно скорее стать продактом!
Спасибо огромное за комментарий и пожелание :)
Интересно, но я так и не понял, зачем в запросе нижнее подчеркивание...?
Самая простая функция по датам DATEDIFF, почему вы ее не используете, вычитание это ненадежно
Спасибо за разбор!
Автор сказал что она не работает в этом диалект где тренажёр
Как я понимаю на StrataScratch уже нельзя проверять ответы без подписки?
Кстати, не во всех диалектах можно писать Group by 1, 2. В кликхаусе, например, нельзя, в вертике можно
Спасибо за комментарий! Не знал такой особенности
Последняя задача непонятна: "Хорошо ли, для всех ли пользователей приходят отмены". Что значит хорошо, а что значит плохо? Как они могут не приходить и каким образом это можно отловить?
не учитываешь версии MS SQL... приходиться поддерживать старые верси в которых нет WITH, OVER etc.... поэтому есть только JOIN-s
Diff, sub_date, date_sub?
На какие позиции фб/Амазон спрашивает sql? Ни разу такого не встречал
На аналитические позиции. Все что связано с data science, product analytics
@@Noukash понятно, спасибо. Не встречал людей на этих позициях, их кажется мало очень. В соседних командах таких нет.
ну на дата инженера 100% надо знать хорошо sql ..
@@ivani3237 да, я уже глянул гайдлайн по собеседованимя, действительно спрашивают. Когда проводишь интервью у обычных SDE не особо знаешь, что там у других направлений :-)
Некоторые пользователи пишут замудреные запросы, которые быстрее отрабатываются.
Аналитиков просят писать оптимизированные запросы?)))
Такой сайт для Python есть ?
Да, там есть задачи и для python :)
@@Noukash можно показать, задачки для каждого уровня, интересно даже посмотреть какую задачу на junior позицию в собеседованиях
Канкел😂
Спасибо за видео и новый ресурс!
Но за group by 1,2 дизреспект. Крайне неудобная штука для будущего легаси.
Оконные функции это полный капец и мозговыверт! Абсолютно непонятный синтаксис и логика.
В вот заджоинить таблицу с собой и разницу дат указать в условии джоин очевидное решение как по мне. Интересно, какой вариант быстрее
На первый взгляд именно так и кажется, но... как всегда есть нюансы. Во первых, синтаксис оконных функций только на первый взгляд кажется непонятным. После того как вы нагуглите где нибудь картинку схематично показывающую смысл определения окна поверх вашей выборки-все резко прояснится. Во вторых, использование концепции окна позволяет избежать избыточной выборки данных. Когда вы делаете JOINT-ы даже той самой таблицы на себя же саму - сервер по факту извлекает и повторно обрабатывает данные, шарит по ключам, индексам, выполняет сравнения и сопоставления условий в ON секции. Попробуйте выполнить EXPLAIN для вашего сложносоставного запроса и посмотреть что по факту делает сервер чтобы его обработать. При использовании оконных функций - данные извлекаются только один раз, при первом считывании таблицы, а оконные функции манипулируют все тем же набором данных, просто "тасуют" его так, как вы определите в условиях разбивки на фреймы и правилах упорядочивания внутри окна. Т.е. вы избавляете сервер от лишних операций выборки и соответственно экономите ресурсы. Ну и еще, эти функции позволяют например легко вычислить разницу между какими то значениями, переместив логику предварительной обработки данных на сторону сервера, это может быть критично для систем где высока стоимость пересылки данных, или их последующей обработки на стороне приложения(например написанного на "тяжелом" скриптовом языке который работает медленно, и неэффективно расходует память для хранения переменных). В этих случаях обычно становится выгодно максимально предварительно обработать данные уже на этапе SQL запроса, чтобы получить компактную "выжимку" именно тех данных которые нужны вашему приложению, а не извлекать вагон и тележку значений, гонять их по сети, а потом их обрабатывать в приложении порождая кучу объектов и тратя под это память.
Кстати, join саму с собой - это чуть ли не единственный вариант решить такую задачу запросом 1С, где в принципе нет оконных функций.
Автор конечно странный, оценивать запросы с точки зрения "красивости". Как по мне единственный правильный критерий - скорость выполнения. Толку от красивости , если он выполняется в разы дольше "некрасивого"
ну второй критерий - читабельность, при прочих равных надо писать так чтобы было понятно
Ну вот когда в собственном же проекте вернешься к супер-оптимальному монстр-запросу, и, побившись об него часик-другой, вскинешь руки к небу и спросишь, кто же тебе "в штаны насрал" - поймешь, какой толк от "красивости".
@@АндрейУшаков-ж9м когда у тебя несколько тысяч юзеров и каждый хочет ,чтобы запросы летали , то глубоко наплевать на красивость. а для читабельности запроса есть такая хрень как комментарии. нормально закомментированный код с документацией может быть любой сложности.
Ресурс интересный и полезный, но есть замечание по первой задаче от амазона, запрос провалился, но решение не верное. В концовке должно быть
select distinct user_id from preptable where next_purchase_at-created_at