Шахматные звезды 4.0

Вчера получилось побывать на закрытии турнира "Шахматные звезды 4.0" и награждении победителей. Связано это было с тем, что генеральным партнером турнира является Т-Банк:) Параллельно взрослому турниру с крутыми участниками, проходили и детские турниры (до 9, до 11, до 13 и до 17 лет). Участникам детских турниров удалось поиграть в одном зале с участниками основного турнира. А основной турнир имел крутой состав: Карякин, Артемьев, Томашеский, Табатабаи, Садхвани, Хоу Ифань, Горячкина, Гунина, Лагно. В итоге, лучшей среди девушек стала Хоу Ифань, а среди мужчин - Владислав Артемьев. У турнира был крутой комментатор - Сергей Шипов, гроссмейстер и автор популярного youtube канала Crestbook Chess, который я периодически посматриваю во время крупных шахматных турниров.

В общем, классно, что этот шахматный турнир уже встал на рельсы и проводился в 4 раз. Плюс круто, что у молодых шахматистов есть возможность блеснуть на турнире и посмотреть и пообщаться с шахматными корифеями вживую. Думаю, что мы продолжим спонсировать этот турнир и помогать развитию шахмат в стране.

P.S.
Для меня это флешбеки из прошлого - я достаточно много турниров играл в детстве, когда еще с первого класса и до седьмого-восьмого ходил в ДЮСШ на занятия по шахматам:) Правда, я оказался слабоват в шахматах, поэтому переключился на математику и физику и дальше подналег на их изучение, чтобы поступить в итоге на Физтех.

P.P.S.
Сейчас дома со своими детишками пробую играть в шахматы, когда есть время. Иногда получается, но я вижу как им сложновато держать фокус, особенно когда рядом (в телефоне) есть игры попроще, а на телевизоре есть развлечения позрелищнее (мультики). Но мне кажется, что учить шахматам детей стоит - это поможет научиться фокусироваться, оценивать позицию, планировать свои действия и так далее

#Chess #SelfDevelopment

Уже второй раз поучаствовал в благотворительном аукционе Meet For Charity, где благотворитель мог на аукционе приобрести возможность пообщаться со мной. Как и в прошлый раз все пожертвованные даньги отправились в фонд "Нить добра", который был создан в целях осуществления благотворительной деятельности, направленной на реабилитацию детей и подростков с онкологическими и другими тяжёлыми заболеваниями. В принципе, у организаторов в канале есть и другие интересные лоты, так что если есть желание пообзащаться с кем-то интересным тет-а-тет, а также помочь одному из фондов, то you are welcome.

P.S.
На этой неделе как раз встречался с благотворителем, который пожертвовал деньги в фонд, и мы достаточно интересно пообщались по широкому кругу вопросов.

#Charity #Software #Management #Leadership

«Т-Банк» — больше, чем просто финансовые услуги: на платформе выстроена полноценная экосистема сервисов. Как она устроена с точки зрения технологий, расскажет Александр Поломодов — технический директор «Т-Банк». 

Темы для обсуждения:
• почему сейчас бизнес и IT должны быть на одной волне;
• как выглядят эффективные процессы разработки и почему они зависят от размера и жизненного цикла компании и продукта;
• как выстроить архитектурные процессы в компании;
• как нанимать сильных инженеров (разработчиков, QA-инженеров и т.д.);
• как появление искусственного интеллекта изменило расклад на рынке разработки.

Ссылка на лот: https://clck.ru/3BBnNN

#MeetForCharityЛоты

Leetcode - прогресс за полгода (Рубрика #SelfDevelopment)

Вот уже полгода я на leetcode, специально под этот полуюбилей я сделал так, чтобы у меня было 404 решенных задачи:) Полмесяца все шло хорошо, но потом случился выезд в Калиниград и ритуал был нарушен и только к концу месяца я оклемался. К сожалению, я так и не начал курс "System Design for Interviews and Beyond", но почти закончил курс "Data Structures and Algorithms", а дополнительно начал "Top Interview Questions (Easy Collection)" и "Google Interview". В общем, с таким набором разных курсов как-то интереснее играть с задачками, которые теперь я решаю примерно полчасика-часик в день:)

P.S.
Предыдущие посты на эту тему доступны здесь: 1, 2, 3, 4, 5 и 6

#SelfDevelopment #Algorithm #Software #SoftwareDevelopment

