Якість інформації: від очищення даних - до моделі підприємства

АНАЛІЗ ДАНИХ

Чистота - запорука + або Ми - заручники +

Продовження. Початок див. PC Week / RE, № 32/2002, с. 20, № / 2002, с. 26.

Трирівнева модель обробки інформації

Дійсно, на шляху "реал-тайму" стоять редути "клінсінгов" і "Стейджінг" * 1, де інформація очищається, узгоджується, наводиться до необхідного виду. Це як шлях по воді від Углича до Москви - суцільні шлюзи.

_____

* 1. Cleansing - процес очищення даних перед завантаженням в сховище даних. Staging area - місце скупчення сухопутних військ перед посадкою на судна або літаки; в області інформаційних технологій означає проміжний технологічний буфер, в якому накопичуються дані з різних джерел, які очікують очищення і узгодження. Після виконання цих процедур staging area, як правило, очищаються.

Існують різні стратегії очищення. В одній з найбільших американських клірингових компаній правила контролю коректності даних різного ступеня складності згруповані в кілька рівнів. Перш за все надходить в систему інформація про операції з цінними паперами піддається перевіркам, які вимагають мінімальних обчислювальних ресурсів, - наприклад, перевіряється наявність позитивних числових даних в поле "Сума". На черговому рівні перевіряються права учасників на вчинення правочину. Кожен наступний рівень все більш вимогливий до ресурсів, але все більше і ймовірність того, що ці ресурси не будуть витрачені на обробку некоректних даних.

Для аудиту, очищення та узгодження даних часто застосовуються спеціальні програмні засоби (див: www.metagenix.com, www.evokesoft.com), що дозволяють в автоматичному і напівавтоматичному режимі збирати метадані з оперативних джерел, узгоджувати між собою їх структури, виявляти залежності в " сирих "даних (raw data) * 1, генерувати правила якості (quality rules) і контролювати їх виконання.

_____

* 1. "Сирими" прийнято називати дані на вході в технологічний цикл поповнення сховища даних.

Для забезпечення якості даних активно використовується математичний апарат, в тому числі статистика. Ральф Кімбелл [2] пропонує використовувати нормальний розподіл для оцінки достовірності інформації про продажі, щодня надходить в центр з сотень невеликих магазинів. Накопичуючи для кожного магазину інформацію про продажі в різні моменти часу, можна оцінити математичне сподівання обсягу продажів. Відомо, що для нормального розподілу 99% величин буде лежати в межах трьох середніх квадратичних відхилень від математичного очікування. Використовуючи цю властивість, можна відкинути слабо змінюються показники, залишаючи в області розгляду лише ті з них, які змінюються кардинально. Такі показники повинні додатково перевірятися.

У міру накопичення досвіду обробки "сирих" даних і збільшення вимог до якості інформації кількість буферних зон і складність алгоритмів перевірки може зростати. У деяких випадках дані не просто виключаються з розгляду, а коригуються з допомогою вже наявної інформації. У компанії, яка займається страхуванням комерційних ризиків, від клієнтів надходить інформація про щорічні виплати за страховками. При контролі аналізуються виплати по роках, і в разі виявлення відсутніх або помилкових даних вони заповнюються за допомогою раніше отриманих фрагментів. Так, якщо в 2000 р клієнт передав інформацію про виплати 1999 го, а в 2001-му цей блок виявився втраченим, система намагається відшукати в архіві 2000 року і заповнити відсутні дані.

Серед калейдоскопа використовуваних технологій і принципів очищення даних, мабуть, один можна вважати універсальним: процеси очищення необхідно розташовувати якомога ближче до оперативного джерела. Настільки близько, що деякі методики оцінки віддачі від інвестицій (Return On Investment, ROI) рекомендують відносити роботи по збільшенню якості "сирих" даних на бюджети оперативних джерел.

