pobierz

Załącznik A do SOPZ
SRHD
System Raportujący Oparty na Hurtowni Danych
Opis systemu
1
Spis treści
1
OPIS SYSTEMU SRHD ............................................................................................................... 3
2
ARCHITEKTURA LOGICZNA SYSTEMU ............................................................................. 3
3
PROCEDURY ZASILANIA SRHD DANYMI (ETL) ............................................................... 6
4
PROCEDURY PRZETWARZANIA DANYCH SRHD ............................................................ 8
5
PROCEDURA CZYSZCZENIA DANYCH ............................................................................... 8
6
PROCEDURA ŁADOWANIA DANYCH .................................................................................. 9
7
UPRAWNIENIA I BEZPIECZEŃSTWO .................................................................................. 9
2
1 Opis systemu SRHD
Celem Systemu Raportującego opartego na Hurtowni Danych (SRHD) jest
zgromadzenie, zorganizowanie i zoptymalizowanie pod kątem szybkiego
raportowania - danych pochodzących z poszczególnych systemów Centralnego
Systemu Teleinformatycznego. SRHD służy przekształcaniu dużych wolumenów
danych w informacje, a następnie przekształcaniu tych informacji w wiedzę.
Przechowuje dane zarówno aktualne jak i historyczne pochodzące z wielu źródeł
(systemów). Wspomaga tym samym proces podejmowania decyzji
strategicznych przez pracowników szczebla kierowniczego Ministerstwa.
System Raportujący Oparty na Hurtowni Danych (SRHD) oparty jest o aplikację:
Oracle Business Intelligence 11.1.1.7.150120 oraz bazę danych: Oracle
Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production.
Aplikacja wykorzystuje 2 środowiska (produkcyjne oraz szkoleniowo-testowe)
korzystające z 2 klastrów po 2 maszyny fizyczne oparte na serwerach IBM
system x3550 z systemem operacyjnym Red Hat Enterprise Linux Server release
6.6.
Aplikacja SRHD posiada do ładowania danych korzysta z 2 aplikacji źródłowych:
 KSI SIMIK 07-13,
 SL2014.
