"Jak efektywnie pozyskać, przechowywać i wykorzystać dane"

Transkrypt

1 "Jak efektywnie pozyskać, przechowywać i wykorzystać dane" Streszczenie G. Sopoliński, B. Nagórski (SOL-BIT sp. z o.o.) Opracowanie zawiera podsumowanie wybranych doświadczeń wdrożeniowych firmy SOL-BIT Sp. z o.o. nabytych w trakcie wdrażania rozwiązań Business Intelligence dla firm z branży energetycznej. Doświadczenia dotyczą procesów pozyskania, przetwarzania i wykorzystania danych masowych. W opracowaniu zaprezentowano przykładową prognozę zapotrzebowania na moc dla Krajowych Sieci Energetycznych na podstawie upublicznionych danych. 1 Wprowadzenie Wraz z nastaniem ery Internetu w latach 90 XX wieku nastąpiła eksplozja gromadzonych, przetwarzanych i przesyłanych danych. Bazy relacyjne doskonałe do zastosowań transakcyjnych i ewidencyjnych okazały się niewystarczające do przetwarzania ogromnych zbiorów danych, w szczególności zbiorów o charakterze niestrukturalnym: dokumentów, stron, plików logów, pomiarów. Powstały i ciągle powstają systemy zarządzania baz danych Open Source o zbiorczej nazwie NoSQL, która ma podkreślić nierelacyjny charakter przetwarzania danych. Bazy te charakteryzuje wysoka wydajność i są one dedykowane do przetwarzania analitycznego. W 2005 roku Roger Mougalas wprowadził termin Big Data w odniesieniu do dużych zbiorów danych, których nie można było przetworzyć za pomocą klasycznych rozwiązań i narzędzi BI. Z pojęciem Big Data wiążą się V-charakterystyki. Pierwotne 3V zdefiniował Gartner Group. 1. Volume (Wielkość) Wielkość danych jest podstawową charakterystyką Big Data. Nie chodzi nawet o wielkości bezwzględne wyrażane w TB lub PB, lecz o takie zbiory danych, które ledwo mieszczą się w pamięci dużych nowoczesnych instalacji komputerowych lub muszą być przetwarzane strumieniowo. Wykładniczy wzrost generowanych, przesyłanych i składowanych danych związany jest z rozwojem Internetu i coraz większą przyłączaną do niego liczbą urządzeń. 2. Velocity (Szybkość) Szybkość generowania danych i przekazywania informacji wzrasta. Wdrożenie systemów telemetrycznych, Internetu Rzeczy (Internet of Things - IoT), danych spływających z czujników urządzeń mobilnych powodują, że generacja danych odbywa się z niespotykaną dotąd szybkością. 3. Variety (Różnorodność) W porównaniu do rozwiązań BI przetwarzających dane strukturalne z relacyjnych baz danych i plików płaskich, Big Data przetwarza pełną paletę formatów danych strukturalnych i niestrukturalnych takich jak video, dźwięk, pliki graficzne, pliki logów, html, dokumenty. 4. Veracity (Wiarygodność)

2 Wraz z dużym wolumenem szybko generowanych danych pojawia się pytanie o autentyczność, weryfikowalność i zaufanie do danych. Nie zawsze odpowiedzi na te pytania są pozytywne i musi to być uwzględnione w analizach danych. 5. Value (Wartość) Oznacza wartość informacyjną i możliwość wykorzystania informacji jaką niesie ze sobą Big Data. Aplikacje Big Data dotyczą wszystkich dziedzin życia. Z pozoru bezużyteczna informacja, w jaki element strony użytkownicy klikają najczęściej, można wykorzystać do badania preferencji klientów, ich wzorców zachowań, które można wykorzystać komercyjnie. Ogromna ilość informacji przeradza się w jakość i wartość, świadomość tego faktu powoli upowszechnia się społecznie. Wiele wzorców projektowych Big Data przenika do świata BI i na odwrót. Dlatego w dalszej części będziemy odnosić się do nich pod wspólną nazwą BI/Big data. 2 Pozyskanie danych 2.1 Praktyka definiowania zakresu informacyjnego BI Ewolucja celów systemów analitycznych Rozwiązania BI powinny wspierać realizację celów biznesowych przedsiębiorstwa. Identyfikacja i definicja celów powinna nastąpić na poziomie zarządu i zostać uszczegółowiona na niższych szczeblach zarządzania. Od momentu swojego powstania BI służył jako narzędzie do monitorowania wartości wskaźników, realizacji celów, odchyleń. Niemniej było to działanie reaktywne - nastawione na automatyzację procesu przeliczania danych, procesu tradycyjnie realizowanego z sukcesem za pomocą "zestawu narzędzi" takich jak komputer osobisty, arkusz kalkulacyjny i pracownik biurowy. Dzięki technikom analizy danych możemy ocenić i sklasyfikować klientów pod względem ryzyka biznesowego, a także przewidzieć ich zachowania, w szczególnym przypadku narażenia nas na straty finansowe. Model prognostyczny/klasyfikacyjny budujemy w oparciu o istniejące dane, testujemy jego jakość prognozy/klasyfikacji na podstawie danych testowych. Kiedy dysponujemy już modelem możemy jego użycie wbudować w nasze produkcyjne systemy operacyjne (np. dzięki architekturze mikro-serwisów), w szczególności w systemy samoobsługowe, klasyfikując klientów i oferując im zmienne warunki oferty. W zależności od danych jakimi dysponujemy o kliencie, model klasyfikacyjny pozwoli wybrać odpowiednie działania handlowe/windykacyjne. System następnie podejmie zautomatyzowane działania. Zastosowanie rozwiązań BI/Big Data ewoluuje, nie mówimy już tylko o pozyskiwaniu i analizowaniu danych i serwowaniu ich decydentom w atrakcyjnej formie, lecz o udostępnieniu automatycznego procesu decyzyjnego na potrzeby systemów transakcyjnych. Zestaw raportów Wymaganie analityczne dotyczące BI przyjęło się tradycyjnie definiować jako zbiór raportów. To bardzo wygodne podejście ułatwia opracowanie wymagań, a także oszacowanie pracochłonności projektów wdrożenia BI i dość precyzyjnie definiuje zakres. Niemniej podejście to obarczone jest wadami. Cykl życia raportu ma zmienną długość życia. W trakcie wdrożenie lub po jego zakończeniu okazuje się, że część raportów nie jest już używanych, za to pojawiają się zapotrzebowania na nowe raporty, dla których

