Największy serwis aukcyjny w Polsce, Allegro – operujący także w kilku innych krajach – nie posiadał dotąd systemu Business Intelligence. Chociaż firma rozwijała się bardzo dynamicznie, analityka nadal posługiwała się arkuszami kalkulacyjnymi, zasilanymi z systemu transakcyjnego. Te narzędzia umożliwiały co najwyżej oszacowanie pewnych wartości i wykrycie trendów.
Bardzo wiele pytań pozostawało jednak bez odpowiedzi. W firmie działającej na rynku handlu elektronicznego należy analizować wiele współczynników, które charakteryzują proces sprzedaży, takich jak rozpiętość kategorii, typowy koszyk zakupów, standardowe zachowania użytkowników. Tymczasem QXL Poland prowadzi wiele serwisów – nie tylko Allegro – ma wielu użytkowników i relacji z dostawcami. Tradycyjne metody pozyskania danych nie dawały precyzyjnych odpowiedzi.

Sięgnąć po dane

QXL Poland, właściciel Allegro, zdecydował się na wdrożenie zaawansowanego systemu analitycznego, co miało przynieść istotne korzyści biznesowe. „Zdecydowaliśmy się na wdrożenie systemu BI, alokując aż 20 proc. całego budżetu IT na ten cel, gdyż nasz szybki wzrost wymagał podjęcia inwestycji związanych ze sprawną obsługą rosnących potrzeb coraz większej ilości użytkowników” – mówi Christian Maar, CIO firmy. Zaplanowany na 40% wzrost Allegro nie przekładał się już tak dobrze na kluczowe wskaźniki, gdyż łączyłby się ze wzrostem liczby użytkowników aż o 100%! A to oznacza, że koszty związane z obsługą większej liczby użytkowników zaczęły bardzo poważnie rosnąć, wymagając dużych nakładów, aby osiągnąć podobny wzrost. Niezbędna więc była nowa technologia.
„Kwerendy mocno obciążały system transakcyjny. W wielu przypadkach danych było tak dużo, że nawet nie mieliśmy pojęcia, czego nie wiedzieliśmy. Nie wiedzieliśmy też gdzie patrzeć, aby znaleźć oczekiwane informacje. Tymczasem drugim z powodów wdrożenia systemu BI, była chęć analizy danych, aby uzyskać odpowiedzi na bardzo ważne – z punktu widzenia biznesu – pytania” – mówi Christian Maar. „Potrzebowaliśmy informacji na temat klienta – czy jest to dobry klient i jak prowadzi interesy we wszystkich naszych serwisach, także zagranicznych? Czy fakt, że na Allegro wydaje niewiele pieniędzy, czyni z niego «złego klienta»? Czy nadal jest to «zły klient», jeśli wiadomo, że ta sama osoba jest wyjątkowo czynnym sprzedawcą na Otomoto i jednocześnie prowadzi interesy w serwisie Molotok.ru? Chcieliśmy mieć pełny obraz naszych klientów, z perspektywy działu obsługi klienta jest to ważna informacja” – dodaje. Kluczem do odpowiedzi na istotne pytania miał stać się system Business Intelligence.

Grupa ds. BI

W drugim kwartale 2008 r. rozpoczęto projekt wdrożenia systemu BI, utworzono specjalną grupę roboczą, w lipcu rozpoczęto prace nad wyborem platformy, planowano ukończenie ewaluacji na trzeci kwartał 2008 r., aby w czwartym kwartale mieć gotowy sprzęt i od początku 2009 r. rozpocząć implementację. „Badaliśmy oferty liderów rynku, takich jak IBM, HP, Sun czy Netezza. Jedna grupa zajmowała się sprzętem, druga stosem oprogramowania. Braliśmy pod uwagę oprogramowanie Business Objects, Oracle i Microstrategy” – opowiada Christian Maar.
Celem było wdrożenie systemu, który umożliwi analizę informacji o pracy serwisu z opóźnieniem nie dłuższym niż pół godziny, także w szczycie obciążenia, przy 520 mln odświeżeń na dobę. Testowano również systemy pamięci masowych różnych firm, takich jak IBM, Sun, HP i 3PAR. Sprawdzano ofertę firmy Netezza, którą porównano z nowym rozwiązaniem Oracle Database Machine. Okazało się ono bardzo wydajnym rozwiązaniem, wygrywając z konkurencją, głównie na polu wydajności.
Allegro stało się pierwszym na świecie użytkownikiem tego rozwiązania.
Przy wyborze oprogramowania Business Intelligence, w finale znalazły się dwa porównywalne rozwiązania – Microstrategy i Oracle. „Pojedynek był bardzo wyrównany. Niektórzy klienci preferowali Microstrategy, głównie ze względu na ładniejszy interfejs i bardzo dobrą integrację z Excelem. Moje doświadczenie pokazało jednak, że przy dużym projekcie prędzej czy później pojawią się problemy. Natomiast gdy całość rozwiązania pochodzi od jednego dostawcy, ryzyko niepowodzenia jest znacznie mniejsze” – konkluduje Christian Maar.

