Привет-привет, сколько всего интересного :) ... Хотя очень большая статья, неподготовленный человек может и утонуть. Думаю, многим будет интересно, подключение спарка сейчас много где актуально.
Потери вообще недопустимы. USER clicked BUTTON - такое событие заполняет три сущности: UserEvent, User, Button.
Это обязательно и в классическом моделирование, и в концепции Streams.
Далее в классическом подходе нужно заполнить две связи (Link, Tie, Relation) событие->user, событие->button А в концепции Streams ключевые связи интегрируются в денормализованную таблицу S_UserEvent, содержащую User_id и Button_id.
По поводу значительно количества событий - представьте, что аналитику нужно проанализировать все события, произошедшие с пользователем на сайте. Сколько таблиц ему нужно проанализировать? 10, 20.... или только одну: S_UserEvent?
Хранение же сейчас - это самое дешевое, что может быть :) ... в условном S3. Но если вы хотите с данными работать, а данные денормализованы - то при каждом запросы вы вынуждены поднимать с диска весь объем, а не только нужные вам поля.
Самое забавное, что как раз подход в видео по ссылке - уже немного устаревший. Он сильно упрощает работу дата-инженеров, но аналитикам с этим работать - сложно. Точнее так, там две части: 1. подход функционального инжиниринга, only-insert, идемпотентный код - полнстью поддерживаю. Все это очень помогает для любых методологий, как инструмент, особенно для Anchor Modeling (или для Data Vault с однодатной историчностью SCD2, без апдейтов). 2. Подход подневных снапшотов для отражения историчности - это фантастика для дата инженера, но ад для аналитика. В ManyChat такой подход сосуществовал с Anchor Modeling на протяжении года, мы его хорошо распробовали. Чтобы понять сложность для аналитиков - предлагаю такое упражнение: измерение Клиентов, с подневными снапшотам, где для клиента хранится, например, регион. Попытайтесь посчитать количество клиентов, которые за 2 года более чем 4 раз меняли регион...
Большое спасибо за статью, хорошее структурирование подходов, хочу ее показать коллегам, чтобы не пересказывать своими словами плюсы подхода именно в контексте гибкости.
PS. В августе планирую написать следующую статью, про новую, четвертую, сущность (кроме сущностей/атрибутов/связей), которая очень помогает работать с кликстримом... В Авито она сформировалась сама по себе, в ManyChat мы ее внедрили осознанно, и оказалось очень удобно.
PPS. Anchor Modeling ManyChat - уже больше 100Тб :)
Я возможно напишу про это следующую статью.
Аналитикам проще с плоскими денормализованными (витринами), факт.
Но.
Витрины нужно спроектировать, реализовать ETL регулярного дополнения, и еще они хранят историю.
А теперь представьте что либо витрина плохо спроектирована, либо понимание бизнеса делает «резкий поворот». В таком случае ее нужно переделать, переложить данные истории, реализовать новый ETL и т.п… Долго, сложно, поэтому аналитика чисто на плоских витринах резкие повороты не любит.
В ManyChat «резкий поворот» — это каждодневная норма, такой регулярности изменений я раньше не видел нигде. Например, прямо сейчас Facebook Messenger канал дополняется Instagram и WhatsApp, и это самое мелкое изменение. Данные в 6НФ (+ история, +ETL, + проверки) не затрагиваются резкими поворотами, они только чуть дополняются. А аналитики собирают, поверх 6НФ, новые витрины, под новое понимание… и ждут следующего поворота :)
К сожалению, это еще не хинты, это примерно на один уровень контроля слабее.
Раскрытие хинтов Вертики позволило нам выйти на новый уровень использования этой базы в Авито.
Сейчас мы очень плотно работаем с поддержкой Snowflake, чтобы получить хоть немного больше контроля, хотя бы на уровне хинтов.
Но пока доступный контроль минимален.
… А вы с кем с команде разработки Snowflake общаетесь, чтоб привет передать?…
Просто есть маркетинг, и есть технические нюансы. В описанной вами статье речь идет не о сравнении с serverless databases, а с serverless query engines, вычленяемых ими, прежде всего, по ценообразованию.
В Snowflake вы не можете «управлять» вычислительными ресурсами, как в managed databases вроде RDS. Вы можете указывать тип вычислительных ресурсов, рекомендовать конкретный ресурс, но без жесткого контроля.
Простейший пример — вы создаете кластер размера M, задаете ему коэффициент скалирования 0-3, и направляете в него, например, 5 последовательных однотипных тяжелых запросов (работающих с идентичными исходными данными, но по разному).
Первый запрос из 5, очевидно, будет сильно медленней, т.к. он упадет в «непрогретый» кластер, и потребует перекачки исходных данных из S3.
Но означает ли это, что остальные 4 выполнятся быстрее, сравнимо быстро? Нет, т.к. возможен, например, следующий сценарий:
1 запрос: старт кластера M1 (Размер Medium, первая копия), наполнение данными из S3, выполнение запроса.
2 запрос: уже поднятый кластер M1, данные уже загружены, только выполнение запросов.
3 запрос: оптимизатор принимает решение, что M1 перегружен. Старт кластера M2 (Размер Medium, вторая копия), наполнение данными из S3, выполнение запроса.
4 запрос: оптимизатор принимает решение, что M1 и M2 перегружены. Старт кластера M3 (Размер Medium, третья копия), наполнение данными из S3, выполнение запроса.
5 запрос: кластер M1 потерян (сбой, перезагрузка), M2 и M3 перегружены. Старт кластера M1 (Размер Medium, первая копия), наполнение данными из S3, выполнение запроса.
В итоге, управление ресурсами — очень опосредованное.
К сожалению да, serverless OLTP база на замену MySQL пока недостижимая мечта… Тем лучше будет позиция тех, кто первым создаст или эмулирует такое решение.
Выбор такого решения был чисто экономический. AM как раз здорово позволило управлять костами Snowflake, за счет мелкой автоматической декомпозиции каждой операции. В итоге огромная доля расчетов и сервисных операций идет на XS и S кластерах. Кластера, сравнимы по костам с полноценной аналитической инсталляцией (L, XL, ...) работают только несколько минут в день.
И вы не читайте :)… И будет вам каждый год сюприз.
Год за годом видно, как в плане толкований и правоприменения 152ФЗ сближается с GDPR. И решения, принятые по GDPR (где 152 еще не давал однозначного ответа) отлично готовят к новым толкованиям.
Так 5 лет прошло....
Привет-привет, сколько всего интересного :) ... Хотя очень большая статья, неподготовленный человек может и утонуть.
Думаю, многим будет интересно, подключение спарка сейчас много где актуально.
Нет, просто поверх стрима появится новый атрибут. A_UserEvent_ClickOrTap, грубо говоря.
А откуда получается потеря сущностей (Anchor-ов)?
Потери вообще недопустимы.
USER clicked BUTTON - такое событие заполняет три сущности: UserEvent, User, Button.
Это обязательно и в классическом моделирование, и в концепции Streams.
Далее в классическом подходе нужно заполнить две связи (Link, Tie, Relation) событие->user, событие->button
А в концепции Streams ключевые связи интегрируются в денормализованную таблицу S_UserEvent, содержащую User_id и Button_id.
По поводу значительно количества событий - представьте, что аналитику нужно проанализировать все события, произошедшие с пользователем на сайте. Сколько таблиц ему нужно проанализировать? 10, 20.... или только одну: S_UserEvent?
Хранение же сейчас - это самое дешевое, что может быть :) ... в условном S3. Но если вы хотите с данными работать, а данные денормализованы - то при каждом запросы вы вынуждены поднимать с диска весь объем, а не только нужные вам поля.
Самое забавное, что как раз подход в видео по ссылке - уже немного устаревший. Он сильно упрощает работу дата-инженеров, но аналитикам с этим работать - сложно. Точнее так, там две части:
1. подход функционального инжиниринга, only-insert, идемпотентный код - полнстью поддерживаю. Все это очень помогает для любых методологий, как инструмент, особенно для Anchor Modeling (или для Data Vault с однодатной историчностью SCD2, без апдейтов).
2. Подход подневных снапшотов для отражения историчности - это фантастика для дата инженера, но ад для аналитика. В ManyChat такой подход сосуществовал с Anchor Modeling на протяжении года, мы его хорошо распробовали. Чтобы понять сложность для аналитиков - предлагаю такое упражнение: измерение Клиентов, с подневными снапшотам, где для клиента хранится, например, регион. Попытайтесь посчитать количество клиентов, которые за 2 года более чем 4 раз меняли регион...
В Авито сотни ТБ, Anchor Modeling ManyChat, на базе Snowflake - уже более 100 Тб.
Большое спасибо за статью, хорошее структурирование подходов, хочу ее показать коллегам, чтобы не пересказывать своими словами плюсы подхода именно в контексте гибкости.
PS. В августе планирую написать следующую статью, про новую, четвертую, сущность (кроме сущностей/атрибутов/связей), которая очень помогает работать с кликстримом... В Авито она сформировалась сама по себе, в ManyChat мы ее внедрили осознанно, и оказалось очень удобно.
PPS. Anchor Modeling ManyChat - уже больше 100Тб :)
А сейчас я занимаюсь этим: habr.com/ru/company/manychat/blog/530054
Аналитикам проще с плоскими денормализованными (витринами), факт.
Но.
Витрины нужно спроектировать, реализовать ETL регулярного дополнения, и еще они хранят историю.
А теперь представьте что либо витрина плохо спроектирована, либо понимание бизнеса делает «резкий поворот». В таком случае ее нужно переделать, переложить данные истории, реализовать новый ETL и т.п… Долго, сложно, поэтому аналитика чисто на плоских витринах резкие повороты не любит.
В ManyChat «резкий поворот» — это каждодневная норма, такой регулярности изменений я раньше не видел нигде. Например, прямо сейчас Facebook Messenger канал дополняется Instagram и WhatsApp, и это самое мелкое изменение. Данные в 6НФ (+ история, +ETL, + проверки) не затрагиваются резкими поворотами, они только чуть дополняются. А аналитики собирают, поверх 6НФ, новые витрины, под новое понимание… и ждут следующего поворота :)
Про деньги — пока получается в разы дешевле возможных аналогов. :)
Раскрытие хинтов Вертики позволило нам выйти на новый уровень использования этой базы в Авито.
Сейчас мы очень плотно работаем с поддержкой Snowflake, чтобы получить хоть немного больше контроля, хотя бы на уровне хинтов.
Но пока доступный контроль минимален.
Просто есть маркетинг, и есть технические нюансы. В описанной вами статье речь идет не о сравнении с serverless databases, а с serverless query engines, вычленяемых ими, прежде всего, по ценообразованию.
В Snowflake вы не можете «управлять» вычислительными ресурсами, как в managed databases вроде RDS. Вы можете указывать тип вычислительных ресурсов, рекомендовать конкретный ресурс, но без жесткого контроля.
Простейший пример — вы создаете кластер размера M, задаете ему коэффициент скалирования 0-3, и направляете в него, например, 5 последовательных однотипных тяжелых запросов (работающих с идентичными исходными данными, но по разному).
Первый запрос из 5, очевидно, будет сильно медленней, т.к. он упадет в «непрогретый» кластер, и потребует перекачки исходных данных из S3.
Но означает ли это, что остальные 4 выполнятся быстрее, сравнимо быстро? Нет, т.к. возможен, например, следующий сценарий:
1 запрос: старт кластера M1 (Размер Medium, первая копия), наполнение данными из S3, выполнение запроса.
2 запрос: уже поднятый кластер M1, данные уже загружены, только выполнение запросов.
3 запрос: оптимизатор принимает решение, что M1 перегружен. Старт кластера M2 (Размер Medium, вторая копия), наполнение данными из S3, выполнение запроса.
4 запрос: оптимизатор принимает решение, что M1 и M2 перегружены. Старт кластера M3 (Размер Medium, третья копия), наполнение данными из S3, выполнение запроса.
5 запрос: кластер M1 потерян (сбой, перезагрузка), M2 и M3 перегружены. Старт кластера M1 (Размер Medium, первая копия), наполнение данными из S3, выполнение запроса.
В итоге, управление ресурсами — очень опосредованное.
PS. Скоро будут новые :)… про Anchor Modeling на бессерверных базах.
Год за годом видно, как в плане толкований и правоприменения 152ФЗ сближается с GDPR. И решения, принятые по GDPR (где 152 еще не давал однозначного ответа) отлично готовят к новым толкованиям.