2.4 Загрузка в реальном времени (Real-Time Loading, eai)

Обычно в системе реального времени транзакции содержат: Бизнес ключи Хаба, отношения (непосредственно сделка), и данные, описывающие транзакцию (или информация в Спутнике Связи). Кроме того, в таких системах данные поступают слишком быстро и слишком «яростные», чтобы тратить время, необходимое, чтоб поместить их в буферную область, попытаться очистить и подготовить к загрузке в хранилище данных. Минута, потраченная на очистку или объединение данных, – это пришедшие в негодность или «умершие» данные, так как транзакция уже была или обновлена, или удалена. В любом случае, захват транзакционных данных в буферную область любого типа является трудным и почти невозможным без некоторого допустимого времени задержки.

Примером транзакции могло быть изъятие (снятие денег со счета) в банкомате, где счет был открыт в 8:00, а изъятие было сделано в 9:00. Транзакция, которая поступит в нашу систему, указывает только номер счета, общую изъятую сумма, дату и время осуществления, и вероятно филиал. Также могло быть указана общее сумма на счете, доступная для снятия. Наиболее вероятно эта транзакция не содержит информации об имени клиента, адресе, или кредитном рейтинге. Эти детали поступят ночным рейсом в главный банковский компьютер, вероятно поздно вечером. Итак, мы должны сохранить номер счета в Хабе, номер клиента в Хабе, а снятие клиентом со счета в таблице Связи, чтобы сделать ассоциацию. Если у нас есть номер филиала, где произошло снятие, то его можно было бы зарегистрировать в таблице Связи как местоположение. Наконец, построить Спутник на связи с общей суммой счета, датой, временем и снятой суммой.

В среде реального времени, ключи будут вытянуты из транзакции, Хаб будет загружен на лету, и таблицы связи заполнены в то же самое время. Наконец наиболее вероятно, что во время загрузки в реальном времени, Спутниковая информация для Связи (детали транзакции) также будет доступна, таким образом, она будет загружена либо одновременно или почти одновременно с родительской таблицей Связи.

Среда реального времени изменяет требования ко времени ожидания / задержки. Обычно там меньший объем для обработки, но и более короткий промежуток времени на загрузку с момента поступления. Если бремя ложится на процессы загрузки, то меньше шансов построить систему реального времени. Другими словами, тяжелая дополнительная работа по обеспечению качества данных, очистка, сопоставление, очистка, и т.д... все вызывает замедление и увеличение времени ожидания, что недопустимо во время загрузки данных в режиме реального времени. В качестве заключительного примера, возьмите любую транзакцию, поступающую в реальном времени (5-секундные обновления). Мы получаем транзакцию, которая «говорит»: вставьте меня, я новая. Наши правила запрещают данным попадать в хранилище – таким образом, процесс загрузки строки терпит неудачу и она помещается в плоский файл, затем мы получаем оповещение о необходимости исправления ошибки, прежде чем эти данные смогут попасть в хранилище.

Если нам требуются 5 минут, чтобы исправить данные и 5 минут, чтобы перезагрузить их, то к тому времени, когда мы исправили и перезарядили их, мы получили дополнительные данные транзакциях, которые за это время были либо обновлены, либо удалены. Мы опять отстаем. Архитектура загрузки, спроектированная подобным образом, не будет работать в режиме реального времени. К сожалению, выбранные модели данных убеждают нас в этом мнении и этих парадигмах. Использование Data Vault поможет предотвратить некоторые из этих катастрофических результатов в ходе цикла загрузки.