Apache Kafka. Потоковая обработка и анализ данныз (Kafka: The Definitive Guide)

Все привыкли, что я читаю книги достаточно быстро, но вот с этой книгой получилось не так - пока я читал перевод первого издания вышло второе:) Первое издание вышло осенью 2017 году, а второе в конце 2021. Первое издание состоит из 11 глав

1. Meet Kafka - в этой главе мы встречаемся с главным героем и знакомимся с базовыми понятиями обмена сообщениями, дальше мы узнаем про основы Kafka: сообщения и пакеты, схемы сообщений, топики и партиции, producers и consumers, а также как выглядят сами брокеры и как они объединяются в кластера.
2. Installing Kafka - здесь авторы рассказывают про установку Kafka и на что обращать внимание при выборе железа (интересно, что во втором издании авторы делают больший акцент на переезде в облака)
3. Kafka Producers: Writing Messages to Kafka - здесь обсуждаются вопросы записи в Kafka (само название говорит о том, что эта система ориентирована на писателей:) ). Здесь говорится про конфигурацию producers, сериализацию и работу с партициями
4. Kafka Consumers: Reading Data from Kafka - здесь идет речь про то, как читать из Kafka и управлять оффсетом через разные варианты коммитов: автокоммит, асинхронный и синхронный коммит
5. Kafka Internals - эта часть интересна тем, кто любит заглядывать под копот. Тут идет речь про то, как работает сам кластер, как реализуется членство в кластере, что такое контроллер, как выглядит репликация, а дальше обработка запросов (на запись и на чтение), а дальше как работает физический уровень
6. Reliable Data Delivery - здесь обсуждаются гарантии доставки и как их обеспечить за счет совместной работы producer, Kafka и consumers. Здесь как раз можно почитать про семантику at least once и exactly once в Kafka
7. Building Data Pipelines - здесь кратко рассказывается про ETL пайплайны и работу с Kafka Connect (подробнее на эту тему рекомендую почитать Data Pipelines Pocket Reference)
8. Cross-Cluster Data Mirroring - про репликацию данных между кластерами и что лучше стягивать данные с удаленного кластера, чем их пушить в удаленный кластер (если есть такая возможность)
9. Administering Kafka - вопросы администрирования Kafka, здесь зарыто достаточно сложности, но эту часть определенно стоит почитать, если у вас Kafka в production:)
10. Monitoring Kafka - здесь обсуждаются вопросы мониторинга и они по большей части относятся к мониторингу java приложений и дальше использованию JMX для получения данных для мониторинга из процессов Kafka
11. Stream Processing - это интересный раздел про потоковую обработку, который подан очень сжато, но позволяет понять область применимости Kafka Streams API

На этом книга оканчивается, но есть смысл сразу пойти и изучить второе издание, чтобы оценить накопившиеся за пять лет различия:))

#Data #Databases #Engineering #SoftwareArchitecture #Software #SoftwareDevelopment #Management #Queue

Вакансии в наши команды DBaaS (Database as a Service)

Я очень люблю распределенные системы, архитектуру, дизайн систем. А самое интересное в этом та часть, где хранится state или по простому базы данных. Причем базы данных бывают разные и сейчас у нас в компании активно разрабатывается продукты Database as a Service (пока Postgres и Cassandra). И если вы любите базы как я и еще умеете писать код на Python или Go, то вы можете присоединится к этой команды.

Вот как они сами описывают свой продукт
- Наша команда делает продукт для массового управления кластерами БД.
Но не просто систему получения кластера БД - мы глубоко интегрируемся с платформой разработки, платформой мониторинга и алертинга, платформой доставки данных, и т.д.
Это позволяет предоставить бесшовный опыт для большого количества пользовательских сценариев буквально по клику мышки и вызову одной команды.

А вот какие планы по развитию этих продуктов
Сейчас мы предлагаем пользователям кластера PostgreSQL и Cassandra, однако планируем расширять список поддерживаемых БД. Запускаемые нагрузки активно растут, сейчас это сотни команд и тысячи кластеров, однако ожидаем десять+ тысяч кластеров. Одним словом - огромное количество возможностей для развития и прокачки скиллов в условиях решения нетривиальных задач, с которыми сталкиваются только крупнейшие компании. Сейчас большинство БД работает на виртуальных машинах в приватном облаке, однако в ближайшее время мы планируем запускать наши БД на Baremetal K8s для улучшения производительности.

Вот стек и конкретные задачи, которыми можно будет заняться прямо сейчас
Пишем на Python и Golang, c упором на надежность кода и полное покрытие тестами. Сейчас есть много продуктовых и технических целей как в части подключения Change Data Capturing в PostgreSQL, реализации Disaster Recovery Plan, так и в части управления конфигурациями, инфраструктуры, K8s и разработки Control Plane. Наша команда самостоятельно проектирует, декомпозирует, прототипирует и реализует такие задачи.

