projekt systemu analitycznego z wykorzystaniem hurtowni ... · streszczenie praca opisuje projekt...

Rok Akademicki 2014/2015

Politechnika Warszawska

Wydział Elektroniki i Technik Informacyjnych

Instytut Informatyki

PRACA DYPLOMOWA INŻYNIERSKA

Michał Zdzisław Dębski

Projekt systemu analitycznego z wykorzystaniem

hurtowni danych w systemie Hadoop i narzędzia

analitycznego SAS.

Opiekun pracy:dr inż. Andrzej Ciemski

Ocena: . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Podpis Przewodniczącego

Komisji Egzaminu Dyplomowego

Kierunek: Informatyka

Specjalność: Inżynieria Systemów Informatycznych

Data urodzenia: 1992.12.10

Data rozpoczęcia studiów: 2011.10.01

Życiorys

Michał Dębski ukończył liceum ogólnokształcące im. Tadeusza Kościuszki w Prusz-

kowie w klasie o profilu matematyczno-fizyczno-informatycznym. Wiedział, iż Infor-

matyka jest dziedziną nauki, która będzie wiatrem żagli jego życia, dlatego aplikował

na kilka uczelni posiadających kierunek o takiej specjalizacji. Ze wszystkich ofert na-

uki wybrał Politechnikę i Wydział Elektroniki i Technik Informacyjnych, która później

stała się dla niego drugim domem. W 2013 rozpoczął prace u lidera sektora IT – fir-

mie Samsung Electronics, gdzie jego wytrwałość i profesjonalizm zaprowadziły go na

kolejne stopnie kariery.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Podpis student

Egzamin dyplomowy

Złożył egzamin dyplomowy w dniu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Z wynikiem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Ogólny wynik studiów: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Dodatkowe wnioski i uwagi Komisji: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Streszczenie

Praca opisuje projekt systemu do analizy akcji spółek publicznych zarejestrowa-

nych na giełdach papierów wartościowych. Przedstawione są zasady działania giełdy

jako dziedziny przedmiotu, a także technologie użyte w systemie. System składa się

z hurtowni danych działającej na rozproszonym systemie Hadoop z wykorzystaniem

silnika hurtowni Hive. Jako narzędzie analityczne został wykorzystany SAS, który

umożliwia bardzo zaawansowane możliwości analityczne. W pracy został także zaim-

plementowany proces ETL w języku Java z wykorzystaniem biblioteki Spring Batch

do tworzenia przepływu danych.

Słowa kluczowe: hurtownie danych, giełda papierów wartościowych, Hadoop, Hi-

ve, SAS

Project of analytical system with Hadoop data warehouse and SAS

analytics

Thesis describes design of stock exchange analytical system for analysis and fore-

casting of stock prices. In the paper, stock exchange principles of sale and buy orders

are depicted and technical aspect of used subsystems is explained. System is built on

data warehouse backed by Hadoop with Hive as data warehouse engine. For analyti-

cal software toolkit SAS was chosen, as it allows for very complex analytical queries.

Thesis also describes implementation of ETL process in Java programming language

using Spring Batch library for creating data flow.

Keywords: data warehouse, stock exchange, Hadoop, Hive, SAS

Spis treści

Spis treści 4

Spis rysunków 6

Spis tabel 7

1 Wstęp 8

2 Giełda papierów wartościowych 9

2.1 Funkcjonowanie giełdy . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 Akcje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.2 Indeksy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Terminologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Metody analizy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Hurtownia Danych 14

3.1 Architektura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.1 ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2 Modelowanie wymiarowe . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Hadoop 19

4.1 Architektura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1.1 HDFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1.2 MapReduce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2 Hive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5 SAS 24

5.1 Architektura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.2 Analiza w SAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.3 Hadoop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4

SPIS TREŚCI 5

6 Opis techniczny systemu 28

6.1 Wymagania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.2 Model pojęciowy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6.3 Model logiczny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.3.1 Denormalizacja modelu logicznego . . . . . . . . . . . . . . . . . 33

6.4 Model fizyczny - architektura . . . . . . . . . . . . . . . . . . . . . . . 37

6.4.1 Konstrukcja hurtowni danych . . . . . . . . . . . . . . . . . . . 37

6.4.2 Architektura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.4.3 Źródła danych . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.4.4 ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.4.5 System przetwarzania i przechowywania danych . . . . . . . . . 45

6.4.6 Narzędzie analityczne . . . . . . . . . . . . . . . . . . . . . . . . 45

6.4.7 Środowisko . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

7 Testowanie Systemu 48

8 Przykłady wykorzystania systemu 49

8.0.8 Wykres świecowy . . . . . . . . . . . . . . . . . . . . . . . . . . 49

8.0.9 Prognozowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

9 Podsumowanie 53

Bibliografia 54

Spis rysunków

2.1 Wykres świecowy(candlestick) . . . . . . . . . . . . . . . . . . . . . . . 13

3.1 Diagram hurtowni danych . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2 Schemat gwiazdy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1 Strona administracyjna serwera NameNode. . . . . . . . . . . . . . . . 20

4.2 Diagram obrazujący przetwarzanie Map Reduce. . . . . . . . . . . . . . 22

5.1 Architektura SAS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.2 Panel administratora systemu SAS . . . . . . . . . . . . . . . . . . . . 26

6.1 Diagram schematu hurtowni przed denormalizacją. . . . . . . . . . . . 36

6.2 Diagram schematu hurtowni po denormalizacji. . . . . . . . . . . . . . 40

6.3 Architektura systemu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.4 Proces ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

8.1 Wykres świecowy dla 4 kwartału 2014 dla spółki Yahoo . . . . . . . . . 50

8.2 Aplikacja SASStudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

8.3 Prognoza cen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

8.4 Program SAS Enterprise Guide . . . . . . . . . . . . . . . . . . . . . . 52

6

Spis tabel

6.1 Tabela faktów Transakcje przed denormalizacją. . . . . . . . . . . . . . 32

6.2 Tabela wymiaru Symbole giełdowe przed denormalizacją. . . . . . . . . 33

6.3 Tabela wymiaru Spółek przed denormalizacją. . . . . . . . . . . . . . . 34

6.4 Tabela faktów Lista indeksów przed denormalizacją. . . . . . . . . . . 34

6.5 Tabela faktów Zeznania dochodowe przed denormalizacją. . . . . . . . 35

6.6 Tabela wymiaru Giełdy przed denormalizacją. . . . . . . . . . . . . . . 35

6.7 Tabela faktów Transakcje po denormalizacji. . . . . . . . . . . . . . . 37

6.8 Tabela wymiaru Symbole po denormalizacji. . . . . . . . . . . . . . . . 38

6.9 Tabela faktów Zeznania podatkowe po denormalizacji. . . . . . . . . . 39

6.10 Tabela faktów Lista indeksów po denormalizacją. . . . . . . . . . . . . 39

7

Rozdział 1

Wstęp

Celem pracy jest zaprojektowanie, a następnie implementacja systemu analitycznej

hurtowni danych. Przedmiotem przetwarzania tego systemu są dane instrumentów

finansowych dostępne na giełdzie papierów wartościowych, a dokładniej akcje spółek

publicznych. Dane będą przechowywane przy użyciu rozproszonego systemu Hadoop,

a analizowane z użyciem narzędzia analitycznego SAS.

Praca jest podzielona na logiczne części – rozdziały, które opisują kluczowe zagad-

nienia związane z przedmiotem tej pracy.

Rozdział drugi opisze dziedzinę problemu – spółki publiczne rejestrowane na gieł-

dzie papierów wartościowych. Terminologię używaną w tym kontekście oraz związane

zagadnienia.

Trzeci rozdział omówi koncepcję hurtowni danych, model przepływu danych w

takim systemie i jego zastosowanie.

Następny rozdział dotyczyć będzie rozproszonego systemu Hadoop, który służyć

będzie do przechowywania i częściowo do przetwarzania informacji. Zawarta w nim

też będzie informacja na temat systemu Hive, który jest silnikiem hurtowni danych

działającym na Hadoop.

Piąty rozdział opisze narzędzie analityczne SAS, omówi jego architekturę oraz spo-

sób jego integracji z Hadoop.

Rozdział szósty skupi się na projekcie hurtowni danych oraz jego implementacji z

wykorzystaniem omówionych wcześniej narzędzi w zadanej dziedzinie przedmiotowej.

Kolejny rozdział pokaże przykładowe metody analizy danych opisanej dziedziny

przedmiotowej z wykorzystaniem tego systemu.

W ostatnim rozdziale zawiera się podsumowanie i wnioski płynące z tej pracy.

8

Rozdział 2

Giełda papierów wartościowych

Giełda papierów wartościowych to miejsce, gdzie można wymieniać akcje, obligacje,

czy inne instrumenty finansowe. Podstawową funkcjonalnością giełdy jest zapewnienie

miejsca do sprawiedliwych i sprawnych transakcji kupna i sprzedaży, a także ułatwienie

dostępu do informacji na temat ceny tych instrumentów. Giełda może być fizyczna,

jak na przykład giełda warszawska, lub NYSE, albo elektroniczna jak w przypadku

NASDAQ.[7]

2.1 Funkcjonowanie giełdy

Każda giełda ma wyznaczone dni i godziny w jakich funkcjonuje, to znaczy te,

w których jest możliwe dokonywanie transakcji. Aby dokonać transakcji kupa, bądź

sprzedaży, dwie strony ustalają cenę i liczbę instrumentów, a następnie transakcja jest

rejestrowana i dokonywana. Kiedyś cały ten proces był przeprowadzany ręcznie przez

człowieka, natomiast teraz zajmują się tym głównie komputery. Akcjonariusze jedynie

składają zamówienie kupna/sprzedaży, a cały proces dzieje się automatycznie.

Najsłynniejsze giełdy świata to giełda w mieście New York – NYSE, w Londynie

LSE oraz czysto elektroniczna NASDAQ. Istnieje także giełda w Polsce, to jest War-

szawska Giełda Papierów wartościowych jednak nie ma ona takiego wpływu na rynek

światowy jak NYSE, czy NASDAQ.

2.1.1 Akcje

Jednym z instrumentów finansowych, którym operuje się na giełdzie papierów war-

tościowych są akcje. Reprezentują one częściowe, ograniczone prawo własności do da-

9

Rozdział 2. Giełda papierów wartościowych 10

nej spółki i uprawniają do m. in. podziału w zyskach, czy prawa głosu na walnym

zgromadzeniu.[9]

Akcje są emitowane przez spółkę publiczną kiedy wchodzi ona na giełdę tak zwa-

na emisja założycielska lub przy podwyższaniu kapitału zakładowego to jest emisja

wtórna. W tym przypadku akcje są oferowane po cenie emisyjnej. W przypadku rynku

wtórnego, kiedy transakcje są zawierana między akcjonariuszami ceny są ustalane in-

dywidualnie i zazwyczaj zmieniają się między kolejnymi operacjami. Ceny po jakich są

one przeprowadzane zostają zarejestrowane, na koniec dnia można zobaczyć po jakich

cenach akcje zostały sprzedane na początku dnia, na końcu oraz jaka była najwyższa

i najniższa wartość transakcji.

Akcje odzwierciedlają także wartość firmy, której dotyczą. Jeżeli spółka wyemito-

wała tysiąc akcji, których wartość ostatniej transakcji to trzy złote, oznacza to, że

jest ona warta trzy tysiące złotych. W ten sposób, jeżeli wartość akcji spada, spada

także wartość spółki, przez to można skorelować pewne działania, które podejmuje

firma jako dobre, lub złe w zależności, czy prowadzą one do zwiększenia wartości

przedsiębiorstwa, lub przeciwnie.

2.1.2 Indeksy

Indeks to statystyczna miara zmiany w ekonomi lub na rynku inwestycyjnym. W

