Книжный куб

Вакансия партнера по работе с данными (Рубрика #Vacancy) В Т-Банке мы привыкли принимать решения на основе данных, а данных от 46+ млн клиентов и целой экосистемы продуктов у нас очень много. Для того, чтобы использовать более эффективно мы переносим ответственность за данные с централизованной дата платформы в сами домены. Мы считаем, что это позволит эффективнее работать с данными в каждом из направлений, за счет синка с продактами, аналитиками, разработчиками приложений. По-факту, в моей домен входят - Клиентские интерфейсы: платформенные команды веба, мобилы и API - Маркетинговые технологии: внешняя реклама, маркетинговая платформа - Соц-медиа платформы: социальные сети, медиаплатформа, медиапроекты (ТЖ, Бизнес-секреты), игры - Цифровые экосистемы: аутентификация/авторизация, биометрия, главная страница приложения, финздоровье - Продуктовая аналитика и a/b платформа В итоге, я ищу к себе человека, который поможет мне составить стратегию по работе с данными внутри этих доменов так, чтобы мы как компания получили дополнительный value. А дальше этот партнер по данным будет помогать реализовывать эту стратегию силами команд разработки внутри моего домена, используя инструменты дата платформы, которая сейчас уходит от стандартного DWH подхода в сторону data lake и lake house. Например, в этому году мы уже перенесли ответственность за отгрузку данных на сторону команд разработки, а также реализовали в новых инструментах (streaming data platform) возможность задавать контракты данных. Если выкинуть за скобки старые интеграции через базу (которых большинство), то мы уже живем в мире, где поток данных в data platform - это контракт примерно такой же, как публичный REST API. И на проблемы с этим контрактом реагируют продуктовые SRE команды. Собственно, у data platform есть еще много планов по тому, как нам двигаться в сторону data mesh технологически, а мне нужен помощник, что будет помогать мне двигать мои продуктовые команды в эту сторону светлого будущего. Если приземляться на грешную землю, то успешному кандидату придется - Выстраивать стратегию работы с данными, управления ими и эксплуатации в контексте домена - Отвечать за people management: участвовать в процессах найма, развития и оценки, проводить one-to-one-встречи - Выявлять проблемы и прогнозировать их - Оптимизировать взаимодействие команд направления и платформы данных - Собирать фидбэк от пользователей и заносить его в платформу - Регулярно проводить аудит процессов или автоматизировать его - Прогнозировать затраты ресурсов — например, в случае открытия нового продукта в своем направлении - Участвовать в проектировании архитектуры данных домена и обеспечивать ее связность с данными организации Само собеседование будет состоять из трех этапов: - System design interview - тут нужно будет показать умения в дизайне несложных систем. Я много рассказывал про этот вид интервью - Data architecture и технологии - здесь нужно будет тоже решить задачку о том, как спроектировать data архитектуру решения для построения аналитики по одному из доменов, а также про распределение ответственности между ролями - Engineering management - этот тип интервью мы даем для руководителей, кто уже управлял несколькими командами. Я про него тоже рассказывал. Если вам понравилась вакансия, то пишите в личку @apolomodov P.S. Для того, чтобы лучше понять мои ожидания от кандидата рекомендую 1) Послушать эпизод подкаста "Все считается" про проект "Данные под рукой" 2) Почитать whitepaper "What Goes Around Comes Around... And Around..." про развитие баз данных за последние 20 лет (есть мой обзор из трех частей: модели данных и языки запросов, системная архитектура, общие выводы и комментарии на будущее) Я рассчитываю, что мой партнер по данным понимает куда двигаются технологии и почему, а также как это выглядит у нас в компании 3) Полистать книгу Zhamak Dehghani "Data Mesh: Delivering Data-Driven Value at Scale", чтобы знать куда мы идем и быть готовым драйвить эти изменения в моем домене (я уже рассказывал про эту книгу) #Management #Data #Leadership #Vacancy #Career

Observability in an Asynchronous World • James Eastham • GOTO 2024 - Part II (Рубрика #Architecture) Вторая часть поста про observability в асинхронных системах как раз говорит про observability, так как в первой мы успели обсудить только асинхронность:) 11) В асинхронных системах используются стандартные подходы к observability: logs, metriics, traces. Но это инструменты для обеспечения observability 12) Но автор предлагает вернуться к вопросу, а зачем нам нужна наблюдаемость в нашей системе - по его мнению это The ability to ask questions of your system, you didn't know you'd need to ask from outside your system То есть, при возникновении проблем мы сможем разобраться в этом. 13) Асинхронные системы наблюдаемость из-за множества движущихся частей. Essential complexity домена остается на месте, а accidental complexity в асинхронной системе высока. 14) Чтобы с ней бороться нам надо правильно использовать distributed tracing. Трассировка помогает понять влияние событий на систему. 15) Асинхронная архитектура упрощает эволюцию за счет добавления новых обработчиков событий, но надо следить за тем, как эволюционирует схема событий во времени - это может приводить к интересным проблемам. В качестве примера Джеймс приводит изменение для поддержки оплаты пиццы несколькими валютами. То есть важно учитывать влияние изменений на все системы, участвующие в обработке событий. 16) Дальше автор говорит про спецификацию событыий и ррассказывает про cloud events и про event catalog. Эти подходы определяют что включать в события, что помогает с идемпотентностью при обработке и с трассировкой. 17) Дальше автор рассказывает про подход API First Design и дальше говорит о том, что события в некотором роде тоже являются API, то есть нам нужно относиться к ним с уважением. И использовать каталог событий для документирования систем, управляемых событиями. 18) Автор говорит о том, что в нашей observability системе часто важно сохранять не содержание событий, а их схему. Это позволяет задавать вопросы о системе и улучшать распределенную трассировку 19) Вообще про observability и трассировки прикольно посмотреть в докладе "What Is This OpenTelemetry Thing?", про который я недавно рассказывал 20) Отдельно автор говорит про полезные метрики по событиям: глубина очереди, количество опубликованных и обработанных сообщений, возраст сообщений. Но вообще выбор метрик зависит от контекста и целей. 21) Observability платформа позволяет находить события, анализировать их структуру, а также отслеживать распространение событий и выявлять регрессии. 22) Мне понравился вопрос автора о том, а как понять что тот или иная часть кода работает на проде. По-факту, через те же логи, трейсы и метрики. Для тех, кто хочет посмотреть как это работает на практике, Джеймс запилил код той систеемы для пиццерии, о которой он рассказывал. При желании можно изучить как это работает с использованием в качестве observability платформы Datadog. #SRE #Architecture #DistributedSystems #Software

Observability in an Asynchronous World • James Eastham • GOTO 2024 - Part I (Рубрика #Architecture) Интересное выступление от James Eastham, Serverless Developer Advocate из Datadog, на тему событийно-ориентированной архитектуры и тому, как в ней обеспечивать observability. В самом докладе нет ничего про Datadog, но есть сквозной пример пиццерии, архитектуру которой автор делает в EDA стиле и показывает как обеспечить ей наблюдаемость. Тезисы примерно такие 1) В распределенных системах сложно понять, что пошло не так при какой-то проблеме 2) В случае синхронный взаимодействий - это +/- понятно как делать, но в асинхронном мире наблюдаемость еще больше усложняется 3) В какой-то момент по мере роста масштаба систем мы пришли к большому количеству отдельных сервисов 4) При их построении принято стремиться к low coupling и high cohesion, условно связи между сервисами нужно делать несильными, а вот внутри сервиса логика должна быть сильно завязана друг на друга 5) Одним из вариантов решения проблемы связей между сервисами был переход на event-driven architecture. Тут автор показывает свою архитектуру для пицерии, где есть order processing service, kitchen service, delivery service, которые взаимодействую посредством событий 6) Дальше автор разбирает что такое событие (это непреложный факт, который нельзя изменить). Важно, что автора интересуют именно бизнес-события, которые приводят систему в движение. На эту тему рекомендую изучить технику event storming, про которую я рассказывал раньше 7) События - это разновидность сообщения, но событие уже произошло в прошлом. Также есть сообщение типа "команда", которое предписывает что-то сдлеать в будущем. 😍 События бывают трех видов: нотификации, события с передачей состояния (event-carried state transfer) и доменные события (это из event sourcing). Рекомендую почитать мой разбор главы про EDA и event sourcing из книги "Learning DDD" Влада Хононова 9) Собственно взаимодействие сервисов осуществляется через publish/subscribe шаблон, производители публикуют события с определенной схемой, а потребители могут их использовать (или не использовать) 10) Такое взаимодействие позволяет сделать асинхронную систему, что позволяет отвязать производителей от потребителей событий. Ответственность за контроль и потребление событий контролируют потребители событий Продолжение в следующем посте. #SRE #Architecture #DistributedSystems #Software

Иллюстрация результатов опроса для исследования про успешность IT проектов. В этой диаграмме 7 считается полным успехом, 5 и 6 - это выше mid-level, а ниже 5 считается неудачей.

Assessing IT Project Success: Perception vs. Reality (Рубрика #Management) Эта статья была опубликована в сентябре в ACM Queue и она посвящена рассмотрению изменяющегося понимания успеха IT проектов. Раньше эту тему активно педалировали ребята из Standish Group, еще в 1994 году рассказывая в "The CHAOS Report" о том, что большая часть IT проектов проваливается. Они рассматривали успех с точки зрения не просто проекта, а проектного управления, а точнее попадания в проектный треугольник: сроки, бюджет и scope.

The project is completed on time and on budget, with all features and functions as initially specified.

Но авторы нового исследования задумались о том, а какие еще есть объективные показатели помимо этих метрик, по которым можно оценить успешность проекта. Они выбрали следующие дополнительные метрики - Level of global success achieved Level of compliance with the scope, time, and cost - Level of vendor (supplier) satisfaction - Level of client satisfaction - Deliverables impact - Achievement of benefits verified in the project. Для проведения исследования использовались опросы с участием опытных менеджеров IT-проектов из различных отраслей и регионов. Респондентов попросили оценить один недавно завершенный проект с помощью детализированной анкеты, включающей как субъективные оценки, так и объективные критерии. Ответы предполагалось давать по шкале Лайкерта, а всего было заполнено порядка 200 опросов. Надо было выбрать проект, который закончился больше полугода назад - это позволяло ответить на дополнительные вопросы про - Использование клиентом результатов проекта на постпроектной стадии. - Найм клиентом специалистов для поддержки или обслуживания проекта. - Заключение клиентом новых контрактов с тем же подрядчиком. - Рекомендации клиента данного подрядчика другим. Основными выводами исследования стало то, что вопреки распространенному мнению о частых неудачах IT-проектов (например, согласно отчетам Chaos Reports группы Standish), исследование показало, что большинство IT-проектов достигают высокого уровня успеха. В частности, 90,16% опрошенных проектов получили оценки выше среднего уровня по глобальной шкале успеха, а 61,66% достигли двух верхних уровней. По расширенным критериям, описанным выше результаты проектов тоже показывают высокую долю успеха. Интересно, что обнаружена положительная корреляция между глобальным успехом проекта и такими факторами, как удовлетворенность клиента (ρ = 0.714), выгоды для клиента (ρ = 0.751) и удовлетворенность подрядчика (ρ = 0.653). Это подчеркивает важность ориентированности на результаты для клиента как ключевого индикатора успеха. В будущих исследованиях авторы рекомендуют начать учитывать мнения различных заинтересованных сторон (например, конечных пользователей, спонсоров) для получения более целостной картины. Практикам проектного менеджмента авторы рекомендуют оценивать не только показатели выполнения проекта, но и долгосрочные результаты, такие как удовлетворенность клиентов и выгоды для бизнеса. Такой подход позволит организациям лучше понимать и улучшать свои методы управления проектами. Я это трактую так, что стоит использовать продуктовый подход, так как часто результатом проекта является новый продукт или изменение существующего, а долговременным результатом проекта является успех этого продукта:) Итого, в этом исследовании дан более комплексный взгляд на успех IT-проектов, по сравнению с демагогией от Standish Group. И это исследование показывает, что многие IT-проекты достигают значительных успехов при всесторонней оценке, бросая вызов устаревшим представлениям о повсеместных неудачах в этой области. Исследование подчеркивает необходимость развития рамок оценки для учета многогранности современных IT-проектов:) #Management #Processes #Leadership #Project #Product

Code of Leadership #23 - Interview with Andrew Marchenko (Рубрика #Architecture) В этом эпизоде ко мне пришел крутой гость, Андрей Марченко, мой бывший коллега, который сделал много хорошего для веба Tinkoff.ru. Андрей является software engineer высокого грейда с большим опытом разработки платформенных решений для внутренних разработчиков. Много лет он работал над тем, чтобы сделать разработчикам жизнь проще, а продукты качественнее на разных позиций от разработчика, до руководителя 16+ инженеров. В последнее время он перешел в продуктовую разработку в одной из FAANG компании на позиции инженера. Сейчас он с интересом изучает как все устроено внутри, находит отличия от Российского IT, а также ищет путь для быстрого роста и повышений внутри компании. Мы поговорили про следующие темы - Начало карьеры Андрея в общем - Как Андрей оказался в Тинькофф - Как выглядел рост Андрея в Т - Важность взаимодействия с людьми - Переход в платформенную команду - Про Statist и продуктовую аналитику - Инфраструктурные проекты Андрея - Коммуникации и убеждение - Высокоуровневые инженеры - Опыт работы в Тинькофф и переезд зарубеж - Работа в Booking и изучение баз данных - Ведение блога и улучшение английского - Переход в FAANG компанию и текущие проекты - Проблемы роста в американской компании - Планы на будущее и как пришел к желанию переехать - Потеря влияния в новой компании (карма и доверие) - Решение сложных задач как залог роста - Изучение дизайна крупных и высоконагруженных систем FAANG компаний изнутри - Личный опыт и советы Андрея о том, как стать таким же крутым - Проблемы Андрея с учебой из-за дислексии и их преодоление - Важность работы и упорства Дополнительные ссылки - Блог Андрея со статьями, которые он иногда пишет на тему инфрастуктуры/архитектуры - Телеграм канал Андрея - Выступление Андрея про tramvai - "Tramvai, модульный фреймворк для React-приложений от Tinkoff" - Выступление Андрея "Пять лет эволюции React-приложения" #Architecure #Software #SystemDesign #Management #Staff #Engineering #PlatformEngineering

Database Internals Meetup #5 (офлайн + онлайн): 5 докладов на конференции ISPRAS Open Последние пару дней у меня в канале посвящены базам данных, поэтому позволю себе порекомендовать посетить пятый митап российского сообщества разработчиков СУБД и распределенных систем, на котором будут доклады от основателей и ведущих разработчиков YDB, Picodata, Tarantool, openGauss и CedrusData. Мероприятие пройдет 11 декабря офлайн и оно будет частью конференции ISPRAS Open в Москве. Регистрация бесплатна и доступна здесь. Программа митапа будет плотной и насыщенной: - 13:00 — 14:00 Эволюция архитектуры СУБД на примере YDB, Андрей Фомичев, Яндекс, основатель и руководитель YDB - 14:00 — 15:00 Blue/green deploy для хранимых процедур в кластерной СУБД на примере Picodata, Константин Осипов, Picodata, основатель Picodata - 15:00 — 16:00 Оптимизация подсказками: ускоряем запросы, не изменяя планировщик. Сергей Зинченко, OpenGauss, Инженер - 16:00 — 16:30 Кофе брейк - 16:30 — 17:30 Columnar In-Memory в Tarantool: зачем нужно строить еще одну колоночную СУБД, да еще и в памяти? Николай Карлов, VK, Head of Innovations, tarantool.io - 17:30 — 18:30 Переписывание запросов на основе материализованных представлений в аналитической системе CedrusData. Владимир Озеров, Александр Блажков, генеральный директор и разработчик CedrusData #Database #Architecture #Management #DistributedSystems #Software #Engineering

Архитектура в Т-Банке: вчера, сегодня, завтра — выступление на ArchDays 2024 (Рубрика #Architecture) В этой статье я рассказываю про наши подходы к проектированию и построению архитектуры систем. Я в "Т" уже 8 лет и видел как эти процессы эволюционировали во времени, а также знаю к чему мы пришли. Я выделил следующие четыре стадии и объяснил как и почему они сменяли друг друга во времени 1. COTS (commercial of the shelf) 2. Свой собственный софт 3. Platform Engineering 4. Большие мегапроекты и governance Напоследок я рассказал про подходы корпораций и технологических компаний к должностям/ролям архитекторов, а также поделился своим видением того, как нам дальше стоит развиваться. Эта статья является расшифровкой моего доклада на ежегодной конференции "ArchDays 2024", которая прошла в этом году уже в шестой раз. #Architecture #Software #Evolution #Management

What Goes Around Comes Around... And Around... Part III (Рубрика #Data) В продолжение рассказа (1 и 2) про эту статью 2024 стоит закончить про разные подходы к системной архитектуре, а дальше рассказать про прощальные комментарии авторов, что повторяют частично предостережения из 2005 годов, когда вышла первая статья "What Goes Around Comes Around" Архитектуры 5. Аппаратные ускорители Этот подход предполагает использование специализированного оборудования (например, GPU или FPGA) для ускорения выполнения запросов. Подход выглядит работоспособным только для cloud вендоров из-за стоимости разработки кастомного железа и написания кастомного софта. Кроме того, обычно это не дает кратного роста эффективности. 6. Базы данных на основе блокчейна Блокчейн обещал гарантии неизменяемости данных и прозрачности транзакций. Но такие системы остаются нишевыми из-за ограничений производительности и сложности интеграции с традиционными приложениями. Выводы относительно архитектур баз данных Авторы статьи отмечают, что многие из этих архитектур либо заняли нишевые рынки, либо постепенно интегрируются в реляционные СУБД - Колоночные системы теперь являются стандартом для аналитики. - Облачные базы данных доминируют благодаря удобству управления. - NewSQL-системы становятся мостом между традиционными реляционными базами и масштабируемыми NoSQL-подходами. - Эти изменения демонстрируют адаптацию СУБД к современным требованиям приложений и аппаратным инновациям. Прощальные комментарии - Никогда недооценивайте значение хорошего маркетинга для плохих продуктов: как было с Oracle в 1980х, MySQL в 2000х, MongoDB в 2010х:) Последние 2 примера я видел своими глазами - Опасайтесь DBMSs от крупных вендоров не из рынка DBMS. Крупные технологические компании часто пишут свои базы данных in-house, а дальше отпускают их на волю (в мир open source). У некоторых bigtech компаний так получаются крутые продукты: Apache Hive, Presto, Apache Cassandra, RocksDB или Apache Kafka, Apache Pinot, Voldemort, а у других нет. Авторы делают предположение, что система промоушенов внутри таких компаний приветствует создание новых технологий внутри, а не использование готовых инструментов. Так на свет появляется куча уродцев от команд, которые не имеют опыта в создании баз данных - Не игнорируйте первое впечатление пользователя при с вашей базой (out-of-box experience). Важно, чтобы продуктом было удобно пользоваться новичкам (иначе они пойдут крутить данные с помощью Python notebooks) - Разработчикам все еще надо иногда делать запросы к базам данных напрямую, несмотря на старания создателей ORM:) - Влияние AI/ML на базы данных будет значительным. Скорее всего запросы на естественном языке не заменят SQL для OLTP типов запросов, но вот для OLAP - это может быть делом ближайшего будущего. Внутри корпораций для принятия решений используются данные, но LLMs не так просто будет помочь с этим. Есть проблема с тем, чтобы объяснить их результаты людям, а также с количеством данных, которые требуются для обучения. А эти данные так просто не отправишь для генерации в крауд системы. Отдельно авторы отмечают направление исследований об оптимизации работы самих DBMSs при помощи ML/AI. И даже если в этом результаты будут получены, то они не избавят от потребности в выскокачественной системной инженерии. В заключении авторы грозятся через 20 лет написать статью продолжение

We caution developers to learn from history. In other words, stand on the shoulders of those who came before and not on their toes. One of us will likely still be alive and out on bail in two decades, and thus fully expects to write a follow-up to this paper in 2044.

#Architecture #Software #DistributedSystems

What Goes Around Comes Around... And Around... Part II (Рубрика #Data) В продолжение рассказа про эту статью 2024 стоит поговорить про разные подходы к системной архитектуре, которые развивались в последние два десятилетия. Эти архитектуры отражают изменения в software (менялись типы приложений и их требования), а также изменения в hardware, а точнее изменения в параметрах аппаратного обеспечения (мощность CPU, скорость оперативной памяти, разные типы дисков, скорость сети и так далее). 1. Колоночные системы (columnar systems) Эти системы стали стандартом де-факто в мире аналитических баз данных. Суть в том, что там запросы часто обращаются только к небольшому числу атрибутов таблиц. Колоночное хранение данных позволяет читать только нужные данные, а также лучше сжимать их благодаря однородности значений. Кроме того, можно добиться ускорения выполнения запросов за счет векторизованной обработки данных. Примерами таких баз данных являются Vertica, Amazon Redshift, Google BigQuery, Clickhouse, DuckDB. 2. Облачные базы данных (cloud databases) Эти базы данных предоставляются в облаках, в которые было модно перевозить свою инфраструктуру. Такие базы обеспечивали масштабируемость и эластичность, что позволяло клиентам динамически изменять ресурсы. Восход этих баз данных связан с тем, что за последние 20 лет скорость сети увеличивалась гораздо быстрее, чем скорость диска, поэтому использование NAS (network attached storage) стало привлекательной альтернативой для стандартного устройства хранения. Собственно, основные вендоры в качества NAS используют объектные хранилища (например, AWS S3). Такая архитектура приводит к тому, что у нас разделяется compute и storage и мы имеем такие преимущества - Можно обеспечить эластичность на уровне отдельных запросов - Вычислительные ноды можно отправить на другие задачи, если DBMS не полностью утилизируется - Можно переместить вычисления прямо на ноды хранения данных - подход называется "pushing the query to the data" и он показывает себя лучше, чем стандартный "pulling the data to the query". Интересно, что два первых подхода называются serverless computing и в мир DBMS их принесла Snowflake. А среди популярных облачных баз данных есть - Google Spanner - рекомендую интересный whitepaper - Amazon Aurora - рекомендую интересный whitepaper, который мы даже как-то разбирали в выпуске подкаста "Code of Leadership", а также рекомендую глянуть рассказ с AWS Re:Invent 2023 о том, как они завезли туда шардирование 3. Озера данных (Data Lakes) и Lakehouses Облачные платформы разожгли интерес к тому, чтобы отказаться от монолитов в аналитике и перейти к data lakes, где данные как есть загружались в объектные хранилища (S3 like). То есть тут был отход от стандартных ранее ETL (extract-transform-load) к ELT (extract-load-transform). После загрузки, прямо поверх данных выполнялись вычисления при помощи движков lakehouse, минуя стандартные DBMS (типа Greenplum). Собственно lakehouse - это комбинация из data warehouse и data lake:) Данные в data lake хранятся в бинарном виде: Parquet, ORC (optimized row columnar), а для обмена данных in-memory можно использовать формат Apache Arrow. В каждом облаке есть managed data lake сервисы, а также есть отдельные варианты в виде Databricks, Dremio, PrestoDB, Trino. 4. NewSQL-системы В 2010х годах появился этот класс систем, чтобы совместить ACID транзакции из RDBMS и масштабируемость NoSQL решений. Одним из первых представителей стал уже упоминавшийся Google Spanner. По-факту, тут было 2 типа систем in-memory и стандартные disk-oriented. Часть стартапов ставили на больший спрос на in-memory подходы, но ставка не сыграла. На смену этим подходам пришли распределенные и транзакционные SQL RDBMS навроде TiDB, CockroachDB и думаю, что можно туда добавить YDB с их Calvin-транзакциями. Эти системы подходят для приложений, требующих как высокой производительности, так и строгой консистентности данных. В продолжении окончание разбора статьи. #Architecture #Software #DistributedSystems

What Goes Around Comes Around... And Around... Part I (Рубрика #Data) Интересная обзорная статья 2024 года от Michael Stonebraker и Andrew Pavlo про развитие баз данных за последние 20 лет. Оба автора являются корефееями в области баз данных: Michael создал Postgres и еще кучу других баз, а Andrew - исследователь в области баз данных, профессор и преподаватель, лекции которого доступны на Youtube. Сама статья продолжает статью 2005 года "What Goes Around Comes Around", которую написали Michael Stonebraker и Joseph M. Hellerstein. Они проанализировали историю развития баз данных за 35 лет и предсказали что модные тогда объектные и xml базы данных не смогут обойти по реляционную модель. С тех пор прошло порядка 20 лет и пришло время сделать новый обзор мира баз данных. Для этого авторы решили посмотреть на это с двух сторон: - Модели данных и языки запросов - Архитектура баз данных Начнем с разбора существующих data models и query languages: 1. MapReduce-системы Изначально они были разработаны в Google для обработки больших объемов данных (веб-краулер). MapReduce не использует фиксированную модель данных или язык запросов, они выполняют пользовательские операции map и reduce. Открытой версией MapReduce стал Hadoop, который сейчас не очень популярен из-за низкой производительности и заменяется более современными платформами аля Apache Spark или просто СУБД. 2. Key-Value хранилища У них максимально простая модель данных: пары "ключ-значение". Они используются для задач кэширования (Memcached, Redis) или хранения сессий. Возможности в модели ограничены - нет индексов или операций join, что усложняет применение для сложных приложений. Многие KV-хранилища (например, DynamoDB, Aerospike) эволюционировали в более функциональные системы с поддержкой частичной структуры (JSON). Среди популярных встроенных k/v решений популярны LevelDB и RocksDB. 3. Документные базы данных Они хранят данные в виде документов (например, в формате JSON). Изначально получили популярность благодаря простоте интеграции с веб-приложениями (например, MongoDB), предлагая подход schema on read. Интресно, что к 2020-м годам большинство документных СУБД добавили SQL-подобные интерфейсы и поддержку ACID-транзакций, а иногда и schema on write. 4. Column-Family базы данных (wide columns) По-факту, это упрощенная версия документной модели с ограниченной вложенностью. Начиналось все с Google BigTable, а в миру есть open source реализация в виде Apache Cassandra. Изначально в Cassandra не было вторичных индексов и транзакций. Но по мере развития они появились (но там все очень интересно) 5. Поисковые движки Они нужны для полнотекстового поиска (Elasticsearch, Apache Solr). Поддерживают индексацию текста, но ограничены в транзакционных возможностях. Реляционные СУБД также предлагают встроенный полнотекстовый поиск, но с менее удобным API. 6. Базы данных для массивов Они предназначены для работы с многомерными массивами, например, научные данные (SciDB, Rasdaman). Ниша ограничена специфическими областями применения: геоданные, изучение генома. 7. Векторные базы данных Используются для хранения эмбеддингов из машинного обучения (Pinecone, Milvus). Основное применение — поиск ближайших соседей в высокоразмерных пространствах. Реляционные СУБД уже начали добавлять поддержку векторных индексов. 8. Графовые базы данных Моделируют данные как графы (узлы и связи). Примеры: Neo4j для OLTP-графов, TigerGraph для аналитики. Большинство графовых задач можно реализовать на реляционных СУБД с помощью SQL/PGQ (новый стандарт SQL:2023). Общие выводы - Большинство нереляционных систем либо занимают нишевые рынки, либо постепенно сближаются с реляционными СУБД. - SQL остается основным языком запросов благодаря своей гибкости и поддержке современных приложений. - Реляционные СУБД продолжают развиваться и интегрировать новые возможности (например, JSON, векторные индексы), что делает специализированные системы менее конкурентоспособными. В продолжении поста будет про архитектуру баз данных. #Data #Architecture #Software #DistributedSystems

Финал Медиа Баскет Лиги (#Sport) Утром открыл IT конфу своим докладом, а вечером пошел на финал медиа лиги по баскетболу. Про эту лигу я узнал неделю назад, команд и игроков не знаю, но сами полуфиналы получаются динамиными. Жду финального матча:) #Sport

Как стать продуктивнее в IT, если вы уже прокачали свои харды (Рубрика #Management) Сегодня я выступлю на конференции soft weekend, первой софтовой офлайн-конференция в России (что бы это ни значило). Я не могу сказать, что люблю рассказывать чисто про софты, но эту конференцию организует мой знакомый, Андрей Смирнов, автор подкаста "Frontend Weekend", куда я ходил в гости в прошлом году. В итоге, я решил рассказать что-то из серии набора качеств и навыков, что важны для всех: и для крутых инженеров и для хороших менеджеров. Доклад будет состоять из 4х частей, которые описаны ниже, причем фокус будет на третьем пункте, а точнее навыках и умениях помимо hard skills, что помогали лично мне расти на протяжении всей карьеры 1) Зачем нам нужны soft skills - В современном мире процессы разработки становятся все сложнее, зона ответственности IC (individual contributor) все увеличивается и включает system design, operation, data, security, ... (подробнее в моем рассказе о современном SDE и SDLC) - Для борьбы с этой сложностью обычно применяют разные абстракции, например, для инфры это IaaS -> PaaS -> SaaS -> ...(подробнее в моем рассказе об облачных технологиях для Финтех Школы) - Мы все живем в комплексном и хаотичном мире (complex и chaotic из фреймворка Cynefin) 2) Как расти в таких условиях - Для инженеров есть две стандартные дороги: индивидуального контрибьютора или менеджера. В обоих, с какого-то уровня надо уметь проявлять лидерство. Условно, до middle+ IC можно дорасти только на хардах, а вот дальше ...(подробнее здесь) - Например, в T есть матрица для инженера вида: scope, impact, complexity, leadership, improvement. По этой матрице оцениваются достижения инженеров в Т-рост (подробнее в отдельном посте) - Т-рост - это процесс, по которому проходят повышения в Т. Инициатором является сам сотрудник, который готовит заявку на повышение с учетом своих достижений, упирая на то, что он закрыл оси вышеуказанной матрицы, а также прикладывает артефакты, которые это доказывает 3) Какие навыки и умения помогут проявлять лидерство и расти в таких условиях - Умение планировать свое время (а дальше если повезет и своей команды) - Умение и желание брать на себя ответственность (и главное доводить сложные дела до конца) - Навыки общения с коллегами и договороспособность (эта часть часто западает) - Навыки самомотивации и мотивации окружающих (правда, если разбираться в вопросе, то внешняя мотивация - это скорее стимуляция) - Важность любопытства и желание копать глубже, чтобы действительно разобраться как что-то работает (или скорее что не работает) 4) Важность hard skills как базы для дальнейшего роста (пи... не мешки ворочать) Если вы раскачаете софт скиллы с отсутствующей базой в виде hard skills, то это будет шатким фундаментом, который может рухнуть в произвольный момент. А в некоторые компании без них в принципе не попасть - например, у нас для инженеров есть интервью по программированию, языку разработки и system design. Такой набор эффективно отсеивает мастеров разговорного жанра. P.S. Запись выступления будет и потом я поделюсь ей в этом канале. #Leadership #Processes #Management

Designing Data-Intensive Applications, 2nd Edition Всеми любимая книга DDIA или просто "кабанчик" уже порядком устарела. Мартин Клеппман начинал ее писать уже порядка 10 лет назад, а издана она была в 2017 году. Я рассказывал про первую книгу раньше и она для меня стала дверью в более интересный мир распределенных и высоконагруженных систем. Новая книга доступна в виде early release на платформе O'Reilly и там уже есть первые 4 главы, которые я уже успел проглотить

1. Trade-offs in Data Systems Architecture 2. Defining Nonfunctional Requirements 3. Data Models and Query Languages 4. Storage and Retrieval

А полностью книга будет готова к следующему новому году. Из интересного могу отметить, что - Контент остался +/- тем же самым, но обновилась немного история и примеры, чтобы включить изменения за прошедшие 10 лет - Добавился соавтор Chris Riccomini, который работал в PayPal, LinkedIn, WePay, создал Apache Samza и SlateDB, а также написал книгу "The Missing README" В общем, рекомендую начинать читать книгу по мере написания - она того стоит:) #Data #Architecture #Software #DistributedSystems

Опыты и эксперименты для детей 10 в 1 (Рубрика #ForKids ) Уже приближается конец недели, а завтра начнутся выходные, которые можно провести с семьей. А у меня в семье три сына, которые не любят скуку. Если не придумать для них развлечения, то они могут перевернуть весь дом. Одним из таких развлечений являются разнообразные химические/физические фокусы, которые позволяют сделать руками что-то интересное и немного рассказать о научной составляющей вопроса. Достаточно хорошим является вариант опытов "10 в 1", в котором мы сделали за прошлую неделю все эксперименты, а некоторые их результаты украшают интерьер нашей кухни, например, разноцветные кристаллы, приложенные к посту в качестве снимков. В общем, я рекомендую знакомить малышей с наукой при помощи научпоп подходов (особенно учитывая, что такие эксперименты очень простые и красивые). #Physics #PopularScience #ForKids #ForParents

Зачем заниматься темой developer productivity в большой компании - D-Day (Рубрика #Management) В выходные я выступал на конференции D-Day, что оффлайн проводится в Тирасполе.Я рассказывал про тему developer productivity: зачем заниматься этой темой, как это принято делать в индустрии, как мы подходим к этому в Т-Банке. В конце я порекомендовал такой набор источников для более глубого знакомства с темой. 1) Мое выступление "Как и зачем измерять инженерную продуктивность в крупной компании" на MTS конференции 2) Обзор книги канонической книги "Accelerate" в трех частях: -- Общая информация по книге, формат исследования и DORA метрики -- Технические практики, архитектуру и интеграцию вопросов безопасности в процессы разработки -- Менеджерские и лидерские практики 3) Выпуск подкаста "Code of Leadership" про "Accelerate" с Игорем Курочкиным 4) Разбор темы developer productivity в фреймворках SPACE, DevEx 5) Разбор начальной статьи ребят из Google "A Human-Centered Approach to Developer Productivity" и рассказ про целую колонку в IEEE журнале от этих авторов 6) Разбор статьи "Measuring Developer Goals" от ребят из Google (продолжение серии про Human-Centered Approach) 7) Разбор статьи "Developer productivity for Humans, Part 7: Software Quality" от ребят из Google (продолжение серии про Human-Centered Approach) 😍 Разбор выступления моего коллеги Вовы Калугина "Почему DevEx важен при разработке IDP и как его померить", где он рассказывает про нашу платформу Spirit и как мы подходим к вопросам developer experience и developer productivity #Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

How to Make the World Add Up (Ложь, наглая ложь и статистика) - Part II (Рубрика #Math) Продолжая рассказ про книгу Тима Харфорда "How to Make the World Add Up" расскажу про оставшиеся правила 4. Чтобы увидеть всю картину, отступите на шаг назад. Важно уметь видеть информацию в контексте, тогда утверждения вида "случился еще один ужасный инцидент" могут заслонять тенденцию, что "в целом количество инцидентов снизилось":) То есть нам необходимы сравнения и контекст, чтобы понять как тезисы согласуются между собой. 5. Узнайте предысторию. Когда мы видим интригующие результаты исследований, то это часто связано с эффектом публикации (publication bias). Если смотреть шире, то нам нужно определить источник статистических данных и изучить, а все ли данные были учтены. 6. Спросите, кого не хватает. Надо всегда задавать себе вопрос, а все ли группы людей были учтены в исследованиях и если не все, то как бы поменялось исследование. В большинстве старых классических психологических исследованиях участниками были студенты колледжей, а не репрезентативная выборка всего населения. Одновременно, там не хватало даже студенток, которых можно было относительно легко привлекать к исследованиям, но об этом как-то не думали раньше. Про это подробнее можно прочитать в посте про "Опрос, что изменил опросы" 7. Требуйте прозрачности от компьютера. Этот пункт особенно актуален в наше время, когда у нас много больших данных и сложных алгоритмов. Важно не бояться задавать неудобные вопросы о том, что это за данные и как именно работает алгоритм. Интересно, что условный perplexity.ai сразу вместе со сгенерированным ответом дает ссылки на источники, откуда он брал информацию. Это не всегда спасает от галлюцинаций, но вы хотя бы можете сделать факт-чекинг. 8. Цените краеугольный камень статистики. Автор предлагает ориентироваться на официальную статистику, особенно в тех странах, где ей не принято манипулировать в угоду политическому курсу. 9. Помните, что дезинформация тоже бывает привлекательной. Если вам показывают красивую визуализацию, график или дашборд, то надо не стесняться и задавать вопросы о том, а что стоит за такой красотой:) 10. Не бойтесь изменить свое мнение. Автор говорит о том, что надо уметь менять свое мнение при появлении нового опыта или доступной информации. То есть надо рефлексировать относительно того, а не заблуждаемся ли мы, настаивая на старой точке зрения. 11. Золотое правило. Сохраняйте любознательность. В общем, автор предлагает копать глубже и задавать больше вопросов. Он выдвигает гипотезу, что любознательность можно прокачивать ... Я не знаю можно ли прокачивать любознательность, но у меня она с детства была где-то на уровне 10 из 10. Помню как я доставал родителей, воспитателей, тренеров и учителей своими вопросами "А почему все работает именно так":) Походу, любознательность действительно дает хорошие плоды. Развивайте любознательность у себя и своих детей и изучайте с интересом мир вокруг вас! P.S. В своей книге автор упоминает и другие книги про статистику 1) Как лгать при помощи статистики (How to Lie with Statistics) - книга, где на пальцах объясняется как врут с помощью статистики. Собственно, автор книги зарабатывал на жизнь тем, что тасовал данные, убеждая в том числе, что курение не приводит к раковым заболеваниям 2) Темные данные (Dark Data. Why What We Don’t Know Is Even More Important Than What We Do) - книга про то, как можно облажаться с данными и что с этим можно сделать 3) The Tyranny of Metrics (Тирания показателей) - эта интересная книга, название которой идет наперекор стандартному подходу к измерению всего и вся:) Она напоминает по структуре научную статью и классно описывает проблемы, которые во многом рождены из закона Гудхарта "Когда мера становится целью, она перестает быть хорошей мерой". #Math #Management #Statistics

Черная пятница в издательстве «Питер» (Рубрика #Sales) В издательстве Питер очередная распродажа со скидками в 40% на бумажные книги и 50% на электронные. Для получения этой скидки надо использовать промокод "Бумажная" (или "Электронная", если покупаете элетронную версию) при оформлении заказа. На прошлых распродажах я уже купил себе пачку книг и докупил на этой распродаже еще книг Новые купленные книги - Производительность систем - интересная книга о производительности от Brendan Gregg, крутого эксперта, который одновременно много сделал для внедрения eBPF, о чем можно узнать из документалки - Креативный программист - я решил изучить креативные методы, что могут помочь в решении инженерных задач - Продвинутые алгоритмы и структуры данных - книжка о самых необходимых алгоритмах решения сложных задач программирования в области анализа данных, машинного обучения и графов. Хочу подтянуть свои знания алгоритмов - Ненормальные личности. Учение о психопатах - решил почитать про ненормальность от Ганнушкина - Об уме вообще - книга Павлова (хозяина знаменитой собаки из экспериментов), который писал интересно о работе мозга Книги, что я уже успел прочитать - Чистый Python. Тонкости программирования для профи - решил вспомнить теорию по python - Компьютерные сети. Принципы, технологии, протоколы: Юбилейное издание, дополненное и исправленное - я уже как-то читал книгу Олиферов, но это было много лет назад и она была ок. Сейчас я прочитал 150 страничек из нового издания и могугу - Гейм-дизайн: как создаются игры - эта книга про геймдизайн, про который я и до этого много читал и писал (1, 2, 3), а сейчас я уже прочитал и рассказал об этом - Разработка приложений на базе GPT-4 и ChatGPT - базовая книга про chatGPT, я ее уже прочел и даже рассказывал оо ней - Мифический человеко-месяц, или Как создаются программные системы - классическая книга Фредерика Брукса, которая в следующем году справляет свой юбилей. Я раньше уже рассказывал про эту книгу - Распределенные данные. Алгоритмы работы современных систем хранения информации - в девичестве на английском эта книга Алекса Петрова называлась Database Internals и я про нее много рассказывал (1 и 2), а также мы ее обсуждали в подкасте "Code of Architecture" - Безопасные и надежные системы: Лучшие практики проектирования, внедрения и обслуживания как в Google - эту книгу я читал в оригинале и она называлась "Building secure and reliable systems", а также уже рассказывал про нее. Книги, что мне еще предстоит прочитать - Data mesh в действии - интересная тема о переходе от DWH в сторону Data Mesh и Lake House. До этого я читал частями книгу "Data Mesh: Delivering Data-Driven Value at Scale". - Грокаем алгоритмы искусcтвенного интеллекта - просто тема интересная для меня:) - Настоящий CTO: думай как технический директор - тут я решил сравнить насколько я думаю как настоящий технический директор, а то вдруг я думаю как-то не так:) - README. Суровые реалии разработчиков - книга про будни разработчиков и практиками инжиниринга - Software: Ошибки и компромиссы при разработке ПО - эта книга подкупила меня своей второй главой, которая называется "Дублирование кода не всегда плохо". - Грокаем Continuous Delivery - я вроде неплохо понимаю в CI/CD, но хочется почитать про него подробнее - Грокаем функциональное программирование - интересно почитать просто про функциональщину - Дизайн для разработчиков - я довольно много книг читаю про дизайн для дизайнеров (1, 2, 3), а тут хочу посмотреть как это подают разработчикам - Карьера Software Engineering Manager. Эффективное управление командой разработчиков ПО - в рамках работы над книгой про engineering management полезно изучить другие источники - Карьера продакт-менеджера. Все что нужно знать для успешной работы в технологической компании - для инженеров и технических руководителей сейчас полезно думать продуктово, особенно если вы работаете не в галере. Яуже писал про книги на эту тему: 1, 2, 3, 4, 5 - Паттерны проектирования API - я люблю паттерны, люблю хорошие API, плюс мне понравилось оглавление. #Sales

How to Make the World Add Up (Ложь, наглая ложь и статистика) - Part I (Рубрика #Math) Забавно, как книгу Тима Харфорда "How to Make the World Add Up" озаглавили на русском крылатой фразой "Ложь, наглая ложь и статистика". Фраза конечно громкая и книга скорее всего хорошо продается, но при этом переводе полностью теряется смысл фразы из оригинального названия, а точнее "make the world add up", которая в данном контексте означает стремление к тому, чтобы мир "сошёлся", то есть чтобы информация и данные вокруг нас были понятны, логичны и соответствовали реальности. А книга Тима как раз посвящена тому, как статистические данные могут быть использованы для манипуляции и искажения истины. Автор предлагает десять простых правил (+ одно золотое), которые помогут читателю научиться различать правду за цифрами и не поддаваться на когнитивные ловушки. И вот эти правила 1. Прислушайтесь к голосу сердца. Нужно уметь останавливаться и определять эмоциональную реакцию, которое вызывает то или иное заявление. Главное - это не принимать решения под влиянием эмоций. Автор рассказывает про аферу века с картинами Вермеера, которому поддался Бредиус, главный эксперт по творчеству этого художника. Он это сделал под влиянием своих эмоций и ожиданий. 2. Учитывайте свой личный опыт. Важно полагаться не только на цифры, но учитывать контекст и собственные наблюдения. Статистику автор называет взглядом птицы, а собственные наблюдения - взглядом червяка. Осмысление противоречий между ними поможет лучше понять ситуацию и разобраться в вопросе. 3. Не спешите с подсчетами. Важно не только уметь работать с числами, но и задавать вопросы относительно того, а что именно подсчитывается и какие истории скрываются за этим. Я часто видел дашборды, которые использовались для принятия решений, но никто из принимающих решения до конца не понимал терминов и методологию расчета:) А вопросы, а что собственно мы тут считаем вызывали реакцию вида "бей или беги". Оставшиеся правила в следующем посте. #Math #Management #Statistics

Code of Leadership #22 - Интервью с Дмитрием Аношиным про data engineering (Рубрика #Data) В этом выпуске ко мне пришел в гости крутой гость, Дмитрий Аношин. Дима является экспертом в data engineering, ведет канал @rockyourdata, также Дима почти 10 лет работал западных Bigtech компаниях. Кстати, выпуск доступен в виде подкаста и в Яндекс Музыке. Мы обсудили следующие темы: - Как Дима входил в IT порядка 15 лет назад - Как он развивал свои навыки как дата инженер - Как он уехал в Канаду и адаптировался там - Как развивалась карьера Димы в Amazon, Microsoft и что он вынес из этого опыта - Как Дима стал создателем обучающих проектов datalearn, surfalytics, а также как ему удалось написать целую гору книг - Как находить мотивацию для роста и развития Если говорить подробнее про Дмитрия, то он уже больше 15 лет занимается аналитикой и инжинирингом данных, а 10 последних лет проработал в Северной Америке. Из них 5 лет в Амазоне, где работал в нескольких командах, включая Alexa AI (в Бостоне) и Customer Behaviour Analytics (в Сиэтле). Поучаствовал в действительно инновационных проектах, где драйвером являются данные. Видел и Big Data и Machine Learning в действии в масштабе крупнейшей компании мира. После Амазона работал 4 года в Microsoft Xbox и Microsoft Azure Data&AI. Активно принимал участие в развитии Microsoft продуктов для аналитики - Synapse, Fabric, Azure Databricks. Теперь, Дмитрий помогает создавать инновационные аналитические решения, дата команды и модернизировать устаревшие решения через свою компанию rockyourdata.cloud и глобально готовит инженеров и аналитиков через свое сообщество Surfalytics.com (на английском), до этого несколько лет развивал проект Datalearn.ru, на котором делился фундаментальными знаниями и помогал бесплатно всем желающим войти в ИТ, знания там все еще актуальны. Дмитрий написал несколько книг по аналитике и преподает несколько лет Облачные Вычисления (Cloud Computing) в партнерстве с Microsoft в Университете Виктории. Еще из интересных проектов: - Создал онлайн выставку писем CEO про увольнения в крупных компаниях - https://www.layoffmemos.com/ - Совместно с Московским Зоопарком и Вконтакте организовал группу по наблюдению за популяцией пеликанов и экомониторинга с использованием AI - https://www.scifly.ai/ Из последнего, Дмитрий создает главный Российский портал Дата Инженеръ посвященный карьере дата инженера, куда он планирует добавить road map для вакансий Инженера Данных, Аналитика и BI разработчика и ссылки на лучшие бесплатные ресурсы: книги, тренинги, курсы, видео, телеграмм каналы, и многое друго, что поможет понять, кто такой иженер данных и как таким стать, преимущественно на русском языке. #Database #Architecure #Software #Data #SystemDesign #Management