Немного про условия
Трудоустройство возможно как в РФ, так и в странах СНГ с Центрами Разработки Тинькофф.

Если вам хочется заниматься такими задачами, то напишите мне в личку (@apolomodov) и дальше я пообщаюсь с вами и познакомлю с коллегами.

#Vacancy #Databases #SoftwareDevelopment #Engineering #Architecture #Architect

Материалы из Code of Architecture про базы данных и распределенные системы

В продолжении поста хочу поделиться материалами из клуба Code of Architecture
- Design Data-Intensive Applications (вот плейлист)
- Database Internals - (вот статьи с краткими саммари каждого выпуска: 1, 2, 3 и 4)
- Distributed Systems, 4th Edition (вот статья с ссылками на все выпуски и кратким саммари)
- Обсуждение white paper "Amazon Aurora" (статья с саммари)

Ради интереса я попросил модель Сбера "Кандинский 2.2" нарисовать картинку к посту по описанию "База данных как сервис с логотипами postgres и cassandra" в стиле kandinsky и получилось забавно:)

#Vacancy #Databases #SoftwareDevelopment #Engineering #Architecture #Architect

POSTGRES: The First Experience (POSTGRES: Первое знакомство)

Эта книга отлично подходит для начинающих знакомиться с популярной базой данных Postgres. Авторами книги являются Pavel Luzanov, Egor Rogov, Igor Levshin, причем Егор Рогов является еще и автором книги "PostgreSQL 15 изнутри", а про эту книгу я уже рассказывал. И хоть книга про внутрянку Postgres хороша, но она сложновата для старта, а сегодняшняя книга отлично для этого подходит. Она состоит всего из 175 страниц, что разделены на 12 глав, представленных ниже. Скачать книгу можно здесь: русская версия, английская версия

1. PostgreSQL — what is it all about? - рассказ про возникновение и развитие проекта postgres
2. What’s new in PostgreSQL 15 - changelog изменений в версии 15 по сравнению с 14 версией
3. Installation on Linux and Windows - простенькая инструкция про установку postgres, чтобы с ней можно было поиграться
4. Connecting to a server, writing SQL queries, and using transactions - пример работы с postgres через командную строку с выполнением DDL (Data Definition Language), DML (Data Manipulation Language), DCL (Data Control Language), TCL (Transaction Control Language) или по простому: create table, alter table, drop table, select, insert, delete, update, grant, revoke, begin/commit, rollback
5. Learning the SQL language on a demo database - демо на примере букинга отелей, покупки билетов, аэропортов и так далее. Эту демо-базу можно скачать и поиграть с запросами посложнее, включая функции агрегации, оконные функции, работу с массивами, рекурсивные запросы, а также работу с расширениями.
6. Using PostgreSQL with your application - глава с рассказом о том, как заводить пользователей для отдельных приложений. Дальше удаленными подключениями из программного кода (php, perl, python, java). Дальше идет рассказ о том как делать бекапы.
7. Minimal server setup - глава про настройки postgres и как они влияют на работу системы. Здесь на сцене появляются настройки: буфферов (shared_buffers), размера кеша (effective_cache_size), рабочей памяти (work_mem), настройки autovacuum, настройки костов для планировщика запросов (random_page_cost и seq_page_cost). Интересно, что в книге приводит настройка 1C.
8. About a useful pgAdmin application - глава про использование UI для конфигурирование postgres
9. Advanced features: full-text search, JSON format, foreign data wrappers - рассказ про дополнительные фичи, доступные в postgres, среди которых есть полнотекстовый поиск, который не сравнится с условным elastic, sphinx, но для части вещей подойдет. Другая крутая фича jsonb, которая позволяет использовать postgres как документо-ориентированную базу данных (залезая на террирторию MongoDB), причем мы можем индексировать поля внутри jsonb. Ну и финальная фича - это внешние интеграции через foreign-data wrapper.
10. Education and certification opportunities - здесь идет речь про обучение и сертификации, которые есть у компании Postgres Professionals и какие области они покрывают.
11. Keeping up with all updates - описание источников для получения дополнительной информации: mailing list, конференции
12. About the Postgres Professional company - описание компании Postgres Pro, вендора Postgres из России, в которой работают авторы этой книги

#Databases #DistributedSystems #Architecture #SoftwareArchitecture #Software

Designing A Data-Intensive Future: Expert Talk • Martin Kleppmann & Jesse Anderson • GOTO 2023

