Pull to refresh
56
0
Николай Голов @azathot

User

Send message

Привет-привет, сколько всего интересного :) ... Хотя очень большая статья, неподготовленный человек может и утонуть.
Думаю, многим будет интересно, подключение спарка сейчас много где актуально.

Нет, просто поверх стрима появится новый атрибут. 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Тб :)

Поэтому люди, которые жалеют железо, так не делают. А те, кому бизнес важнее, вполне готовы рискнуть.
Я возможно напишу про это следующую статью.
Аналитикам проще с плоскими денормализованными (витринами), факт.
Но.
Витрины нужно спроектировать, реализовать 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, выполнение запроса.

В итоге, управление ресурсами — очень опосредованное.
В этой терминологии вообще все базы данных — файловые субд, без исключений. т.к без файлов на диске нигде не обошлись.
Так можно на автора клинуть, и там все мои статьи будут :)…
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 и бессерверная облачная база — далеко не единственный компонент нашего решения, который ранее в такой роли не применялся, но на удивление хорошо себя показал.

Information

Rating
Does not participate
Location
Erewan, Yerevan, Армения
Works in
Date of birth
Registered
Activity