В мире больших данных
245 subscribers
34 photos
5 files
54 links
Полезные заметки о системном анализе в мире больших данных. Если вам интересны Big Data, DWH, SQL и как навести порядок в данных — заглядывайте. Будет интересно и по делу.

Автор: @JuliaMur
加入频道
Иметь перед глазами шпаргалки-напоминалки и короткие конспекты порой очень удобно, особенно, если чем-то пользуетесь не на регулярной основе. Пользуйтесь 😎
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1🙏1
Forwarded from Инжиниринг Данных (Dmitry)
sql-for-data-analysis-cheat-sheet-a4.pdf
140.7 KB
SQL Cheatsheet:

- SQL Basics Cheat Sheet
- SQL for Data Analysis Cheat Sheet
- SQL Window Functions Cheat Sheet
- SQL JOIN Cheat Sheet

Вот если вы не знаете SQL или только начинаете учить, попробуйте просто выучить наизусть несколько примеров, и будет полегче
8
Разбираемся с дублями

Если вашу выборку нужно почистить от дублей, вы можете сделать это очень просто:


SELECT *
FROM your_table
QUALIFY ROW_NUMBER() OVER(PARTITION BY column_id ORDER BY column_dt DESC) = 1;


В результате получим в выводе только уникальные строки (вместо *, конечно же, указываем корректный список полей).

QUALIFY + ROW_NUMBER() = никаких лишних подзапросов 🙃

Недостаток: пока что работает не во всех СУБД 🥲

Если СУБД не поддерживает оператор QUALIFY, можем чистить так:

WITH cte AS (
SELECT *,
ROW_NUMBER() OVER (PARTITION BY column_id ORDER BY column_dt DESC) AS rn
FROM your_table
)
SELECT *
FROM cte
WHERE rn = 1;


P.S. Про сам QUALIFY я уже писала здесь.

#sql
Please open Telegram to view this post
VIEW IN TELEGRAM
👍43🔥2
Forwarded from Дашбордец
👍31🔥1💔1
Иногда приходится разбирать чужие sql-запросы и периодически сталкиваюсь с различными ошибками. Сегодня хочу рассказать о трёх наиболее распространённых.

Некорректная работа с NULL
Я уже много раз писала, NULL — не просто пустота, это неизвестность. Поэтому нельзя сравнивать с NULL в лоб. Запрос вам ошибку не выдаст, но отработает некорректно.


-- неправильно:
SELECT * FROM users WHERE age = NULL;
SELECT * FROM users WHERE age != NULL;

-- правильно:
SELECT * FROM users WHERE age IS NULL;
SELECT * FROM users WHERE age IS NOT NULL;


Также при подсчёте количества строк COUNT(column_name) пропустит все NULL-значения. Поэтому если нужно посчитать прям вообще всё используйте COUNT(*).


-- считает количество заполненных номеров:
SELECT COUNT(phone) FROM users;

-- считает все строки, в том числе с NULL:
SELECT COUNT(*) FROM users;


Больше про #null я писала в постах с соответствующим тегом) на собесах часто про это спрашивают, но уделить внимание теме, конечно же, стоит не только поэтому.

Неправильное использование оператора BETWEEN
Ещё часто вижу, как забывают об особеннстях BETWEEN, забывая, что он включает и верхнюю, и нижнюю границы диапазона. Это может привести к дублированию данных или их пропуску при последовательной выборке.


-- пример кода с ошибкой:
-- выборка за 1 марта о полю типа дата-время
SELECT * FROM orders WHERE order_dttm BETWEEN '2024-03-01' AND '2024-03-02';
-- Выборка за 2 марта
SELECT * FROM orders WHERE order_dttm BETWEEN '2024-03-02' AND '2024-03-03';


В этом примере заказы, созданные ровно в полночь 2 марта (2024-03-02 00:00:00), будут включены в обе выборки! Лучше использовать явные полуинтервалы:

-- правильно:
-- выборка за 1 марта
SELECT * FROM orders WHERE order_dttm >= '2024-03-01' AND order_dttm < '2024-03-02';
-- выборка за 2 марта
SELECT * FROM orders WHERE order_dttm >= '2024-03-02' AND order_dttm < '2024-03-03';


Но если сильно хочется BETWEEN, то:

-- выборка за 1 марта
SELECT * FROM orders WHERE order_dttm BETWEEN '2024-03-01 00:00:00' AND '2024-03-01 23:59:59';
-- выборка за 2 марта
SELECT * FROM orders WHERE order_dttm BETWEEN '2024-03-01 00:00:00.000' AND '2024-03-01 23:59:59.999';