Это крутое интервью от топовых специалистов
- Мартина многие знают как автора классической книги с кабанчиком ("Designing Data-Intensive Applications"), сейчас он больше исследователь и занимается так называемым "Local-First Collaboration Software" (automerge) - подробнее можно посмотреть в выступлении Мартина, которое я разбирал месяц назад
- Jesse я узнал в качестве автора книги "Data Teams", а также автора интересного выступления "Why Most Data Projects Fail and How to Avoid It", про который я рассказывал 2 месяца назад
Оба участника превосходно шарят в теме разговора и их интересно слушать. Вот тут доступна расшифровка.

Ниже тезисно расскажу основные мысли
Мартин рассказывает про свою книгу "DDIA", котороя про основы работы с данными и широкий ландшафт технологических решений (на момент 10 лет назад, когда Мартин начинал писать книгу)
Мартин планирует написать второе издание книги, в котором он рассмотрим вопросы
- Рост популярности cloud-native приложений и разработку распределенных приложений слоями, когда одна распределенная система опирается на нижележащую распределенную систему и так далее - рекомендую про это подробнее прочитать в whitepaper от ребят из Google "Deployment Archetypes for Cloud Applications", про которую я рассказывал раньше
- Закат Map-Reduce, чью поляну забрали cloud DWH с точки зрения аналитики и стриминговые системы с точки зрения приложений с кастомной логикой
Мне нравится, что Мартин продолжить и во второй книге использовать подход

So I'm not telling people what to do, I'm telling people what questions to ask.

Правда, написание новой книги идет не быстро, поэтому ждать ее скоро не стоит.
Потом Martin и Jesse обсуждают концепцию единого инструмента для всех задач, связанных с данными, и приходят к выводу, что если бы такой инструмент был, то он бы делал все эти задачи плохо. Поэтому Martin говорит о том, что надо использовать правильные инструменты для конкретных задач, например, удобно начинать с реляционной базы данных, которая достаточно гибкая и производительная. Круто использовать streaming systems для того, чтобы иметь потом возможность переключиться на более удобное решение

For example, you could run both consumers side by side for an amount of time, check the consistency across the two systems, and then eventually decide to switch over from the old one to the new one. Streaming systems allow that so much better than, for example, systems based on, like, doing calls to individual services. So I feel like, as you said, the streaming can help with making change easier there.

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

Дальше Мартин вспоминает про automerge, что я упоминал в начале и потом переходит на тему работы ученым и почему он переключился после 10 лет пребывания в стартапах на стезю ученого и как это позволяет ему лучше продумывать сложные идеи в области distributed systems. А также почему так мало PhD диссертаций превращаются в рабочие системы (значимое исключение Apache Flink).

Ну и напоследок участники дают советы
- Мартин: "I guess my recommendation would be to learn just enough about the internals of the systems that you're using so that you have a reasonably accurate mental model of what's going on there."
- Jesse: "There are a lot of paths out there. Pit's to look out the various paths, look at what you want to do and what your skills are and see if one of those applies to you", где приведены карьерные варианты: разработка, менеджмент, наука, консалтинг, devrel. И в зависимости от сильных сторон и предпочтений, стоит выбрать свой путь.

#Management #Data #Databases #SystemEngineering #DistributedSystems #Software #Architecture

How Data & Software Eng. Teams Collaborate to Ensure Smooth Data Integrations • Sam Bail • GOTO 2023

Интересное выступление Sam Bail про коллаборацию команд, что отвечают за разработку софта и за аналитические данные:) Слайды этого выступления доступны здесь.

Сетап проблемы выглядит так

Product manager: We’re launching this awesome new feature next month! And we need analytics from day 1! Let’s GOOO!
Data team: HOLD ON! Lemme talk to the software engineering team first and see what their data architecture looks like…

А дальше доклад посвящен следующим темам и выстроен в виде важных вопросов, которые обычно задает Sam в очередном проекте
1. Logistics - нужны доки, нужны встречи и понятная зона ответственности, понятные коммуникации, ответы на вопросы: что мы планируем измерять и когда (уже в первый день, неделю, месяц, ...). Как сделать так, что команда разработки была в синке с аналитикой.
2. Infrastructure - где хостятся данные, какой там тип хранилища, могут наши ETL инструменты с этим справиться, нужен ли SSH туннель. Есть ли prod и dev инстансы, мы используем реплики для получения данных? Нужен ли нам доступ на запись? Что мы делаем с credentials (личные они или общие, как мы их шарим). Когда удастся получить доступ к данным? На dev или prod?
3. Data model - как выглядит схема данных, есть ли документация, кто поддерживает изменения в схеме и кто и как их коммуницирует? Как будет выглядеть data constraints enforcing (foreign key relationship, NULL values, default values, JSON schemas)? Как обрабатываются таймзоны в датах, валюты? Действительно ли мы сохраняем все, что хотим измерять?
4. Application and data flow - как и когда записи создаются и поля заполняются значениями? Какие действия вызывают модификации значений? Как события модификаций данных логируются (поле updated_at или отдельная таблица с событиями логирования)? Как будут обработаны удаления (hard или soft удаления)? Архивируются ли "старые" данные? Нужна ли миграция данных из старого приложения? Будут ли реалистичные тестовые данные, на которых можно будет разрабатывать? Будут ли тестовые данные в production среде?
5. Data contracts - как будут документированы договоренности из пунктов 1-4? И как мы будем обеспечивать их соблюдение в будущем не требуя слишком большого человеческого участия? Что из этого можно вынести в CI/CD и проверять на стороне производителе данных (а не как обычно на стороне потребителя)? Как нужно будет коммуницировать об изменениях и кого надо будет информировать об этом? Что делать, если что-то сломается? Как надо будет репортить о проблемах, а также какое SLA будет на фиксы?