przypadku giełdy papierów wartościowych indeks jest to sztuczne portfolio papierów

wartościowych, w tym przypadku akcji, reprezentujący stan rynku, lub jego części.[8]

Każdy indeks definiuje swoją funkcję, która określa jego wartość, dlatego o indeksach

mówi się zazwyczaj w kontekście zmian procentowych, a nie numerycznych. Spółki,

które są brane pod uwagę przy liczeniu indeksu, zazwyczaj są ustalane odgórnie i co

jakiś czas zmieniają się zgodnie z ustaleniami odpowiedniej komisji.

Najpopularniejszymi funkcjonującymi indeksami są S&P 500, DOW oraz w Polsce

WIG20. S&P 500, czyli Standard and Poor’s 500, zawiera pięćset firm o największej ka-

pitalizacji notowanych na NYSE i NASDAQ. Indeks ten jest ważony z poszczególnych

komponentów składających się na niego, a waga jest określana jako stosunek wartości

komponentu do wartości całego indeksu. Kolejnym ważnym wskaźnikiem jest DOW

to znaczy Dow Jones Industrial Average, w skład którego wchodzi 30 największych

amerykańskich przedsiębiorstw notowanych na NYSE i NASDAQ. Indeks ten liczo-

ny jest jako suma wartości akcji poszczególnych komponentów, a następnie dzielony

przez współczynnik nazywany DOW divisor, który jest wyznaczony ręcznie. Polskim

największym wskaźnikiem jest WIG30, który zastąpił WIG20, składa się on z 30 naj-


większych spółek w Polsce i jest liczony podobnie do indeksu S&P 500. Wspomniane

wskaźniki często są utożsamiane ze stanem rynku i kiedy gospodarka jest w złym

stanie indeksy te spadają.

2.2 Terminologia

Akcja (ang. share) – reprezentuje udział w firmie, a także prawo do własności i

podziału w zyskach. Spółki emitują akcje, aby pozyskać, lub zwiększyć kapitał zakła-

dowy.

Spółka publiczna – firma, której akcje zostały dopuszczone do obrotu publicznego.

Spółki nie są ograniczone do pojedynczych rynków, dlatego zdarzają się sytuacje, że

spółka wyemitowała akcje na różnych giełdach.

Indeks – jest to funkcja od wartości akcji spółek publicznych, która zazwyczaj

służy do reprezentowania stanu jakiejś części rynku (na przykład sektor farmaceu-

tyczny), bądź jego całości. Najbardziej znane indeksy to S&P 500, DOW, a także

polski WIG30(dawniej WIG20).

Symbol – często nazywany po angielsku ticker. Jest złożony z kilku znaków i jed-

noznacznie reprezentuje spółkę na wybranej giełdzie. Unikalność symbolu jest ogra-

niczona tylko do danej giełdy, dlatego zdarzają się sytuacje, gdzie ten sam symbol

reprezentuje inne spółki na różnych giełdach.

2.3 Metody analizy

Analizując działania podejmowane przez spółkę, można próbować wywnioskować w

jaki sposób będzie się zmieniać jej wartość, dzięki czemu, można odgadnąć kiedy należy

kupić, bądź sprzedać jej akcje. Do tej analizy można dodać analizę historyczną, wiedząc

kiedy i jakie decyzje zostały przez przedsiębiorstwo podjęte, możliwe jest skorelowanie

danych historycznych z możliwymi danymi przyszłymi. Do tego nie rzadko istnieją

powiązania między firmami – jeżeli, którejś wiedzie się gorzej, to jest jej wartość spada,

prawdopodobnie spadnie też wartość spółki od niej zależnej. Te, a także inne przypadki

są możliwymi przedmiotami analizy transakcji dokonywanych na akcjach.

Często przeprowadza się także analizę indeksów, ponieważ analizując przeszłe tren-

dy sektora opisywanego przez dany wskaźnik, można wywnioskować jaka będzie jego

reakcja na aktualne zmiany. Ponieważ indeksy zazwyczaj składają się ze spółek, które


radzą sobie najlepiej na rynku, nierzadko tworzy się portfel, który składa się z firm

wliczanych do popularnych wskaźników.

Najczęściej do analizy giełdowej używa się wykresów świecowych Rys. 3.1. W przy-

stępny dla oka sposób wizualizują jak zmieniały się ceny akcji w wybranym przedziale

czasu. Na takie wykresy często nakłada się różne wskaźniki, które reprezentują trendy,

albo inne właściwości danych akcji. Popularnymi funkcjami wykorzystywanymi są:

Średnia krocząca to średnia arytmetyczna biorąca pod uwagę n ostatnich okresów.

Do tego stosuję się wersję ważoną, gdzie okresy są brane pod uwagę z wagami

malejącymi arytmetycznie oraz wykładniczą średnią kroczącą, gdzie znaczenie

kolejnych okresów maleje wykładniczo.

Wskaźnik względnej siły zawiera informację o szybkości spadku, lub wzrostu cen.

Akcje które miały więcej lub silniejsze wzrosty, będą miały wyższy wskaźnik,

natomiast w przypadku częstszych lub silniejszych spadków niższy.

MACD (Moving Average Convergence / Divergence) bada zbieżności i roz-

bieżności średnich ruchomych. Jest różnicą wartości długoterminowej i krótko-

terminowej średniej wykładniczej.


Rysunek 2.1: Wykres świecowy (ang. candlestick) przedstawiające zagre-

gowane transakcje dla danego dnia. Czerwone wypełnienie oznacza spadek

danego dnia, a białe wzrost. Cienkie linie oznaczają najwyższą i najniższa

cenę danego dnia. Poniżej znajduje się także wykres kolumnowy przedsta-

wiający liczbę akcji na jaką przeprowadzono w sumie transakcje.

Rozdział 3

Hurtownia Danych

Hurtownie danych (ang. data warehouse) to systemy zoptymalizowane na raporto-

wanie i analizę danych. Są one często zorientowane na pewien wycinek rzeczywistości

i zbierają dane z systemów operacyjnych nazywanymi źródłami danych. Hurtownia

danych to wyższy poziom abstrakcji niż relacyjna baza danych, które służą do obsługi

aktualnych procesów w firmie. W hurtowni przetrzymywane są informacje aktualne,

ale także historyczne i służą najczęściej do wspomagania decyzji na szczeblu mena-

dżerskim.

Systemy operacyjne, z których zasilana jest informacją hurtowania danych, służą

do obsługi procesów, które są bezpośrednim celem korporacji – sprzedaży. Systemy

operacyjne to swego rodzaju motor przedsiębiorstwa, przyjmują nowe zamówienia,

rejestrują użytkowników, rozliczają transakcje. Użytkownicy takich systemów najczę-

ściej mają do czynienia z jednym rekordem na raz i wykonują takie same operacje

wielokrotnie.

Z drugiej strony użytkownicy hurtowni danych obserwują jak ten motor pracuje.

Liczą aktualne transakcje i porównują z poprzednim okresem rozliczeniowym, próbują

znaleźć odpowiedzi na takie pytania jak, dlaczego użytkownik wybrał ten produkt,

co mu się w nim nie podobało. Analitycy wykorzystujący hurtownie danych działają

na ogromnych zbiorach danych, obejmujący setki tysięcy rekordów, a każde zapytanie

znacząco różni się od poprzedniego, ponieważ próbuje znaleźć odpowiedź na zupełnie

inne pytanie.

Hurtownia jak nowy rodzaj systemu w przedsiębiorstwie stara się odpowiedzieć

na inne potrzeby biznesu niż dotychczasowe systemy, dlatego można sformułować dla

nich nowy zbiór wymagań[1]:

14

Rozdział 3. Hurtownia Danych 15

Dane muszą być przystępne. Model danych zapisany w hurtowni danych musi być

w takiej formie, aby był on zrozumiały także dla człowieka, który nie jest bez-

pośrednio związany z informatyką. Dane muszą być konsekwentnie i zrozumiane

opisane, ponieważ analityk będzie chciał dzielić i łączyć je w potencjalnie nie-

skończone możliwości. Narzędzie używane do komunikacji z bazą musi być także

łatwe w użyciu, a wyniki zwracane w jak najkrótszym czasie.

Informacja musi być reprezentowana konsekwentnie. Hurtownia zawiera da-

ne zebrane z wielu różnych systemów operacyjnych i z zewnętrznych źródeł.

Dane muszą być wiarygodne, dlatego przed załadowaniem ich do systemu trzeba

być pewnym, że po oczyszczeniu i transformacjach są gotowe do dla użytkownika

systemu. Informacje z różnych systemów powinny się zgadzać, a jeżeli mają tą

samą nazwę to muszą znaczyć to samo.

Hurtownia powinna być odporna na zmianę. Dane i procesy systemów opera-

cyjnych zmieniają się, nie jest możliwe uniknięcie tego. Hurtownia danych musi

być przygotowana na obsługę zmian. Zmiany w hurtowni powinny być łagodne,

to znaczy nie powinny sprawić, że dotychczasowe dane przestaną być ważne, ani

że aktualne aplikacje przestaną działać.

Dane muszą być chronione. W hurtowni bardzo często przechowywane są kluczo-

we dane dla biznesu przedsiębiorstwa. Takie informacje jak ceny, klienci, czy

transakcje to dane, które mogą być bardzo szkodliwe w przypadku ujawnienia.

Dlatego bezpieczeństwo systemu powinno być efektywnie zarządzane.

Hurtownia powinna być bazą do podejmowania lepszych decyzji. Dane zapi-

sywane w hurtowni powinny wspierać podejmowane decyzje. Jest tylko jeden

prawdziwy wynik generowany przez hurtownie danych – decyzja, która została

podjęta po zaprezentowaniu faktów z hurtowni. Najlepszym opisem hurtowni

danych jest system wspierania podejmowania decyzji.

3.1 Architektura

System hurtowni danych składa się z czterech kluczowych komponentów. Systemów

operacyjnych, które są źródłami danych, operacyjnego magazynu danych, w którym

dane są oczyszczane i przygotowywane do załadowania, właściwej hurtowni danych

oraz narzędzi do analizy zebranych danych.


Rysunek 3.1: Diagram przedstawia cztery najważniejsze komponenty

hurtowni danych oraz przepływ danych między nimi.

Systemy operacyjne, jak już zostało wspomniane, to systemy, które napędzają

biznes przedsiębiorstwa. Zazwyczaj są poza hurtownią danych i projektant nie ma nad

nimi żadnej kontroli. Źródła danych, którymi są systemy operacyjne, nie przechowują

danych historycznych, bądź tylko informacje z niedalekiej przeszłości. Często dane w

takim systemie są przechowywane w specyficznym dla systemu formacie i niezbędne

jest uprzednie oczyszczenie danych.

Operacyjne magazyny danych służą jako strefa przejściowa między hurtownią da-

nych a źródłami. W tym miejscu następuje proces ETL, jest to operacja, która prze-

kształca wszystkie dane wejściowe, z niekompatybilnych informacji natywnych dla

systemów operacyjnych do wspólnego formatu używanego w hurtowni danych. Dane

w tej części nie są dostępne dla użytkowników, a jedynie służą do załadowania danych

do hurtowni.

Warstwy prezentacji – samej hurtowni danych, gdzie dane są zorganizowane, posor-

towane i udostępnione w optymalny sposób dla użytkowników narzędzi analitycznych.

Części hurtowni danych dzieli się na serie data martów, które w uproszczonym po-

jęciu reprezentują pojedynczy proces biznesowy. Dane w warstwie prezentacyjnej są

zapisane przy pomocy modelowania wymiarowego, gdzie informacja jest podzielona na

wymiary, które je opisują i fakty, które reprezentują pojedyncze wystąpienie jakiegoś

zdarzenia.

Ostatnim komponentem hurtowni danych są narzędzia analityczne. Udostępniają

