Аналитика данных / Data Study

простая уловка с алиасами колонок в SQL дело в том, что обычно СУБД названия столбцов таблицы воспринимают на латинице в нижнем регистре. А если нужно использовать смешанный регистр или перейти на кириллицу, то нужно применять кавычки. COALESCE(cost, 0) AS CurrentPrice — колонка будет в итоге в нижнем регистре currentprice COALESCE(cost, 0) AS "CurrentPrice" — колонка будет с названием точно таким как его указали в кавычках COALESCE(cost, 0) AS "Текущая цена" - или так сразу на русском задать название для выгрузки, а не менять его потом в Python или вручную.

Как усилить навыки, чтобы получить повышение 💰 уже в ближайшее время Бизнесу важен результат. И чем быстрей и лучше может дать результат сотрудник, тем больше ему готовы платить. А теперь сравните 2 сотрудников: Петя - умеет писать SQL запросы, выгружать результат в файлы и вручную собирать из них отчеты. Если задача сложнее, то придется писать ТЗ на другой отдел, чтобы реализовали задачу. Маша - умеет работать как Петя, но может делать лучше. Она автоматизирует те задачи, которые понимает что должны выполняться периодически. Если ей нужно построить отчет, для этого она сама может собрать данные, обработать их, подготовить отчет и поставить весь этот процесс на автоматику. Ей не нужно тратить время на ТЗ и ждать выполнение задачи от другого отдела. Кто в рамках одной компании из этих сотрудников имеет все шансы получать больше другого? Конечно Маша. Результат для компании и в том и другом случае будет идентичный - конечный отчет. Только Маша сделает всю работу сама, а Пете придется привлекать кого-то еще (а это тоже деньги компании между прочим за время работы другого человека) или он в целом будет не в силах сделать такую задачу. Чтобы быть в этой ситуации как Маша, приглашаю тебя на курс "Продвинутый SQL и автоматизация витрин данных". Старт уже сегодня! ✅ закрытое сообщество учеников ✅ 13% налоговый вычет ✅ возможна оплата от компании ✅ если запланирован отпуск или нужно подвинуть сроки, всегда можем договориться заранее

Вся правда про текущий рынок трудоустройства Олег, ученик июльского потока курса, столкнулся с реальностью текущего рынка труда. Рынок работодателя это: - высокий конкурс на вакансию - компания управляет вилкой зарплаты и находится в более сильной позиции чем кандидат, потому что желающих много - меньше «хантинга» и предложений в личку, активность идет больше от соискателей работы Поэтому компания чувствует себя так скажем «вальяжно» в плане выбора кандидатов и это сказывается на скорости их обратной связи. ПОЧЕМУ МОГУТ ВЫБРАТЬ ДРУГОГО, А НЕ ТЕБЯ? Не надо сразу искать изъяны в себе, с тобой и твоими компетенциями может быть все хорошо. Но вот несколько хотя бы примеров, которые могу повлиять на выбор: - человек оценивает себя ниже чем ты. В виду всех прочих равных конечно компания захочет сократить затраты на те же задачи - отвечали более уверенно, без стеснения, произвели по soft-навыкам лучшее впечатление - показался более релевантный опыт просто по набору компаний. Есть такое например в банках, что возьмут кандидата с опытом работы в банке, чем например даже более опытного по годам кандидата - человеческий фактор. Когда принималось решение или было собеседование, человек, принимающий решение, мог быть не в духе, а это сильно отражается на принятых решениях, к сожалению - Возраст, ваше местоположение, возможность работать на гибриде. Да, у каждого опять же принимающего решения человека есть свои установки и картинка кого он ищет, поэтому даже не профессиональные факторы могут сыграть как нам в плюс, так и минус. ОБРАЗ ИДЕАЛЬНОГО КАНДИДАТА ПО МНЕНИЮ КОМПАНИЙ 😁 - молодой человек 25-30 лет. В декрет не уйдет, желательно с военным билетом, в армию не загребут. - 2 высших образования - живет в Москве и готов ездить в офис сколько ему скажут. Часовой пояс самый удобный - Готов работать за «спасибо» и печеньки в офисе. А о повышении вообще не должен говорить ближайшие 5 лет работы - это табу. - При этом минимум 10 лет опыта, из них 5 лет в БигТехе - Желательно со своим ноутбуком, чтобы деньги на выдачу техники не тратить - Не зумер, но и не бумер, чет среднее, чтобы в тиктоке не сидел, но и мозги пока работали и новый материал быстро усваивали Походите под идеальный образ? 😆 А вообще хочу поздравить Олега, он трудоустроился и сейчас проходит испытательный срок. Желаю успехов! 🎉🎉🎉 #кейс