Да, про миллисекунды забывать не нужно, а то можно что-то потерять. И всё-таки проще использовать полуинтервалы)

Ошибки в логических операторах
Ещё часто забывают про приоритеты при использовании AND и OR в одном условии. В SQL сначала выполняются все AND, а затем уже OR.
Например, нужно найти все транзакции на сумму больше 100.000, которые имеют статус "completed" и при этом либо от премиум-пользователя, либо оплачены кредитной картой.

-- неправильно:
SELECT * FROM transactions
WHERE amount > 100000
AND status = 'completed'
AND user_type = 'premium' OR payment_method = 'credit_card'


По правилам SQL операторы AND приоритетнее. Поэтому запрос интерпретируется так:

SELECT * FROM transactions
WHERE (status = 'completed' AND amount > 100000 AND user_type = 'premium')
OR (payment_method = 'credit_card')


То есть мы получим все завершённые транзакции премиум-пользователей с суммой больше 100000, плюс абсолютно все транзакции с кредитных карт (даже незавершённые и с маленькими суммами).

Так мы получим именно то, что хотели:

-- правильно:
SELECT * FROM transactions
WHERE status = 'completed'
AND amount > 100000
AND (user_type = 'premium' OR payment_method = 'credit_card')


В целом, проще лишний раз указать скобки, чем запутаться и получить ошибочный результат.

Кому-то кажется очевидным, но такие вещи, действительно, встречаются. А с какими ошибками в sql вы часто сталкиваетесь?

#sql
👍6🔥5
#мотивация

Учеба - это череда маленьких побед. Кажется, что все будет линейно, но большинство знает, что это провалы и восхождения, процесс крайне нестабильный. И когда ты подступаешься к очередной теме в SQL, Spark или любой другой в DE, ты думаешь "А как это понять, как выучить?"

И главная мысль в том, что учёба в области DE нужна постоянно. Это не покорение одной большой горы, а маленькие победы каждый день. Одна задача. Один новый паттерн, одно новое понимание.

Сегодня ты разобрался, что идет первым, WHERE или GROUP BY.
Завтра - написал нормальный JOIN с ROW_NUMBER().
Послезавтра - построил ETL в Spark, от источника до BI.

И всё это складывается (если постоянно практиковать).

Уже через какое-то время тебе говорят, что ты не просто хорошо пишешь код, а неплохо оптимизируешь запросы, иди ка подскажи!

🌱 Не пытайся обогнать всех. Просто расти каждый день по 1%. И так в любой области кстати: профессия, спорт, хобби.

Я сейчас вспоминаю python, решая каждый день по 10 задач. Беда в том, что знания быстро уходят, если их не применять. Поэтому иногда необходимо создавать для себя искусственный полигон.

👇 Расскажи, какую маленькую победу ты помнишь.
Из каждого угла на нас нападают с хард скиллами — везде требуют знания технологий, инструментов, методологий. Но давайте немного вспомним и про софт скиллы — те самые навыки, без которых все харды теряют половину своей силы.

Я начала читать книгу Фрэнка Сесно "Как узнать всё, что нужно, задавая правильные вопросы" — и в серии постов хотела бы делиться с вами короткими конспектами и личными выводами. Ведь в работе системного аналитика, да и дата инженера тоже (если он взаимодействует с бизнесом) умение правильно спрашивать, слушать и понимать услышанное очень важно.

Пару слов об авторе: Фрэнк Сесно — американский писатель, журналист, теле- и радиоведущий, лауреат премии "Эмми" и директор Школы СМИ и связей с общественностью Университета Джорджа Вашингтона. В своей книге он делится методами и приемами, как задавать вопросы так, чтобы получать действительно полезные и точные ответы — будь то в интервью, переговорах, на встрече с заказчиком или даже в обычной рабочей переписке.

Ставьте палец вверх, если эта тема вам интересна.

P.S. Параллельно (но чуть позже) подумываю взять "в конспект" и технические книжки, которые всё никак не дочитаю. Пока выбираю из старенькой, но всё ещё актуальной "Testing the Data Warehouse Practicum" и более свежей, но узконаправленной "Data Modeling with Snowflake".

#книги #сесно
1👍9🔥3
29 и 30 мая в Москве пройдет Aha!25 — техническая конференция о product science, продуктовой аналитике и эффективности бизнеса: 16 тематических потоков и более 1200 участников на одной площадке. Крутая возможность обзавестись классными знакомствами и понетворкаться.

