Структурированный раздельный сбор А давайте мы отделим бизнес | Chief Data Officer

Структурированный раздельный сбор
А давайте мы отделим бизнес процессы в отдельные структуры и будем считать, что вот таблица - вот она про это. А вот эта таблица, - она про другое. И команды, которые пишут в эти таблицы, отвечают за свои данные и за свои структуры, описывают их, следят. Полная свобода у команд творить любую дичь внутри своих структур. Это уже форма раздельного сбора мусора, когда команда сама отделяет бутылки пластиковые от бутылок стеклянных и сама следит за тем, чтобы у них всё было хорошо. Как правило, аналитики в этих командах, понимая, что наконец-то появилась какая-то зона, которую можно привести в порядок, начинают спрашивать у разработчиков "а это что, а вот это что", начинают описывать то, что творится в зоне таблиц команды, начинают писать какие-то разумные мониторинги этих данных, а также задавать неудобные вопросы типа "а зачем мы пишем вот это, если мы это не используем и никогда не будем". Старожилы говорят, что "так исторически сложилось". Если довести до ума, то в целом получается рабочая и не очень дорогая система. Только есть одно но, - каждая команда организует данные по-разному... Например, одни в своей таблице пользователя называют user_id, а другие команды в своих таблицах называют customer_id, а третьи - device_id. Одни и те же сущности имеют разные описательные свойства, что приводит к проблемам связывания данных друг с другом. Представьте, что одни отделяют бутылки стеклянные от бутылок пластиковых, а другие тоже отделяют, но кладут ещё к стеклянному банки, битое стекло, а также выкидывают использованные линзы - ну для них это в целом тоже почему-то стекло. Короче: разные команды либо называют разные сущности одними именами, либо одинаковые сущности разными именами. В итоге тратится время на "синхронизировать понятия" - подобная горизонтальная коммуникация отнимает очень много времени. Писать что угодно как угодно не выйдет - нельзя так просто зайти к соседней команде и сказать "чуваки, мне нужно чтобы вы в таком виде мне залогировали вот такие данные и всё равно куда" - неее, тут ты приди, попроси, мы там обсудим, сделаем по-своему, потому что "у нас тут всё чётко".

Централизованное управление
А давайте группа из N человек придумает структуры для всего бизнеса, придумает правильную денормализацию, вникнет в продукт целиком, продумает непротиворечивый набор таблиц, которые были бы связаны друг с другом общим замыслом, общими свойствами, проекции из которых давали бы необходимые метрики, а DAU считался бы путём простого объединения user_id из этих таблиц - если хочется проникновение в сервисы - то просто группировка по источнику. Централизуется принятие решений о том, куда, как и что и в каком виде пишется. Это крайне редкая и крайне успешная конфигурация. Почему? Как минимум, потому что есть ответственные за структуры и их эффективность для бизнеса. Они ставят задачи о том, что и в каком виде и куда складировать, а главное - они понимают почему. Как правило у такой конфигурации прекрасно описанная аналитика в едином стиле с примерами. Ввиду того, что часто вырабатываются похожие структуры для разных команд, то к ним применимы велосипеды - например, сделали мы мониторинг метрик для одной команды, - оно почти 1 в 1 с применением техники напильника переносится и на все другие команды. Кол-во датаинженеров в этой конфигурации минимально - и они как правило не заняты тем, чтобы придумывать как данные в витрины собрать, а думают о том, как сделать так, чтобы всё это работало эффективней, быстрее, дешевле. Это самая быстрая и самая дешёвая форма, но у неё есть один недостаток - она очень не подходит для стартапов, в которых всё быстро меняется. А потому, к сожалению, с неё крайне сложно начинать. Но, как только вырисовываются core фичи, которые точно не пропадут, можно смело идти в переделывание аналитики на эти новые централизованные рельсы.