Na potrzeby autoryzacji użytkowników SRHD wykorzystuje AD poprzez
mechanizmy ADFS. Dodatkowo na potrzeby weryfikacji uprawnień aplikacja w
interwałach czasowych dokonuje synchronizacji uprawnień Row-Level Security z
systemami źródłowymi niezależnie od procesu zasilania danymi.
Na potrzeby raportowania systemu SL2014 zbudowano model oparty o struktury
gwiazdy w ramach poszczególnych obszarów analitycznych.
2 Architektura logiczna Systemu
Architektura logiczna systemu SRHD przedstawia główne komponenty systemu
oraz powiązania między nimi. Definiuje także połączenia pomiędzy
podsystemami
oraz
przepływy
sterowania
pomiędzy
wewnętrznymi
komponentami systemu oraz komponentami zewnętrznymi w stosunku do
projektowanego systemu.
Poniższy schemat prezentuje strukturę logiczną systemu SRHD
3
MIR LAN
Synchronizacja użytkowników/uprawnień z maks. opóźnieniem do 5 min (w tym dzienna)
Synchronizacja użytkowników/uprawnień
Oracle Business Intelligence Foundation Suite
BI Answers
WebLogic Server
LDAP
Enterprise Manager
Użytkownik
zewnętrzny
BI Publisher
Użytkownik
wewnętrzny
Administrowanie OBI
Generowanie/pobieranie raportu
HTTP/HTTPS
Administrowanie procesami ETL
BI Dashboards
Przegląd/zarządzanie metadanymi
HTTP/HTTPS
Repozytorium BI (RPD)
Admin Tool
Generowanie
/pobieranie
raportu
KSI SIMIK 07-13
(replika)
ETL
MODEL
MODEL
ZINTEGROWANY
ZINTEGROWANY
ETL
ETL
OBSZAR
OBSZAR
PRZEJŚCIOWY
PRZEJŚCIOWY
ODI/OWB/narzędzia bazy Oracle
Modele
tematyczne
ODI/OWB/narzędzia bazy Oracle
ESSBASE
ETL
SL2014
SL2014
(replika)
(replika)
Synchronizacja użytkowników/uprawnień
W przedstawionym ujęciu konceptualnym źródłem danych dla systemu SRHD są
systemy Zamawiającego, ujęte w bloku MIR LAN. Poniżej przedstawiono krótką
charakterystykę przepływów przedstawionych na powyższym diagramie:
Przepływy zewnętrzne (do lub z systemu SRHD):
1. KSI SIMIK 07-13 (replika) → OWB/narzędzia bazy Oracle: źródłem danych dla
systemu SRHD będzie replika systemu KSI SIMIK 07-13.
2. Użytkownik wewnętrzny → Oracle Business Intelligence Foundation Suite
(generowanie raportu): użytkownik wewnętrzny może komunikować się
z aplikacją Oracle Business Intelligence (jej elementami składowymi) w celu
uruchomienia procesu generowania raportów/analiz, w oparciu o wprowadzone
parametry;
3. Użytkownik wewnętrzny → Oracle Business Intelligence Foundation Suite
(Administrowanie): użytkownik wewnętrzny o nadanych rolach administratora
technicznego i/lub merytorycznego może wykonywać czynności administracyjne
w Systemie;
4. Użytkownik wewnętrzny → OWB/narzędzia bazy Oracle: użytkownik
wewnętrzny o nadanych rolach administratora technicznego może zarządzać
procesami ETL dostępnymi za pośrednictwem OWB lub innych narzędzi bazy
danych Oracle;
5. Oracle Business Intelligence Foundation Suite → Użytkownik wewnętrzny
(pobieranie raportu): po wygenerowaniu raportu użytkownik wewnętrzny może
4
pobrać dane raportu (wyeksportowane do jednego z predefiniowanych formatów)
na swój komputer lokalny;
6. Użytkownik zewnętrzny → Oracle Business Intelligence Foundation Suite
(generowanie raportu): użytkownik zewnętrzny może komunikować się z
aplikacją Oracle Business Intelligence (jej elementami składowymi) w celu
uruchomienia procesu generowania raportów/analiz, w oparciu o wprowadzone
parametry;
7. Oracle Business Intelligence Foundation Suite → Użytkownik zewnętrzny
(pobieranie raportu): po wygenerowaniu raportu użytkownik zewnętrzny może
pobrać dane raportu (wyeksportowane do jednego z predefiniowanych formatów)
na swój komputer lokalny;
8. Użytkownik wewnętrzny → Repozytorium BI (RPD): użytkownik wewnętrzny
o nadanych rolach administratora technicznego i/lub merytorycznego może
komunikować się bezpośrednio z repozytorium BI (RPD), w celu
tworzenia/usuwania/modyfikacji
elementów
prezentowanych
w warstwie
prezentacji aplikacji Oracle Business Intelligence, a tym samym dostępnych dla
raportów (predefiniowanych i tworzonych ad hoc);
9. MIR LAN → OWB/narzędzia bazy Oracle: replikacja uprawnień pochodzących
z systemów zewnętrznych w stosunku do systemu SRHD, na uprawnienia
użytkowników/ról w ramach systemu SRHD.
10.
KSI SIMIK 07-13 (replika) → LDAP: synchronizacja użytkowników oraz
uprawnień pomiędzy bazą produkcyjną systemu KSI SIMIK 07-13 a serwerem
LDAP, w czasie nieprzekraczającym 5 minut od momentu modyfikacji uprawnień
w systemie źródłowym.
Przepływy wewnętrzne obrazują procesy przetwarzania i wymiany danych
zachodzące w obrębie systemu SRHD, pomiędzy tworzącymi go elementami
składowymi. Skrócona charakterystyka przepływów wewnętrznych wygląda
następująco:
Przepływy wewnętrzne (w obrębie systemu SRHD):
1. Repozytorium BI (RPD) ↔ Oracle Business Intelligence Foundation Suite:
dwustronna komunikacja pomiędzy OBI a repozytorium metadanych pozwala na
wykorzystanie obiektów zdefiniowanych w ramach obszarów zainteresowań do
tworzenia raportów/analiz;
2. LDAP → Oracle Business Intelligence Foundation Suite: uprawnienia
pochodzące z repliki bazy danych SIMIK 07-13 przechowywane są na serwerze
LDAP. Podczas normalnej pracy aplikacja Oracle Business Intelligence korzysta
z serwera LDAP do pobierania informacji o uprawnieniach przysługujących
poszczególnym użytkownikom/rolom aplikacyjnym.
5
3. OWB/narzędzia bazy Oracle → Obszar przejściowy: dane pozyskane z
systemów zewnętrznych w stosunku do systemu SRHD, jak również z
produkcyjnych baz danych systemu KSI SIMIK 07-13 (repliki) zasilany będą do
obszaru przejściowego po przetworzeniu i oczyszczeniu w aplikacji OWB, lub
narzędzi udostępnianych przez bazę Danych Oracle wraz z dostarczanymi
dodatkami;
4. Obszar przejściowy → OWB/narzędzia bazy Oracle: dane z obszaru
przejściowego podlegają zasilaniu do modelu zintegrowanego z wykorzystaniem
narzędzia OWB lub narzędzi udostępnianych przez bazę Danych Oracle wraz
z dostarczanymi dodatkami;
5. OWB/narzędzia bazy Oracle → Model zintegrowany: dane z obszaru
przejściowego ładowane będą do docelowej hurtowni danych, czyli do modelu
zintegrowanego. Na tym etapie zasilania realizowane będą transformacje na
danych, takie jak filtracje, czyszczenie, grupowania, agregacje, konwersje typów
itd., a następnie ładowane będą do tabel faktów i wymiarów zlokalizowanych w
modelu zintegrowanym.
6. Model zintegrowany → Modele tematyczne: na podstawie danych
załadowanych do modelu zintegrowanego utworzone zostaną modele
(hurtownie) tematyczne (ang. Data Marts), obejmujące różne podobszary
działalności Zamawiającego;
7. Model zintegrowany → Repozytorium BI (RPD): fizyczna struktura tabel
zlokalizowanych w modelu zintegrowanym zostanie odzwierciedlona w postaci
obiektów warstwy logicznej repozytorium BI oraz powiązań pomiędzy tymi
obiektami. Obiekty zostaną udostępnione użytkownikom końcowym za
pośrednictwem warstwy prezentacji repozytorium BI;
8. Oracle Data Integrator → LDAP: transfer przetworzonych uprawnień,
pochodzących z systemów zewnętrznych na uprawnienia obowiązujące
w ramach OBI (użytkownicy/uprawnienia) i przechowywane na serwerze LDAP;
9. LDAP → Oracle Business Intelligence Foundation Suite: uprawnienia
pochodzące z systemów zewnętrznych, a zmigrowane do systemu SRHD za
pomocą narzędzi ODI lub OWB, lub narzędzi udostępnianych przez bazę Danych
Oracle wraz z dostarczanymi dodatkami przechowywane są na serwerze LDAP.
Podczas normalnej pracy aplikacja Oracle Business Intelligence korzysta
z serwera LDAP do pobierania informacji o uprawnieniach przysługujących
poszczególnym użytkownikom/rolom aplikacyjnym.
3 Procedury zasilania SRHD danymi (ETL)
Istotny element systemu SRHD stanowią procesy ETL (ang. Extraction,
Transformation, Loading), odpowiedzialne za cykliczne zasilanie hurtowni
6
nowymi danymi pochodzącymi z systemów źródłowych. Głównym zadaniem tych
procesów jest:
 ekstrakcja danych z systemów źródłowych (systemów transakcyjnych oraz
dodatkowych źródeł danych),
 przekształcenie danych do postaci struktur docelowych,
 wyczyszczenie danych wprowadzanych do hurtowni, w tym eliminacja błędów