3 "brakuje" danych w systemie BI. Wynika to często z faktu,że model danych BI tworzony był wyłącznie w oparciu o struktury istniejące w raportach, więc przestał być aktualny. Zasadnym wydaje się więc, żeby zbiór wymagań raportowych potraktować jak jedne z dodatkowych wymagań, a nie wymagań główne czy też jedyne. Model korporacyjny danych Punktem wyjściowym do tworzenia modelów danych w BI powinien być Korporacyjny Model Danych. Model pozwalający spełnić wymagania historyczne, wymagania bieżące oraz zmiany w wymaganiach, które mogą nastąpić i które można przewidzieć w najbliższej przyszłości. Model korporacyjny powinien zostać uzupełniony o dodatkowe atrybuty wynikające z analizy metadanych systemów źródłowy i zewnętrznych źródeł danych. Powinniśmy przestać postrzegać modelu danych w kategoriach inżynierskich, a raczej postrzegać dane i ich modele w kategoriach aktywów informacyjnych. Aktywów, których przetwarzanie pozwoli uzyskać dodatkową wartość biznesową: dopasować lepiej ofertę do klienta, prognozować sprzedaż, przepływy pieniężne itd. Powinniśmy uwzględnić w modelu wartość jaką mogą wygenerować dane, uwzględnić koszt ich pozyskania i przetwarzania oraz opcjonalność/obligatoryjność ich posiadania. 2.2 Architektury referencyjne systemów BI/ Big Data W architekturach BI/Big Data za jedną z architektur referencyjnych przyjęło uważać się architekturę Lambda, której diagram funkcjonalny przedstawiono na poniższym rysunku. Warstwa Batch Źródła danych dane: przetwarzane wsadowo i strumieniowo, dane wewnętrzne i zewnętrzne przeliczania i transformacji danych w trybie wsadowy i mikro-wsadowym, dane mają wysoką jakość - są kompletne Warstwa Speed niskie opóźnienie w dostępie do danych, brak dostępu do danych historycznych mechanizmy przetwarzania zdarzeń Warstwa dostępu przekazanie danych do aplikacji analitycznych, do odbiorców z organizacji oraz spoza organizacji, eksploracja danych Rysunek 1 Architektura Lambda Źródła danych (ang. Data Source) są to systemy, z których można pozyskać dane. Mogą one dostarczać dane z organizacji oraz spoza organizacji. Dane mogą być w postaci strukturalnej lub niestrukturalnej. Warstwa Batch (ang. Batch Layer) zajmuje się przetwarzaniem danych w trybie wsadowym. Dane są pobierane z systemów źródłowych, przekształcane (czyszczone, konsolidowane, agregowane) i przekazywane do warstwy udostępniającej dane. Operacje te są wykonywane przez oddzielne komponenty. Częstotliwość przetwarzanie zależy od wymogów biznesowych, może to być przetwarzanie raz na dzień, tydzień czy miesiąc, ale mogą to być wielokrotne przetwarzania w ciągu doby.

