ПОТОКОВЫЕ  ETL  ХРАНИЛИЩА  ДАННЫХ  В  РЕАЛЬНОМ  ВРЕМЕНИ

Бегма  Татьяна  Витальевна

студент  6  курса,  кафедры  математических  методов  системного  анализа  ННК  «ИПСА»  НТУУ  «КПИ»,  Украина,  г.  Киев

Е-mail:  tatianitatati00@gmail.com

Селин  Александр  Николаевич

научный  руководитель,  доцент  кафедры  математических  методов  системного  анализа  ННК  «ИПСА»  НТУУ  «КПИ»,  Украина,  г.  Киев

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

Не  так  давно  инженеры  яростно  защищали  понятие,  что  хранилище  данных,  должно  предоставлять  непоколебимой  набор  данных  для  людей  принимающих  бизнес-решения  [1,  c.  4],  обеспечивая  надежную  информационную  основу,  на  которую  можно  положиться.  Вплоть  до  этого  момента  отчетности  мешала  изменчивость  данных,  бизнес-пользователи  обращались  на  производственные  приложения,  на  которых  работал  бизнес.  Таким  образом,  пользователи  должны  были,  создавать  запроси  в  хранилище  данных  для  получения  исторической  картинки  того,  что  произошло  в  бизнесе  по  состоянию  на  вчера  и  приходилось  искать  по  всем  многочисленным  OLTP  системам  для  формирования  картины  того,  что  происходит  сегодня.  Бизнес-пользователи  никогда  полностью  не  примут  этот  разрыв.  Почему  они  не  могут  обратиться  в  одно  место,  чтобы  получить  бизнес  информацию,  которая  им  нужна?

Что  ж,  многое  изменилось,  и  хранилища  данных  теперь  стали  жертвой  собственного  успеха.  Хотя  задержка  между  бизнес-операциями  и  их  появлением  в  хранилище  данных,  как  правило,  меньше,  чем  24  часа,  для  многих  стремительно  развивающихся  организаций  в  отраслях  с  живой  динамикой  изменения  данных,  эта  задержка  слишком  велика  [2,  c.  1].  Тут  хранилище  данных  становится  критически  важным,  слишком  затратным  кормление  ценной  информации  операционным  системам,  которые  затем  используются  для  обработки  операций,  персонализации  приложений,  и  расчета  самых  выгодных  акций.  Тогда  когда  закачка  более  свежей  информации  -  всегда  актуальна.

ETL  хранилища  данных  в  реальном  времени,  по  определению  Ральфа  Кимпбела  [5,  c.  58],  является  неправильным  названием  для  категории  хранилищ  данных,  которые  больше  являются  БД  в  реальном  времени,  чем,  во  многих  случаях,  ETL.  Вместо  этого,  термин  относится  к  программному  обеспечению,  которое  переносит  данные  асинхронно  в  хранилище  данных  с  какой-то  срочностью  в  течении  нескольких  минут  для  выполнения  бизнес-операций.  Во  многих  случаях,  разработка  хранилища  данных  в  режиме  реального  времени  требует  подходов,  весьма  отличающихся  от  методов  ETL  [3,  c.  46],  используемых  в  пакетно-ориентированном  хранилище  данных.  Просто  использование  обычных  пакетов  ETL,  которое  становится  все  более  и  более  частым  в  течение  дня  может  быть  не  практично,  также  как  и  при  использовании  OLTP  систем  в  хранилище  данных.  И  наоборот,  в  том  числе  у  хранилищ  данных  в  OLTP  системах  логика  комитов  (commit)  и  транзакций  также  может  не  работать.  Системы  OLTP  не  могут  позволить  себе  роскошь  в  ожидании  завершения  отработки  транзакций  комита  хранилища  данных  чтобы  начать  обрабатывать  свою  следующую  транзакцию,  так  же  как  и  не  могут  позволить  ожидания  какого-либо  лока  (loking)  или  практику  использования  логики  комитов  с  двухфазной  фиксации  в  системах  с  различной  структурой  и  различными  уровнями  детализации.  Вместо  этого,  большинство  стремится  просто  переместить  новые  транзакции  в  специальный  раздел  в  реальном  времени  (real-time  partition)  из  хранилища  данных  в  котором  некоторые  временные  рамки  считаются  приемлемыми  для  бизнеса,  обеспечивая  аналитическую  поддержку  день-в-день  оперативными  решениями.  В  настоящее  время,  эта  процедура  является  нашим  практическим  определением  ETL  в  реальном  времени.

Хранилища  данных  в  реальном  времени  представляет  ряд  уникальных  задач  и  возможностей  для  инженера  ETL.  С  точки  зрения  технической  архитектуры,  у  него  есть  огромный  потенциал  чтобы  изменить,  подход  большого  взрыва,  необходимый  во  время  ночных  сессий  ETL  нагрузок  Windows,  на  непрерывный  ETL-подобный  поток  на  протяжении  всего  дня  [1,  c.  1].  Требования  к  доступности  системы  могут  усложняться  и  расти  так  как  в  бизнесе  приходится  полагаться  на  наличие  быстрого  ответа  от  бизнес  операций  в  хранилищах  данных.  Если  организация  отдает  предпочтение  подходу  использования  менеджера  в  режиме  реального  времени,  описанном  выше,  доступ  и  наличие  данных  становятся  стратегическим  преимуществом.