niespójności, niekompletności, redundancji, wraz z rejestracją wykrytych
nieprawidłowości w danych,
 załadowanie poprawnych danych do hurtowni.
Realizacja procesów ETL wykonana jest za pośrednictwem dostarczonych w
ramach systemu SRHD narzędzi:
 PL/SQL
 narzędzia bazy danych Oracle: Oracle Streams, Oracle Data Pump (export
import), Database Link,
System SRHD zasilany jest danymi pochodzącymi z baz danych systemów
zewnętrznych.
W ramach procesu ETL zaimplementowany został mechanizm ładowania danych
z uwzględnieniem kwartalnej granulacji danych. Dla poszczególnych tabel
dodany został klucz jednoznacznie identyfikujący okres, za który dane są
załadowane do Hurtowni Danych. Maska klucza ma format YYYYK, gdzie YYYY
oznacza rok, K numer kolejny kwartału - typ danych NUMBER. W oparciu o
parametr przyjmujący wartość domyślną na podstawie daty systemowej
wyznaczony jest dany kwartał dla którego dane w systemie SRHD będą
czyszczone oraz ładowane ponownie. Źródłem danych dla procesu pobierania
danych będzie replika bazy systemu źródłowego. Dane zmagazynowane w
Hurtowni Danych, które odnoszą się do zamkniętego kwartału (data systemowa
wskazuje na dzień późniejszy niż ostatni dzień poprzedniego kwartału) nie
podlegają procesowi ponownego czyszczenie oraz ponownego ładowania.
W celu przeładowania danych archiwalnych kwartałów zaimplementowany został
proces z możliwością podania wartości klucza YYYYK.
Zasilenie danych systemu SRHD realizowane jest poprzez procesy ETL
zbudowane w oparciu o źródła danych wykorzystywanych w obecnym systemie.
Procesy ETL wykorzystywany do zasilenia obiektu docelowego odkładają
informacje o liczbie pobranych rekordów oraz ich liczbę załadowaną do obiektu
docelowego. Wszystkie logi z wykonywanych operacji są odkładane w
dedykowanych
tabelach
(tabelach
XXT_SRHD_PROCES_ETL,
XXT_SRHD_ERROR_ETL) z informacją o czasie ich uruchomienia, jakiego
obiektu dotyczą. Proces czyszczenia danych będzie realizowany poprzez
ponowne załadowanie danych w cyklu okresowym lub poprzez ręczne
uruchomienie procesu.
7
4 Procedury przetwarzania danych SRHD
W ramach procedury przetwarzania danych SRHD w Oracle Warehouse Builder
został zaimplementowany mechanizm ładowania danych z uwzględnieniem
kwartalnej granulacji danych. Dla wszystkich tabel w strukturach SRHD został
dodany klucz jednoznacznie identyfikujący okres, za który dane zostały
załadowane do Hurtowni Danych. Maska klucza ma format YYYYK, gdzie YYYY
oznacza rok, K numer kolejny kwartału - typ danych NUMBER. W oparciu o
parametr przyjmujący wartość domyślną na podstawie daty systemowej zostanie
wyznaczony dany kwartał, dla którego procedury przetwarzania danych realizują
proces czyszczenia oraz ponownego ładowania.
Dane zmagazynowane w Hurtowni Danych, które odnoszą się do zamkniętego
kwartału (data systemowa wskazuje na dzień późniejszy niż ostatni dzień
poprzedniego kwartału) nie podlegają procesowi ponownego czyszczenie oraz
ponownego ładowania w zadaniu harmonogramowym.
Został zaimplementowany mechanizm ręcznego uruchamiania procesu
czyszczenia oraz ładowania z możliwością podania wartości klucza rok kwartał.
Zasilenie danych systemu SRHD realizowane jest poprzez procesy ETL
zbudowane w oparciu o źródła danych wykorzystywanych w obecnym systemie.
Każdy element procesu ETL wykorzystywany do zasilenia obiektu docelowego
będzie odkładał informacje o liczbie pobranych rekordów oraz ich liczbę
załadowaną do obiektu docelowego. Wszystkie logi z wykonywanych operacji
będą odkładane w dedykowanej tabeli z informacją o czasie ich uruchomienia,
jakiego obiektu dotyczą oraz z jakiego mechanizm pochodzą. Dodatkowo
informacje o błędach będą zapisywane w powiązaniu z źródłem danych oraz
czasem wykonania operacji.
W związku z powyższym proces czyszczenia danych będzie realizowany
poprzez ponowne załadowanie danych w cyklu okresowym lub poprzez ręczne
uruchomienie procesu.
5 Procedura czyszczenia danych
Czyszczenie danych jest realizowane automatycznie każdorazowo podczas
uruchomienia procesu ładowania, bazy docelowej z bazy przejściowej, przez
zadanie harmonogramowe. Procedura czyszczenia danych jest wykonywana z
domyślną wartością klucza rok kwartał, określaną na podstawie daty systemowej.
Procedurę czyszczenia danych można uruchomić także ręcznie z podaną
wartością klucza rok kwartał a także z nazwą tabeli która ma być wyczyszczona.
8
Tabele z danymi raportowymi zawierają kolumnę ROKKW, która określa z
którego okresu dane znajdują się w danym rekordzie. Procedura czyszczenia
danych jest procedurą bazodanową, która wykonuje operację usuwania danych
na tabeli w kontekście klucza rok kwartał. W wyniku działania tej procedury
usuwane są rekordy, dla których wartość kolumny ROKKW jest równa wartości
podanego w parametrze tej procedury klucza rok kwartał.
6 Procedura ładowania danych
Ładowanie danych danych realizowane jest z wykorzystaniem mechanizmu
DBLINK. Ładowanie uruchomione przez zadanie harmonogramowe jest
realizowane z domyślną wartością klucza rok kwartał, określoną na podstawie
daty systemowej. Wartość klucza można zmienić na etapie podawania parametru
uruchomieniowego podczas ręcznego uruchomienia procedury ładowania.
Procedura ładowania danych odkłada informacje w dedykowanych tabelach na
temat ładowanego obiektu, liczbę rekordów w tabeli źródłowej, liczby rekordów w
tabeli docelowej, a także czasem wykonania operacji.
Procedurę ładowania danych można uruchomić także ręcznie z podaną
wartością klucza rok kwartał a także z nazwą tabeli która ma być wyczyszczona.
7 Uprawnienia i bezpieczeństwo
Uprawnienia
System raportowania umożliwia tworzenie zestawień i analiz przez wielu
użytkowników, w oparciu o różne poziomy uprawnień. Raporty tworzone przez
określoną grupę użytkowników są widoczne dla danej grupy jak również niektóre
szczegółowe i „wrażliwe dane” oraz funkcje systemu powinny są dostępne tylko z
określonego zestawu użytkowników.
W systemie SRHD proces autoryzacji i replikacji uprawnień użytkowników oparty
jest o wielopoziomowy model dostępu obejmujący następujące elementy:
 poziom zabezpieczeń dla obiektów/funkcji (Object Level Security) - zapewnia