4 Warstwa Speed (Speed Layer) zajmuje się przetwarzaniem napływających danych w trybie ciągłym. Dane w tej warstwie są pobierane ze strumienia, przetwarzane i publikowane. Niskie opóźnienia w dostępie do danych są okupione brakiem dostępu do części danych historycznych, przez co nie wszystkie analizy są możliwe do wykonania. Warstwa udostępnia widoki do podglądu danych w czasie rzeczywistym. Warstwa dostępu (Serving Layer) zajmuje się udostępnianiem danych uzyskanych z warstw Batch oraz Speed dla: aplikacji analitycznych i aplikacji raportujących, aplikacji operacyjnych, aplikacji do Data Mining i analiz statystycznych, bezpośrednio dla analityków i programistów. Ze względu na czas przetwarzania danych w Big Data klasyfikujemy przetwarzanie jako: Rodzaj przetwarzanie Macro batch Micro batch Czas przetwarzania 15 min < t 2 min < t =< 15 min Near Real Time Decision Support 2 s < t =< 2 min Near Real Time Event Processing 50 ms < t =< 2 s Real Time 0 s < t =< 50 ms 2.3 Kadry Wdrożenie i obsługa BI wymaga specjalistów o zróżnicowanych kompetencjach. Jak w całej branży IT, pozyskanie odpowiednio kompetentnego i wydajnego zespołu stanowi trudność. Koszty utrzymania zespołu są znaczące. Również rotacja członków zespołu ma istotny wpływ na eksploatacje rozwiązania. Planując wdrożenie BI należy uwzględnić kwestie związane z pozyskaniem i utrzymaniem zespołu. Z względu na istotne koszty warto rozważyć: Konsolidację systemów BI do jednego rozwiązania centralnego w grupie kapitałowej. Inwestycję w narzędzia zwiększające produktywność członków zespołu: konsole administracyjne, oprogramowanie do monitorowania, zarządzania, strojenia wydajności. Zakontraktowanie usług firm zewnętrznych w zakresie rozwoju, utrzymania i gdy konieczne administracji systemem. Wykorzystanie zewnętrznej infrastruktury lub usług przetwarzania (Cloud Computing), w szczególności na etapie pilotażowym, kiedy opłacalność inwestycji nie jest jeszcze dobrze oszacowana. 2.4 Wzorce użycia BI BI samoobsługowy Historycznie BI wywodzi się z systemów wspomagania decyzji DSS z lat 70 XX wieku. Pierwotnie był to zbiór zestawień do wydruku przygotowanych przez programistów. Z czasem podejście to okazało się niewystarczające, użytkownicy z oczywistych względów potrzebowali wydajnego, wiarygodnego i w miarę aktualnego zbioru danych (Hurtowni Danych) oraz narzędzi informatycznych pozwalających im w sposób

5 samodzielny (bez udziału IT) na przygotowanie własnych zestawień i raportów. Rozwiązanie ewoluowało w stronę portalu informacyjnego, wizualizacji graficznych i KPI. Dzięki temu można było podjąć próby analizy eksploracyjnej i wykorzystania technik graficznych. Miało to również swoje złe strony, forma danych i grafika przytłoczyła treść danych, a proces decyzyjny dalej pozostał intuicyjny. BI analityczny Narzędzie statystyczne zawiera implementację wielu procedur i algorytmów badających relacje pomiędzy danymi. Znalezienie silnej i wiarygodnej relacji, prowadzi do odkrywania "prostych" reguł decyzyjnych używanych w biznesie, medycynie, procesach technologicznych. Posługiwanie się narzędziami statystycznymi wymaga przygotowania teoretycznego i praktyki. Dlatego narzędzie te nie są tak popularne. Jednakże trudno przecenić ich rolę w procesie podejmowania decyzji. W odniesieniu do dużych zbiorów danych wykorzystywane są techniki eksploracji danych znane jako Data Mining. W odróżnieniu od klasycznej analizy statystycznej nie stawiamy hipotez a priori, poszukujemy wzorców i współzależności pomiędzy danymi nie przyjmując z góry żadnych założeń ani oczekiwań. Kiedy takie zależności odnajdziemy, budujemy i oceniamy modele predykcyjne/klasyfikacyjne pozwalające przewidzieć zachowania klientów, wielkości sprzedaży, awarie itp. Kiedy posiadamy już model możemy go wdrożyć i zastosować. Data mining to zagadnienie interdyscyplinarne i łączy elementy przetwarzania baz danych, statystyki i sztucznej inteligencji (AI). W technikach Data Mining akceptujemy podejście czarnej skrzynki (np. użycie wielowarstwowej sieci neuronowej, której działania nie potrafimy opisać prostym modelem). Ponieważ dla części decydentów nie jest to akceptowalne, zazwyczaj zestawia się klasyczne algorytmy klasyfikacyjne/prognostyczne np. drzewa decyzyjne z działaniem sieci neuronowych. Przy czym przeważnie modele oparte o sieci neuronowe charakteryzując się lepszą jakością prognozy/klasyfikacji. BI operacyjny BI Operacyjny to odpowiedź na potrzebę analizy aktualnych danych rejestrowanych w systemach transakcyjnych. Analizy i raporty wykorzystywane są operacyjnie z niewielkim (nieznaczącym) opóźnieniem w zbieraniu danych. BI operacyjny wykorzystywany jest w przypadku, gdy potrzebne w procesach decyzyjnych są dane krótkoterminowe, codziennie i często generowane. Często BI operacyjny zintegrowany jest ze aplikacjami transakcyjnymi. Praktyką ostatnich lat jest rekomendowanie klientom oferty produktowej na podstawie modelów klasyfikacyjnych/predykcyjnych wykonywanych przez Big Data i zintegrowanych z serwisem klienckim za pomocą architektury mikro-serwisów. 2.5 Struktury vs dane Projektując rozwiązania BI/Big Data zmuszeni jesteśmy projektować różne struktury danych. Oczywiście najważniejsze są dane, natomiast ich struktura jest cechą drugorzędną. Dobór i projekt struktury zależą od tego jakimi algorytmami i w jakich technologiach zamierzamy przetwarzać dane, to cecha charakterystyczna dla systemów BI/Big Data. 2.6 Cykle ładowania danych

