Chief Data Officer

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

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

2023-04-12 20:29:30 Привет!
Сегодня я расскажу о типах аналитических хранилищ, с которыми сталкивался в своей консультационной и не только практиках.

Неструрированная помойка
Это наиболее популярный тип хранилищ, которым как правило больше всего гордятся его создатели. Это либо кликстрим, либо много разрозненных неструктурированных логов. Как правило все данные есть, но никто не знает, где они находятся. Если и знают, то никто не знает всех "приколов" и "фич" в этих данных. С утра до ночи датаинженеры пишут скрипты, которые очищаются всё и складывают в какие-то более менее адекватные витрины. Раз в месяц выясняется, что всё мы делали не так и надо немного подправить весь пайплайн и пересобрать всю историю и займёт это пару дней. Мониторинги в такой системе практически невозможны, почти всё время data science специалистов уходит на найти, выяснить, отфильтровать, вычистить, обогатить. Bus factor минимальный, само собой, потому что человек, который разобрался в какой-то аналитической зоне бизнеса, как правило является единственным, кто может с этими данными адекватно работать. Из плюсов - пиши что хочешь, как хочешь, сколько хочешь. Из минусов, как я и сказал, - неясно что пишется, куда пишется, и пишется ли уже - дада, может быть порядка 5 разных событий, логов, структур про одно и то же с разными значениями метрик. Как правило документация обрывиста и бесполезна. Тут часто бизнесу продаётся как "у нас дешёвая и масштабируемая инфраструктура" - по факту фонд оплаты труда так раздут, что смешно говорить о дешевизне. При этом ещё стоит понимать, что delivery по любого рода аналитике растянут в 10 раз.

Структурированная помойка
Это разновидность помойки, когда бизнес уже достало, что штат аналитиков и датаинженеров разросся, а выхлопа от аналитики кроме графиков нет. Конечно, есть ML кудесники - у них там пайплайны, которые научились выжимать из песка воду. Есть и отдельные крутые Data Science, которые кайфуют от того, что несколько недель тратят на подготовку датасета. Но в целом бизнес осознал проблему и направил усилия в "сделайте это эффективней". Тогда начинаются всякие проекты по таксономии, по привязыванию структур и типов в стиле protobuf, по описанию структур данных, по деланию более прозрачным процесса преобразования данных. Data Science специалисты начинают делиться друг с другом экспертизой, появляются общие скрипты. Но всё равно зачастую это выглядит как ...мы большую помойку разделили на кучки поменьше, подписали, что в этой кучке у нас вот такие данные и приписали "наверное", а вот в той кучке мы уже научились сортировать мусор кое-как, но всё равно иногда в горке пластиковых бутылок появляются стеклянные и наоборот. Тут уже появляются ограничения, что и куда и как писать - потому что если мы эти ограничения не введём, то помоечка быстро станет неструктурированной. А потому - вот вам процесс, ревью, инструкция для разработчиков, кое-какие уже мониторинги появляются. То есть уже, что хочешь и как хочешь писать не получится - то есть получится, но немного сложнее, чем в первом пункте. Есть кое-какая документация - по некоторым областям даже хорошая, авторы гордятся, ФОТ локальный ещё больше, чем в неструктурированной помойке - потому что нужно много ресурсов на переделывание имеющегося. По-прежнему Data Science неэффективен. Открыть/Комментировать

2023-04-08 23:27:39 Всем привет!
Пора возрождать канал, а делать это нужно, само собой, рассказом про что-то выдающееся.

Некоторое время назад я познакомился с Ashot Vardanian - Founder @ Unum. Он и его команда - это выдающиеся таланты нашего времени, чьё детище будет однажды греметь на весь мир громче Google и OpenAI.

Вот далеко не весь список проектов, над которыми они работают:
UKV - Universal Keys & Values
UNSW - Uncluttered Navigable Small Worlds
UJRPC - Uninterrupted JSON RPC
UCSB - Unbranded Cloud Serving Benchmark
UCSet - Exception-less Concurrent Containers
UDisk - Fastest ACID Persistent LSM Tree
UForm - Multi-Modal AI Inference for Search

У Unum есть своя альтернатива RocksDB, которая до 7 раз быстрее. Вокруг нее построена череда open-source проектов, включая UKV - универсальную базу данных, которая может хранить документы, графы и бинарные данные, предлагая сквозные ACID транзакции, а также целый набор интуитивно понятных библиотек для пользователей верхнеуровневых языков. Например, в Python, работа с UKV таблицами очень напоминает Pandas.

Что мне лично нравится, - бескомпромиссность в скорости и удобстве. Они выжимают из железа больше, чем в него заложено программно, находя всё новые и новые способы добавить перфоманса. Яркий пример подхода ребят к тому, что они делают Remote Procedure Calls Up to 100x Faster than FastAPI

