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

Стрим с Сергеем Щербининым про инженерную культуру в Тинькофф

Вчера вечером мы вместе с Сергеем пообщались в рамках "безвотэтоговотвсего" и обсудили большое количество вопросов, среди которых самыми интересными были:
- Что поменялось в Тинькофф за 7 лет, что я уже в компании
- Как мы выглядим внутри с точки зрения управления и организации работы и что позволяет разным нашим продуктам двигаться вместе (я рассказывал об этом на примере мобильного приложения Тинькофф на Highload++ 2022)
- Как устроены архитектурные подходы в компании (я про это рассказывал как-то на ArchDays 2020)
- Как можно смотреть на эффективность разработки (тут я вспомнил про темп разработки и качество продукта, см. подробнее в книге "Accelerate" и моем выступлении "Improving software flow" на нашем фестивале в Казани неделю назад)
- Какие культурные ценности в компании и почему именно такие (про это я пока только планирую дописать статью)
- Какие еще есть компании в России с крутой инженерной культурой

#Management #Leadership #Engineering #SoftwareDevelopment #Architecture #Podcast #Software

Трек "Архитектура, надежность, качество" на ИТ-пикнике

Через 2 недели, 2 сентября в Коломенском пройдет большой ИТ-пикник от Тинькофф, DevFest и Мельницы. Там будет музыка, научпоп, выступления про AI, менеджмент и конечно про архитектуру. И как раз в последнем треке получилось собрать крутых ребят в программный комитет: Олег Бондарь - CPO Yandex DB, Максим Смирнов - архитектор и автор популярного канала "Архитектура ИТ-решений", Дмитрий Масленников - руководитель центра надежности в Тинькофф, плюс последний участник - это автор этого канала.

А дальше уже мы собрали отличных спикеров с крутыми выступлениями в программу нашего трека. В итоге, получилась такая dream team:
- Дима Крутик из Тинькофф расскажет про то, как мы оцениваем качество услуг глазами глазами клиентов
- Сергей Баранов из Scrumtrak расскажет про восстановление архитектурных знаний
- Михаил Кабищев из Озон расскажет про internal developer platform в Озоне, зачем она нужна и как помогает эффективнее разрабатывать
- Егор Гордовский из Яндекс расскажет про то, как устроены датацентры Яндекса
- Павел Лакосников из Авито расскажет про паттерны отказоустойчивой архитектуры на примерах
- Андрей Якушев из VK расскажет про архитектуру ленты и рекомендаций в VK

Если вас заинтересовали эти темы, то приходите на фестиваль именно на наш трек:)
Для участия вам потребуется выбрать благотворительный фонд из списка и сделать донат от 1000 рублей. Подробности и регистрация — тут.

#Conference #Architecture #Software #SRE #QualityAssurance #SoftwareDevelopment #SoftwareArchitecture #DistributedSystems

Why Is My App SLOw? Defining Reliability in Platform Engineering • Jez Humble • GOTO 2023

Интересный доклад от Jez Humble, техлида SRE команды, которая поддерживает сервисы serverless платформы в Google Cloud. Основная проблематика следующая: в рамках этой платформы надо отслеживать ее работоспособность, но
- Ориентироваться при этом на восприятие клиентов того, насколько хорошо работают их приложения поверх платформы
- Можно ориентироваться на latency приложений, но у них разброс latency в пять порядков (от миллисекунд до сотен секунд)
- Можно ориентироваться на request delivery metrics, которые мерят время от попадания в сетевой слой Google и до доставки запроса до приложения и обратную часть этого цикла - но это чуть искусственная метрика.

В итоге, ребята поставили себе целью придумать метрику со следующими свойствами
- A metric that represents the customer experience
- Combinable across projects / cells / regions
- Can be used to detect anomalies affecting multiple customers (likely platform issues)
- Computationally cheap (high QPS)
- Principle-based

И они нашли ее опираясь на понимание статистики и используя концепцию стационарности (свойство процесса не менять свои характеристики со временем). Если кратко, то они выделил отдельные когорты запросов по версии приложений, развернутых в serverless платформе. Дальше для каждой когорты проверили укладывается ли распределение ее latency в логнормальное распределение. Если укладывается, то сохранили параметры распределения в базу, если нет, то откинули эту когорту. В итоге, половина нагрузок укладывается в логнормальное распределение. Дальше ребята используют подход 2 сигма для измерения 2 стандартных отклонений от среднего для каждой из когорт и собирают это в график, гда видно каков процент таких рабочих нагрузок с таким большим отклонением. Нормальное состояние платформы характеризуется 2% -5% рабочих нагрузок с отклонениями больше 2 сигма, а вот если этот показатель поднимается до 10%, то это повод для беспокойства. Для построения такого распределения обычно используется 15 минутное окно. Дальше автор рассказывает как это работает в деталях, но мне интересно рассказать еще о выводах, которые Jez подводит в самом конце доклада
- We can reliably detect and measure the impact of platorm regressions
- Reliability is a shared property (between customer & service)
-- Reconstruction of end to end behavior is critical
- Metric combinability is critical for analysis
- Variability is what customers actually care about
- Distributed systems ofen produce decorrelation
-- We can measure it, and its absence
- Workload correlation can identify proximate causes