6 Trend związany ze skróceniem cykli przetwarzania danych jest bardzo silny, praktycznie potrzebujemy dostępu do bieżących danych. Dążymy do przetwarzania informacji on-line. Z punktu widzenie technologii ilość informacji i skrócone czasy przetwarzania stanowią duże wyzwanie. W systemach BI ciągle dominuje przetwarzanie wsadowe, ze względu na skrócony czas przetwarzania nazywane mikro-wsadowym. W nowo budowanych systemach zasilania wykorzystuje się mechanizmy replikacji dzienników baz danych w celu ciągłego zasilania i propagacji zmian z systemów źródłowych do systemu BI. Dużo zapożyczeń wzorców projektowych pochodzi z systemów Big Data, gdzie dane napływają w sposób ciągły i są zbyt duże, żeby je składować i archiwizować. 2.7 Ładowanie danych detalicznych vs zagregowanych W trakcie budowy Hurtowni Danych i projektu jej zasilania pojawia się strategiczne pytanie: czy przechowywać dane zagregowane czy też dane detaliczne. Dane detaliczne wymagają dużych i kosztownych przestrzeni dyskowych oraz wydłużonego czas na przetwarzanie danych. Jednakże nie występuje efekt utraty informacji, możliwa jest zmiana algorytmów naliczania danych lub możliwość zaprezentowania danych w innych przekrojach analitycznych. Natomiast dane zagregowane mają mniejsze wymagania na przestrzeń dyskową i moc obliczeniową, ich przechowywanie i przetwarzanie kosztuje mniej. Agregacja danych niesie ze sobą utratę informacji i ograniczenie możliwości przetwarzania. O ile przetwarzanie danych detalicznych jest możliwe tzn. mieszczą się na dyskach a ich przetwarzanie zajmuje rozsądny czas, rekomendujemy użycie danych detalicznych. Niestety nie zawsze jest to możliwe np. w przypadku dużej ilości danych pomiarowych, generowanych z dużą częstotliwością. 2.8 Interfejsy dedykowane vs replikacja baz W procesie zasilania Hurtowni Danych najczęściej praktykuje się dwa podejścia: Replikacja bazy danych systemów źródłowych lub ich podzbiorów. Do replikacji można wykorzystać klasyczny dostęp do baz danych za pomocą interfejsów ODBC lub JDBC jak również mechanizm replikacji logów bazy danych. Budowa interfejsu dedykowanego zawierające przeliczone i przetworzone dane. Interfejs dedykowany może zostać zaimplementowany jako perspektywa bazodanowa - dane są aktualne na moment wykonania zapytania lub jako dedykowana odrębna struktura danych: tabele bazodanowe, pliki lub komunikaty w systemie kolejkowym. W przypadku odrębnych struktury wymagany jest proces, przygotowania i naliczenia danych. Proces ten jest kontrolowany z poziomu systemu źródłowego. Interfejs dedykowany jest formą "kontraktu" pomiędzy stronami, pozwala na "przerzucenie" odpowiedzialności za jakość i poprawność danych na przygotowującego interfejs. W przypadku replikacji logów bazodanowych, proces zasilania odbywa się ciągle, następują szybka propagacja zmian, a wydajność przetwarzania w systemach źródłowych nie jest naruszona. Replikacja baz danych oprócz swoich oczywistych zalet i przewagi technicznej nad interfejsami dedykowanymi może sprawiać problemy związane z restrykcjami w politykach licencyjnych producentów oprogramowania. Przykłady restrykcji w politykach licencyjnych: Dane w bazie danych są własnością firmy, struktury danych są własnością producenta oprogramowania. Pobranie danych z bazy danych przez interfejs programowy wymaga licencji.

