Вивчаємо платформу розширеної аналітики: Частина 6. Координація SPSS, Operational Decision Management (ODM) і Streams на прикладах рішень для проблем використання і боротьби з шахрайством

1. Серія контенту:
2. Цей контент є частиною серії: Вивчаємо платформу розширеної аналітики
3. Малюнок 1. Компоненти AAP, що використовують шаблони Discover, Detect, Decide, Drive
4. Варіанти використання D4
5. Варіант використання No Fault Found (несправність не знайдено)
6. Малюнок 2. Потік для варіанту використання NFF
7. Discover
8. Detect
9. Таблиця 1. Приклад типів даних для моніторингу та початкової фільтрації
10. Decide
11. Drive
12. Малюнок 3. Приклад дерева несправностей пристроїв
13. Варіант использование Fraud (шахрайство)
14. питання дизайну
15. Інтеграція Streams з SPSS
16. Інтеграція Streams з ODM
17. Таблиця 2. Опис продуктів і технологій IBM, що мають відношення до варіантів використання, описаним в статті
18. Висновок і подальші плани
19. Ресурси для скачування

Вивчаємо платформу розширеної аналітики

Шаблони для швидкого виявлення та запобігання проблем в даних високій швидкості

Серія контенту:

Цей контент є частиною # з серії # статей: Вивчаємо платформу розширеної аналітики

http://www.ibm.com/developerworks/library/?sort_by=&show_abstract=true&show_all=&search_flag=&contentarea_by=Big+data+and+analytics&search_by=Explore+the+advanced+analytics+platform&product_by=-1&topic_by=-1&industry_by=- 1 & type_by = All + Big + data + and + analytics + Types & ibm-search = Search

Слідкуйте за виходом нових статей цієї серії.

Цей контент є частиною серії: Вивчаємо платформу розширеної аналітики

Слідкуйте за виходом нових статей цієї серії.

Стаття продовжує серію, присвячену платформі розширеної аналітики (AAP). У попередніх статтях описувалися наскрізна архітектура і високорівневі варіанти використання платформи. Також обговорювалися шаблони для текстового і геопространственного аналізу. Продовжимо серію розглядом шаблону D4 і його використання на платформі AAP.

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

Відповідний шаблон, який дозволяє виконати вищевказаний аналіз і швидко відреагувати на нього, називається D4 (Discover, Detect, Decide, Drive). Шаблон D4 на верхньому рівні складається з наступних частин:

• Discover (виявлення) - ідентифікує нові закономірності за допомогою багатого набору засобів аналізу. Потім ця інформація може надаватися у вигляді бізнес-правил, прогнозних моделей, моделей визначення аномалій і моделей об'єктного аналізу. Ці моделі готові до розгортання в операційних системах в режимі реального часу і близькому до реального часу, а також в пакетному режимі.
• Detect (визначення) - запускає процеси аналізу, використовуючи інформацію, отриману під час виявлення. У міру появи в бізнес-процесі (в режимі реального часу) закономірності розпізнаються і позначаються для подальшого дослідження відповідної групою і виконання практичних дій.
• Decide (рішення) - виконує і координує глибокі запити до виявлених закономірностей для прийняття рішення. Етап Decide включає в себе процес управління для перевірки нових правил, моделей і контрольних списків, критично важливих для петлі зворотного зв'язку, що сприяє виконанню динамічних змін.
• Drive (дія) - виконує відповідну дію для знайденої закономірності. Ці дії часто вимагають використання систем управління діями, зовнішніх по відношенню до AAP. Результати виконання цих практичних дій зазвичай повертаються в AAP, тому процес виявлення вдосконалюється за рахунок подальшого уточнення описаних вище моделей.

На малюнку 1 показані ключові компоненти AAP, що використовують атрибути Discover, Detect, Decide і Drive Пронумеровані мітки пов'язують атрибути шаблону D4 з платформою AAP: 1 = Discovery, 2 = Detect, 3 = Decide, 4 = Drive.