Кейс с собеседований на SQL В истории заказов хранится несколько строк на один order_id с разными статусами и датами обновления. Необходимо оставить строки с последним актуальным статусом, не применяя JOIN. ➡️ Решение: используем ROW_NUMBER(), чтобы пронумеровать версии по дате и взять последнюю актуальную

WITH ranked_orders AS (
    SELECT
        *,
        ROW_NUMBER() OVER (
            PARTITION BY order_id
            ORDER BY updated_at DESC
        ) AS rn
    FROM orders_history
)
SELECT
    order_id,
    status,
    updated_at,
    amount
FROM ranked_orders
WHERE rn = 1;

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

Такая мысль крутится Все чем мы пользуемся, создано другими людьми. А эти созданные продукты собраны на компонентах, созданных еще другими людьми. И так множество шагов вниз, пока не дойдешь до ФИЗИКИ. Например, я как аналитик пишу SQL и пользуюсь для этого программой DBeaver . 🔹Я - пользователь, а есть разработчики и аналитики этой программы. 🔹Дальше эта программа работает на операционных системах. У каждой системы есть свои разработчики и аналитики. 🔹Сами операционные системы работают на девайсах (ноутбуки, телефоны и т.п.). Девайсы разрабатывают огромное число вовлеченных в процесс людей - инженеры, конструкторы, дизайнеры и т.д. 🔹Девайсы собраны из компонентов: процессор, память, экран батарея и т.д. Каждый компонент - это отдельный сложный процесс производства с своими умными людьми. 🔹А дальше самый интересный и загадочный уровень - ФИЗИКА. Чтобы любое физическое устройство работало, его должны изобрести, изучить физические законы и свойства, на которых строится его работа. И каждый элемент памяти, процессора, электроники сам по себе максимально сложен конструктивно и сочетает десятки законов физики и математики внутри себя. Вы только вдумайтесь! Большинство людей - это пользователи конечного продукта, в котором столько работы спрятано и мы об этом даже не задумываемся. И теперь с этими мыслями чувствуется сколько мы всего не знаем, и все равно можем считать себя образованными и достаточно умными, хотя находимся на самом верху этой "технологической матрёшки". И насколько ученые-исследователи находятся вообще в другой вселенной от всех нас 🤯

Нам пришлось сломать стандартный подход DWH, чтобы повысить качество данных Кажется странным, да? Вроде стандарты создаются, чтобы улучшать подходы, процессы, продукты. Но в нашем случае привычный подход просто не работал. Мы всё время не сходились по количеству пользователей и актуальности данных между источником и DWH. Дело в том, что нужная нам таблица отличается от всего остального. Стандарты DWH заточены на событийные данные, где каждое событие хранится в своей строке или одни типы событий агрегируются по части полей. Но у нас одна строка должна содержать и агрегировать внутри себя множество событийных данных клиента из разных источников: регистрации, авторизации, удаления, коммуникации, установки приложений и т. д. Стандартный подход DWH: инкремент по дате. Наш подход: инкременты по дате каждого типа событий + общий инкремент по ID пользователей, исходя из первых инкрементов. Так мы перестали терять апдейты, а данные выровнялись и по количеству, и по актуальности с системой-источником. Вот так переход от очевидного и принятого решения сделал наши данные чистыми и правдивыми для всех команд компании, хотя даже сейчас этот скрипт витрины выглядит неординарно по сравнению со всем остальным репозиторием :) Ещё больше таких историй о нестандартных решениях будет обсуждаться в зале «Ломаем шаблоны» на конференции «Продукты 24 × ffdd2d». Из интересного мне хочется послушать доклад «Почему хорошие решения не всегда рождаются по правилам» от Максима Кирилычева. Обязательно зарегистрируйтесь и приходите 12 сентября в Москве, в комплекс «Мечта» на набережной парка Горького.

