Знакомые попросили опубликовать вакансию. Кто находится в поиске или кому вакансия покажется интересной, велкам ⤵️

Вчера отработал последний рабочий день в 2023, на конец недели взял 2 day off чтобы не пропали)

Поэтому появилось свободное время чтобы посидеть с проектом анализа навыков из вакансий. Думал что hh хранит более менее стандартизированные названия навыков, которые указываются в вакансиях, но нет 😔
Ладно названия одних и тех те навыков/инструментов попадаются в разном написании, но есть множество ошибок в самих словах и просто мусора, который нужно чистить. Занимаюсь стандартизацией названий, чтобы в анализ шла очищенная выборка. Думал опубликую дашборд до конца года, но видимо будет только в начале следующего 😉

Достучаться до истины

Отсутствие доверия к данным - одна из проблем в компаниях.

Почему нет доверия?

Существует список причин, который так или иначе подрывает доверие к имеющимся данным
📍низкое качество данных
📍потери данных
📍противоречивые данные в разных системах
📍кривые отчеты аналитиков
...

Давайте на примере разберем, почему так может происходить.
Стандартная поток данных от их генерации до аналитического отчета выглядит так ⤵️

1️⃣ Ввод данных в UI (пользовательский интерфейс)
2️⃣ Обработка данных на backend и запись в базу данных приложения
3️⃣ Отправка данных в аналитическое хранилище / систему аналитики
4️⃣ Расчеты и построение отчетов, витрин данных
5️⃣ Использование данных для получения инсайтов и отчетности

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

P.S. буквально из рабочего чата для вас достал золотые слова на скриншоте.

Завтра допишу вторую часть поста с примером где и по каким причинам может упасть качество данных, если на этот пост конечно реакций накидаете 😉

Достучаться до истины (часть 2)

Вчера поднял тему доверия к данным. Основная причина почему доверия нет - низкое качество данных.

Пример:
У компании есть сайт, на котором она продает товары покупателям. Компания отслеживает когда покупатель на сайте просматривал карточку товара и нажал на кнопку "В корзину". Считаем конверсию сколько людей просмотрели карточку -> сколько из них положили товар в корзину.

Проблема на Frontend (пользовательский интерфейс сайта)
Всегда клик по кнопке "В корзину" учитывался корректно, а в один из дней вдруг взяло и перестало считаться. Заметил это бравый разработчик через пару дней и поправил баг.
➡️ Из-за такого инцидента пока ошибка не была устранена - данным в этот период доверять нельзя.

Проблема на Backend (логика приложения и база данных)
С новым релизом приложения поменялся API метод и принимаемый формат сообщения данных, благодаря которому данные о клике пользователя записываются в базу данных. Из-за скрытого и трудно воспроизводимого бага не заметили проблему и в итоге часть сообщений записывалось в базу успешно, а часть записывалось с дублированием данных, но под разным временем записи события. В итоге: клик клиент сделал один раз - а в базе на этот клик оказалось 2 события

Проблема в ETL при передачи из БД в Аналитическое Хранилище
Есть поток данных, который каждый день выгружает пачку накопившихся событий о кликах за сутки и записывает это в аналитическое хранилище. Выгрузка идет ночью, чтобы не нагружать системы в рабочее время. И вот представим такое правило: сколько данных в пачке забрали из базы -> столько и должны положить в хранилище (пусть трансформаций никаких не будет).
И вот представьте, наступает время выгрузки ночью, запускается процесс, и в это время возникает проблема с внутренней сетью и инструмент просто отваливается и перестает грузить пачку данных. Сбой в одну ночью, через неделю еще сбой, через месяц еще похожая ситуация. Если такие сбои не улавливать и не прогружать части данных после них корректно - в итоге многое можно потерять.

Проблема при расчетах на аналитическом слое
Здесь не буду усложнять и растягивать. Пусть мы на эту задачу поставили не очень внимательного аналитика, не провалидировали его расчеты и отдали это бизнес-пользователям. А потом через время получили от них ***, потому что цифры с реальностью вообще никак не бьются.

Кто виноват?
- невнимательный аналитик?
- frontend-разработчик?
- тестировщики?
- backend-разработчик?

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

Здесь прям хочется дать сравнение с рекой . Если кто-то наверху течения кинул мусор в реку, то его увидят все кто стоит ниже по течению. А тому кто выше будет пофиг на это, ведь у него все чисто)

Не мусорите ни в природе, ни в потоках данных 😃

Хочу зафиксировать здесь некоторые цели, которые поставил перед собой на 2024

1️⃣ Улучшить свою физическую форму и здоровье
Это пожалуй цель топ-1 на этот год. С удаленной работой очень мало подвижности, что сразу сказывается на самочувствии, и как правило отражается в настроении. Ввожу потихоньку домашние тренировки и наращиваю нагрузку постепенно, надеюсь созреть опять на походы в бассейн

2️⃣ Разработать материалы для курса Analytics Engineering (Аналитика данных 2.0)
Работы в этом направлении очень много: написать программу обучения, поделить ее на модули/уроки.темы, подготовить материалы презентаций, конспектов, сделать практическую часть обучения, оформить домашние задания... Начну в скором времени закидывать сюда опросы, пройдя которые вы мне поможете определить основные тезисы и блоки программы обучения

3️⃣ Записать онлайн-курс на одну из платформ курсов
Это будет отличный опыт формирования курса именно полностью в онлайн форме. Плюсом хочется сделать курс по смежным инструментам, которые важно знать не только аналитикам, но и всем кто работает на IT проектах. Пока мыслей много, но их нужно все формализовать