Так что, всем предлагаю подписаться, поставить star у них на github и внимательно следить за Unum. Возможно, завтра вам понадобится выстраивать инфраструктуру работы с данными, учитывая мультимодальность, а также требуя скоростей и оптимальности доступа к данным, которые немыслимы для всех современных инфраструктур. Собственно, они делают немыслимое возможным и делают это невероятными темпами. Открыть/Комментировать

2023-04-08 22:15:59 Channel name was changed to «Estim.art» Открыть/Комментировать

2021-03-11 22:49:41 Всем привет!
Давно я тут не писал, потому что с головой ушёл в продукт - это безумно интересно, аналитика очень помогает. Но продукт у нас не один - их много и все крутые. Было бы разумно организовать аналитику на уровне выше - а именно такую аналитику, процессы, структуры данных и подходы,
которые применимы ко всем продуктам компании, чтобы каждый отдельный продукт не изобретал велосипед. А потому у меня для вас уникальная вакансия - она для супер амбициозных, опытных и заряженных желанием специалистов.

Head of Analytics
Задача: организовать продуктовую аналитику на уровне множества продуктов. Единую и универсальную, быструю, красивую.

Что мы ждём от кандидата:
- 3 года опыта в роли ведущего аналитика или Head на крупном и успешном продукте с опытом выстраивания эффективной команды аналитики и процессов вокруг
- уверенное владение SQL, Python и статистическими пакетами, умение применять ML в реальных аналитических задачах
- умение реализовать A/B тестирование не только на уровне t-test-а, а много глубже
- уверенный пользователь ClickHouse
- а также хороший пипл менеджемент (найм, увольнение, персональное развитие)

Что конкретно предстоит делать, могу рассказать подробней в личке, но там полный спектр - от people management и придумывания структур данных до реализации CUPED тестов и мониторингов аномалий. Ещё мы ищем аналитика в команду рекламы и сильного аналитика в команду продукта Ultimate Guitar. Так что готовы принять сразу троих

Пишите, если вы такой или знаете таких ;)

UPD: нашёлся

tg: @stovm
facebook: stovmasyan Открыть/Комментировать

2020-09-01 23:28:26 Привет!

Меня порой спрашивают, что почитать по статистике и теории вероятностей. Учился я на Мат-Мехе СПбГу, на чистой математике, на кафедре теории вероятней и математической статистики. Затем учился в аспирантуре по тому же направлению. Образование это очень хорошее, фундаментальное, но часто бывает оторванным от практики, - то есть тебя сразу окунают в глубины глубин абстракций, оставляя один на один с фантазиями о том, как и где применять полученные знания. Такой подход в целом про нашу школу преподавания и он имеет свои плюсы и свои минусы, но 100% не очень подходит для самостоятельного освоения дисциплины, - потому что с первых страниц конспектов или книг бесконечное ощущение, что очень сложно и очень непонятно.

На самом деле всё не очень сложно и достаточно понятно, а если преподнести красиво и вкусно, то ещё и очень увлекательно. Так, например, есть совершенно потрясающий курс лекций от Harvard University. Когда я впервые увидел эти лекции, то осознал, что такое очень крутой преподаватель и в тот же момент понял, какая это невероятная по сложности работа - преподнести материал ёмко, красиво, весело, понятно, без ошибок и при этом удерживать внимание аудитории. Конечно, в этом курсе нет претензии на то, чтобы вырастить учёных, - есть цель объяснить слушателям всё от определения вероятности до цетральной предельной теоремы и её следствий, пройдя при этом через случайные величины, их свойства, распределения разные и т.д.
В общем, если вы боялись, но всегда хотели попробовать или пробовали, но не получалось, вот точка входа в увлекательный мир теории вероятностей и математической статистики.


Открыть/Комментировать

2020-08-09 15:35:56 Таким образом, резюмируя, - не нужно экономить на месте, жертвуя скоростью. Скорость - самое главное в аналитике, скорость фильтрации данных и подготовки datasets для дальнейшей аналитики - то, чем не стоит жертвовать. А потому используйте денормализацию в столбцовых базах данных! Открыть/Комментировать

2020-08-09 15:35:56 Всем привет!

Сегодня я хочу поговорить про денормализацию данных. Нормализация предназначена для приведения структуры базы данных к виду, обеспечивающему минимальную логическую избыточность. Всю начальную теорию так или иначе придумал Эдгар Кодд, работавший в IBM. Когда я ещё только учился на Мат-Мехе, мне было известно лишь о 4-х нормальных формах, но сейчас есть и 5-я и 6-я и я даже знаю тех, кто реализовал аналитическую СУБД на уровне 6-й нормальной формы. Подробнее о каждой форме нормализации вы можете почитать сами, я же остановлюсь на том, почему 6-я форма ужасна с точки зрения аналитики.

Итак - 6-я нормальная форма - это «декомпозиция до конца» - избавление от любой избыточности, подход, который упрощает поддержание целостности базы данных, однако работа с самими данными представляет из себя ад. Представьте, что для того, чтобы получить 3 свойства объекта, вам необходимо не только сделать 3 JOIN-а, но ещё и следить в условиях за версионностью этих самых свойств. Мало того, что организация 6-й нормальной формы - процесс трудоёмкий, он ещё и усложняет дальшейшую работу с данными.