one możliwość wykonywania zapytań na danych przechowywanych w hurtowni. Takie

narzędzie może być bardzo proste, jak na przykład zapytanie SQL, ale może także

może to być kolejny system jak na przykład SAS, który jest opisany w kolejnym

rozdziale.


3.1.1 ETL

Bardzo ważnym procesem, który zachodzi w hurtowni danych jest proces ETL,

czyli ekstrakcja, transformacja i ładowanie (ang. extract, transform and load). Jest on

bardzo istotny dla hurtowni, ponieważ dzieje się on na styku systemów operacyjnych

z warstwą prezentacyjną – hurtownią.

Ekstrakcja jest relatywnie prostym zadaniem, ponieważ polega na załadowaniu

interesujących z punktu widzenia hurtowni informacji. Jednak ta operacja może nie

być trywialna, jeżeli system, z którego należy pobrać dane nie posiada wygodnych

zewnętrznych interfejsów do komunikacji, albo jeżeli jest to system zewnętrzny poza

zasięgiem przedsiębiorstwa.

Transformacja zbiorów danych polega na przekształceniu informacji, która może

być zapisana w formacie natywnym dla źródła do formatu czytelnego dla hurtowni.

Przy tym procesie dodatkowo dane się oczyszcza z niepotrzebnych informacji oraz

uzupełnia w miarę możliwości o te brakujące. Później są one zapisywane w taki sam

sposób, aby informacje opisujące to samo były w ten sam sposób opisane, dzięki temu

informacje można w miarę potrzeb wstępnie zredukować bądź zagregować.

Proces ładowania polega na wpisaniu przekształconych informacji do docelowej

hurtowni danych. Operacja ta nierzadko jest odkładana w czasie tak, aby nie zakłócić

normalnego działania systemu i nie spowolnić zapytań wykonywanych do systemu.

W procesie ETL często wykorzystuje się relacyjne bazy danych, które używają

modelu relacyjnego, aby łatwiej można było przeprowadzić transformację. Jednak po

załadowaniu do hurtowni używany jest model wymiarowy.

3.2 Modelowanie wymiarowe

W hurtowniach danych stosuje się modelowanie odmienne od relacyjnego – mo-

delowanie wymiarowe. W tym koncepcie dane są podzielone na dwie tabele: faktów

i wymiarów. Fakty reprezentują jakieś zdarzenie, które wielokrotnie możemy zaob-

serwować, na przykład sprzedaż, inaczej mówiąc fakt jest miarą biznesową. Fakty są

opisywane przez wymiary, które zawierają informacje na temat faktów, są to zbiory,

które są swego rodzaju tekstowymi opisami faktów.

Fakty zawierają przedmiot analizy i są powodem istnienia hurtowni danych. Zaj-

mują większość miejsca w hurtowni, tabele faktów mają miliony wierszy, ale za to małą

liczbę kolumn, które w większości są kluczami obcymi do tabeli wymiarów. Najważ-

niejszymi atrybutami faktów są atrybuty numeryczne, które można łatwo agregować


Rysunek 3.2: Na diagramie widać przykładowy schemat gwiazdy mode-

lujący sprzedaż produktów. Tabele Sklepy, Produkty i Czas to wymiary i

opisują tabelę faktów – Sprzedaż.

i grupować, atrybuty tekstowe byłoby bardzo trudno analizować przy takiej ilość re-

kordów. Fakt znajduje się na przecięciu wymiarów i zazwyczaj wyraża związek wiele

do wielu, jego klucz jest złożony i zazwyczaj składa się z kluczy obcych do tabeli

wymiarów, nie stosuje się klucza sztucznego.

Tabele wymiarów są integralną częścią faktów i zawierają opisy faktów. W dobrze

zaprojektowanej hurtowni tabela wymiarów ma mało wierszy za to posiada bardzo du-

żo atrybutów. Najczęściej wymiary posiadają klucz główny złożony z jednego atrybu-

tu, przez który jest połączony z faktem. Atrybuty wymiarów są podstawą do tworzenia

zapytań do hurtowni danych i są kluczowym składnikiem operacji dokonywanych na

danych.

Jeżeli połączymy te dwa pojęcia i utworzymy tabelę faktów, reprezentującą ja-

kąś miarę biznesową, otoczoną wymiarami, czyli opisami tej miary uzyskamy schemat

gwiazdy. Ten model jest bardzo popularny, ponieważ w takim schemacie mamy bardzo

mało złączeń, dlatego jest on szybki i zazwyczaj preferowany. Kolejnym schematem

wykorzystywanym w modelowaniu hurtowni danych jest schemat płatka śniegu, wy-

różnia go od modelu gwiazdy to, iż wymiary są znormalizowane. Tworzą hierarchie

tabel, dzięki czemu łatwiej modyfikować taką strukturę, niestety przez tą budowę spa-

da wydajność zapytań, ponieważ zwiększona jest liczba wymaganych złączeń. Trze-

cim używanym schematem jest konstelacja faktów, stanowiący kombinację schematów

gwiazd, które dzielą niektóre wymiary.

Rozdział 4

Hadoop

Apache Hadoop to otwarte oprogramowanie rozwijane przez organizację Apache.

Jest to pakiet bibliotek, które umożliwiają rozproszone przetwarzanie bardzo dużych

zbiorów danych na klastrach serwerowych wykorzystując proste modele programistycz-

ne. Był projektowany z myślą o łatwym skalowaniu do klastrów posiadających wiele

tysięcy węzłów, z czego każdy oferuje lokalne przetwarzanie i przestrzeń na dane.

Hadoop nie polega na rozwiązaniach sprzętowych przy zapewnianiu dostępności, jest

zbudowany tak, aby warstwa aplikacyjna była w stanie samodzielnie wykryć i obsłużyć

awarię.

4.1 Architektura

Rdzenną część Hadoop można podzielić na dwie logiczne części. Zajmującą się

przechowywaniem danych oraz na model przetwarzania. Tym pierwszym zajmuje się

HDFS – rozproszony system plików, który ma spełnić podstawowe postulaty Hado-

op oraz stworzyć bazę, na której toczyć się będzie przetwarzanie. Drugą częścią jest

pakiet przetwarzający, który zajmuje się rozdystrybuowaniem pracy na węzły w jak

najbardziej optymalny sposób, wykorzystując do tego między innymi nowy model

przetwarzania informacji.

4.1.1 HDFS

HDFS, czyli Hadoop File System to rozproszony system plików. Został on za-

projektowany z myślą o przechowywaniu bardzo dużych plików to jest o rozmiarach

liczonych w setkach gigabajtów, lub terabajtach. Strumieniowym wzorcu dostępu do

danych, czyli dane są zapisywane raz, ale czytane wielokrotnie i często w całości, jest

19

Rozdział 4. Hadoop 20

to bardzo częsty wzorzec przy zbiorach danych, które zostały wygenerowane, bądź

skopiowane z zewnętrznych źródeł. Oraz o działaniu na zwykłym i tanim sprzęcie ser-

werowym. HDFS nie wymaga specjalistycznego sprzętu, możliwe jest aby w klastrze

były komputery różnej klasy od różnych dystrybutorów. W takich warunkach awa-

ria pojedynczego węzła jest pewna, ale HDFS jest w stanie poradzić sobie z takim

problemem bez zauważalnego dla użytkownika opóźnieniem.

Rysunek 4.1: Strona administracyjna serwera NameNode. Widać na niej

zużycie pamięci, ale także wykorzystane miejsce w HDFS.

Węzły będące zarejestrowane w klastrze udostępniają swoją przestrzeń dyskową

na potrzeby HDFS, nazywane są one DataNode. Centralną częścią tego systemu jest

węzeł NameNode, który przechowuje informacje na temat położenia plików na węzłach

oraz zajmuje się dystrybucją plików w taki sposób, aby klaster był jak najbardziej od-

porny na awarię. Dobrze skonfigurowany NameNode posiada informacje o strukturze

serwerowni i wie, które węzły znajdują się w ramach jednej szafy serwerowej. Dzięki

temu stara się on tak rozmieścić pliki, które są odpowiednią do konfiguracji liczbę razy

duplikowane, aby nawet w przypadku awarii przełącznika, albo zasilania szafy, praca

mogła dalej być wykonywana. Dodatkowym węzłem mającym zapobiegać utracie da-

nych jest Secondary NameNode, który wbrew nazwie, nie jest serwerem zapasowym


NameNode. Przechowuje on natomiast kopie wszystkich informacji, które znajdują

się na podstawowym węźle i jeżeli dojdzie do jego awarii, wystarczy wymiana węzła.

Nowy NameNode pobierze wszystkie informacje od wersji Secondary i klaster jest z

powrotem gotowy do pracy.

Pliki na HDFS są przechowywane w formie bloków fizycznych. Plik jest dzielony na

ustaloną liczbę bajtów, standardowo 64, lub 128 MB, następnie bloki są replikowane,

a później wysyłane do węzłów posiadających miejsce na przyjęcie nowych bloków.

NameNode stara się przy okazji tak umiejscowić bloki, żeby jednocześnie umieścić je

możliwie blisko siebie, względem topologii sieciowej, a jednocześnie tak rozproszyć,

aby nawet awaria dużej części klastra nie spowodowała niemożliwość wykonywania

operacji.

4.1.2 MapReduce

MapReduce to model programowania, który umożliwia rozproszenie obliczeń na

klastrze serwerowym. Programy pisane w tym modelu nie są trywialne, ale dają moż-

liwość analizowania ogromnych zbiorów danych w wystarczająco dużej grupie serwe-

rów. MapReduce dzieli przetwarzanie na dwie podstawowe fazy: fazę mapującą i fazę

redukującą. Każda z tych faz na podstawie par klucz wartość generuje kolejne takie

pary. Pary wejściowe i wyjściowe jak i funkcje, które realizują te fazy są definiowane

przez programistę. Program MapReduce, który jest wykonywany na klastrze zostaje

podzielony między węzły, z których każdy wykonuje część mapującą i redukującą.

Proces wykonywania takiego programu przedstawia się następująco. Dane wejścio-

we zostają podzielone na bloki logiczne (w odróżnieniu od HDFS, gdzie podział jest

fizyczny), następnie każdy taki blok jest przekazywany jest mapowany do klucza i

przekazywany do funkcji mapującej, która wykonuje obliczenia i generuje wyniki po-

średnie w formie par klucz-wartość. Następnie te wyniki zostają posortowane według

zdefiniowanego wcześniej algorytmu, a później zostają wysłane do funkcji redukują-

cej. Funkcja ta ma za zadanie zredukować, na przykład poprzez agregację, wyniki

częściowe i utworzyć wynik końcowy.

Przykładowym programem MapReduce jest program do zliczania maksymalnej

temperatury w regionie w poszczególnych latach[2]. Pliki wejściowe zawierające da-

ne pomiarów z danego roku ze wszystkich stacji pomiarowych w regionie, mają one

określoną strukturę. Funkcja mapująca jako argument przyjmuje numer linii oraz jej

zawartość. Jej zadaniem jest znalezienie temperatury powietrza oraz roku zawartych

w linii i wyemitowanie pary rok-temperatura. Następnie wyniki z funkcji mapujących


Rysunek 4.2: Diagram obrazujący przetwarzanie Map Reduce.

są sortowane według klucza – rok i grupowane. Takie pary są przekazywane do funkcji

redukujących, która z listy temperatur dla danego roku wybiera maksymalną i zapisuje

do wyniku końcowego. Rysunek 4.2 pokazuje diagram wykonania tego programu.

Aby wykonać przetwarzanie MapReduce na klastrze Hadoop klient wysyła program

na serwer JobTacker. Zajmuje się on dystrybucją zadań i przetrzymuje informacje na

temat węzłów, które mają wolne miejsce na przetwarzanie. TaskTracker, który wy-

konuje zadania ma przydzieloną liczbę miejsc na operacje mapowania i redukowania.

