Это разве аналитика?

Ода эффективным менеджерам

«Это мне ИИшка посчитала, я не знаю, как и почему»

От создателей:

«Этот слайд мне аналитик прислал, у него и спрашивайте»

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

На открытом уроке 30 сентября в 20:00 МСК разберем, как применять ИИ в анализе данных: от подготовки запроса и очистки данных до поиска аномалий, проверки гипотез и создания аналитических выводов. Вы узнаете, какие задачи можно передать нейросети, как проверять ее результаты и превращать данные в рекомендации для принятия решений.

Урок пройдет в преддверие старта курса «Аналитик данных». Занятие подойдет аналитикам, системным и бизнес-аналитикам, которые хотят сократить рутинные задачи и эффективнее работать с данными.

Освойте практический подход к анализу данных с помощью ИИ и используйте новые инструменты в работе:
https://clck.ru/3VyBJz

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Главный вопрос к AI не «умеет ли он», а «умеешь ли ты ставить ему задачу»

Такую мысль услышал в подкасте о том, как AI трансформирует аналитику в Яндексе.

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

Близко сопротивление сеньоров: «Я сделаю быстрее сам». И я делал. Но аргумент ломается, когда ресурсов в команде меньше, а задач больше. Тогда агент перестаёт быть игрушкой и становится единственным способом успеть.

Хорошая мысль в подкасте была и про KPI: важно измерять не само использование AI, а его результат. Иначе инструмент начинают осваивать ради галочки.

И последнее — про привычку. Сначала работа с ИИ может быть медленной и неловкой — потом не представляешь работу иначе. Это правда касается любого инструмента, не только ИИ.

Обратный ETL через Superset и премудрости корп архитектуры

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

Открыл для себя что один из самый простых способов поставить данные из КХД на прод - через Superset API. Там есть несколько методов программно по HTTP выдрать датасет из-под чарта.

Опа!
https://superset.company.name/api/v1/chart/{chart_id}/data/ - и готово!

И это здорово, так как не порождает никаких доп процессов и систем. Суперсет-то все равно работает. Данные - обычный датасетик-витрина, легко создается и обмазывается теми же DBT тестами. Всяко лучше, чем городить силами дата офиса отдельные сервисы на FastAPI. Ноль лишних сущностей для команды данных.

И самый смех в том, что в условиях кровавого энтерпрайза эта конструкция легко протаскивантся через самые жесткие комитеты. Включая кибербезников.

Сами посудите

1️⃣ Данные идут из готовой системы, которая уже утверждена по высокому классу безопасности. А как по-другому, в BI в любом случае содержатся и перс данные и корп тайна.

2️⃣ Ролевая модель доступа - есть. Достаточно замороченная (для целей BI - слишком замороченная). Авторизация - есть, причем уже сынтегрированная с принятыми в вашей конторке SSO и LDAP-ами. Даже RLS можно сделать! Даже секьюрити аудит через логи суперсета можно устроить.

3️⃣ HTTP протокол, значит он легко убирается за доп слои безопасности, за любые балансировщики и фаерволлы, хоть NGFW с анализами паттернов доступа. Накинуть серты Минцифры - запросто! Его же легко замониторить, он понятен разработчикам на абсолютно любом стеке.

4️⃣ Готовый MCP сервер заказывали? А он там есть.

В итоге на первый взгляд - элемент дендрофекальной архитектры. А на деле - надежный энтерпрайзный паттерн интеграции.
🧐🧐🧐

Гайз, знаю что все ждали этого — новый сезон опроса State Of Data
оч прошу потратить 10 минут времени всем и каждому + разослать по чатикам с коллегами

в этом году, ожидаемо, появились вопросы про всякие llm и прочих агентов )

https://forms.gle/Fp6HrZxBw7Y5VbFw7

давайте посмотрим насколько помирает хадуп (особенно по сравнению с позапрошым годом)
насколько выстреливает старрокс (или наоборот стагнирует)
и прочие интересные инсайты вытащим

там в форме есть ссылки на .parquet с исходниками опросов '24 и '25
по текущему опросу исходник выложу в ту же гуглопапку ~ в середине октября

По заявкам.

Разные движки воспринимают ролевую модель айсберг-лейкхауса по-разному. И с этим надо смириться и воспринимать как вариант нормы.

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

Один из способов- начать работать с S3 ключами.