В реляционных базах данных так или иначе нормализация более чем оправдана, однако в колоночных аналитических СУБД сценарий работы совершенно другой - так как JOIN-ы дорогие, а транзакционность не требуется. Более того, в колоночных базах данных, например, в ClickHouse происходит поколоночное сжатие данных, а потому денормализация - хорошая затея. Теперь подробней про неё…
Представим, что у нас есть события переходов пользователя по сайту: time, user_id, screen_from, screen_to, event
И представим, что у нас есть таблица с информацией о пользователях - date, user_id, age, sex, country, city
Мы хотим получить в группировке по странам, как пользователи переходят с какого-то экрана на другой, предполагая, например, найти проблемы с переводами или качеством выдачи, - видя разницу в поведении при переходе с одного экрана на другой. Переходов при этом может быть достаточно много, как и самих пользователей, и как следствие JOIN станет очень дорогим.

Идея денормализации заключается в том, чтобы иметь «расширенную» таблицу:
time, user_id, age, sex, country, city, screen_from, screen_to, event

То есть в таблице уже есть вся интересующая нас информация о пользователе - это и есть идея денормализации, - создании избыточности данных ради скорости доступа к ним. Как вы понимаете, если пользователь совершил 100 действий (переходов), то вероятнее всего у него будет 100 строк с одинаковыми age, sex, country, city, однако, как я говорил, при поколоночном сжатии это не такая большая проблема, особенно если сортировка данных содержит в себе user_id - то есть много одинаковых данных лежат рядом и подряд, а соответственно и сжатие работает много лучше.

Идею денормализации данных можно расширить до «хотим в событии иметь всё». То есть не только информацию о пользователе, но и дополнительную информацию об объекте взаимодействия, а также контекст, в котором происходит взаимодействие. Возможно, даже свойства связи объекта и субъекта. Например, если это событие подписки, то можно дополнить колонками типа had_subscription или last_subscription_date - говорящими о том, была ли у пользователя когда-либо подписка, чтобы, например, не перемалывать всю историю для определения того, что пользователь впервые покупает подписку.

Где предел денормализации? На самом деле это большое искусство, которым можно овладеть, продумывая прежде основные и дополнительные аналитические сценарии, которые будут происходить над таблицей. В ВКонтакте я создавал таблицы вплоть до 150 колонок для сырых данных, а также были таблицы и на 1000 колонок для агрегированных - но это ВКонтакте. Большинству компаний, которые я консультировал, такая сильная денормализация не была нужна, а потому зачастую обходились 30-60 колонками. Открыть/Комментировать

2020-07-26 23:40:45 Прошу прощения за то, что давно ничего не публиковал. Дело в том, что я ушёл из ВКонтакте и стал CPO в замечательной команде Ultimate Guitar, - в первый месяц был очень занят, но по мере появления свободного времени обязательно начну делиться интересной аналитикой и мыслями на тему… Уже скоро Открыть/Комментировать

2020-05-16 15:26:14 В начале 20 века на свет появился Фрэнк Рамсей - математик, который за свою, к сожалению, недолгую жизнь дал математике достаточно много нового и познавательного. На одном из экзаменов на Мат-Мехе мне пришлось доказывать теорему Рамсея, - приятного в этом мало, но теорема весьма интересная. Строгую формулировку тут приводить не имеет смысла - она слишком сложная, а простая, тем временем, звучит так - полный беспорядок невозможен - упорядоченные конфигурации неизбежно присутствуют в любой большой структуре. Неслучайно, что на звёздном небе мы находим знакомые нам фигуры. Этот математико-философский посыл переносим и на работу с большими данными - можно попасть примерно в такую же ситуацию, - мы начинаем видеть знакомые структуры безотносительно того, имеют эти структуры под собой какую-либо объективную причину или нет. Ещё хуже обстоят дела, когда исходные данные отчасти грязные и зашумлённые, когда есть внутренние корреляции, которые мешают смотреть объективно на метрики. Потому, зачастую, аналитику первым делом нужно из большой кучи данных выделить "правильное" со многих точек зрения подмножество. Это достигается в первую очередь путём фильтраций, группировок, - SQL наиболее приспособлен к таким операциям, а потому овладение SQL запросами является, на мой взгляд, первым шагом на пути начинающего аналитика. Нужно уметь свободно крутить-вертеть данные на уровне SQL запросов, - не бояться синтаксиса, понимать возможности. Подготовка хорошего и правильного dataset-а - важнейший этап, - именно он позволяет с уверенностью приступать к поиску зависимостей. Всё это, конечно, переплетается с моим постом про колоночные базы данных, - именно они позволяют существенно (в 10-1000 раз) ускорить процесс подготовки данных, а аналитику дают возможность проверять больше гипотез за единицу времени Открыть/Комментировать