🤖 XPeng показала IRON - самый человечный робот года

На AI Day в Гуанчжоу IRON вышел на сцену, прошёл "кошачьим шагом" и жестами как человек. Зрители решили, что это костюм - поэтому Хэ Сяопэн прямо на сцене "распаковал" робота, показав skелет и "мышцы".

Что интересно:
⏩1:1 габариты человека: 178 см, 70 кг
⏩22 DOF в каждой руке, до 82 DOF по телу
⏩Три чипа Turing, до 3 000 TOPS (по данным XPeng)
⏩Полноразмерная мягкая "кожа" и бионные "мышцы"
⏩Впервые для класса - твердотельная батарея
⏩Цель - коммерция и масштабирование в 2026

Применение: витрины/гиды в ритейле и промышленные инспекции (партнёрство с China Baowu уже в работе).

📹 Смотри на видео как доказывали, что это не человек.

#XPeng #IRON #роботы #гуманоид #AI #humanoid #robotics

🖼️ Релиз Apache Airflow CTL 0.1.0

airflowctl - новый официальный CLI, который разговаривает с Airflow Public API и даёт удобные команды для повседневных задач:
🔘триггерить DAG-и
🔘листать и проверять DagRun-ы
🔘паузить/анпаузить
🔘управлять connections/variables

Всё это удалённо, из CI/CD или локально, без SSH на кластеры.

Зачем это нужно:
🔘централизованный доступ к продам и стейджам через API
🔘единый инструмент для SRE/Platfоrm/DE‑команд и пайплайнов
🔘безопаснее: используем API‑токен, который хранится в keyring.

Пример - поставить и дернуть DAG удалённо:

# установка
pip install apache-airflow-ctl

# логин (через токен; API должен быть включён)
export AIRFLOW_CLI_TOKEN=<api_token>
airflowctl auth login --api-url https://airflow.example.com --env prod

# посмотреть доступные DAG-и
airflowctl dags list -o table

# триггернуть DAG с конфигом и заметкой
airflowctl dags trigger \
  --dag-id example_etl \
  --conf '{"country":"RU"}' \
  --note "triggered from airflowctl"

# проверить последние запуски
airflowctl dagrun list --dag-id example_etl --limit 5 -o table

Подробнее в доке.


#airflow #release #airflowctl

Субагенты и мультиагенты, в чём разница.

Субагенты - это внутренние помощники одной модели. Мультиагенты - это полноценная экосистема отдельных моделей, взаимодействующих друг с другом.

Субагенты - это когда одна большая модель разбивает работу на своих "внутренних специалистов". Как мини-команда в голове одного ИИ: каждый субагент отвечает за кусок задачи, а итог собирает сама модель.

Мультиагенты - это уже реальная команда из разных моделей/агентов, у каждого свои цели, навыки и автономия. Они общаются, координируются и делают то, что одной модели сложно: планирование, распределение ролей, параллельные процессы.

Проще:
Субагенты 🔜 внутренние роли одной модели.
Мультиагенты 🔜 самостоятельные игроки, работающие вместе.

#agents #subagents #multiagents #AI #LLM #агенты #субагенты #мультиагенты #ИИ #БЯМ

🖼️ Выкатили Airflow 3.1.3

TL;DR: 3.1.3 — это security+stability апдейт: безопаснее API‑сервер, корректная работа Connections/Variables в контекстах сервера, рывок по скорости UI/API и пачка важных фиксов планировщика и миграций. Обновляться стоит.

Главное в 3.1.3:

▶️Security: удалён небезопасный endpoint /api/v2/dagReports, который исполнял пользовательский код в процессе API‑сервера. Рекомендация — использовать airflow dags report.

▶️Секреты и контексты: исправлен доступ к Connections/Variables в контекстах API‑сервера (плагины, лог‑хендлеры) за счёт явного разграничения цепочек секретов для client/server/fallback. Плагины и хуки теперь корректно работают без компромиссов изоляции воркеров.

▶️Производительность UI/API: заметно ускорены страницы (включая список task instances и “next run assets”), исправлен экспорт логов.

▶️Надёжность планировщика: фикс использования неверного max_active_runs из кеша DAG; корректнее обработка триггер‑правил.

▶️Миграции БД и XCom: устранены падения миграций и апгрейда при NaN в XCom.