Каждый день сталкиваюсь с какими-то трудностями с доступом к сервисам. Сейчас вот Cursor перестал работать на территории РФ, теперь только под впн отвечает( Сами впн постоянно меняются, бывают частично недоступны и это вызывает кучу неудобств для ведения канала, а вам для чтения. Основной канал все равно планирую вести здесь, но настроил все таки репостинг в MAX. Кому там удобней читать материалы без танца с бубнами, велком Канал в MAX

🎯 Всего один фактор в разы увеличивает успех прохождения собеседований Это не накрученный опыт, ИИ-агент или зубрежка теории. ➡️Это уверенность в себе: в своих знаниях и своем практическом опыте. Недавно получил сообщение от ученика с курса, он сейчас проходит технические собеседования. Потому что когда не делал вживую все равно чувствуется неуверенность. А когда хотя бы раз сделал сам или по примеру то другое дело. даже сложный дашборд готов был сверстать хоть из таблицы хоть с построением витрины))) За виды витрин и типы обновлений так рассказал,как будто каждый день делаю. Именно это чувство «как будто делаю каждый день» и есть главный маркер сильной кандидатуры и уверенности на собеседовании. Когда не просто догадываешься или размышляешь как сделать задачу, а когда ты уже прожил подобный опыт и рассказываешь как это сделал бы повторно. И заметьте, для этого не обязательно иметь коммерческий опыт в компании, нужен хороший и качественный практический трек в рамках обучения. Будь это самостоятельный проект, практический курс, занятия с практикующим ментором или другой вид практики. Рекрутер и техлид считывают уверенность моментально: перед ними не человек, который зубрил теорию в ночь перед интервью, а специалист, который уже «трогал» задачу руками. Вот почему практика решает и для наглядности приведу примеры с технических собесов: 🔹 Ты не просто знаешь про типы обновлений SCD, а можешь с ходу объяснить, чем SCD2 отличается от SCD3 на примере витрины клиентов — потому что сам настраивал логику версионности в проекте. 🔹 Ты не пугаешься слова «автоматизация»: если спросят про выгрузку или оркестрацию, ты не теряешься, а спокойно говоришь про пайплайны, зависимости и обработку ошибок — ведь уже делал первую автоматизацию в рамках своей практики. 🔹 Когда на собеседовании дают кейс «сверстай отчёт по выручке», ты не придумываешь план из головы, а предлагаешь: «Сначала схожу уточню требования, потом исследую данные и проверю их на качество и возможность покрыть требования к отчету, сделаю логику для сбора данных, потом рассчитаю метрики, потом визуализирую». Именно поэтому в своем курсе я не даю абстрактных примеров. Мы идём по реальному пайплайну: от staging до витрины, от SQL-запросов до дашбордов в BI. Ты решаешь задачи, которые реально встречаются в вакансиях DWH-аналитика и Data Analyst: миграции, дедупликация, построение метрик, оптимизация запросов, работа с оконными функциями и рекурсивными CTE. И к моменту собеседования у тебя уже есть не просто знания, а опыт — и, как следствие, уверенность. Присоединяйся к практической группе, старт 14 сентября В группе будет: ✅ работа в инструментах, которые спрашивают на интервью (SQL, Python, ETL, DWH-архитектуры, BI); ✅ код-ревью и фидбек по твоим решениям; ✅ выполнение реальных рабочих задач аналитика