7 2.9 Narzędzie ETL Wraz z rozwojem systemów BI i Hurtowni Danych konieczne stało się wdrożenie i wykorzystanie specjalizowanych narzędzi do ładowania i transformacji danych. Oprócz podstawowej funkcjonalności (ładowanie danych), narzędzia ETL zapewniają możliwość audytu i logowania operacji a także błędów ładowania. Dzięki temu możliwa jest diagnostyka procesu ładowania. Celem wdrożenia narzędzi ETL jest uniezależnienie się od zespołu programistów, łatwe utrzymanie i automatyczne udokumentowanie procesu przetwarzania danych oraz ułatwiona diagnostyka procesu ładowania. Czas i zasoby przeznaczone na rozwój i administracje ETL są ograniczone. W takiej sytuacji rozwiązaniem jest takie zaprojektowanie procesu ETL i dostarczenia takich narzędzi administracyjnych i diagnostycznych, żeby zmniejszyć nakład na diagnostykę i administrację systemu. Oznacza to, że należy: Zaprojektować proces ETL, żeby był powtarzalny i odwracalny w dowolnym momencie. Zaprojektować tak proces ETL, żeby jego uruchomienie pozostawało bez konsekwencji dla użytkowników pracujących na aktualnych danych prezentacyjnych. Zapewnić, żeby dane źródłowe/interfejsowe przetwarzane przez ETL nie uległy zniszczeniu. Opracować procedury weryfikacji i walidacji danych źródłowych przed ich przetwarzaniem, tak żeby użytkownik/administrator otrzymała precyzyjną informację w formie czytelnego zestawienia, które dane źródłowe i w jaki sposób trzeba poprawić. Zapewnić rozbudowaną obsługę wyjątków i mechanizmów kontrolnych sprawdzających liczby przetworzonych rekordów i sumy kontrolne na każdym etapie ładowania, zapobiegających załadowaniu nieprawidłowych danych. Zapewnić prosty interfejs uruchamiania zadań i kontrolowania zadań w harmonogramie, tak żeby mogła obsłużyć go osoba bez technicznego przygotowania. Zapewnić prosty interfejs diagnostyki przetwarzania (z możliwością wyświetlenia informacji diagnostycznej i kodów źródłowych) dla obsługi technicznej i programistów. Zapewnić aplikację dla utrzymania/edycji metadanych referencyjnych, posiadającą funkcjonalność wersjonowania danych w czasie. Zapewnić prosta i szybką ścieżkę nawigacji do komunikatów o błędach Narzędzia Data Quality i Data Cleansing Narzędzia do zapewnienia jakości danych pozwalają na ocenę jakości danych poprzez zastosowanie automatycznych predefiniowanych reguł. Możliwe jest też definiowanie własnych bardziej złożonych reguł danych. Przygotowane reguły sprawdzania danych można wykorzystać i zintegrować z procesem ETL. Integracja narzędzi Data Quality i ETL nie jest bezproblemowa. W praktyce użycie narzędzi Data Quality oznacza wysokie koszty. Alternatywą jest badanie jakości danych i implementacja reguł jakości danych przez zespół programistów zajmujących się ETL. Oprogramowanie do czyszczenia danych dotyczy najczęściej czyszczenia danych adresowych. Oprogramowanie to potrafi dopasować badany rekord danych do słowników referencyjnych korzystając z algorytmów dopasowania rozmytego (ang. fuzzy match).

8 Strategia związana z zapewnieniem jakości danych jest dość prosta, ale wymagająca w implementacji. Jakość danych należy zapewnić implementując reguły integralności i poprawności danych w systemach źródłowych, w pierwszej kolejności w bazie danych, następnie w aplikacji Metadane Metadane pełnią kluczową rolę w systemach BI. Opisują struktury Hurtowni Danych, struktury systemów źródłowych, stanowią specyfikacje warstwy semantycznej użytkownika, występują w specyfikacji struktur raportów a także zawierają informację o procesach zasilania, ich konfiguracji i przebiegu. System BI nie istnieje bez swoich metadanych. Z powodu braku akceptacji standardów wymiany metadanych między producentami oprogramowania, zarządzanie metadanymi to prawdziwy problem i w zasadzie główny czynnik kosztowy wdrożenia systemów BI. Często ze względu na istotność biznesową metadanych, tworzy się wyodrębnione systemy (tzw. systemy słownikowe) służące do centralnego zarządzania i propagacji tych danych. W istocie problem metadanych biznesowych nie dotyczy tylko BI, dotyczy całego ekosystemu informatycznego w firmie. Dokonując ewaluacji i wyboru narzędzi dla środowiska BI, oprócz ważnych elementów funkcjonalnych, zwróćmy też uwagę na niedoceniany aspekt: integrację i wymianę metadanych pomiędzy narzędziami, które kupujemy. 3 Wykorzystanie danych Kosztowne i pracochłonne pozyskiwanie danych oraz ich przetwarzanie wykonuje się w jednym zasadniczym celu: wykorzystania pozyskanych informacji w taki sposób, żeby zdobyć przewagę konkurencyjną. Przewagę informacyjna związana jest z posiadaniem informacji, którymi nie dysponuje nasza konkurencja. Dysponując nią, możemy podjąć działania, które zabezpieczą nasz udział w rynku, przychody, pozwolą na pozyskanie nowych klientów, utrzymanie starych itd. Oczywiście zbieramy dane, które w momencie ich powstania są już danymi historycznymi, bo dotyczą przeszłych zdarzeń. Jednakże analizując historię możemy opracować model prognostyczne/klasyfikacyjne, które pozwolą lepiej oszacować wartość przyszłych zdarzeń np. zużycia prądu. Przykład prognozy zostanie podany w dalszym tekście. Poniżej przedstawimy typowe scenariusze użycia BI, zaczynając od klasycznej rachunkowości, a kończąc na prognozowaniu. 3.1 Wykorzystanie BI w księgowość BI w księgowości używany jest powszechnie, w szczególności techniki OLAP związane z drążeniem danych. Interesuje nas jakie salda bądź obroty kont księgowych, składają się na pozycje sprawozdań finansowych. W przypadku kont interesuje na jakie zapis księgowe i związane z nimi zdarzenie gospodarcze składają się na obroty. Umożliwia to łatwą weryfikację sprawozdania finansowego. Wykonywane przetwarzanie danych charakteryzuje się małym obciążeniem, pracujemy na danych wstępnie zagregowanych, dane przetwarzane są w cyklach podatkowych: zamknięcie miesiąca, zamknięcie roku. Użytkownicy pracując używając gotowe, predefiniowane raporty, nie tworzą własnych zestawień.