На практиці це не завжди дотримується. Внесення змін до оперативні джерела в інтересах інтелектуальної інфраструктури (ІІ) є серйозною проблемою для архітекторів сховищ даних. Якщо стикаються інтереси розробників операційної системи і сховища даних, як правило, пріоритет віддається першим. Особливо часто подібна ситуація зустрічається в банківському секторі, де ціна будь-якого збою в роботі може у багато разів перевищити вартість проекту зі створення самої вишуканої ІІ. Тому там широко поширена мова програмування Кобол.

Але за можливість внесення змін в оперативні джерела доводиться платити. Необхідність настройки, виконання та супроводу складних операцій очищення і узгодження даних значно підвищує вартість проекту. Ці процедури знижують оперативність поповнення сховища даних інформацією. Крім того, якщо дані коригуються на етапі транспортування в сховище, в компанії будуть співіснувати, як точно помітили фахівці Teradata, "дві версії правди": одна - в оперативному джерелі, інша - в сховище даних. Таке роздвоєння може стати постійним джерелом конфліктів і негативно вплинути на культуру компанії.

"Чистилище" даних

Після проходження тестів дані потрапляють в оперативне сховище (Operation Data Store, ODS) або безпосередньо в сховище даних. Часто ODS використовується для побудови вітрин даних та надання інформації для оперативного аналізу. Але основне його завдання - накопичення даних, збудованих у вигляді тимчасові / г зрізів. Справа в тому, що оперативні джерела описують послідовність подій. Причому щільність опису в часі вкрай нерівномірна і залежить від ступеня важливості процесу або його етапів з точки зору оперативного управління. Крім того, і деталізація відображення процесів в часі в різних оперативних джерелах може відрізнятися.

У сховищі ж даних діяльність відображена у вигляді послідовності "миттєвих" знімків, зроблених в різні моменти часу. Таке подання інформації відповідає інтересам стратегічного управління і аналізу даних. Тому дані при перевантаженні в сховище представляються у вигляді тимчасові / г зрізів.

Формування "миттєвого" знімка може займати досить тривалий час. Бив Інмона писав, що в той момент, коли дані стануть повністю узгодженими і абсолютно якісними, вони вже нікому не будуть потрібні. Виявивши дані на етапі перевірки, ми тим самим порушили цілісність тимчасово / го шару. Для його відновлення необхідно очікувати виправлення даних в джерелах і завантажити цю. На це часом йдуть тижні і місяці. Адже первинні дані можуть збиратися по віддаленим філіям, з якими зв'язок менш оперативна, і неважливо, чи є засобом доставки коні в степах Калмикії або всюдиходи в Уренгої, головне - ми не отримаємо виправлень о 24 годині, а тим більше в реальному часі. Тому потрібно шукати компроміс між оперативністю подання даних і їх якістю.

Інше завдання, для вирішення якої використовується ODS, - формування "дельти поновлення". У ODS накопичуються зміни, що становлять різницю між актуальним станом господарської системи і тим, яке відображено в сховище даних. Дані "дельти поновлення" лише доповнюють історичну картину господарської діяльності новим "миттєвим" знімком. Такий підхід дозволяє максимально актуалізувати інформацію в сховище даних з мінімальними витратами. Однак він вимагає введення додаткових ідентифікаторів шарів в структури таблиць ODS і оперативних джерел, що не завжди можливо.

На закінчення розмови про ODS відзначимо, що воно відіграє найважливішу роль у приведенні даних до єдиної семантичної структурі сховища та структурі параметрів моделі підприємства. ODS, як і "чистилище", відкриває даними нові шляхи застосування.

Модель - не імітація, а засіб управління

Ми вже побіжно згадували поняття "модель підприємства", але не приділяли йому належної уваги. Що ж це таке? В роботі [3] пропонується розглядати три перспективи ІІ: концептуальну, логічну і фізичну. Концептуальна перспектива найбільш абстрактна і описується в термінах предметної області. Логічна перспектива відображає концептуальну в термінах реляційної багатовимірної або будь-якої іншої методології проектування. Фізична перспектива описує реалізацію відповідної логічної моделі в контексті конкретних інструментальних засобів.