Малюнок 1. Компоненти AAP, що використовують шаблони Discover, Detect, Decide, Drive

Далі будуть розглянуті два варіанти використання шаблону на прикладі чотирьох шаблонів.

Варіанти використання D4

Представлені в цій статті варіанти використання типові для багатьох галузей.

• У першому варіанті розглядається випереджаюче обслуговування мобільних телефонів з використанням шаблону D4 в рамках платформи AAP. Аналогічне рішення можна поширити на інші галузі, де будь-які пристрої або активи повинні бути керованими.
• У другому варіанті описується ефективна боротьба з шахрайством з використанням шаблону D4. Розглядається випадок шахрайства в телефонній компанії, але оскільки ця проблема характерна і для таких галузей, як банки, роздрібна торгівля і страхування, пропоноване рішення можна використовувати і в інших областях.

У першому варіанті наводиться інформація про використання шаблону. У другому наводиться високорівневе опис використання шаблону з поясненням його застосування в інших варіантах використання.

Варіант використання No Fault Found (несправність не знайдено)

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

Для варіанту використання No Fault Found (NFF) ми спростимо процес, щоб показати, як CSP обробляє великий обсяг даних, що надходять від різних мобільних телефонів. Часто CSP стикаються з ситуацією, коли клієнти дзвонять в службу підтримки і стверджують, що в їх пристрої з'явилися проблеми. У більшості випадків це проблеми не самого пристрою, а його використання клієнтом (наприклад, зміна налаштувань клієнтом або перегляд програм, які на пристрої). Найчастіше CSP не можуть вирішити ці проблеми і змінюють клієнтам телефони, несучи непотрібні витрати на випуск нових. Варіант NFF дозволяє CSP завчасно реагувати на подібні проблеми, швидко аналізуючи дані мобільного телефону і виконуючи відповідні бізнес-процеси для запобігання непотрібного повернення мобільних телефонів.

Високорівнева потік для цього варіанту використання (див. малюнок 2 ) Описаний нижче:

1. Зонди, що виконуються в мережі CSP, накопичують інформацію про параметри пристрою і поведінці мережі, яку можна фільтрувати і об'єднувати на апаратному рівні для підвищення продуктивності. Дані мережі доповнюються даними пристрої, які надходять від агентів, що виконуються на мобільному телефоні.
2. Запускаються прогнозна модель і модель визначення аномалій для створення короткого списку потенційно несправних телефонів.
3. Система управління бізнес-процесами виконує відповідні бізнес-процеси для створеного на кроці 2 списку, щоб виправити проблему або запобігти потенційно можливі проблеми.
4. Мобільний пристрій користувача оновлюється або користувач отримує повідомлення про дії, необхідні для виправлення існуючих або потенційних проблем.

Малюнок 2. Потік для варіанту використання NFF

Далі описується застосування шаблону в варіанті використання NFF :

Discover

Discover - це процес ідентифікації нових закономірностей за допомогою багатого набору засобів аналізу. Ці кошти призначені для дослідження конкретних проблем пристроїв, ідентифікації нових проблем, які не були виявлені раніше, і проблем, які здаються пов'язаними з пристроєм, але не є такими. Потім ця інформація може надаватися у вигляді бізнес-правил, прогнозних моделей, моделей визначення аномалій і моделей об'єктного аналізу для виявлення проблеми устрою. Ці моделі готові до розгортання в операційних системах в режимі реального часу і близькому до реального часу, а також в пакетному режимі для подальшого виявлення проблеми устрою. Для телефонів ідентифікуються різні закономірності, включаючи погіршення якості обслуговування з часом, проблеми перезавантаження і проблеми конкретного пристрою, наприклад ресурс батареї.

Дані для цих моделей можна отримати з різних джерел, приклади яких наведені нижче:

• Подання мережі про активність використання
• Дані про конкретний пристрої від сторонніх постачальників.
• Дані передплатників з систем CRM і записи центрів обробки викликів.