9 3.2 Wykorzystanie BI w Kontrolingu Kontroling współpracuje z kadrą zarządzającą, jest doradcą i partnerem w zarządzaniu. Wykorzystuje dane pochodzące z ewidencji księgowej (dokumenty finansowe) jak również dane pochodzące z ewidencji pozafinansowej takiej jak: karty czasy pracy, zużycie energii, zużycie materiałów, użycie maszyn, środków transportu do celów realizacji zleceń usługowych lub produkcyjnych. Dział Kontrolingu jest "najlepszym" użytkownikiem systemu BI w organizacji. Typowe wzorce przetwarzania danych to: agregacja danych, agregacja danych narastająco, alokacje danych z użyciem kluczy podziałowych, wyliczanie średnich, odchyleń, udziału procentowych, proste formuły wyliczeniowe, a czasami również rozwiązywanie układu równań liniowych. Dane przetwarzane to najczęściej dane wyliczeniowe i szacowane. Wyniki przetwarzania bardzo często są wizualizowane za pomocą wykresów. Zestawienie i raporty nie mają stałego formatu i charakteru, przygotowywane są ad-hoc dla potrzeby analizy konkretnego zagadnienia. Narzędzia BI wspierają pracę Kontrolingu przez możliwość pozyskania aktualnych danych produkcyjnych, dowolnego ich zestawienia i prezentacji. 3.3 Wykorzystanie BI w sprzedaży Prognozowanie zużycia Precyzyjne prognozowanie zużycia pozwala na zakup energii elektrycznej na giełdzie z zastosowaniem instrumentów związanych z atrakcyjniejszymi cenami zakupu. Precyzyjna prognozy pozwalają unikać zakupów na drogim rynku SPOT. Do prognozowania zużycia wykorzystuje się analizę szeregów czasowych i wielowarstwowe sieci neuronowe. Zużycie charakteryzuje się sezonowością i trendem, jego prognozowanie nie sprawia problemu. Prognozowanie cen Motywacje do sporządzania prognozy cen są takie same jak dla prognoz zużycia. Jakość prognozy cen przy stosowaniu zbliżonych algorytmów jest niższa niż jakość prognozy zużycia. Zdecydowanie wykorzystuje się wielowarstwowe sieci neuronowe. Prognozowanie cen jest ogólnie trudne. Migracje klientów (churn) Jedną z metoda analiz danych jest przewidywanie migracji klientów (churn) poprzez odkrywanie wzorców zachowań klientów. Pozwala to działom sprzedaży z wyprzedzeniem podjąć działania, żeby zapobiec temu procesowi jak również dostosować ofertę do potrzeb klienta. Migracje klientów w Data Mining to zagadnienie klasyfikacyjne, wykorzystuje się do niego techniki: Drzew Decyzyjnych, Regresje Logistyczną i oczywiście wielowarstwowe sieci neuronowe. Często dokonuje się segmentacji klientów po to, żeby zróżnicować ich obsługę i osiągnąć lepszą rentowność. Wykorzystuje się do tego celu algorytmy analizy skupień, której celem jest pogrupowanie badanych obiektów tak żeby stopień powiązań obiektów w ramach grupy był jak największy, a jak najmniejszy z obiektami z pozostałych grup. 3.4 Wykorzystanie BI w eksploatacji