Чем мне помогает ИИ на реальных задачах аналитика данных По моим наблюдениям есть 3 лагеря людей 1. "ИИ не может помочь мне в моих задачах потому что ..." 2. "Я делаю практически все через ИИ, хотя сам этого никогда не делал" 3. "Использую ИИ как помощника, который ускоряет мой процесс работы и снимает часть рутины и объема, но главные вещи я делаю сам" Первый и второй лагерь - это две крайности. Одни игнорируют удобство ИИ, а другие им злоупотребляют и с небольшими собственными техническими навыками сильно полагаются на него. Я отношусь к 3-му лагерю и называю это "осознанное использование" 😁, где ИИ реально экономит 3–5 часов в неделю Например, часть моих сценариев 🔹 Генерация и проверка SQL и Python кода по ТЗ/задаче. Даёшь ИИ описание и сэмпл данных: «Нужно посчитать LTV по когортам, окно 12 месяцев, исключить возвраты, группировка по source и country» — и получаешь рабочий запрос с оконными функциями и CTE. Дальше проверяешь логику, оптимальность, правишь сам или через итерации с агентом и доводишь до финала. Это не сразу «готовое решение», а черновик, который экономит время на написание кода с нуля. НО ЕСЛИ ТЫ САМ НЕ ЗНАЕШЬ SQL ИЛИ PYTHON, такой подход будет содержать кучу ошибок, которые ты даже проверить не сможешь. Это сравнимо с тем, чтобы попросить ИИ написать текст на китайском, а результат ты никак не оценишь, если сам китайского не знаешь. 🔹 Рефакторинг кода. Есть старый запрос на 700 строк без комментариев? Кидаешь его в ИИ с промптом: «Разбей на CTE, добавь алиасы, прокомментируй каждый блок одной строкой, объясни логику преобразования данных». Получаешь читаемую структуру, которая поможет разобраться в чужом коде и быстрей его понять 🔹 Работа с документацией и поиском информации по гиту. Нужно быстро найти, как считается конкретная метрика или где и как используется конкретная таблица? Натравил ИИ на репозиторий со всеми файлами или на выборку документации и просишь: «Найди все места, где упоминается Retention, выпиши формулы, источники данных. За пару минут получаешь выжимку, которую раньше искал вручную через поиск или спрашивая других аналитиков. 🔹 Прототипирование дашбордов и макетов. Это не про тему навайбкодить готовый дашборд, так в крупных компаниях с установленным набором инструментов и доступов не прокатит. Это про структуру разрабатываемого отчета: «Дай список метрик, измерений и фильтров для панели “Продажи по регионам”» или «Предложи 3 варианта визуализации для динамики оттока». Это помогает быстрее согласовать макет с бизнесом и не тратить время на «переделки». 🔹 Разбор ошибок и логов. Получил непонятную ошибку в ETL потоке данных? Кидаешь текст ошибки и фрагмент кода — ИИ часто подсказывает, в чём проблема: «Ошибка связана с приведением типов в JOIN, проверь, что id в обеих таблицах — INT, а не VARCHAR» или «В подзапросе нет алиаса для агрегированного поля». ➡️ИИ не заменяет экспертизу аналитика. Он не знает всех бизнес-правил, особенностей логики, хотелки заказчиков и «подводные камни». Но он отлично закрывает рутину: синтаксис, структуру, выжимки, черновики. А финальное решение, проверка данных и ответственность — всегда на аналитике.

🎉 С Днём знаний, друзья! 📚 Пусть новые знания даются в радость, а не через «надо», и сразу находят применение — в крутых запросах, в аккуратных витринах, в решениях, за которые не стыдно. Пусть каждая строчка кода становится не просто упражнением, а маленьким шагом к уверенному «я это умею». 💪 А если хочется, чтобы теория не висела в воздухе, а сразу ложилась в практику — я как раз готовлю группу к старту 14 сентября. Там всё про реальные задачи, инструменты и навыки, которые реально спрашивают на собеседованиях. Обучение созданию аналитических витрин и автоматизации потоков данных

Счастливый на рыбалке в месте, где провел все незабываемое детство 😊

CTE + рекурсия: когда нужно «пройтись» по иерархии данных Есть задачи, где данных недостаточно «плоских» таблиц: нужно подняться по иерархии (от подчинённого к руководителю), спуститься по дереву категорий или пройти по цепочке транзакций. Тут выручают рекурсивные CTE — мощная штука, про которую многие вспоминают только тогда, когда обычный JOIN уже не спасает. Конструкция простая по форме, но очень эффективная:

WITH RECURSIVE имя_cte AS (
    -- Базовый случай (с чего начинаем)
    SELECT ...
    UNION ALL
    -- Рекурсивный шаг (как переходим дальше)
    SELECT ... FROM имя_cte JOIN ...
)
SELECT * FROM имя_cte;

Есть типичный формат иерархической таблицы, где фиксируется сам объект и его родительский id. К примеру давайте посмотрим на категории товаров, когда например для товара есть целый путь категорий ("Для мужчин" - "Верхняя одежда" - "Зима" - "Куртки"). В итоге с помощью рекурсии для каждого объекта можно сразу достать весь путь его родительских категорий).

WITH RECURSIVE category_path AS (
    SELECT
        category_id,
        parent_category_id,
        name,
        name AS full_path,
        1 AS depth
    FROM categories
    WHERE parent_category_id IS NULL  -- корневые категории

    UNION ALL

    SELECT
        c.category_id,
        c.parent_category_id,
        c.name,
        cp.full_path || ' > ' || c.name,
        cp.depth + 1
    FROM category_path cp
    JOIN categories c ON c.parent_category_id = cp.category_id
)
SELECT category_id, full_path, depth
FROM category_path;

Другими словами, рекурсия с cte - это некая реализация цикла с помощью SQL. Ставь 👍 если узнал новое