А как? А вот так.

1️⃣ команде пользователю данных выдаем ключ не на весь бакет, а более гранулярно. Пользуемся тем, что если default location у нас s3://ice-bucket/data, то объекты по умолчанию будут разложены по префиксам s3://ice-bucket/data/schema/table.

Вот и выписываем их гранулярно на схемы и таблицы. Эти же ключи раскладываем по ноутбукам, спаркам, трино каталогам, аэрфлоу и тд.

2️⃣ В айсберг таблице есть параметр location. Это корень обхода дерева метадаты айсберг и то куда айсберг складывает свой стафф. По умолчанию он берется из настроек коннектора и каталога.

Так вот, ничего не мешает этот локейшен точечно переопределить. Например на s3://ice-bucket/secret/ или s3://secret-bucket или (внезапно!) hdfs://path

И все будет работать до тех пор пока чтец обладает правами на предоставленных ему s3 ключах.

Причем во многих s3 реализациях нельзя на один ключ грантовать права в разных бакетах. Разнося таблицы по бакетам мы получаем гарантию, что команды из чистой зоны физически не смогут добраться до секретной зоны со своими ключами.

Вот так мы добавляем доп слой гарантированной безопасности, который будет работать на низком уровне даже если сервисы джейлбрейкнут Ranger или REST Catalog. (А они ведь могут!)

Не забудьте только навайбкодить сервис, который будет выпускать, отзывать, аудировать и раскладывать в конфиги и волты ваши s3 ключи! 😎

Безопасность в Iceberg-Lakehouse

Берем Iceberg REST Catalog в виде Apache Polaris. Коннектим его к Трино как каталог. При этом передаем общие принципала и креды. Все подключается и успешно создаем, удаляем, работаем со схемами и таблицами.

Теперь хотим подцепиться к тому же каталогу через PyIceberg. С теми же кредами. И Ловим 401 на попытке прочитать таблицу? Почему?

Потому что PyIceberg честный и спрашивает креды на значимые действия с таблицей. Подчинаяется ролевой модели поляриса в этом плане. А трино просто взял metadata.json из каталога и пошел сам по S3 расшифровывать айсберговскую дату и метадату, никакого разрешения от каталога ему для этого не нужно. Ну и свою ролевую модель поверх наложил.

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

Напоследок - доступные роли в Полярисе, грантов которых PyIceberg от нас ждет. Грантуется это исключительно через CURL.

# Доступные права в поларис

[
CATALOG_MANAGE_ACCESS,
CATALOG_MANAGE_CONTENT,
CATALOG_MANAGE_METADATA,
NAMESPACE_CREATE,
TABLE_CREATE,
VIEW_CREATE,
NAMESPACE_DROP,
TABLE_DROP,
VIEW_DROP,
NAMESPACE_LIST,
TABLE_LIST,
VIEW_LIST,
NAMESPACE_READ_PROPERTIES,
TABLE_READ_PROPERTIES,
VIEW_READ_PROPERTIES,
NAMESPACE_WRITE_PROPERTIES,
TABLE_WRITE_PROPERTIES,
VIEW_WRITE_PROPERTIES,
TABLE_READ_DATA,
TABLE_WRITE_DATA,
NAMESPACE_FULL_METADATA,
TABLE_FULL_METADATA,
VIEW_FULL_METADATA
]

В другом каталоге Iceberg REST роли могут быть другие. В JDBC/Hive каталогах - вообще своя атмосфера.

Apache Airflow 3.3.0: Stateful Tasks and Multi-Language Support

В Airflow 3.3 появился AIP-108 — Language Task SDK. Теперь отдельные tasks можно реализовывать на Java или Go, при этом сам DAG и scheduling остаются в Python.

В DAG задача объявляется как stub:

@task.stub(queue="golang")

Дальше Airflow через Coordinator передает выполнение нужному runtime: JavaCoordinator для JVM или ExecutableCoordinator для Go.

При этом задача остается частью Airflow: доступны XCom, Variables, Connections, retries и стандартный logging.

Это особенно интересно для команд, где orchestration построен на Airflow, а часть production-кода уже написана на Java или Go. Теперь такую логику не обязательно переписывать на Python или выносить за пределы task model Airflow.

Пока Language Task SDK — experimental feature, поэтому API и protocol еще могут меняться.

Документация

@tldr_data

