Big Data *

Сегодня многие компании внедряют ИИ‑ассистентов, которые автоматически пишут SQL‑запросы и помогают менеджерам готовить отчеты. На первый взгляд они отлично справляются с цифрами и синтаксисом, но теряются, когда дело доходит до бизнес-контекста. Почему? Потому что бизнес живет не только данными, но и контекстом: историей компании, внутренними правилами, неформальными договоренностями, культурой. 

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

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

Практическое руководство по построению сервиса перехвата медленных запросов в StarRocks: правила kill и пороги (full table scan, scan rows/bytes), анализ execution plan, интеграции с Grafana и Feishu, SQL-схемы и YAML-конфигурация для продакшена.

Привет, Хабр! Меня зовут Евгений Мичурин, я senior BI-разработчик в Авито.

Если у вас BI растёт хаотично — вы наверняка сталкивались с тем же, что и мы: сотни дашбордов, разный стиль, неясные владельцы, дублирующиеся датасеты. В какой-то момент это превращается в хаос, где пользователи не доверяют данным, а self-аналитика становится невозможной.

Мы решили навести порядок и создали фреймворк автосертификации BI‑отчётов. В этой статье рассказываю, как он работает, какие критерии мы выбрали и как мотивировали команды участвовать в процессе.

Попробуйте найти исторические курсы для пар вроде «доллар к афгани» или «евро к таджикскому сомони». Данные либо платные, либо их просто нет в виде готового датасета. Мы решили эту проблему в рамках своего проекта, хотя единственный подходящий API диктовал суровые условия: 8 запросов в минуту и 5000 дней за раз.

Получилось! Наш Python-скрипт аккуратно, чанк за чанком, собрал историю всех 287 пар за 4.5 часа, ни разу не превысив лимит. В статье делюсь техническими деталями, как выстроить такую загрузку, и уроками, которые мы извлекли.

Для начала — немного контекста. Я не программист и не разработчик. Последние 12 лет я проработал в Федеральной налоговой службе. Начинал с низов, занимался выездными и камеральными проверками (проводил лично и курировал). Два месяца назад я уволился, завел свой телеграм‑канал и теперь работаю в налоговом консалтинге.

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

DAX содержит гибкие возможности фильтрации, и важными функциями являются ALL и REMOVEFILTERS. При использовании ALL и REMOVEFILTERS в качестве модификатора CALCULATE они ведут себя одинаково, т.к. в этом случае REMOVEFILTERS является псевдонимом ALL, однако ALL в FILTER возвращает «новую таблицу» и очищает влияние всех фильтров, что важно учитывать с точки зрения производительности и результатов.

Интересующимся особенностями ALL и сравнением ALL и REMOVEFILTERS  — добро пожаловать под кат :)

После моей статьи про АИС «Налог-3» (как одну из самых мощных государственных IT-систем России) в комментариях больше всего спорили не про масштабы данных и вопроса, «видит ли ФНС всё». Основной скепсис вызвал мой тезис о необходимости внедрения больших языковых моделей (LLM) в работу налоговых органов.

Основной аргумент в противовес моей позиции звучал так: «Зачем там нужен Искусственный Интеллект? Всё формализовано, достаточно жестких алгоритмов и грамотных шаблонов. Экспертная система справится сама, не надо усложнять».

В этой статье я постараюсь привнести ясность в то, как происходит сбор доказательственной базы по налоговым правонарушениям и как формируется итоговый документ (акт и решение по налоговой проверки). Потому что в реальной налоговой проверке проблема не в том, чтобы найти риск или подсветить признаки. Это АИС «Налог-3» уже умеет делать достаточно хорошо. Проблема в другом - превратить массив фактов в доказательства и выводы, а затем изложить это в юридически выверенном тексте, который выдержит спор сначала на стадии возражений, потом в вышестоящем налоговом органе, а при необходимости и в суде.

Если вы читаете меня впервые: я не аналитик со стороны и не «диванный эксперт». За моими словами 12 лет работы в налоговых органах, в том числе на руководящих должностях. Из системы я ушёл совсем недавно и прекрасно понимаю, как это работает изнутри.

За последнее десятилетие Федеральная налоговая служба (ФНС) совершила фундаментальный переход от традиционной модели администрирования к подходу, основанному на анализе больших баз данных.

Если вы соприкасались с налоговой системой - проходили проверки, бывали на комиссиях в инспекциях, общались с налоговыми органами, то вы слышали про АИС «Налог-3», одну из самых масштабных государственных IT-платформ в России.

Я проработал в системе налоговых органов 12 лет - от рядового инспектора в ИФНС до заместителя начальника отдела проведения налоговых проверок Управления ФНС - и наблюдал эту трансформацию изнутри. В этой статье я хочу показать, насколько эта система действительно мощная, как она эволюционировала, что она реально умеет сегодня и почему, несмотря на весь объём данных, это пока не «искусственный интеллект, который всё делает сам»

Сразу обозначу границу: я не раскрываю никакой служебной информации. Всё, о чём в статье пойдёт речь, это обобщение моего опыта работы в службе и данные, которые размещены в открытом доступе. Из налоговых органов я ушёл относительно недавно (2 месяца назад), и за это время мало, что могло поменяться, поэтому информация все еще остается актуальной.

CUPED часто рекомендуют как простой способ сделать A‑B тесты чувствительнее, но в реальных экспериментах он может как помочь, так и навредить. Причины почти всегда практические: историческая ковариата пересекается по времени с экспериментом, отличается единица анализа, есть пропуски или выбросы настолько велики и значительны, что оценка коэффициента становится неустойчивой.

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