10 Systemy BI używane są do składowania danych, wizualizacji i udostępniania wyników pomiarowych dla pomiarów ciągłych wykonywanych przez systemy telemetryczne i SCADA. Przydatne są również do wyszukania anomalii w danych pomiarowych, które mogą się świadczyć o błędach pomiarów lub awariach. Wykorzystuje się też dane pomiarowe do prognozowania awarii, w trakcie działania systemu, co pozwala dyspozytorom podjąć decyzje z wyprzedzeniem i uniknąć kosztownych nieplanowanych przestojów i związanych z nimi strat finansowych. 3.5 Prognozowanie Prognozowanie popytu jest ważnym wyzwaniem dla biznesu, w tym również dla przedsiębiorstw energetycznych. Utworzenie rynku energii elektrycznej spowodowało, że jakość prognoz ma bezpośredni wpływ na wyniki finansowe przedsiębiorstw energetycznych. Prognozowanie zapotrzebowania na energię elektryczną jest związanie z budową odpowiedniego modelu. W ramach niego należy uwzględnić takie czynniki jak: dane historyczne, wahania sezonowe, czynniki atmosferyczne, zaplanowane zdarzenia np. przerwy technologiczne u kluczowych odbiorców. Podejścia do prognozowania: Metody naiwne. Metody te wykorzystują proste aproksymacje. Modele są bardzo proste w implementacji i zrozumieniu. Ich wadą mogą być duże błędy prognoz związane z brakiem uwzględnieniem istotnych czynników, Modele regresyjne. Modele oparte na regresji pozwalają przewidywać wartość zmiennych w zależności od wartości innych zmiennych. Poziom skomplikowania wpływa na skuteczność prognoz, ale jednocześnie powoduje zwiększone zapotrzebowanie na ilość danych oraz sprawia większe problemy z interpretacją wyników. Modelowanie szeregów czasowych. Modele oparte o szeregi czasowe mogą opierać się zarówno o pojedyncze jaki i o złożone wzorce sezonowości. Model te są dobrze opisane matematycznie i dają przyzwoite rezultaty. Głębokie sieci neuronowe. Jest to stosunkowo nowy sposób podejścia do prognozowania. Uzyskane prognozy są dokładne, ale podejście to wymaga dużych mocy obliczeniowych, a modele są trudne do interpretacji. Agregacja prognoz, Agregacja prognoz w uproszczeniu polega na scaleniu wyników wielu prognoz i otrzymanie lepszego wyniku niż każda z zastosowanych prognoz oddzielnie. 3.6 Przykład prognozy - zapotrzebowanie na moc KSE Szereg czasowy to sekwencja pomiarów wykonywana w równych odstępach czasu. W danych szeregu można wyodrębnić składnik systematyczny i losowy. Analizę szeregu czasowego wykonuje się w dwóch celach: wykrycie natury zjawiska: trendu i sezonowości, oraz przewidzenie przyszłych wartości szeregu czasowego. Trend opisuje ogólny kierunek rozwoju (liniowy lub nieliniowy) a sezonowość opisuje okresowe systematyczne zmiany. Sezonowość może być złożona i tak jak w przypadku zapotrzebowania na moc dotyczyć cykli dobowy, tygodniowych i rocznych. Jako przykład wybrano szereg czasowy zapotrzebowania na moc Krajowego Systemu Energetycznego w okresie lipiec dane godzinowe. Dane pochodzą z portalu Polskich Sieci Elektroenergetycznych. Wybraliśmy krótki okres tak żeby pominąć wpływ sezonowości rocznej. Wykorzystaliśmy modelowanie szeregów czasowych - metoda TBATS. Metoda ta stosowana jest do analizy szeregów czasowych o złożonej

11 sezonowości. Algorytm uwzględnia trend długookresowy i niejednorodność wariancji w czasie. Poniższe rysunki prezentują analizę otrzymanej sezonowości oraz tygodniową prognozę. Rysunek 2 Zapotrzebowanie na moc lipiec 2018 observed dane surowe, rzeczywiste level wartość po wyeliminowaniu czynników sezonowego season1 sezonowość okres dobowy (24h) season 2 sezonowość okres tygodniowy(168h) Rysunek 3 Tygodniowa prognoza zapotrzebowania na moc sierpień 2018