4️⃣ Дорастить канал до 10 000 подписчиков
Канал - это оказалось то место, которое помогает
📍мне донести до вас полезную информацию или просто зафиксировать мысли из головы, а также находить людей под разные цели и задачи
📍вам получить для себя практические материалы, перенять возможно в чем-то мой опыт, ну и также найти единомышленников
Спасибо вам, что участвуете в моей жизни таким образом 🔥😉
Вы кстати тоже помогаете развивать канал, если делитесь постами отсюда со своими друзьями, коллегами, знакомыми 😎

Есть еще и другие более личные цели, которые пожалуй сюда писать не буду) Посмотрим через год что из этого будет достигнуто и закрыто и на каком уровне 🚀

Уже завтра начинаем заниматься с учениками группы курса 😍

Их 100% результат, который получит каждый из группы
📍через месяц - уверенно работают с данными в базе данных с помощью SQL
📍через 2 месяца - пишут свои скрипты Python для извлечения, трансформации и загрузки данных
📍через 3 месяца - реализуют свой практический проект c помощью SQL, Python, визуализации BI и готовят документацию своего решения

И каждый еще в процессе будет искать и находить работу аналитиком 🔥

Желающие еще могут присоединиться к нам 😉 ➡️ Запись в группу
Буду рад вас видеть в группе единомышленников! Уже завтра будем общаться с вами и осваивать новые навыки

Data Study

Мониторинг качества данных в ETL процессах

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

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

1️⃣ Проверка объемов
Сколько выгрузили = столько должны загрузить. Это работает, если в процессе у нас не участвуют этапы трансформации в виде фильтрации, либо агрегации. Выгрузили из источника данных 1000 строк и в таком же виде эти 1000 строк переложили в хранилище данных.
Если объемы не совпадают - срабатывает алерт, либо специальны мониторинг.

🔎 Алерт (alert) - сигнал, уведомление для человека, что что-то пошло не по плану.

2️⃣ Проверка контрольных сумм
Работает тогда, когда в данных есть числовые метрики, например сумма продаж, стоимость продуктов и т.п.
Можно считать общую сумму по набору забираемых данных и сравнивать с суммой загруженных по итогу данных в целевую систему. Например, забираем из источника 1100 строк, с общей суммой по столбцу sale_amount = 350к. + стоит правила на фильтрацию данных с заказами, где sale_amount = 0. В итоге загрузили в целевую систему уже только 900 строк (объем был 1100), а по сумме заказов sale_amount = 350к, т.е. все хорошо. Просто в процессе правильно отфильтровались нулевые заказы и даже можно считать сколько таких было.

3️⃣ Частота выгрузки
Большая часть процессов работает по расписанию. Например, мы вугружаем данные 1 раз в час.
Т.е. каждый час у нас происходит: выгрузка, трансформация, загрузка почки данных.
Если в очередной час выгрузка не сработала - это повод для алерта.

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

Накидайте реакций, если вам интересна эта тема и стоит еще про нее рассказывать 😉

Предлагают курс записать, только жаль что на все времени не найти 🤔

Как выбрать график для отчета?

Для этого нужно ответить себе на вопрос, что я хочу показать или какую историю рассказать с его помощью. Существуют различные виды графиков, которые решают определенные задачи. Можно показать динамику, можно части целого, а может быть необходимо отразить зависимость между переменными. Чтобы проще было подобрать необходимый график существует различные шпаргалки. Одной из таких поделились Financial Times. Было это четыре года назад, но информация не теряет своей актуальности и сегодня.

Его можно использовать как интерактивный справочник.

А можно распечатать плакат и повесить в офисе или на рабочем месте.

On-premise или Cloud для Хранилища Данных?

Сегодня ученица на курсе написала такой вопрос. Решил поделиться ответом не только в чате учеников, но и здесь ⤵️

Выбор On-premise или Cloud решения зависит от бизнес-потребностей компании и множества других факторов:
📍какими данными компания обладает,
📍какие объемы данных нужно хранить,
📍нефункциональные требования к хранилищу данных (безопасность, отказоустойчивость, надежность...)
📍выделяемый бюджет

➕плюсы облачного решения:
- быстро настраивается, т.к. есть уже готовые продукты в облаке
- не нужно держать большую команду инженеров для настройки и поддержки серверов
- в зависимости от нужных ресурсов может быть более выгодно чем покупать свой сервер и думать где его установить. некий pay as you go

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

➕плюсы on-premise решения ("свой купленный железный сервер"):
- в первую очередь решение всех минусов облака)
- неограниченное количество ресурсов для масштабирования (покупай ресурсы сколько хочешь на свой сервер)
- дается возможность хранить любые данные внутри сети компании, НО за безопасность данных отвечает сама компания и никто больше
- on-premise обычно быстрее работает, опять же зависит от ресурсов сервера, но еще важно что сервер стоит обычно где-то недалеко (возможно прямо в центральном офисе), что влияет на скорость работы

❌ минусы on-premise
- обычно это дорого и платить нужно сразу большую сумму в моменте (даже для небольших компаний стоимость может исчисляться десятками млн. рублей)
- своя команда инженеров для настройки и поддержания работоспособности
- ответственность за все ложится на плечи компании и команды инженеров в том числе (информационная безопасность, доступы, настройки сети, безопасное хранение данных)