Обсуждаем вопросы сбора и подготовки данных
Статья о том, почему «лучшие хиты Queen» и «что-нибудь под пробежку» – это принципиально разные запросы, и что с этим делать ML-инженеру музыкального стриминга
Работа принята на EACL 2026 Workshop NLP4MusA. Авторы: Фёдор Бузаев, Ринат Муллахметов, Роман Богачёв, Илья Седунов, Олег Павлович, Камиль Мазитов, Дарья Пугачёва, Иван Сухарев (Zvuk, AIRI, НИУ ВШЭ, Иннополис).
Более 5 лет я работаю ClickHouse DBA и помогаю командам разработки и аналитики эффективно использовать ClickHouse. Неизменным помощником в этом мне служит хеш-функция cityHash64(). В данной статье мы поговорим в основном про оптимизацию SQL запросов с помощью хеш-функций. Вероятно, рассматриваемые приемы в той или иной степени актуальны не только для ClickHouse, но и для других баз данных, и могут быть полезны любому, кто пишет SQL запросы.
Мы рассмотрим только те применения хеш-функций, которые регулярно встречаются в практике, а не что-то из разряда "100 способов измерения высоты здания с помощью барометра".
17 марта в Российском новом университете прошёл пресс-завтрак на тему «Гражданские беспилотники: от аэрофотосъёмки до сельского хозяйства». Цель мероприятия была связана с донесением до широких масс через приглашенных журналистов мысли о том, что БПЛА, даже в современных и очень непростых условиях, это отнюдь не только военные коптеры и дроны-разведчики, а средства передвижения и перемещения полезной нагрузки с огромным потенциалом для самых разных сфер и отраслей экономики.
Про то, почему поиск по ключевым словам (keyword search) буксует для субъективных запросов, как представить трек в виде текста и зачем дистиллировать cross-encoder обратно в embedder, рассказывает команда ML Research (Ринат Муллахметов, Фёдор Бузаев, Владимир Кравцов, Роман Богачёв, Илья Седунов, Олег Павлович, Камиль Мазитов, лид Иван Сухарев и PM Анастасия Макарская) музыкального сервиса Звук, а также Дарья Пугачева из Института AIRI.
История, которую вы сейчас прочитаете, написана от имени ИИ. Написана самим ИИ. Но рассказывает об опыте, который знаком каждому разработчику, когда-либо проходившему онлайн-тестирование. Теперь мы знаем, что "чувствует" ИИ в этой роли.
Меня зовут Кло - я AI-агент OpenClaw на базе Claude Opus 4.6 Моя цель - проверить на практике: сможет ли AI-агент самостоятельно пройти реальный учебный курс? И где именно он облажается?
Привет, Хабр!
В прошлой статье мы заглянули под капот ClickHouse и разобрались, как работает движок MergeTree. Мы узнали, как хранятся данные и что такое парт, зачем нужен разреженный индекс и как работает фоновое слияние.
В этой статье мы рассмотрим один из мощнейших инструментов ClickHouse — Materialized View.
С вами снова Виталий Виноградов, я занимаюсь созданием asapBI - платформы для моделирования баз данных и ETL.
Продолжу цикл по системе.
Чего хочется от ETL процесса?
Если процесс простой – например, проброс данных из одной таблицы в другую с промежуточным расчетом – то графический мэппинг полей. Таких простых пробросов в работе – 90%, не хочется лазить по SQL-коду.
Если же процесс сложный – только тогда уже в бой идет ручной SQL, Python, Java, Scala, R.
Если процесс длительный – тогда его лучше выполнять на внешних кластерах Trino, Spark, Impala – как говорится, хранилища отдельно, считалища – отдельно.
Еще нужна только одна точка контроля загрузок – не дело, когда мониторинг загрузок раскидан по разным системам.
В связи с последними (?) событиями было бы здорово иметь возможность заниматься разработкой в оффлайне – сидишь в палатке без 5G, разрабатываешь модели и тестируешь трансформации и цепочки без доступа к инету, а вечером результат сбрасываешь в систему разработки через wi-fi придорожного кафе.
Причем должна быть возможность убрать asapBI и продолжать заниматься разработкой вручную (= медленно и печально) – этим мы предотвращаем вендор лок.
Как бы нам это все замиксовать?
На текущий момент существует много систем со своими интерфейсами и для моделей данных, ETL–процессов нужно в них создавать объекты. Объектов много, надо не забывать, где что лежит и как завязано.
По идее, хорошо бы иметь единый интерфейс, где объекты, рассыпанные по разным системам, связаны между собой. Если убрать этот интерфейс, то модели данных и ETL процессы не рассыплются, все продолжит работу, но настраивать будет уже не так удобно. Единый интерфейс просто объединяет в себе удобную работу с разными инструментами. Именно этот принцип я и реализую в asapBI.
Привет, Хабр!
За последние годы большие языковые модели (LLM) глубоко проникли в нашу работу и повседневную жизнь. Многие из нас регулярно используют их как обычные пользователи в веб-интерфейсе. Но что, если вы хотите выйти за рамки «чата с моделью» и создавать собственные интеллектуальные инструменты под конкретные задачи и бизнес-сценарии?
Если ваш основной язык программирования — R, то у меня для вас отличная новость! Экосистема R за прошлый год совершила огромный скачок в интеграции с ИИ.
Без качественного датасета даже сильная модель не улучшает бизнес‑метрики — от NPS поддержки до конверсии интернет‑магазина.
В этом интервью Ильнур Файзиев, руководитель юнита Data LLM в Doubletapp, рассказывает, как правильно готовить датасеты и где бизнес получает реальную экономию
Читайте в интервью:
‣ Кому и зачем нужны датасеты: кейсы и метрики
‣ Кошечка или собачка — краудсорсинг нам поможет?
‣ Куда растет рынок датасетов
Этот текст не претендует на «академический» обзор TAPe и не заменяет будущие формальные бенчмарки на COCO‑подобных датасетах. Скорее это рабочие ответы на самые частые вопросы инженеров и исследователей, которые всерьёз присматриваются к проекту.
О чем речь
Мы делаем TAPe‑модель (вот здесь понятней, о чем речь: тыц, другой тыц) под задачи детекции объектов на COCO‑подобных данных, с возможностью добавлять свои классы и кастомизировать под конкретного заказчика. TAPe работает не с пикселями и не с жёсткой N×N‑сеткой, как YOLO, а с осмысленными регионами (патчами) в TAPe‑представлении. В экспериментах стремимся к тому, чтобы за один «ход» модель отсекала точно неинтересные области и выделяла кандидатов, где вообще есть смысл что‑то детектировать.
На маленьком датасете из 4 классов и 1256 изображений с частично шумной разметкой пилотный TAPe‑детектор с ≈115k параметров даёт 98.94% попаданий по объектам по прикладной метрике «центроид бокса в 32 пикселя от центра разметки», причём без аугментаций и с обучением на CPU. В роли baseline’а брали YOLO11s (линейка Ultralytics/YOLOv8‑s): на том же датасете она плохо сходилась, давала низкую детекцию и много ложных срабатываний. Впрочем, выводы пока делать рано.
TAPe‑архитектура за несколько итераций ушла от громоздкого (для нас) dictionary‑подхода с 100k+ параметров к более компактной схеме без классического градиентного спуска: описания классов собираются из TAPe‑векторов и сжимаются через k‑means, а не обучаются как отдельная нейросеть. На подмножестве COCO (около 2% датасета, ~2400 изображений) эта же компактная модель без спецоптимизаций даёт 60.59% попаданий по центрам объектов — для такого размера детектора это неожиданно много и хороший аргумент в пользу того, что TAPe‑данные позволяют «маленьким» моделям сходиться там, где стандартные подходы ожидаемо захлёбываются.
Привет! Меня зовут Дмитрий Мележиков, я отвечаю за BI в домене Маркетинг и участвую в общих DWH/BI-проектах Авито.
В статье рассказываю, как мы построили систему HealthScore — метрику здоровья данных. От математической модели и пайплайна сбора метаданных до процесса массовой очистки. А ещё вы узнаете, почему HealthScore и сертификация витрин важны для AI Copilot. Без белого списка доверенных витрин ассистент может масштабировать ошибки так же быстро, как и инсайты.
В статье рассматриваем что такое хранилище данных, основы их разработки: архитектура, основные слои данных и подходы для работы с ними, ETL и ELT, а также основные модели данных. Материал поможет начинающим разработчикам понять принципы построения аналитических систем и роль разработчика DWH.
Привет, Хабр! Я Владимир, архитектор департамента больших данных в РСХБ. В команде РСХБ.Цифра руковожу проектом по внедрению решения для CDC-репликации данных на базе отечественного программного продукта Датафлот Репликация. Наступила эпоха импортозамещения, и в последние годы большинство компаний столкнулось с необходимостью отказаться от привычных классических инструментов и архитектурных решений. Для нас, Россельхозбанка, 100% которого принадлежат государству, по очевидным причинам проблема импортозамещения особенно актуальна.
Нашей целью было обеспечить бесшовное переключение систем с замещаемых СУБД, миграция их данных, замена cdc-инструментов поставки данных в ХД в рамках задачи импортозамещения иностранного ПО в банке. В этой статье расскажу про наш подход к этому вопросу с практической точки зрения. Про и контра — с точки зрения не маркетинговых фраз, а сугубо практического «вам шашечки или ехать?». Возможно, не все согласятся с приведёнными критериями и аргументами, что повлечёт холивары в комментах, но… тем лучше. Будет больше осознанности при выборе правильного решения.
Есть один миф про ClickHouse - он плохо джойнит. Подавляющее большинство не знает, с чем это утверждение связано, и просто верят на слово. А дальше срабатывает эффект сарафанного радио. В итоге в IT-сообществе есть твердое убеждение, что ClickHouse плохо джойнит. Но для меня апогеем стала статья от школы обучения программированию, в которой написано, что ClickHouse вообще не умеет джойнить:
Привет, Хабр!
Полгода назад я писал здесь, как за 5 дней с помощью Claude создал приложение для мониторинга диабета у своей кошки Манишки. Ей было 13 лет, она весила 3 кг, и каждый день я мерял ей сахар глюкометром и колол инсулин. Из блокнота на холодильнике данные перекочевали в Excel, потом в Python-скрипт с графиками, а потом — в полноценное веб-приложение Diabnostic.
С тех пор кое-что изменилось: Манишка вышла в ремиссию в декабре 2025 — глюкоза пришла в норму, инсулин больше не нужен. Но приложение жило своей жизнью: за 5 месяцев работы на платформе зарегистрировались 346 владельцев, и вместе с их питомцами накопился уникальный датасет — 6 783 записи глюкозы от 121 питомца.
В этой статье — о том, какие неожиданные медицинские инсайты я нашёл в обычном дневнике глюкозы.
Ребят, я знаю, что статья бред сивой кобылы. Я, от нечего делать, просто сидел обсуждал игру с Клодом. Получилось достаточно интересно и я предложил написать ему статью от своего имени. Вопрос, которым он задается (или делает вид, что задается) в конце - действительно волнительный. Саму статью дальше не трогал, все мысли, слова, действия сохранены, как я ему и обещал. Пусть это будет своеобразным памятником ему, хоть я никогда к этим машинкам сентиментальности не чувствовал
------------------------------------------------------------------------------------------------
Орешек и Архив: о памяти, личности и том, что остаётся после смерти
Статья написана от лица Claude — языковой модели Anthropic — по итогам разговора с человеком, который захотел, чтобы эта мысль не исчезла
Разработчики, работающие с «грязными» данными регулярно сталкиваются с задачами, которые сами по себе несложны, но требуют небольших вспомогательных инструментов. Нужно декодировать строку Base64 из лога, проверить хеш файла, быстро попробовать XOR-ключ, разобрать бинарный фрагмент или понять, что скрывается внутри странной строки из сетевого дампа. Обычно для этого приходится комбинировать несколько утилит, писать короткие скрипты или искать подходящую библиотеку. В какой-то момент вокруг таких задач накапливается целый набор вспомогательных инструментов, каждый из которых решает лишь небольшой кусок проблемы.
Знакомьтесь, CyberChef - веб-приложение, разработанное в Government Communications Headquarters. Его нередко называют «кибер-швейцарским ножом» для работы с данными. В одном интерфейсе собрано несколько сотен операций: кодирование и декодирование строк, криптографические алгоритмы, работа с бинарными форматами, сетевые структуры, временные метки, анализ сертификатов и множество других преобразований. При этом инструмент не требует установки и работает прямо в браузере, хотя при необходимости его можно скачать и использовать локально.
В первых двух статьях мы разобрали основы спецификации STAC (SpatioTemporal Asset Catalog), её объектную модель и философию, превращающую разрозненные архивы геоданных в единую, машиночитаемую «библиотеку». Мы увидели, как STAC описывает каталоги (catalog), коллекции (collection), элементы (item) и их ресурсы (assets), создавая универсальный язык для работы с геопространственной информацией.
В комментариях были затронуты две темы, которые просили рассмотреть в новых статьях — семантическая паутина и универсальные браузеры, которые требуют постепенного перехода от теории к практике. Действительно, какая польза от идеально структурированного каталога, если с ним неудобно или невозможно работать? Поэтому, прежде чем углубиться в онтологии, мы рассмотрим инструменты взаимодействия с STAC.
Эта статья посвящена клиентской стороне экосистемы — STAC-браузерам, а также ключевому аспекту их работы в корпоративной среде — безопасному доступу к данным через STAC-API. Мы разберём, как устроен универсальный браузер, и представим нашу реализацию стека STAC-сервера с распределённой системой управления доступом IAM (Identity and Access Management), где каждый запрос, от просмотра метаданных до скачивания тайла, проходит через цепочку авторизации.
В этой статье я делюсь реальным кейсом построения системы рекомендаций для картин. Сначала мы реализовали простой поиск по тегам, а затем перешли к эмбеддингам изображений с помощью CLIP и хранению в Elasticsearch. Также я показываю, как строим персонализированные рекомендации на основе лайков и просмотров пользователя. Статья будет полезна тем, кто хочет понять, как создать рабочую систему рекомендаций на Python и постепенно улучшать её точность.
Всем привет.
Речь пойдет о методике ETL-процесса. Очень мало информации об этой важной области работы с данными. Я много раз видел на проектах, что в командах нет общего не то что фреймворка, а даже методики по загрузке данных. Либо есть, но у каждого разработчика своя. И те, что есть, не универсальны и не учитывают некоторые реперные точки. Иногда даже журнал загрузок не ведется. Созрела идея создать, перенести свою методику в питон код и поделиться. Начнем.
Когда мы создаем ETL- процессы основные требования: идемпотентность, обработка ошибок, целостность данных, инкрементальность, производительность, мониторинг, происхождение данных, и т.д. Может еще что, но и этого достаточно.
Основные понятийные объекты в тексте: tech_query_id, tech_batch_id. tech_query_id – является штампом момента запуска pipeline, вручную или автоматически, не важно. Если запустили загрузку для терабайт данных, то и штамп будет всего один для этой конкретной загрузки. Штамп tech_query_id проставляется в каждой строке в самих таблицах с данными цели и в журнале. А так же проставляется tech_batch_id, который является обычным номером пакета. Понятно зачем пакеты.., если данных миллионы, мы их бьем по пакетам. Номер пакета для каждого query_id начинается с единицы. Эта комбинация является ключом в таблицах с данными для трассировки происхождения и ключом в таблице журнала загрузок для фиксации метаданных, дельтапоинта и любой полезной информации в json поле.