На сцене — топ-эксперты из Т-Банка, Яндекса, Авито, OZON, Альфа-Банка и других крупнейших компаний Рунета и СНГ: Виктор Кантор (MLinside), Кевин Ханда (Uzum), Сергей Веренцов (EORA), а также профессора и кандидаты наук из ИТМО, РЭШ, Центрального университета.

Ключевые темы:
- Интеграция LLM, ML и AI в цифровые сервисы
- Современные подходы к A/B-тестированию
- Оцифровка пользовательского опыта
- Применение машинного обучения в управлении продуктом
- Математическое мышление и поведенческая экономика

Программа будет полезна как новичкам, так и экспертам.
Для себя уже присмотрела интересные темы 😎 например: "Как создать универсальный инструмент для работы с данными и автоматизировать аналитику" от ребят из Flocktory.

Где: МГУ, кластер «Ломоносов» (Раменский бульвар, 1).
Программа: http://ahaconf.ru/program

Купить оффлайн и онлайн билеты можно со скидкой 10% по промокоду: BDSA10.
1🔥1
Зачем спрашивать? Умные вопросы делают людей умнее
Фрэнка Сесно "Как узнать всё, что нужно, задавая правильные вопросы". Ч.1

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

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

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

Автор отмечает, что любопытство — это часть ДНК. И успешные люди умеют развивать его через вопросы и умение слушать. Здесь мне кажется идёт прямая связь любопытства и критического мышления — когда не всё принимаешь как факт и через вопросы пытаешься сделать "картинку" объемнее.

От себя добавлю, что считаю навык правильной постановки ключевым в ближайшие годы, учитывая развитие ИИ. Ведь чем точнее и осозненнее составлен промт, тем более качественный ответ мы получим в итоге. Хотя книга, конечно, не про составление промтов) написана она в 2017 году.

В следующей части разберем, что такое диагностические вопросы и зачем они нужны.

#книги #фрэнксесно
👍4
Занималась тут оптимизацией чужого запроса. И вот вроде бы знаешь базу и хочешь её применить, но оптимизатор всегда оказывается хитрее 🙂

Среди прочего, пыталась применить одно из главных правил оптимизации — predicate pushdown. Это когда мы поднимаем условия фильтрации как можно выше, чтобы заранее уменьшить объем данных. Так вот, вынесла в cte фильтрацию одной таблички (~2GB), а в другом cte уже шла работа с отфильтрованными данными — джойны и тп. Смотрю в план запроса и вижу фигу, что снежок (snowflake) всё равно сначала сканирует таблицу целиком, затем джойнит, и только после этого фильтрует 😵 причём аналогичный сценарий на другой, но бОльшей таблице (~в 8GB) отрабатывает как надо 🥲 Видимо, размер данных или внутренняя статистика влияют на решения cost-based оптимизатора.

Никаких инсайтов в этой заметке вам не дам, но в очередной раз убеждаюсь: важно уметь читать (и понимать) планы запросов и анализировать query profile. Не всегда логичные на первый взгляд шаги оптимизации работают как ожидается. И не только от СУБД к СУБД поведение может разительно отличаться, но и даже в рамках таблиц в одном хранилище. Экспериментируйте и тестируйте на реальных данных 🤖

P.S. Тем, кто хочет использовать для анализа планов гпт, всё же советую сначала самостоятельно научиться их читать, т.к. LLM всё ещё склонны к галлюцинациям. Как говорится: "на ИИ надейся, да сам не плошай".

#sql #snowflake
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥12
Как-то в одной из моих команд появился коллега, который крайне негативно относился к GIT в DE-практиках, считая это никому не нужным усложнением 👀 и "вообще я привык один работать".

Git — это распределённая система контроля версий (VCS), которая позволяет отслеживать изменения в файлах и совместно работать над проектами.

Помню, тогда меня это сильно удивило, так как всегда считала использование гита стандартом де-факто в любой разработке. Да что уж там говорить – даже при написании документации он пригождается. Когда только начинала работать SA, я даже онлайн-митап проводила для наших аналитиков — объясняла, зачем им гит в контексте написания sql-скриптов и как им пользоваться.

С тех пор, конечно, много воды утекло. Но хочется напомнить и здесь, что владение гитом – это, действительно, важный навык, который вам пригодится в реальной работе, а не просто собесы проходить. Даже если вдруг вы работаете в одиночку, git всё равно будет вашим другом. Откатиться к рабочей версии после неудачного эксперимента? Легко. Посмотреть, что вы меняли в SQL-скрипте три месяца назад? (ну это на тот случай, если вы не любитель писать доки). Без проблем. А уж когда дело доходит до командной работы — тут вообще без вариантов. В общем, если вы ещё не пользовались гитом, пора восполнить пробелы в знаниях.

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

