Технологические проблемы
Технологические проблемы берут начало от используемых систем. Мы переходим от сбора данных о завершенных транзакциях (когда клиенты подтвердили факт доставки, покупки или иного пути получения чего-либо) к сбору данных о планируемых транзакциях (когда действия клиента отслеживаются через механизмы на подобии Web clicks или RFID). Данные поступают уже не только из традиционных источников и в традиционных форматах, например, в виде баз данных или текстовых файлов, но все более и более во множестве разнообразных форматов (от файлов с патентованным форматом и документов Microsoft Office до XML файлов) и из источников, основанных на интернет технологиях (например, Web-сервисы или потоки RSS (Really Simple Syndication). Вот наиболее типичные возникающие при этом проблемы:
- Множественные источники с различными форматами данных.
- Структурированные, частично структурированные и неструктурированные данные.
- Порции данных от разных источников доставляются в разное время.
- Огромный объем данных.
В идеальном случае даже если мы каким-то образом сумеем собрать все эти данные в одном месте, то перед нами тут же возникнут новые проблемы. А именно:
- Качество данных.
- Необходимость понимать различные форматы данных.
- Преобразование данных в формат понятный бизнес-аналитикам.
Опять предположим, что каким-то волшебным способом мы справились с задачей сбора данных и можем эти данные очистить, преобразовать и отобразить в нужном нам формате. По-прежнему существует отступление от традиционных способов перемещения и интеграции данных. Это отступление выражается в переходе от фиксированных длительных пакетно-ориентированных процессов к изменчивым и коротким процессам, запускаемым по требованию. Пакетно-ориентированные процессы обычно работали в часы "простоя", когда нагрузка на систему со стороны пользователей мала. Обычно это заранее определенное "окно" в 6-8 часов в ночное время, когда не предполагается наличие кого-либо на рабочем месте. Но в условиях глобализации всех видов и типов бизнеса такое предположение уже не является неоспоримым. Время простоя системы становится малым или вообще исчезает, поскольку кто-нибудь из работников всегда находится на рабочем месте где-то по всему миру. Другими словами в глобальном бизнесе больше нет понятия конец рабочего дня. В результате чего мы имеем:
- Увеличенную потребность в скорейшей загрузке данных.
- Потребность в одновременной загрузке во множество приемников данных.
- Множество приемников данных.
Все перечисленное выше нам не только предстоит сделать, но предстоит сделать наиболее быстрым способом. В особо "тяжёлых" случаях, например, в онлайн бизнесе существует необходимость в непрерывной интеграции данных. В таком бизнесе не существует временных "окон" для пакетной обработки и время ожидания данных не может превышать нескольких минут. Во многих подобных системах процесс принятия решения автоматизирован с помощью программного обеспечения с непрерывной обработкой.
Масштабируемость и производительность становятся все более и более важными в тех сферах бизнеса, которые не могут позволить себе и малейшего времени простоя.
Без подходящей технологии система почти на каждом этапе процесса работы с хранилищем данных и интеграции данных нуждается в дополнительных действиях над данными. При использовании в ETL (Extract, Transform, and Load - система извлечения, преобразования и загрузки данных) различных (особенно нестандартных) источников данных, а также при сложных манипуляциях с данными (например, при data mining - нахождении трендов), потребность в дополнительной обработке данных возрастает. Как показано на Рисунке 1, с увеличением дополнительных этапов обработки данных возрастает и время "закрытия цикла" (т.е. время на анализ новых данных и выполнения действий над новыми данными). Традиционные архитектуры ETL (как противоположность "чистым" ETL процессам, т.е. происходящим до загрузки данных) накладывают серьёзные ограничения на способность системы соответствовать возникающим потребностям бизнеса.
Рисунок 1
И, наконец, вопрос о том, как проблема интеграции данных влияет на общую архитектуру интеграции предприятия становится более значимым,
когда одновременно требуется применять как транзакционную технологию интеграции приложений реального времени, так и пакетно-ориентированную высокообъемную технологию интеграции данных для решения бизнес проблем предприятия.