#витрины_данных — Public Fediverse posts

После JOIN сумма выросла: как детализация ломает BI-витрину

Отчёт обновился без ошибок. Количество заказов совпало с источником. А сумма оказалась выше, чем до добавления товарных позиций. Можно начать искать дубли в загрузке, но сначала стоит проверить сам JOIN: иногда он совершенно правильно соединяет строки, которые нельзя суммировать вместе. Разберём небольшой учебный пример: три заказа, их позиции и оплаты. Покажу, почему COUNT(DISTINCT) может скрыть проблему, SUM(DISTINCT) — испортить результат, а предварительная агрегация — исправить расчёт только при правильно выбранной детализации. SQL-примеры проверены в SQLite; это разбор логики данных, без привязки к конкретной BI-системе. Разобрать пример

https://habr.com/ru/articles/1095156/

#sql #join #bi #витрины_данных #качество_данных

Данные построчно правильные, а итог неверный: ошибки JOIN и гранулярности в аналитике

Ошибки в аналитических витринах часто скрываются за корректным числом строк и успешно выполненным SQL‑запросом. Разберём, как неправильные JOIN и разный уровень детализации данных искажают суммы, почему DISTINCT не всегда помогает и какие проверки позволяют находить такие проблемы.

https://habr.com/ru/companies/otus/articles/1079620/

#SQL #базы_данных #аналитика_данных #JOIN #PostgreSQL #витрины_данных #качество_данных #ETL #DWH #Data_Warehouse

Тестовое задание на аналитика DWH: 4 задачи с разбором

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

https://habr.com/ru/companies/otus/articles/1067758/

#DWH #SQL #SCD2 #оконные_функции #CDC #дедупликация_данных #моделирование_данных #витрины_данных #темпоральные_данные #контроль_качества_данных

Вчера в отчёте было 12 480, сегодня 12 517: пять причин, по которым цифры за прошлый месяц продолжают меняться

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

https://habr.com/ru/companies/otus/articles/1058824/

#инкрементальная_загрузка #витрины_данных #опоздавшие_события #идемпотентность #дедупликация #event_time #ingested_at #SCD #часовые_пояса #пересчёт_данных

Как мы построили витрины данных из разрозненных микросервисов

Раньше наш способ собрать данные из всех микросервисов в одно место (в витрину) напоминал копролит (только не древний, а наш собственный ИТ-артефакт). Он был сложный, медленный, постоянно ломался и требовал много ручной работы. Данные размазывались по куче баз данных. Чтобы сделать отчёт или отправить данные во внешнюю систему, надо было собирать их вместе. Высока вероятность, что у вас такой же или похожий. Если нет — приходите рассказать «а я же говорил» в комментариях. Мы тратили время на латание дыр, а не на разработку. В какой-то момент решили, что пора выкинуть этот велосипед и внедрить нормальный, промышленный подход к работе с данными — Data Lakehouse с медальонной архитектурой. В чём были наши ошибки: — Спроектировали сложную доменную модель для витрины, которая не соответствовала ни моделям в исходных сервисах, ни требованиям пользователей. Одна таблица из микросервиса могла раскладываться на 5 таблиц в витрине. — Превращали данные из сервисов в эту модель — это был ад. — Схема данных на фронте, в сервисе, в витрине и у потребителя была везде разная. Это постоянные баги из-за того, что кто-то ждёт ID, а ему приходит business_number. — Чтобы отдать данные потребителю, приходилось делать кучу JOIN-ов. Это ломало SLA по производительности. — Любое изменение в схеме БД микросервиса (добавил колонку) требовало сложной доработки витрины. Всё тесно связано и хрупко. — Сервисы писали изменения в свои локальные outbox-таблицы, а отдельный обработчик забирал их и складывал в витрину. Данные из разных сервисов приходили в разное время. Запрос к витрине мог пытаться сджойнить данные о клиенте и его заказе, но данные по заказу ещё не приехали. В итоге потребителю уходило неполное или вообще никакое сообщение. — Разработчики сервисов вместо одного события «Заказ сохранён» генерировали 20 событий на каждое изменение поля в UI. Это забивало очередь и создавало дикую нагрузку. — Тестирование — тоже ад. Для таких ситуаций есть понятный шаблон — трёхслойная архитектура с понятным дата-пайплайном.

https://habr.com/ru/companies/greenatom/articles/1007324/

#витрины_данных #Data_Lakehouse #медальонная_архитектура #архитектура_данных #обработка_данных #доменная_модель #хранилища_данных #Kafka #интеграции

Lakehouse vs Data Warehouse в 2026: что выбирать DE-команде

Привет, Хабр! Выбор между lakehouse и классическим хранилищем остается проблемой не первый год, но к 2026-му накопилось достаточно опыта, чтобы говорить предметно. Разберём, как эти архитектуры устроены под капотом, где каждая реально сильна и почему универсального ответа до сих пор нет. Сравнить подходы

https://habr.com/ru/companies/otus/articles/991128/

#БД #lakehouse #data_warehouse #Spark #объектное_хранилище #витрины_данных

Как в Авито обеспечивают self-service разработки и деплоя витрин

Привет! Меня зовут Николай Огоров, я Big Data-инженер в Авито . В этой статье я и мой коллега Айк Оганесян расскажем, как обеспечили пользователей инструментами, которые дают им возможность самим создавать витрины в хранилище Авито без привлечения специалистов. Эта история больше про подходы, решения и философию, которые позволяют жить в парадигме, когда потребностей на создание объектов DWH стало сильно больше, чем возможностей Data-инженеров.

https://habr.com/ru/companies/avito/articles/968596/

#dwh #selfservice #авито #avito #avitotech #витрины_данных

Atomic insert in Clickhouse

В этой статье мы поговорим о том, как реализовать поведение атомарной вставки в ClickHouse. Рассмотрим несколько вариантов, подсветим их сильные и слабые стороны, а также, когда каждый из них применять.

https://habr.com/ru/articles/969282/

#clickhouse #кликхаус #атомарность #atomic #etl #витрины_данных #insert #sql

Сокращаем трудозатраты при выводе витрин на Hadoop

Привет, друзья! Я Олег Васильев, владелец продукта Dream DE. В этой статье расскажу, как мы научились быстро и эффективно выводить витрины на Hadoop в эксплуатацию, или как мы за один квартал вывели 26 инициатив в рабочую среду силами четырёх инженеров по данным.

https://habr.com/ru/companies/sberbank/articles/954476/

#витрины_данных #hadoop #прототипы

Витрина данных: сверка с эталоном

Одним из этапов разработки витрин данных является тестирование результата и подтверждение корректности разработанного функционала. При этом организовано тестирование может быть по-разному. Определим несколько видов тестирования: 1. Технические тесты Техническими тестами легко можно проверить корректность сборки витрины. Из основных видов технических тестов можно выделить: · Дубли - проверка на наличие дублей по ключу · Разрывы - проверка на разрывы в истории · Перекосы - проверка наложения исторических записей друг на друга · Даты - проверка корректности формирования дат · NULL в ключе - проверка NULL в ключевых и обязательных к заполнению полях Подробно на этих тестах останавливаться не будем, информация по ним есть в открытом доступе. 2. Бизнес-тесты Это набор тестовых запросов, направленных на выявление ошибок в бизнес-данных. Как правило набор бизнес-тестов предоставляет владелец объекта. Бизнес-тестов может быть великое множество, здесь все зависит от вашего бизнес-домена и от конкретных требований к витрине. Приведу примеры некоторых бизнес-тестов:

https://habr.com/ru/companies/neoflex/articles/918628/

#СУБД #витрины_данных #тестирование