Поделюсь своими ощущениями по использованию AI агентов. Этап эйфории прошёл.

Немножко поподробней про этот этап. У вас есть Claude Code и больше ни у кого его нет. У вас уже настроены MCP ко всем дата-сервисам и базам, и Claude делает за вас 100% работы. Любую задачу вы решаете мгновенно. Коллеги не понимают, что такое Claude Code, и все делают по старинке руками. На их фоне вы просто монстр производительности, даже можете менять и траблшутить Source Code.

Дальше компании начинают инвестировать в подписки Claude Code, и уже волей-неволей у всех появляется Claude. Ты им показываешь, как с ним работать и как всё работает. 2–3 месяца — и коллеги уже могут сами использовать MCP и делать PR через агентов.

Первый звоночек — обычно что-то вроде: «Ты слишком быстро всё сделал, и агент написал лабуду». То есть надо уже больше смотреть за агентом, всё перечитывать и перепроверять. Особенно сложно это делать, когда открыты несколько активных серий в разных репозиториях с серьёзными изменениями.

Также изначально Claude создавал код поверх кода, написанного руками. Этот код очень понятен, ведь ты его сам писал. Но спустя полгода код весь написан уже агентом, и мы уже на 100% зависимы от агента, ведь без него уже очень сложно разобраться, как там всё устроено и как это дело быстро подправить.

И теперь мы приходим к тому, что все одинаково умеют использовать агентов, друг другу проверяют PR, пишут огромные простыни текста — что починить, что исправить. То есть человек как proxy между общением агентов. 😄

Вся скорость и производительность выветриваются, и по факту вам надо больше и тяжелее работать. Если раньше вы работали на 120%, а команда лишь на 20%, то теперь это уже 115% на 120%, то есть в лучшем случае вы немного лучше, но какой ценой?!

Таким образом, мы пришли к тому, о чём говорили всегда: работы стало больше, задачи стали сложнее, а требования по скорости и качеству — выше. Я вижу на примерах, как растут аппетиты у VP-уровня, особенно когда они сами могут общаться с данными и находить инсайты. Они хотят больше и быстрее. У бизнеса теперь много идей, которые надо внедрить.

Да, даже элементарно — частота стендапов возросла до ежедневной, и уже не скажешь «я там ковыряю код», ведь за тебя агент может всё перековырять — сиди и читай, читатель-инженер.

Что будет дальше? А дальше требования будут расти. Даже от новичков будут требовать больше. Вам ведь думать не надо — за вас агент думает, поэтому просто сидите и общайтесь с ним, разбирайтесь. Задач будет больше, требований больше, свободного времени меньше. Людей однозначно нужно больше. Агенты ещё те шалунишки — нужен глаз да глаз за ними, а то положат продакшн. Это ещё не так критично в области data, а вот в customer-facing apps — там ещё сложнее.

Я спросил агента про известные концепции:

Jevons Paradox (Парадокс Джевонса)
Чем эффективнее технология, тем больше её потребляют. Производительность выросла → бизнес поднял планку → работы стало больше, а не меньше. Классика, описанная ещё в 19 веке применительно к паровым машинам.

Automation Bias
Склонность доверять автоматизированным системам больше, чем следует. Отсюда и «агент написал лабуду, но никто не заметил» — люди перестают критически проверять вывод системы.

Skill Atrophy / Deskilling
Деградация навыков из-за делегирования задач инструментам. Ты описал это точно: «код весь написан агентом, и без него уже сложно разобраться». Это активно обсуждается сейчас применительно к junior-разработчикам, которые никогда не научатся думать самостоятельно.

Productivity Paradox (Парадокс производительности)
Технологии растут, а реальная производительность и удовлетворённость сотрудников — не обязательно. Впервые описан в контексте IT-революции 80-90х годов (Solow Paradox).

Alert Fatigue / Review Fatigue
Когда объём вещей, требующих внимания, превышает когнитивные возможности человека. У тебя это — несколько открытых PR в разных репозиториях одновременно.

Shifting Bottleneck
Узкое место не исчезает, оно перемещается. Раньше бутылочное горлышко — написание кода. Теперь — ревью, понимание, верификация того, что написал агент.

Подробности вечернего сбоя в рунете

https://www.securitylab.ru/news/576203.php

meat-proxy — человек который отправляет ответ ИИ вместо своей точки зрения