Na początku pozycje są wypełniane zadaniami mapującymi, aby skorzystać z lokal-

ności przetwarzania, czyli wykonywać operacje tam gdzie dane są zapisane. W drugiej

kolejności dodawane są operacje redukujące. Jeżeli węzły posiadające dane nie mają

wolnego czasu na przetwarzanie zadanie zostaje zlecone innemu węzłowi, który znaj-

duje się blisko tych serwerów w sensie topologii sieci. Każdy TaskTracker w trakcie

wykonywania wysyła periodycznie swój status do JobTrackera. Jeżeli jeden z węzłów,

któremu zostało przydzielone zadanie przestanie wysyłać informacje o pracy, którą

wykonuje uznaje się, że nastąpiła awaria i zadanie, które miał wykonać zostaje przy-

dzielone innemu komputerowi z klastra. Na koniec pracy JobTracker aktualizuje swój

status, a użytkownik może odczytać wynik. W nowszej wersji Hadoop JobTracker

został zastąpiony bardziej zaawansowanym i bardziej zgeneralizowanym zarządcą za-

sobów YARN. Jego główną zaletą jest to, że zadania MapReduce nie są wykonywane

bezpośrednio na nim, ale uruchamiana jest dla każdego nowa instancja procesu, który

jest bardzo podobny w działaniu do JobTrackera.

4.2 Hive

Hive bazując na Hadoop umożliwia nadanie danym znajdującym się na HDFS

struktury, a także udostępnia znany interfejs, czyli SQL w postaci dialektu HQL. Hive

jest to narzędzie do tworzenia hurtowni danych, która będzie wykorzystywać wszystkie


zalety modelu przetwarzania danych oraz udostępni znane metody tworzenia i zarzą-

dzania danymi w Hadoop. W Hive tworzymy tabele, którym nadajemy odpowiednie

kolumny i typy, taka struktura jest następnie przechowywana na klastrze. W tym mo-

delu w odróżnieniu od zwykłych systemów bazodanowych dane ładowane do hurtowni

nie są weryfikowane pod kątek poprawności, dzieje się to dopiero w momencie od-

czytu. Dzięki takiemu podejściu ładowanie bardzo dużych zbiorów danych jest dużo

szybsze. Niestety przez to musi nastąpić weryfikacja w trakcie odczytu i jeżeli dane są

niepoprawne w ich miejscu pojawi się wartość null.

W Hive tabele są umieszczane na systemie w formie zwykłych plików i możliwy

jest ich odczyt za pomocą zwykłych programów MapReduce. Pliki mogą mieć postać

tekstową a także binarną w postaci plików sekwencyjnych. Udostępniony jest także

mechanizm partycjonowania danych w celu przyspieszenia ich odczytu. W trakcie de-

finiowania schematu hurtowni określa się, które kolumny są partycjami, a Hive tworzy

dla ich wartości osobne katalogi, przy takim rozwiązaniu, dla określonych wartości

nie jest potrzebny pełen skan bazy, a tylko jednego podkatalogu. Następnym me-

chanizmem przyspieszającym operacje jest dzielenie danych na kubełki na podstawie

zakodowanej wartości wybranej kolumny. Jest to najbardziej przydatny mechanizm w

przypadku złączeń, ale także przy wybieraniu próby danych.

Dane na temat schematu bazy danych oraz użytkowników nie są przechowywane

na klastrze tylko w osobnej bazie relacyjnej. Dzięki takiemu rozwiązaniu zapytania do

hurtowni są dużo szybsze gdyż nie trzeba wysyłać zadań do klastra w celu załadowania

schematu tabel. Hive udostępnia także usługę o nazwie hiveserver, która umożliwia

łączenie się za pomocą standardowych interfejsów bazodanowych takich jak JDBC do

hurtowni.

Rozdział 5

SAS

SAS to lider w dziedzinie analityki biznesowej, posiada produkty związane z bu-

siness intelligence, ale także inne produkty i usługi dotyczące samej analityki. Jego

głównym produktem jest system SAS, który posiada wszystko czego potrzebuje kor-

poracja aby wydajnie czerpać informacje ze swoich danych operacyjnych.

5.1 Architektura

System SAS dzieli się na trzy główne komponenty: warstwę serwerową(server tier),

warstwę pośrednią (middle tier) i warstwę kliencką(client tier) oraz źródła danych.

Pierwsze dwie warstwy są instalowane na serwerach, natomiast warstwa kliencka jest

instalowana lokalnie u użytkownika systemu. Każda z tych warstw ma konkretnie wy-

dzielone zadania i zajmuje się innymi operacjami w systemie. Źródłami danych mogą

być zewnętrzne bazy danych, struktury danych SAS, a także odpowiednie systemy do

przechowywania danych SAS, w tym kostki OLAP.

Warstwa serwerowa zajmuje się przechowywaniem i przetwarzaniem danych zwią-

zanych z działaniem systemu oraz wykonywaniem zadań analitycznych. Pierwszym

zadaniem zajmuje się SAS Metadata Server, w nim zapisane są informacje na temat

użytkowników, innych serwerów w systemie, czy zewnętrznych źródeł danych. Jest

on najważniejszą częścią systemu, ponieważ bez jego działania niemożliwe jest funk-

cjonowanie systemu. SAS umożliwia dostęp do metadanych z zewnątrz przy użyciu

specjalnego programu, albo API. Wykonywaniem zadań analitycznych, generowaniem

raportów oraz wykresów zajmują się specjalizowane procesy takie jak SAS Workspa-

ce Server, SAS Forecast Server, czy SAS OLAP Server. Należy zaznaczyć iż warstwa

serwerowa jest przygotowana do skalowania poziomo i jeżeli moc obliczeniowa tej war-

24

Rozdział 5. SAS 25

Rysunek 5.1: Architektura SAS.[5]

stwy jest niewystarczająca, możliwe jest skonfigurowanie dodatkowych komputerów,

które będą równoważyć obciążenie. Aplikacje z pozostałych warstw komunikują się z

warstwą serwerową w celu uzyskania metadanych oraz wykonania zadań analitycznych.

Warstwa pośrednia udostępnia środowisko wykonania dla aplikacji webowych. Pro-

dukty takie jak SAS Web Report Studio i SAS Information Delivery Portal działają w

tej warstwie. Użytkownicy systemu poprzez przeglądarkę mogą zobaczyć aktualne ra-

porty, wykresy, a także wyniki programów analitycznych. Poprzez specjalne aplikacje

webowe – portlety, mogą zmieniać parametry prezentowanych wyników. Aplikacje z

warstwy pośredniej łączą się z warstwa serwerową w celu uzyskania informacji do uwie-

rzytelnienia użytkowników oraz do wykonania programów analitycznych. Ta warstwa

także może być skalowana w poziomie poprzez dodanie nowych serwerów webowych.

Mechanizm równoważenia obciążenia będzie rozdzielał zapytania miedzy odpowiednie

maszyny.

Ostatnia warstwa - kliencka jest instalowana lokalnie u użytkownika. Zapewniają

natywne, ale także webowe aplikacje do tworzenia raportów, generowania zapytań, czy

wykonywania programów na serwerze. Dostarcza informacji i zapewnia funkcjonalność

business intelligence dla użytkowników każdego szczebla przedsiębiorstwa.

Źródła danych w SAS składają się z natywnego formatu – SAS data sets (tables)

są to pliki tworzone, zarządzane i przetwarzane bezpośrednio przez serwery SAS. Ze-

wnętrze źródła danych innych producentów jak na przykład baza danych Oracle, czy

klaster Hadoop z hurtownią danych Hive. Do połączenia z tymi źródłami danych naj-

częściej wymagany jest oddzielny moduł, który umożliwi komunikację serwerów SAS

Rozdział 5. SAS 26

Rysunek 5.2: Panel administratora systemu SAS

z serwerami tego systemu, a dane tam zawarte będą widoczne dla użytkownika jak

natywne. Jako źródła danych dostępny jest także specjalistyczny silnik do wydajnego

przetwarzania dużych zbiorów danych SAS oraz kostki wielowymiarowe.

5.2 Analiza w SAS

SAS udostępnia graficzne narzędzia analityczne takie jak SAS Enterprise Guide,

czy SAS Data Integration Studio. Analityk może łącząc bloki tworzyć przepływy in-

formacji i odpowiednio generować wyniki. Udostępniony jest też interfejs do progra-

mowania. Użytkownik pisząc programy w specjalistycznym języku SAS, może odpo-

wiednio analizować dane Główną zaletą tego scentralizowanego rozwiązania jest to, że

wszystkie zewnętrzne dla SAS zbiory danych są widoczne jako natywne. Do ich obsługi

nie trzeba pisać oddzielnych funkcji, ponieważ używając odpowiedniego modułu SAS

potrafi wykonywać wszystkie wbudowane funkcje przy użyciu tych danych. Trzeba za-

znaczyć iż w wielu przypadku możliwe jest użycie natywnych dla formatu interfejsów

na przykład gdy mamy do czynienia z Hadoop możemy użyć HQL do komunikacji z

Hive.

Rozdział 5. SAS 27

Same programy SAS składają się z dwóch typów kroków(z angielskiego step), data

step i proc step. Data step pozwala na dodawanie, modyfikowanie i usuwanie danych ze

zbiorów danych. Są to podstawowe operacje, które pozwalają na załadowanie danych

do programu w celu późniejszego przetworzenia. Samo działanie na danych dzieje się w

proc step. Proc step wykonuje odpowiednie procedury SAS. Służy on do analizowania,

przetwarzania danych, a także do generowania raportów i wykresów. SAS czerpie wiele

z innych języków programowania i dostępne są w nim takie podstawowe operacje jak

przetwarzanie warunkowe, zmienne, pętle czy tworzenie procedur.

5.3 Hadoop

Aby SAS komunikował się z klastem Hadoop należy najpierw zarejestrować go jako

zewnętrzne źródło danych w serwerze metadanych SAS – SAS Metadata Server. Po

wprowadzeniu go do systemu możliwe jest wykonywanie podstawowych procedur SAS i

wykonywanie programów MapReduce, czy języka skryptowego dla Hadoop – pig. Żeby

dane z Hadoop były widoczne jak natywne dla SAS niezbędne jest zainstalowanie na

klastrze systemu hurtowni danych Hive oraz posiadanie specjalnego modułu SAS. Po

skonfigurowaniu połączenia SAS łączy się z Hadoop poprzez Hiveserver, a tabele z

klastra są widoczne w oprogramowaniu.

Rozdział 6

Opis techniczny systemu

Celem tego systemu jest ułatwienie wykonywania analizy papierów wartościowych

wymienianych na giełdzie. Kluczowe jest umożliwienie wykonywania przetwarzania na

bardzo dużych zbiorach danych to znaczy przy użyciu wielu zmiennych o szerokim za-

kresie historycznym transakcji. Ma to udostępnić przeprowadzanie zapytań, których

wykonywanie na relacyjnych bazach danych, bądź na hurtowniach o innej architek-

turze byłoby nieefektywne. Dodatkowo interfejs analityczny powinien być możliwie

wygodny w użyciu i łatwy w obsłudze także dla osób, które mogą nie być bezpośred-

nio związane z informatyką, ale za to potrafiące bardzo dobrze analizować informacje

przechowywane w tym systemie.

System stworzony w ramach tej pracy ma za zadanie wspieranie podejmowania

decyzji przy inwestowaniu w papiery wartościowe spółek – akcje. Kluczowymi zasto-

sowaniami analitycznymi dla tego systemu są:

• Wyszukiwania korelacji między cenami akcji poszczególnych spółek.

• Znajdowania powtarzających się wzorców w historii.

• Modelowanie optymalnych portfeli, lub własnych wskaźników.

• Przewidywanie trendów.

Można też znaleźć zastosowania, które są charakterystyczne dla systemu informo-

wania kierownictwa:

• Informowanie kierownictwa o stanie prowadzonych portfeli.

• Ostrzeganie przy podejmowanych ryzykownych – rokujących stratę, inwesty-

cjach.

28

Rozdział 6. Opis techniczny systemu 29

Dzięki takiemu systemowi analitycy mają dużą swobodę w definiowaniu własnych

modeli – mogą mieć bardzo duże zbiory danych jak i dużą moc obliczeniową do wy-

konywania zapytań, ale także dla ich przełożonych mogą zostać udostępnione metody

weryfikowania i kontroli poszczególnych analityków. Do takiego systemu można sfor-

mułować szereg wymagań, które powinien spełnić, aby umożliwić taką funkcjonalność.

6.1 Wymagania

System musi umożliwiać wykonywanie skompilowanych zapytań analitycznych w

rozsądnym czasie. Przetwarzanie i przechowywanie tych informacji musi być obłożone

pewnymi minimalnymi kryteriami obowiązkowymi. Dlatego aby być w stanie sprostać

takim zadaniom system musi spełniać następujące wymagania funkcjonalne:

• Przechowywanie danych giełdowych dla co najmniej kilku tysięcy przedsiębiorstw.

• Przetwarzanie zawierające w zapytaniu kilkanaście spółek o wieloletnim zakresie

historycznym.

• Równoległe przetwarzanie wielu zapytań.

• Możliwość tworzenia własnych funkcji przetwarzających.

• Tworzenie wykresów i raportów na podstawie otrzymanych wyników.

• Autoryzacja użytkowników i bezpieczeństwo danych.

• Interfejs webowy do łatwego dostępu do informacji z systemu.

Te kryteria muszą być także uzupełnione o wymagania niefunkcjonalne, które za-

pewnią sprawne działanie systemu oraz umożliwią korzystanie przez osoby nie będące

bezpośrednio związane z informatyką:

• Udostępniać prosty, ale posiadający duże możliwości interfejs do obliczeń anali-

tycznych.

• Maksymalnie długi czas działania bez przerw na działania administracyjne.

• Odporność na awarie.

• Możliwość łatwego skalowania warstwy przetwarzającej i przechowującej dane.


Podsumowując system ten musi udostępniać interfejs odpowiedni dla analityka

umożliwiający przetwarzanie bardzo dużych zbiorów danych. Dlatego odpowiednie

jest połączenie narzędzia analitycznego SAS z systemem przetwarzania rozproszonego

Hadoop. SAS zapewni znany i wygodny dla analityka interfejs aplikacyjny, natomiast

warstwą przetwarzającą i przechowującą dane zajmie się Hadoop z wykorzystaniem

Hive.

6.2 Model pojęciowy

Aby sprostać wymaganiom analitycznym systemu, hurtownia będzie koncentro-

wać się na akcjach, które są wymieniane na giełdach papierów wartościowych, dlatego

podstawowym pojęciem w hurtowni będzie transakcja. Reprezentuje ona podstawo-

wą i kluczową miarę na giełdzie – cena po jakiej są sprzedawane i kupowane akcje

danej spółki. Jako, że często nie jest wymagane posiadanie danych z dokładnością

do pojedynczych transakcji, a także nie są dostępne darmowe źródła takich danych,

informacje o transakcjach będą przetrzymywane w różnych stopniach zagregowania w

czasie. Do danych w ten sposób zgrupowanych trzeba dodać atrybuty, które pozwolą

lepiej analizować takie dane. Standardowo do takich informacji dodaje się atrybuty,

cena otwarcia, najwyższa cena, najniższa cena i cena zamknięcia, takie dane można

dzięki temu łatwo reprezentować za pomocą wykresu świecowego przedstawionego w

rozdziale 2. Poniżej zostały przedstawione poziomy agregacji, które będą uwzględnione

w hurtowni:

Pojedynczych transakcji zawartych między akcjonariuszami. Jest to najmniejszy

poziom agregacji, w którym wszystkie cztery parametry są sobie równe.

Sekund agregujących wszystkie transakcje wykonane w danej sekundzie.

Minut, które jest jednym z częstszych poziomów agregacji.

Godzin.

Dni, które można wykorzystać do bardziej zbiorczych agregacji, lub do programo-

wych agregacji wyższego poziomu (tygodni, miesięcy). Wykorzystywane, także

dla danych historycznych, dla których nie ma dostępu do bardziej dokładnych

danych.

Do tego musi istnieć pojęcie symbolu, albo ticker, który jednoznacznie identyfikuje

spółkę publiczną na giełdzie. Jako, że symbol jest unikalny dla firmy per giełda, mogą


występować kolizje symboli na przestrzeni różnych giełd. Także to samo przedsiębior-

stwo może występować na kilku giełdach i posiadać różne symbole, dlatego trzeba roz-

różnić symbol od spółki. Z samą spółką możemy identyfikować rynek na jakim działa,

czyli na przykład Ameryka, a także sektor operacyjny na przykład farmaceutyka.

Razem z pojęciem spółki w systemie będą przechowywane informacje na temat

wybranych wskaźników giełdowych, ma to ułatwić zapytania związane z tym typem

indeksów. Dlatego w bazie będzie istnieć pojecie indeksu, które będzie tożsame z

pojęciem symbolu, jednak zamiast wskazywać na spółkę, będzie ono identyfikować

listę spółek, które są wliczane do wartości wskaźnika.

Zdefiniowane jest także pojęcie konkretnej giełdy papierów wartościowych, na któ-

rych pojawiają się dane symbole oraz wskaźniki. Oprócz samych akcji z giełdą związa-

na jest waluta, w której przeprowadzane są na niej transakcje oraz rynek, który głównie

obejmuje. Na przykład dla Warszawskiej Giełdy Papierów Wartościowych rynki, który

obejmuje to Polska, natomiast waluta to PLN.

Oprócz danych o akcjach spółek, w systemie będą przechowywane dane na temat

zeznań podatkowych przedsiębiorstw. Są to dane, które można pobrać z zewnętrznych

źródeł w trakcie wykonywania zapytań, jednak są one na tyle związane z działalnością

spółek publicznych, że mają uzasadnienie swojej egzystencji w hurtowni danych razem

z danymi o transakcjach na akcjach.

6.3 Model logiczny

Model logiczny będzie w dużej mierze odpowiadał strukturze danych w modelu

pojęciowym, jednak ze względu na architekturę modelu fizycznego, a dokładnie na

efektywność działania systemu hurtowni danych Hadoop, pewnie obiekty zostaną ce-

lowo zmienione, co zostanie opisane.

Podstawową tabelą faktów, będzie struktura związana z transakcjami na akcjach.

W niej będzie znajdować się informacja o dacie transakcji, cenach, liczbie wymienio-

nych akcji oraz identyfikator symbolu. Tabela 6.1 przedstawia jak wygląda ta struktu-

ra. Pierwsza kolumna oznaczy, czy dana kolumna jest kluczem obcym do innej tabeli,

druga określa kolumnę, trzecia typ kolumny, kolejna, czy atrybut może przyjmować

wartość null, natomiast ostatnia kolumna dodatkowo opisuje kolumnę. Tabela faktów

przedstawiająca wartości indeksów jest taka sama z tym, że nie posiada atrybutu liczba

akcji oraz Identyfikator symbolu giełdowego jest zastąpiony Identyfikatorem symbolu

wskaźnika.


KO Kolumna Typ Null Opis

N Data Transakcji Data Nie

N Cena otwarcia Liczba Nie

N Najwyższa cena Liczba Nie

N Najniższa cena Liczba Nie

N Cena zamknięcia Liczba Nie

N Poziom agregacji Tekst Nie Definiuje zakres czasu, jaki

obejmują ceny.

N Liczba akcji Liczba Nie Liczba akcji, które zosta-

ły wymienione podczas tej

transakcji.

T Identyfikator symbolu

giełdowego

Liczba Nie Jednoznacznie określa akcje

spółki, których dotyczyły te

transakcje.

Tabela 6.1: Tabela faktów Transakcje przed denormalizacją.

Tabelą wymiaru opisującą symbol giełdowy jest tabela 6.2. Posiada nazwę tego

symbolu, która jest używana na giełdzie do identyfikacji danej spółki oraz identyfika-

tory wskazujące na giełdę, na której jest zarejestrowany symbol, a także identyfikator

spółki, której akcje reprezentuje symbol. Analogiczna jest tabela dla symbolu wskaź-

nika, z taką zmianą, że podstawowy identyfikator to Identyfikator symbolu wskaźnika,

a Identyfikator spółki jest zastąpiony Identyfikatorem wskaźnika.

Kolejną tabelą wymiaru, jest tabela 6.3. Zawiera ona informacje na temat spółek

publicznych zarejestrowanych na giełdach. Atrybutami są nazwa spółki, rynek, na

którym działalność prowadzi spółka. Rynek może być różny od rynku giełdy, na której

jest zarejestrowana spółka. Także w tej tabeli umieszczone są sektory, do których

można zaliczyć działalność przedsiębiorstwa.

Następna jest tabela wymiaru indeksu. Posiada ona jedynie Identyfikator wskaźni-

ka oraz jego nazwę. Jednak do pełnego określenia indeksu, jest niezbędna lista spółek,

która jest brana pod uwagę przy liczeniu wartości wskaźnika. Taka lista zmienia się

w czasie, kiedy komisja odpowiedzialna za wskaźnik ustali nową. Do tego jest kolejna

tabela faktów, która zawiera listę spółek, które były wliczane do indeksu w danym

okresie czasowym i zawiera atrybuty czasu, w jakim lista była aktualna oraz listę

samych symboli, do których odnosi się lista. Struktura jest pokazana w tabeli 6.4.


Kolejną strukturą jest tabela faktów, pokazana w 6.5, zawierająca informacje o ze-

znaniach dochodowych spółek, które zazwyczaj są zmuszone do publikowania takich

raportów i są one kluczowe przy określaniu stanu przedsiębiorstwa. Zeznanie podat-

kowe zazwyczaj zawiera wiele pozycji, które niekoniecznie muszą być kluczowe dla

analizy, dlatego w tym przypadku wybrane zostały tylko najważniejsze, czyli przy-

chód.

Ostatnią tabelą jest tabela wymiaru giełdy, która identyfikuje daną giełdę, na

której są wymieniane akcje spółek. Posiada ona następujące atrybuty, takie jak nazwa

i rynek, którego głównie dotyczy oraz waluta na niej obowiązująca. Jest ona ukazana

w tabeli 6.6.

Jak widać na rysunku 6.1, ten model posiada bardzo dużo tabel. Żeby wykonać

jakiekolwiek zapytanie na takim modelu trzeba wykonać co najmniej jedno, ale naj-

częściej więcej złączeń. W typowej hurtowni danych takie rozwiązanie, ze względów

wydajnościowych, nie byłoby opłacalne, także docelowy system – Hive, wykonuje ob-

liczenia dużo szybciej jeżeli liczba złączeń jest jak najmniejsza. Dlatego ten model

został zdenormalizowany.

6.3.1 Denormalizacja modelu logicznego

Przede wszystkim należy zauważyć iż tabele dotyczące wskaźników i samych akcji

są praktycznie identyczne. Jedyną znaczącą różnicą, oprócz różnicy w kluczach obcych

identyfikatorów, jest, że w przypadku rejestrowania wartości indeksu nie ma on atry-


N Identyfikator symbolu

giełdowego

Liczba Nie Jednoznacznie określa sym-

bol w obrębie hurtowni.

N Nazwa symbolu Tekst Nie Tekst symbolu, używany na

giełdzie.

T Identyfikator giełdy Liczba Nie Giełda papierów wartościo-

wych, na której jest zareje-

strowany symbol.

T Identyfikator spółki Liczba Nie Spółka, której akcje są

reprezentowane przez ten

