Как стать автором
Обновить
55
Карма
0
Рейтинг
Николай Голов @azathot

Пользователь

Дилемма моделирования в рамках 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Тб :)

На пути к бессерверным базам данных — как и зачем

Поэтому люди, которые жалеют железо, так не делают. А те, кому бизнес важнее, вполне готовы рискнуть.

Целостность данных в микросервисной архитектуре — как её обеспечить без распределенных транзакций и жёсткой связности

Разве что вот так: www.youtube.com/watch?v=bAhxpqHfP8I&list=PLdMXteIaGViJFoRUOoPjYaNqZFJY64TYr :)… Про авито и микросервисы, но уже после ухода из Авито.
А сейчас я занимаюсь этим: 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, чтобы получить хоть немного больше контроля, хотя бы на уровне хинтов.
Но пока доступный контроль минимален.

На пути к бессерверным базам данных — как и зачем

… А вы с кем с команде разработки 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 на бессерверных базах.

На пути к бессерверным базам данных — как и зачем

К сожалению да, serverless OLTP база на замену MySQL пока недостижимая мечта… Тем лучше будет позиция тех, кто первым создаст или эмулирует такое решение.

На пути к бессерверным базам данных — как и зачем

Выбор такого решения был чисто экономический. AM как раз здорово позволило управлять костами Snowflake, за счет мелкой автоматической декомпозиции каждой операции. В итоге огромная доля расчетов и сервисных операций идет на XS и S кластерах. Кластера, сравнимы по костам с полноценной аналитической инсталляцией (L, XL, ...) работают только несколько минут в день.

На пути к бессерверным базам данных — как и зачем

А представьте, что и базу можно было бы делать serverless? :)… Про это и статья.

На пути к бессерверным базам данных — как и зачем

И вы не читайте :)… И будет вам каждый год сюприз.
Год за годом видно, как в плане толкований и правоприменения 152ФЗ сближается с GDPR. И решения, принятые по GDPR (где 152 еще не давал однозначного ответа) отлично готовят к новым толкованиям.

На пути к бессерверным базам данных — как и зачем

Привет-привет :)
В mail.ru я заглянул совсем ненадолго, понял, что мне важнее дух стартапа, и продолжил путь. Там норм, но перевести аналитику на бессерверное облачное решение вроде Snowflake там я бы не смог.
PS. В течении 2-3 месяцев выйдет еще одна статья от моей команды про нашу архитектуру. Anchor Modeling и бессерверная облачная база — далеко не единственный компонент нашего решения, который ранее в такой роли не применялся, но на удивление хорошо себя показал.

На пути к бессерверным базам данных — как и зачем

Кстати да, колоночность не является препятствием для OLTP. Она просто порождают меньшую эффективность обработки нагрузки, которую можно компенсировать железом.
В SAP Hana, и в одной из новых баз, MemSQL, насколько я знаю, применяется фокус с двойным хранением — данные хранятся дважды, в колонках, и в строках. Строчное хранение держит OLTP нагрузку, колоночное — OLAP нагрузку. Это в некотором роде передний край технологий.

Информация

В рейтинге
Не участвует
Откуда
Erewan, Yerevan, Армения
Работает в
Дата рождения
Зарегистрирован
Активность