Книжный куб

Канал "Евгений Козлов пишет про IT" (Рубрика #Recommendation) Мой коллега ведет интересный канал @careerunderhood, в котором он делится своим опытом. Я сам подписан на этот канал и почитываю его, ведь Женя в отличие от меня своими руками и руками своей команды делает сложные и высоконагруженные продукты. Он руководит командой разработки Statist - это наш внутренний инструмент для продуктовой аналитики, который заменил нам Amplitude (я про него уже рассказывал). Со времен замены мы выросли по объемам хранения в несколько раз, а Женя и его ребята успешно справляются с этим ростом и косты на эксплуатацию этого решения растут сублинейно. В общем, Женя - молодец, у него хороший блог и хорошая команда, в которой можно попробовать применить те подходы, что рассказывал Мартин Клеппман в "Кабанчике" (или более официально "Designing Data Intensive Application"). Кстати, иногда в своем блоге Женя пишет о вакансиях, которые открываются в его команду, как было в середине мая - https://t.me/careerunderhood/283 P.S. Кстати, один из выпусков "Code of Leadership" был с руководителем Жени, Андреем Цыбиным, где мы обсуждали путь Андрея и Statist как продукт в общем. #Analytics #Architecture #DistributedSystems #Management

Working Backwards: Insights, Stories, and Secrets from Inside Amazon (Стратегия Amazon) (Рубрика #Management) Интересная книга про Amazon и какие подходы позволили им вырасти в одну из крупнейших компаний в мире. В заглавие оригинальной книги вынесена основа этого подхода - "working backwards", где ребята идут от клиентов в обратную сторону и выстраивают свою работу так, чтобы сделать оптимальные продукты и сервисы для клиентов и для компании. Они не слишком ориентируются на конкурентов и играют при этом вдолгую. Честно говоря, перевод книги на русский достаточно сомнительный, но читать вполне можно. Сама книга состоит из двух частей: 1) Быть Амазонцем, где авторы рассказывают про - Принципы лидерства и механизмы - Процесс Bar Raiser для найма лучших - Однопотокое руководство - про выстраивание stream-aligned команд и фокусе руководителей на достижении целей этого стрима - Одно- и шестистраничники вместо презентаций - Working backwards - как начанать с клиентского опыта и двигаться в обратную сторону - Показатели - как управлять входными, а не выходными показателями:) 2) Машина для изобретений в действии - здесь авторы рассказывают про создание Kindle, Prime, Prime Video и AWS. Видно как подходы из первой части книги реализуются при создании продуктов внутри Amazon В общем, рекомендую книгу для чтения - она определенно дает пищу для размышлений. Отдельно потом напишу некоторые главы из этой книги. #Management #Leadership #Processes

Гэмба (Рубрика #Management) Это интересный подход характерный для японской управленческой практики кайдзен, согласно которому для полноценного понимания ситуации считается необходимым прийти на гэмба - место выполнения рабочего процесса, собрать факты и непосредственно на месте принять решение. Этот подход может давать много инсайтов. Обычно я практикую его относительно IT деятельности, когда погружаюсь в ключевые бизнесовые направления, дизайн решений, код в конце концов. Но сейчас я отправился на практику представителем, которые в нашей компании взаимодействуют с клиентами, доставляя наши продукты. Причем для полноты ощущений я улетел на практику в Оренбург, так как работа представителем в Москве или Питере отличается от работы в регионах. Мне предстоит 3 интересных дня для погружения в выполнение рабочего процесса:) Надеюсь, что по их окончанию практики у меня появятся какие-то инсайты по тому, как сделать наше обслуживание еще лучше. А пока надо допройти онлайн обучение этой профессии и ложиться спать - завтра меня ждет интересный день:) #Management #Processes #Leadership

Interview with Product Manager in 2024 [Corporate] Еще одно отличное видео про профессии в IT, но в этот раз про product менеджеров в enterprise (в прошлый раз я писал про agile коучей). Здесь и про dog fooding, целепологание и синхронизацию бизнеса и IT, про поитику, процессы и эмоции, ведение JIRA и использование почты и так далее. Мне особенно понравились эти цитаты

- Politics over progress, processes over logic, emotions over process - We did not meet our OKRs this quarter, we need to change our OKRs - I have never used our product - I’m not saying they know what they’re doing, I’m just saying I really don’t care - We have a tool to consolidate our documents... my downloads folder - I'm gonna issue a Jira ticket, but I'll send it by email... so you will forget. - Nobody has a clue what we're doing - I barely know the names of most of the people on our team - We define the requirements at the beginning of the project. Changes come in through change-requests. We do have the agile manifesto hanging on the wall, so to me it sounds like agile.

В общем, рекомендую посмотреть видео в оригинале и насладиться отличным юмором автора и узнаваемыми ситуациями:) #Management #Leadership #Processes #ProductManagement #Project

XWave Surf Вчера с друзьями отлично побывал в X Wave Surf, что на Старом Дмитровском шоссе 1. Приехали пожарили мясо, посидели на природе, покурили кальян (его привезли с собой), а уже к ближе к вечеру покатались на Centurion Ri230 по Клязьме. По-идее, это место для вейксерфинга или катания на сапах, но можно и просто приехать потусить на природе :)

Бизнес-линии, сервис-линии и платформы @ T-Bank - Part III - (Рубрика #Management) Продолжу первые два поста (1 и 2) и расскажу как мы из квази-продуктовой команды делали платформу. Здесь речь идет про Мобильный Банк, о котором я рассказывал много раз и раньше, но самый сочный рассказ был на Higload ++ Spb 2022. Но для этого поста я сокращу его до кратких тезисов: - До конца 2019 года Мобильный Банк Тинькофф рассматривался как самостоятельный продукт, который развивался и побеждал во всех рейтингах вида MarksWebb - Команда была монолитной и со своими приоритетами, где фокус был на кредитных и дебетовых продуктах, а также лайфстайл сервисах - Но в 2019 году компания решила, что Мобильный Банк должен стать супераппом, в котором представлены все бизнес-вертикали (из терминологии первого поста) - В этой концепции мобильный банк должен был стать платформой, а точнее позволить продуктовым командам бизнес-вертикалей автономно разрабатывать свои фичи внутри приложения - Для того, чтобы это работало надо было выделить платформенные команды, которые позволяли бы обеспечивать такие вещи как: согласованная архитектура приложения, общие инструменты для тестирования, сборки, производительности, надежности, дизайн решений В момент перехода мы, фактически провернули обратный маневр Конвея, а точнее - Уловили цели и задачи бизнеса - Выяснили какая архитектура потребуется под их решение - Выработали правильный оргдизайн команд, границы ответственности, процессы работы Дальше мы несколько лет шли в сторону платформизации и сейчас все продуктовые команды мобильного банка и API уехали в свои бизнес-вертикали, а у меня в юните осталось управление разработки клиенстких интерфейсов (УРКИ), в котором остались платформенные команды:) Я считаю, что это преобразование прошло успешно и мы достигли тех целей, которые ставили перед собой, когда запускали эти изменения. Подробнее почитать про этот кейс можно в моей статье или посмотреть видео-записи выступления. P.S. В общем про подходы формирования структуры команд под запросы бизнеса я рассказывал раньше в постах про - структуру команд - проектный подход - продуктовую разработку А также рассказывал про это на конференции Yandex под конец 2023 года #Management #Leadership #Software #Processes

Turbo ML Conf Астрологи объявили неделю анонсов мероприятий Т-Банка, поэтому я расскажу сегодня про первую 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

ИТ Пикник 17 августа ИТ Пикник будет проходить во второй раз. Это большой семейный фестиваль для опытных IT'шников в Коломенском. Я думаю, что мероприятие будет еще масштабнее, чем в прошлом году и оно будет содержать следущие активности - Лекции на разные темы - тут одним из треков будет трек по архитектуре, надежности и качеству. В прошлом году я был в программном комитете, а в этом пристроил ПК в руки своего зама, Антона Костерина - Интерактив для детей и взрослых - тут будут мастер-класссы, шахматный турнир, робототехника, virtual reality, космонавтика и спорт - Музыкальная часть фестиваля - тут будут крутые исполнители и хедлайнер, имя которого пока мы держим в секрете Сам фестиваль организовали Т-Банк, CodeFest и Мельница, а также у фестиваля есть много крутых IT-партнеров. Если вы хотите попасть на фестиваль, то простой трехшаговый алгоритм выглядит так: 1) Зарегистрируйтесь в форме, указав специальность (предполагается модерация заявок) 2) Дождитесь письма, где будет ссылка на внесение благотворительного взноса - для получения билета надо будет пожертвовать от тысячи рублей в один из фондов 3) Получите подтверждение регистрации и билет на указанную вами почту P.S. Думаю, что я приду на фестиваль с семьей, поэтому если кто-то захочет пообщаться, то меня можно будет найти где-то в районе шатра по архитектуре:) #Conference #Software #SoftwareArchitecture #SRE

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

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

#Management #Leadership #History #Strategy

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

Футбол "ЦСКА" - "Партизан" (Рубрика #Kids) Вчера мы с Максимом, моим средним сыном, были на этом интересном матче, который закончился со счетом 3:0. Интересно, что третий мяч забил Зоран Тошич, легенда ЦСКА, которого выпустили на последние 15 матча побегать, но он аж забил:) Нам футбол понравился побольше, чем матч "Динамо" - "Партизан", так как тут ЦСКА уверенно выиграл + у нас была крутая компания, так как на футбол еще пришли мои коллеги, с которыми мы вместе смотрели игру. Максу понравилось и теперь у него к шарфу Динамо добавился и шарф ЦСКА, а также он оценил детский сектор ВЭБ Арены, где перед матчом детишки могут немного поиграть в футбол сами. В общем, мы договорились, что и дальше будем ходить на матчи ЦСКА и Динамо, а зачит мне придется сделать себе Fan ID:) P.S. Я в выходные заболел ОРВИ, но так как обещал сыну сходить с ним на футбол, то закинулся таблетками и сходил на матч. Это привело к тому, что сегодня я уже не смог подняться на работу и полдня провел на встречах из дома, а в остальное время провел во сне. Только к концу дня пришел +/- в норму. #Sport #ForKids #ForParents

Футбол "ЦСКА" - "Партизан" (Рубрика #Kids) Вчера мы с Максимом, моим средним сыном, были на этом интересном матче, который закончился со счетом 3:0. Интересно, что третий мяч забил Зоран Тошич, легенда ЦСКА, которого выпустили на последние 15 матча побегать, но он аж забил:) Нам футбол понравился побольше, чем матч "Динамо" - "Партизан", так как тут ЦСКА уверенно выиграл + у нас была крутая компания, так как на футбол еще пришли мои коллеги, с которыми мы вместе смотрели игру. Максу понравилось и теперь у него к шарфу Динамо добавился и шарф ЦСКА, а также он оценил детский сектор ВЭБ Арены, где перед матчом детишки могут немного поиграть в футбол сами. В общем, мы договорились, что и дальше будем ходить на матчи ЦСКА и Динамо, а зачит мне придется сделать себе Fan ID:) в основное время и по пенальти Динамо проиграл со счетом 2:4. Нам футбол понравился - все было красочно, празднично, под конец матча случилось обилие голов, плюс даже пенальти, которые положены по регламенту турнира "Братский кубок" в случае ничьей. Забавно, что само событие я узнал за день до этого, проезжая на такси домой мимо ВТБ Арены. Суть в том, что мой средний сын болеет за Динамо и он предложение сходить на этот матч воспринял позитивно. Забавно, что у меня через дорогу находится стадион ЦСКА, на который ходить удобнее, но дед сводил Максима первый раз на футбол в прошлом году, когда Динамо играл интересно и претендовал на чемпионство. В итоге, теперь Максим болеет за Динамо, вот вчера у него появился и шарф, с которым удобно праздновать голы:) #Sport #ForKids #ForParents

Обеспечение качественных 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

Обеспечение качественных 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

Приключение мышонка Недо в Калининграде, или квест Мышиного короля (Рубрика #Kids) Недавно я летал в Калининград и по прилету решил, что хочу детям рассказать про него. Посмотрел и поискал книги на эту тему и нашел "Приключения мышонка Недо в Калининграде". Это интересная история про маленького мышонка, обитающего в библиотеке в городе N, который отправился в Калиниград на книжную выставку. Но по прибытию на место он попадает прямиком в историю, который начинается со знакомства с заколдованной Русалкой, которая является частью флюгера флюгера Кафедрального собора. Русалка рассказывает про заклятье Мышиного короля, из-за которого ей грозит исчезновение. Мышонок подписывается на прохождение квеста, в котором нужно найти янтарь, обойти дюну Эфа, отыскать 40 кошек в Зеленоградске, побывать в Танцующем лесу, сосчитать ступени к Солнечным часам в Светлогорске, пробежать сквозь Бранденбургские ворота, забраться на маяк в Балтийске, посетить корабль-памятник «Витязь», съесть «волшебный марципан» и встать спиной к памятнику Канту. Интересно, что большую часть этих ключевых точек в моем путешествии нам помогли пройти гиды, а вот мышонку помогла калининградская девочка Арины и Русалочку удалось спасти. P.S. Книга оказалась настолько хороша, что по ее мотивам сняли мультик. P.P.S. Книга понравилась нашим детишкам, так что она вошла в список тех, которые мы можем читать им перед сном:) #ForKids #ForParents #Tales

Code of leadership #16 - The Five Dysfunctions of a Team (Рубрика #Management) Шестнадцатый выпуск подкаста про лидерство посвящен книге "5 пороков команды", которую написал Патрик Ленсиони в жанре бизнес-романа еще в 2002 году. Эта книга направлена на лидеров, которые хотят сделать свою команду эффективнее. Но этому мешают ряд факторов, которых автор насчитал целых пять штук, которые выстраиваются в пирамиду (подробнее в прошлом посте про эту книгу) Я обсуждаю эту книгу с Андреем Соколовым, экспертом в области эффективных коммуникаций для бизнес-сообщества с 20-летним стажем. У Андрея есть курс по сторителлингу, часть из которого я раньше успел пройти. Для зрителей и слушателей нашего стрима есть скидка в 20% для записи в июльскую или августовскую группу 2024 года. Достаточно использовать кодовое слово "Книжный куб". #Management #Leadership #PublicSpeaking #Storytelling #Culture

Головоломка БондиЛогика (Рубрика #Kids) Пока папа решает easy задачки на leetcode младший сын собирает головоломки из машинок на уровне новичок:) #ForKids #SelfDevelopment

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

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

Пять пороков команды. Притчи о лидерстве (The Five Dysfunctions of a Team. A Leadership Fable) Эта интересная книга 2002 года от Патрика Ленсиони написана в жанре бизнес-романа и направлена на лидеров, которые хотят сделать свою команду эффективнее. Но этому мешают ряд факторов, которых автор насчитал целых пять штук, которые выстраиваются в пирамиду - Взаимное недоверие - Боязнь конфликта - Безответственность - Нетребовательность - Безразличие к результатам Сам роман начинается с конфликта, где успешная в прошлом высокотехнологическая компания начинает пробуксовывать: совместная работа ушла в прошлое, теперь каждый занят своими делами, работа затягивается, качество падает. Руководитель компании покидает свое кресло и ему на смену приходит Кэтрин, главный герой романа, которая готова взяться за решение проблем, но надо понять их причины. В первой части книги эти вопросы решает Кэтрин со своей командой, а во второй автор приводит подробное описание этих «пять пороков команды» и методы их устранения. Вторая часть содержит реальные практические советы для того, чтобы улучшить работы ваших команд. Мне эта книга показалась пересекающейся с другими постами, про модельки, которые я разбирал раньше - Проект Аристотель от Google (Google's Project Aristotle), где ребята из Google изучали факторы, что делают их команды успешными (и тут psychological safety был основным фактором) - Проект Кислород от Google (Google’s Project Oxygen), где ребята из Google изучали есть ли польза от менеджеров и если да, то что делает менеджера хорошим - Типология организационных культур от Рона Веструма (A typology of organisational cultures), где были описаны типы культур P.S. Следующий эпизод подкаста "Code of Leadership" будет посвящен этой книге. #Management #Leadership #Culture #Processes #Thinking