Автор обобщает весь доклад тремя пунктами

- Integrating data from a new source into your data warehouse isn’t just “plug n play”
- There are an infinite number of questions to consider. You will probably miss something.
- The key is connection and context between teams.

А дальше, если все сделать правильно, то проблема из самого начала превращается в

Product manager: Look at this awesome new feature! And the dashboard to track all these cool metrics!
Data team: Well it’s not everything you asked and it was a bit bumpy getting there, but it works! Go team!

#Data #Software #SoftwareDevelopment #Engineering #Management #Leadership #Databases

AWS re:Invent 2023 - [LAUNCH] Achieving scale with Amazon Aurora Limitless Database (DAT344)

Продолжая вчерашнюю тему про модели консистентности, рекомендую посмотреть интересное выступление от ребят из AWS про значимый апгрейд их базы данных Aurora, которую мы как-то обсуждали в бонусном выпуске "Code of Architecture" и по которой есть whitepaper от 2017 года. Сейчас ребята добавили возможности масштабирования к этой базе данных. Причем тут фокус был на масштабировании write нагрузки, так как с read нагрузкой у этой базы уже было все хорошо. Если кратко описывать изменения, то смысл примерно такой

1) Добавляется семантика шардирования внутри самого Aurora - для этого у пользователей появляется возможности
- Пометить таблицы как шардированные и указать ключ шардирования - если транзакции попадают на один шард, то это максимально быстро, если нет, то используются распределенные транзакции двухфазный коммит. Для шардирования используется hash-range partitioning.
- Пометить часть таблиц как reference - такие таблички используются как справочники и они разложены на каждом шарде (их стоит использовать, если write нагрузки на эти таблички небольшие)
2) Шардированная база поддерживается семантику вида read commited и repetable read
3) Эта семантика работает внутри кластера Aurora, поэтому общие штуки типа дампа или point-in-time recovery работают как ожидается от кластера без шардов
4) Под капотом все это работает за счет добавление концепции shard group внутри aurora cluster, где есть роутеры для распределенных транзакций (здесь координируются распределенные транзакции и собирается общий результат) и шардов для доступа к данным (здесь выполняются локальные части запросов, работает локальный планировщик, используются индексы и так далее). Здесь тоже появляется дополнительный параметр compute redundancy, который позволяет compute частям шардов лучше переживать отказы
5) Для реализации repetable read ребята используют концепцию bounded clocks, которая похожа на концепт TrueTime из Spanner. Смысл этой концепции в том, чтобы использовать метки времени с разных устройств для упорядочивания транзакций. Проблема в том, что часы на разных машинка время может чуток отклоняться, поэтому приложению нужно несколько параметров: current time (approximate), earliest possible time, latest possible time. А дальше приложение должно подождать немного для того, чтобы точно не выставить транзакции метку времени из прошлого (иначе это может нарушить порядок транзакций в кластере). Эти параметры приложение получает из сервиса EC2 TimeSync с точностью порядка микросекунд. В самой презентации рассказывается как это работает для локальных и распределенных транзакций, а также для выполнения запросов с агрегатами.
6) В конце доклада авторы рассказывают про то, как взаимодействуют роутеры и шарды, а также как померить эффективность запросов, какие запросы получают максимальные бенефиты от параллелизации выполнения запросов на разных шардах (создание индексов, вакуум, агрегаты)
7) Пока эта limitless версия Aurora доступна через заявку на превью

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

#Software #Architecture #DistributedSystems #SystemDesign #Engineering #Databases

The 12 Factor App for Data • James Bowkett • GOTO 2023

Интересное выступление James Bowkett на тему хороших подходов для работы с данными. В названии он делает отсылку к 12 факторам, которые в свое время сформулировали ребята из Heroku и которые стали предвестником подходов cloud native приложений. James предлагает 12 факторов, которые помогут сделать более качественным пайплайн работы с данными, которые часто называют сейчас big data и используют для обучения ML моделей:) Мне принципы Джеймса понравились, а особенно понравилось то, как он их структурировал

