Довольно часто сталкиваюсь с вопросами о рынке труда ☝️
❓есть ли спрос на специалистов
❓какие сейчас зарплатные вилки
❓можно ли без опыта найти работу
❓сколько времени занимает трудоустройство

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

Сейчас исследование проводят NEWHR по рынку аналитиков, они собирают данные каждый год начиная с 2018!

Рынок каких аналитиков исследуют?
➤ Дата-аналитиков
➤ Продуктовых аналитиков
➤ BI-аналитиков
➤ Маркетинговых аналитиков
➤ Веб-аналитиков

Что исследуют?
👉 Зарплаты и их динамика. Спрашивают про вилки, а потом делятся результатами и корреляциями.
👉 Рейтинг работодателей для аналитиков
👉 Где работают аналитики, как работают (удалёнка/офис), какие планы на трудоустройство.
👉 Как меняется зона ответственности аналитиков.
👉 Как аналитики ищут работу и выбирают работодателя.

Как принять участие в исследовании?
⏩ Заполните 20-мин опросник

После заполнения опросника у вас будет возможность получить не только результаты исследования (они планируются в начале 2025 года пока соберут все данные и проанализируют), вы также получите полезные ссылки и материалы от аналитиков в отрасли 😎🔥

Увидел сегодня вакансию с пометкой о количестве активных пользователей и количестве дашбордов 1200+
Аж мурашки от таких цифр побежали 😨

В таких кейсах всегда интересно как компания реализовывает интеграцию такого количества отчетов в удобное пользование, есть ли data-каталоги, либо системы data governance/management. Иначе потеряется качество данных, одни и те же метрики будут считать на разных отчетах по разному, да и пользователям вообще может быть сложно найти нужный им отчет в таком количестве.

📍Кстати, в публикации вакансий я реализовал пересказ полного описания вакансии с помощью LLM, чтобы посты были более лаконичными. Получилось очень неплохо если сравнивать пересказ с полным описанием)

Data вакансии - https://t.me/data_vacancy

Data Mesh - вид организации аналитических хранилищ
В современном мире данных, где объемы информации растут экспоненциально, традиционные подходы к организации аналитических хранилищ могут оказаться недостаточно гибкими и масштабируемыми. Одним из инновационных решений этой проблемы является концепция Data Mesh.

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

В чем его особенность от других типов хранилищ?
📍Децентрализация: В отличие от традиционных централизованных хранилищ данных, Data Mesh распределяет ответственность за данные между различными командами, что позволяет более гибко и оперативно управлять данными.
📍 Данные как продукты: В Data Mesh данные рассматриваются как продукты, которые имеют своих владельцев, потребителей и стандарты качества. Это способствует более высокому качеству данных и их лучшей доступности.
📍 Автономность команд: Каждая команда, ответственная за свой домен данных, имеет полную автономию в управлении этими данными, что позволяет быстрее реагировать на изменения и потребности бизнеса.

Какие плюсы есть в такой организации хранилища?
➕ Масштабируемость: Data Mesh позволяет легко масштабировать управление данными, так как каждая команда управляет своим доменом данных независимо от других.
➕ Гибкость: Децентрализованная архитектура Data Mesh обеспечивает высокую гибкость в управлении данными, что позволяет быстрее адаптироваться к изменениям и новым требованиям.
➕ Повышение качества данных: Рассмотрение данных как продуктов и назначение ответственных за их качество способствует повышению общего качества данных в организации.
➕ Ускорение инноваций: Автономность команд и децентрализованное управление данными позволяют быстрее внедрять инновации и новые решения.

Потенциальные минусы подхода Data Mesh
➖Сложность управления: Децентрализация ответственности может привести к сложностям в координации между командами, особенно в крупных организациях.
➖ Риск дублирования данных: В условиях децентрализованного управления данными возрастает риск дублирования данных и возникновения несогласованностей.
➖ Необходимость в стандартах и соглашениях: Для успешного функционирования Data Mesh необходимо разработать и поддерживать общие стандарты и соглашения по управлению данными, что может потребовать значительных усилий.
➖ Зависимость от культуры организации: Успешное внедрение Data Mesh требует определенной культуры и менталитета в организации, что может быть сложно достичь в организациях с незрелой Data-культурой.

🔗 Полезные ссылки про Data Mesh
🔗 Data Mesh Architecture
🔗 Статья про Data Mesh на Habr
🔗 Сравнение подходов Data Fabric и Data Mesh

Временные таблицы в базах данных
В ETL процессах часто возникает необходимость в промежуточном хранении данных. Одним из эффективных решений для этой задачи являются временные таблицы.

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

Чем они отличаются от обычных таблиц?
1️⃣ Временность: Временные таблицы существуют только в течение сессии или транзакции, тогда как обычные таблицы сохраняются в базе данных до тех пор, пока их не удалят вручную.
2️⃣ Изоляция: Временные таблицы видны только в пределах текущей сессии или транзакции, что обеспечивает изоляцию данных между разными пользователями или процессами.
3️⃣ Производительность: Временные таблицы часто хранятся в оперативной памяти, что позволяет значительно ускорить операции с данными.

Эти особенности и дают плюсы использования временных таблиц для оптимизации ETL

Пример создания временной таблицы в SQL из результата SELECT запроса:

```
CREATE TEMPORARY TABLE temp_table (
id INT,
name VARCHAR(50),
value DECIMAL(10, 2)
);

--либо создание из результата SELECT запроса
CREATE TEMPORARY TABLE temp_table AS
SELECT
id
, name
, value
FROM table
;
```

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

Оконные функции простым языком - Фреймы (часть 2)

Спустя 2 года после написания первой части статьи наконец дошли руки до второй части.

🚨 Материал исключительно для новичков в SQL и применении оконок, опытные SQLисты проходите мимо. А то там в комментариях уже начали накидывать сложные кейсы, что я их в статье не указал, и вообще не расписал учебник вместо статьи со всей теорией и практикой в одном месте 😅

Читать статью

? ETL с помощью SQL: Инкрементальная загрузка с обновлением данных?

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

Ключевые этапах этого процесса будут следующие:

*1️⃣ Определение инкремента данных*
Пример выделения инкремента из таблицы source по условию, что поле update_date имеет сегодняшнюю дату

```
SELECT *
FROM source s
WHERE update_date = CURRENT_DATE()

Лучше нам результат запроса сохранить в промежуточную временную таблицу.

CREATE TEMPORARY TABLE tmp_increment AS
SELECT *
FROM source s
WHERE update_date = CURRENT_DATE()

```

2️⃣ Вставка инкремента в target таблицу с актуализацией значений данных (перезапись)
Выполняем в 2 шага:

1) Удаляем данные из target, которые есть во временной таблице по уникальному идентификатору записи (например, id). Это удалит нам записи, которые нужно обновить

```
DELETE FROM target
WHERE id IN (SELECT id
FROM tmp_increment);

2) Вставляем инкремент с актуальными записями из временной таблицы `tmp_increment` в `target`

INSERT INTO target
SELECT *
FROM tmp_increment;

```

Таким образом в target таблицу будут добавляться новые записи и перезаписываться обновленные актуальные записи из source
Оставляйте реакции, если пост был полезен ?