symbol.

Tabela 6.2: Tabela wymiaru Symbole giełdowe przed denormalizacją.



N Identyfikator spółki Liczba Nie Jednoznacznie identyfikują-

cy spółkę publiczną.

N Nazwa spółki Tekst Nie

N Rynek Tekst Nie Rynek, na którym działa

spółka, który może się róż-

nić od rynku giełdy, na któ-

rej jest spółka zarejestrowa-

na.

N Sektory operacyjne Lista<Tekst> Nie Sektory działalności spółki.

Tabela 6.3: Tabela wymiaru Spółek przed denormalizacją.

butu, który określa liczbę wymienionych akcji. Jest tak, ponieważ wskaźnik nie ma

przełożenia na papier wartościowy, którym można by handlować. Do tego do tej tabeli

dołączono nazwę symbolu, aby można było wykonywać proste zapytania bez potrzeby

wykonywania jakichkolwiek złączeń. Podobnie dla tabeli Identyfikatorów symboli oraz

wskaźników, jedyna różnica jest w kluczach obcych odnoszących się do tabel spółek

i indeksów. Dlatego te tabele zostały złączone, klucze obce zunifikowane, a atrybuty,

które nie występują w drugiej tabeli stały się opcjonalne.

Aby zmniejszyć liczbę złączeń dotyczącą giełdy, spółek i wskaźników, te tabele

zostały złączone w jedną tabele wymiaru. Powoduje to stworzenie jednego wymiaru,


T Identyfikator wskaźni-

ka

Liczba Nie Identyfikator wskaźnika,

którego dotyczy lista.

N Czas od Data Nie Czas, od którego wskaźnik

był liczony na podstawie tej

listy.

N Czas do Data Nie Czas, do którego lista była

aktualna.

T Lista Identyfikatorów

symboli giełdowych

Lista<Liczba> Nie Lista symboli spółek wcho-

dzących w skład indeksu.

Tabela 6.4: Tabela faktów Lista indeksów przed denormalizacją.


do którego odwołują się wszystkie tabele faktów. Struktura ta jest przedstawiona w

tabeli 6.8.

Tabele faktów na temat zeznań dochodowych oraz listy spółek w indeksach zostały

prawie bez zmian. Jedynie dołączona została nazwa symbolu, aby można było wyko-

nywać zapytania do tych tabel, bez potrzeby złączenia z tabelą symbolów. Poniżej

tabela zeznań dochodowych.

Oraz tabela list symboli wchodzących do wskaźnika. Tabela 6.10.


T Identyfikator spółki Liczba Nie Spółka, której dotyczy ze-

znanie podatkowe.

N Rok Liczba Nie

N Miesiąc Liczba Nie Razem z rokiem daje infor-

macje kiedy zostało złożone

zeznanie.

N Okres Liczba Nie Jest to liczba ostatnich mie-

sięcy, których dotyczy to ze-

znanie.

N Całkowity przychód Liczba Nie

N Koszty przychodu Liczba Nie

N Zysk brutto Liczba Nie Zysk przed opodatkowa-

niem.

N Zysk netto Liczba Nie Zysk po opodatkowaniu.

Tabela 6.5: Tabela faktów Zeznania dochodowe przed denormalizacją.


N Identyfikator giełdy Liczba Nie Jednoznacznie określa gieł-

dę.

N Nazwa Tekst Nie

N Rynek Tekst Nie Rynek, który obejmuje gieł-

da.

N Waluta Tekst Nie Waluta obowiązująca na

giełdzie.

Tabela 6.6: Tabela wymiaru Giełdy przed denormalizacją.


Rysunek 6.1: Diagram schematu hurtowni przed denormalizacją.

Rysunek 6.2 pokazuje schemat hurtowni danych po dokonaniu denormalizacji.



N Data Transakcji Data Nie

N Cena otwarcia Liczba Nie

N Najwyższa cena Liczba Nie

N Najniższa cena Liczba Nie

N Cena zamknięcia Liczba Nie

N Poziom agregacji Tekst Nie Definiuje zakres czasu, jaki

obejmują ceny.

N Liczba akcji Liczba Tak Liczba akcji, które zosta-

ły wymienione podczas tej

transakcji. Atrybut opcjo-

nalny dla wskaźnika.

N Nazwa symbolu Tekst Nie Nazwa z tabeli symboli.

T Identyfikator symbolu Liczba Nie Jednoznacznie określa akcje

spółki, których dotyczyły te

transakcje, lub wskaźnik.

Tabela 6.7: Tabela faktów Transakcje po denormalizacji.

6.4 Model fizyczny - architektura

6.4.1 Konstrukcja hurtowni danych

Aby zapytania do hurtowni danych wykonywały się efektywniej Hive oferuje kilka

specjalnych opcji przy definiowaniu tabeli. Głównymi metodami przyspieszania zapy-

tań są partycjonowanie i kubełkowanie. Partycjonowanie dzieli plik tabeli na części

według klucza z wybranej kolumny i umieszcza go w podkatalogu, dzięki temu przy

określeniu wartości tej kolumny w zapytaniu, nie potrzebne jest wczytanie zawartości

całej tabeli, a tylko podkatalogu o tej wartości partycji. Drugą opcją jest kubełkowanie,

zadana kolumna zostaje określona jako klucz do funkcji mieszającej. Wiersze, którym

odpowiadają te same wartości funkcji mieszającej zostają zakwalifikowane do jedne-

go kubełka. Dzięki takiemu zabiegowi przy złączeniach można użyć wartości funkcji

mieszącej zamiast wartości kolumny, ta opcja jest także przydatna przy próbkowaniu

danych.

W hurtowni danych opisanej powyżej dokonano denormalizacji danych aby zmniej-

szyć maksymalnie potencjalną liczbę złączeń, jednak ilość danych w tabeli faktów do-



N Identyfikator symbolu Liczba Nie

N Nazwa symbolu Tekst Nie Nazwa, która jest używana

na giełdzie, na której wystę-

puje symbol.

N Nazwa giełdy Tekst Nie Giełda, na której wymienia-

ne są akcje tej spółki, bądź

na którym jest dany wskaź-

nik.

N Rynek giełdy Tekst Nie Rynek, który obejmuje gieł-

da.

N Waluta Tekst Nie Obowiązująca na giełdzie.

N Nazwa Tekst Nie Nazwa spółki, lub indeksu.

N Lista sektorów spółek Lista<Tekst> Tak Lista sektorów obsługiwa-

nych przez spółkę. Opcjo-

nalne dla wskaźnika.

N Rynek spółki Tekst Tak Opcjonalny dla wskaźnika.

Tabela 6.8: Tabela wymiaru Symbole po denormalizacji.

tyczącej cen akcji i wartości może spowodować, że wykonywane zapytania będą trwać

bardzo długo głównie z powodu szukania danych, w przypadku operacji full scan, a

nie ich przetwarzania. Dlatego do tej tabeli zdefiniowano następujące kolumny party-

cjonujące:

Poziom agregacji Podstawowym atrybutem zapytania powinien być poziom agre-

gacji, ponieważ bez ustawienia tego parametru zapytania dawałyby błędne wy-

niki przy wszelkiego rodzaju agregacjach. Dlatego pierwszym stopniem party-

cjonowania jest właśnie ten atrybut. Dla zapytań o dużym poziomie agregacji

na przykład dni selektywność tej partycji jest ogromna, co powinno umożliwić

optymalizatorowi wykonywanie niektórych zapytań na przy użyciu jednego wę-

zła, albo nawet wykonanie całej operacji w pamięci.

Nazwa symbolu Drugim atrybutem partycjonowania jest nazwa, ponieważ duża

część zapytań będzie wybierała konkretne symbole giełdowe, albo wiele różnych,

ale prawdopodobnie nigdy wszystkie, przy dużych zbiorach danych pozwoli to

odrzucić nieistotne dla zapytania symbole i tym samym znaczącą skrócić czas



T Identyfikator symbolu Liczba Nie Identyfikuje spółkę, której

dotyczy zeznanie dochodo-

we.

N Nazwa symbolu Tekst Nie

N Rok Liczba Nie

N Miesiąc Liczba Nie Razem z rokiem daje infor-

macje kiedy zostało złożone

zeznanie.

N Okres Liczba Nie Liczba ostatnich miesięcy,

których dotyczy to zezna-

nie.

N Całkowity przychód Liczba Nie

N Koszty przychodu Liczba Nie

N Zysk brutto Liczba Nie Zysk przed opodatkowa-

niem.

N Zysk netto Liczba Nie Zysk po opodatkowaniu.

Tabela 6.9: Tabela faktów Zeznania podatkowe po denormalizacji.

pobierania danych. Ten atrybut będzie miał przede wszystkim znaczenie dla ma-


T Identyfikator symbolu Liczba Nie Identyfikator wskaźnika,

którego dotyczy lista.

N Nazwa symbolu Tekst Nie

N Czas od Data Nie Czas, od którego wskaźnik

był liczony na podstawie tej

listy.

N Czas do Data Nie Czas, do którego lista była

aktualna.

T Lista Identyfikatorów

symboli

Lista<Liczba> Nie Lista symboli spółek wcho-

dzących w skład indeksu.

Tabela 6.10: Tabela faktów Lista indeksów po denormalizacją.


Rysunek 6.2: Diagram schematu hurtowni po denormalizacji.

łych poziomów agregacji, gdzie dla poszczególnych symboli rozmiary danych są

bardzo duże.

Dodatkowo, aby umożliwić optymalizatorowi wykonywanie lepszych złączeń przy

wykorzystaniu Map Bucket Join, dla wszystkich tabel utworzono atrybut haszujący.

Map Bucket Join to specjalny typ złączenia wykonywany przez Hive, w którym złącze-

nie zostaje wykonane po atrybucie kubełkującym, jeżeli atrybut kubełkujący nazywa

się tak samo i ilość kubełków jest wielokrotnością drugiego. Dzięki takiemu złączeniu

można zmniejszyć ilość danych ładowanych przy wykonywaniu zapytania. Dla tabel

w hurtowni jako atrybut kubełkujący został wybrany atrybut identyfikujący symbol,

ponieważ jest to jedyny atrybut, po którym można wykonywać złączenia. Jako liczba

kubełków została wybrana liczba 64. Liczba ta nie powinno być zbyt mała ponieważ

nie uzyska się wtedy odpowiedniej selektywności danych, a przy zbyt dużej fragmen-

taryzacji może być tak duża, że dla zapytań zawierających dużo symboli trzeba będzie

przetworzyć wiele plików, a operacje w Hadoop są dużo szybsze przy małej ilości dużej

plików, niż dużej ilości małych plików.


Niestety w aktualnej wersji Hive nie ma możliwości utworzenia takich obiektów

jak klucz główne, obce, czy więzy integralności. Ma to swoje podłoże w zastosowaniu

systemu, przy tak dużej ilości danych weryfikowania wszystkich więzów byłoby nie-

efektywne. Dlatego zapewnienie spójności i więzów musi być zapewnione na poziomie

procesu ETL.

6.4.2 Architektura

Rysunek 6.3: Architektura systemu. Pierwsze od lewej są źródła danych,

z których dane pobierane są w procesie ETL, wyszczególnione zostały Go-

ogle Finance i Yahoo Finance, który udostępniają interfejs do pobierania

danych. Następnie informacje ładowane są do hurtowni danych. SAS ko-

rzystając z danych tworzy raporty i wykresy. Na diagramie nie zaznaczono,

że SAS może uczestniczyć w procesie ETL.

System przedstawia typowy układ hurtowni danych. Występują zewnętrzne źró-

dła danych, proces ETL do oczyszczenia danych i załadowania ich do hurtowni. Sam

system hurtowni działający na klastrze Hadoop, który przechowuje i przetwarza za-

pytania oraz interfejs hurtowni – narzędzie analityczne SAS. Tam tworzy się raporty,

