📣 📢 13 ИИ агентов для дата инженера

Ребята из Astronomer выложили 13 полезных ИИ агентов для дата инженера. В списке есть имба-агент, помогающий мигрировать Airflow 2 на Airflow 3 — migrating-airflow-2-to-3
Преимущественно агенты сконцентрированы вокруг написания и тестирования Airflow DAGs, проектирования таблиц БД, data lineage. Боевой комплект дата инженера.

Из БД они умеют в Snowflake, Postgres, BigQuery. Также есть навык для работы с SQLAlchemy ORM.

Установка агентов:

npx skills add astronomer/agents

Для Claude Code можно установить прямо их маркетплейса

claude plugin marketplace add astronomer/agents
claude plugin install data@astronomer 

В комплекте есть Airflow MCP сервер.

Ссылка на репозиторий: astronomer/agents

Data Pipelines with Apache Airflow, 2-е издание

Ребята из Astronomer совершенно бесплатно раздают электронную книгу Data Pipelines with Apache Airflow®, Second Edition, by Manning. Это обновлённое издание с учётом новой 3-й ветки Airflow, в книге используется версия Apache Airflow 3.1.0. Ну и конечно же ИИ не обделили, в книге появился контент про RAG, AI Orchestration и т.д.

Приятного чтения, господа! 🤓

🔥 Девушка без навыков разработки запустила AI-бота и вышла на первые продажи за месяц

Аня из комьюнити @its_capitan заметила: люди учат английский годами, но говорить не могут. И тогда она сделала Telegram-бота, который общается с тобой голосовыми на английском и исправляет ошибки как живой собеседник.

Что в итоге:
— ~700 пользователей за первый месяц
— первые 16 оплат
— первая выручка: ~$200
— подписка: $8/мес
— сделано на n8n + OpenAI без разработчиков

Не было ни команды, ни инвестиций, ни кода.

Главное — не технология.
Главное — простая понятная ценность.

Таких запусков в канале уже десятки. Показываем честно: цифры, провалы, рост и продвижение. Без теорий. Только реальные метрики и запуск в реальном времени.

👉 @its_capitan

Подписывайтесь, если интересно, как делать маленькие IT-проекты с доходом и без иллюзий.

Второе издание "кабанчика"

На днях увидел в сети анонс, что вышло новое издание легендарной книги Designing Data-Intensive Applications.

Впервые я познакомился с этой книгой где-то весной или летом 2018 года. Помню как случайно нашел её в архивах какого-то репозитория на Гитхабе. И сказать, что она мне понравилась это ничего не сказать. Я был в восторге от неё, она стала для меня учебником которого мне не хватало. Помню, что до середины я прочитал её на стареньком планшете. Глаза мои уставали, и я решил заказать её в бумажном вариант.

“Кабанчик” до сих пор у меня, пережил несколько переездов и выглядит непрезентабельно. Но к чему этот пост? Я хочу немного изменить формат этого канала и сделать фокус на авторском контенте: больше личного опыта, мыслей и заметок. И первым таким экспериментом будет серия постов по новому изданию книги Designing Data-Intensive Applications. По мере чтения книги я буду разбирать каждую главу или раздел (если главы будет недостаточно для хорошей заметки) и делать свои “зарисовки”, в комментариях будем дискутировать по темам.

Что скажете? Накидайте реакций 👍🔥, чтобы я видел обратную связь от вас.

Designing Data-Intensive Applications

Глава 1. Trade-Offs in Data Systems Architecture

Введение

Первая глава книги получилась объёмной как по количеству страниц так и по количеству информации. По сравнению с первым изданием появилось упоминание Single-Node Data Warehouse решений на примере DuckDB, SQLite, но без деталей. Детали будут раскрываться уже в более поздних главах.

Основная мысль первой главы дать читателю понимание, что нет “серебряной пули”, и в каждом решении существуют как свои плюсы так и минусы (trade offs). Посыл авторов благородный, помочь читателю разобраться в море различных технологических решений. Дать фундамент, который будет помогать принимать правильные решения при проектировании архитектуры будущих приложений.