Моделирование потоков событий в эволюционирующем окружении - Николай Голов - 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

Головоломка БондиЛогика (Рубрика #Kids)

Пока папа решает easy задачки на leetcode младший сын собирает головоломки из машинок на уровне новичок:) Там сначала заполняешь парковку, а потом пытаешься вывести скорую помощь из лабиринта:)

#ForKids #SelfDevelopment

Code of leadership #16 - The Five Dysfunctions of a Team (Рубрика #Management)

Шестнадцатый выпуск подкаста про лидерство посвящен книге "5 пороков команды", которую написал Патрик Ленсиони в жанре бизнес-романа еще в 2002 году. Эта книга направлена на лидеров, которые хотят сделать свою команду эффективнее. Но этому мешают ряд факторов, которых автор насчитал целых пять штук, которые выстраиваются в пирамиду (подробнее в прошлом посте про эту книгу)

Я обсуждаю эту книгу с Андреем Соколовым, экспертом в области эффективных коммуникаций для бизнес-сообщества с 20-летним стажем. У Андрея есть курс по сторителлингу, часть из которого я раньше успел пройти. Для зрителей и слушателей нашего стрима есть скидка в 20% для записи в июльскую или августовскую группу 2024 года. Достаточно использовать кодовое слово "Книжный куб".

#Management #Leadership #PublicSpeaking #Storytelling #Culture

Обеспечение качественных ETL на Vertica - Александр Крашенинников - SmartData 2023 - Part 1 (Рубрика #Architecture)

Интересный доклад от Саши Крашенниникова из Т-Банк про то, как сделать обеспечить бизнес качественными данными причем не только на Vertica:) В докладе замиксованы как процессные, так и технологические моменты, а сам доклад основан на опыте Саши, который он получил еще вне Т-Банка, но сейчас использует на благо нашей компании:) Ну и бонусом к техническим компетенциям Саши идет отличный стиль подачи материала - с юмором и крайне доступно, рекомендую к просмотру в оригинале. Но кому лень смотреть суть примерно такая.

Собственно, все начинается с того, что компания успешна, есть запрос на аналитику по данным. Для решения задачи решают гонять все поверх могучей MPP (massive parallel processing) базы данных. В качестве MPP базы выбирают Vertica, которая является классикой MPP баз (multi-node, column store), ACID совместимая, без SPOF (single point of failure), быстрая и щедрая на системную информацию (что можно использовать для улучшения процессов). Пока все звучит хорошо, но надо добавить, что она проприетарная и сильно платная:) Процессы выглядят так, что инженеры данных привозят "сырье", пользователи сами пишут ETL и выводят его в прод. Все работает ... до какого-то момента.

Но дальше начались проблемы
- "База тормозит" - запуск тяжелых запросов, которые аффектят остальные запросы. Решение через квотирование является стандартным, но квотирование не решает проблем чтения с диска, передачи по сети, перекос нагрузки, "нецелевое" использование базы
- Поверх стандартного квотирования добавляется query watchdog для мониторинга и оптимизации запросов. Часть запросов отстреливаются этим сервисом и отправляется оповещение автору запроса
- Отдельно Саша раскрывает как может выглядеть "нецелевое" использование базы - например, это может быть OLTP-style нагрузкой или однопоточной интеграцией данных. Для выявления запросов в стиле OLTP можно накрутить поиск дублирующихся запросов. А однопоточная интеграция приводит к перегреву узла, через который проходит запрос (например, узла-координатора в Greenplum). Это можно детектировать по системной информации

Дальше Саша рассказывает про то, как они выстраивали процесс обучения пользователей использованию MPP. Ключевыми моментами обучения были
- Структурированная подача информации в курсе
- Тесты для самопроверки
- Аттестация по окончанию курса

В сам курс ребята включили
- Вводную часть про MPP
- Ключевые отличия от single-node баз данных
- Для чего используется в организации
- Как подключиться
- Базовый query language
- Хранение: шардирование, data-locality, сортировка
- Оптимизации: типы joins, group by
- Оптимизации: неточный distinct, argmax

Дальше Саша показывает примеры задачек в рамках курса + рассказывает как сделать прохождение курса обязательным для инженеров, у которых есть роли с доступом к MPP базе. Классно еще сделать возможность запускать локально базу для экспериментов, а также собирать фидбек по самому курсу.

Но остаются запросы
- А что является нормальным?
- Справедливо ли распределение ресурсов?
- Может уже пора заливать проблему железом?