Мой любимый, но редкий вид офиса Спасибо моей профессии, что она позволяет работать из любой точки 🙏 В целом по жизни заметил, что моя одна из основных ценностей - это свобода. Терпеть не могу, когда нужно быть загнанным в работе, жизни, отдыхе, досуге в какие-то рамки. Хочу принимать решение сам, делать то что я хочу внутри, но при этом это никогда не выражается во мне как «бунтарство», или не выполнение своих обязанностей. Когда процессы выстроены правильно, они в любом случае оставляют человеку свободу выбора, частичку творчества и разнообразие решений, будь то рабочие процессы или бытовые вопросы. Увы, сейчас глобально все тяжелее ощущать вокруг себя то что мне ценно. ВСЕ вокруг вызывает неудобства и постоянную тревожность. Думаю, что сейчас я далеко не один такой. Желаю каждому из вас вокруг себя по максимуму создавать и удерживать ту уютную и спокойную среду, на которую можно повлиять напрямую и которая зависит только от вас самих ♥️

Кормили нутрий в Туле, рекомендую 😉

Применяю SQL потому что лень писать на Python) Решал типовую рабочую задачу. Суть в том, что данные были получены с помощью python и по датасету нужно было сделать несколько преобразований и вычислений метрик. Преобразования сами по себе стандартные: фильтрация, агрегация, сортировка. Можно взять написать все эти операции с помощью pandas к уже имеющемуся датафрейму. Но мне так стало лень писать несколько строк кода на python, что для меня было проще написать всю логику в одном select запросе на sql 😁 Вы спросите

"нафига так делать???" чтобы применить sql данные нужно положить в базу данных

Нет, точнее не всегда) Данные остались в том же датафрейме, а обработку я сделал с помощью pandasql. Простой пример применения и сравнения pandas VS pandasql 👇

import pandas as pd 
from pandasql import sqldf

data = {
    'product_id': [1, 2, 1, 3, 2, 3, 1],
    'sale_date': ['2023-01-01', '2023-01-02', '2023-01-03', '2023-01-01', '2023-01-02', '2023-01-03', '2023-01-04'],
    'amount': [100, 200, 150, 300, 250, 350, 400]
}

df = pd.DataFrame(data)

# логика с pandas (фильтруем по датам, группируем по product_id, считаем агрегат суммы по полю amount и сортируем по нему же)
result_df = (
    df[df['sale_date'].between('2023-01-02', '2023-01-03')]
    .groupby('product_id', as_index=False)['amount']
    .sum()
    .sort_values(by='amount', ascending=False)
)

# или применяя sqldf
query = """
    SELECT product_id, SUM(amount) as total_amount
    FROM df
    WHERE sale_date BETWEEN '2023-01-02' AND '2023-01-03'
    GROUP BY product_id
    ORDER BY total_amount DESC
"""

sql_result = sqldf(query, globals())

Я на работе настолько привык крутить все данные с помощью SQL, что в голове любые преобразования я продумываю на логике sql-запросов, а потом если все таки нужно могу переложить это на python скрипты. Это как с разговорными языками. Если например переезжаете в другую страну и начинаете разговаривать/писать/слушать на другом языке, то у вас мозг со временем начинает мыслить на этом же языке. У меня так было с английским 🇬🇧, когда учеба и работа была полностью на английском, при этом жил в Москве, но все равно замечал что формулирую предложения сначала на английском, а потом уже осознаю что можно на русском) P.S. sqldf применяет диалект SQLite, поэтому можно использовать все функции которые доступны для этой базы. 👍 если узнали новенькое для себя из поста

Lakehouse для аналитиков и инженеров данных Приглашаем изучить популярный подход построения хранилищ данных Data Lakehouse c разделенным Compute и Storage на основе Iceberg и Trino.  В программе курса: • Современная архитектура аналитических систем от DWH и Data Lake до Lakehouse с разделением Compute и Storage на базе Apache Iceberg и Trino.  • Iceberg: управление файлами, снимками, каталогами, схемами изменений и очисткой.  • Практическое использование Iceberg Catalog, работа с кластером Trino (на Kubernetes), подключение данных на S3 и выполнение SQL/ Python-запросов. • Работа с Iceberg+Trinо на больших масштабах: сложные запросы к датасету TPC-DS (2.8 млрд строк), интеграция с DBT, Apache Airflow, оценка производительность систем.  • Построение пайплайнов, инструменты  для корректной поддержки, обновления и масштабирования Lakehouse-инфраструктуры на уровне предприятия.  Кто мы: R&D-центр Devhands, наш канал. Автор курса — Алексей Белозерский, CDO в inSales (Сбер 2B), ex: VK Tech, М.Видео, Эльдорадо 🗓 Старт курса: 27 августа Изучить программу и записаться можно здесь. Ждём вас! Реклама. ИП Рыбак А.А. ИНН 771407709607 Erid: 2VtzquZf5с8

