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

Темы для обсуждения:
• почему сейчас бизнес и 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

Data Mesh: Delivering Data-Driven Value at Scale

Недавно я ходил в книжный клуб моих коллег из data platform для обсуждения этой книги Zhamak Dehghani . Мы должны были обсудить девятую главу "The Logical Architecture", которую я и успел прочитать к записи выпуска, пропустив остальные главы, отчасти из-за того, что я эту концепцию помню с момента основания, а также видел ее разбор в разных книгах
- В 2019 году Zhamak Dehghani выступала про data mesh на многих конференциях, например, на QCon или на Software Architecture Conference в Берлине, которую я посетил лично
- В 2022 году вышла эта книга и Zhamak Dehghani приходила в книжный клуб goto обсудить эту книгу
- В книге "Learning DDD" Влада Хононова в одной из глав разбиралась на пальцах связь domain driven design и data mesh (и у меня есть краткий разбор тезисов)

Собственно, глава про логическую архитектуру начинается с воспоминаний о концепциях data mesh, а дальше идет попытка разобраться как их реализовать

1) Domain ownership extends domains with analytical data sharing interfaces
2) Data as a product introduces a new architecture quantum, aka data quantum
3) The self-serve data platform drives a multiplane platform architecture
4) Federated computational governance embeds computational policies into each data product

Дальше авторы много говорят про контракты по данным от доменов, а также про кросс-зависимости между доменами. Во втором авторы используют неоднозначное понятие архитектурного кванта, введенное в книге "Software Architecture: The Hard Parts", которую мы разбирали в подкасте "Code of Architecture". Это же понятие активно использовалось в книге "Building Evolutionary Architecture", которую мы тоже разбирали

An architectural quantum, defined in Building Evolutionary Architectures (O’Reilly), is the smallest unit of architecture that can be independently deployed, has high func‐ tional cohesion, and includes all the “structural elements required for its function.”

Из этого понятия архитектурного кванта у ребят рождается понятие data quantum, где ETL как бы внутри и абстрагирован от внешнего окружения. А сам квант представлен API: input data API, output data API, Discovery and observability API.
Дальше идет интересное обсуждение платформы и ее отдельных planes:
- Mesh experience plane
- Data product experience plane
- Infrastructure utility plane
Где самым интересным является первый уровень, так как именно он позволяет совместно использовать разные дата продукты, опубликованные командами отдельно. Отдельно отмечается, что вся эта платформа должна быть перевязана policies и standards для того, чтобы общая концепция не развалилась из-за децентрализованного подхода.

В общем и целом, подход интересный, но достаточно сложно реализуемый. Можно глянуть доклад про платформу данных Евгения Ермакова из toloka.ai, где они на практике шли в сторону data mesh целенаправленно, правда там фокус все-таки на dbt как ядре их платформы данных. Я делал краткое саммари этого доклада.

#Data #Datamesh #DWH #Processes #Management

Битва за прошлое. Как политика меняет историю - Part III (Рубрика #History)

Заканчиваю рассказывать про книгу "Битва за прошлое" обсуждением последней части "Прошлое как действие". Предыдущие посты можно почитать здесь: 1 и 2.
Собственно в этой части автор говорит о том, как День Победы стал референтной точкой для современной России - ведь имперское прошлое уже далеко, а советская ключевая дата в виде Великой Октябрьской социалистической революции уже перестала быть актуальной. В общем, вся эта часть про то, как прошлое влияет на действия в нашем текущем настоящем:) Рабирается история с делом Дениса Карагодина, где обычный выпускник Томского университета решил расследовать смерть своего деда, который стал жертвой Большого террора НКВД в начале 1938 года. Похожая история есть и в США, где 120к японцев переселили от Тихого океана во внутренние штаты.
Дальше автор разбирает историю с реконструкторами и том, как популярно играть в нацистов в США, где республиканского кандидата в члены конгресса в 2010 запечатлели в форме дивизии СС "Викинг". Интересно, что он участвовал в реконструкциях сражений и форму СС "Викинг" он и его группа выбрали из-за того, что эта дивизия воевала на восточном фронте против советской армии, а не против британцев или американцев. Собственно, в США память о победе во второй мировой войне может быть описана цитатой Трамппа из твиттера в 2020 году, где было написано, что. "8 мая 1945 года Америка и Великобритания победили нацистов", где СССР даже не упоминается:) А вообще в США реконструируют обычно времена их гражданской войны. А в России реконструкторское движение сейчас патронирует Министерство обороны, которое проводит масштабные мероприятия военно-исторических клубов в своем парке "Патриот".
Ну и последняя глава этой части посвящена движению "Бессмертный полк", которое появилось благодаря нескольким активным журналистам, а потом оказалось под крылом правительства. Это движение оказалось хорошим сделать так, чтобы память о ветеранах прожила дольше, чем они сами, так как их количество на Парадах Победы 9 мая все сокращалось. В итоге во вторую часть заглавия этой главы автор выносит риторический вопрос "Кому принадлежит память о войне".

Ну и финализирует книгу автор таким абзацем

Споры по поводу прошлого никуда не исчезнут, потому что причина их лежит в современности. История лишь предоставляет материал и язык для современного политического конфликта. Можно, однако, договориться о границах "исторических" конфлктов, как договариваются о неиспользовании некоторых приемов языка и конкретных слов в дипломатическом диалоге. Можно понять, что множественность прошлого теперь с нами навсегда. И научиться жить с ней.

#Management #Leadership #History #Strategy

ИТ Пикник (Рубрика #Software)

17 августа ИТ Пикник будет проходить во второй раз. Это большой семейный фестиваль для опытных IT'шников в Коломенском. Я думаю, что мероприятие будет еще масштабнее, чем в прошлом году и оно будет содержать следущие активности
- Лекции на разные темы - тут одним из треков будет трек по архитектуре, надежности и качеству. В прошлом году я был в программном комитете, а в этом пристроил ПК в руки своего зама, Антона Костерина
- Интерактив для детей и взрослых - тут будут мастер-класссы, шахматный турнир, робототехника, virtual reality, космонавтика и спорт
- Музыкальная часть фестиваля - тут будут крутые исполнители и хедлайнер, имя которого пока мы держим в секрете

Сам фестиваль организовали Т-Банк, CodeFest и Мельница, а также у фестиваля есть много крутых IT-партнеров.

Если вы хотите попасть на фестиваль, то простой трехшаговый алгоритм выглядит так:
1) Зарегистрируйтесь в форме, указав специальность (предполагается модерация заявок)
2) Дождитесь письма, где будет ссылка на внесение благотворительного взноса - для получения билета надо будет пожертвовать от тысячи рублей в один из фондов
3) Получите подтверждение регистрации и билет на указанную вами почту

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

#Conference #Software #SoftwareArchitecture #SRE