Что изменилось по сравнению с первым изданием? Первое издание книги вышло в 2017 году, с тех пор прошло 9 лет. Мир не стоит на месте, технологии развиваются. По словам авторов, в новом издании они постарались уделить достаточно внимания технологиям вокруг ИИ инфраструктуры, cloud native решениям на базе хранилищ объектов по типу Amazon S3, полностью переписали главу про Batch Processing из-за неактуальности MapReduce в наше время (при проектировании новых архитектур).

Конспект

Приложение считается Data-Intensive, если управление данными это одна из его ключевых задач.

Основные вызовы у таких приложений

— эффективная обработка и хранение большого массива данных
— обеспечение доступности данных в условиях отказа частей системы
— обеспечение согласованности данных (data consistency)

Главные строительные блоки

— Базы данных для хранения информации (например, PostgreSQL, MySQL, Microsoft SQL Server и т.д.)
— Кэш-системы для обеспечения быстрого доступа к данным (например, Redis, memcached)
— Поисковые движки для обеспечения быстрого поиска в большом массиве данных (Elasticsearch, Sphinx)
— Системы для потоковой обработки данных (Apache Flink, Apache Storm)
— Системы для пакетной обработки данных (Apache Hadoop, Apache Spark)

Примеры конкретных инструментов это моё личное дополнение, их множество, здесь приведены лишь наиболее популярные и те, что у меня на слуху. От себя я бы ещё добавил, что рука об руку с обработкой данных идут и различные оркестраторы и workflow-менеджеры по типу Apache Airflow, Oozie, Luigi, NiFi, Prefect, Dagster и т.д.

Типы баз данных

— Транзакционные (OLTP), авторы в книге также называют их операционными
— Аналитические (OLAP)

Транзакционные базы используются там, где данные берут своё начало, а именно базы для бэкенда приложения с которым пользователи взаимодействуют через фронтенд (веб-приложения, мобильные приложения и т.д.). Транзакционным базам присущи точечные запросы на чтение, запись, обновление или удаление. Например, по user_id. Запросы преимущественно формируются на стороне приложение, пользователь напрямую не имеет доступа к базе и не пишет запрос. Примеры: PostgreSQL, MySQL, Oracle DB, Microsoft SQL Server.

Аналитические базы данных используются для работы с данными для принятия решений на стороне бизнеса. Такие базы хранят в себе данные, собранные в том числе из транзакционных баз. Пользователями таких баз в основном являются бизнес и дата аналитики, Data Science специалисты. Зачастую они напрямую посылают запросы к базе, используя SQL. Запросы чаще всего большие и подразумевают обработку огромного набора данных (большие выборки). Примеры: Amazon Redshift, ClickHouse, Apache Druid, Pinot.

Современный подход к организации данных подразумевает четкое разделение между OLTP и OLAP. Но до массового внедрения OLAP транзакционные базы данных использовались и в качестве хранилища аналитических данных. Были придуманы способы моделирования аналитических данных с учётом ограничений реляционной модели, например, Star Schema, Snowflake Schema. В условиях современных OLAP баз данных такие подходы устарели.

Связь между OLTP и OLAP

Аналитические базы выступают в роли общего хранилища, куда стекаются данные из различных подсистем. Это могут быть OLTP базы, а также внешние сервисы (данные из которых можно тянуть по API, например). Процесс насыщения данными обозначают аббревиатурой ETL - Extract Transform Load. Но существует и другая аббревиатура ELT - Extract Load Transform. В первом случае трансформация данных происходит до загрузки в главное хранилище, а во втором уже на стороне хранилища (хранение в “сыром” виде).

Также есть процесс reverse ETL, это обратный процесс, когда данные из аналитической базы попадают в транзакционное хранилище. Например, такое практикуется при построении моделей машинного обучения и деплоя их в продакшн.

HTAP