▶️Поведение воркеров: healthcheck теперь уважает --worker-timeout.

▶️HITL & UX‑мелочи: валидация параметров для HITL‑тасков, фикс logout, рабочая кнопка “Test connection”, resize заметок в UI, обновления переводов.

#airflow #release #de #data

🤖 Walker S2: когда демки превращаются в поставки

UBTECH показала массовую отгрузку человекоподобных Walker S2. На видео — строй роботов в цеху: синхронный марш. Снято так чисто, что интернет спорит, CGI это или нет — но именно такая синхронность и отличает хорошо отлаженное производство.

Почему это важно?
🔘Вместо шоукейсов — операционная готовность: батарейная логистика, док‑станции, единый такт.
🔘Заявка на первую массовую поставку гуманоидов для реальных линий и складов.

Как тебе такой марш будущего?

#robotics #AI #UBTECH #WalkerS2 #humanoids #automation #industry40 #роботы #гуманоиды #ИИ

Статья Data Warehouse, Data Lake, Data Lakehouse, Data Mesh: What They Are and How They Differ

⏩Склад данных (DWH) — про централизованную чистую аналитику и жёсткие схемы

⏩Озеро (Data Lake) — про гибкость и дешёвое хранение сырья

⏩Лейкхаус (DLH) — пытается объединить их на объектном хранилище с ACID

⏩Меш (DataMesh) — не технология, а оргмодель с доменным владением данными

Выбор зависит от типа данных, требований к скорости/качества и зрелости команды.

〰️〰️〰️〰️〰️〰️〰️〰️

🌙 Как отличаются подходы 🌙

1️⃣ Data Warehouse (DWH) — "чистая кухня" для BI
Централизованное, чтение-оптимизированное хранилище под OLAP‑аналитику и отчёты. Схема фиксируется на записи (schema‑on‑write), сильные гарантии качества и согласованности (ACID), быстрые агрегации. Лучше всего отвечает на "известные вопросы про известные данные".
✏️ Минусы: жёсткость к изменениям, дороговизна при росте, слабая работа с полуструктурой.

2️⃣ Data Lake — "сырьевой парк" для экспериментов
Складывает данные "как есть" (schema‑on‑read) — от логов и JSON до медиа, дёшево масштабируется на объектных сторах. Идеально для исследований и ML.
✏️ Риск: без управления качество деградирует в "болото", запросы часто медленнее, транзакционных гарантий нет.

3️⃣ Data Lakehouse — "самолёт‑гибрид"
Один слой поверх дешёвого объектного стора + "табличный формат" (Delta/Hudi/Iceberg), который приносит ACID, снапшоты, эволюцию схем и ускорение запросов. Цель — гибкость озера c надёжностью склада.
✏️ Ограничения: зрелость стеков, сложность внедрения, иногда уступает специализированному DWH по перформансу.

4️⃣ Data Mesh — "микросервисы для данных"
Это не новый стор, а операционная модель: доменные команды владеют данными как продуктами, есть самосервисная платформа и федеративная (программируемая) дата‑гавернанс.
✏️ Хорош в больших организациях с автономными командами; требует культуры и инвестиций в платформу.

〰️〰️〰️〰️〰️〰️〰️〰️

❓ Когда что выбирать — ориентиры

❗️ У тебя отчётность и стабильные метрики, много SQL‑пользователей, высокие требования к "единой правде": начни с DWH (или с легковесной его версии в облаке).

❗️ Много полуструктуры/неструктуры, активный ML/DS, дешёвое "историческое" хранение сырья критично: ставь Data Lake, но сразу добавляй управление качеством и метаданными, чтобы не получить "болото".

❗️ Нужно и то, и другое, а два стека — боль: бери Lakehouse на открытом табличном формате (Delta/Iceberg/Hudi) — один слой, ACID, time‑travel, апгрейд до "медальонов".

❗️ У тебя много доменов и центральная дата‑команда — узкое горло: добавляй Data Mesh как орг‑надстройку (поверх DWH/Lake/Lakehouse), но не недооценивай стоимость самосервиса и федеративной политики.

👌 Пример из жизни продукта

