Как объединять данные из двух баз в единую модель, например снежинку или звезду

Что проверяют

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

Как отвечать

Идите по шагам моделирования по Кимбаллу:

• бизнес-процесс и зерно: сначала решите, что такое одна строка факта, например одна позиция заказа. Если в одной базе строки по позициям, а в другой по заказам целиком, в одну таблицу их просто так не сложить;
• согласованные измерения: dim_customer, dim_product, dim_date общие для обоих источников. Каждая сущность получает суррогатный ключ хранилища, натуральные ключи источников лежат рядом вместе с колонкой source_system;
• сопоставление сущностей: клиента из двух систем склеивают по нормализованным признакам (email в нижнем регистре, телефон в едином формате, ИНН), неоднозначные совпадения уходят на ручной разбор;
• нормализация значений: валюты, единицы, часовые пояса и справочники статусов приводятся к одной шкале до попадания в факт;
• история: для меняющихся атрибутов решите тип SCD. Тип 2 хранит версии с valid_from и valid_to, тип 1 просто перезаписывает.

Звезда держит измерения денормализованными, запросы проще и быстрее, и в колоночных хранилищах вроде ClickHouse это обычный выбор. Снежинка оправдана, когда у измерения большая иерархия, общая для нескольких витрин.

Стек типичный: сырые данные грузят через Airbyte или CDC на Debezium, оркестрация в Airflow, трансформации и тесты в dbt (unique, not_null, relationships), слои staging, intermediate и витрины.

Где спотыкаются

Джойнят по натуральным ключам источников. Когда в двух базах customer_id = 42 означает разных людей, отчёт тихо смешивает их данные.

Не обрабатывают поздно пришедшие измерения. Факт пришёл, а клиента в справочнике ещё нет, и строка выпадает из INNER JOIN. Решение: запись «неизвестный» с ключом -1 и последующая доработка.

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