-> Architecture & Design - факторы, относящиеся к проектированию решений
1. Data structures as code - универсальный совет не полагаться на UI, а конфигурировать настройки для управления данными через код. Это стандартный совет в духе IaC (infrastructure as a code), GitOps и так далее.
2. Append-only data structures - использование таких структур данных добавляет историчность и позволяет time travel.
3. Optimise for access and retrieval - автор рекомендует не делать кладбище данных (data graveyard), а думать про то, как денормализовать данные так, чтобы их было удобно использовать
4. Separate data from logic - автор предостерегает от использования протекающих абстракций (leaky abstraction), навроде магических значений, которые требуют специальной обработки на стороне потребителя. Это приводит к запутанности в данных, а также куче дополнительной лапши в коде у потребителей
5. Strongly type your data columns - автор призывает думать про типы данных и использовать их. Это позволяет получать более качественные данные в хранилище + сами движки хранения эффективнее работают если нам не нужно непрерывно кастовать данные между типами (что, кстати, тоже является протекающей абстракцией)
-> Quality & Validation - факторы, относящиеся к качеству данных и валидации
6. Architect for regression testability - наше решение должно быть спроектировано с учетом потребности в регрессионном тестировании отгружаемых данных, что является пререквизитом для CD (continuous delivery)
7. Track changes in your test data - автор рекомендуют хранить лог изменений, который применялись к тестовым данным, а также применять их консистентно между средами
-> Audit & Explainability
8. Mind your metadata: Data-Cataloguing - автор рассказывает про каталогизирование данных, что позволяет управлять метаданными. Мельком он упоминает OpenMetadata и Apache Atlas
9. Mind your metadata: Code Traceability - автор рекомендует организовать трассировку от данных к коду, системам, людям, которые их сгенерировали. Это позволяет понять происхождение данных, что может быть полезно при траблшутинге и не только
-> Consumption
10. Defined APIs for accessing data - автор рекомендует специфицировать API, отделить внутреннюю модель данных от внешней и никогда-никогда не открывать доступ к вашему внутреннему хранилищу (избегайте интергаций через шаренную базу данных)
11. Defined SLAs (& SLOs) for data - у API должен быть определен уровень обслуживания и ожидания для потребителей
12. Treat data as a product - данные надо воспринимать как продукт. А дальше стоит думать про потребителей продукта, их потребности, сценарии использования, ... В итоге данные начинают работать и организация становится data-driven.

#Data #DataOps #Databases #Software #Engineering #Management #Processes #Devops

Amazon Aurora DSQL (Рубрика #Data)

Вернер Вогель, CTO Amazon, в своем keynote на re:Invent 2024 полчаса рассказывал про новые возможности базы Aurora, которая появилась порядка 10 лет назад, а теперь перещла в класс newSQL и стала по фичам напоминать Google Spanner, который как раз появился больше 10 лет назад. Вот какие фичи выделял Вернер
1) Serverless Architecture - для автоматического масштабирования под нужные нагрузки
2) High Availability - для одного региона 99.99% availability, для мультирегионального master-master сетапа 99.999%
3) PostgreSQL Compatibility - полная подддержка PostgreSQL
4) Performance - обещают 4х скорость по сравнению с другими похожими решениями, видимо, из мира newSQL. Я бы глянул на бенчмарки, чтобы понять с кем они сравнивались:)
5) Active-Active Multi-Region Operations - собственно, мультирегиональный вариант, который может принимать записи и реплицировать их в реальном времени (интересно глянуть насколько это быстро работает в мультирегиональном исполнении)
6) Zero Infrastructure Management - пользователям не надо думать об инфре (кроме как сколько это счастье будет стоить)
7) Innovative Transaction Processing - здесь Вернер пафосно рассказыва про аналог гуглового TrueTime, что был еще 10+ лет назад в Google Spanner. Теперь у Amazon есть свои спутники и атомные часы для микросекундной точности и все это называется Amazon Time Sync Service. Это и позволяет сделать распределенные транзакции с хорошими гарантиями консистентности:)

P.S.
Про Aurora я уже часто упоминал раньше
- Бонусный выпуск Code of Architecture по white paper "Amazon Aurora: Design Considerations for High Troughput cloud-Native Relational Databases"
- AWS re:Invent 2023 - [LAUNCH] Achieving scale with Amazon Aurora Limitless Database (DAT344)

#Databases #Architecture #SoftwareArchitecture #SystemDesign #DistributedSystems #Cloud #Management #Leadership

Research Insights Made Simple #14 Review of"What goes around comes around ... and around" (Рубрика #Databases)

