Enterprise Business Intelligence
Zawartość strony
 | Wstęp |
| Użytkownicy systemów raportowych |
| SQL Server 2005 |
| Narzędzia w SQL Server 2005 |
| Unified Dimensional Model |
| Skalowalność |
| Możliwości analityczne |
| Podsumowanie |
Wstęp
Niezależnie od wielkości, każde przedsiębiorstwo potrzebuje do efektywnego działania informacji. Niezależnie od wielkości, w każdym przedsiębiorstwie odpowiadać trzeba na pytania w rodzaju:
| • | Jaka jest wartość zamówień na dziś, za zeszły tydzień, na przyszły miesiąc? |
| • | Jaki jest poziom satysfakcji naszych klientów? |
| • | Czy dana działalność jest zyskowna? |
| • | Dlaczego kampania marketingowa nie przyniosła spodziewanych efektów? |
Celem jest:
| • | Szybsze podejmowanie lepszych decyzji biznesowych. |
| • | Odkrywanie nieoczywistych zależności i przewidywanie z dobrym przybliżeniem najbliższej przyszłości. |
| • | Sprawozdawczość obowiązkowa. |
| • | Budżetowanie i wiele innych. |
Niezależnie od wielkości przedsiębiorstwa wreszcie, szybko okaże się, że aby odpowiedzieć na tak postawione pytania, skorzystać trzeba z danych znajdujących się w różnych systemach i w różnych lokalizacjach, oraz że dane zapisane są w różnych formatach - w systemach transakcyjnych (finansowo-księgowym, magazynowym, kadrowo-płacowym) i w plikach Excel’a, Access’a, tekstowych, w XML-u i w wielu innych.
W dużych przedsiębiorstwach stosowanym od lat sposobem konsolidacji danych na potrzeby raportowe jest zbudowanie hurtowni danych. Podczas przenoszenia dane są poddawane obróbce – są czyszczone, doprowadzane do spójnej postaci oraz agregowane. Pozostaje pytanie: czy hurtownia danych jest w stanie zaspokoić w najlepszy sposób potrzeby wszystkich użytkowników i czy użytkownicy powinni odwoływać się bezpośrednio do hurtowni. Przyjrzyjmy się temu zagadnieniu w perspektywie największych firm.
Użytkownicy systemów raportowych
Użytkowników systemów raportowych podzielić można na trzy grupy. Po pierwsze są to konsumenci informacji – pracownicy operacyjni, którzy do działania potrzebują informacji w formie raportów czy też zestawień. Osoba odpowiedzialna za zamawianie towarów musi dostać raport mówiący o tym, że stany magazynowe danych produktów są poniżej pewnego ustalonego minimum. Osoby z tej grupy potrzebują płaskich, statycznych raportów i pewnie dałoby się zaspokoić ich potrzeby bez budowy specjalnego systemu, dyby nie liczność tej grupy, gdyby nie potrzeba pracy na danych zawsze aktualnych i gdyby nie konieczność zapewnienia pewnych, odpornych na błędy, kanałów dystrybucji informacji, np. przy pomocy poczty elektronicznej.
Drugą grupę stanowią analitycy. To osoby odpowiadające na pytania, zaczynające się od słów: „Jak”, „Dlaczego”. Potrzebują one do swojej pracy narzędzia, które pozwoli im wykonywać raporty ad-hoc, narzędzia do raportowania otwartego, dzięki któremu będą w stanie docierać do dowolnej informacji w możliwie krótkim czasie. Narzędzia, które pozwoli im poruszać się wśród dobrze zdefiniowanych pojęć biznesowych, przechodzić od ogółu do szczegółu, nawigować w danych przy pomocy hierarchii. Narzędzia, które pozwoli odpowiedzieć na pytanie – trzymając się poprzedniego przykładu - „Jakie powinny być minimalne stany magazynowe, które zapewnią ciągłość sprzedaży?”
Ostatnią grupę stanowi kierownictwo. Tutaj potrzebna jest metodologia i narzędzie prezentujące dane w postaci syntetycznej, dzięki któremu wiedzę o kondycji firmy, o tym czy organizacja firmy jest efektywna, czy firma się rozwija a klienci są zadowoleni, można było posiąść w jednej chwili.
Proszę zauważyć też, że istnieją oczywiste zależności między osobami z różnych grup. Jeśli klienci naszej firmy nie są zadowoleni i jeśli kierownictwo firmy to dostrzeże, wówczas zleci analitykom znalezienie odpowiedzi na pytanie, dlaczego tak jest. A analitycy po znalezieniu odpowiedzi będą musieli dostarczyć pracownikom operacyjnym informację o tym, w jaki sposób powinni zmienić oni swój sposób działania. Na pewno jednym ze sposobów może być zmiana informacji, na podstawie której konsumenci informacji działają, zmiana zestawień i raportów, w oparciu o które podejmują oni swoje decyzje.
SQL Server 2005
A zatem dział IT ma przed sobą trudny orzech do zgryzienia:
| • | Przy pomocy jakich narzędzi zintegrować dane z różnych źródeł? |
| • | Jakie narzędzia będą odpowiednie dla analityków? |
| • | Jak stworzyć system, którym będzie można łatwo administrować i będzie on modyfikowalny? |
| • | Jak zrobić to wszystko, gdy jednym z naszych priorytetów jest minimalizacja ponoszonych kosztów? |
Aby zaspokoić te – często sprzeczne – potrzeby, relacyjna hurtownia danych to za mało. Nie ma jednego narzędzia i jednej technologii, ani w warstwie wizualizacji i dostarczania danych, ani w warstwie analizy i przechowywania danych. Potrzebujemy narzędzia do raportowania masowego, które przy pomocy godnych zaufania kanałów dystrybucji dostarczy szerokiej rzeszy konsumentów informacji płaskie, statyczne raporty w różnych formatach. Takim narzędziem jest Reporting Services z pakietu SQL Server 2005. Potrzebujemy bazy wielowymiarowej, która zapewni łatwą nawigację i poruszanie się wśród dobrze zdefiniowanych pojęć biznesowych i Data Mining’u żeby z dobrym przybliżeniem przewidzieć przyszłość – takim narzędziem jest wchodzące w skład SQL Server 2005 Analysis Services. Potrzebujemy metodologii i narzędzia żeby zbudować system informowania kierownictwa – Analysis Services zawiera odpowiednią infrastrukturę.
Idealnym jej uzupełnieniem jest Business Scorecard Manager – niezależny od pakietu SQL Server (i odrębnie licencjonowany) zestaw narzędzi implementujący metodologię Balanced Scorecard. Potrzebujemy wydajnej, skalowalnej i bezpiecznej bazy danych, aby zbudować centralną hurtownię danych i żeby zbudować hurtownie tematyczne (data marts), gdyż bardzo szybko okaże się, że informacja, która znajduje się w hurtowni jest zbyt rozległa i zbyt szczegółowa na potrzeby pewnych typów raportów i dostęp do tej informacji jest zbyt skomplikowany i zbyt czasochłonny. Potrzebujemy wydajnego narzędzia do budowy procesu ekstrakcji, transformacji i ładowania (ETL), aby wszystkie wymienione wcześniej elementy mogły działać na spójnych, rzetelnych danych – takim narzędziem jest Integration Services – znowu fragment SQL Server 2005.
A jeśli potrzebnych jest tak wiele elementów, to należy postawić pytanie: jak połączyć je w całość, aby w naszym systemie istniały dobrze zdefiniowane warstwy odpowiedzialne za ekstrakcję, transformację, czyszczenie i ładowanie danych, za przechowywanie i analizę danych, wreszcie za udostępnianie i wizualizację danych? Co zrobić, żeby system był modyfikowalny i żeby jego modyfikacje nie prowadziły do powstawania nowych niepołączonych z już istniejącymi, bądź połączonymi siecią, niejawnych zależności komponentów? Co zrobić, żeby system po niekontrolowanym wybuchu nie obumarł jako niezarządzalny i niemodyfikowalny i w końcu kompletnie nieprzystający do tego, co potrzebne jest użytkownikom końcowym do wsparcia ich codziennej pracy?
Potrzebny jest dobry projekt, potrzebna jest skuteczna metodologia, ale przede wszystkim potrzebne są odpowiednie narzędzia, dzięki którym to, co jest niezbędne, aby urzeczywistnić wizję systemu Business Intelligence (BI) dla każdego, udało się zrealizować.
Narzędzia w SQL Server 2005
Jestem przekonany, że SQL Serwer 2005 zawiera zestaw takich narzędzi, dzięki którym budowa systemu BI dla każdego jest nie tylko możliwa, ale również jesteśmy w stanie zrobić to łatwiej, szybciej i lepiej niż w innych narzędziach. Jestem pewien, że oferta jest kompleksowa, platforma zawiera narzędzia z jednej strony bardzo ściśle ze sobą zintegrowane, a jednocześnie zbudowane w oparciu o standardy. Jestem przekonany, że narzędzia te zapewniają wysoką produktywność, co przełoży się na niższy całkowity koszt posiadania, a system stworzony przy ich pomocy będzie zarządzany i modyfikowalny.
Wiem, że na razie to stwierdzenie możemy tylko traktować jako pewną hipotezę. Spróbuję ją udowodnić.
Przyjrzyjmy się najpierw narzędziu do ekstrakcji, transformacji i ładowania danych. Jeśli ktoś z Państwa próbował budować troszkę bardziej skomplikowane rozwiązania w oparciu o Data Transformation Services (DTS) – poprzednika Integration Services – to pewnie dobrze zna jego wady. Architektura DTS’u i brak wbudowanych komponentów transformacji, które rozwiązywałyby najczęściej pojawiające się problemy w procesie ETL, komponentów, które można by łatwo konfigurować do użycia w typowych sytuacjach - obie te rzeczy powodowały, że proces ETL wyglądał zwykle tak, że dane co chwila lądowały w strukturach tymczasowych. Architektura i brak komponentów powodował, że pojawiały się problemy z wydajnością, a nawet typowe zadania trzeba było tworzyć od zera. Dodatkowy problem pojawiał się, jeśli potrzebna była informacja zwrotna z procesu, nie mówiąc już o próbie automatycznego naprawienia błędów w danych i ponowieniu próby ich załadowania do hurtowni.
Integration Services to zupełnie inne narzędzie. Z jednej strony to otwarta platforma, którą można dowolnie rozbudowywać, ale to także bogaty zestaw komponentów, rozwiązujących najczęściej pojawiające się problemy podczas implementacji procesu ETL. Wśród tych komponentów najważniejsze służą do wyszukiwania informacji, wyszukiwania podobieństw i grupowania elementów podobnych, agregacji danych, próbkowania danych, denormalizacji i normalizacji danych (operacje pivot i unpivot). Integration Services to także obsługa wolno zmieniających się wymiarów, łącznie ze wsparciem dla scenariusza, w którym konieczne jest zapewnienie ciągłości historycznej raportowania. To komponenty, które pozwalają na podział strumienia danych na dwa, w zależności od spełnienia jakiegoś warunku logicznego; to komponenty do łączenia dwóch strumieni w jeden, do powielania wejściowego strumienia danych i sortowania danych. To także komponenty do konwersji danych, wyliczania nowych wartości na podstawie istniejących, eksportu z kolumn do plików i importu z plików do kolumn w strumieniu danych. To w końcu element pozwalający na Data Mining. Do tego szereg komponentów sterujących przepływem danych (np. pętle). Zaimplementowane transformacje oraz architektura Integration Services sprawiają, że możliwe jest teraz zaprojektowanie procesu ETL jako jednego (nie tylko logicznie, ale również fizycznie) ciągu zdarzeń. Przetwarzanie danych w buforach w pamięci wszędzie tam, gdzie jest to możliwe sprawia, że Integration Services to narzędzie niezwykle wydajne. Integration Services to integracja na trzech poziomach:
| • | Na poziomie różnych źródeł danych – SQL Server, pliki tekstowe, Excel, Access, bazy danych firm trzecich, WebServices. |
| • | Na poziomie typów danych – dane relacyjne, niestrukturalne dane tekstowe, XML. |
| • | Na poziomie różnych technologii – bazy relacyjne, bazy wielowymiarowe, Data Mining. |
Integration Services to narzędzie klasy Enterprise.
Unified Dimensional Model
Kolejna unikalna cecha SQL Serwera to Unified Dimensional Model (UDM). Koncepcja, której zadaniem jest zbliżenie do siebie dwóch światów – świata baz wielowymiarowych i świata raportowania relacyjnego.
Bazy wielowymiarowe mają szereg istotnych zalet. Trzy najważniejsze to:
| • | Intuicyjna nawigacja – poruszanie się w danych przy pomocy hierarchii oraz dobrze zdefiniowane pojęcia biznesowe. |
| • | Szybkość raportowania, która wynika z silnego zagregowania danych i przechowywania ich w strukturach zoptymalizowanych pod kątem odczytów. |
| • | Oraz – co po części wynika z dwóch pozostałych – możliwość definiowania bardzo skomplikowanych obliczeń – wystarczy spojrzeć na implementację jakiegokolwiek opartego na modelu OLAP narzędzia do budżetowania.Jakie narzędzia będą odpowiednie dla analityków? |
Jednocześnie modelowi OLAP brakuje pewnych funkcjonalności, które są obecne w raportowaniu relacyjnym. To przede wszystkim:
| • | Możliwość pracy na danych zawsze aktualnych – tradycyjnie rozumiany model OLAP zawsze wprowadza opóźnienia związane z koniecznością agregowania danych i przeniesienia ich do struktur zoptymalizowanych pod kątem odczytów. |
| • | Bogate możliwości modelowania rzeczywistości i budowanie nawet bardzo skomplikowanych zależności między danymi. |
| • | Oraz – co także jest złożeniem dwóch pozostałych punktów – bardzo szczegółowe i dokładne raportowanie. |
Te różnice powodowały, że twórca rozwiązania raportowego stawał przed strategicznym wyborem: raportowanie relacyjne, baza OLAP, czy jedno i drugie za cenę skomplikowania. Dodatkowo sytuacji nie poprawiał fakt, że czasami uważa się raportowanie wielowymiarowe za lepszą wersją raportowania relacyjnego. To nie jest prawda, a firmy, które próbują zastąpić systemy raportowania relacyjnego raportowaniem OLAP bardzo szybko stają przed problemami nie do rozwiązania.
Koncepcja UDM to kostka, która jest tylko perspektywą na dane relacyjne oraz tradycyjnie wiązane z OLAP-em, a także nowe techniki, takie jak synchronizowanie agregacji z danymi relacyjnymi. Wszystko po to, żeby mieć jednocześnie:
| • | Skomplikowane obliczenia i szczegółowość raportowania. |
| • | Dane aktualne i bardzo krótkie odpowiedzi na dowolne zapytania. |
Efekt to połączenie najlepszych cech raportowania wielowymiarowego i relacyjnego.
Aby UDM stał się rzeczywistością, Analysis Services zostało wyposażone w szereg cech. Najważniejsze to:
| • | Data Source View – logiczna warstwa dostępu do danych łącząca różne źródła relacyjne w jeden widok, z możliwością tworzenia wirtualnych tabel, wirtualnych kluczy i wirtualnych relacji, z możliwością dodawania własnych wyliczeń i opisywania tabel i kolumn zrozumiałymi nazwami. |
| • | Pro-active caching – technologia, której celem jest zlikwidowanie opóźnień pomiędzy zmianą w danych relacyjnych, a odświeżeniem agregacji. Dzięki temu kostka wielowymiarowa staje się w zasadzie cache’m dla danych relacyjnych. Dzięki tej technologii MOLAP i ROLAP łączą się jedno, ale nie tak, jak w HOLAP-ie – statycznie. Teraz zapytanie od użytkownika końcowego będzie zrealizowane w oparciu dane ze struktur MOLAP-owych lub z danych relacyjnych – synchronizując jednocześnie cache z danymi - w zależności od tego czy dane relacyjne się zmieniły, czy nie. |
| • | Możliwość tworzenia kostek OLAP w oparciu o wiele tabel faktów. |
| • | Możliwość tworzenia wymiarów w oparciu o relacje wiele do wielu. |
| • | Przeniesienie atrybutów – kolumn z tabel w bazie relacyjnej – do wymiarów i budowanie hierarchii w oparciu o atrybuty. |
Dzięki UDM-owi architektura naszego systemu może być prostsza, ponieważ mamy teraz jedno miejsce, jeden model, z którego raportujemy zarówno relacyjnie, jak i wielowymiarowo. A to oznacza, że jesteśmy w stanie dostarczyć lepszy system BI, którym będzie łatwiej zarządzać i łatwiej będzie go można modyfikować, a zatem całkowity koszt posiadania takiego systemu będzie niższy.
Skalowalność
Przejdźmy teraz do problemu skalowalności – bardzo szybko okaże się, że jest to wyzwanie dla naszego systemu BI. Zarówno silnik relacyjny, jak i silnik OLAP pozwalają na partycjonowanie danych. W silniku relacyjnym możliwe jest tworzenie partycji typu range. Duży fizycznie zbiór danych dzielimy przy pomocy pewnego kryterium – tzw. klucza partycjonowania na wiele mniejszych fragmentów, na zasadzie „od – do”. Każdy taki fragment formuje partycję, a wszystkie partycje razem wzięte dają wyjściowy zbiór danych. Najczęściej pojawiającym się scenariuszem w przypadku relacyjnych hurtowni danych jest partycjonowanie tabel faktów względem czasu. Piękno tego rozwiązania polega na tym, że z jednej strony jesteśmy w stanie znacznie uprościć operacje administracyjne na dużych zbiorach danych, z drugiej strony partycjonowanie jest całkowicie przezroczyste dla aplikacji i jest w stanie dać przyrost wydajności.
Partycjonowanie tabel faktów może stanowić także podstawę do partycjonowania kostek OLAP.
Skalowanie oznacza też potrzebę dostępu do dużej ilości pamięci. System BI, w którym zarówno w procesie ETL, jak i podczas odpytywania hurtowni relacyjnej, bardzo często mamy do czynienia z operacjami łączenia danych, grupowania, agregowania i sortowania, jest szczególnie wymagający w tym względzie. Liniowy dostęp do dużej ilości pamięci jest krytyczny. W serwerze OLAP, jeśli pojawiają się bardzo liczne wymiary, jeśli mamy do czynienia z dużą liczbą jednoczesnych użytkowników – także odniesiemy korzyść, jeśli będziemy dysponować dużą ilością liniowo adresowanej pamięci. Wszędzie w tych zastosowaniach platforma 64-bit jest tym, czego potrzebujemy. Wszystkie produkty serwerowe z pakietu SQL Serwer 2005 działają zarówno na platformie x64 jak i na platformie Itanium.
Możliwości analityczne
Możliwości analityczne, zarówno silnika relacyjnego, jak i Analysis Services, zostały znacznie rozbudowane. Język zapytań do bazy relacyjnej - Transact-SQL - został rozbudowany m.in. o:
| • | Możliwość tworzenia zapytań rekurencyjnych. |
| • | Operacje denormalizacji i normalizacji danych (pivot i unpivot). |
| • | Operacje except – wybór unikalnych wartości ze zbioru danych, które nie występują w zbiorze referencyjnym. |
| • | Operację intersect – wybór unikalnych wartości występujących jednocześnie w dwóch zbiorach danych. |
| • | Funkcje do rankingu i próbkowania tabel. |
W Analysis Services zaimplementowano nowy obiekt – Key Performance Indicator (KPI). Wskaźnik, który zawiera w sobie nie tylko aktualną wartość (tak, jak miara), ale również cel (wartość, do której dążymy), status (czy wartość aktualna jest powyżej czy poniżej wartości, do której dążymy i czy to dobrze czy źle), oraz trend (zmiana obserwowanej wartości w czasie). Możliwe jest też budowanie hierarchii tych wskaźników – to jest właśnie infrastruktura, dzięki której możliwe jest budowanie systemów informowania kierownictwa.
Bardzo rozbudowany (6 nowych algorytmów) został Data Mining (DM). Algorytmy DM wyszukują nieoczywiste zależności w danych oraz śledzą trendy, dzięki czemu można zbudować model mining’owy. Model służy do klasyfikowania, przewidywania i planowania działań przyszłych w oparciu o istniejące informacje. Dzięki tym algorytmom możemy m.in.:
| • | Skierować kampanię marketingową do odpowiednich osób. |
| • | Przewidzieć przyszłą sprzedaż. |
| • | Zasugerować klientowi kupującemu jakiś towar w sklepie internetowym, co jeszcze mógłby kupić. |
Wśród narzędzi związanych z DM znajdziemy przeglądarki do modeli mining’owych (dla każdego algorytmu oddzielna przeglądarka), narzędzie do porównywania dokładności i przydatności konkretnego modelu mining’owego w danej sytuacji, rozszerzenia Transact-SQL o polecenia do tworzenia, modyfikowania i predykcji w oparciu o modele mining’owe. Z całą pewnością Microsoft ma teraz konkurencyjną ofertę także w obszarze DM
Całość oferty BI dopełnia Reporting Services. Zbudowana w oparciu o .NET Framework, otwarta, rozszerzalna, skalowalna i wydajna platforma do raportowania. Platforma, która jest w stanie spełnić potrzeby konsumentów informacji, ale również w dużym stopniu – analityków, dzięki możliwości tworzenia bogatych, interaktywnych raportów – także korzystających z danych zgromadzonych w Analysis Services. Platforma, która oferuje nie tylko narzędzie deweloperskie do tworzenia raportów, ale również narzędzie dla użytkownika merytorycznego (Report Builder). Platforma, którą można rozszerzać, jeśli okaże się, że brakuje nam jakiegoś elementu wizualnego, nie możemy dostać się do nietypowego źródła danych, albo potrzebujemy raportu w nieprzewidzianym przez twórców formacie.
Podsumowanie
Zamiast podsumowania – zachęcam do lepszego poznania przedstawionych w artykule narzędzi (zapraszam na stronę www.microsoft.com/poland/sql) i do budowania przy ich pomocy systemów BI, które są w stanie sprostać wymaganiom szerokiego grona odbiorców w największych firmach.
 | Paweł Borowiecki |