Существуют и гибридные базы данных HTAP - Hybrid Transactional/Analytical Processing. Они сочетают в себе сразу 2 типа системы: транзакционное и аналитическое хранилище. Мотив простой: объединить всё в одну систему и исключить промежуточные процессы по загрузке данных из других систем. Я накопал пример такой БД: TiDB от PingCap. Не думаю, что основная цель таких БД заменить главное аналитическое хранилище, скорее решить специфическую задачу, где критически важно быстро обрабатывать операционные и аналитические запросы сразу без промежуточных этапов.

Data Lakes

Хранилище неструктурированных данных. Если OLTP и OLAP предъявляют требования по организации и хранению данных, то Data Lakes это своего рода помойка, где данные могут лежать в любом формате и виде: текстовые файлы, бинарные данные, данные в форматах по типу Parquet или Avro.

Данные и законодательство

С развитием GDPR, CCPA, ,EU AI Act и прочих законодательных норм и правил по персональным данным появилась необходимость учитывать риск хранения и обработки этих данных. В какой-то момент хранимые на серверах данные превратились не в актив компании, а в обязательства. Штрафы за утечку и раскрытие персональных данных или несоблюдение законодательных норм огромные, и компании должны учитывать риск. Порой безопаснее не хранить данные, которые могут понадобиться когда-нибудь в будущем, а сразу их удалять.

Cloud vs Self-Hosted

Вечная дилемма что выбрать: использовать облачные сервисы или всё развернуть на своих серверах. Это снова вопрос компромиссов. У каждого подхода есть свои плюсы и минусы. Можно комбинировать два подхода и не уходить в крайности. Например, использовать виртуальную машину на AWS на которой хостить базу данных вместо использования managed-решения. Например, self-hosted PostgreSQL вместо Amazon RDS.

Облачные сервисы избавляют команду от операционного управления, например, не нужно самостоятельно следить за обновлениями, патчами безопасности или высокой доступностью тех или иных сервисов. Порой вам даже не нужно думать о масштабировании, за вас это делает облачный провайдер. Взамен вы платите более высокую цену, получаете менее гибкий сервис и возможный vendor lock. Например, управляемый Apache Airflow от AWS это черный ящик и если что-то идёт не так, то сложно понять причину, необходимо тратить время на общение со службой поддержки, которая больше напоминает бездушных роботов. Также существуют облачные решения, которые невозможно развернуть самостоятельно, например Amazon Redshift. Если вы строите свой Data Warehouse на базе Redshift, то получаете vendor lock.

Self-hosted решения зачастую гибче и дешевле, но приходится нести бремя обслуживания. Порой специалисты, способные качественно обслуживать self-hosted сервисы стоят дороже чем их обслуживание в облаках. Но всегда необходимо оценивать как краткосрочные планы так и долгосрочное видение. В моменте self-hosted подход может быть дороже, но в долгосрочном плане выгоднее. Также могут существовать административные ограничения, которые не позволяют использовать облака. Например, требование к хранению персональных данных на территории конкретного государства.

Распределённые системы

Приложение в обслуживание которого задействованы 2 и более машины является распределённым. В текущих реалиях распределённые системы это обыденность:

— Данные на 1 машину уже не помещаются, их нужно размазать на несколько (Data Sharding)
— Нагрузка на приложение растёт и его необходимо масштабировать и обеспечивать высокую доступность (Fault-tolerance, high-availability)
— Обслуживание с минимальными задержками (Latency)
— Соответствие законодательным нормам, когда данные пользователей хранятся в соответствующем регионе или стране (Legal compliance)

Проблемы распределённых систем

— Взаимодействие между машинами происходит по сети и в любой момент может быть обрыв связи
— Задержки в передаче данных, даже несмотря на то, что 2 машины могут быть в одном дата-центре, передача данных между ними всё равно будет медленнее нежели если бы данные были лишь на одной
— Отладка проблем в распределённой среде сложнее, для этого придуманы инструменты Observability (сбор логов и метрик по работе систем)

Микросервисы и Serverless