zapytania oraz generuje wykresy. Jak widać na diagramie do systemu można łado-

wać dane z różnych źródeł, których formaty znacząco się od siebie różnią. W tym

przypadku oba źródła są dostępne w sieci internetowej i mają interfejs REST, jednak

Yahoo udostępnia także specjalną formę dostępu przez YQL, który ułatwia pobieranie

danych w formie podobnej do SQL.

6.4.3 Źródła danych

Jako źródła danych można wykorzystać prawie dowolne medium. Jednak na tej

płaszczyźnie wyróżnia się przede wszystkim Yahoo i Google, które w sowich platfor-


mach giełdowych udostępniają interfejs do pobierania danych z giełdy bez opłaty.

Niestety zakres możliwych danych do pobrania jest ograniczony, a informacje nie są

udostępniane w czasie rzeczywistym, dlatego niemożliwe jest zbudowanie produkcyj-

nego systemu w oparci o te źródła. W prawdziwym systemie dane można uzyskać

bezpośrednio od operatora giełdy, lub specjalizowanych dystrybutorów takich infor-

macji. Jednak w obu przypadkach istnieje możliwość iż dane nie będą w formacie zgod-

nym z naszą hurtownią dlatego niezbędny będzie proces ETL. Dodatkowymi źródłami

danych, z których można skorzystać są strony operatorów giełdy, udostępniających

niektóre informacje w formie plików excel, lub CSV. Dane te można także załadować

do systemu przy użyciu innego procesu ładowania danych.

Dane z usługi Google Finance uzyskiwane są w formacie CSV posiadającym na-

główek opisujący format, uzyskuje się je w poprzez zapytanie do odpowiedniego URL

z odpowiednimi parametrami. Serwer odpowiada plikiem CSV z danymi. Takie dane

można już bezpośrednio przetworzyć. Niestety takia forma komunikacji ma dużą wa-

dę. W przypadku zmiany adresu, formy parametrów, lub formatu pliku niezbędna jest

modyfikacja procesu ETL.

Informacje pobrane z Yahoo Finance można uzyskać poprzez zapytanie YQL udo-

stępniane w ramach innej usługi tej samej firmy. YQL to interfejs webowy, który

pozwala pobierać dane poprzez zapytania podobne do SQL przekazane w adresie stro-

ny. Na serwerze przechowywane są formaty zapytań i odpowiedzi docelowej usługi.

Kiedy serwer otrzyma zapytanie w formacie YQL następuje translacja do zapytania

REST w formacie odpowiednim dla serwera udostępniającą usługę i zapytanie jest

wykonywane. Zwrócony wynik jest następnie przekształcany do formatu JSON, lub

XML i zwracany klientowi. Taki proces pobierania danych jest bardzo wygodny i od-

porny na zmiany. Jeżeli zmieni się adres, parametry, format URL, lub plik wynikowy

definicja translacji zostanie zaktualizowana w bazie YQL, a proces ETL nie będzie

wymagał żadnej zmiany.

6.4.4 ETL

Właściwy proces dzieli się na dwa główne rodzaje z powodu charakterystyki zmiany

danych. Wszystkie dane oprócz danych o cenach akcji i wartości indeksów zmieniają

się dosyć rzadko. Dane transakcji są niezmienne, dlatego wystarczy iż proces ETL

będzie dopisywał nowe wartości do tabeli. Danych tych będzie bardzo dużo dlatego

proces musi być efektywny. Dlatego tabela transakcji będzie aktualizowana poprzez

osobny proces wykonujący operacje ETL w określonych interwałach.


Ta funkcja będzie realizowana w języku Java przy użyciu biblioteki Spring Batch.

Spring Batch to otwarta biblioteka służąca do przetwarzania zbiorowych ilości danych

w postaci kroków. Bardzo dobrze pasuje do procesu ETL, który jest zbiorem kolejnych

działań, które trzeba wykonać na danych aby móc je załadować do hurtowni. Spring

udostępnia także wbudowaną bazę danych, którą można wykorzystać do przechowy-

wania danych przed załadowaniem do systemu. Spring Batch umożliwia definiowanie

procesów w formie zadań (ang. Job), składających się z kroków (ang. Step), które

należy wykonać, aby ukończyć zadania. Biblioteka ma także wbudowane narzędzia do

obsługi błędów w przetwarzania i ponownym uruchamianiu zadań. Każdy krok składa

się z ładownia danych, przetwarzania i zapisu. Sam proces przetwarzania może składać

się kolejnych podprocesów.

Rysunek 6.4: Proces ETL

Do ładowania danych o transakcjach będą wykorzystywane osobne zadania dla

różnych źródeł danych. Aktualnie będą one miały tylko jeden krok, gdzie proces ła-

dowania i mapowania danych będzie specyficzny dla źródła natomiast przetwarzanie i

zapis będzie taki sam. Taki podział umożliwi łatwe dodawanie nowych źródeł danych,

czy definiowanie innego sposobu przetwarzania. Wystarczy stworzyć nowy proces ła-

dowania i nowe zadanie i źródło danych jest w stanie współpracować z naszym syste-

mem. A jeżeli chcemy zmienić proces przetwarzania dla wszystkich źródeł wystarczy

napisać jeden moduł wspólny dla wszystkich zadań. Dzięki temu proce ETL będzie

spójny dla wszystkich źródeł. Sam proces zapisu będzie komunikował się z hurtownią

przy wykorzystaniu interfejsu JDBC, jednak nie ma problemu, aby wykorzystać inny

interfejs w przyszłości.

Poniżej widać strukturę ETL zdefiniowaną w bibliotece Spring przy użyciu XML.

Zdefiniowane są dwa zadania, dla dwóch źródeł danych, posiadają rożne metody pobra-

nia danych – flatFileReader dla pliku CSV i xmlFileReader dla pliku XML. Następnie


zdefiniowany jest procesor transformujący, który w przypadku YQL jest procesorem

złożonym, zawierającym także procesor tickerIdSetter używany w ładowaniu danych

z Google Finance. Ostatnim etapem jest załadowanie danych do hurtowni danych,

które jest identyczne dla obu procesów. Właściwość commit-interval, ustawiona na

sto dla obu zadań, definiuje w jakich ilościach dane powinny być zapisywane do hur-

towni. Niestety JDBC dla Hive nie obsługuje jeszcze aktualizacji zbiorczych, dlatego

ta wartość jest ustawiona jedynie dla wygody monitorowania przebiegu procesu ETL.

1 <batch:job id="googleFinanceQuotesLoader">

2 <batch:step id="loadGoogle">

3 <batch:tasklet transaction-manager="transactionManager">

4 <batch:chunk reader="flatFileReader"

5 processor="tickerIdSetter"

6 writer="hqlItemWriter"

7 commit-interval="100" />

8 </batch:tasklet>

9 </batch:step>

10 </batch:job>

11

12 <batch:job id="yahooYQLFinanceQuotesLoader">

13 <batch:step id="loadYahoo">

14 <batch:tasklet transaction-manager="transactionManager">

15 <batch:chunk reader="xmlFileReader"

16 processor="xmlCompositeProcessor"

17 writer="hqlItemWriter"

18 commit-interval="100" />

19 </batch:tasklet>

20 </batch:step>

21 </batch:job>

Ładowanie danych do systemu jest możliwe także z poziomu narzędzia SAS. Two-

rząc program w języku SAS definiujemy własnoręcznie proces ETL, dzięki takiemu

rozwiązaniu możliwe jest załadowanie do systemu niestandardowych danych, a także

zainicjowanie hurtowni, czy jej testowanie. Osoba zajmująca się administrowaniem da-

nymi w takim systemie mogłaby łatwo przeprowadzić operacje na danych bez potrzeby

modyfikowania opisanego wcześniej procesu ETL.


6.4.5 System przetwarzania i przechowywania danych

Jako system do przechowywania i przetwarzania danych jest użyty Hadoop, na

którym działa silnik hurtowni danych Hive. Hadoop dzięki swoim możliwościom skalo-

wania zapewni iż system w przypadku zwiększonego zapotrzebowania na przetwarza-

nie bardzo łatwo będzie można rozbudować. Dzięki temu iż jest to bardzo elastyczne

narzędzie możliwe jest aby w przyszłości rozbudować system o kolejne komponenty

przy wykorzystaniu tej samej architektury, ponieważ nie zawiera ona nic specyficznego

dla dziedziny problemu.

Silnik Hive pozwala ustrukturyzować dane przechowywane na klastrze, a także

udostępnia standardowy interfejs do komunikacji – JDBC. Dzięki temu można skorzy-

stać z niego nie tylko z poziomu SAS, ale także połączyć nowe systemy analityczne

do hurtowni. Daje to możliwość uniezależnienia się od komercyjnego SAS na rzecz na

przykład popularnego środowiska R, ale także połączenia tego systemu z innymi.

Hadoop razem z Hive spełnia wszystka wymagania postawione systemowi. Hado-

op jak i Hive zapewniają także uwierzytelnionym użytkownikom kontrolę dostępu do

plików tabel, dlatego możliwa jest kontrola danych nie tylko odgórnie, ale także na

poziomie samych plików i tabel. Pozwala na przechowywanie bardzo dużych zbiorów

danych idących w petabajty, a w razie zwiększonego zapotrzebowania można rozbudo-

wać system o dodatkowe węzły, które zwiększą pojemność systemu. Udostępnia także

bardzo duże możliwości przetwarzania danych, zapytania wysyłane do systemu zosta-

ją podzielone między węzły, które równolegle wykonują część obliczeń, dzięki temu

ogromne ilości danych można przetwarzać dużo krócej niż na pojedynczym serwerze.

System udostępnia także dużo możliwości interakcji z nim. Możliwe jest wykonywa-

nie programów MapReduce, pisanie zapytań SQL, czy używanie specjalnego języka

skryptowego Pig, ale także dzięki JDBC użycie ogromnej ilości różnych narzędzi. Ha-

doop zapewnia także interfejs webowy, jednaj jest on przeznaczony raczej do celów

administracyjnych systemu. Hadoop był projektowany z myślą o bezawaryjności i nie-

przerwanym czasie działania. W przypadku awarii bądź potrzeby administracji można

wykonać te operacje na działającym systemie jedynie wyłączając część klastra. Ska-

lowanie w tej warstwie jest bardzo proste wystarczy dodać do klastra nowe jednostki.

6.4.6 Narzędzie analityczne

Jako interfejs do hurtowni danych i zarazem interfejs do całego systemu wykorzy-

stany jest SAS. Dzięki temu narzędziu zostały spełnione pozostałe wymagania syste-


mu. Pozwala on na tworzenie własnych raportów i wykresów z systemu, a także pre-

zentowanie ich przy wykorzystaniu interfejsu webowego. SAS zapewnia na wysokim

poziomie autoryzacje użytkowników i pozwala na integracje z innymi systemami uwie-

rzytelnienia na przykład LDAP. SAS udostępnia także sprawdzony interfejs do pracy

analitycznej. Można w nim tworzyć proste, ale także bardzo skomplikowane modele

analityczne, dzięki specjalnemu modułowi SAS część obliczeń wykonuje na klastrze

obliczeniowym. Trzeba nadmienić iż SAS umożliwia także zainstalowanie na każdym

węźle klastra specjalny proces do wykonywania obliczeń specyficznych dla SAS. Dzięki

temu całość obliczeń zostaje wykonywana na klastrze. Niestety takie rozwiązanie nie

zostało wykonane w przypadku tego systemu z powodu ograniczeń licencyjnych.

SAS zapewnia także w tym systemie warstwę uwierzytelniającą użytkownika. Po-

siada centralny system uprawnień, dlatego łatwo odpowiednio skonfigurować prawa

dostępu, które będą obowiązywały przy połączeniu z narzędziem analitycznym. Do-