Не реклама, рекомендация от души)
Please open Telegram to view this post
VIEW IN TELEGRAM
👍81
Меня дико бесят недокументированные данные! 🤬 А это, увы, встречается слишком часто. Злит, что пункт "документация" не входит в неотъемлемую часть разработки какого-либо продукта. И вот ты подцепляешься к базе какого-то нового используемого сервиса и видишь просто кучу табличек с 100+ столбцами без какого-либо намёка какие данные там лежат. Особенно "приятно", когда нет возможности пощупать сам сервис и поэкспериментировать с данными в UI. Садишься и пытаешься описать (читай — сделать чужую работу) всё это богатство, опираясь только на свою логику и здравый смысл.

Часто бывает, что задачи на интеграцию прилетают asap, и кажется, что тебе нужно просто загрузить данные, а там уж аналитики разберутся. Но терпеть не могу, когда в моём хранилище что-то лежит без описания 👿 поэтому в любом случае стараюсь заполнить метаданные по максимуму. Да, это занимает дополнительное время, но зато потом не приходится каждый раз заново разбираться в структуре и объяснять коллегам, что означает загадочное поле "fl_xyz_2".

Понимаю, что разработчики работают в условиях жёстких дедлайнов, но отсутствие доков — это техдолг, который рано или поздно аукнется. А сейчас, когда все активно используют ИИ, хорошие=правильные описания становятся ещё важнее, тем более когда мы говорим о сложных продуктах и запутанных взаимосвязях. Без доков даже самый умный ИИ будет строить уверенные предположения, которые чаще всего окажутся ошибочными. Опять же, разработчикам в эпоху ИИ накидать описания к полям и таблицам при наличии ТЗ к проекту и доступом к коду — вполне реально и быстро. Но пока это мне приходится использовать ИИ в паре с анализом, логикой и гаданием на кофейной гуще.

Когда-то я хотела стать техписом именно из-за того, что мне нравится всё описывать и структурировать, но решила, что совсем без технарской работы будет скучно 💻 а теперь совмещаю и то, и другое.

А вас какие боли при работе с данными? 🙃
Please open Telegram to view this post
VIEW IN TELEGRAM
😢5💯51
Work-life balance или как проходит это лето

В последние пару недель встречаю очень много постов про то, как лето проходит мимо, и вспоминаю свои такие же периоды в жизни. Но в этом году моё лето настолько в стиле life, что balance совсем не соблюдается 🤫 Весна выдалась горячей и я решила выдохнуть и никуда не спешить, наслаждаясь моментами жизни (ведь мы за этим с вами растём и работаем, правда?).

Моё замедление пришло через совершенно неожиданные вещи. Зимой мы переехали в квартиру побольше и к лету я решила чуть оживить балкон зеленью, а в итоге всерьез увлеклась комнатными растениями. Теперь каждое утро начинается с чашечки кофе и обхода владений 🪴 поливы, пересадки, изучение грунтов и горшков – миллион информации из совершенно другого мира. Вместе с этим и вся жизнь как будто замедлилась. Бэклог личных дел растёт, но крокодил не ловится, не растёт кокос.

Много лет я жила в страхе "не успеть" и с желанием "бежать-развиваться", чтобы догнать ребят из инфо-поля. Казалось, что если остановишься хоть на день — и всё, отстанешь навсегда. Но чем больше ты развиваешься, тем больше растёт и развивается твоё инфо-поле, и этой гонке нет конца. Мне кажется, что это путь к выгоранию, насколько бы интересно тебе не было.

Хотя, конечно, и у замедлания есть обратная сторона. Во-первых, к размеренности слишком легко привыкнуть и вот уже мозг начинает лениться и тяжелее въезжает даже в обычные рутинные процессы. Появляются ошибки, сама грешна. А во-вторых, порой из замедления сложно выйти без встряски. Но лично у меня чаще всего бывает наоборот. Наступает момент, когда устаёшь от размеренности и с новыми силами "врываешься" в любимые активные дела. И, как будто бы, жизнь показывает: позволяя себе перерывы, в итоге мы становимся только продуктивнее. В конце концов, что такое пара месяцев в рамках множества рабочих лет?

А как проходит ваше лето? Боитесь отстать от IT-гонки или позволяете себе отдых?

#life
Please open Telegram to view this post
VIEW IN TELEGRAM
👍52😎2