Jak zasilać hurtownię

Hurtownia jest zasilana z dwóch źródeł danych – systemu transakcyjnego platformy Allegro oraz z systemu rejestrowania kliknięć użytkowników. Dane z bazy transakcyjnej nie wymagają konwersji. Problemem jest jednak ich ilość – liczbę krotek w największej tabeli szacuję się w miliardach – oraz zmienność – system odnotowuje 20 tys. operacji na sekundę, tak więc dane pobierane przez kwerendę zmieniłyby się jeszcze przed zakończeniem analizy. Chociaż infrastruktura bazodanowa jest bardzo mocna – pracują tu dwa komputery klasy mainframe, IBM Power 595 – zasilanie bezpośrednio z głównej bazy mimo wszystko generowało zbyt duże obciążenie.
Rozwiązaniem było zastosowanie narzędzia Oracle Data Guard, które cyklicznie wykonuje kopię migawkową produkcyjnej bazy danych, replikowaną przez światłowód (o przepustowości 10 Gb/s) do drugiego centrum obliczeniowego, zlokalizowanego we Frankfurcie. Druga z kopii – wykonywana w trybie tylko do odczytu – służy do zasilania różnych systemów, w tym hurtowni danych. Kopie wykonywane przez Oracle Data Guard są spójne, opóźnione względem platformy produkcyjnej jedynie o kilka minut.
Informacje o odwiedzinach serwisu przez internautów są pobierane z 10 maszyn z bazami MySQL, ładujących ok. 20 mln rekordów co godzinę. Dane te wymagają pewnych prac przygotowawczych przed zasileniem hurtowni. Na tym etapie następuje konwersja typów, związanych z innym formatem przechowywania danych w MySQL i Oracle oraz pocięcie na poszczególne pola, np. IP.

Trzy ważne schematy

