działania na dużych zbiorach danych Clementine Server
white paper SPSS działania na dużych zbiorach danych Wzrost wydajności z wykorzystaniem 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
Jak Clementine Server 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 APLIKACJA DZIAŁAJĄCA NA SERWERZE CLEMENTINE BAZA DANYCH 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. Testy wydajnoś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
WARSTWA BAZY DANYCH BAZA DANYCH 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. APLIKACJA DZIAŁAJĄCA NA SERWERZE CLEMENTINE WARSTWA SERWERA 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 APLIKACJI 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 Windows 2000 Clementine Server Windowe NT Server Dell Latitude CPt C400GT Intel Celeron 400MHz Dell Poweredge 6300 400 4x500MHz 130 MB RAM 1 GB RAM 6 GB disk 10 MB ethernet 36 GB disk 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
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
Ś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
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
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: info@spss.pl www.spss.pl www.analizadanych.pl www.webmining.pl