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

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 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

Архитектура в Т-Банке: вчера, сегодня, завтра — выступление на ArchDays 2024 (Рубрика #Architecture)

В этой статье я рассказываю про наши подходы к проектированию и построению архитектуры систем. Я в "Т" уже 8 лет и видел как эти процессы эволюционировали во времени, а также знаю к чему мы пришли. Я выделил следующие четыре стадии и объяснил как и почему они сменяли друг друга во времени
1. COTS (commercial of the shelf)
2. Свой собственный софт
3. Platform Engineering
4. Большие мегапроекты и governance

Напоследок я рассказал про подходы корпораций и технологических компаний к должностям/ролям архитекторов, а также поделился своим видением того, как нам дальше стоит развиваться. Эта статья является расшифровкой моего доклада на ежегодной конференции "ArchDays 2024", которая прошла в этом году уже в шестой раз.

#Architecture #Software #Evolution #Management

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: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

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

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

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

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

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

Вакансия партнера по работе с данными (Рубрика #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

Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity (Радикальная прямота) (Рубрика #Management)

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

Часть I - Новая философия менеджмента
1. Выстраивание радикально откровенных отношений. В этой главе описывается основная идея книги - важность сочетания личной заботы о сотрудниках с прямым вызовом. Автор объясняет, как это помогает улучшать рабочие отношения и повышать производительность команды.
2. Получать, отдавать и помогать. Эта глава посвящена методам установления доверительных отношений в команде, что является основой для успешного применения радикальной откровенности. Для этого автор описывает модель, которая визуализируется как двухмерный график. На графике вертикальная ось представляет "Личную заботу", а горизонтальная ось - "Прямой вызов". Цель состоит в том, чтобы работать в квадранте, где оба элемента высоки, создавая среду открытой и конструктивной обратной связи. Это и есть квадрант радикальной откровенности, а также есть разрушительное сочувствие, оскорбительная агрессивность и манипулятивная неискренность.
3. Что мотивирует каждого члена вашей команды. Здесь автор приводит свою модель суперзвезд и надежных сотрудников: фактически есть "суперзвезды", которые находятся на крутой траектории роста, и "надежные сотрудникы", которые предпочитают стабильность и устойчивую производительность. Признание этих различий помогает эффективно управлять ростом команды.
4. Добиться успеха вместе. В этой главе автор рассказывает про свою модель работы с людьми в команде "Выслушать" - "Объяснить" - "Обсудить" - "Решить" - "Убедить" - "Выполнить" - "Усвоить" и дальше опять "Выслушать". На протяжении всей главы автор рассказывает как должен работать этот цикл в компании.

Часть 2 - Инструменты и техники
5. Взаимоотношения. Эта глава посвящена построению и поддержанию эффективных отношений в команде. Автор подчеркивает важность доверия и открытого общения между коллегами. Она предлагает стратегии для улучшения взаимодействия, чтобы создать более сплоченную и продуктивную рабочую среду.
6. Наставничество. В этой главе рассматривается роль наставничества в развитии сотрудников. Автор объясняет, как руководители могут эффективно наставлять своих подчиненных, помогая им расти и развиваться в профессиональном плане. Она делится методами, которые позволяют вдохновлять и мотивировать сотрудников через личный пример и поддержку.
7. Команда. Глава фокусируется на создании эффективных команд. Автор обсуждает, как собрать команду, которая будет работать слаженно и продуктивно, а также как управлять различиями в характерах и навыках сотрудников. Автор подчеркивает важность разнообразия и инклюзивности для достижения лучших результатов.
8. Результаты. Заключительная глава посвящена достижению результатов через применение принципов радикальной откровенности. Автор делится инструментами и техниками, которые помогают руководителям не только устанавливать высокие стандарты, но и достигать их вместе с командой. Она акцентирует внимание на том, как измерять успех и корректировать подходы для постоянного улучшения.

Интересные факты о книге
- Ким Скотт активно использует свой опыт работы руководителем в bigtech компаниях, таких как Google и Apple.
- Она подчеркивает необходимость адаптации радикальной откровенности к различным культурным контекстам, чему она научилась в процессе работы с разнообразными командами по всему миру
- Книга не только теоретическая - она включает практические инструменты, такие как сценарии для сложных разговоров и основы для эффективных встреч.

#Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering

ЦЕХ 4 - Урок #23 "Продвижение автора. Личный кейс. Эксперт — Лариса Парфентьева" (Рубрика #Writing)

В очередном уроке разбирался пример личного продвижения автора. О своем пути рассказывала Лариса Парфентьева. Основные моменты, что я вынес из урока такие
1) У авторов есть внутренние стандарты при написании книг, иногда они мешают довести ее до конца, а значит надо уметь вовремя останавливаться
2) Сначала надо написать книгу, а потом ее продвигать:) Иначе может случиться фальстарта
3) Личный бренд автора включает книгу-бестселлер, личную историю, социальное подтверждение и профессиональные награды.
4) Круто, если биография автора интересна и легко запоминается читателями
5) Важно презентовать свою книгу друзьям, знакомым, чтобы запустить сарафанное радио
6) Завершение книги увеличивает самоуважение и уверенность в других сферах жизни
7) Авторам стоит участвовать в профильных концеренциях и работать с профильными СМИ (писать статьи по своей профильной теме)
😍 Профессиональные награды могут помочь в продвижении книги, но можно обойтись и без них
9) Маркетинговая деятельность требует энергии, за которую она конкурирует с написанием книги
10) Если вы интроверт и не хотите внимания, просто пишите блестящие книги. Издательства сами займутся продвижением.
11) Личная история может помочь в продвижении, особенно если она связана с вашей экспертной книгой.
12) Можно нанять специалиста в SMM (social media marketing) для помощи в продвижении книги, а можно самому вести соцсети
13) Но важнее всего писать хорошие книги, так как без этого маркетинговые активности пропадут втуне

Предыдущие посты про этот курс писательского мастерства доступны здесь
1. Увидеть свое имя на обложке может каждый
2. Целевая аудитория и ее потребности в создании книги
3. Жанры и стили. Как найти тему для нон-фикшн-книги
4. Как организовать работу
5. Как преодолеть писательские блоки. Практическое занятие
6. Жду музу, а она все не приходит
7. Книга по полочкам
8. MS Word для работы с большими и сложными текстами
9. Рассказываем истории: сторителлинг в книге
10. Саморедактура: работа с текстом, сокращения, фактчекинг
11. Правила сильной книги захватывающего текста
12. Авторская стилистика
13. Как превратить рукопись в сценарий
14. Рукопись готова. Что дальше?
15. Превращение рукописи в издание
16. Авторские права и договор с издательством
17. Дизайн книги.
18. Продвижение в самиздате.
19. Продвижение автора
20. Social media marketing (SMM)
21. Ведение блога и его продвижение в Телеграме
22. Взаимодействие с обозревателями, критиками и СМИ

#SelfDevelopment #PublicSpeaking #Storytelling #Writing

Research Insights Made Simple #5 "DORA Metrics, SPACE, DevEx, Human Approach to Dev Productivity" (Рубрика #Management)

Очередной выпуск подкаста с разбором whitepapers посвящен разбору темы developer productivity, где мы говорим про DORA метрики, фреймворк SPACE, подход DevEx, а также про human approach от Google к теме developer productivity. Для обсуждения этих тем ко мне пришел гость, Артем Арюткин, руководитель проектного и продуктового офиса в RideTech & e-com Яндекса. Артем отвечает за развитие платформы для разработчиков, а раньше в Сбере занимался развитие платформы Сбербанк онлайн и рекомендательной платформы. Артем ведет интересный телеграм канал "Плохой Project" (https://t.me/badTechProject). Кстати, выпуск доступен на двух площадках (Yandex Music и Youtube)

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
9) "Грокаем Continuous Delivery" - отличная книга, которая расскажет о CI CD и проведет вас по всему пути эволюции
10) "Гормоны счастья. Как приучить мозг вырабатывать серотонин, дофамин, эндорфин и окситоцин" - прекрасная книга, раскрывающая многие наши поступки. Мы слегка затронули тему длительного цикла обратной связи для менеджера и эта книга попадает туда, чтобы раскрыть тему. Но желание покрасить все тесты в зеленый простым их перезапуском - это, внезапно, про то, как работает наш мозг и желание получения быстрого дофамина. И когда занимаешься Developer Experience такое нужно учитывать

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