Микросервисы реализуют идею decoupling для команд разработки. Группа людей может заниматься конкретным сервисом и использовать технологический стек по своему усмотрению. Сервис в этом случае является изолированным юнитом одной большой системы. Но всё не так прекрасно как на бумаге. У микросервисов есть множество подводных камней:

— Сложности взаимодействия между системами (транзакции, согласованность данных)
— Зоопарк технологий
— Общее усложнение системы (мониторинг, тестирование, деплой)

Если нет острой необходимости внедрять микросервисную архитектуру, то делать этого не стоит. Они могут быть неплохим решениям для большой организации, но в небольших компаниях лучше идти по более простому пути (монолит).

Serverless

Ещё один архитектурный подход при котором разработчики оперируют функциями и не думают об инфраструктуре на которой запускается их код (Function as a Service, FaaS). Примеры: Amazon Lambda, Google Cloud Functions. Удобно использовать там, где нагрузка варьируется потому что при резком росте FaaS дают гибкость и легко масштабируются. Но работа с функциями порой требует пересмотра привычного подхода к разработке приложений, и на мой взгляд, сильно привязывает к конкретному провайдеру облачных технологий.

Mastering PostgreSQL

Supabase и Manning Publications выпустили бесплатную книгу про PostgreSQL.

107 страниц концентрированной информации про самые популярные темы этой замечательной базы данных. Например, я не знал про существование отдельного типа данных для хранения денег — MONEY. Как то так получилось, что не попадался он мне на глаза.

Книга поделена на 4 части:

— Modern SQL
— Postgres for Full-Text Search (FTS)
— Improper Data Type Usage
— Table & Index Mistakes

Скачать книгу можно в комментариях к посту.

Ребят, всем привет!

Я не забыл про книгу, скоро будет конспект по второй главе (был перерыв). А пока я пишу конспект, то предлагаю вам насладиться подкастом с автором книги Designing Data-Intensive Applications Martin Kleppmann у Gergely Orosz — Designing Data-intensive Applications with Martin Kleppmann

Designing Data-Intensive Applications

Глава 2. Defining Nonfunctional Requirements

Вторая глава книги посвящена нефункциональным требованиям к разрабатываемым нами системам. Под нефункциональными требованиями автор подразумевает:

- Производительность (Performance)
- Надёжность (Reliability) и отказоустойчивость (Fault Tolerance)
- Масштабирование (Scalability)
- Поддержка (Maintainability)

Система может быть полностью корректна с точки зрения функциональных (т.н. бизнес) требований, но неудобна в использования из-за проблем с надёжностью (потеря данных), производительностью (частые “зависания” из-за нагрузки). Поэтому нефункциональным требованиям также необходимо уделять внимание.

Мартин во второй главе книги разбирает пример ленты из соцсети. Как корректная с т.з. функционала фича может быть абсолютно неюзабельна с точки зрения производительности при росте числа пользователей и постов.

Производительность
Производительность определяется двумя метриками:

1. Время ответа
2. Пропускная способность

Время ответа (response time) — время, затраченное с момента начала запроса до момента получения ответа от системы. Обычно измеряется в секундах, миллисекундах или микросекундах. Чем этот показатель ниже тем производительность выше. Но на него могут влиять факторы не зависящие от самой системы напрямую (например, скорость клиента).

Пропускная способность (throughput) — максимальное количество запросов или единиц (МБ, ГБ, ТБ) данных в секунду, которое система способна обработать. Чем выше показатель тем производительность системы лучше.

С точки зрения конечного пользователя лучшая метрика это время ответа от системы. Именно она влияет на положительный опыт взаимодействия с ней. Пропускная способность системы же определяет возможности вычислительных ресурсов системы (железа, производительности кода).

Есть ещё одна метрика, которую часто путают с временем ответа это задержка (latency). Автор пишет, что эти два термина зачастую используют как взаимозаменяющие, но на практике задержка означает время, необходимое для доставки сетевых пакетов до пункта назначения и обратно (после обработки запроса). То есть, время ответа уже включает в себя время задержки, т.е. response time > latency практически всегда.