zabezpieczenie dostępu do logicznych obiektów na podstawie roli przypisanej
do użytkownika.
 poziom bezpieczeństwa danych (Data Level Security) – zapewnia kontrolę
widoczności danych (rodzaju i ilości) na raportach na podstawie uprawnień
użytkownika do danych w systemie transakcyjnym (źródłowym). W ramach
integracji z systemem KSI SIMIK 07-13 wykorzystana jest polityka dostępu do
danych – Row Level Security.
 autoryzacja użytkownika (User Level Security) - zapewniająca mechanizm
weryfikacji dostępu użytkownika do systemu. Wykorzystany został wbudowany
9
mechanizm uwierzytelnienia oparty o Oracle WebLogic Server, który
wykorzystuje (integruje) zewnętrzne katalogi użytkowników (OpenLDAP)
zaimplementowane dla potrzeb integracji z innymi systemami Zamawiającego.
Poza uwierzytelnieniem, kluczowym aspektem bezpieczeństwa jest zapewnienie
dostępu użytkownika wyłącznie do przypisanych mu uprawnień. W odróżnieniu
od definiowania polityk bezpieczeństwa użytkownikom w grupach w
zewnętrznych katalogach użytkowników system korzysta z modelu opartego na
rolach kontroli dostępu do aplikacji. Poziomy bezpieczeństwa przypisywane są
wówczas do ról aplikacyjnych (mogą one posiadać hierarchiczną strukturę, w
której uprawnienia mogą być dziedziczone z innych ról), które mapowane będą
bezpośrednio do użytkowników lub grup z zewnętrznych katalogów
użytkowników. Przypisywanie grup użytkowników do odpowiednich ról
aplikacyjnych jest realizowane w Enterprise Manager (domyślnie role systemowe
to: BISystem, BIAdministrator, BIAuthor, BIConsumer).
Polityka dostępu do danych – Row Level Security
Bezpieczeństwo danych w SRHD w odniesieniu do danych pochodzących z
systemów zewnętrznych zapewnia w szczególności wbudowany mechanizm
bazy danych Oracle – polityk bezpieczeństwa (security policy), które kontrolują
dostęp użytkowników na poziomie obiektów bazy danych (określonego obiektu
schematu , w szczególności tabel i perspektyw) oraz konkretnych rodzajów
działań dozwolonych dla każdego użytkownika (tj. SELECT). Podczas każdego
odwołania do obiektu bazy danych dla którego zdefiniowano politykę
bezpieczeństwa następuje automatyczne filtrowanie danych przez mechanizm
bazy danych poprzez dodanie w klauzuli WHERE dla danej operacji
dodatkowego warunku zawężającego opartego o funkcję.
Bezpieczeństwo komunikacji
Bezpieczeństwo komunikacji zapewniono dzięki wdrożeniu następujących
zabezpieczeń:
 Separacja środowisk na poziomie warstwy przetwarzania i składowania.
