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

Why Most Data Projects Fail and How to Avoid It • Jesse Anderson • YOW! 2022

Интересное выступление про data проекты от Jesse Anderson, автора книги "Data Teams". Автор говорит о ключевых вопросах, которые стоит задать при старте проектов
- Who - Автор говорит про правильный состав команды для data проектов. Собственно автор про это написал целую книгу и он говорит про баланс data scientists, data engineers, operations.
- What - Автор задает вопрос про бизнес значение того data продукта/проекта, которым вы занимаетесь. Автор говорит о том, что фразы "Мы делаем AI" от CEO не хватает для data strategy:) В общем, надо понимать как ваш проект принесет ценность для бизнеса. Причем помимо стратегии нужен план и его execution. Особенно во времена, когда tech компании занимаются сокращениями в направлениях, что не приносят деньги.
- When - Автор говорит о том, а когда эта бизнес ценность будет создана. Нужен проект с понятными временными границами, чтобы он не был слишокм долгим, чтобы быть отмененным где-то посердине и не слишком коротким, обещающим золотые горы, которым на самом деле будет невозможно соответствовать.
- Where - И вот мы наконец-то добрались до первого технического вопроса, а где собственно эти данные будут обрабатываться, как будет выглядеть архитектура решения. И тут для ответа тоже не хватает фразу "Мы будем использовать технологию XYZ вендора ABC". Проблема в том, что вендор может пообещать все что угодно, но это обещание не факт, что выполнимо, более того, не факт, что оно оптимально для заказчика:)
- How - Здесь речь идет про план выполнения и про фокусировку на приоритетных направлениях. Хотя часто такие data проекты пытаются успеть сразу везде, а дальше теряют эффективность на context switches и застывают на месте, переставая генерировать какую-либо ценность кроме рассказов о наступлении AI:) Автор интересно рассказывает про то, как бизнес заказчикам перпендикулярно на конкретные технические решения, но важно какую бизнес-ценность они могут получить по результатам выполнения плана.
- Why - Автор задает вопрос, а почему же эти данные обладают ценностью? Просто отгружать данные и гонять ETL/ELT пайпланы не достаточно. Важно понимать как использование данных в новых проектах позволит обеспечить нужный ROI (return on investments), причем автор говорит о том, что он ищет 10x ROI для data проектов

Напоследок автор говорит о том, что для AI и data проектов важно понимать, что такие проекты сложны и требуют навыков, людей и организационных изменений для своего успеха. И это достаточно сложно и не все способны приносить пользу в таких проектах. Конкретно, автор рассказывает про то, что если запускать data и AI проекты внутри DWH команд, то такие проекты обречены на неудачу ("the team where good data projects go to die). Это обусловлено не тем, что DWH технологии плохие, а потому, что это скорее проблема людей ("people problem"), которые очень специфично разбираются с проблемами и очень специфичным образом выстраивают свою работу. В общем, автор говорит о том, что эта не та команда, которая должна отвечать за data и AI проекты нового типа.

В конце автор рассказывает о том, как можно получить помощь с такими проектами за счет аутсорсинга (если у компании нет своей инженерной команды и культуры), за счет привлечения консультантов (правда, автор говорит о том, что консультанты по менеджменту типа BCG, Bain, Mckinsey зачастую не обладают компетенциями для помощи в таких data проектах). В конце автор упоминает свою книгу "Data teams", которую он написал для менеджеров, которым предстоит запускать data и AI проекты.

P.S.
Мне автор продал свою книгу, поэтому я добавлю ее в свой long list на чтение:)

#Management #Leadership #Data #DataScience #AI #Engineering #Software #SoftwareDevelopment #ML

AI-помощники при работе с кодом. Взгляд в будущее - Евгений Колесников - Platform Engineering Night (Рубрика #AI)

Крутое выступление Евгения из команды Yandex Infrastructure, в котором он делится глубокими мыслями про развитие AI copilot инструментами. Женя выступал с этим докладом на Platform Engineering Night в Т-Банке. Я уже рассказывал про выступления моих коллег оттуда: "AI и Platform Engineering" от Игоря Маслова и "Разработка собственного AI-ассистента для кода: спринт или марафон?" Дениса Артюшина. Ребята рассказывали про наши подходы к интеграции AI в SDLC) и интересно сравнить мысли из тех докладов с идеями Жени, что я постарался изложить ниже

