Подготовка данных

Рассмотрим банковское хранилище, в котором имеются данные о клиенте, его картах и транзакциях по картам.

Концептуальная схема

Перед тем, как регистрировать данные в приложении, необходимо спроектировать концептуальную схему хранения данных:

Выделить набор сущностей
Определиться с атрибутами сущностей
Определить связи между сущностями

Пример подготовленной концептуальной схемы для нашего примера:

Data Pipeline

Опишем получившиеся сущности:

Клиент - характеристики клиента. Набор ключей определяется Primary keys исходной таблицы, значит ключ будет один - customer_id
Карта - характеристики карты. Ключ - card_id

Атрибуты сущностей по таблицам:

Таблицы CUSTOMER и CARD содержат в себе справочные данные о своих сущностях. Такие данные уже представлены в готовом виде.
Таблица TRANSACTIONS содержит данные о транзакциях по картам, которые предварительно агрегированы до карты в разрезе валюты (currency), торговой категории (mcc_code) и месяца транзакции (transaction_month). Для использования данных в аналитике их потребуется агрегировать в разрезе сущности, т.к. получившаяся структура данных является предагрегатом.

Связи сущностей:

Таблица CUSTOMER_X_CARD является "мостом" между сущностями Клиент и Карта. Она используется для получения информации о картах клиента и наоборот. Тип связи 1:M, где на одного клиента может быть зарегистрировано несколько карт.

Требования к таблицам данных

Следующим этапом будет соотнесение физических данных (таблиц) с их представлениями в приложении.

CUSTOMER

Содержит в себе справочные данные о клиентах банка.

Сущность - Клиент.
Тип загрузчика - загрузчик готовых фичей.

Требования к таблице:

В атрибуте customer_id нет пропусков
Значения customer_id уникальны
Типы данных атрибутов таблицы соответствуют своей природе, например age (возраст) - целое число

Для регистрации загрузчика в WEB-интерфейсе нужно выбрать "Готовые переменные".

CARD

Содержит в себе справочные данные о картах клиента.

Сущность - Карта.
Тип загрузчика - загрузчик готовых фичей.

Требования к таблице:

В атрибуте card_id нет пропусков
Значения card_id уникальны
Типы данных атрибутов таблицы соответствуют своей природе, например expire_date (дата окончания срока действия карты) - дата, card_id - целое число

Для регистрации загрузчика в WEB-интерфейсе нужно выбрать "Готовые переменные".

TRANSACTIONS

Содержит в себе данные о транзакциях по картам.

Сущность - Карта.
Тип загрузчика - загрузчик предагрегатов.

Требования к таблице:

В атрибутах card_id нет пропусков
Типы данных атрибутов таблицы соответствуют своей природе, например transaction_amount (размер транзакции) - decimal. Важно, чтобы card_id имел одинаковую размерность с card_id в таблице CARD: если CARD.card_id - integer, то и TRANSACTIONS.card_id - integer (не varchar и не decimal)

Для регистрации загрузчика в WEB-интерфейсе нужно выбрать "Предагрегат".

CUSTOMER_X_CARD

"Мост" между сущностями Клиент и Карта.

Сущность - поскольку таблица связывает сущности, в ней имеются две полноценные сущности - CUSTOMER, CARD.
Тип загрузчика - загрузчик связи сущностей.

Требования к таблице:

В атрибутах customer_id и card_id нет пропусков
Сочетание атрибутов customer_id и card_id - уникально
Типы данных customer_id и card_id соответствуют типам данных аналогичных полей в таблицах CUSTOMER и CARD

Для регистрации в WEB-интерфейсе нужно выбрать "Связь сущностей"

Общие требования и рекомендации к таблицам

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

В атрибутах ключей не должно быть null-ов
Типы данных полей ключей в таблицах источника должны соответствовать типам данных, которые определены для этих ключей
Согласовывать типы данных одинаковых атрибутов между таблицами, например:
- Размерность полей с плавающей точкой должны быть одинаковой
- Соблюдать порядок целочисленных значений (int, bigint или smallint) для измеряемых значений
Во всех таблицах сущности должны присутствовать атрибуты всех ключей сущности
Нет дублей по ключам для загрузчиков готовых переменных
Если для подготовки данных требуются сложные операции, то их нужно выполнять перед загрузкой в витрины и не вносить внутрь представления:
- Предварительная агрегация
- Сложная фильтрация
- Долгие JOIN-ы

Рекомендации:

Использовать в атрибутах ключей целочисленные типы данных
Не создавать сущности с тремя и более ключами
Не плодить много сущностей - это снизит скорость работы с данными и ухудшит опыт работы с продуктом. Лучше заранее уделить время денормализации витрин и выделении ключевых сущностей. Как правило, порядка 20 сущностей достаточно для сложных банковских хранилищ.
При проектировании сущностей стоит учесть, что приложение будет выполнять все JOIN-ы именно по ключам этих сущностей.
Использовать версионность данных (период актуальности) только там, где необходимо хранить историю. В примере выше это может быть таблица TRANSACTIONS, когда данные поступают регулярно и предварительно агрегируются за конкретный период (например атрибут transaction_amount содержит в себе сумму транзакций за последнюю неделю в разрезе конкретной карты)
Стараться не использовать представления и хранить данные для приложения в таблицах