12 MAE RMSE MAPE MASE Training set Test set Oceniając jakość prognozy używamy następujące wskaźniki (od najprostszych): średni błąd bezwzględny MAE [MW] (ang. mean absolute error), MAPE średni bezwzględny błąd procentowy (ang. mean absolute percentage error) RMSE MASE pierwiastek błędu średniokwadratowego ( ang. root mean squared error) średni bezwzględny błąd skalowany (ang. mean absolute scaled error) złożony wskaźnik, zaprojektowany do oceny poprawności prognoz gdzie X - wartość rzeczywista, F - wartość prognozowana, t - indeks szeregu czasowego, n- liczba pomiarów. Oceniając wyniki widzimy, że średni bezwzględny błąd prognozy wynosi 3,85%. Dla porównania przy stosowaniu metod naiwnych osiągamy błędy prognozy powyżej 9%. Natomiast przy stosowaniu wielowarstwowych sieci neuronowych MAPE wynosi około 2,8%. Nie wynika to bezpośrednio z przykładu, ale im dłuższy okres prognozowany tym mniejsza jakość prognozy. Jakość prognozy wpływa istotnie na planowanie przyszłych przychodów (również ich rentowności), a także powiązane przepływy pieniężne. 4 Podsumowanie 4.1 Wyzwania i zagrożenia Branża energetyczna narażona jest na działanie czynników zewnętrznych: prawnoregulacyjnych, a także na działania podmiotów z innych sektorów gospodarki w szczególności z sektora finansowego. Właśnie w sektorze finansowym upatrywałbym zewnętrznego zagrożenia dla branży energetycznej i nie są to tylko tradycyjne zagrożenia związane z brakiem finansowania, naruszeniem płynności, dochodzą również zagrożenia związane z uwolnieniem handlu energii i obligiem sprzedaży energii a w szczególności praw majątkowych na towarowej giełdzie energii. Oznacza to groźną konkurencję, która ma większy kapitał i potrafi lepiej dokonywać transakcji. 4.2 Stan adaptacji technologii BI/Big Data Z naszych obserwacji wynik, że branża energetyczna podejmuje nieustannie działania w zakresie budowy repozytoriów danych i wdrożenia narzędzi analitycznych. Jednakże te działania nie mają jasno określonej długoterminowej perspektywy - mapy drogowej rozwoju. Być może wpływ na to ma duża fluktuacja kadr i efekt braku "pamięci organizacji". Na podstawie własnych doświadczeń wdrożeniowych postanowiliśmy przygotować zestawienie pokazujące stopień adaptacji rozwiązań BI/Big Data w branży energetycznej

13 i branży finansowej. Nie są to badania reprezentatywne, niemniej łatwo można ocenić stopień adaptacji rozwiązań na swoim własnym przykładzie. Obszar Technologia Energetyka Bankowość Przechowywanie Operational Data Store + + Data Mart + + Corporate Data Warehouse -/+ + Big Data/Hadoop - + Rozwiązania hybrydowe - - Cloud Computing - - Przetwarzanie Wsadowy ETL + + Replikacja logów -/+ + Przetwarzanie strumieniowe - + Przetwarzanie in-memory - -/+ Hierarchical Storage Management - + Wykorzystanie Raporty predefiniowane + + BI Samoobsługowy -/+ + BI Operacyjny - -/+ Analityka Analizy statystyczne -/+ + Narzędzi Data Mining i eksploracyjne - + Machine Learning, Deep Neural Networks - -/+ Legenda: + wdrożenia produkcyjne -/+ wdrożenia Proof Of Concept/pilotażowe, wdrożenia w trakcie - brak wdrożenia lub brak danych 4.3 Wnioski Przed wszystkim czeka nas zmiana nastawienie do zbiorów danych, należy je potraktować jako aktywa informacyjne (a nie jako uboczny produkt pracy systemów), zacząć je wykorzystywać i czerpać korzyści. Konieczne jest pozyskanie, utrzymanie kompetentnych analityków i wyznaczeni im precyzyjnych długoterminowych biznesowych celów związanych z wykorzystaniem BI/Big Data. Jeśli któryś z czynników należałoby podkreślić i wyróżnić to właśnie jakość Kadr. Zespoły zajmujące się analityką biznesową i systemami BI/Big Data to nie tylko administratorzy, architekci, programiści czy analitycy systemowi, to również statystycy a także matematycy - absolwenci specjalności data science. Inwestycje w kadry, a w szczególności w budowę komplementarnego, kompetentnego i doświadczonego zespołu są istotnie wyzwaniem. O ile może przekazać w outsourcing wdrożenie czy też obsługę administracyjną, to jednak utrzymanie zespołu doświadczonych analityków jest kluczowe dla rozwoju i konkurencyjności firmy. Przewaga konkurencyjna to nie jest usługa, która można zamówić u dostawcy. Model biznesowy i wynikającą z niego przewagę biznesową trzeba wypracować samemu. Narzędzia do tego istnieją od lat, wystarczy je wykorzystać.

14 5 Literatura 1. IBM Corporation (2014) "The four V's of Big Data", IBM Big Data & Analytics Hub. 2. Muan Sang, Go & Xu, Lai & De Vrieze, Paul. (2016). A reference architecture for big data systems /SKIMA Ralph Kimball, Joe Caserta "The Data Warehouse ETL Toolkit", Willey Ralph Kimball, "The Data Warehouse Toolkit 2nd ed.", Willey StatSoft (2006). Elektroniczny Podręcznik Statystyki PL, Krakow, 6. Adam Zagdański, QuantUp: "Analiza i prognozowanie szeregów czasowych o złożonej sezonowości", Rob J Hyndman, Monash Universit, "Forecasting time series with complex seasonal patterns using exponential smoothing" (2010). 8. PSE SA, raporty dobowe z pracy KSE, zapotrzebowanie na moc za lipiec 2018.