не будьте meat-proxy 😏

@tips_ai

Хочу проверить, как вы думаете. Держите дело 🕯

Из пятницы в пятницу вы читали, как я собираю это по кускам. Пора показать целиком.

DATA NOIR 🔥
Ночь, лампа, стол, папка с делом.
Вы осматриваете место преступления, ищете подозреваемых по приметам, допрашиваете, ловите на лжи, тянете нити между уликами на доске.
С миром дела вы говорите SQL-запросами. Но учить SQL вас никто не заставляет. Запрос это просто ключ под конкретную дверь.

сначала решаете, какую дверь открыть, и уже под неё ищете ключ

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

Явно верного пути нет. Есть ваша версия и факты, которые её либо держат, либо рассыпают. Ошиблись с обвинением, минус $10 с жетона и обратно к фактам.

Что за этим стоит 🛠
Полтора года заметок, потом сборка. Свет от лампы, доска с нитями, схема таблиц, переписанный онбординг, про каждое из этого я тут уже писал, по второму кругу не пойду.
Просто держите в голове, что стоит за этой картинкой.

Как зайти 🤔
https://data-noir.com/

Важно: сейчас портал открывается только через VPN. Включайте.
Начните с дела №0, это пробный обход. Там вас проведут за руку. Дальше уже сами.

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

А что не зашло, напишите в комментариях 👇
@data_dzen 🙂

😂😂😂😂😂

Цифры от которых бывает печально

смотрю на отчеты топ облачных компаний. За 2 квартал.

Azure - $100+ млрд/год. Рост +43% год-к-году.

AWS - $168 млрд/год ($42 млрд/квартал). Рост +27% год-к-году.

Для сравнения - топ облако в России - Яндекс Клауд показал $0.3 млрд в год. Примерно столько же, сколько Clickhouse Inc.

Российский рынок ИТ по оценке ТАдвайзера - 3,5 трлн рублей в год. Равно $45 млрд.

Капексы только двух компаний Azure + AWS за год - это больше чем потратили на российский ИТ за всю его историю.

Привет моему любимому типу заказчика российского облака: "Ну в Амазоне конечно же круче сделано, чем у вас!" Да чудо что мы смогли к AWS вообще хоть как-то приблизиться имея примерно 0,2% его ресурсов.

Пять базированных вещей для тех, кто вкатывается в аналитику
Часть 2

Первая часть здесь, и там мы остановились на:

А что менеджеру-то отвечать, если он спросит про падение метрик?

4️⃣Умение объяснить результат

Возможно теперь это умение конкурировать с AI за экспертизу. Но еще это умение не городить сложные модели, которые никому не нужны. Давайте не будем строить космолеты с катбустом из 50 фич, когда достаточно просто таблички со скорами.

А давайте теперь представим, что бизнес просто сходил в ChatGPT и спросил что ему нужно напрямую. Ему отвечают быстро, красиво, правильно и уверенно. Почему бизнесу должно ждать именно нас?

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

Умение слушать бизнес и переводить его вопросы в задачи AI не заменит еще достаточно долго

5️⃣Воспроизводимость

Мы обучили модель, получили 0.95 ROC-AUC. Через неделю пересчитали и стало 0.85. А в чем проблема? Ллмка говорит, что random_seed не был зафиксирован, а еще версия нампая обновилась.

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

Скажу базу - AI мощный инструмент в руках того, кто понимает суть и глубину вопроса

С другой стороны уже нет столько времени изучать большие материалы в сильно динамичном мире. Забудьте про roadmap'ы с миллиардами курсов. Берите проблемы и вопросы, которые вас реально беспокоят и на них практикуйте SQL, статистику, питоны. Сделайте из этого реальный проект, пиште код, который будет работает одинаково. Ну и собирайте команду единомышленников, чтобы взаимодействовать друг с другом.

Согласны? Надеюсь никого не напугал?

Кстати, можем попробовать собрать мини-комьюнити с таким движняком - с вас эмодзи или стикеры в комментариях. А с меня время на подумать

#ml #career #novice #softskills #llm #agents

Пять базированных вещей для тех, кто вкатывается в аналитику
Часть 1

