Кратко - основные инсайты с круглого стола «Хадуп мертв»

1️⃣ HDFS сам по себе мало кому нужен, если есть S3.
2️⃣ Даже YARN уже не так необходим.
3️⃣ Современная BigData признана начинающейся от 10 Петабайт. Эта планка постепенно растет.
4️⃣ Приходится делать много ухищрений, чтобы получить в он-преме S3. И принимать множество компромиссов.
5️⃣ Hadoop (HDFS) - все еще хороший, надежный, понятный и предсказуемый способ получить скалированное хранилище для бигдаты
6️⃣ Но с нуля Hadoop сейчас мало кто решится разворачивать для GreenField проектов
7️⃣ Apache Ozone - перспективный способ получить S3 (+HDFS) на сегодня - признано 60% участниками дискуссии.

Печалька, но факт опровергнуть невозможно 🙃☹️

#meme #dev #ai #llm #stackoverflow #notmeme

🔥 ИИ-разработка - это уже мета-программирование

Раньше, чтобы быть сильным инженером, достаточно было знать язык, предметную область и свой проект.
Теперь к этому добавилось новое измерение - понимание самой нейросети, с которой ты работаешь.

Ты должен знать:
🧠 как она "думает"
🧩 где у неё слепые зоны
📚 какая у неё внутренняя терминология
⚙️ и как подать задачу так, чтобы она дала не просто ответ, а нужное решение.

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

Автор статьи сравнивает асинхронность и многопоточность в Python на фоне свободнопоточности (No GIL) в Python 3.13.

Выводы:
🔘 при IO‑bound до ≈1000 одновременных задач скорости близки
🔘 асинхронность выигрывает по ресурсам и масштабируемости (10k+ соединений)
🔘 с No GIL классическая многопоточность начинает догонять и местами обгонять async на смешанных нагрузках (есть заметная доля CPU)

✏️ Что важно из статьи:

⏩ Для CPU‑bound задач по‑прежнему уместен multiprocessing; для IO‑bound многопоточность и асинхронность дают схожие времена, разница - в механике переключений (OS‑scheduler vs await) и сложности разработки: асинхронный код труднее писать и отлаживать.

⏩ Async нередко маскирует пулы потоков: aiofiles внутри зовёт loop.run_in_executor, а Motor (async‑драйвер MongoDB) использует под капотом синхронный PyMongo через thread‑pool; часть Django‑стека вынужденно прыгает между sync/async, добавляя оверхед.

⏩ Микротесты ожидания: при 100–1000 задач разницы почти нет; при 10 000 - у threading "can’t start new thread". Память: ~4 МБ на поток против ~4 КБ на async‑задачу, поэтому на больших кардинальностях async существенно экономнее; у множества потоков растёт стоимость переключений и нагрузка на планировщик.

⏩ В реальных библиотеках возможен крупный выигрыш: у psycopg 3 асинхронный путь даёт ≈2200–2500 RPS против ≈700–800 RPS у синхронного.

⏩ Эксперимент с FastAPI: многопоточность с GIL - ~2800 RPS, async - ~3500 RPS. С No GIL: async остаётся примерно на том же уровне, а многопоточность поднимается до ~3540 RPS, местами обгоняя async. Итог автора: апгрейд на No GIL даёт прирост, сопоставимый с полной перепиской на async.

⚡️ Итог:

🟢 асинхронность - про экономию железа и экстремальную конкурентность (10k+)
🟢 No GIL усиливает многопоточность там, где в запросе есть заметная доля CPU (условно 20–40% и выше)
🟢При чистом IO (например, LLM‑агенты 5/95) разумнее оставаться на async; при типичных нагрузках <1000 конкурентных запросов решающей разницы нет.


Все цифры - из измерений автора статьи, на твоих задачах результаты могут отличаться.

Плюс ➕ gist

Глаз да глаз нужен за этими затейниками 🙂

😶‍🌫️ Agentic AI от Andrew Ng - как строить ИИ, который не просто отвечает, а действует: планирует шаги, вызывает инструменты и улучшает себя через рефлексию.

Что внутри:

▶️ Паттерны: Reflection, Tool Use, Planning, Multi‑Agent.
▶️ Интеграции: базы данных, API, веб‑поиск, исполнение кода, Model Context Protocol (MCP).
▶️ Практика и продакшн: evals, error analysis, оптимизация и деплой.
▶️ Капстоун: собираем Research Agent, который сам планирует ресёрч и выдаёт развёрнутый отчёт.


Формат: 5 модулей, ~6 ч, self‑paced, уровень Intermediate. По завершении - сертификат.

🔜 Курс: https://deeplearning.ai/courses/agentic-ai/

Если ты делаешь ассистентов, RAG или внутренние сервисы - этот курс закрывает "как" и "почему" агентные пайплайны реально работают.

#edu #course #ai #llm #agents

🚀 Как не сжечь Airflow при масштабировании Celery до 16 воркеров

Если ты решился расти с 1–2 нод до целого кластера - держи короткий гайд, как не утопить Redis и не ловить OOM-ы.


0⃣ Сначала делай замеры, потом крути ручки

Включи celery events и следи за:

🔘 потреблением RAM / CPU каждого воркера;
🔘 p50/p90/p99 времен выполнения задач;
🔘 latency брокера (redis-cli --latency) - держи p95 < 10–20 мс.


1️⃣ Сделай три тестовых DAG’а

Чтобы понять, где предел, сделай три типа задач:

🔘 чисто CPU (например хеширование);
🔘 I/O (сети, файлы);
🔘 смешанные.

Поднимай concurrency по шагам - смотри, где падает throughput или растёт latency.

2️⃣ Найди конкуренцию на ядро

Идеал - максимум задач без лагов и OOM.
Обычно выходит 0.5–0.7 × число ядер.

⏩ Пример: 8 vCPU 🔜 ставь concurrency ~5.


3️⃣ Посчитай ёмкость для 16 воркеров

🔘 Определи конфиг ноды: 8 vCPU, 16–32 ГБ RAM.
🔘 Дальше просто:

per_worker_conc = cores × коэффициент
cluster_conc = per_worker_conc × 16

🔘 Проверяй память:

RAM ≈ per_task_RSS × per_worker_conc × 1.3

🔘 Redis и Postgres - лучше на отдельных нодах, не внутри оркестратора.


4️⃣ Настройки Celery / Airflow

🔘 worker_concurrency = твоя формула;
🔘 worker_prefetch_multiplier = 1–2;
🔘 task_acks_late = True (если идемпотентно);
🔘 таймауты = p99 × 1.5–2;
🔘 тяжёлые DAG’и в отдельные очереди.


5️⃣ Как понять, что всё ок

🔘 Redis p95 < 20 мс;
🔘 задержка queued 🔜 running < 10 с;
🔘 RSS < 85 % лимита;
🔘 CPU БД < 70 %;
🔘 нет OOM и "heartbeat lost".


✔️ Быстрый старт

▶️ Воркеры: 8 vCPU / 16–32 ГБ RAM
▶️ Concurrency ~5
▶️ Prefetch = 1
▶️ 16 нод ➡️ ~80 одновременных тасок

#airflow #celery #redis #config #ha #cluster