Итого, это интересный доклад для тех, кто строит платформы и хочет выстроить SLO/SLA/SLI с учетом не только своих технических метрик, но и том, как себя чувствуют пользовательские нагрузки внутри платформы.

P.S.
Слайды доступны здесь.

#SRE #SystemDesign #Software #Architecture #Metrics #SoftwareArchitecture #Engineering #Math #ContinuousDelivery

Dream Team. Как создать команду мечты

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

В общем, читать книгу мне было интересно, но ... вот со второй половиной книги надо быть аккуратнее:)

Типичные ошибки проектирования (Bug Patterns In Java)

Эта книга из начала моей карьеры. На английском она вышла в 2002 году, а уже в 2003 году издательство Питер применило креатив при переводе и "Bug Patterns in Java", которые можно было перевести как паттерны багов в Java превратилась в типичные ошибки проектирования:) Но несмотря на креатив в названии, книга показалась мне тогда полезной и объемной. В ней всего 23 части
1. Agile Methods in a Chaotic Environment - здесь речь шла про гибкие подходы, концепцию паттерно в общем в и паттернов багов конкретно, а также зачем их изучать
2. Bugs, Specifications, and Implementations - объяснение как понять что такое баг, а что такое фича. После прочтения легко становится понятна фраза "Это не баг, это фича":)
3. Debugging and the Development Process - как отлаживаются программы, про парное программирование, про общее владение кодом и про написание тестов для "всего, что может сломаться"
4. Debugging and the Testing Process - как писать тестируемые программы, про статический контроль типов, правильные абстракции и инкапсуляцию, хорошие интерфейсы
5. The Scientific Method of Debugging - обсуждение научного подхода к дебагу - наблюдение, построение гипотез, проверка гипотез при помощи экспериментов, повторение этих шагов в цикле, пока не исправим проблему
6. About the Bug Patterns - расказ про важность паттернов багов, объяснение как выглядит такой антипаттерн и большой справочник по отладке программ
7. The Rogue Tile - это антипаттерн фальшивая черепица, в котором программа после исправления ведет себя так, как будто баг не был исправлен. Причина может быть в том, что проблемная логика растиражирована внутри приложения и ее нужно вынести в общее место и починить один раз там:)
8. Null Pointers Everywhere! - стандартная история с Java:)
9. The Dangling Composite - болтающийся компонент, который характерен для рекурсивно определенных типов данных, где некоторым базовым случаям не выделяются классы, а используются null pointers
10. The Null Flag - когда программа вместо выкидывания значимого исключения кидает null pointer exception.
11. The Double Descent - проблема с рекурсивным обходом составной структуры, когда мы прыгам более чем на один щаг вниз
12. The Liar View - антипаттерн "лживое представление" на случай, когда используется паттерн MVC и работа представления и модели расходится
13. Saboteur Data - история про косяки с валидацией входных данных и дальнейшим их использованием внтури приложения
14. The Broken Dispatch - косяки с полиморфизмом и перегрузкой методов
15. The Impostor Type - тип-самозванец, когда программа одинаково обрабатывает принципиально разные типы данных. Про такую проблему рассказывал Джон Остерхут в книге "A philosophy of software design" как о проблеме, которую он пытался найти полгода:)
16. The Split Cleaner - проблемы при некорректном управлении ресурсами, когда они или не освобождаются или наоборот делают это слишком рано
17. The Fictitious Implementation - проблема, когда реализация интерфейса не удовлетворяет некоторым содержащимся в нем инвариантам
18. The Orphaned Thread - проблема в многопоточном приложении, когда потоки остановились в ожидании данных от поттока, что прекратил свою работу
19. The Run-On Initialization - проблема при инициализации атрибутов класса, когда конструктор инициализировал не все из них
20. Platform-Dependent Patterns - платформо-зависимые ошибки
21. A Diagnostic Checklist - список вопросов и симптомов некорректного поведения, который можно использовать для дебага
22. Design Patterns for Debugging - паттерны проектирования, которые помогают в отладке (первый паттерн в использовании статической типизации)
23. References - ссылки на ресурсы, что были полезны 20 лет назад:)

#Software #SoftwareArchitecture #Patterns #Design #Architecture #SoftwareDevelopment #Engineering