Дані збираються для визначення закономірностей пристроїв, які об'єднуються в набір визначених параметрів, які визначають середні значення і стандартні відхилення. Ці параметри використовуються при фільтрації для створення цільового списку пристроїв, що вимагають подальшого дослідження.

Цей етап виконується до будь-якого потоку, показаного на малюнку 2.

Detect

Detect - це виконується в режимі реального часу процес безперервного аналізу даних пристрою під час роботи і даних з інших джерел для ідентифікації можливих проблем пристрою. Цей процес використовує інформацію, отриману на етапі виявлення і позначену як вимагає подальшого дослідження.

У таблиці 1 наведені приклад різних типів даних для моніторингу та початкової фільтрації на основі типу даних.

Таблиця 1. Приклад типів даних для моніторингу та початкової фільтрації

Дані мережі Відсутність голосового зв'язку Кількість дзвінків, що завершилися через відсутність зв'язку Аномальні дані 1, якщо дані визначені як аномальні, і 0 в іншому випадку Завершення передачі даних через слабкого сигналу Кількість сеансів передачі даних, що завершилися через слабкого сигналу Відсутність зв'язку для даних Кількість сеансів передачі даних, що завершилися через відсутність зв'язку Складальник даних пристроїв сторонніх постачальників Аномальне стан батар і 1 при виявленні аномального ресурсу батареї і 0 в іншому випадку Ресурс батареї Середній час життя батареї, виміряний в годиннику Центр обробки викликів (клієнт) Профіль клієнта Інформація про клієнта, наприклад краща контактна інформація або індикатори підписки на послуги

Для підвищення продуктивності первісна фільтрація може виконуватися на обладнанні в зондах шляхом використання таких продуктів як The Now Factory (TNF) Sourceworks. Потім ці дані направляються в потоки, які:

1. Впорядковують дані з декількох джерел.
2. Ідентифікують інформацію про передплатника у вхідних даних.
3. Застосовують до даних прогнозну модель і логічні правила для створення короткого списку потенційно несправних телефонів.

Цей список передається на етап Decide для подальших дій

Decide

На цьому етапі виконуються глибокі запити до результатів, отриманих на етапі Discover, для кращого розуміння роботи пристрою. Також підтримується компіляція даних і забезпечується ретельний аналіз для діагностики проблем пристрої та реалізації рекомендованих змін. Виконується перевірка нових правил, моделей і контрольних списків, критично важливих для петлі зворотного зв'язку в життєвому циклі управління пристроєм, яка сприяє виконанню динамічних змін в пристроях.

Дослідження виконується шляхом обробки відфільтрованих і вибраних даних з використанням технології управління прийняттям оперативних рішень (Operational Decision Management - ODM). ODM-обробка виконується в рамках програми Streams за допомогою Streams Rules Toolkit. Правила ODM дозволяють бізнес-користувачам управляти процесом, що забезпечує перехід з окремих записів про показники пристрою на рішення для обробки заявок і взаємодії з клієнтом. Процес Decide зазвичай складається з двох частин:

• Збагачення. Записи про події, що пройшли ODM-обробку, збагачуються шляхом узгодження полів з різних джерел і додавання похідних полів, що обчислюються з полів, наявних в запису. У прикладі дані пристрої збагачуються відповідними даними мережі.
• Виконання правил. Метою виконання правил першого рівня є обробка записів про події відповідно до бізнес-правилами, визначеними бізнес-користувачами, і генерування попереджень, заявок або автоматичних відповідей. Результатом виконання цих правил буде виконання конкретних дій, як описано далі.

Drive

Для вирішення проблем пристрої виконуються конкретні дії. Попередження і заявки, згенеровані на попередньому етапі, можуть вимагати втручання людини. У більшості випадків їх можна обробити автоматично за допомогою відповідних бізнес-процесів для автоматичної зміни пристрою або повідомлення власника про рекомендовані дії.

