Проблемы данных: 5 кругов ада для аналитика
Когда аналитик может быстро взять нужные, чистые, понятные данные, чтобы принести пользу бизнесу - это базовый минимум или роскошный максимум?
Я успела поработать в компаниях с разной инфраструктурой, объемом данных и квалификацией дата-инженеров. И очень рада, что весь треш пришелся именно на первую половину моей карьеры!
1. Селекты на несколько часов
❌ Как НЕ надо - мой опыт: В одной из компаний, где я работала, была ужасная инфра и данных было так много, что в основном приходилось использовать уже агрегированные, чтобы сделать SELECT за какое-то вменяемое количество времени. Но когда нужно было лезть в сырые.. я ставила запрос на ночь, чтобы пройти в питоновском цикле хотя бы несколько дней
✅ Как надо - мой опыт: Последующие компании меня разбаловали. СУБД Google BigQuery и ClickHouse в этом вопросе очень радуют! И я привыкла в большинстве случаев получать результат запроса сразу или в течение минуты
2. Данные второй свежести
❌ Как НЕ надо - мой опыт: Данные за вчерашний день были доступны в лучшем случае к утру, а в случае (частых) задержек - после обеда или позже. Каждый такой раз у продактов случалась истерика😱
✅ Как надо - мой опыт: Сейчас я уже привыкла, что через несколько минут после того, как покликаю в приложении / на сайте, данные об этом прилетят в таблицу
3. Мусор
❌ Как НЕ надо - мой опыт: Пропавшие куски данных, какие-то дубли.. У одной из компаний было хотя бы оправдание в огромном количестве данных и легаси. В другой же, данных хоть и не было много, с ними постоянно что-то случалось. Ох, если бы те дата инженеры меньше выясняли отношения и больше работали..🤓 Но тогда я очень круто прокачалась в том, чтобы выискивать такие проблемы и их источник
✅ Как надо - мой опыт: Была компания, где я за 1.5 года по-моему вообще ни разу не сталкивалась с подобным, это был какой-то рай на Земле
4. Дата-ребусы
❌ Как НЕ надо: Когда столбцы в таблицах выглядят так, будто их называл кот, пробежавший по клавиатуре. Документации, разумеется, нет. И много важной информации лежит в гигантских JSONах
5. Бюрократия
❌ Как НЕ надо: Когда чтобы получить доступ к данным, нужно создать тикет в Jira, согласовать его с безопасниками, владельцами данных, тимлидом и папой римским. И ждать недели две
Сталкивались с подобными проблемами? Какая бесит больше всего?
Когда аналитик может быстро взять нужные, чистые, понятные данные, чтобы принести пользу бизнесу - это базовый минимум или роскошный максимум?
Я успела поработать в компаниях с разной инфраструктурой, объемом данных и квалификацией дата-инженеров. И очень рада, что весь треш пришелся именно на первую половину моей карьеры!
1. Селекты на несколько часов
❌ Как НЕ надо - мой опыт: В одной из компаний, где я работала, была ужасная инфра и данных было так много, что в основном приходилось использовать уже агрегированные, чтобы сделать SELECT за какое-то вменяемое количество времени. Но когда нужно было лезть в сырые.. я ставила запрос на ночь, чтобы пройти в питоновском цикле хотя бы несколько дней
✅ Как надо - мой опыт: Последующие компании меня разбаловали. СУБД Google BigQuery и ClickHouse в этом вопросе очень радуют! И я привыкла в большинстве случаев получать результат запроса сразу или в течение минуты
2. Данные второй свежести
❌ Как НЕ надо - мой опыт: Данные за вчерашний день были доступны в лучшем случае к утру, а в случае (частых) задержек - после обеда или позже. Каждый такой раз у продактов случалась истерика😱
✅ Как надо - мой опыт: Сейчас я уже привыкла, что через несколько минут после того, как покликаю в приложении / на сайте, данные об этом прилетят в таблицу
3. Мусор
❌ Как НЕ надо - мой опыт: Пропавшие куски данных, какие-то дубли.. У одной из компаний было хотя бы оправдание в огромном количестве данных и легаси. В другой же, данных хоть и не было много, с ними постоянно что-то случалось. Ох, если бы те дата инженеры меньше выясняли отношения и больше работали..🤓 Но тогда я очень круто прокачалась в том, чтобы выискивать такие проблемы и их источник
✅ Как надо - мой опыт: Была компания, где я за 1.5 года по-моему вообще ни разу не сталкивалась с подобным, это был какой-то рай на Земле
4. Дата-ребусы
❌ Как НЕ надо: Когда столбцы в таблицах выглядят так, будто их называл кот, пробежавший по клавиатуре. Документации, разумеется, нет. И много важной информации лежит в гигантских JSONах
5. Бюрократия
❌ Как НЕ надо: Когда чтобы получить доступ к данным, нужно создать тикет в Jira, согласовать его с безопасниками, владельцами данных, тимлидом и папой римским. И ждать недели две
Сталкивались с подобными проблемами? Какая бесит больше всего?