Базы данных - MySQL - статьи

         

Технологические проблемы


Технологические проблемы берут начало от используемых систем. Мы переходим от сбора данных о завершенных транзакциях (когда клиенты подтвердили факт доставки, покупки или иного пути получения чего-либо) к сбору данных о планируемых транзакциях (когда действия клиента отслеживаются через механизмы на подобии Web clicks или RFID). Данные поступают уже не только из традиционных источников и в традиционных форматах, например, в виде баз данных или текстовых файлов, но все более и более во множестве разнообразных форматов (от файлов с патентованным форматом и документов Microsoft Office до XML файлов) и из источников, основанных на интернет технологиях (например, Web-сервисы или потоки RSS (Really Simple Syndication). Вот наиболее типичные возникающие при этом проблемы:

  • Множественные источники с различными форматами данных.
  • Структурированные, частично структурированные и неструктурированные данные.
  • Порции данных от разных источников доставляются в разное время.
  • Огромный объем данных.

В идеальном случае даже если мы каким-то образом сумеем собрать все эти данные в одном месте, то перед нами тут же возникнут новые проблемы. А именно:

  • Качество данных.
  • Необходимость понимать различные форматы данных.
  • Преобразование данных в формат понятный бизнес-аналитикам.

Опять предположим, что каким-то волшебным способом мы справились с задачей сбора данных и можем эти данные очистить, преобразовать и отобразить в нужном нам формате. По-прежнему существует отступление от традиционных способов перемещения и интеграции данных. Это отступление выражается в переходе от фиксированных длительных пакетно-ориентированных процессов к изменчивым и коротким процессам, запускаемым по требованию. Пакетно-ориентированные процессы обычно работали в часы "простоя", когда нагрузка на систему со стороны пользователей мала. Обычно это заранее определенное "окно" в 6-8 часов в ночное время, когда не предполагается наличие кого-либо на рабочем месте. Но в условиях глобализации всех видов и типов бизнеса такое предположение уже не является неоспоримым. Время простоя системы становится малым или вообще исчезает, поскольку кто-нибудь из работников всегда находится на рабочем месте где-то по всему миру. Другими словами в глобальном бизнесе больше нет понятия конец рабочего дня. В результате чего мы имеем:


  • Увеличенную потребность в скорейшей загрузке данных.
  • Потребность в одновременной загрузке во множество приемников данных.
  • Множество приемников данных.


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

Масштабируемость и производительность становятся все более и более важными в тех сферах бизнеса, которые не могут позволить себе и малейшего времени простоя.

Без подходящей технологии система почти на каждом этапе процесса работы с хранилищем данных и интеграции данных нуждается в дополнительных действиях над данными. При использовании в ETL (Extract, Transform, and Load - система извлечения, преобразования и загрузки данных) различных (особенно нестандартных) источников данных, а также при сложных манипуляциях с данными (например, при data mining - нахождении трендов), потребность в дополнительной обработке данных возрастает. Как показано на Рисунке 1, с увеличением дополнительных этапов обработки данных возрастает и время "закрытия цикла" (т.е. время на анализ новых данных и выполнения действий над новыми данными). Традиционные архитектуры ETL (как противоположность "чистым" ETL процессам, т.е. происходящим до загрузки данных) накладывают серьёзные ограничения на способность системы соответствовать возникающим потребностям бизнеса.

Рисунок 1

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

когда одновременно требуется применять как транзакционную технологию интеграции приложений реального времени, так и пакетно-ориентированную высокообъемную технологию интеграции данных для решения бизнес проблем предприятия.


Содержание раздела