Зазвичай дії координує система управління бізнес-процесами (BPM). Потік робіт BPM запускається, коли використовує Streams ODM-обробка направляє список пристроїв в BPM для аналізу основної причини проблем. BPM запитує у системи аналізу подальший статус пристрою і застосовує правила пошуку та усунення несправностей для визначення основної причини несправності принтера. Коригувальні дії робляться в залежності від основної причини проблем. Основними причинами можуть бути проблеми мережі, проблеми устрою і обмеження додатки.

Такий підхід забезпечує потужні можливості самовідновлення. Більшість пристроїв не ламається одномоментно. Процес деградації іноді займає дні або тижні, і часто раніше виявлення є простим і найменш дорогим виходом. Моніторинг всіх пристроїв і пошук закономірностей деградації - це рішення, що дозволяє визначити ранні симптоми, які можна використовувати для своєчасного виправлення:

• Оптимізація пристрої для конкретного використання.
• Додавання аксесуарів, які зроблять пристрій більш зручним.
• Установка в пристрій агентів для подальшого його моніторингу. Агент направляє дані в CSP в режимі реального часу або в пакетному режимі. Ці дані інтегруються з даними з інших джерел для подальшого аналізу.

Грунтуючись на результатах діагностики, CSP може виконати відповідні коригування, використовуючи повідомлення, які генеруються системою автоматично. Ці коригувальні процеси діагностують і виправляють ситуацію, перш ніж вона стане критичною. На малюнку 3 показаний приклад дерева несправностей і наслідків неусунення несправності до звернення клієнта.

Малюнок 3. Приклад дерева несправностей пристроїв

Діагностику проблеми виконує механізм правил (Operational Decision Manager - ODM). Грунтуючись на результатах діагностики, можна виконувати відповідні коригування для передплатника за допомогою повідомлень, які генеруються системою автоматично. Дії по відновленню виконує простий покроковий процес, що запускається BPM-механізмом інтелектуальних процесів.

Варіант использование Fraud (шахрайство)

У міру того як постачальником телекомунікаційніх послуг переходять з голосовим сервісів зв'язку на контент и торгівлю, керовані відео и данімі, підвіщується ризики шахрайського использование їх мереж. Експерт оцінюють Втрата від Шахрайство в 2013 году в 46,3 мільярда долларов, что на 15% більше, чем 2011 году. У відсотках від глобального доходу Галузі телекомунікаційніх услуг¹ Втрата від Шахрайство становляться примерно 2.09% (зростання на 0.21% у порівнянні з 2011 роком). За словами 93 учасников опитування CFCA, найбільш значний часть ставити шахрайство з підпіскою, на Пожалуйста пріпадає 5.22 мільярда долларов Втрата в усьому мире. С помощью несанкціонованого доступу шахрай может зламаті чіюсь підпіску и нелегально використовуват послуги. Більше 70% учасников опитування повідомілі, что на шахрайські операции доводитися до 2% від загально ОБСЯГИ їх операцій. Аналітики шахрайської активності часто використовують параметр "помилкове спрацьовування" для опису числа проаналізованих випадків, які виявилися не шахрайськими. Успішна система визначає шахрайську закономірність за допомогою мінімального аналізу. Вона концентрує обмежені ресурси для виявлення шахрайства на найменшій кількості операцій з максимальною вірогідністю шахрайства, знижуючи витрати на помилкові спрацьовування.

Типовий потік для варіанту використання Fraud складається з наступних етапів:

1. Аналітик шахрайської активності виконує аналіз попередніх даних для ідентифікації кращих способів виявлення шахрайських закономірностей. Визначається ряд правил виявлення, заснованих на параметричних фільтрах.
2. Правила виявлення застосовуються до вихідних даних, істотно зменшуючи розміри даних (зазвичай до менш ніж 5% від вихідних даних).
3. Потім на етапі дослідження операції аналізуються більш детально, часто з виконанням пошуку додаткових даних в обраних облікових записах, пристроях і місцях розташування.
4. Потенційне шахрайство запобігає шляхом відключення сервісів. У деяких випадках інформація про злочинну діяльність передається в правоохоронні органи.

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