System Design for Interviews and Beyond - Курс на Leetcode - Part I (Рубрика #Architecture)

Я наконец-то закончил этот курс с Leetcode, в котором доступно и понятно рассказывали о том, что такое system design interview и что он призван проверять у кандидатов. В этом курсе много теории, но она подана в практико-ориентированном виде - автор не рассказывает про условные сети с начала времен и по сегодняшний день, а раскрывает основные концепции тогда, когда речь заходит про общение компонентов системы между собой. Похожее происходит и с хранением данных - легко уйти глубоко в теорию, но сложно удержаться и рассказать про b-tree и lsm-tree по ходу дела, рассматривая реальные вызовы проектирования системы. Но автор отлично справляется с вызовом и рассказывает одновременно понятно и достаточно точно. Если же возвращаться к содержанию курса, то он состоит из следующих частей

1. How to define system requirements.
Здесь автор говорил про важность функциональных и нефункциональных требования, а дальше проходил по типовым архитектурным характеристикам (-ilities), с которым обычно имеют дело на system design interview: high availability, fault tolerance, scalability, performance, durability, consistency, maintainability, security, cost efficiency. У автора курса отлично получилось объяснить все эти характеристики буквально на пальцах, а также показать их связь между собой, условно, все можно сделать безопасно просто отключив систему и сделав ее недоступной, но кажется, что нам нужен баланс:)

2. How to achieve certain system qualities with the help of hardware.
Здесь автор проводит связку между архитектурными характеристиками системы и тем, как она развернута. Он рассказывает про концепции регионов, зон доступности, дата центров, стоек и финально серверов. Дальше он переходит к рассказу про сервера, виртуальные машины, контейнеры и даже serverless. Я считаю, что эту базу нужно знать, чтобы дизайнить внятные системы.

3. Fundamentals of reliable, scalable, and fast communication.
Для того, чтобы из отдельных частей получилась система, этим частям надо уметь эффективно общаться между собой. В ээтой главе автор про это и рассказывает, а для этого он проговаривает основы
- Синхронные и асинхронные коммуникации
- Паттерны асинхронных коммуникаций (messaging queue, publish/subscribe, competing consumers, request/response, priority queue, claim check)
- Сетевые протоколы (UDP, TCP/IP, HTTP)
- Блокирующие и неблокирующие операции ввода/вывода (i/o)
- Формат кодирования данных (текстовые и бинарные, как шарить схему данных, backward/forward compatibility)

4. How to improve system performance with caching.
В этом разделе автор рассказывает про кеширование, но мне сам раздел показался вырванным из контекста рассказа - условно еще не поговорили про хранение данных, а уже воткнули куда-то кеши:)

5. The importance of queues in distributed systems.
Важный раздел, в котором автор детально разбирает очереди и их использование в распределенных системах (а в system design вы обычно дизайните как раз распределенную систему). В общем, автор говорит про следующие концепции
- Bounded и unbounded queue, а также про circular buffer (например, когда у вас логи по кругу перезаписываются в одно ограниченном по размеру файле)
- Что делать с переполнением очередей и пустыми очередями: load shedding, rate limiting, dead letter queues, backpressure, elastic scaling
- Паттерны producer-consumer, блокирующие очереди, семафоры
- Как работают thread pools, в чем разница между cpu-bound и i/o-bound задачами, как обеспечить graceful shutdown
- Как работает batching и параллельная обработка jobs

Продолжение обзора будет в следующем посте.

#Software #Architecture #DistributedSystems #SystemDesign #Engineering