Для определения границ нормальности надо собирать телеметрию по запросам и кластеризовать их, а дальше анализировать аномалии. Эксперты анализируют OLAP куб и выявляют проблемы, коммуницируют с владельцами кода для исправления. Если проблема не решена, блокируют учетную запись и форсируют авторов кода на исправление.

Вообще, стоит составить рейтинг пользователей по дефектам
- Дефекты - это ошибки проектирования структуры таблиц и процессов.
- Дефекты делятся на статические и динамические, первые не влияют на работу базы, вторые влияют.
- Примеры статических дефектов: использование типов данных, не оптимизированных для работы с текстом и числами.
- Примеры динамических дефектов: использование внешних функций, которые могут привести к избыточному использованию ресурсов базы.

Конкретные примеры работы с дефектами в посте-продолжении.

#Data #DWH #Processes #Management #Architecture #Software #SoftwareArchitecture

Обеспечение качественных ETL на Vertica - Александр Крашенинников - SmartData 2023 - Part 2 (Рубрика #Architecture)

В первый пост по этому докладу не поместились все практические советы Саши, поэтому продолжим

Для построения аналитики стоит построить OLAP куб с компонентами
- Измерения: время, учетная запись, ресурсная группа, узел кластера
- Показатели: sum/skew/avg/q50/q75/q90/q99 по метрикам запросов
- Время: CPU, общее время
- RAM
- Объемы данных: чтение/запись по диску, чтение/запись по сети
- Число запросов
- COST

Ну а дальше работа с дефектами - когда проблемы имеют схожие паттерны, которые можно разделить на
- Статические - данные лежат спокойно, но больно станет, когда придется с ними работать (таблицы, колонки)
- Динамические - это уже сейчас работает не оптимально (запросы и последовательности запросов)

Статические дефекты данных
- Хранение и обработка текстовой информации в VARCHAR - если мы просим VARCHAR(2048), а пишем туда 2 символа, то мы имеем доп накладные расходы, а при использовании UDF (user defined functions) мы действительно будем занимать все 2kb даже если напишем 2 символа
- numeric с управлением точности числа - больше точность, больше места на диске, а при несовпадении типов у нас тратится CPU и RAM на их приведение. Обычно хватает numeric(18, 4) в 90% случаев (что занимает места как int64)
- Сортировка - важно сортировать по меньшему полю + слишком много полей для сортировки может быть ошибкой
- Распределение данных (шардинг) - шардинг по меньшему полю + правильное использование несегментированных таблиц. Использование сегментации по float может быть ошибкой (из-за плавающей точности и распределения близких значений по разным нодам)
- Партиционирование - по правильному полю + большое партицируем на не слишком много партиций, если маленькое, то не партицинируем
- Перекос данных - перекошенные данные тормозят все запросы, надо с перекосами бороться. Саша показывает как это делать с NULL полями
- И еще куча проблем

Динамические дефекты данных
- Динамические дефекты данных могут быть связаны с уязвимостями и "дурным запахом" в уже работающих запросах.
- Например, если запрос генерирует много временных данных, это может быть признаком ошибки, и запрос может быть отстрелен рано или поздно.
- Если запрос передает много данных по сети, это также может быть признаком ошибки, и запрос может быть отстрелен за это.
- Если запрос обновляет данные в ходе выполнения, и это превышает определенный размер, это может быть признаком ошибки, а запрос может быть оптимизирован для использования инкрементального обновления.

Оптимизация запросов
- Суммарное чтение данных не масштабируется, необходимо оптимизировать процесс и перейти на инкрементальное обновление.
- Перекос данных может привести к проблемам с производительностью.
- Важно пересмотреть процесс, если он не масштабируется.

Проблемы с производительностью
- Объем временных данных на одном узле может вызвать проблемы с производительностью.
- Неявные коммиты и множественные sql инструкции могут вызвать ошибки и false positive.
- Важно обучать пользователей правилам игры и границам дозволенного.

Выводы
- Квотируйте ресурсы на самом старте
- Обозначайте правила игры с базами данных и границы дозволенного
- Обучайте пользователей - документаци, воркшопы, ...
- Собирайте аналитику по деятельности процессов
- Не бойтесь отстреливать проблемные процессы
- Создавайте прозрачность для пользователей про показатели их процессов

#Data #DWH #Processes #Management #Architecture #Software #SoftwareArchitecture