При виявленні шахрайства шаблон використовується наступним чином:

1. На етапі Discover ідентифікуються звичайні місця розташування шахраїв і відстань від них до пристрою під час роботи і інші шаблони.
2. На етапі Detect досліджуються всі ситуації, коли місце розташування пристрою різко змінюється за короткий час.
3. На етапі Decision тестується швидкість для перевірки, чи є це зміни шахрайської операцією. Також може збиратися додаткова інформація пристрої для подальшої перевірки його розташування і переміщення.
4. На етапі Drive виконується з'єднання з абонентом для перевірки його ідентичності та можливої ​​зміни інформації про підписку з метою запобігання подальшого клонування.

питання дизайну

Деякі аспекти дизайну шаблону D4 можуть викликати проблеми при реалізації шаблону. Ми зупинимося на двох аспектах дизайну, часто зустрічаються при реалізації шаблону. Ці два аспекти дизайну розглядаються тут ще й тому, що вони не були висвітлені в попередніх статтях цієї серії .

Інтеграція Streams з SPSS

Їх в режимі реального часу оцінка, класифікація, виявлення і дозвіл дій, заснованих на прогнозованих результатах, здійснюється за допомогою IBM® InfoSphere® Streams, інтегрованого з моделями, створеними раніше з використанням IBM SPSS®. Ця інтеграція спирається на можливості SPSS зі створення моделей, шаблонів і правил оцінки на основі ретроспективних даних. Вона використовує модульний дизайн InfoSphere Streams з необмеженою масштабованість для обробки мільйонів подій в секунду, одночасного аналізу даних різних типів і виконання складних обчислень в режимі реального часу.

Інтеграція дизайну шаблону, реалізована в цьому рішенні, виконується в три етапи.

1. Етап автономного моделювання. Спеціаліст за даними за допомогою SPSS Modeler створює аналітичні моделі, засновані на маркованих навчальних даних. Дані можуть розміщуватися на будь-якій платформі: в сховище даних, в PureData ™ Systems for Analytics або Hadoop.
2. Етап проміжної інтеграції. Є два варіанти розгортання моделей SPSS в Streams. Перший - генерування моделі PMML. У форматі PMML генерується обмежений набір моделей. Потім модель PMML розгортається в Streams за допомогою Data Mining Toolkit. Інший підхід є більш загальним і збільшує різноманітність і складність моделей, розгорнутих в Streams. Більш загальний підхід полягає в публікації моделі для генерування файлів .pim, .par і .xml, підтримуваних SPSS Analytics Toolkit for Streams. Потім ці файли конфігуруються за допомогою SPSS Modeler Solution Publisher.
3. Онлайновий етап. Streams SPL (Streams Processing Language - мова обробки потоків) дозволяє розробнику використовувати відповідні оператори і визначення введення / виведення інших моделей. Такий підхід робить можливим аналіз в режимі реального часу.

На автономному етапі SPSS Modeler звертається до навчальних даних в PureData System for Analytics і створює Model Nugget (ядро моделі). Вузол Modeler ODBC звертається до даних і визначень в таблиці бази даних і витягує навчальні дані, що відповідають зазначеним критеріям. Потім Modeler створює Model Nugget для публікації Streams.

На онлайновому етапі InfoSphere Streams споживає мережевий трафік, збагачує дані і в режимі реального часу виконує оцінку, використовуючи SPSS Analytics Toolkit, який надає оператори SPSSScoring, SPSSPublish і SPSSRepository для моделей оцінки. Крім того, при виявленні певної закономірності або досягнення граничного значення можна виконувати відповідні дії в режимі реального часу.

Інтеграція Streams з ODM

