Big Data *

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

Привет, Хабр! Меня зовут Игнатий Цукергохер, я фриланс-журналист и блогер. На Хабре в основном пишу про технику и выкладываю интервью, но решил вернуть рубрику обзоров мероприятий. И начну с такой камерной и при этом хардкорно-айтишной встречи, как True Tech Arch #8.

От корпоративной ИТ-архитектуры сегодня ждут скорости, устойчивости и понятной ценности для бизнеса, но она все еще часто существует в виде схем, презентаций и документов, которые быстро устаревают и мало помогают в ежедневной работе команд. На конференции True Tech Arch #8, последней встрече Гильдии архитекторов MWS в 2025 году, рассказывали, как выбраться из этого замкнутого круга.

В этом материале расскажу про основные темы, которые на ней поднимались: переход от Big Data к Small Data и Data Lakehouse, способы превратить архитектуру в исполняемую и измеряемую систему, а также изменение роли архитектора и коммуникаций между командами при внедрении AI-ассистентов.

Мы в Геоинтеллекте любим геоданные и геоаналитику. Часто миксуем технологии. Вот, например, мы попробовали генерировать графики BI системы DataLens внутри платформы для Геоаналитики “Геоинтеллект”. Что из этого вышло, посмотрим на реальном кейсе, которая выполняла наша сотрудница. 

Задача

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

Я уверен, вы видели модели машинного обучения, которые принимают текст и предсказывают, является ли он спамом. Аналогично модель может проанализировать отзыв о фильме и определить его тональность — положительную или отрицательную, понимать что «груша» связана с «яблоком» куда больше, чем с «теплоходом».

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

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

С картинками все просто. В чёрно-белом изображении (в градациях серого) самый яркий пиксель имеет значение 1, самый тёмный — 0, а оттенки серого имеют значения от 0 до 1. Такое числовое представление упрощает обработку изображений. Преобразовав изображение в цифровую форму на основе значений пикселей, мы можем использовать его в качестве входных данных для обучения нашей модели, позволяя нейронной сети обучаться на значениях пикселей.

Однако что делать с текстом? Как спроецировать буквы в числа?

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

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

Именно о них предлагаю поговорить сегодня.

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

Привет, Хабр! С каждым годом ИИ способен решать более сложные задачи, одной из задач является понимание DAX, связанных предметных областей и генерация кода. Можно выделить несколько задач, которые не являются первостепенными, тем не менее актуальны для анализа или работы в Power BI, например, от простейших — создание клиента для выполнения DAX запросов в Power BI из произвольной среды (например, из .NET приложения) и импорт метаданных TOM модели, до более сложных задач — экспорта схемы данных и самих данных из Power BI в произвольную СУБД (понятно, что такая задача не всегда актуальна с точки зрения ETL, т.к. проще взять данные из исходных источников, а не из Power BI, но польза решения задачи «интуитивно понятна» пользователю) и задач генерации SQL запросов на основе DAX для заданной СУБД, причем результаты сгенерированного SQL должны совпадать с результатами DAX запросов.

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

Matplotlib — это мощно, но часто «многословно». Чтобы превратить стандартный график в нечто презентабельное, приходится писать десятки строк настройки осей и легенд.
В этой статье я собрал практическую шпаргалку (Cookbook) по библиотеке Seaborn. Разберем, как одной строкой строить красивые Heatmap, Boxplot и Pairplot. Минимум теории, максимум готовых рецептов (copy-paste), которые покроют 90% задач аналитика.

Миронов В.О., Кальченко С.Н.

Добрый день, уважаемые хаброгорожане;‑) Крайние тренды по части тестирования современных больших языковых моделей выходят на невиданные высоты и ставится цель: пересматривать не только всю систему анализа моделей, но и саму структуру эволюции нашего подхода к пониманию больших языковых моделей в самом широком контексте. Здесь мы всё больше «скатываемся» к математическому описанию объекта промпта и его понятия. По большому счету, наибольшее понимание, а именно, формирование идей в машинном представлении, основано на геометрическом понимании «форм» слов, а не алгебраическом, в виде векторов, эмбеддингов и матриц, хотя это тоже очень важно на базовом уровне. Отличный пример такого подхода изложен в этой статье, где как раз и показано, что важно, топологическое представление пространства слов и их смыслов, так как оно максимально гибко и позволяет работать с двумя главными понятиями для словоформ: значение и время, в течение которого это значение сохраняется для текущего контекста.

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

Сегодня многие компании внедряют ИИ‑ассистентов, которые автоматически пишут 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 год? Какие компании и стартапы сейчас на слуху? Как ИИ влияет на экономику и регуляции? Помогает ли ИИ двигать науку и медицину? Ответы (с мемами!) смотрите в статье