System Design for Interviews and Beyond - Курс на Leetcode - Part II (Рубрика #Architecture)

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

6. Data store internals.
Здесь автор кратко рассматривает тему хранения данных:
- Log - самый простой способ сохранения данных, но вот читать их сложно в таком виде (full scan на любой запрос)
- Index - индексы в качестве способа подготовки данных для эффективных запросов на чтения
- Time series data - отдельный тип данных, которые полезны, например, при мониторинге
- Simple key/value database - автор объясняет как будет работать база с простейшей моделью данных
- B-Tree index - автор рассказывает про вездесущие b-tree индексы, как они устроены и для каких сценариев подходят оптимально
- Embedded databases - иногда удобно встроить базу прямо в процесс приложения, например, так могут LevelDB, RocksDB, DuckDB
- RocksDB - автор рассказывает как устроена эта база и тут речь про memtable, write-ahead log и SSTables
- Сравнение LSM-tree и B-Tree - автор показывает компромиссы каждого из подходов и сравнивает их границы применимости
- Page cache - заканчивает автор рассказом о том, как все это приземлить на файловую систему внутри OS. Без этих знаний многое из описанного выше не будет хорошо работать

7. How to build efficient communication in distributed systems.
В этой части автор говорит про классику коммуникаций
- Push vs pull модели взаимодействия
- Как выглядит host и service discovery (тут появляется DNS), а также peer discovery
- Как выбирать сетевой протокол под задачу (UDP, TCP, HTTP) и как они ведут себя на практике
- Как обычно передается видео-поток и что такое CDN (content delivery network)
- Что такое short pooling, long pooling, web-socket, server-sent events, зачем они нужны и как они ведут себя на практике
- В конце раздела автор показывает как могут работать пуши на клиентов на большом масштабе (аля Netflix)

8. How to delivery data reliably.
Этот раздел начинается с известного списка fallacies of distributed systems, а дальше автор переходит к практическим средствам обеспечения надежности
- Таймауты и стратегии действий с неуспешными запросами: cancel, retry, failover, fallback
- На конкретных примерах автор разбирает когда и как делать retries
- Дальше наступает время обсудить гарантии доставки сообщений: at most once, at least once, exactly once
- Дальше автор рассматривает как работают log-based message queues (аля Kafka) и что такое consumer offset

9. How to deliver data quickly
Здесь автор рассказывает про подходы к батчингу и компрессии данных, что обеспечивает лучшую пропускную способность.

10. How to deliver data at large scale
В этой части наступает время обсудить вопросы масштабирования обработки данных. Автор рассказывает про
- Партиционирование (шардирование) и рассматривает стратегии: lookup strategy, range strategy, hash strategy
- Как партиционирование работает в реальном мире и какие плюсы/минусы имеет
- Как выглядит роутинг запросов
- Что делать с ребалансировкой шардов
- Что такое consistent hashing

Продолжение обзора будет в следующем посте.

#Software #Architecture #DistributedSystems #SystemDesign #Engineering

System Design for Interviews and Beyond - Курс на Leetcode - Part III (Рубрика #Architecture)

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

11. How to protect servers from clients
Здесь автор рассказывает о том, как обычно выглядит overload системы, что такое autoscaling, как применять load shedding и как ограничивать количество запросов при помощи rate limiting. В общем, тут идет речь про базовые паттерны для построения надежных систем.

12. How to protect clients from servers
Здесь все начиналось с рассмотрения того, а какие типы клиентов бывают: синхронные и асинхронные. Дальше автор разобрал как работает circuit breaker и как он помогает как клиентам, так и серверам. Дальше речь зашла про fail fast principle, который в моем представлении противоречит концепции resiliency. Ну или это мой bias, когда я видел слишком много примеров небезопасного кода, который оправдывали подходом fail fast:) Следующий принцип bulkhead - я сам его люблю вспоминать в контексте переборок на Титанике, которые были сделаны хреново и на самом деле не защищали от проблем. Ну и финальный паттерн - shuffle sharding, который выглядит действительно интересно в разрезе количества пользователей, которых затрагивает проблемы при выходе нод из строя.

13. Практические задачки
В конце курса автор предлагает потренироваться в проектировании на достаточно стандартных задачках:
- Классический url shortener
- Fraud detection system
- Authn и authz система
- Мониторинговая система

#Software #Architecture #DistributedSystems #SystemDesign #Engineering