С  точки  зрения  архитектуры,  хранилище  данных  в  режиме  реального  времени  сталкивается  с  проблемой  позиционирования  [4,  c.  102],  в  которой  хранилище  данных  представляется  как  система  дискретных  периодических  измерений  —  провайдер  бизнес  снимков  (snapshots)  —  пропагандируя  взамен  систему  комплексной  и  непрерывной  во  времени  информации.  Этот  сдвиг  будет  происходить  незаметно,  если,  например,  частота  загрузки  информации  будет  производиться  не  один  раз  в  день,  а  каждые  15  минут,  но,  в  тоже  время,  разницу  нельзя  будет  не  заметить,  если  загрузка  фактов  и  записей  измерений  будет  происходить  непрерывно.  В  таком  случае  хранилище  данных  может  захватить  данные  бизнес  операции  и  их  контекст  в  каждый  момент  времени.  Медленно  меняющиеся  измерения  становятся  быстро  меняющимися  измерениями,  и  поведение  хранилища  данных  принимает  более  оперативный  характер.  На  самом  деле,  если  хранилище  данных  реального  времени  также  будет  поддерживать  измерения  в  реальном  времени  в  соответствии  с  синхронизацией,  это  тогда  может  превратиться  в  логическое  продолжение  самих  операционных  систем.

От  подхода  режима  реального  времени  к  хранилищам  данных  можно  проследить  четкую  линию  к  тому,  что  изначально  называлось  ODS  (Operational  data  store).  Мотивы  оригинальной  ODS  были  похожи  на  современные  хранилища  данных  в  режиме  реального  времени,  но  реализация  хранилища  данных  в  режиме  реального  времени  отражает  новое  поколение  аппаратных  средств,  программного  обеспечения,  и  аналитических  подходов. 

Некоторые  другие  важные  факторы  вступили  в  сговор  с  целью  заставить  практикующих  хранилищ  данных  переосмыслить  некоторые  более  ранние  основы:  Управление  взаимоотношениями  с  клиентами  (CRM  —  Customer  relationship  management).  Постоянные  требования  CRM  [6,  c.  80]:  современный,  последовательный  и  целостный  образ  клиента,  который  доступен  для  всех  операционных  систем,  которые  непосредственно  или  косвенно  служат  клиент-совсем  —  это  непростая  задача.  Несмотря  на  маркетинговые  требования  ведущих  поставщиков  CRM,  эта  возможность  не  может  быть  приобретена  с  полки;  если  еще  не  все  системы  ориентированные  на  клиента  ушли  в  отставку,  то  они  упакованы  в  CRM  комплект,  предприятия  также  должны  включать  в  режим  реального  времени  все  приложения  с  унаследованными  транзакциями.  Хранилищам  данных,  конечно,  абсолютно  необходимо  постоянная  информация  о  клиентах  из  транзакций  и  об  операционной  деятельности,  но  более  того,  операционные  системы  опираются  на  хранилища  данных  обогащенные  информацией  о  клиентах,  тоже.  Таким  образом,  можно  предсказать,  что  организации  начали  исследовать  архитектурные  альтернативы,  которые  могут  поддерживать  более  обобщенные  интеграционные  сценарии  движущихся  оперативных  данных  между  приложениями  и  синхронно  загружающихся  и  выгружающихся  из  хранилища  данных  с  все  возрастающей  срочностью.

Список  литературы:

1. Томашевский  В.Н.  Математическая  модель  задачи  проектирования  гибридных  хранилищ  данных  с  учетом  структур  источников  данных  [Текст].  Вестник  НТУУ  "КПИ".  Информатика,  управление  и  вычислительная  техника:  Сб.  наук.  пр.  /  Томашевский  В.Н.,  Яцишин  А.Ю.  К.:  Век  +,  —  2011.  —  №  53.  —  211  c.  13.
2. Яцишин  А.Ю.  Применение  генетического  алгоритма  для  проектирования  гибридных  хранилищ  данных  [Текст].  Вестник  Нац.  ун-та  «Львовская  политехника»,  секция  "Информационные  системы  и  сети",  /  Яцишин  А.Ю.  Львов  2011.
3. Fast  Discovery  of  Association  Rules  /  R.  Agrawal  etc.  //  Advances  in  Knowledge  Discovery  and  Data  Mining.  Menlo  Park,  Calif  :  AAAI  Press,  1996.  Chap.  12.
4. Discovery  and  Data  Mining.  Menlo  Park,  Calif.:  AAAI  Press,  1997.
5. Ralph  Kimball.  The  data  warehouse  toolkit:  the  complete  guide  to  dimensional  modeling  [Текст]  /  RalphKimball  Wiley,  2002  —  436  p.
6. Srikant  R.  Mining  Association  Rules  with  Item  Constraints/  R.  Srikant,  Q.  Vu,  R.  Agrawal  //  Proc.  Third  Int’l  Conf.  Knowledge.