Недавно разбирал резюме кандидатов на вакансию и в который раз заметил одни и те же шаблоны. Открываешь резюме, и там написаны все ключевые слова, супер проекты, несколько лет опыта в виде прохождения курсов, ну и скорее всего перед собесами выучены одни и те же источники с ответами на 100 самых известных вопросов. А потом откликаются на непростые вакансии с узкой направленностью и на первых же вопросах идет столкновение с бурмалдой реальностью.

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

Зачем мне SQL/статистика/питончик - у меня есть ChatGPT, он все напишет

1️⃣SQL

Я уже писал об этом, и реально рекомендую начинать именно с SQL. Больше половины рабочего времени уходит на подготовку, обработку данных и приведение их в нормальный вид. SELECT, WHERE, JOIN, GROUP BY, оконные функции - это обычный базовый минимум.

И пусть ChatGPT напишет вам запрос и возможно он заработает с первого раза. Только как вы поймете, что он написал его правильно, если сами не знаете SQL? Я по долгу своей работы неоднократно видел кейсы, когда скармливаешь LLM весь контекст задачи, раздаешь тулы, доступы, апишки, и возможно даже на выходе получаю красивый запрос. Но блин есть вероятность, что он либо не отработает, либо выдаст не тот результат. Допустим из-за неправильного джойна или не выбора не той колонки из 5-ти похожих.

Ну и прикиньте, если кто-то из нас спокойно понес бы этот результат бизнесу, потому что проверить не хватило экспертизы

2️⃣Статистика

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

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

Пока AI не сможет собирать весь контекст, он не заменит языка выводов в том смысле, в котором знаем его мы

3️⃣Реальный проект

Напомню, что в последнее время требования растут. При входе в профессию уже не хватит просто знаний Python и SQL. Нужен реальный и работающий проект, сделанный полноценно от формулировки задачи до крутых метрик и выводов. И скорее всего уже не Kaggle (только если не планируется там лутать медали). Реальный имеется в виду такой, где мы сами собирали данные, чистили пропуски, работали с дубликатами, обучали модель и тестировали гипотезы.

Хорошая новость - AI реально может ускорить рутину и написать весь этот код с чисткой данных, бейздайнами и пайплайнами, уже и предложит идеи по фичам. Плохая новость - если ты бездумно использовать ллмки как костыль с первого дня, ты возможно мы не на 100% погрузимся вглубь того, что сейчас происходит внутри проекта.

Как можно управлять процессом, которого не понимаешь? Что делать, если все поломалось и данных нет? Какой вариант правильный из трех предложенных агентом?

А что менеджеру-то отвечать, если он спросит про падение метрик?

Продолжение завтра...
А пока накидайте ваших мыслей в комментарии, что же там может быть еще?

#ml #career #novice #softskills #llm #agents

Какой-то микс нынче в дата мире происходит

Сократят ли кожаных в пользу AI? Я тут погуглил. Мне кажется, что эти 2 компании умеют пользоваться иишкой как никто другой. Ну и чего, сократили там кого-нибудь? :)

С другой стороны не пользоваться сейчас таким инструментом кажется довольно глупой идеей. Не знаю как у вас, у нас в командах данных текучки более 50 процентов. Я больше 10 лет пишу код, около 5 лет в текущей компании. Писать очередной оператор в эйрфлоу, объяснять зафиксированные метрики в дбт в очередной раз? Увольте пусть ии ответит за меня.

И вот эта история с данными, мне кажется, подводит отделы данных к решению такой задачки, как создание "единого хранилища контекста", а моем понимании ai платформы в компании. Что все понимают под этими словами (и понимают ли) - большой вопрос. Есть ли какие-то устоявшиеся шаблоны или хотя бы примеры - нет. Можно ли угадать, куда пойдет развитие иишки - нет.

Именно поэтому это довольно клевая задача :)

Похоже, что StarRocks будет все меньше (хотя мы его и опробовали как хранилище векторов, и у меня для него лежит написание нативного CDC на гошке в беклоге), а больше будет всего подряд про современную техничку в офисе данных во всех ее ипостасях. Потому что никто не рассказаывает про графы для dbt, платформы агентов, тлен векторизации и как подсадить хотя бы 100 человек на свои скилы (оказалось, что писать mcp на гошке - кайф) :)

PS кстати dbx - тормозная штука с глюками интерфейса. И да, это тот момент, когда даже гуй на жабе быстрее.

MotherDuck сделали классный сервис для своего демо, который анализирует данные с LLM