stęp do innych części systemu może być odpowiednio udostępniony poprzez strony

www, do których dostęp będzie określony w konfiguracji SAS.

Wszystkie warstwy SAS składają się ze sprawdzonych, komercyjnych rozwiązań.

Dzięki temu umożliwiają bardzo zaawansowane działania zapobiegające awariom wła-

ściwie bez potrzeby dodatkowej konfiguracji. SAS w warstwę pośrednią ma wbudowane

mechanizmy balansowania obciążenia także nawet w przypadku nadzwyczajnego ruchu

w systemie możliwe jest jego efektywne działanie, a kiedy potrzeby systemu zwiększą

się można rozbudować go o kolejne jednostki. Poprzez wykorzystanie komponentów

od innych producentów większość modułów jest standardowym oprogramowaniem i

umożliwia dostosowanie go do własnych, specyficznych potrzeb, a także robienie kopii

zapasowych.

Interfejs analityczny został zapewniony przez szereg modułów, które umożliwiają

projektowanie graficzne modelu analitycznego poprzez wykorzystanie SAS Enterpri-

se Guide, pisanie zaawansowanych programów z wykorzystaniem przeglądarki w SAS

Studio, albo przewidywaniem zachowania w SAS Forecast Studio. Generowane rapor-

ty, czy wykresy mogą być zarejestrowane SAS Information Delivery Portal, gdzie będą

dostępny przy wykorzystaniu przeglądarki. SAS do wszystkich tych modułów udostęp-

nia proces uwierzytelnienia i kontroli dostępu, który może być centralnie sterowany

przez administratora.

Dodatkowo dzięki uniwersalności systemu hurtowni danych możliwe jest podłącze-

nie innych narzędzie analitycznych i wykorzystywanie ich do przygotowywania analiz

danych.


6.4.7 Środowisko

System ten może i docelowo jest takie założenie, iż będzie działał na co najmniej

kilku osobnych komputerach. Zwłaszcza część hurtowni danych – Hadoop zadowala-

jącą wydajność osiągnie dopiero przy użyciu kilku-kilkunastu serwerach w klastrze.

Jednak z powodu ograniczonej dostępności zasobów wszystkie komponenty systemu

zostały skonfigurowane i uruchomione na jednej maszynie fizycznej.

Komputer składał się z cztero rdzeniowego procesora Intel R© CoreTM2 Quad CPU o

taktowaniu 2,4 GHz. Posiadał on maksymalną możliwą ilość pamięci RAM to znaczy 8

GB oraz dysk o prędkości 7200RPM. Na maszynie został zainstalowany system Oracle

Linux 6 z jądrem Unbreakable Enterprise Kernel, który jest jedyną darmową wersją

systemu Linux, która jest oficjalnie wspierana przez SAS. Później został zainstalowany

SAS w wersji 9.4 oraz Hadoop 2.5.1 skonfigurowany z zarządcą zasobów YARN i

Hive w wersji 0.14. Ponieważ przy instalacji oprogramowania SAS zostały wybrane

dodatkowe komponenty części serwerowej oraz warstwy pośredniej system w trakcie

działania zajmuje całą dostępną pamięć fizyczną oraz około 50% tej wartości w pamięci

wymiany. Ponieważ niektóre komponenty SAS wymagają środowiska graficznego, do

komunikacji z serwerem zostało skonfigurowane połączenie zdalnego pulpitu – VNC.

Rozdział 7

Testowanie Systemu

System został przetestowany, aby sprawdzić, czy nie ma błędów w konfiguracji,

lub jakieś komponenty nie działają. Każdy system posiada osobne metody weryfikacji

jego działania.

Hadoop oraz Hive zostały przetestowane poprzez wykonanie testowych zadań. W

przypadku Hadoop, było to wykonanie testowego zdania MapReduce oraz sprawdzenie

działania systemu plików HDFS. W obu przypadkach systemy zaraportowały prawi-

dłowe rozpoczęcie, wykonanie i zakończenie zdań. W interfejsie webowym Hadoop

zadanie zostało zapisane prawidłowo. Wyniki testowych zapytań zwróciły prawidłowe

wyniki.

W przypadku SAS narzędzie dostarcza specjalny zestaw procesów weryfikujących

działanie systemu. Zadania zostały wykonane i nie zwróciły błędów. Dodatkowo sys-

tem został przetestowany pod kątem działań operacyjnych. Zostały stworzone przy-

kładowe programy, które wykonały operacje na załadowanych danych. Test zakończył

się pozytywnie.

Do testowania połączenia hurtowni danych oraz narzędzia analitycznego zostały

załadowane do hurtowni danych przykładowe dane. Możliwe było skorzystanie z in-

formacji z poziomu SAS oraz wykonanie testowych programów na danych z hurtowni.

Wynik testowania był pozytywny. Kolejnym testem było sprawdzenie możliwości za-

pisu w hurtowni przy użyciu interfejsu dostarczanego przez SAS. Testowe dane zostały

załadowane prawidłowo i zweryfikowane po stronie hurtowni.

Do testowania procesu ETL zostały użyte dane testowe. Dane poprawnie zostały

przetransformowane przez proces, a następnie załadowane do systemu. Informacje

widoczne były po stronie hurtowni i dostępne z poziomu narzędzia analitycznego.

Wykonanie programów testowych na systemie zwróciły prawidłowe wyniki.

48

Rozdział 8

Przykłady wykorzystania systemu

Jako przykłady zastosowań systemu zostaną pokazane dwa programy w języku

SAS. Pierwszy będzie to program generujący wykres świecowy dla spółki giełdowej.

Drugi natomiast bardziej zaawansowany i przygotowany w zautomatyzowanym środo-

wisku pokazywać będzie prognozę dla akcji innej firmy.

8.0.8 Wykres świecowy

Jako podstawowe narzędzie analityka giełdowego wykorzystywane są wykresy świe-

cowe. W wygodny sposób można względnie szybko ocenić kondycję danego papieru

wartościowego. Jako przykład pokazany będzie przebieg wartości akcji spółki Yahoo

na elektronicznej giełdzie NASDAQ. Jako dane wejściowe wybrano czwarty kwartał

2014 roku oraz stopień agregacji na poziomie dni.

Aby uzyskać taki wykres należało pobrać dane z hurtowni danych używając od-

powiednich ograniczeń, a następnie posortować je według czasu. Tak przygotowane

dane można było pokazać na wykresie. Jednak, aby zwiększyć wartość merytoryczną

schematu dodano także funkcję średniej kroczącej. Do jej uzyskania niezbędne było

dodanie dodatkowego kroku danych, które obliczą odpowiednie parametry. Następnie

wykresy nałożono na siebie, aby uzyskać spójny obraz.

Do stworzenia tego programu została użyta aplikacja SASStudio, która jest do-

stępna z poziomu przeglądarki dla zarejestrowanych w systemie użytkowników.

8.0.9 Prognozowanie

Jako drugi przykład użyto bardziej zaawansowanego programu, który został wyge-

nerowany w programie SAS Enterprise Guide. Jest to program umożliwiający graficzne

49

Rozdział 8. Przykłady wykorzystania systemu 50

Rysunek 8.1: Wykres świecowy dla 4 kwartału 2014 dla spółki Yahoo

Rysunek 8.2: Aplikacja SASStudio


definiowanie procesów analizy danych i takiego też modelu użyto do wygenerowania

prognozy.

Rysunek 8.3: Prognoza cen

Jest to prognoza wykorzystująca wbudowane procedury SAS, jako funkcje pro-

gnozującą wybrana została autoregresja liniowa, która określa iż każda wartość jest

kombinacją liniową poprzednich wartości. Wygenerowane zostały prognozy dla kolej-

nego roku na podstawie danych z lat 2012-2014. Wybrane zostały akcje firmy IBM z

giełdy NYSE o agregacji na poziomie dni, ponieważ przy tak ogólnej prognozie bar-

dziej dokładne dane nie są potrzebne. Na wykresie widać także zakres pewności, który

wynosi tutaj 95%.

Wykorzystany program SAS Enterprise Guide dostarczył gotowe rozwiązania z

dziedziny analizy, ale także stworzył wygodny interfejs do przeglądania wyników. Za-

pewnia także uwierzytelnienie użytkownika poprzez połączenie z centralną bazą da-

nych SAS działającą na serwerze.


Rysunek 8.4: Program SAS Enterprise Guide

Rozdział 9

Podsumowanie

W niniejszej pracy opracowano projekt systemu umożliwiający analizę wartości pa-

pierów wartościowych na giełdach. Zostały przedstawione zasady działania na giełdzie

to jest proces sprzedaży i kupna oraz wyliczania indeksów. Opisane zostały podstawo-

we technologie, czyli Hadoop z Hive jako hurtownia danych oraz SAS jako narzędzie

analityczne, z których się on składa oraz wykazano zasadność ich bytu. Przeprowadzo-

no projekt hurtowni danych, która przechowuje niezbędne dane do analizy oraz może

być wykorzystana jako silnik do wykonywania zapytań. Do tego ukazano narzędzie

analityczne, które służy do analizy w tym systemie oraz przykładowe analizy w tym

narzędziu. Także zaprojektowany i zaimplementowany został proces ETL służący do

zasilania systemu danymi.

System jest skalowalny, posiada duże możliwości rozwoju w tym zmianę technologii

analitycznej. Możliwe jest też definiowanie nowych źródeł danych i rozwijanie procesu

ETL. System został zainstalowany i skonfigurowany na fizycznej maszynie, a jego

działanie zostało przedstawione na przykładach.

53

Bibliografia

[1] Ralph Kimball and Margy Ross. The Data Warehouse Toolkit Second Edition

The Complete Guide to Dimensional Modeling. John Wiley and Sons, Inc., 2nd

edition, 2002.

[2] Tom White. Hadoop: The Definitive Guide. 3rd edition, 2012.

[3] Clark Bradley, Ralph Hollinshead, Scott Kraus, Jason Lefler, and Roshan Taheri.

Data modeling considerations in hadoop and hive. Technical paper, SAS Institute

Inc., October 2013.

[4] Jeffrey Dean and Sanjay Ghemawat. Mapreduce: Simplified data processing on

large clusters. Technical paper, Google, Inc., October 2004.

[5] SAS Institute Inc. SAS R© 9.4 Intelligence Platform: Overview, 2013.

[6] SAS Institute Inc. SAS/ACCESS R© 9.4 for Relational Databases Reference, sixth

edition, 2014.

[7] Definition of ’exchange’. http://www.investopedia.com/terms/e/exchange.

asp. [dostęp: 10.01.2015 21:20].

[8] Definition of ’index’. http://www.investopedia.com/terms/i/index.asp. [do-

stęp: 11.01.2015 13:35].

[9] Definition of ’shares’. http://www.investopedia.com/terms/s/shares.asp.

[dostęp: 11.01.2015 14:15].

[10] 5 tips for efficient hive queries. http://www.qubole.com/

5-tips-for-efficient-hive-queries/. [dostęp: 12.10.2014 21:00].

[11] Understanding hadoop clusters and the network. http://bradhedlund.com/

2011/09/10/understanding-hadoop-clusters-and-the-network/. [dostęp:

12.10.2014 21:00].

54

http://www.investopedia.com/terms/e/exchange.asp

http://www.investopedia.com/terms/e/exchange.asp

http://www.investopedia.com/terms/i/index.asp

http://www.investopedia.com/terms/s/shares.asp

http://www.qubole.com/5-tips-for-efficient-hive-queries/

http://www.qubole.com/5-tips-for-efficient-hive-queries/

http://bradhedlund.com/2011/09/10/understanding-hadoop-clusters-and-the-network/

http://bradhedlund.com/2011/09/10/understanding-hadoop-clusters-and-the-network/

projekt systemu analitycznego z wykorzystaniem hurtowni ... · streszczenie praca opisuje projekt...

Documents