Big Data *

На прошлой неделе я перенес форк Apache Cloudberry на PostgreSQL 19 в виде набора расширений и рассказал, где этот порт проигрывает оригинальному форку. Впрочем как и Cloudberry на ClickBench современные колоночные движки обгоняют его на порядок. И дело тут не в реализации MPP, а в исполнителе PostgreSQL - он работает с кортежами в памяти СУБД. Каждый кортеж проходит отдельно, значение проходит через fmgr, а сегменты кластера лишь добавляют число процессоров на котором крутится тот же самый цикл по строкам таблицы.

Следующий логичный шаг для ускорения - векторизованный исполнитель в PostgreSQL. В открытом коде Apache Cloudberry его нет: от закрытого движка в репозитарии остались только следы - флаг create_vectorization_plan, который планировщик всегда передает как false, а также узел WindowHashAgg без реализации и адаптер PAX под VEC_BUILD, который не компилируется. Проектировать придется самому и, конечно, снова в виде расширения постгреса. Так появился pg_vexec - набор расширений для PostgreSQL 19.

Проект не требует модификации ядра PostgreSQL даже при использовании планировщика ORCA в одноузловой конфигурации без координатора на ванильной сборке PostgreSQL. Модуль gp_orca из порта Cloudberry теперь собирается без pg_core и прочих потрохов greenplum и патчей ядра СУБД, а vexec превращает ORCA в векторный планировщик с исполнителем в “одном флаконе”: его оптимизатор оценивает стоимости теперь и векторных узлов, а транслятор генерирует эти узлы в плане. Патчи ядра не нужны, только если не нужна функциональность и колоночное хранение данных таблиц из Cloudberry. Если же загрузить расширение Cloudberry на пропатченном ядре постгреса, то vexec может более эффективно читать и писать колоночные PAX и ao_column, без лишних конвертаций из и в строки, а Motion тогда может передавать между сегментами данные сразу в колоночном формате Arrow IPC.

И к постгресу можно подключаться как по привычному pgwire протоколу, так и по более современному Flight SQL, что могут оценить те кто будет запускать ML модели на данных из PostgreSQL. Как минимум при загрузке данных в polars скажут мне спасибо!

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

Решили попробовать через бакетирование. Все пользователи в рамках одного эксперимента разбиваются на 256 бакетов, поэтому статистика считается уже по бакетам. В результате вычислительная сложность и объём хранимых данных сокращаются на порядки. Вместо миллионов строк мы работаем всего с 512, поскольку для двух групп нужно обработать по 256 бакетов.

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

Привет! На связи Ольга Попова, ИИ-Евангелист Лаборатории искусственного интеллекта Департамента больших данных Россельхозбанка. Сентябрь получился очень показательным. Если отбросить очередную гонку бенчмарков, вокруг ИИ одновременно происходят три гораздо более интересных процесса: модели превращаются в действующих агентов, ИИ незаметно встраивается в привычные рабочие инструменты, а компании и государства всерьёз обсуждают, кто будет контролировать эту новую цифровую рабочую силу.

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

Привет, Хаброжители! Джей Бортен дает подробное практическое руководство по интеграции данных — от базовых понятий и терминологии до реального сквозного примера, который шаг за шагом превращает разрозненные источники в работающий конвейер на AWS, Qlik, Databricks и Confl uent.

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

BeautifulSoup, Scrapy, Selenium и Playwright часто сравнивают как аналоги, хотя это инструменты разных уровней. Я собрала тестовый стенд и сравнила их на статическом HTML, JavaScript-странице, массовом обходе и работе с UI — с замерами времени, памяти и неожиданными результатами.

Я собрал больше 32 тысяч объявлений с Krisha и данные БНС по зарплатам, ценам, тарифам и переездам. Потом посчитал, сколько остаётся от зарплаты после аренды, еды и коммуналки, и сравнил это с тем, куда на самом деле переезжают люди.

Привет, Хабр!

Меня зовут Данила Ильичев, я инженер-аналитик продукта Digital Q.Sensor BI в компании «Диасофт». Недавно я провел вебинар, на котором мы разбирали практический вопрос: как далеко сегодня можно зайти в финансовой аналитике, если отдать часть рутинной работы искусственному интеллекту.

ИИ в финансовой аналитике для нас – это не история про модную технологию, которую нужно куда-нибудь встроить ради факта использования ИИ. В первую очередь это вопрос: какие этапы аналитики можно ускорить с помощью ИИ, сохранив контроль над данными, расчетами и результатом. Одним из ответов стала легковесная платформа Digital Q.Sensor BI.

Главный сдвиг — Data Catalog перестал быть просто справочником метаданных и становится инфраструктурой доверия к данным и источником контекста для аналитиков, процессов и ИИ-агентов.

Три года назад мы выпустили исследование российских каталогов данных. Тогда для сравнения решений хватало около 20 вопросов: есть ли автоматическая каталогизация, Data Lineage, бизнес-глоссарий и другие базовые функции.

В отчёте «Data Catalog Круг Громова 2026» - количество критериев выросло до 325. За три года рынок заметно изменился, и прежней методики стало недостаточно. В этой статье расскажем не о результатах сравнения продуктов, а о главных изменениях рынка — в том числе тех, которых мы сами не ожидали увидеть.

В первой части материала мы разобрали, что необходимо контролировать в корпоративном хранилище данных - от инфраструктуры и ETL/ELT-процессов до Data Quality и выполнения запросов:

Мониторинг и логирование DWH, часть 1: уровни контроля, метрики и типовые проблемы