Этот выпуск посвящен обсуждению whitepaper "What goes around comes around ... and around" от Michael Stonebraker и Andrew Pavlo про развитие баз данных за последние 20 лет. Разбору статьи помогает мне Алексей Светличный, мой коллега, что руководит развитием отдела баз данных в Т-Банке. Алексей работает с базами данных более 15 лет, где он прошел путь от небольших систем, до крупных Enterprise решений. Сейчас руководит командой, которая разрабатывает DBaaS и развивает экспертизу по базам данных в компании.

За час общения с Лешей мы обсудили половину статьи, успев разобрать общее впечатление от статьи и часть про модели данных и языки запросов. В итоге, получились следующие темы
- Введение и знакомство с гостей
- Общий обзор статьи
- Отличия российского и мирового контекста развития БД
- Обсуждение авторов статьи и их влияния на индустрию (Майкла Стоунбрейкера и Эндрю Павло)
- Эволюция моделей данных и языков запросов
- MapReduce (аля Hadoop и почему они уже leagcy)
- Системы KV и их ограничения
- Документно-ориентированные базы данных (MongoDB)
- Wide Column Family и Apache Cassandra
- Полнотекстовый поиск - Elasticsearch и встроенные возможности в RDBMS
- Векторные базы данных и семантический поиск
- Многомерные данные и array databases
- Графовые базы данных
- Заключение и анонс следующей темы

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

#Software #Engineering #Metrics #Databases #Architecture #Devops