Для створення правил для комплексного аналізу подій є зрілий набір продуктів і шаблонів. Кваліфіковані фахівці можуть розробляти складні механізми правил для різних практичних проблем. Зазвичай правила регулярно оновлюються (навіть по кілька разів на день), тому аналітик може швидко реагувати на мінливі шаблони, враховуючи, наприклад, поява нових видів шахрайства.

Прості шаблони можна перетворити в високопродуктивні потокові механізми, але при зміні цих шаблонів потрібно повторна компіляція. Повторна компіляція програмного коду, як правило, збільшує тривалість циклів ІТ-розробки, тестування та випуску. Механізми правил дозволяють встановити порядок зміни шаблонів користувачами без тривалих ІТ-циклів. Щоб скористатися перевагами швидкості виконання і гнучкості зміни, шаблони потрібно модифікувати з використанням механізму правил, а виконувати з використанням потокового механізму в режимі реального часу. У даній статті демонструється, як ODM забезпечує гнучкість розробки і модифікації правил, а InfoSphere Streams надає середу високошвидкісний поставки.

Шаблон інтеграції має три компоненти:

1. Редактор правил. Надає аналітику можливості створення і зміни правил. Ці правила можна протестувати на прикладі даних, щоб гарантувати їх ефективну роботу при виконанні завдань виявлення або дослідження. Редактор використовується для редагування двох наборів правил:
   1. Першим є набір правил видалення, написаних безпосередньо в Streams. Ці правила, більш прості за структурою і враховують невелику кількість атрибутів, використовуються для видалення більшості варіантів, де навряд чи можна знайти проблему, щоб прискорити обробку даних. Для сценарію NFF такими варіантами є справні телефони, які не мають ознак низької продуктивності. Для сценарію Fraud такими варіантами є регулярні операції, що виконуються на мобільних пристроях без атрибутів, в основному пов'язаних з шахрайськими операціями.
   2. Другим є набір правил дослідження, написаних для оператора ODM, який виконується в Streams. Ці правила дозволяють досліджувати конкретний набір варіантів, завдяки великій кількості параметрів і комбінацію ретроспективних даних і даних, отриманих в режимі реального часу. У сценарії NFF ці правила дозволяють досліджувати комбінацію даних пристрою і даних мережі. У сценарії Fraud ці правила дозволяють шукати шахрайські закономірності в комбінації платежів і даних мережі.
2. Streams-оператор фільтрації використовує правила, певні на кроці 1а. Вони використовують простий набір шаблонів для видалення більшості операцій за допомогою порогових значень і точок спрацьовування для невеликого числа атрибутів. Аналітик може налаштувати ці порогові значення за допомогою редактора (див. Крок 1а).
3. ODM-оператор працює в рамках Streams і бере участь в потоці даних, застосовуючи правила, що передаються йому редактором правил. ODM-оператор можна змінити за допомогою редактора (див. Крок 1b). ODM-оператор використовує комбінацію ретроспективних даних і даних, отриманих в режимі реального часу, а також безліч джерел даних для детального вивчення обраного варіанту.

Зазвичай Streams-оператор видаляє 95-98% операцій, залишаючи 2-5% операцій ODM-оператору. Наш досвід аналізу продуктивності показує, що Streams-оператор фільтрації працює в 10-100 разів швидше ODM-оператора і надає зручний інтерфейс для ODM-оператора.

Для успішної реалізації шаблону D4 необхідно кілька інструментів. У таблиці 2 наведені різні продукти і технології IBM, мають відношення до варіантів використання, описаним в статті. Додаткову інформацію про продукти, згаданих в статті, але відсутніх в таблиці 2, можна знайти в інших статтях цієї серії .

Таблиця 2. Опис продуктів і технологій IBM, що мають відношення до варіантів використання, описаним в статті