Во второй части перейдем к конкретным инструментам: Prometheus, Grafana, Zabbix, ELK Stack, OpenSearch, Loki. Разберем, как они устроены, какие задачи решают, чем отличаются друг от друга и на что обратить внимание при выборе стека для мониторинга и логирования DWH.

Привет, Хабр! Меня зовут Максим Шуматбаев, я инженер технической поддержки в Arenadata. Это вторая часть разбора, что на самом деле происходит при работе клиентских приложений с Kafka-кластером. В первой части мы проследили запись от получения метаданных до транзакций и exactly-once. Теперь очередь второй половины пути: как потребитель получает данные, делит партиции с другими участниками группы, фиксирует прогресс и почему иногда начинает отставать.

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

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

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

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

Ну что может быть сложного? Оказалось — примерно всё.

Семь человек и десятки тысяч событий в секунду. Groot — корневая система Иви: команда работает с данными, которые нужны для рекомендаций, персонализации и обучения ML-моделей. В этом интервью Вова Петухов, руководитель отдела больших данных, рассказал, как ребята собирают real‑time события, строят сервисы поверх хранилищ, вместе учатся на ошибках, радуются, ходят на каток и придумывают стартапы за обедом.

Привет, Хабр. На связи Николай Карасов, ведущий разработчик отдела рекомендаций контентных сервисов в AI VK. Наша команда отвечает за рекомендации в Ленте ВКонтакте.

Перед нами стояла цель — развить внутри ВКонтакте новый пользовательский сценарий: человек приходит за контентом, видит у автора интересный ему товар и переходит к покупке прямо из социальной сети. Так в Ленте появился новый тип объекта — товарный пост. Первым партнёром в этом сценарии стал Ozon. Дальше речь пойдёт именно про товарные посты авторов в рамках реферальной программы Ozon, а не про любые публикации с товарами.

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

С запуском Астры я тянула. Не потому, что не было времени. Просто знала, что стоит запустить и она утянет меня в бездну. Задаешь один вопрос, спрашиваешь, а это можно? И модель выдает такое, что уже не остановиться и часы на экране показывают полночь, а утром на работу. Поэтому я ждала. Еще хотела, чтобы в голове загорелась идея и любопытство, которые уже ничем не сдержать. Так что, когда в пятницу после обеда я почувствовала это, решила, пора. Ровно в пять захлопнула рабочий ноутбук, повернулась к домашнему Маку, справа поставила айпад с чатом GPT, слева - большой стакан воды. Дело предстояло не шуточное. Даже скажем так, сумасшедшее – решили программным путем достучаться до данных Евклида (Euclid) – нового телескопа, висящего в полутора миллионах километров от Земли в районе точки Лагранжа L2, пропустить его данные через новую модель GPT 6 – Astra Extra High и…

Вот это «и» было главным вопросом.

Спор о формате таблиц для lakehouse, похоже, закончился, Iceberg сегодня поддерживают Trino, Spark, ClickHouse, Snowflake и дальше по списку, так что следующим приходится выбирать каталог. Каталог хранит указатель на актуальную версию таблицы, проводит commit и решает, кому эту таблицу читать, поэтому по весу я бы поставил этот выбор рядом с выбором СУБД.

В статье разбираю Lakekeeper, это один бинарник на Rust и обычный Postgres для метаданных, права на OpenFGA до отдельной таблицы и механизм ContractVerification, который может отклонить commit, если тот ломает контракт данных. Для сравнения рядом Apache Polaris, проект фонда Apache на Java с RBAC в два уровня и федерацией внешних каталогов.

В конце описан стек из банковского проекта (RustFS, Lakekeeper с Postgres, SeaTunnel, NiFi, Trino и ClickHouse), который развернули на своём железе за три дня и через три недели вывели в тестовую эксплуатацию.

Сценарий знакомый: открываешь в pandas файл побольше, ноутбук задумывается, и через минуту всё падает с MemoryError. Следом обычно звучит совет: для больших данных есть Spark. Я решил проверить его цифрами, но не на кластере, а на слабой машине с двумя ядрами и 5,8 ГБ памяти.

Сравнил шесть вариантов: pandas, pandas с pyarrow, Polars, Polars в потоковом режиме, DuckDB и PySpark. Пять типовых операций, объёмы от 6 до 180 млн строк, контроль памяти и автоматическая сверка результатов между библиотеками. Эта сверка по дороге нашла баг, из-за которого Spark терял целый день данных.

Кто сдался первым, кто удивил и почему переход на Spark часто не лучший выход, рассказываю под катом.

Считал долю пальмового масла в детском питании, получил 10%, обрадовался сенсации. Потом открыл выборку глазами - и всё поехало. Разбор ложных срабатываний поиска по ключевому слову на базе составов: пальмитат, медь, мускатный орех и другие ловушки.

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

Звучит так, будто привычная модель использования BI действительно начинает терять смысл. Но что именно устаревает - необходимость анализировать данные или наше представление о том, как должна работать аналитическая система?

В этой статье попробуем разобраться.

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

Поэтому при эксплуатации DWH используют инструменты мониторинга и логирования.

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

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

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

До последнего времени в мире IT всё главным образом крутилось вокруг computer science, математики, финансов (статистики) и промышленного дизайна. Однако с появлением LLM этот, вполне себе теплый и камерный мир, где «рыбак рыбака видел из далека», начал стремительно разрушаться. Вначале, появились голосовые помощники и чат‑боты, а теперь это разрослось до новой формы поиска и попыток управления чем‑то (и да же вынесения суждений о чем‑то) в реальном мире с помощью LLM.