Środowisko produkcyjne i testowe zbudowane są na osobnych urządzeniach.
Posiadają dedykowane serwery, miecierze, switche LAN, switche SAN i load
balancery.
 Separacja sieci za pomocą VLANów. Zastosowano osobne VLANy dla
podsieci aplikacyjnej, managementowej i backupowej.
 Zastosowanie protokołu HTTPS podczas dostępu do aplikacji z sieci LAN i
Internet.
10
 Zastosowanie zapór sieciowych na systemach operacyjnych. Konfiguracja
umożliwia komunikację tylko na wymaganych portach. Pozostałe porty zostają
zamknięte.
 Zastosowanie dodatku Advanced Security bazy danych Oracle zapewnia
szyfrowanie transmisji do/z bazy danych.
Poniższe schematy prezentują fizyczna strukturę sieci LAN
Środowisko produkcyjne
Środowisko szkoleniowo-testowe
MIR LAN ROUTER
MIR LAN ROUTER
Load Balancer
Load Balancer
Switche LAN
Load Balancer
Load Balancer
Biblioteka taśmowa
Switche LAN
Switche SAN
Macierz dyskowa
Switche SAN
Macierz dyskowa
Serwery
APP
Serwery
DB
Serwer
zapasowy
Serwery
APP
Sieć aplikacyjna
Sieć MGMT
Sieć PRIVATE
Serwery
DB
Sieć aplikacyjna
Sieć MGMT
Sieć PRIVATE
11