W rozwiązaniu BI w Allegro nie wykorzystuje się wielowymiarowych kostek, ale zestaw tabel o strukturze gwiazdy. Przyczyną takiego wyboru jest chęć szybkiego ładowania danych do hurtowni i uproszczenie konstrukcji raportów. Hurtownia jest podzielona funkcjonalnie na trzy części, z osobnymi schematami – Import, Target i Data Mart. Schemat Import służy do zasilenia danymi i zawiera tabele o strukturze optymalizowanej do sprawnego ładowania z zewnętrznych źródeł.
W schemacie Target dane są reorganizowane, zaprojektowano strukturę gwiazdy z wieloma tabelami konstelacji faktów, wokół nich są tabele wymiarów. Struktura ta jest zoptymalizowana pod kątem wielowymiarowych zapytań raportowych. „Nie stosujemy motoru OLAP do udostępniania danych i wyliczania agregatów. Okazało się, że w Database Machine schematy relacyjne działają równie sprawnie, co motor OLAP, ale proces ładowania danych jest wielokrotnie szybszy. Dobrze partycjonowane tabele dają wyniki bardzo szybko, niemal natychmiast” – mówi Rafał Kudliński, menedżer BI w QXL Poland. Największą z tabel faktów jest tabela billingowa, która ma ok. 3 mld rekordów. Załadowanie i odświeżanie takiej ilości danych w modelu OLAP byłoby bardzo czasochłonne. Przy dobrym partycjonowaniu danych na 120 dysków, na partycje dzienne i godzinne, zapytania są sprowadzane do odpytania pewnych wartości i analizy wielokrotnie mniejszych ilości danych.
W trzecim schemacie Data Mart znajdują się agregaty opracowane dla najczęściej wykonywanych raportów. Są tam agregaty dzienne i miesięczne. Dzięki stosowaniu odpowiedniej metodologii modelowania wielowymiarowego, zarówno tworzenie, jak i odpytywanie agregatów trwa bardzo krótko. Zasilanie danymi odbywa się ze schematu Target i trwa nie więcej niż 15% ogółu czasu zasilania hurtowni. Aplikacja korzystająca z Data Mart działa na danych agregowanych, ale w miarę potrzeb, może także zejść na poziom schematu Target.
Proces ten jest całkowicie przezroczysty dla użytkownika, ale szczegółowe zapytanie trwa nieco dłużej.
„Tabele w schemacie Data Mart mają nie więcej niż kilkaset tysięcy rekordów każda i wyniki są dostarczane na bieżąco. Gdy zapytanie musi zejść do poziomu Target, proces obliczeń trwa nieco dłużej, do 30 sekund, ale taki czas wykonania raportu jest akceptowalny.
Predefi niowane zapytania wykraczające poza Data Mart są jednak stosunkowo rzadkie” – mówi Rafał Kudliński.

Analitycy potrzebują różnych danych

Bardzo ważnym powodem pobierania danych spoza agregatów, jest praca analityków.
Mają oni dostęp do narzędzia, które umożliwia wizualne budowanie zapytań ad hoc, gdy standardowe agregaty nie wystarczą. Na etapie projektowania interfejsu nie dało się określić zakresu danych niezbędnych do pracy analityków.
„Początkowo analitycy nie mogli sprecyzować, jakich agregatów potrzebują, bo sami nie wiedzieli, jakie informacje będą im potrzebne. W firmie wykonuje się ok. 200 projektów rocznie, każdy z nich wymaga trochę innych danych. Dostęp do schematu Target oraz sprawne narzędzia do konstrukcji zapytań umożliwiają pozyskanie niezbędnych danych, gdy warunek trzeba założyć na najniższym poziomie agregacji. Przygotowywanie agregatów pod konkretny projekt nie zawsze ma sens” – wspomina Rafał Kudliński.
Jeśli konkretne raporty ze schematu Target są wykonywane przez analityków dość często, informatycy mogą przygotować odpowiednie agregaty, aby przenieść źródło danych raportu do schematu Data Mart.
Kilka takich agregatów już utworzono, dzięki optymalizacji i opracowanym warunkom, działają wielokrotnie szybciej.

Miliardy kliknięć i rekordów

Najwięcej kłopotów sprawiał system rejestrowania kliknięć. Problemy były spowodowane nie tyle ilością danych (250-300 mln krotek dziennie), ale liczbą charakteryzujących je wymiarów. Do importu surowych danych wystarczy odpowiednie przygotowanie tabel, do których są ładowane fakty. Gdy trzeba te same fakty kategoryzować wymiarami, zaczynają się problemy. Chociaż liczba pól nie przekracza kilkudziesięciu, wymiary są wielomilionowe. Jednym z nich jest użytkownik (ok. 15 mln zarejestrowanych), do najważniejszych należą także kategoria (8 tys.), czy rejestrowana lokalizacja (80 tys.). Ponieważ ilość kombinacji byłaby bardzo duża, wyszukiwanie identyfi katorów nie mogło mieć zastosowania. Problem rozwiązano za pomocą grupowania i łączenia tabel, z którymi Oracle Database Machine sobie doskonale radzi, nawet przy bardzo skomplikowanych warunkach. Sumaryczny czas tych operacji w ciągu doby nie przekracza czterech godzin.
Ponieważ system rejestracji kliknięć dostarcza dużo danych, już wdrożono reguły ich retencji. Komplet informacji przechowuje się przez trzy miesiące, starsze dane są agregowane miesięcznie. Według planów ten system będzie wystarczający na najbliższe 10 lat. Przy danych z systemu transakcyjnego, archiwizacja nie jest obecnie potrzebna. Testy wykazały, że nawet trzykrotny wzrost ilości danych przy dwukrotnym wzroście obciążenia nie będzie problemem dla istniejącej infrastruktury.
Obecnie dokonywany jest refaktoring kodu portalu aukcyjnego, aby zredukować ilość zapisów w produkcyjnej bazie danych.
Wzrost ilości danych i obciążenia wpłynąłby tylko na nieznaczne wydłużenie czasu opóźnienia kopii wykonywanej za pomocą Oracle Data Guard.?