Представь маркетплейс:
🟡 BI‑команда хочет "вчера к утру" отчёты по GMV/конверсии 🔜 витрины/март в DWH.
🟡 DS‑команда обучает рекомендашки на кликах/поисковых логах/изображениях 🔜 сырые/серебряные слои в Lakehouse на Iceberg/Delta.
🟡 Бизнес растёт, появляются автономные направления (Поиск, Логистика, Финансы) 🔜 они публикуют доменные "данные‑как‑продукт" (контракты, версии, SLO), а платформа обеспечивает каталог, lineage, права и качество ➡️ это уже Data Mesh поверх твоего Lakehouse.

⚡️ Что важно унести из статьи

Автор трезво разводит технологии и организацию:
🟢Lakehouse решает техническую боль разрыва "озеро↔склад"
🟢Mesh — организационную боль централизованных "бутылочных горлышек".

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

#DE #DWH #DataWareHouse #DL #DataLake #DLH #LakeHouse #Mesh #DataMesh

Gemini 3.0 ломает интернет — и делает «теорию мёртвого интернета» не такой уж теорией 🤯

Сейчас по X летает формулировка:

Gemini 3.0 is breaking the internet. Users reported that this model is from another world. 10 unbelievable examples.

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

Но с моделями уровня Gemini 3.0 / GPT-5.x / Claude 4.x мы реально подходим к точке, где:

🔘посты, комменты, обзоры и даже «личные истории» можно генерить пачками;

🔘инфополе забивается не тем, что важно, а тем, что легко сгенерировать;

🔘человеку всё сложнее отличить живой опыт от очень качественной симуляции.


Получается парадокс:
чем мощнее становятся модели, тем меньше "живого интернета" у нас остаётся. Лента ощущается насыщеннее, но живых голосов там всё меньше.

И на этом фоне вопрос уже не «какой ИИ лучше», а как не превратиться в статиста в мире, где львиная доля контента — синтетика.

❓Как тебе такое: через пару лет большинство того, что ты читаешь в ленте, будет написано моделями уровня Gemini 3.0 — норм или крипово?

#deadInternettheory #AI #LLM #теориямёртвогоинтернета #ИИ #БЯМ

📕 Dagster выкатил Scaling Data Teams — практическое руководство по масштабированию дата-команд

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

〰️〰️〰️〰️〰️〰️〰️〰️

🙂 Почему стоит прочитать

Помогает ответить на вопрос: «Как построить такую платформу, чтобы она масштабировалась не хаотично, а с ясностью, надёжностью и уверенностью?»

Не теория, а ориентир: описаны этапы роста — 1, 5, 10, 20 человек.

Разбирает технологический стек и архитектуру таких инструментов как dbt, dlt, Sling, DuckDB и др.

〰️〰️〰️〰️〰️〰️〰️〰️

📌 Ключевые моменты

1️⃣ Этап «1 человек» — как действовать, пока платформа почти не сформирована: выбирать инструменты, делать архитектурные решения, которые не убьют рост.

2️⃣ Этап «5-10 человек» — важность качества, тестирования, рабочих процессов и модульного дизайна.

3️⃣ Этап «20 человек» и больше — как платформа становится инфраструктурой: управление, кросс-командная работа, строгие guardrails.

4️⃣ Архитектурный обзор: современный стек данных, оркестрация, загрузка, трансформация, аналитика.

〰️〰️〰️〰️〰️〰️〰️〰️

✔️ Что можно применить прямо сейчас

⏩ Посмотри на свою текущую команду и платформу: на каком ты этапе?

⏩ Проверь, не делаешь ли архитектурные решения «как для 1 человека», в то время как фактически рост уже требует другого подхода.

⏩ Внедри практики тестирования и процессов, которые подходят не только сейчас, но и под будущий рост.

⏩ Обрати внимание: инструменты могут быть важны, но правильное время для их внедрения и синхронизация с ростом команды — ключ к успеху.

〰️〰️〰️〰️〰️〰️〰️〰️

✏️ Для кого эта книга особенно полезна

➡️ Руководителям дата-инженерных или платформенных команд, которые думают о росте.

➡️ Платформенным дата-инженерам и технологическим лидерам, которые хотят улучшить процессы и архитектуру.

➡️ Организациям, которые понимают — просто больше данных или больше инструментов не решат проблему, пока не построены процессы и культура.

#book #dataengineering #data #dataengineer #engineer #данные #книга #инженерияданных #датаинженер #инженер