Big Data *

Привет! Меня зовут Маргарита, я BI-архитектор в Далее. Моя задача — чтобы клиенты получали подготовленные данные в удобном для них виде. В этом мне помогает dbt (Data Build Tool).

Раньше мы использовали локальную версию dbt, а с прошлого года перешли на внутреннюю веб-платформу SubQuery. Теперь все задачи я делаю в одном окне, и на ту же работу уходит заметно меньше времени: по моим ощущениям, в 2-3 раза.

Возможно, этот обзор будет полезен коллегам, которые тоже работают с данными. Первое, к чему я быстро привыкла, — результат SQL-запроса модели dbt можно посмотреть сразу в превью. Не нужно отдельно открывать СУБД  и проверять данные на корректность выполненного SQL.

После крупного инцидента SaaS-компании приходится отвечать на неудобный вопрос: кто заметил проблему первым — мониторинг или клиенты? У команды Atlassian долгое время не было однозначного ответа. Команда VK Tech перевела статью о том, как небольшая команда перестроила платформу обнаружения инцидентов на Apache Kafka, Apache Flink в Kubernetes и OpenTelemetry. На этой платформе работает AutoHOT — система автоматического создания инцидентов высокой серьёзности. Авторы рассказывают об архитектурных решениях, показателях, которые отслеживали ежемесячно на протяжении восемнадцати месяцев, и о том, что сделали бы иначе.

Результаты оказались неоднозначными. Доля обнаруженных реальных инцидентов среди тех, которые охватывает мониторинг, выросла примерно с 60% до 86% на пике, но в неудачный месяц снова упала до 64%. Точность — доля срабатываний, оказавшихся настоящими инцидентами, — по-прежнему ниже, чем хотелось бы авторам. Они приводят цифры и разбирают ограничения системы, включая пропущенные инциденты и ложные срабатывания.

Статья адресована тем, кто строит потоковый мониторинг на Kafka и Flink и хочет учесть ошибки авторов при проектировании собственной системы.

Можно ли разложить 15+ млн хаотичных товаров по 1100 категориям за месяц? Да – без зубодробительного ML и миллионных затрат на LLM-инференс!

В статье о том, как:

1. ML проиграл системе простых бизнес-правил;

2. мы присвоили артикулы товарам для целой отрасли;

3. заставить работать даже самые зашумлённые данные из CRM.

В статье разбираем, как устроен Apache Airflow 3, для каких задач он используется, какую роль играет в архитектуре DWH и BI, и когда его стоит выбирать для оркестрации процессов обработки данных. Сравниваем с Prefect и Dagster.

Привет, Хаброжители! Мы подготовили для вас новый перевод статьи о контрактах данных. Здесь рассмотрены контракты данных на основе объектов, реализованные на базе CDC. Рассказано, каково определение контракта, как он выполняется, и как для него предписывается схема.

Команда Data в Cloudflare рассказывает, как держит под контролем конвейер данных, через который идёт около двух миллиардов событий в секунду, пока трафик растёт экспоненциально, а железо линейно. Пять шагов за пять лет: разбор монолитной схемы (−35–40% трафика), замена LZ4 на zstd (−40% сжатого трафика), поздняя репликация вместо двойной записи (−36 ГБ/с), двойное сэмплирование (−25 ГБ/с, 2 ПБ в сутки) и агрегации по всему конвейеру (−80% на HTTP-наборе). С графиками и цифрами по каждому шагу.

Про Iceberg сейчас много чего понаписано. Либо обзор «формат будущего, открытость, лейкхаус», после которого непонятно, где нажать, либо разбор одного механизма — снимки отдельно, каталог отдельно, права отдельно. Iceberg плохо объясняется словами, поэтому я собрал стенд, где все части уже соединены и поднимаются одной командой. Trino, каталог Lakekeeper, права в OpenFGA через OPA, вход через Keycloak, S3 на RustFS, а из инструментов нужен только DBeaver. В статье — путь одного запроса через все компоненты, снимки и откат таблицы, права мышкой и обслуживание таблиц с рекомендациями для рабочей системы.

В DWH требовалось организовать приём событий пользовательского поведения из RabbitMQ и предоставить команде e-commerce доступ к ним с задержкой не более пяти секунд. Под задержкой далее понимается интервал между публикацией сообщения в RabbitMQ и доступностью соответствующей записи для запроса в ClickHouse.

В исходных именах таблиц и представлений используется термин customer tracking. В данной статье он обозначает события взаимодействия пользователя с платформой интернет-магазина: просмотры и переходы, поисковые запросы, операции с корзиной и действия в мобильном приложении. То есть термин clickstream events.

Сразу было принято решение записывать в отдельные таблицы:

1. исходные сообщения в виде JSON-логов — для диагностики, аудита преобразований и повторного разбора;

2. типизированные колонки — для аналитических запросов без регулярного парсинга JSON.

П.1 обеспечивает независимость от команды разработки платформы интернет-магазина и защищает (во всяком случае частично) обработчик очереди от

Ограничение в пять секунд относится к конвейеру целиком. В представленной конфигурации значение rabbitmq_flush_interval_ms = 4000 резервирует до четырёх секунд для формирования пакета на стороне RabbitMQ-движка. Однако само по себе оно не гарантирует соблюдение end-to-end SLA: в измерение также входят публикация в брокер, доставка сообщения, обработка Materialized View и вставка в целевую таблицу. Поэтому фактическое соблюдение требования следует контролировать по метрикам задержки между временем публикации и временем доступности данных в ClickHouse.

Просто стало интересно — что такое описательный анализ. Математический анализ, функциональный анализ знаю. А описательный?

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

Как теоретическую основу я использовал идеи из следующих источников:

Process Mining — Ван дер Аалст, «Process Mining: Data Science in Action (2016). Методология извлечения знаний о процессе из логов событий.»

EDA (Exploratory Data Analysis) — Тьюки, 1977. Принцип: сначала смотреть на данные, потом строить модели.

Lean Six Sigma — DMAIC (Define, Measure, Analyze, Improve, Control). Стандартная методология улучшения процессов.

Я не применяю всех методов, описываемых в Process Mining: Data Science in Action. Для данного анализа достаточно понимать, что наука о данных — это, в частности, превращение данных в реальную ценность.

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

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

Когда говорят о Neo4j, чаще всего вспоминают social networks, fraud detection, recommendation systems или knowledge graphs.

Но графовая база может быть полезна и внутри обычного data engineering проекта, где уже есть Kafka, аналитическая база, dbt, Airflow и BI.

Мне было интересно проверить именно этот сценарий.

Допустим, мы запустили АБ‑тест, рандомизировали клиентов, и теперь хотим оценить эффект фичи на средний чек. Средний чек — это пример ratio‑метрики или метрики отношения: считаем отношение суммы покупок к их количеству. Как анализировать эффект на такую метрику?

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

В этой статье разберём, как с этим работать: корректно считать эффект, дисперсию, p‑value и доверительный интервал. Придём к дельта‑линеаризации, которая позволяет сравнивать исходный средний чек через привычный поюзерный тест. Заодно разберём, как использовать CUPED с дельта‑методом, и покажем связь с OLS с кластерными ошибками.

На прошлой неделе я перенес форк 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.