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

Автор: @JuliaMur
Download Telegram
GROUPING SETS для упрощения агрегации

Мы группируем данные десятки раз в день: по датам, категориям, клиентам или нескольким полям сразу. Но что, если нужно получить несколько уровней агрегации в одном результате? Объединять три разных запроса через UNION ALL? Писать вложенные подзапросы? Такой сценарий превращает простую задачу в головоломку с кучей повторяющегося кода 🔄

Теперь представьте: один запрос возвращает и детализацию, и промежуточные итоги, и общую сумму. И всё это без дублирования логики и потери производительности. Это не магия — это GROUP BY GROUPING SETS. Спойлер: после него вы вряд ли захотите возвращаться к старому подходу.

Синтаксис:

SELECT column1, column2, AGG_FUNC(column3) AS aggregate_result
FROM table_name
GROUP BY GROUPING SETS
(
(column1),
(column2),
(column1, column2),
() -- итоговая строка для всех данных
);


Итак, у нас есть таблица с заказами, и нужно вывести витрину продаж: по дням, категориям, дням и категориям, а также общие продажи.


| order_id | order_dt | category | price |
|----------|------------|-------------|-------|
| 1 | 2025-02-01 | Книги | 100 |
| 2 | 2025-02-01 | Книги | 200 |
| 3 | 2025-02-01 | Электроника | 700 |
| 4 | 2025-02-02 | Книги | 150 |
| 5 | 2025-02-02 | Электроника | 250 |
| 6 | 2025-02-02 | Электроника | 550 |


Запрос:

SELECT
order_dt,
category,
SUM(price) AS total_sum
FROM orders
GROUP BY GROUPING SETS
(
(order_dt, category), -- Группировка по дням и категориям
(order_dt), -- по дням
(category), -- по категориям
() -- Итоговая строка
);


Результат:

| order_dt | category | total_sum |
|------------|-------------|-----------|
| 2024-01-01 | Книги | 300 |
| 2024-01-01 | Электроника | 700 |
| 2024-01-02 | Книги | 150 |
| 2024-01-02 | Электроника | 800 |
| 2024-01-01 | NULL | 1000 |
| 2024-01-02 | NULL | 950 |
| NULL | NULL | 1950 |
| NULL | Книги | 450 |
| NULL | Электроника | 1500 |


🔵Полные строки (order_dt и category заполнены) — детализированные данные.
🔵Строки с order_dt и NULL показывают суммы по каждому дню.
🔵Строки с category и NULL показывают суммы по каждой категории.
🔵Строка с двумя NULL — общая сумма.

Если нужно определить, какие строки являются результатом группировки, используйте функцию GROUPING(). Она возвращает 1 там, где значение агрегировано.

Пример:

SELECT
order_dt,
category,
SUM(price) AS total_sales,
GROUPING(order_dt) AS is_dt_agg,
GROUPING(category) AS is_cat_agg
FROM orders
GROUP BY GROUPING SETS
(
(order_dt), -- Группировка по дням
(category), -- Группировка по категориям
() -- Итоговая строка
);

| order_dt | category | total_sales | is_dt_agg | is_cat_agg |
|------------|------------|-------------|-----------|------------|
| 2024-01-01 | NULL | 1000 | 0 | 1 |
| 2024-01-02 | NULL | 950 | 0 | 1 |
| NULL | NULL | 1950 | 1 | 1 |
| NULL | Книги | 450 | 1 | 0 |
| NULL | Электроника| 1500 | 1 | 0 |


Почему GROUPING SETS лучше UNION ALL?
один запрос вместо нескольких
оптимизация выполнения — СУБД сканирует таблицу один раз и для каждой строки вычисляет все группировки параллельно
читабельность кода

поддерживаются не все диалекты SQL (но основные — PostgreSQL, Oracle, SQL Server, Snowflake, BigQuery — да)

GROUP BY GROUPING SETS полезен для отчетности и аналитических анализов, где нужны сводные данные разной детализации. Это инструмент работает:
🟢 удобно: меньше кода, меньше ошибок
🟢 быстро: один проход по данным
🟢 гибко: возможны любые комбинации группировок

#sql
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5👍3
Привет 👋 Живя за тысячи километров от «цивилизации», не хватает нетворкинга и свежего взгляда на дата-мир. Посты, подкасты, видео — всё это хорошо, но хочется живого общения.

Хочется узнать больше о вас, мои читатели. Расскажите о себе и вашем опыте. Как у вас строятся дата-пайплайны? С какими сложностями сталкиваетесь? Или, может, вы только начинаете свой путь в мире данных?

Моя текущая боль — интеграция с 1С, данные из которой падают в кафку в куче всяческих вариаций структур. И надо всё разложить по красоте, ничего не потеряв по пути и обложив проверками. Бесконечная вложенность объектов, непредсказуемые структуры, русские наименования сущностей... в общем, то ещё извращение 😏 А в жире уже ждет следующая пачка 1С на интеграцию. Вы как, дружите с 1С?) Делитесь опытом!
Please open Telegram to view this post
VIEW IN TELEGRAM
6💔1
SQL под капотом: как выполняются запросы

Знаете ли вы, что происходит под капотом СУБД, когда вы выполняете SQL-запрос? База данных запускает целый процесс, шаг за шагом превращая код в набор данных. Каждая команда проходит проверку, оптимизацию, выполнение, обработку и вывод результата. Давайте посмотрим на каждый из этапов:

1. Query Parsing (разбор запроса)
Сначала сервер проверяет, правильно ли написан запрос. Проводит так называемый синтаксический анализ. Ошиблись в запятой или перепутали порядок ключевых слов? Получите ошибку.

После синтаксического анализа начинается семантический разбор: существуют ли таблицы и колонки, есть ли у вас права на запрос? Если все ок, база строит parse tree.

Parse Tree — это иерархическое представление запроса, где каждый узел — отдельная операция (например, фильтр, join, сортировка). Это облегчает работу оптимизатора и позволяет строить разные планы выполнения.

2. Query Optimization (оптимизация запроса)
На этом этапе в работу вступает умный планировщик. Он оценивает различные стратегии выполнения запроса, чтобы определить наиболее эффективную и менее ресурсоёмкую. Оптимизаторы сильно отличаются от СУБД к СУБД, но, к примеру, в Snowflake он, действительно, умный и даже плохо написанный запрос в большинстве случаев "переписывает" оптимально самостоятельно (это, конечно, не значит что стоит писать запросы как попало 👿).

Оптимизатор, в зависимости от СУБД может проверять:
Как соединять таблицы — Nested Loop, Hash Join, Merge Join?
Как фильтровать и сортировать данные?
Использовать индексы или нет?

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

3. Query Execution (выполнение запроса)
После этого база данных начинает пошагово выполнять запрос, согласно выбранному плану.

Запросы могут выполняться через:
🔵 Table Scan — полный перебор строк в таблице (долго).
🔵 Index Seek — точечный поиск через индекс (быстро, но требует индекса).

4. Извлечение или изменение данных
Если наш запрос извлекает данные (SELECT - Data Query Language), база выбирает нужные строки из таблиц и формирует результат. Если же запрос изменяет данные (INSERT, MERGE, UPDATE или DELETE - Data Manipulation Language), информация в таблице обновляется, удаляется или дополняется.

5. Формирование результата
Когда SQL-движок собрал нужные строки, он финально формирует итоговый результат: сортирует, группирует, выполняет агрегатные вычисления. Однако часть агрегаций, особенно в запросах с GROUP BY, может выполняться еще на этапе извлечения данных, если движок решит, что это эффективнее. То есть это зависит от плана выполнения запроса и используемого метода обработки.

6. Результат
Когда всё готово, результат возвращается в клиентское приложение, которое уже отображает его пользователю.

Для SELECT-запросов, если данных много, они передаются частями, чтобы не перегружать память.
Некоторые базы поддерживают Lazy Execution — строки выгружаются только при необходимости.


Как видите, написанный запрос запускает целые механизмы внутри СУБД. Каждый этап играет свою роль: разбор проверяет синтаксис на ошибки, оптимизатор выбирает самый быстрый путь, выполнение шаг за шагом приводит к нужному результату, а передача данных гарантирует, что вы получите ответ в удобной форме, ничего не потеряв.

Не всегда имеет смысл знать, что происходит под капотом, но хотя бы верхнеуровневое понимание помогает нам самим работать эффективнее. Если что-то идет не так, вы будете знать, где искать проблему и как ее решить. Понимание происходящего — ключ к написанию быстрых и оптимизированных запросов.

#sql
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6👎21🤡1
Помню, что задолжала пост про инструменты в руках системного аналитика.

Но много думала об этом и выходит слишком скользкая тема) ведь главное — это не инструменты, а результат. А любой инструмент — это всего лишь путь к нему. Поэтому от компании к компании, да даже в рамках одной компании инструменты будут постоянно меняться.

Можно, конечно, поковырять всего понемногу из какой-нибудь таблички как на примере выше 😬, но сначала спросите себя "зачем". Быть в курсе трендов и быстро меняющегося мира данных — ок, знать всё обо всём без практической применимости — достижение уже спорное. Так или иначе, в работе вы будете погружаться в новые для вас инструменты и технологии.

Когда я приходила на свою первую работу без DWH бекграунда, то знала что такое airflow чисто теоретически из пары обзорных видео. Но жизнь заставила быстро разобраться что к чему. На текущей работе также пришлось моментально погружаться в Snowflake, про который каждый из коллег знал примерно столько же (так как зарождение DWH в компании началось с нас).

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

Возвращаясь к инструментам. Чем пользуюсь в работе ежедневно сейчас: snowflake, airflow, kafka, tfs, базы различных наших источников (MS SQL, PostgreSQL и прочее), а также множеством самописных фреймворков (в том числе etl), разработанных нашими инженерами, тестирую новые загрузки через питон+тетрадку, исследую сторонние апи через постман (или ту же тетрадку). Заглядываю в датахаб и табло. Периодически сталкиваюсь с чем-то новым. В прошлом месте инструментарий был совсем другой) например, был гораздо более плотный опыт взаимодействия с Oracle, Greenplum и ClickHouse. Какие-то популярные решения, типа dbt ещё не было возможности потрогать в бою) только в качестве личного "факультатива".

Так что инструменты приходят и уходят, а мозг остаётся с нами всегда 😀 наше лучшее вложение 🤑🤫

#системный_анализ
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8
Иметь перед глазами шпаргалки-напоминалки и короткие конспекты порой очень удобно, особенно, если чем-то пользуетесь не на регулярной основе. Пользуйтесь 😎
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).
Программа: https://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
👍3😎21