Моделирование потоков событий в эволюционирующем окружении - Николай Голов - SmartData 2023 (Рубрика Architecture)
Интересный доклад Николая Голова на тему моделирования кликстрима. Коля - крутой эксперт, который сначал работал с data vault на базе teradata, anchor modeling на базе vertica (в Avito) и anchor modeling+ на базе snowflake (в Manychat). Интересно, что объем кликстрима часто сильно превышает объем других данных, поэтому важно правильно научиться работать с ним:) Сам кликстрим характеризуется тем, что у нас
- Сотни (тысячи) типов событий
- Схема каждого типа события меняется
- Аналитики хотят одну таблицу .. быструю и простую
Его можно сохранять в виде частично структурированных данных (аля json) в нормальную базу (условный postgres) и это работает до определенных масштабов. Условно если нам нужно анализировать до миллиона событий, то можно работать напрямую с этими json, но если данных для анализа больше, то начинают играть роль проблемы с json
- Производительность: колоночные базы данных не ускоряют работы с json в sql
- Схема: какие атрибуты использовать в наших json
- Безопасность: как хранить данные в json безопасно (условно перс данные) В итоге, хранить clickstream можно в виде json в data lake, но недолго - иначе получим data swamp. Но что же с этим делать?
Дальше Коля говорит про anchor modeling, фанатом которого он и является. Anchor modeling - это развитие data vault и 6 нормальная форма. У нас есть таблица сущности achor, таблица для атрибута attribute, а также таблица для связи - tie. Это очень сложный подход, но в Авито удалось разложить в свое время кликстрим разложить в сотни нормализованных страниц. Но теперь Коля не рекомендует так делать из-за проблем
- Сотни гигантских страниц
- Для загрузки нам требуется joins 10ˆ9 строк
- Для анализа нам требуется joins 10ˆ9 строк
- Типа джойним одно и то же два раза.
А дальше Коля предлагает свой подход, к которому он пришел уже после Авито. Предложение в том, чтобы остановиться где-то посередине между 6NF и jsons. Коля начинает с того, что вспоминает про то, как работает star schema:
- У нас есть таблица фактов в сотни таблиц
- Большая часть таблицы разреженная
- Для анализа нужны joins на таблицы dimensions
- Каждое событие с парой атрибутов добавляет столбцы для все таблицы В общем, этот подход не работает для кликстрима - мы это не запихнем в условный ClickHouse и словарики слишком большие для joins.
Но вместо star schema можно использовать activity schema. Идея в том, чтобы сделать аналитику на одной таблице, где мы все события пытаемся представить как список активностей, происходящих с определенной сущностью. В итоге, табличка видит примерно так
- stream_id
- user_id
- event_id
- action_datetime
И у этого решения есть плюсы
- Быстрая и дешевая загрузка
- Колоночность. Компрессия. ClickHouse
- Удобная базовая аналитика: DAU/WAU/MAU, Funnels, Conversions Дальше Коля показывает как можно этот анализ делать прямо на примерах SQL запросах. А потом что же делать, если у событий есть дополнительные данные?
- Если атрибуты событий случаются часто, то их можно сунуть в основную схему
- Но если атрибуты случаются редко, то их можно унести в небольшие нормализированные таблицы с деталями (микс с data vault) - это таблицы-саттелиты Интересно, что это с первого взгляда похоже на star schema, но отличается кардинально:
- В star schema ссылки на dimensions идут из таблицы фактов
- В этой схеме у нас ссылки из таблиц-саттелитов на activity таблицу, которая ничего не знает про дополнительные атрибуты Это решает проблему с разряженными таблицами + позволяет реализовать фичи безопасности, так как sensitive атрибуты можно хранить в таблицах-саттелитах
А дальше Коля рассказывает про то, что в этой схеме можно еще сделать классификацию событий через теги, которые можно навешивать на события и это работает хорошо. Второй вариант классификации - это создание реестра метаданных, который сильно сложнее с точки зрения внедрения в процессы компании.
#Data #DWH #Processes #Management #Architecture #Software #SoftwareArchitecture