Sourceworks (The Now Factory), що входить в архітектуру збору даних The Now Factory продукт Sourceworks є джерелом даних для всіх наших програм, які також можна використовувати з продуктами сторонніх постачальників. Надаючи постачальникам послуг зв'язку (Communication Service Provider - CSP) в режимі реального часу на гігабітних швидкостях безперервну інформацію про використання клієнтами мобільних мереж і мереж з фіксованими IP, він усуває складність і проблему отримання даних з багатьох джерел і робить інформацію придатною для практичного використання. Високошвидкісний збирач даних з мережевих пристроїв Smartworks (The Now Factory) Smartworks - лежить в основі портфеля рішень The Now Factory модуль узгодження і аналізу в режимі реального часу - являє собою оптимізований пакет програмного забезпечення, серверів і сховищ, здатний зберігати і обробляти великі обсяги даних з безлічі різноманітних джерел.
Будучи по-справжньому універсальною і повністю інтегрованої платформою, Smartworks зберігає дані в агрегованому багатовимірному форматі для обробки, аналізу та виконання запитів на високій швидкості, надаючи доступ в режимі реального часу до списку пристроїв, що вимагають діагностики і ремонту. Високошвидкісне сховище відфільтрованих даних великого обсягу Streams IBM® InfoSphere® Streams - це платформа розширеної аналітики, що дозволяє призначеним для користувача додатків швидко отримувати, аналізувати і зіставляти інформацію в режимі реального часу по мірі її надходження з тисяч джерел. Це рішення здатне обробляти дані на високій швидкості (до мільйонів подій або повідомлень в секунду) і застосовувати серії складних алгоритмів аналізу, створених сторонніми розробниками і застосовуваних з використанням Streams в режимі, близькому до реального часу. Механізм високошвидкісної обробки для виявлення та ідентифікації заснованих на систематизованих закономірності даних підозрілих або несправних пристроїв. ODM IBM® Operational Decision Manager надає елегантну середу розробки (поряд з виділеними інтерфейсами бізнес-користувачів) для автоматизації та управління часто зустрічаються повторюваними рішеннями в різних процесах і додатках.
IBM Operational Decision Manager забезпечує "інтелект" в Smarter Process, підтримуючи автоматизацію рішень в бізнес-процесах, мобільних додатках і хмарних середовищах. Механізм діагностики підозрілих або несправних пристроїв за допомогою ключових показників продуктивності (KPI), що визначаються механізмом моделювання. IBM BPM Продукти IBM Business Process Manager забезпечують контроль і управління бізнес-процесами. Ці продукти підтримують нові рівні взаємодії з іншим програмним забезпеченням IBM і легко масштабуються з початкового проекту на все підприємство. Організація отримує простоту, ефективність, прозорість і можливість співпраці, необхідні для управління динамічними мережевими бізнес-середовищами. Механізм повідомлень і подальших дій для генерування попереджень або повідомлення клієнта, збирача даних і інших фахівців в предметної області (SME) на підставі результатів аналізу. Vantage Надаючи постачальникам CSP зручний доступ в режимі реального часу до інформації про використання окремими клієнтами мобільних сервісів, Vantage Customer Manager допомагає клієнтам і постачальникам швидко діагностувати і вирішувати проблеми в складній суміші додатків, пристроїв і мереж. Механізм аналізу для надання різних звітів по роботі пристрою, мережі і клієнта.

Висновок і подальші плани

Advanced Analytics Platform дозволяє створити кілька шаблонів аналізу. Ми розглянули шаблон D4, чотири ключові компоненти цього шаблону, кілька варіантів використання його використання і типові аспекти його дизайну. У наступній статті будуть розглянуті загальні проблеми інтеграції, що виникають при використанні декількох інструментальних засобів і відповідних шаблонів. Також буде розглянута інтеграція, необхідна для аналізу в режимі реального часу. Високопродуктивна інтеграція необхідна, щоб компоненти, які не можуть обробити дані в режимі реального часу, не стали вузькими місцями, що перешкоджають аналізу в режимі реального часу в усій архітектурі.

Ресурси для скачування

Схожі тими

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів