System ocen scoringowych zbudowany na platformie Windows Server 2003 z wykorzystaniem Visual Studio .NET 2003
|
Informacje o firmie
Firma VisionSoft jest niezależnym dostawcą oprogramowania i rozwiązań informatycznych. Firma działa na rynku od dziesięciu lat, w tym okresie zdołała się wyspecjalizować w budowie dedykowanych systemów informatycznych wymagających złożonego funkcjonalnie i zaawansowanego technologicznie oprogramowania oraz niekonwencjonalnych rozwiązań informatycznych.
Spośród głównych klientów firmy można wymienić czołowe polskie banki, firmy ubezpieczeniowe, zakłady komunikacyjne, urzędy, zakłady gazownicze i komunalne oraz firmy windykacyjne.
Uwarunkowania zewnętrzne i konieczność integracji lub współpracy z systemami już posiadanymi przez klientów, wymogły zastosowanie dla wielu rozwiązań oferowanych przez VisionSoft architektury przetwarzania rozproszonego zakładającej heterogeniczność platformy sprzętowej, systemów operacyjnych oraz środowisk programistycznych.
Realizując swoje projekty, firma wykorzystuje technologie intranetowe i internetowe oraz wdraża je w oparciu o wydajne platformy bazodanowe (MS SQL Server, Oracle) a także inne, najnowsze technologie informatyczne takie jak Microsoft .NET, J2EE.
Wyzwanie
Jednym z podstawowych źródeł przychodów dla banków są odsetki i prowizje związane z udzielaniem kredytów. W przypadku banków detalicznych, koncentrujących się na obsłudze osób fizycznych, dużą część tych kredytów stanowią kredyty odnawialne związane z kontami osobistymi prowadzonymi przez bank. Aby uniknąć złych kredytów, niezbędne jest dokonywanie oceny wiarygodności kredytowej klientów banku – szczególnie na podstawie historii transakcji dokonywanych na kontach.
Dla naszego klienta zaproponowaliśmy i z powodzeniem wdrożyliśmy system ocen scoringowych. Do jego stworzenia wykorzystaliśmy środowisko Microsoft Visual Studio .NET 2003. System pracuje w oparciu o Microsoft Windows Server 2003.
Sytuacja
Klient VisionSoft – jeden z dużych banków detalicznych – zdecydował się wdrożyć system ocen scoringowych. Jednym z jego zadań była współpraca z zewnętrznym systemem analiz finansowych. Dane wejściowe do zewnętrznego systemu, to zestaw funkcji agregujących wyliczonych na podstawie historii transakcji zachodzących na koncie klienta banku. Dane wyjściowe to zestaw danych obrazujących przewidywane dalsze zachowanie klienta banku, w tym propozycję w zakresie wysokości udostępnianych klientowi środków.
Dodatkowym wymaganiem wobec systemu była konieczność korzystania z informacji o zaangażowaniu kredytowym klienta w innych instytucjach kredytowych.
Struktura systemu informatycznego klienta opiera się na niezależnych centrach transakcyjnych obsługiwanych przez instancje systemu księgowego. Na potrzeby oceny scoringowej dane transakcyjne muszą zostać przekazane do centrali i zagregowane. Przy liczebności kilku milionów kont prowadzonych przez kilkadziesiąt centrów, proces pozyskiwania danych nie był zadaniem prostym.
Następnym etapem miało być przetworzenie danych transakcyjnych i przygotowanie na ich podstawie około 200 funkcji agregujących (agregatów) – obrazujących sytuację na każdym koncie w kolejnych przedziałach czasowych. Aby zobrazować skalę przetwarzania, upraszczając i zakładając średnio zaledwie 10 operacji miesięcznie na każdym koncie, co miesiąc konieczne jest przetworzenie kilkudziesięciu milionów rekordów.
Tak przygotowane dane w postaci anonimowej przekazywane są do zewnętrznego systemu, gdzie podlegają dalszej analizie. Wyniki tej analizy są przesyłane do serwisów oferowanego systemu, będąc podstawą przetwarzania. Przetwarzanie to polega na wyliczeniu kolejnych agregatów, tym razem już konkretnie dotyczących oferty kredytowej dla rachunku.
Dodatkowym utrudnieniem przy projektowaniu systemu jest konieczność zawarcia całego cyklu przetwarzania informacji w napiętym harmonogramie. Dane transakcyjne dostępne są około 8 dnia miesiąca, przetwarzanie danych w firmie zewnętrznej to około 2 dni. Ażeby udostępnić nową ofertę kredytową od 1 dnia następnego miesiąca, konieczne jest zakończenie procesu przetwarzania w ciągu około 20 dni.
Poniżej zaprezentowano ogólny schemat działania systemu:
Rysunek 1 Ogólny schemat przetwarzania
Rozwiązanie
Projekt systemu musiał zmierzyć się z dwoma podstawowymi problemami, jakimi była olbrzymia ilość danych – jak zostało to opisane przykładem wspomnianym powyżej, oraz szeroka konfigurowalność systemu wymagana przez klienta – m.in. udostępnienie uprawnionym użytkownikom podsystemu konfiguracji następujących parametrów:
| • | Ustalanie kalendarzy pobierania i przetwarzania danych oraz wymiany danych |
| • | Konfigurowanie wartości słownikowych |
| • | Zarządzanie kluczami szyfrowymi wykorzystywanymi w operacjach kryptograficznych |
| • | Parametryzowanie zbiorów kodów operacji (umożliwiających rozpoznanie rodzajów transakcji prowadzonych na rachunkach) |
| • | Definiowanie zbiorów parametrów określających, które operacje mają być wykorzystane do wyznaczenia danych agregatów |
| • | Konfigurowanie funkcji agregujących |
| • | Określanie wzorów raportów i zestawień generowanych przez moduły raportowe |
Ponieważ czas wdrożenia systemu był bardzo ograniczony, zdecydowano się na zastosowanie sprawdzonej już platformy .NET pozwalającej zarówno na łatwe opracowanie interfejsu użytkownika – w postaci aplikacji WWW, jak i szybkie przygotowanie aplikacji serwisowej, na której spoczywał główny ciężar przetwarzania danych. Aplikacja WWW posadowiona została na klastrze trzech serwerów pracujących pod kontrolą systemu Windows 2003 Serwer, zaś aplikacja serwisowa została zainstalowana na 4–procesorowym serwerze pod kontrolą systemu Windows 2000 Serwer. Jako platformę bazodanową postanowiono wykorzystać SQL Server 2000 w wersji 64 bitowej pracujący na serwerach wyposażonych 2 procesory Italium, wyposażoną w macierz dyskową SCSI. Na poniższym rysunku przedstawiono schemat architektury fizycznej systemu:
Rysunek 2 Schemat architektury systemu
Skala ilości przetwarzanych danych wymagała szczegółowego zaplanowania projektu i dokonania wyboru środowiska, w którym operacje będą dokonywane najefektywniej. Dlatego też główny nacisk został położony na maksymalne wykorzystanie silnika bazy danych, na którego barki złożono główną część obliczeniową systemu. Mechanizm zarządzania systemem odbywa się poprzez aplikację WWW, posiada ona także interfejs konfiguracyjny oraz funkcje przeglądania logów. Na potrzeby osób zarządzających i kontrolujących udostępniono także poprzez WWW interfejs do przeglądania zawartości tabel zawierających zarówno dane transakcyjne, jak i dane przetworzone. Dane prezentowane są na każdym etapie ich przetwarzania. Aplikacja serwisowa realizuje poniższe zadania zlecone poprzez standardową przeglądarkę internetową:
| • | Wczytywanie danych transakcyjnych z plików źródłowych a także plików z innych systemów – z wykorzystaniem w szerokim zakresie mechanizmu BULK INSERT (dla przykładu, skala przetwarzania obejmuje wczytanie około 70 milionów rekordów miesięcznie, dane wczytywane są przez około 24 godziny) |
| • | Zarządzanie wyliczaniem agregatów |
| • | Generowanie plików wyjściowych na potrzeby komunikacji z innymi systemami |
| • | Dokonywanie walidacji zarówno danych transakcyjnych, jak i przetworzonych agregatów |
Największym wyzwaniem była metoda wyznaczania agregatów. Po analizie algorytmów zdecydowano się na ich wyznaczanie całkowicie po stronie serwera bazodanowego poprzez wykonanie odpowiednio przygotowanych zapytań SQL. Ponieważ wykonanie takiego zapytania jednocześnie dla wszystkich rachunków było bardzo czasochłonne, a jakiekolwiek zakłócenia w pracy sieci w trakcie jego wykonywania powodowały utratę wyników, zdecydowano się na wykonywanie ich dla paczek obejmujących po 10.000 rachunków. Takie podejście pozwoliło też na równoległe przeprowadzenie zadań realizowanych po stronie serwera bazy danych. Poniżej przedstawiono schemat logiczny systemu, na którym ujęte zostały główne składowe systemu:
Rysunek 3 Model logiczny
Do kodowania algorytmów opracowano pseudojęzyk oparty na języku SQL (wykonywany przez moduł wyliczeń podczas definiowania funkcji agregujących), a także – w ramach aplikacji WWW – narzędzie służące do przygotowywania i testowania algorytmów. Wykorzystano tutaj mechanizm podobny do metody generowania klas z plików aspx przez środowisko .NET – zakłada on wykorzystanie technologii CodeDOM. Całość systemu została wykonana za pomocą narzędzi Visual Studio 2003, z wyjątkiem prostego narzędzia szybkiej walidacji plików transakcyjnych, które przygotowane zostało w Visual C++ 6.0. Aplikacja serwisowa została wykonana jako aplikacja konsolowa uruchamiana okresowo przez Harmonogram zadań, jej komunikacja z modułami systemu jest realizowana poprzez mechanizmy bazy danych. W efekcie udało się osiągnąć akceptowalny dla klienta czas wyliczania agregatów: około 5 dni. Obciążenie serwerów (we wspomnianej powyżej konfiguracji) podczas wykonywania funkcji agregujących wzrosło o około 30%. Działanie aplikacji serwisowej w minimalnym stopniu wpływa na pracę serwerów.