Я блокчейн разработчик, и в проекте у нас базы на сотни гигабайт с децентрализованных бирж. Чтобы строить аналитические отчеты и делать агрегации, такие как вычисления цен, биржевых свечей, объемов торгов, цен на токены, мы используем БД Clickhouse. До этого я работал только с Postgres (и давно с MSSQL), и хочу рассказать, как я вкатывался, что удивило – практический опыт и WTFы. Прочитав эту статью вам, возможно, захочется сделать аналитику по своим данным в Clickhouse – возможно, ищете, что полезного освоить на длинных выходных. Итак, поехали!

Весь год я ежедневно следил за новостями в области искусственного интеллекта. И очень устал. Имена новых моделей, бьющих очередные бенчмарки, превращаются в шум, а мозг уже не реагирует на очередные срочные (!) сообщения инфлюэнсеров о БЕЗУМНОМ прорыве. На деле такое количество информации избыточно, если только вам профессионально не нужно следить за какой-либо областью. Но охота видеть развитие технологий широкими мазками, чтобы понимать изменения на горизонте месяцев и лет. Не найдя такой высокоуровневой подборки, которая бы меня устроила, я решил написать её сам. В этой статье вы найдёте описание развития ИИ за год. Что изменилось в технологиях за 2026 год? Какие компании и стартапы сейчас на слуху? Как ИИ влияет на экономику и регуляции? Помогает ли ИИ двигать науку и медицину? Ответы (с мемами!) смотрите в статье

Вокруг ФНС в последнее время крутится слишком много мифов. Последний из них — история про новогодний стол, икру и якобы контроль налоговой через фотографии в соцсетях.

Этот инфоповод и стал причиной написать статью. Не для того, чтобы обсуждать конкретную «страшилку», а чтобы показать как на самом деле устроен налоговый контроль: что ФНС реально проверяет, на какие данные опирается и почему большинство популярных представлений не имеет отношения к практике.

Я опираюсь не на слухи и пересказы, а на реальный опыт работы с налоговыми проверками и понимание внутренних механизмов ФНС. За плечами — 12 лет работы в налоговой системе в разных направлениях: предпроверочный анализ, камеральные проверки, выездные проверки и курирование отраслевых направлений внутри региона.

Аномалия: CRM «горит», хотя графики растут

Утро. На белой доске ещё держится вчерашний план смены, а в CRM задачи мигают красным — как гирлянда, только без ощущения праздника. При этом на дашбордах всё выглядит прилично: лидов больше, звонков больше, эфир растёт.

Проблема в том, что «больше» не всегда означает «лучше». В процессах с ограниченным ресурсом (в нашем случае — люди и минуты эфира) рост входа часто масштабирует не результат, а потери: очереди, лишние пересадки, паузы в коммуникации, усталость смены.

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

Контекст: вход процесса — лид, выход — следующий шаг

Мы — Lead IT. Приводим застройщикам лиды по фиксированной цене и работаем по CPA. Плюс держим свой колл‑центр..

Чтобы не путаться, зафиксируем термины как процесс.

Всем привет! Меня зовут Дмитрий Листвин, я занимаюсь аналитическим хранилищем данных в Авито.

В этой статье я собрал наш опыт построения Lakehouse поверх объектного хранилища, как реальная аналитическая нагрузка быстро превращает «обычный S3» в самый капризный элемент всей архитектуры. Будет много про извлечение максимума производительности из Ceph: как добиться высокой пропускной способности HDD, когда поверх данных хочется запускать тяжёлые аналитические запросы.

Привет, Хабр! Меня зовут Игорь Миленький, я руководитель отдела ML-аналитики в музыкальном сервисе Звук. Расскажу об еще одной профессии в Data Science, ML-аналитике, и покажу на практике, как устроена работа команды в Звуке. В статье хотел бы дать общее представление о профессии ML-аналитика и примерах задач.

Всем привет! Меня зовут Дмитрий Рейман, я техлид аналитической платформы Avito. Уже третий год мы занимаемся миграцией с Vertica на Trino. Изначально казалось, что это будет просто: перенесём запросы, перепишем коннекторы, чуть подправим пайплайны.

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

Это заключительная часть серии «23 фичи Luxms BI, которыми мы гордимся». В первой мы говорили о платформенности и архитектуре, о фундаменте системы. Во второй – о классическом BI-функционале. В третьей – о возможностях, выходящих за рамки привычной бизнес-аналитики.

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

Привет, Хабр!  Меня зовут Юлианна Валиуллина и я главный эксперт по развитию BI в банке Уралсиб.

Для начала немного о нас: мы практикуем self-service подход, в банке более 200 разработчиков, из них 150 имеют опубликованные дашборды, остальные делают аналитику для себя. Более 1200 опубликованных дашбордов, MAU около 1500. Большая часть дашбордов в нашем банке работает в spider(extract) режиме, доля direct 15-20%.

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

Всем привет! Меня зовут Дмитрий Рейман, я техлид аналитической платформы Авито. Мы строим систему общего назначения, которая одновременно обслуживает ETL, витрины, BI, ad-hoc аналитику и продуктовые платформы.

И в какой-то момент мы столкнулись с неприятным эффектом: объём данных начал расти заметно быстрее, чем органический рост, на который мы ориентировались раньше. Модель классического on-prem DWH перестала масштабироваться линейно: борьба за ресурсы мешала давать гарантии готовности данных; локальные оптимизации давали всё меньший эффект; любой рост требовал масштабирования “по месту” и приводил к длительным простоям аналитики.

Стало понятно, что дальнейший рост в рамках прежней архитектуры будет только усиливать эти эффекты. Именно так мы пришли к необходимости сменить базовую парадигму хранилища и начать движение в сторону Lakehouse-архитектуры. О том, как это было, читайте под катом.