1. Реальность разработки
По стате разработчики пишут код всего 40 минут - 120 минут в день, при этом комитят в среднем только 40 строк кода в день. Основная проблема не в скорости печати, а в сложности мыслительных процессов, что идут на трех уровнях
- Ментальная модель - что мы хотим сделать
- Семантическая модель - как мы это будем делать
- Синтаксическая модель - непосредственно сам код
ИИ сейчас помогает в основном на последнем этапе, что объясняет ограниченность эффекта.
2. Режимы работы разработчиков
Существуют два основных режима:
- Flow - сотояние потока, когда код "летит из-под пальцев". Интересно, что в DevEx фреймворке Flow - это одна из составлящих, кстати, я делал обзор whitepaper о нем
- Exploration - поиск информации в документации, интернете, общение с ИИ
Понимание этих режимов критично для эффективного использования ИИ-инструментов.
3. Чего хотят разработчики от ИИ
По мнению Евгения ожидания инженеров такие
- Переложить на AI рутинные операции, например, написание юнит-тестов
- Общаться на естественном языке с последующим уточнением через промпты
- Получить детерминированные результаты от недетерминированного genAI
Интересно, что у Google был whitepaper буквально с таким названием "What Do Developers Want From AI?" - я его разбирал раньше, а потом еще записал эпизод подкаста "Research Insights" вместе с моим коллегой, Колей Бушковым, где мы разбирали этот whitepaper
4. Бизнес-приоритеты
Бизнес хочет сокращения time to market, снижения издержек, а также предсказуемости. Но обычно все упирают на сокращение издержек, когда говорят, что "90% кода будет писаться ИИ". Но часто это не означает увольнение 90% программистов, а увеличение продуктивности существующих команд. Евгений привел пример Дарио Амодея с его тезисами из цитаты выше - а я разбирал это выступление раньше
5. Проблема измерения эффективности
Критически относитесь к цифрам вроде "повышение продуктивности на 55%". Продуктивность - неопределенный термин, зависящий от множества факторов. Пока нет единого способа точно измерить пользу от ИИ-инструментов. Интересно, что я уже пару раз выступал с темой навроде "Зачем заниматься темой developer productivity в большой компании"
6. LLM ≠ Продукт
Использование последней языковой модели не гарантирует успех продукта. UX/UI, правильный промптинг и интеграция в рабочий процесс часто важнее, чем выбор конкретной модели.
7. Правильные метрики
Стоит измерять NPS, CSAT в связке с retention (у SourceCraft от Yandex между 60-70%), cycle time, lead time и влияние на бизнес-метрики. Метрика счастья пользователя - интегральный показатель принятия/отклонения подсказок.
8. Снижение хайпа - это хорошо
За 2023-2024 год интерес к ИИ в некоторых областях упал и это хорошо - разработчики начинают реалистично оценивать возможности и ограничения ИИ-инструментов, что ведет к более эффективному использованию.
9. Будущее: от генерации к агентам
Развитие сейчас идет от генеративных моделей к агентским. Агенты проактивно решают задачи, но пока крайне ненадежны. Следующий этап развития - сделать агентов более надежными и предсказуемыми. Чем глубже интеграция ИИ в инфраструктуру компании, тем больше выигрыш.

Если подводить итоги, то Евгений считает, что AI-помощники однозначно полезны, но важно понимать их ограничения и правильно интегрировать в рабочий процесс, а не гнаться за хайпом.

#AI #Software #Engineering #Architecture #Agents

Краткий обзор платформы данных Т-Банка (Рубрика #Data)

Прочитал интересную статью от коллег про про нашу data platform. Если обобщать достаточно длинную статью, то можно отметить, что платформа данных Т-Банка эволюционировала более 18 лет, следуя общеотраслевым трендам. Компания постепенно отходила от классических концепций хранилищ данных по Инмону и Кимбеллу в сторону Data Lake, а затем — к современным Lakehouse-архитектурам. Платформа сейчас обслуживает более 17 тысяч пользователей и обрабатывает свыше 144 млн запросов в месяц, что требует постоянного развития масштабируемости и производительности. Текущая архитектура включает 19 ключевых систем, которые обеспечивают полный жизненный цикл работы с данными — от сбора до визуализации и обеспечения безопасности. Вот как они сгруппированны

1. Сбор и транспортировка данных
- Data Replication: BODS (legacy) и Chrono для пакетной и потоковой репликации
- Event Sourcing: SDP (Streaming Data Transfer Platform) на основе принципов Data Mesh
- Reverse ETL: Spheradian для возврата данных в операционные системы с латентностью до 100 мс
2. Хранение данных
- Data Warehouse: GreenPlum как основная СУБД (15 кластеров, 1,7 ПБ данных)
- LakeHouse: Spark/Trino + S3 с несколькими вычислительными движками
- Real-Time Analytics: ClickHouse для быстрой аналитики на больших таблицах
3. Обработка и трансформация
- Streaming Processing: Unicorn (на Apache Flink) и NiFi
- Workflow Management: TEDI (на Apache Airflow) и Moebius для оркестрации
- Analytics Tools: Proteus (на Apache Superset) для дашбордов и Helicopter для совместной работы
4. Управление данными
- Data Discovery: Data Detective для поиска и каталогизации
- Data Governance: Data Contracts для управления поставками данных
- Data Observability: DQ Tools для контроля качества и Data Incident Management
- Data Security: SLH для управления доступом к чувствительным данным

Если хочется узнать больше, то можно почитать статью и позадавать вопросы в комментариях.

#Data #Database #Architecture #Software #Engineering #PlatformEngineering