Вакансия java разработчика в a/b платформу (Рубрика #Vacancy)

Что-то в последнее время я пишу только про позиции engineering менеджеров, но нам в компании требуются не только руко водители, но и крутые инженеры на сложные задачи. Сегодня я хотел рассказать про позицию java разработчика в a/b платформу в команду, что делает движок для обсчета всех метрик по экспериментам для всей компании. Круто, если этот инженер будет уровня senior и дополнительным плюсом будет глубокое знание Apache Spark.

Если говорить про a/b платформу, то это действительно важный для всей компании проект, который несет под себе инженерную сложность (про нее расскажу подробнее). Если говорить про a/b тесты, то есть классическая книга Рона Кохави "Доверительное a/b тестирование", про которую я рассказывал раньше. Если же говорить про историю a/b платформы, то она была у нас давно, но раньше их было много и они кусочно покрывали разные уровни тестов - когда я приходил в компанию порядка 9 лет назад, то уже тогда был прототип платформы DCO, которую мы с тех пор раскачали и использовали для экспериментов в вебе и мобильных приложениях. Пару лет назад мы решили закопать DCO и сделать новую платформу Hippo (я как-то показывал ее потенциальный логотип).

С тех пор платформа сильно выросла и научилась многому, но пришло время масштабировать ее на всю компанию и для этого надо сделать многое по расчету метрик, которые прошли следующий путь
- Все аналитики из продуктов считают метрики по экспериментам в своих python ноутбуках (легко ошибиться или получить результат, пытая данные под разными углами)
- Лаборатория экспериментальной статистики написала свои алгоритмы обсчета метрик для a/b экспериментов на таких же лабах, но для ограниченного набора метрик
- Инженерная команда metric store забрала эти python ноутбуки и перевела на Apache Airflow, где расчеты велись поверх Greenplum, где MPP база была нашим основным хранилищем данных для аналитических вычислений
- Инженерная команда metric store перевезла расчет этих метрик на новую архитектуру, где метрики считаются с помощью Apache Spark, а данные лежат уже внутри нашего Data LakeHouse (DLH)

По-факту, наша датаплатформа мигрировала на подход с DLH, который мы как-то разбирали с Колей Головым в подкасте Research Insights. Кстати, в ближайшее время будет серия подкаста с разбором того, как мы это делали с техническим директором датаплатформы. Плюс про a/b платформу тоже будет отдельный эпизод подкаста, где мы поговорим про то, что это такое, насколько она важна и сложна. Но если вы хотели решать сложные технические задачи уже сейчас, то можете писать мне в личку и мы обсудим варианты.

P.S.
Кстати, у меня уже есть эпизоды
- С руководителем этого отдела Андреем Цыбиным, где мы говорили про соседний продукт Statist (продуктовая аналитика)
- С лидом бекенда этого продукта Женей Козловым, где мы говорили как про бекенд Statist, так и в общем про инженерный подход к разработке

#Engineering #Software #Career #Vacancy #Databases #Fintech

Research Insights Made Simple #15 Review of"What goes around comes around ... and around" - Part II (Рубрика #Databases)

Этот выпуск продолжает обсуждение whitepaper "What goes around comes around ... and around" от Michael Stonebraker и Andrew Pavlo про развитие баз данных за последние 20 лет. Здесь мы поговорили о том, как менялись архитектуры баз данных и почему, а также обсудили выводы авторов исследования о будущем баз данных. Разбору статьи помогает мне Алексей Светличный, мой коллега, что руководит развитием отдела баз данных в Т-Банке. Алексей работает с базами данных более 15 лет, где он прошел путь от небольших систем, до крупных Enterprise решений. Сейчас руководит командой, которая разрабатывает DBaaS и развивает экспертизу по базам данных в компании.

За час общения с Лешей мы обсудили вторую половину статьи, куда входили следующие темы

- Введение и план обсудить эволюцию архитектур баз данных за 20 лет.
- Развитие архитектур реляционных и колоночных БД
- Появление и развитие облачных БД с разделением хранения и вычислений (масштабирование ресурсов, эластичность вычислений, объектное хранилище)
- Прорывы в OLTP-масштабировании (пример AWS Aurora)
- Data Lake House и гибридные движки (Parquet, Iceberg, разделение масштабирования воркеров и хранилища)
- Качество данных и подходы к хранению разных классов данных
- Изменение парадигмы ответственности за данные в компаниях (Data Mesh)
- NoSQL базы, CAP-теорема и консистентность (MongoDB, Cassandra, ACID в NoSQL)
- NewSQL базы (Google Spanner, CockroachDB, YDB) и сложность их эксплуатации
- Новые технологии и аппаратная поддержка БД
- Роль маркетинга в успехе технологий, опенсорс и пользовательский опыт
- Финальные выводы whitepaper и размышление о будушем баз данных

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

#Software #Engineering #Metrics #Databases #Architecture #Devops

Code of Leadership #50 - Interview with Sergey Mikhalev about Odnloklassniki, VK, T-Bank and Data Platform (Рубрика #Data)

В очередном выпуске подкаста ко мне пришел интересный гость, Сергей Михалев, который работает техническим директором data platform в Т-Банке. До этого Сергей успел приложить руку к дата платформам Одноклассников и ВКонтакте. В этом видео мы успели с Сергеем обсудить его карьерный путь, который всю дорогу был связан с большими данными. Заодно мы обсудили как само это понятие менялось во времени и как выглядит state of the art сейчас, а также почему мы в Т-Банке переезжаем с Greenplum (mpp база данных) на более модный и молодежный подход с DLH (data lake house) и как имплементирует федеративный подход с data mesh, а также как поверх всего этого работает a/b платформа. А если быть точнее, то список тем, что мы успели обсудить за 2 часа приведен ниже

- Введение и знакомство с гостем
- Ранние годы, образование и профессиональный выбор
- Начало карьеры, оптимизация БД, миграции данных и рост до тимлида
- Рост компетенций
- Работа в «Одноклассниках» над дата инфраструктурой
- Инженерная и экспериментальная культура «Одноклассников»
- Важность данных и много a/b экспериментов как признак зрелого продукта
- Развитие дата-платформы в «Одноклассниках» и переход на позицию технического директора дата-платформы всего VK
- Переход в Т-банк и обсуждение культуры работы с данными, принятой в Т
- Уровень инженерной культуры, дежурства, обработка логов, AB-тесты, интерфейсы для экспериментов.
- Архитектура Greenplum, параллельность, ограничения, расширение кластеров
- Обеспечение надежности, риски при переключениях, резервная система. Ограничения Greenplum
- Новая архитектура дата-платформы с разделением compute и storage
- Новая парадигма работы с данными: внедрение дата контрактов
- Федерализация дата инженеров и передача ответственности в сами продуктовые команды
- Сервисы и дата-продукты, пайплайны, взаимодействие в экосистеме
- Форматы работы: офис против удалёнки
- Баланс работы и личной жизни
- Будущее IT и потенциал биомедицины
- Советы по саморазвитию и поддержанию мотивации
- Завершение и благодарности

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

#Software #Engineering #Databases #Architecture #Devops #Management #Career #Architecture #DistributedSystems #SystemDesign #Leadership

Research Insights Made Simple #17 - Measuring the Impact of Early-2025 AI on Developer Productivity (Рубрика #DevEx)

Разбор отчета METR "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity", где показано замедление разработчиков при использовании AI. Методология мне показалось хоть и интересной, но объем выборки аж в 16 инженеров казался мне маловатым для того, чтобы делать громкие заявления о замедлении разработки. Правда, такой размер выборки не помешал многим журналистом активно писать про это исследование. В итоге, я позвл в гости Артема Арюткина, СРО платформы для разработчиков в Городских сервисах Яндекса, вместе с которым мы обсудили все плюсы и минусы этого исследования.

Вот примерный список тем, что мы успели обсудить за 40+ минут
- Введение, анонс METR и бенчмарка
- Знакомство с гостем
- Спонсор исследования и возможная предвзятость
- Как устроен эксперимент
- Гипотезы о мотивах и дизайне исследования
- Оценка и самооценка задач участниками
- Набор участников и требования к ним
- Ограничения масштаба и методологии
- Цифры: 246 задачи от 1 до 8 часов по длительности, 16 инженеров в исследовании
- Пять факторов замедления работы
- Контекст, интеграция и коммуникации как узкое место
- Как работать с инструментом по уровням сложности
- Почему моделям сложно применять изменения в реальном коде
- Итоги бенчмарков и ограниченность генерализации

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

P.S.
На Big Tech Night в ближайшую пятницу Станислав Моисеев, мой коллега, что руководит RnD центром, расскажет про разные подходы к измерению developer productivity в общем, а также то, как померить влияние Gen AI на это. Если тема вам интересна, то регистрируйтесь и приходите послушать.

#Software #Engineering #Metrics #Databases #Architecture #Devops

Code of Leadership #56 - Interview with Alexey Gorbov about system administration & databases (Рубрика #Engineering)

Интервью с Алексеем Горбовым, моим коллегой, который в Т-Банке занимается базами данных и разивает нашу Cassandra as a Service. Параллельно этому Леша курирует нашу секцию собеседований по траблшутингу для SRE, которую я когда-то курировал сам, а также рассказывал про нее на конференциях. За полтора часа мы обсудили множество тем

- Введение и представление гостя
- Детство, образование и первые шаги в IT
- Работа в «Одноклассниках»: начало карьеры
- Инцидент в ОК и переосмысление надежности
- Переход к системной надежности
- Работа с Cassandra и автоматизация процессов
- Новые технологии и взаимодействие команд
- Миграция дата-центра: проект и организация
- Уход из «Одноклассников» 
- Первые шаги с Cassandra в новой роли
- Развитие Cassandra как сервиса в Т-Банке
- Проблемы архитектуры и декомпозиции кода
- Практические выводы и преимущества Cassandra
- Рекомендации инженерам по поводу развития и роста

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

#SRE #Architecture #Reliability #Management #Staff #Engineering #Processes #Databases #DistributedSystems

[1/2] Monarch: Google's Planet-Scale In-Memory Time Series Database (Рубрика #Architecture)

Наконец-то я дочитал оригинальный whitepaper про эту интересную систему для работы с time-series данными от Google. Идея появилась после моего погружения в архитектурный whitepaper, где эту систему перепроектировали с использованием quality-based подхода и UML диаграмм. Если кратко, то суть примерно такая, что в 2020 году вышла статья на VLDB Endowment про эту самую масштабную в мире базу для временных рядов
1) Monarch - это глобально распределённая, мультитенантная in‑memory БД временных рядов для мониторинга почти всех пользовательских и инфраструктурных сервисов Google. Ежесекундно принимает терабайты метрик и обрабатывает миллионы запросов. Архитектура - разделенная по регионам с глобальным plane запросов и конфигурации.
2) Ключ к масштабу: лексикографическое шардирование по “target”, агрегация на этапе сбора, компактные индексы подсказок (Field Hints Index), двухуровневые исполнители запросов (Root/Zone Mixers).
3) На июль 2019: почти 950 млрд рядов в оперативной памяти (~петабайт сжатых данных); средняя агрегация при сборе 36:1 (до 1 000 000:1); индексы позволяют срезать fan-out до десятков тысяч лишних leaf‑узлов.