Для измерения производительности используется базовая статистика, а именно:

- Арифметическое среднее (Mean)
- Медиана (Median)
- Процентиль (Percentile)

Использовать арифметическое среднее для измерения времени ответа некорректно (но применимо для измерения пропускной способности). Оно не даёт объективной картины, т.к. сильно подвержено влиянию выбросов (outliers). Лучше всего подходит процентиль. Медиана, например, является 50-м процентилем (p50). Если, например, медиана времени ответа 200мс, то это значит что 50% пользователей получили ответа до 200мс, а остальные 50% от 200мс и выше. Лучше всего использовать p90, p95, p99.

Надежность
Надёжная система подразумевает что:

- Она соответствует ожиданиям пользователя (функциональным)
- Корректно обрабатывает ошибки от пользователя (некорректный ввод, нестандартное поведение)
- Производительность соответствует ожиданиям пользователя
- Защищает от несанкционированного доступа к личным данным

Отказоустойчивая система подразумевает, что в случае выхода из строя части системы она продолжает свою работу. Например, отказ работы одного из жестких дисков или физической машины не должен повлиять на работоспособность приложения. Для проектирования отказоустойчивых систем практикуют т.н. Chaos Engineering. Это инженерная дисциплина, направленная на проверку надёжности распределенных систем через регулярное внедрение преднамеренных сбоев (увеличение сетевых задержек, отключение серверов и т.д.)

Отказоустойчивость железа достигается через добавление избыточных компонентов, например, в системе может быть несколько жестких дисков, подключенных в режиме RAID-массива. В случае распределённых систем, запросы могут был равномерно распределены между несколькими независимыми машинами внутри дата-центра. Случается и так, что требуется отказоустойчивость на уровне дата-центра, тогда машины распределяют по нескольким физически независимым точкам (например, разные регионы AWS). Важно придерживаться здравого смысла и понимать какого уровня отказоустойчивости вам будет достаточно.

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

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

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

Улучшить масштабируемость можно несколькими способами:
- Добавлением новых ресурсов (улучшение памяти, дисков, CPU), вертикальное масштабирование (vertical scaling)
- Добавлением новых машин, горизонтальное масштабирование (horizontal scaling)

Автор подход с горизонтальным масштабированием разбивает на два:

1. Shared-Disk Architecture
2. Shared-Nothing Architecture

Первый тип подразумевает отдельные машины, но все они делят между собой единый диск (например, NAS), куда пишут или откуда читают данные. Второй тип пропагандирует отсутствие общих ресурсов, а значит независимость при работе. В случае с первым типом у кластера есть бутылочное горлышко в виде общего сетевого диска. Второй подход подразумеваем более сложную организацию работы с данными (партицирование, шардирование).

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

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

Чтобы снизить тяжесть бремени поддержки стоит придерживаться нескольких принципов:

- Работоспособность (Operability)
- Простота или управляемая сложность (Simplicity)
- Расширяемость или жизнестойкость (Evolvability)

Работоспособность
- Автоматизация рутинных задач (например, CI/CD, внедрение DevOps практик)
- Автоматический сбор и анализ состояния работы систем и подсистем (Observability & Monitoring)
- Актуальная документация и база знаний
- Внедрение практики дежурства и postmortems, SRE-практик

Простота или управляемая сложность
Авторы книги сложность системы делят на два типа:

1. Необходимая (Essential), она появляется из сложности самой доменной области приложения при проектировании
2. Случайная (Accidental), такой тип сложности уже возникает из-за ошибок в проектировании, организации кода, компромиссов при выборе технологий

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

Расширяемость
Требования к работе приложений меняются, а значит и оно само должно меняться. Чтобы внесение изменений не превратились в страшный сон необходимо постоянно пересматривать организацию кода, закрывать технический долг, внедрять непрерывное тестирование через практики TDD, XP. Чем проще вносить изменения в систему тем выше её расширяемость и тем ниже связность между её частями.