działania na dużych zbiorach danych white

Transkrypt

działania na dużych zbiorach danych white
white
PA P E R
działania na dużych
zbiorach danych
Clementine Ser v er
white paper SPSS
działania na dużych zbiorach danych
Wzrost w ydajności z w ykorz ystaniem
drążenia danych
Wydajność procesu drążenia danych jest mierzona w przypadku systemu Clementine przy pomocy wskaźnika „time–to–value”, czyli czasu koniecznego do uzyskania ze zgromadzonych i analizowanych danych
wartościowych informacji dla przedsiębiorstwa. Celem ograniczenia czasu trwania projektu Data Mining
w Clementine wprowadzono koncepcję graficznego projektowania rozwiązania analitycznego. Korzystając z graficznego interfejsu programu Clementine jego użytkownicy są w stanie płynnie poruszać się
przez wszystkie etapy procesu drążenia danych, co pozwala im zastosować wiedzę biznesową znacznie
szybciej niż w innych rozwiązaniach.
zrozumienie
uwarunkowań
zrozumienie
danych
przygotowanie
danych
wdrożenie
DANE
modelowanie
ewaluacja
Rysunek 1.
Metodologia CRISP–DM
Inne podejścia do procesu drążenia danych kładą szczególny nacisk na moc przetwarzania danych surowych, znacznie większy niż na produktywność całego procesu. Jednak szybko działające modele wcale
nie muszą dostarczać wyników wartościowych dla organizacji. Biorąc pod uwagę całość procesu Data
Mining opisanego według metodologii CRISP–DM (rysunek 1)należy raczej dążyć do optymalizacji działań
i skracania czasu trwania wszystkich etapów tego procesu. Zwiększenie wydajności procesu drążenia
danych uzyskuje się właśnie poprzez minimalizację wskaźnika „time–to–value”.
W przeszłości Clementine był narzędziem dedykowanym głównie do analizy zbiorów danych przechowywanych w zasobach lokalnego komputera. Wraz z udostępnieniem architektury klient–serwer Clementine
możliwości programu związane z przetwarzaniem dużych wolumenów danych i z wydajnością całego
systemu znacznie wzrosły. Aktualnie na bardzo dużych zbiorach danych może być prowadzona niemal interaktywna praca, począwszy od obróbki tych danych i ich przetwarzania przygotowującego, poprzez
modelowanie, a na procesach produkcyjnych, generujących oczekiwane wyniki skończywszy. Dodatkowo
integracja szeregu etapów, począwszy od przygotowywania danych, a na dystrybucji wyników analiz
kończąc powoduje dalsze obniżenie współczynnika „time–to–value”.
2
white
PA P E R
Jak Clementine Ser ver usprawnia
działania na duż ych zbiorach danych
Clementine Server korzysta z mechanizmów wbudowanych w bazy danych.
Operacje które mogą być wykonane bezpośrednio w bazie są do niej przekazywane. Wbudowany w Clementine mechanizm optymalizacji zapytań SQL pozwala na wykonywanie zoptymalizowanych operacji
przygotowania danych i niektórych operacji analitycznych bezpośrednio w bazie.
UŻYTKOWNIK A
UŻYTKOWNIK B
K L I E N T
S E R W E R
A P L I K AC JA DZ I AŁ A JĄC A N A S E RW E R Z E C L E M E N T I N E
B A Z A DA N YC H
Rysunek 2.
Trzy warstwy rozwiązania Clementine
Architektura rozwiązania Clementine składa się z trzech warstw: DBMS nazywana warstwą bazy danych,
warstwa aplikacji serwera oraz warstwa użytkownika (rysunek 2 ). Warstwa użytkownika zawiera interfejs
Clementine wraz ze strumieniem przepływu danych, który prezentuje każdy etap drążenia danych
Z pomocą Clementine Server strumień danych jest przetwarzany bezpośrednio w bazie danych. Operacje, które nie mogą być przekształcone w zapytania SQL są wykonywane przez aplikację serwerową
Clementine, dysponującą większą mocą obliczeniową. Jedynie istotne wyniki wysyłane są do warstwy
użytkownika (do klienta Clementine).
3
white paper SPSS
działania na dużych zbiorach danych
Rysunek 3.
Przykład zoptymalizowanej współpracy Clementine z bazą danych
Wszelkie operacje wykonywane bezpośrednio w bazie danych są sygnalizowane w interfejsie graficznym
Clementine. Podczas wykonywania strumienia analitycznego wszystkie węzły operacji przeniesionych
na bazę są wyróżniane kolorem fioletowym (rysunek 3 ).
Ostatni fioletowy węzeł w strumieniu reprezentuje jednocześnie ostatnią operację przeniesioną na bazę.
Pozostałe operacje są wykonywane przez Clementine Server lub przez oprogramowanie klienckie Clementine.
Im więcej operacji zostanie wykonanych w bazie danych, tym krótszy będzie czas ich analizy w systemie
analitycznym Clementine.
Optymalizacja zapytań SQL i operacji wykonywanych w strumieniu danych przebiega automatycznie, bez
udziału użytkownika. Dzięki temu może się on skoncentrować na biznesowych aspektach rozwiązania
analitycznego, nie martwiąc się o przebieg wykonania strumienia analitycznego. Wewnętrzny mechanizm
optymalizacji nie wpływa na wynik prowadzonych analiz. Oznacza to, że wyniki operacji nieoptymalizowanych i zoptymalizowanych mogą się różnić jedynie czasem wykonania.
Test y w ydajnościowe
Celem tego opracowania jest dostarczenie wiarygodnych wyników testów skalowalności rozwiązania analitycznego stworzonego za pomocą Clementine Server. Istnieje szereg czynników wpływających na wydajność programu Clementine. Architektura systemu, sprzęt i oprogramowanie, a także przyjęte rozwiązanie
analityczne odgrywają istotną rolę w ostatecznej wydajności. Na szybkość działania Clementine największy wpływ mają dwa czynniki, dostępna pojemność pamięci RAM oraz powierzchni dyskowej przy
założeniu określonej ilości analizowanych danych.
4
white
PA P E R
WARSTWA BAZY DANYCH
B A Z A DA N YC H
przetwarzanie danych
selekcja, sortowanie i agregowanie rekordów;
łączenie tabel przy pomocy zmiennych kluczowych;
filtrowanie i wyliczanie zmiennych.
wizualizacja
wykresy punktowe i liniowe;
wykresy rozkładu;
wykresy sieciowe.
APLIK ACJA
DZIAŁAJĄCA
NA
SERWERZE CLEMENTINE
WARSTWA SERWER A CLEMENTINE
operacje, które nie mogą zostać wykonana w bazie:
inne kroki przetwarzania danych i wizualizacji;
modelowanie;
dostęp do plików płaskich
UŻYTKOWNIK
WARSTWA APLIK ACJI KLIENCKIEJ
rezultaty istotne z punktu widzenia analizy
wykresy i inne dane wyjściowe;
tylko dane przeglądane przez użytkownika.
Rysunek 4.
Zakres operacji w poszczególnych warstwach rozwiązania
Im więcej operacji ma być wykonywanych przez Clementine Server, tym większa musi być dostępna
pojemność dysków. Z pomocą dostępnych w środowisku Clementine węzłów agregacji, łączenia, losowania i selekcji danych, wymagana pojemność dyskowa może zostać ograniczona. Bezpiecznym nawykiem
jest przyjmowanie trzykrotnie większej wymaganej przestrzeni dyskowej w porównaniu z płaską tabelą
analityczną zbudowaną na postawie bazy. Pozwoli to z wystarczającym marginesem bezpieczeństwa
przeprowadzać wszelkie operacje na analizowanych danych.
Intencją niniejszej publikacji jest dostarczenie wyników testów wydajnościowych przeprowadzonych na typowych operacjach związanych z różnymi etapami drążenia danych. Rezultaty tych testów dają obraz
wydajności operacji na dużych zbiorach danych. Testowanymi operacjami są:
Przetwarzanie danych
Związane z nim są:
dostęp do dwóch tabel źródłowych, klientów i transakcji,
agregacja tabeli transakcji do poziomu pojedynczego klienta,
łączenie dwóch tabel, klientów i zagregowanych transakcji.
W procesie tym dodatkowo wyliczane są dwie nowe cechy.
Modelowanie
W dalszej kolejności wyliczana jest jeszcze jedna nowa cecha i tak przygotowany zbiór jest modelowany
z pomocą algorytmu drzewa klasyfikacyjnego C&RT. Algorytm ten jest stosowany, ponieważ daje czysty
5
white paper SPSS
działania na dużych zbiorach danych
obraz wydajności programu w zakresie budowania modeli drążenia danych. Inne techniki modelowania
są zbyt wrażliwe (sieci neuronowe) lub nieczułe na ilość danych (algorytm GRI ). Czas przeznaczony
na budowanie modeli zależy zawsze od danych i wybranej techniki analitycznej. Domyślne ustawienia
Clementine pozwalają budować dokładniejsze modele. Jeżeli zależy nam na szybkości działania algorytmów, wówczas musimy modyfikować parametry.
Scoring
W przeciwieństwie do budowy modelu, gdzie zazwyczaj korzystamy z prób danych, scoring zazwyczaj
angażuje kompletny zbiór danych. Przykładem niech będzie reakcja na wysyłkę, która może kształtować
się na poziomie 1% . Budowanie modelu na bazie wszystkich obserwacji może doprowadzić do uzyskania
zniekształconych wyników. Dane treningowe do modelu reakcji na wysyłkę powinny zatem zawierać około
2% wszystkich obserwacji, po jednym procencie poszczególnych kategorii: odpowiedź na wysyłkę, brak
odpowiedzi. Chociaż model tworzony jest na bazie dwuprocentowej próby danych, to sam scoring powinien zostać przeprowadzony na całej dostępnej populacji klientów. Tylko wtedy mamy szansę wychwycić
wszystkich, którzy potencjalnie odpowiedzą na wysyłkę.
Przykład ten obrazuje rzeczywisty czas potrzebny na stworzenie modelu na podstawie niewielkiej próby
i przeprowadzenie scoringu w trybie wsadowym na dużym zbiorze danych.
Testy zostały przeprowadzone na komputerach o poniższych parametrach:
Clementine Client
Clementine Server
Windows 2000
Windowe NT Server
Dell Latitude CP t C400GT
Dell Poweredge 6300
Intel Celeron 400MHz
400 4x 500MHz
130 MB RAM
1 GB RAM
6 GB disk
36 GB disk
10 MB ethernet
SQL Server
Zastosowane zbiory danych zawierają od 1 do 13 milionów obserwacji. Na etapie przygotowywania
danych wykorzystano dwa zbiory, pierwszy zawiera 16 cech ( 8 jakościowych i 8 ilościowych), drugi zaś
8 cech (4 jakościowe i 4 ilościowe). Zbiór służący do modelowania zawiera 9 cech ( 5 jakościowych i 4
ilościowe), natomiast do scoringu zastosowano zbiór zawierający 8 cech (4 jakościowe i 4 ilościowe).
Wszystkie przedstawione wykresy (oprócz wykresu dla scoringu) dotyczą testów przeprowadzonych
na bazie danych z Clementine, wykorzystującą mechanizm optymalizacji zapytań SQL . Dostęp do bazy
danych bez optymalizacji SQL spowoduje, że dane, które są przetwarzane, zostaną ściągnięte z bazy do
środowiska Clementine. Proces ten jest i tak szybszy w porównaniu do wczytywania danych z płaskich
plików zlokalizowanych w warstwie serwera. Clementine musi odczytywać wszystkie dane z plików i tylko
istotne kolumny z bazy danych nawet bez optymalizacji SQL . Praca z bazą danych przy użyciu Clementine jest zawsze efektywniejsza. Jest to szczególnie ważne kiedy wczytywany zbiór danych posiada
dużą liczbę cech.
Korzystanie z płaskich plików danych w warstwie serwera jest natomiast znacznie efektywniejsze od
wczytywania ich w warstwie klienta. Często wykorzystywanym mechanizmem jest tworzenie pośrednich
płaskich plików, zoptymalizowanych pod kątem prowadzonych analiz. Procedura ta umożliwia skrócenie
czasu wczytywania danych, jeżeli użytkownik nie wykorzystuje mechanizmu optymalizacji zapytań SQL
kierowanych do bazy.
6
white
PA P E R
Wyniki testów
Przetwarzanie danych
Przeciętny wzrost czasu wymaganego na przetworzenie kolejnego miliona obserwacji wyniósł w badanych zbiorach około 69 sekund. Niemal liniową zależność czasu obliczeń od liczby analizowanych
obserwacji prezentuje wykres poniżej (rysunek 5 ).
Rysunek 5.
Zależność wydajności przetwarzania danych od ich ilości.
Rysunek 6.
Fioletowe węzły reprezentują operacje w bazie danych.
7
white paper SPSS
działania na dużych zbiorach danych
Zaprezentowany strumień analityczny jest przykładem przygotowywania danych, czyli jednego z początkowych etapów drążenia danych zgodnych z metodologią CRISP–DM (rysunek 6 ). Zawiera kilka typowych
operacji, między innymi agregację i łączenie zbiorów oraz wyliczenie nowych cech niezbędnych do modelowania danych. Zgodnie z praktyką wynikającą z metodologii CRISP–DM jest to jednocześnie najdłuższy etap, pochłaniający od 75 do 90 procent ogólnego czasu poświęconego całemu projektowi.
Modelowanie
Również i w tym przypadku liczba obserwacji ma wprost proporcjonalny wpływ na czas niezbędny
do stworzenia modelu. Świadczy to o pełnej skalowalności procesu modelowania danych w środowisku
Clementine (rysunek 7).
Rysunek 7.
Zależność wydajności modelowania od ich ilości danych analitycznych.
Rysunek 8.
Modelowanie z wykorzystaniem algorytmu CRT.
Strumień danych jest odzwierciedleniem etapu modelowania w metodologii CRISP–DM (rysunek 8 ). Wyliczana jest w nim dodatkowa cech, która następnie wykorzystywana jest w modelowaniu z pomocą algorytmu C&RT. Zbiór danych zawiera 8 cech (4 jakościowe i 4 ilościowe). Zgodnie z metodologią CRISP–DM
etap ten jest powtarzany wielokrotnie z wykorzystaniem fragmentów danych pochodzących z oryginalnego zbioru. Procedura ta ma na celu zidentyfikowanie parametrów, przy których wyniki osiągane przez
model są najlepsze. W dalszej kolejności na podstawie kompletnego zbioru analitycznego budowany
jest ostateczny model.
8
white
PA P E R
Środowisko Clementine oprócz możliwości optymalizacji zapytań SQL, posiada również mechanizmy
optymalizacji procesów tworzenia modeli drążenia danych. Połączenie obu tych mechanizmów istotnie
wpływa na wzrost efektywności budowanych rozwiązań.
Szereg czynników wpływa na czas wykonywania modeli w środowisku Clementine. Podstawowym z nich
jest rodzaj zastosowanego modelu. Na przykład, sieci neuronowe ze względu na swoje charakterystyczne
cechy wymagają znacznie większych mocy obliczeniowych niż modele drzew klasyfikacyjnych. Kolejnymi
czynnikami mającymi istotny wpływ na czas modelowania są: wielkość zbioru danych (liczba obserwacji
i cech w zbiorze oraz typy poszczególnych cech), architektura, sprzęt i oprogramowanie.
Należy przy tym pamiętać, że szybkość budowania modelu niekoniecznie idzie w parze z wysoką jakością ostatecznych wyników. Proces budowania może zostać przyspieszony poprzez modyfikację parametrów poszczególnych algorytmów drążenia danych. W pracy na dużych zbiorach danych dobrym
nawykiem jest w pierwszej kolejności optymalizowanie modelowania pod kątem szybkości, a następnie
dostosowywanie parametrów dla uzyskania najwyższej skuteczności budowanego modelu.
Scoring
Podobnie jak w poprzednich dwóch przykładach, również i w tym istnieje pełna skalowalność procesu.
Czas poświęcony na scoring klientów jest wprost proporcjonalny do ich liczby (rysunek 9 ).
Rysunek 9.
Zależność wydajności scoringu od ich ilości danych.
9
white paper SPSS
działania na dużych zbiorach danych
Rysunek 10.
Dystrybucja wyników uzyskanych w wyniku modelowania.
Rysunek 11.
Scoring prowadzony interaktywnie w czasie rzeczywistym.
Pierwszy zaprezentowany strumień analityczny jest przykładem dystrybucji wyników uzyskanych z poprzednich etapów projektu (rysunek 10 ). Scoring w tym przypadku polega na przypisaniu poszczególnym
klientom odpowiednich ocen i ufności uzyskanych na podstawie modelu i zapisanie tych informacji zwrotnie w nowej tabeli bazy danych.
Drugi strumień danych obrazuje scoring prowadzony interaktywnie w czasie rzeczywistym (rysunek 11).
Wykonywany jest wielokrotnie dla pojedynczych obserwacji. Zagadnienie to jest szczególnie istotne przy
budowaniu rozwiązań, których wyniki mają być dystrybuowane z pomocą cienkiego klienta.
Każde uruchomienie drugiego strumienia danych powoduje wykonanie następujących operacji:
wczytanie danych z pliku produktów (ofert specjalnych),
odczytanie pojedynczej obserwacji z pliku, w którym pojawiają się dane o kliencie pochodzące
z formularza internetowego,
połączeniu obu zbiorów (pojedynczej obserwacji z plikiem ofert specjalnych),
zastosowanie przygotowanego modelu na połączonym zbiorze danych,
wybór 10 najtrafniejszych ofert specjalnych dla danego klienta,
zapisanie wyniku do pliku.
Scoring został uruchomiony tysiąc razy za każdym razem dla pięciu obserwacji ze zbioru klientów. Każda
z tysiąca iteracji trwała około 0,22 sekundy. Testy zakończono uzyskując wynik średni na poziomie 255
iteracji na minutę.
10
white
PA P E R
Konkluzje
Wciąż rosnące ilości danych gromadzonych przez organizacje otwierają nowe możliwości i wyzwania
dla technik drążenia danych. Integracja wszystkich danych o klientach i innych źródeł danych oraz możliwość ich wykorzystania do analiz z wykorzystaniem nowoczesnych technik modelowania, prowadzi
w efekcie do poprawy wyników finansowych organizacji podejmujących takie zadania. Skalowalność rozwiązań analitycznych zbudowanych w oparciu o środowisko Clementine sprawia, że drążenie danych jest
obecnie możliwe nawet na bardzo dużych zbiorach danych, jakie posiadają wielkie organizacje. Prowadzi to nie tylko do skrócenia czasu niezbędnego do uzyskanie wiedzy na podstawie surowych danych, ale
do uzyskania z tego tytułu wymiernych korzyści.
11
white
PA P E R
SPSS dostarcza wiedzę i narzędzia, które pozwalają na efektywną realizację projektów badawczych. Dostarczamy rozwiązań z zakresu zarządzania relacjami z klientem ( CRM ) i business intelligence, które umożliwiają użytkownikom systemów SPSS
bardziej dochodową współpracę z ich klientami. Narzędzia SPSS pozwalają scalać
i analizować dane marketingowe, dane o klientach i dane operacyjne w obrębie
najważniejszych branż na całym świecie – między innymi w telekomunikacji, ochronie zdrowia, bankowości, finansach, ubezpieczeniach, produkcji, handlu, badaniach
rynku, administracji, edukacji i sektorze publicznym. Poza centralą w Chicago ( USA )
SPSS posiada blisko 170 biur na całym świecie.
SPSS Polska zapewnia pełną informację o produktach SPSS, prowadzi kursy i szkolenia z zakresu analizy danych oraz obsługi i zastosowań programów SPSS. Użytkownikom zapewnia serwis i pomoc techniczną. Więcej informacji znajdą Państwo
na stronach SPSS Polska, dostępnych pod adresem www.spss.pl.
SPSS Polska
ul. Racławicka 58
30–017 Kraków
tel./faks 012.636.96.80
tel./faks 012.636.07.91
tel./faks 012.636.45.35
e–mail: [email protected]
www.spss.pl
www.analizadanych.pl
www.webmining.pl