Agentic Engineer

Что даёт на практике Arrow

🟢 Быстрая загрузка / выгрузка больших табличных данных — поскольку Arrow ориентирован на колоночное, бинарное хранение, это хорошо подходит для интеграций с базами и форматами вроде Parquet / Feather.

🟢 Возможность работы с данными больше RAM — благодаря памяти-маппингу и chunked-формату, реально обрабатывать большие датасеты, не загружая всё в RAM.

🟢Более стабильное — и иногда быстрее — создание pandas-объектов при использовании Arrow как промежуточного формата (например, через pyarrow 🔜 pandas) вместо прямого pd.DataFrame(...). Есть реальные бенчмарки с 20–35% ускорением в ряде случаев.

🟢Возможность построения более продвинутых вычислительных движков: с query-planning, ленивыми выражениями, многопоточностью, оптимизированной аллокацией памяти — в духе того, как устроены современные БД или big-data фреймворки. Это путь к pandas v2 / next-gen DataFrame-средам.

Apache Arrow ❓

#apache #arrow #pandas #bigdata

#friday #meme #dev

#friday #memes #work #dev

Персональное средство воздухоплавания.
Цена вопроса - $250k

#helicopter #flyscooter #wow #zapata

#dev #memes #friday

Плюсы Apache Arrow

Arrow закладывает новый memory-уровень — колонное, компактное, соседнее в памяти хранение всех значений столбца. Это даёт сразу несколько плюсов:

🟣Данные хранятся contiguously — т.е. подряд в памяти, что снижает количество промахов кэша и повышает производительность при сканировании столбцов.

🟣Поддержка null / пропусков (missing data) на уровне битовой маски: отдельная карта битов, быстрая проверка, оптимизация путей, когда null отсутствуют.

🟣Возможность мемаппинга больших датасетов — работать с таблицами, превышающими RAM, как с mmap-файлами, читать куски данных без загрузки всего.

🟣Эффективная поддержка категориальных данных (categorical / dictionary types) — не костыли, а родной тип.

🟣Более "нормальное" добавление данных / апенд — благодаря chunked/streamed колонной структуре, можно делать append без жёсткого переписывания всего столбца.

🟣Широкая типизация и возможность добавлять новые типы данных с гибким мета-описанием, расширяемое.

То есть Arrow — это фундамент, на котором можно строить более масштабируемые, быстрые и "бигдатаподобные" аналоги pandas-подходов.

Apache Arrow ❓

#apache #arrow #pandas #bigdata

Apache Arrow — это попытка решить главные внутренние проблемы pandas, связанные с производительностью, памятью и масштабируемостью. Он даёт эффективное, колонное, близкое к металлу представление данных, что открывает путь к работе с наборами, которые раньше были просто нереалистичны в pandas.

Автор статьи считает, что pandas «сдулся» для тяжёлых задач:
🔘 Когда автор начинал писать pandas в 2008, задачи были проще, рамок не было для анализа сотен гигабайт — внутренности pandas (через BlockManager, NumPy и Python-объекты) были адекватны.
🔘Современные сценарии часто подразумевают большие данные. По грубой оценке автора, чтобы безопасно работать с датасетом ~10 ГБ, нужно 64–128 ГБ RAM.
🔘Кроме того, представление строк и других типов через отдельные Python-объекты размазывает данные по куче — жёстко бьёт по памяти и скорости.

В следующих постах расскажу:
🔘Плюсы Apache Arrow
🔘Что даёт на практике
🔘Когда Arrow даёт преимущество

#apache #arrow #pandas #bigdata

#dev #meme

✨ Всё вместе: как этим реально пользоваться 🌟

Соберём картинку целиком.

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

1️⃣ Bus matrix
чтобы показывать бизнесу прогресс в их координатах: процессы × разрезы.

2️⃣Data contracts
чтобы каждая продовая таблица была продуктом с понятными ожиданиями.

3️⃣ Insert-only факты и snapshot-измерения
чтобы пайплайны были простыми, а история — честной.

4️⃣ 4 базовых DQ-паттерна
constraints, референциальная целостность, reconciliation, variance.

5️⃣ Lineage
чтобы дебаг был техзадчей, а не расследованием.

6️⃣ Централизованные метрики
чтобы в компании была одна реальность, а не десять.

Это тот редкий случай, когда набор простых практик:
🟢 снимает кучу боли у дата-инженеров
🟢 делает бизнес счастливее
🟢 помогает тебе выглядеть взрослым инженером, а не человеком, который крутит SQL по запросу

〰️〰️〰️〰️〰️〰️〰️〰️
Порядок в DWH

#dev #de #dwh

Нейродроны от neiry

🚀 Новая эра дронов — живых дронов. Neiry представила своих первых "птиц-биодронов" — реальных голубей с вживлёнными нейроинтерфейсами.

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

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

🔥 Преимущества перед обычными БПЛА: биодроны автономны — птица ведёт обычную жизнь, а электроника питается от солнечных батарей. Дальность полётов, выносливость и скрытность сильно выше.



❗️ По словам Neiry, проект уже переходит к реальным испытаниям и внедрению — возможно, подобные живые беспилотники мы увидим в деле совсем скоро.

#pigeon #drone #biodrone #bird #neiry

#dev #memes #deploy

⭐️ Единый источник правды для метрик — иначе все живут в разных реальностях

Со временем в компании становится:
🔘 всё больше метрик
🔘 всё больше команд
🔘 всё больше дашбордов, считающих "почти одно и то же, но чуть-чуть по-другому"

Без единого источника правды ты получаешь войну дашбордов: у маркетинга один LTV, у продукта другой, у финансов третий.

Критически важно держаться одной из двух стратегий (или гибрида):

1️⃣ Semantic layer
🟢 отдельный слой, где объявляются метрики: как считать, из чего, какие фильтры
🟢 все системы (BI, отчёты, сервисы) бьют запросами в этот слой и получают одно и то же определение.

2️⃣ Data mart с метриками
🟢 заранее считаем метрики в витринах
🟢 BI только читает уже готовые значения

Общее правило:
🟣 у каждой метрики должен быть owner
🟣 определения метрик должны жить в одном месте
🟣 чем более метрики размазаны по командам, тем тяжелее их дебажить и согласовывать.

〰️〰️〰️〰️〰️〰️〰️〰️
Порядок в DWH

#dev #de #dwh

#dev #meme

▶️ Линейность (lineage) — без неё любой дебаг превращается в детективное расследование

Баг в отчёте — классика. Вопросы всегда одни и те же:
🔘 откуда вообще взялись эти цифры?
🔘 какой слой сломался — сырые данные, стейджинг, витрина?
🔘 где конкретно в цепочке логика пошла не туда?

Без data lineage всё это — ручной форензик в стиле "гуляем по кодовой базе и гадаем".

Что даёт нормальная линейность:

1️⃣ Быстрый ответ на вопрос "из каких таблиц и трансформаций родилась эта витрина?".

2️⃣ Возможность пройти путь: отчёт 🔜 витрина ➡️ факт/измерения 🔜 стейджинг 🔜 сырые данные.

3️⃣ В регуляторных областях (финансы, медицина) — это вообще must-have для аудита.

Многие современные тулзы уже умеют в lineage из коробки (dbt, SQLMesh и не только).

Но главный пойнт такой:

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

〰️〰️〰️〰️〰️〰️〰️〰️
Порядок в DWH

#dev #de #dwh

#dev #meme #floppy #fdd

🙂 4 проверки данных, которые дают 80% пользы

Если ты когда-либо видел, как неверные цифры попадают в отчёт к C-level — ты понимаешь, какой это треш. Доверие ломается мгновенно.

Важно фокусироваться на 4 типах DQ-проверок с максимальным ROI:

1️⃣ Table constraints
🔘 уникальность (id уникален)
🔘 not null там, где бизнес-логика не допускает пропусков
🔘 допустимые значения (enums, статусы, типы событий)

2️⃣ Referential integrity
🔘 каждый ключ измерения в факте должен существовать в соответствующем dimension
🔘 иначе join выкинет часть строк, и цифры поедут.

3️⃣ Reconciliation checks
🔘 сравниваем количество строк и ключевые агрегаты (выручка, количество заказов) между источником и витриной
🔘 допускаем небольшой дельта-порог, но не бесконечный

4️⃣ Metric variance
🔘 отслеживаем, насколько текущий запуск отличается от исторического диапазона
🔘 если привычно имеем +2–3%, а тут внезапно –40% — пора останавливать пайплайн.

📌 Фишка:
лучше иметь эти 4 хороших типа проверок, чем 40 рандомных, которые никто не смотрит.

Отдельно рекомендую использовать WAP-паттерн (write-audit-publish): сначала загрузили и проверили данные, потом только опубликовали конечную таблицу потребителям.

〰️〰️〰️〰️〰️〰️〰️〰️
Порядок в DWH

#dev #de #dwh

... а потом играют в баскетбол 🏀

#ai #robotics #robot #humanoid #ии #робототехника #робот #гуманоид #basketball #nba #баскетбол

Про разработку и AI-специалистов.

Дядя открывает рубрику #холиварвыходногодня. На рынке найма сталкиваюсь с заблуждением, что MCP должны создавать MLE или DS спецы. На самом деле, это придумано на замену API, для более нативной интеграции LLM и агентов с сервисами, т.к. обычные стандартные API для этого не подходят AS IS. А их доработки всеравно приведут вас к MCP-like. И делать это должны не ML-only спецы, а бэкендр разработчики, пусть и совместно с MLE, но при необходимости. При этом же я вижу кругом евангелистов агентов, которые вчерашние swe и другие представители разработки, и это, на мой взгляд, не с проста.

Действительно агентные системы это прикладной инструмент, который использует апи и AI-технологии вокруг, без необходимости знать детали работы LLM под капотом. Надо разделять разработку core технологий которые ложатся в основу agents и сами конструкторы агентных систем, для создания которых с уже готовыми блоками в виде библиотек, MCP, LLM ds/MLE уже не нужны. Свою работу они сделали, дали то, на чем это строится в лице моделей.

Моя позиция в том, что MCP и агентные системы, как прикладные решения, удел вчерашних разработчиков, когда как технологии (модели, алгоритмы консенсуса и др) в основании этого под капотом, удел ML/DL спецов. Причём, обратите внимание, как агентные системы нативны с тч зрения алгоритмики и архитектуры построения, что делает их проектирование разрабами более удобным и нативным для этих спецов.

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

А что думаете вы? Пишите в комментариях. 👇👇👇👇

Ловкие китайские гуманоиды.

#ai #robotics #robot #humanoid #ии #робототехника #робот #гуманоид