❌ Хотите внедрить ИИ в компании? Не начинайте с выбора модели. Иначе есть риск потратить бюджет, а получить красивые, но бесполезные ответы. Причина большинства неудачных AI-проектов — не технологии. Проблема в данных: они разрознены, устарели, хранятся в 1С, CRM, Excel и десятках других систем. На бесплатном вебинаре разберем, как подготовить данные, чтобы корпоративный ИИ действительно помогал бизнесу, а не генерировал «галлюцинации». Расскажем: ✔️ почему данные важнее модели; ✔️ как автоматизировать получение данных из 1С; ✔️ зачем компании DWH и единый слой корпоративных знаний; ✔️ как выглядит рабочая AI-ready архитектура на реальном примере. 🎁 Всем зарегистрированным — запись вебинара, презентация спикеров, материалы по архитектуре AI-ready и возможность задать вопросы экспертам. 📅 12 августа | 11:00 (МСК) 💻 Онлайн, участие бесплатное. 👉 Зарегистрируйтесь сейчас и узнайте, с чего действительно стоит начинать внедрение корпоративного ИИ.

Data Warehouse, Data Lake, Data Lakehouse, Data Fabric, Data Mesh – что это такое, и в чем разница между концепциями Есть классная историческая справка про появление понятия DWH (сможете похвастаться перед коллегами или на собесах знанием истории концепций хранилищ данных 😎). Если кто-то думает, что аналитика данных и Big Data зародились когда все об этом начали в рекламе курсов кричать, то вы далеко ошибаетесь, история уходит еще в 20 век. Ну и лаконично описаны концепции хранилищ и показаны на визуальных схемах с основными элементами. Помогает понять зачем вообще такой зоопарк систем нужен и как это все обусловлено эволюцией подходов работы с данными. Читать статью

Без реального опыта попасть в IT ОЧЕНЬ трудно У каждого человека, кто пытается найти свою первую позицию аналитиком, возникает сложность при поиске и понятный аргумент:

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

Я скажу то, что даже с вашим опытом вне аналитики и просто с реализацией максимально практического проекта вне рамок коммерческого опыта у вас есть все возможности найти работу. Но для этого недостаточно ❌ навайбкодить без понимания процессов в проекте ❌ взять готовый датасет и покрутить его в юпитер-ноутбуке ❌ взять чужой проект с GitHub и выдать его за свой И здесь я согласен с мыслями Саши Исакова из его поста про 5 базовых вещей для старта в аналитике. Чтобы собрать практический проект тебе нужно реально его сделать самостоятельно, а для этого: ✅ тебе нужно знать фундаментальные инструменты работы с данными - SQL, Python, BI. быть знакомым со статистическими методами исследования данных ✅ уметь пользоваться LLM как своим помощником и "турбо-кнопкой" для ускорения своей работе, а не отдавать ему всю работу целиком. ты должен понимать суть проекта, какие данные используются, как они обрабатываются, хранятся, какие метрики считаются и какие выводы мы можем из этого сделать Именно глубина понимания, а не строчки кода, превращает новичка в аналитика, которого готовы нанимать. Начните с проекта, за которым стоят ваши навыки.

За что аналитики получают 300к+ в месяц? Далеко не каждый аналитик получает такие суммы, а только те, кто имеет сильные технические компетенции. И получают за то, что другие специалисты сами сделать не могут, или если спец может сделать работу за 2-их или 3-их людей, которые суммарно будут дороже стоить компании. Поэтому совмещение компетенций аналитики и инженерии данных в одном специалисте ценят, ищут, и готовы за это платить выше чем тем, кто только знает "базовые запросы sql, собрать оучную выгрузку" и "я могу только в excel это сделать" Поэтому если хочешь больше 💰, то можешь даже не рассчитывать, что базовых навыков SQL или Python тебе для этого будет достаточно. Нужно копать глубже, иметь техническую насмотренность. ➡️А получить это ты можешь вместе со мной на курсе, стартуем уже завтра