Potrzebowaliśmy informacji na temat klienta – czy jest „dobry” i jak prowadzi interesy we wszystkich naszych serwisach? Czy fakt, że na Allegro wydaje niewiele pieniędzy czyni z niego „złego klienta"? Czy nadal jest to „zły klient”, jeśli wiadomo, że ta sama osoba jest wyjątkowo czynnym sprzedawcą na Otomoto i jednocześnie prowadzi interesy w serwisie Molotok. ru? CHRISTIAN MAAR, CIO w QXL Poland
Hurtownia odciąża serwis Jednym z zadań silnie obciążających system, było wyliczanie statystyk i raportów. Przed wdrożeniem BI, zapytania musiały działać kilka godzin, bardzo mocno obciążając system produkcyjny. Obecnie te zadania przeniesiono do hurtowni danych. Dzięki przygotowaniu odpowiednich agregatów, czas obliczenia kilkunastu statystyk skrócono z kilku godzin do kilku minut. Wyliczone agregaty są następnie przenoszone do systemu transakcyjnego. „Przyniosło to istotną korzyść biznesową – zmniejszając obciążenie systemu transakcyjnego o ok. 30 proc., odsuwając w czasie niezbędne inwestycje w wydajność serwisu” – mówi Christian Maar. Takie odciążenie spowodowało podwyższenie rezerwy wydajności, a to bardzo ważna cecha w przypadku portalu, który wykazuje się wysoką dobową i godzinową nierównomiernością obciążenia.
20 mln rekordów o odwiedzinach serwisu Allegro przez internautów jest co godzinę pobieranych z 10 baz MySQL.
Nie stosujemy motoru OLAP do udostępniania danych i wyliczania agregatów. W Oracle Database Machine schematy relacyjne działają równie sprawnie, co OLAP, ale proces ładowania danych jest wielokrotnie szybszy. RAFAŁ KUDLIŃSKI, menedżer BI w QXL Poland
Dane z bazy transakcyjnej nie wymagają konwersji. Problemem jest jednak ich ilość oraz zmienność – system odnotowuje 20 tys. operacji na sekundę, tak więc dane pobierane przez kwerendę zmieniłyby się jeszcze przed zakończeniem analizy.
Drugie dno klikania Hurtownia danych zasilona informacjami o przeglądaniu – w połączeniu z danymi transakcyjnymi – umożliwia wykrycie automatów pobierających zawartość serwisu. „Widzimy, co robią użytkownicy z różnych krajów. Jedni za pomocą botów przeglądają strukturę katalogów, inni pobierają zawartość konkretnych kategorii, aby dokonywać analiz ofert i cen. Część z tych automatów została skatalogowana, inne już zostały zablokowane. Dla nas najważniejszy jest ruch użytkowników powiązany z przeglądaniem serwisu, połączony z późniejszymi transakcjami”- mówi Rafał Kudliński. Analiza kliknięć została wdrożona w sierpniu. QXL Poland zamierza udostępnić usługę, która dzięki niej usprawni działanie sklepów i aukcji wystawianych przez supersprzedawców. Oprócz analizy ruchu, bardzo ważnych informacji dostarczają słowa kluczowe używane przy wyszukiwarce aukcji w serwisie. Te wszystkie informacje zostaną połączone, aby służyć supersprzedawcom przy jak najlepszym dopracowaniu oferty.

źródło: Computerworld (PL) | 15.9.2009 | rubryka: Technologie | strona: 22 | autor: MARCIN MARCINIAK

Liczba komentarzy (0) - Dodaj komentarz do artykułu: