Потери вообще недопустимы. 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 еще не давал однозначного ответа) отлично готовят к новым толкованиям.
Привет-привет :)
В mail.ru я заглянул совсем ненадолго, понял, что мне важнее дух стартапа, и продолжил путь. Там норм, но перевести аналитику на бессерверное облачное решение вроде Snowflake там я бы не смог.
PS. В течении 2-3 месяцев выйдет еще одна статья от моей команды про нашу архитектуру. Anchor Modeling и бессерверная облачная база — далеко не единственный компонент нашего решения, который ранее в такой роли не применялся, но на удивление хорошо себя показал.
Кстати да, колоночность не является препятствием для OLTP. Она просто порождают меньшую эффективность обработки нагрузки, которую можно компенсировать железом.
В SAP Hana, и в одной из новых баз, MemSQL, насколько я знаю, применяется фокус с двойным хранением — данные хранятся дважды, в колонках, и в строках. Строчное хранение держит OLTP нагрузку, колоночное — OLAP нагрузку. Это в некотором роде передний край технологий.
Дилемма моделирования в рамках Data Vault/Anchor Modeling: объект или событие
Нет, просто поверх стрима появится новый атрибут. A_UserEvent_ClickOrTap, грубо говоря.
Дилемма моделирования в рамках Data Vault/Anchor Modeling: объект или событие
А откуда получается потеря сущностей (Anchor-ов)?
Потери вообще недопустимы.
USER clicked BUTTON - такое событие заполняет три сущности: UserEvent, User, Button.
Это обязательно и в классическом моделирование, и в концепции Streams.
Далее в классическом подходе нужно заполнить две связи (Link, Tie, Relation) событие->user, событие->button
А в концепции Streams ключевые связи интегрируются в денормализованную таблицу S_UserEvent, содержащую User_id и Button_id.
По поводу значительно количества событий - представьте, что аналитику нужно проанализировать все события, произошедшие с пользователем на сайте. Сколько таблиц ему нужно проанализировать? 10, 20.... или только одну: S_UserEvent?
Обзор гибких методологий проектирования DWH
Хранение же сейчас - это самое дешевое, что может быть :) ... в условном S3. Но если вы хотите с данными работать, а данные денормализованы - то при каждом запросы вы вынуждены поднимать с диска весь объем, а не только нужные вам поля.
Обзор гибких методологий проектирования DWH
Самое забавное, что как раз подход в видео по ссылке - уже немного устаревший. Он сильно упрощает работу дата-инженеров, но аналитикам с этим работать - сложно. Точнее так, там две части:
1. подход функционального инжиниринга, only-insert, идемпотентный код - полнстью поддерживаю. Все это очень помогает для любых методологий, как инструмент, особенно для Anchor Modeling (или для Data Vault с однодатной историчностью SCD2, без апдейтов).
2. Подход подневных снапшотов для отражения историчности - это фантастика для дата инженера, но ад для аналитика. В ManyChat такой подход сосуществовал с Anchor Modeling на протяжении года, мы его хорошо распробовали. Чтобы понять сложность для аналитиков - предлагаю такое упражнение: измерение Клиентов, с подневными снапшотам, где для клиента хранится, например, регион. Попытайтесь посчитать количество клиентов, которые за 2 года более чем 4 раз меняли регион...
Обзор гибких методологий проектирования DWH
В Авито сотни ТБ, Anchor Modeling ManyChat, на базе Snowflake - уже более 100 Тб.
Обзор гибких методологий проектирования DWH
Большое спасибо за статью, хорошее структурирование подходов, хочу ее показать коллегам, чтобы не пересказывать своими словами плюсы подхода именно в контексте гибкости.
PS. В августе планирую написать следующую статью, про новую, четвертую, сущность (кроме сущностей/атрибутов/связей), которая очень помогает работать с кликстримом... В Авито она сформировалась сама по себе, в ManyChat мы ее внедрили осознанно, и оказалось очень удобно.
PPS. Anchor Modeling ManyChat - уже больше 100Тб :)
На пути к бессерверным базам данных — как и зачем
Целостность данных в микросервисной архитектуре — как её обеспечить без распределенных транзакций и жёсткой связности
А сейчас я занимаюсь этим: habr.com/ru/company/manychat/blog/530054
Snowflake, Anchor Model, ELT и как с этим жить
Аналитикам проще с плоскими денормализованными (витринами), факт.
Но.
Витрины нужно спроектировать, реализовать ETL регулярного дополнения, и еще они хранят историю.
А теперь представьте что либо витрина плохо спроектирована, либо понимание бизнеса делает «резкий поворот». В таком случае ее нужно переделать, переложить данные истории, реализовать новый ETL и т.п… Долго, сложно, поэтому аналитика чисто на плоских витринах резкие повороты не любит.
В ManyChat «резкий поворот» — это каждодневная норма, такой регулярности изменений я раньше не видел нигде. Например, прямо сейчас Facebook Messenger канал дополняется Instagram и WhatsApp, и это самое мелкое изменение. Данные в 6НФ (+ история, +ETL, + проверки) не затрагиваются резкими поворотами, они только чуть дополняются. А аналитики собирают, поверх 6НФ, новые витрины, под новое понимание… и ждут следующего поворота :)
Snowflake, Anchor Model, ELT и как с этим жить
Про деньги — пока получается в разы дешевле возможных аналогов. :)
На пути к бессерверным базам данных — как и зачем
Раскрытие хинтов Вертики позволило нам выйти на новый уровень использования этой базы в Авито.
Сейчас мы очень плотно работаем с поддержкой 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, выполнение запроса.
В итоге, управление ресурсами — очень опосредованное.
На пути к бессерверным базам данных — как и зачем
Vertica+Anchor Modeling = запусти рост своей грибницы
PS. Скоро будут новые :)… про Anchor Modeling на бессерверных базах.
На пути к бессерверным базам данных — как и зачем
На пути к бессерверным базам данных — как и зачем
На пути к бессерверным базам данных — как и зачем
На пути к бессерверным базам данных — как и зачем
Год за годом видно, как в плане толкований и правоприменения 152ФЗ сближается с GDPR. И решения, принятые по GDPR (где 152 еще не давал однозначного ответа) отлично готовят к новым толкованиям.
На пути к бессерверным базам данных — как и зачем
В mail.ru я заглянул совсем ненадолго, понял, что мне важнее дух стартапа, и продолжил путь. Там норм, но перевести аналитику на бессерверное облачное решение вроде Snowflake там я бы не смог.
PS. В течении 2-3 месяцев выйдет еще одна статья от моей команды про нашу архитектуру. Anchor Modeling и бессерверная облачная база — далеко не единственный компонент нашего решения, который ранее в такой роли не применялся, но на удивление хорошо себя показал.
На пути к бессерверным базам данных — как и зачем
В SAP Hana, и в одной из новых баз, MemSQL, насколько я знаю, применяется фокус с двойным хранением — данные хранятся дважды, в колонках, и в строках. Строчное хранение держит OLTP нагрузку, колоночное — OLAP нагрузку. Это в некотором роде передний край технологий.