"Припустимо, що аналітик або керуючий хоче мати якусь інформацію про бізнес. У нього немає можливості отримати її безпосередньо. Він повинен спиратися на зібрану і агрегированную інформацію. В цьому випадку ми не застраховані від того, що інформація дасть картину, що не адекватну що відбувається. Компенсувати це можна лише методично обґрунтованою системою обробки інформації у відповідних перспективи ІІ - від вибірки, очищення та завантаження даних в сховище аж до її агрегації і доставки до користувача ". Центром такої концептуально витриманою ІІ є модель підприємства. "Решта моделі визначаються як її проекції" [3].

Пропонуються різні методології побудови моделі підприємства. У продукті Oracle Financial Services Application (OFSA) компанії Oracle, призначеному для автоматизації банківської діяльності, застосовується підхід, заснований на подвійному записі і принципі збереження балансу для відображення фінансового стану предпріятія.Куби OFSA відповідають рахункам бухгалтерської Головною книги. Але їх багатовимірна аналітична структура визначається потребами користувачів і поповнюється безпосередньо з оперативних додатків. Таким чином, подвійний запис забезпечує узгодженість кубів між собою, а багатовимірна аналітика відповідає потребам користувачів. У своїй практиці наша компанія також застосовує балансовий підхід і для ведення управлінського обліку, і для автоматизованої підтримки процесів продажів і постачання на підприємствах [4, 5].

Фахівці компанії SAP при розробці кубів Business Warehouse (BW) в рамках інфраструктури стратегічного управління підприємством (Strategic Enterprise Management, SEM) спиралися на структуру ключових показників (КП) добре знайомої вже багатьом системи збалансованих показників (Balanced Score Card, BSC). Сукупність КП - це також модель, що відображає господарську діяльність підприємства і забезпечує управління ім. Проектуючи структуру кубів з урахуванням найкращого способу формування значення КП, можна домогтися максимальної якості інформації в концептуальної, логічної та фізичної перспективі ІІ.

У цьому полягає активна роль моделі підприємства, яка забезпечує підтримку прийняття рішень і контролю за їх виконанням. На закінчення зазначимо, що активна функція моделі підприємства посилює вимоги до оперативності інформації в сховищах даних. В роботі [6] автори відзначають, що оперативність збору інформації про значення КП "грає вирішальну роль, коли організація намагається заохотити службовців і закріпити позитивні тенденції в їх поведінці". Повільна зворотний зв'язок, на їхню думку, може стати причиною відмови від BSC.

З оптимізмом на ситуацію дозволяє дивитися те, що, за твердженням Дугласа Хекні, "вже сьогодні ми маємо інструменти і технології, які дозволяють отримати можливості OLTP, ODS і сховищ даних в єдиній базі даних" [7]. Але без вирішення питань якості даних, побудови оптимальної моделі підприємства і єдиної структури бізнес-контенту ці інструменти лише вгамують наше професійна цікавість, а для вирішення нагальних проблем бізнесу опиняться марні.

література

1. PC Week / RE, № 32/2002, 33/2002.

2. Ralph Kimball. Is Your Data Correct ?. http://www.intelligententerprise.com/001205/webhouse1_1.shtml.

3.Matthias Jarke, Manfred A. Jeusfeld, Cristoph Quix, Panos Vassiliadis. Architecture and Quality in Data Warehouse. http://www.dbnet.ece.ntua.gr/~dwq/publications.html.

4. Аксьонов Є. Поганий той менеджер // PC Week / RE, № 3/2001, с. 23.

5. Нікітіна Н., Гараева Ю., Юдкін Ю. Системи-трансформери: у пошуках оптимального ступеня свободи // PC Week / RE, № 19/2002, с. 24.

6. Ши-Джен Каті Хо, Мак-Кей Рут. Два погляди на збалансовані показники. http://www.consulting.ru/main/mgmt/texts/m14/183_cpa.shtml.

7. Hackney D. Data Warehouse Delivery: The Future is Now // DMReview, 2002 December.

Версія для друку

Тільки зареєстровані користувачі можуть залишати коментарі.