Я убеждён в том, что аналитикам данных критически-важно иметь доступ без боли, искажений и рисков к наиболее детализированным данным проекта для исполнения своих обязанностей..
Нет данных - нет мультиков аналитики. Работа только с агрегированными и преобразованными по непрозрачной логике данными приводит к ошибкам и отсутствию доверия от бизнеса.
Статья может быть полезна к изучению при принятии решений о развитии аналитики с 0 в проекте.
К сожалению, вопросу получения данных часто не уделяется хоть какое-то внимание.
Бизнесу интересно не получение данных, а инсайты и рекомендации. Принято отдавать этот вопрос на откуп аналитикам и взаимодействию аналитиков и IT. Только у аналитиков редко есть опыт и понимание лучших практик по работе с данными и для IT задача использования данных аналитиками может быть чем-то чужеродным.
Тем не менее, как-то они договариваются. Не сталкивался с примерами, когда совсем не договорились и никакой аналитики нет.
Сталкивался с разными вариантами урона от реализации.
Пустили в прод аналитиков делать отчёты, иногда на проде даже появляются отдельные схемы и объекты под цели аналитики
В таком режиме возможно делать какие-то простые-быстрые-первичные подходы к анализу.
Очевидный плюс - никаких дополнительных затрат. Выдали доступы, люди работают. Если стадия затягивается, запросы аналитиков начинают подвешивать базы прода. В итоге аналитики нет, продукт не работает. Копятся взаимные обиды и беклог для проработки с психотерапевтом.
Не пускаем в прод, реплики не хотим или не умеем делать. Силами IT собираем набор SQL-скриптов, называем это отчётами, пишем фреймворки для выгрузки по написанным скриптам ну и сопровождаем это хозяйство как-то
На мой взгляд, это самый трудный путь для развития аналитики в проекте. Хорошо, что работа в принципе хоть как-то делается.
Дорогое решение. Задачи вовлекают специалистов из 2-х команд, доп.затраты на попытки повышения user-friendly фреймворками, отдельная инфраструктура под интерфейс выполнения запросов.
Сценарий развития встречал только негативный. Спустя пару месяцев с создания решение начинает деградировать. Появляются отчёты, которые дублируют расчёты, из созданных ранее, а цифры новые, обновлять логику трудно-долго да и сама логика понятна только тем, кто систему сопровождает. Причина проста - аналитические продукты требуют регулярной актуализации и системного подхода. Перед IT-специалистами задача ставится как "быстро закрыть проблему с доступом к данным".
А если и ставится более осознанно и комплексно, есть действительно сложные моменты - актуализация нужна не только на изменения в архитектуре данных, но и поправки на бизнес-процессы, о которых без тесной работы с бизнесом узнать сложно-невозможно.
Вопрос корректности расчётов не имеет конечного ответственного - ТЗ для IT формируют аналитики, которые не видят как устроены данные, решение выдают IT-специалисты, для которых принципиально-важно не решение боли, а точное выполнение ТЗ.
Ещё такой подход требует выделения в IT на полную занятость специалистов. Фактически, возникает два центра компетенций в компании - например, аналитики с подчинением продукту и специалисты, которые аналитикам готовят данные, но подчиняются IT директору.
И со временем каждый из центров начинает "тянуть одеяло на себя" вместо кооперации.
Я не обобщаю, уверен, что есть случаи, в которых такая сложносочинённая схема работы с данными работает. Не встретил пока за 13 лет.
Минусы
сложность масштабирования, сроки разработки чего-либо для аналитики зависят и от ресурса аналитика и от ресурса IT
ответственность за результат размыта, логика расчётов часто неизвестна никому, потому что от IT ответственные сменились, а аналитики логику знают неглубоко, на уровне бизнес-формулировок
частые ошибки в расчётах из-за отсутствия возможности профилирования данных со стороны аналитиков. Очевидные ошибки находят только по косвенным проверкам, не очевидные не находят совсем
Настраиваем полную репликацию баз данных и выдаём доступы на чтение аналитикам
Подход лечит все минусы из предыдущего решения. Второй по бюджетности после доступа в прод. Возникают траты на железо для полных реплик и ресурс devOps/DBA на поддержку процесса репликации. Возможно, не тратимся, а переиспользуем - если реплика используется как резервная версия прода, и риск-политика допускает такой сценарий переиспользования.
Проблемы как в случае с доступом в прод - если резервная копия подвешена, есть риск, что свою прямую функцию она не исполнит.
Был случай на pgsql и логической репликации, когда подвешенная реплика подвесила и прод-базу. Из-за тяжелых запросов, подвисших на 2+ часа, на проде закончилось место под val-файлы с изменениями заблокированных таблиц и прод перестал отвечать.
Встречал и вариацию, в которой сами IT собирали расчёты на репликах - в кейсе аналитики не умели в SQL. Отношу подобное к забавным девиациям в профессиях, не рабочая история.
Хорошее решение, для многих проектов с небольшими таблицами (<10млн. строк) на нём можно и остановиться.
Что не закрывает полная репликация:
если для аналитики нужны 2+ базы, данные придётся объединять с использованием конструкторов в BI или обработкой в том же Python. Это замедляет подготовку данных для анализа. Если объединять нужно очень детальные данные (таблички по 1млн.+записей), задача становится вызовом
решение всё ещё препятствует масштабированию функции аналитики в проекте, поскольку даже одинаковые расчёты в каждой новой задаче нужно дублировать. Можно пофиксить добавлением базы-песочницы, в которую аналитики будут складывать по расписанию какие-либо материализации расчётов. Переиспользуются только сами скрипты-алгоритмы. Относительно быстро упираемся в возможности железа
часто из всего объема данных для аналитики полезна-нужна только часть. Из моей практики, в лучшем случае, 30% всех данных. Если реплика поддерживается только для аналитики, переплачиваем за железо
если в отчёте некорректные данные от того, что реплика не обновлена, кто виноват? Продолжение размывания ответственности
Решением может стать частичная загрузка данных
Грузим только то, что нужно для аналитики, складываем в одном месте. Технически, самый сложный в части используемых технологий вариант. Добавим роль архитектора данных и можем собирать хранилище данных. Для реализации нужна роль data-engineer.
Если таблицы небольшие (<500 тыс. записей), можем каждый раз грузить всё что есть. С ростом объёмов, нужен способ получения инкремента - части данных.
Т.е., если данных много, чтобы оптимизировать загрузку в первый раз грузим всё, что есть в таблице, а каждый последующий определяем инкремент и грузим только часть.
В идеале, для загрузки инкрементом нужно иметь в загружаемой таблице колонку, которая однозначно размечает весь массив по порядку - метку. Логика простая - после каждой загрузки сохраняем максимальное значение метки и в новой итерации грузим только те данные, в которых значения метки больше.
На практике такой идеальный сценарий редко применим. Данные могут меняться, удаляться и добавляться в историческом периоде без изменений выбранной метки и вообще без следов изменений.
Был кейс, в котором изменения в таблицу транзакций платёжных операций "долетали" в периоды позапрошлого года и такое поведение объяснялось не ошибкой, а особенностью бизнеса, не учтённой в сценарии учёта транзакций.
В случае неидеальной базы получаем то, что данные в аналитических отчётах начинают расходиться с тем, что есть в исходных системах.
Конечно, возможны инженерные "workaround". Например, грузить по метке, но дополнительно перезагружать раз в неделю последние 2 года данных. Или перезагружать каждый раз последние пару кварталов. Результат таких решений - не вполне точные данные.
Если на своей аналитике вы строите финансовые модели, модели машинного обучения, ведёте фин.учёт или есть ещё какие-либо причины, из которых даже неточность в пару процентов важна, есть более точная технология.
CDC - Change Data Capture или захват изменений в данных. Популярные СУБД вроде Oracle, MSSQL, PostgreSQL имеют свои решения CDC. Интересно, что на рынке специалистов РФ data-engineer, который на практике работал с CDC и знает как настроить сбор и передачу данных встречается крайне редко. Читатель, умеешь в CDC? Поздравляю, ты data-единорог.
По сути, технология подключается к конкретным таблицам и сохраняет полный лог изменения записей в таблице. Далее лог можно передать в базу для аналитики.
Технология позволяет как поддерживать соответствие данных в системах-источниках и аналитической базе, так и сохранять полную историю изменений данных, что может пригодиться в отдельных задачах аудита или сложной аналитики.
Прелесть подхода с частичной загрузкой в том, что грузятся только нужные данные, нагрузка на прод либо полностью отсутствует (некоторые решения позволяют работать с репликами) либо не превышает нагрузки от репликации. Также, при использовании CDC вместе с брокером сообщений возможна настройка стриминга и доступности онлайн-свежести данных для аналитики.
Хочу уточнить, всё написанное выше - это не про хранилище. Только загрузка данных в аналитическую базу, куда аналитики сгружают всё нужное для работы. Я в работе такое привык называть хабом данных.
Принципиальные отличие хаба данных от DWH в том, что хаб можно организовать не понимая модели данных и не проектируя архитектуру хранения. Ну и сроки.
Настроить загрузку = до пары месяцев работы, с учётом бюрократии и особенностей инфраструктуры вашего проекта.
Собрать хранилище = 6-12 месяцев на mvp.
Статью дублирую в свой tg-канал.
Поделитесь, как вы работаете с данными? Есть более оптимальные подходы?
Буду рад обсудить эти и другие вопросы из сфер управления данными и аналитики.
