Головоломка БондиЛогика (Рубрика #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

Turbo ML Conf (Рубрика #ML)

Астрологи объявили неделю анонсов мероприятий Т-Банка, поэтому я расскажу сегодня про первую ML конференцию, которую мы приоводим 20 июля для всех, кто занимается машинным обучением. Организаторы говорят, что посетить ее будет интересно всем: исследователям, ML-инженерам, SDE инженерам, техлидам и даже тимлидам.
 
Конференция состоит из плотной программы из технических докладов, а также вечернего афтепати. Там будет:
- Четыре потока — NLP & MLOps/LLMOps, Research & RnD, CV & Speech и RecSys & TS;
- Кейсы лидеров индустрии — заглянем в самое сердце AI-продуктов Т-Банка, VK, SberDevices, Яндекса, MTS AI, AIRI, Lamoda и других бигтехов;
- Афтепати, нетворкинг и уникальные челленджи, чтобы проверить свои скиллы на деле.

Мерооприятие пройдет в Москве в Гоэлро Лофте, на сайте есть форма регистрации, так что у желающих есть возможность попробовать добыть билетик.

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

#Conference #Software #ML #DataScience

Бизнес-линии, сервис-линии и платформы @ T-Bank - Part III - (Рубрика #Management)

Продолжу первые два поста (1 и 2) и расскажу как мы из квази-продуктовой команды делали платформу. Здесь речь идет про Мобильный Банк, о котором я рассказывал много раз и раньше, но самый сочный рассказ был на Higload ++ Spb 2022. Но для этого поста я сокращу его до кратких тезисов:
- До конца 2019 года Мобильный Банк Тинькофф рассматривался как самостоятельный продукт, который развивался и побеждал во всех рейтингах вида MarksWebb
- Команда была монолитной и со своими приоритетами, где фокус был на кредитных и дебетовых продуктах, а также лайфстайл сервисах
- Но в 2019 году компания решила, что Мобильный Банк должен стать супераппом, в котором представлены все бизнес-вертикали (из терминологии первого поста)
- В этой концепции мобильный банк должен был стать платформой, а точнее позволить продуктовым командам бизнес-вертикалей автономно разрабатывать свои фичи внутри приложения
- Для того, чтобы это работало надо было выделить платформенные команды, которые позволяли бы обеспечивать такие вещи как: согласованная архитектура приложения, общие инструменты для тестирования, сборки, производительности, надежности, дизайн решений

В момент перехода мы, фактически провернули обратный маневр Конвея, а точнее
- Уловили цели и задачи бизнеса
- Выяснили какая архитектура потребуется под их решение
- Выработали правильный оргдизайн команд, границы ответственности, процессы работы
Дальше мы несколько лет шли в сторону платформизации и сейчас все продуктовые команды мобильного банка и API уехали в свои бизнес-вертикали, а у меня в юните осталось управление разработки клиенстких интерфейсов (УРКИ), в котором остались платформенные команды:) Я считаю, что это преобразование прошло успешно и мы достигли тех целей, которые ставили перед собой, когда запускали эти изменения. Подробнее почитать про этот кейс можно в моей статье или посмотреть видео-записи выступления.

P.S.
В общем про подходы формирования структуры команд под запросы бизнеса я рассказывал раньше в постах про
- структуру команд
- проектный подход
- продуктовую разработку

А также рассказывал про это на конференции Yandex под конец 2023 года

#Management #Leadership #Software #Processes