Как это примерно работало
- Система мультитенантная и глобальная. Региональные зоны автономно принимают и хранят данные в памяти, а глобальные плоскости обеспечивают единый запрос и конфигурацию. Это снижает зависимость от внешней персистентности и повышает доступность мониторинга во время инцидентов.
- Модель данных и запросов отличается от предшественника Borgman (кстати, именно Borgman стал прототипом Prometheus - об этом можно глянуть в документалке, о которой я рассказывал). В отличие от “строчных ключей” прежних систем, Monarch использует типо‑насыщенную реляционную модель метрик (включая распределения/гистограммы) и выразительный язык запросов, что упрощает статический анализ и оптимизации.
- Архитектура обработки выглядела примерно так
-- Ингест: клиенты → ingestion routers → зона → leaf router → Leaves (in‑memory). Уже здесь может работать collection aggregation.
-- Запросы: Root Mixer распределяет по зонам (Zone Mixers); Index Servers (в т.ч. Field Hints Index) заранее исключают нерелевантные узлы, резко уменьшая фан‑аут.
- Отдельно были сделаны оптимизации
-- Collection aggregation: в среднем 36 входных рядов → 1; в экстремуме до 10⁶:1. Экономит память/CPU и трафик.
-- Field Hints Index (FHI): зоны с >10 000 leaves и триллионами ключей; FHI позволяет отсечь ~73 000 нерелевантных leaves для сложных выборок.
-- Лексикографическое шардирование по target: все метрики одного объекта попадают на один leaf → локальные агрегации/джойны, меньше fanout.

В продолжении рассказ, а что было с этой системой дальше.

#Software #Architecture #DistributedSystems #SRE #Engineering #Databases #Data