Zen Habits

Встречайте, ещё один побочный продукт моего вайб-кодинга — Zen Habits.

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

Велком: https://zenhabits.dev/

Пожелания, критику и оскорбления жду в чатике канала 🫂

fastjsondiff - High-performance JSON comparison with a Zig-powered core

Написал небольшую библиотеку для сравнения двух JSON-текстов/файлов. В Python есть популярная либа jsondiff, но её основная проблема это сильные тормоза, если на вход подать более менее крупный JSON-текст. Давно вынашивал идею реализации чего-то такого, но на Zig/Rust, т.к. чистая реализация на Python будет всё равно медленнее. По итогу получилось реализовать на Zig основную либу и Python-интерфейс к ней.

pip install fastjsondiff-zig

Github: https://github.com/adilkhash/fastjsondiff
PyPI: https://pypi.org/project/fastjsondiff-zig/

Буду признателен за ⭐ на репе в гитхабе, это поможет её распространить дальше.

pandas 3.0

Вышла мажорная версия самой, пожалуй, популярной библиотеки для работы с данными в Python - pandas 3.0. В новом релизе появилось два значительных изменения: новый dtype для строк str вместо привычного numpy object. По словам разработчиков это значительно улучшает производительность кода. Также теперь Copy-on-Write это единственный режим для изменения значения колонок у датафрейма, более подробно здесь. Перед миграцией на новую версия pandas необходимо прошерстить легаси код и внести изменения, если вдруг в коде есть проверки на object или неоднозначные изменения датафрейма (вездесущий SettingWithCopyWarning в логах).

Ссылка на полный release notes.

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

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