Wsparcie Techniczne

Najnowsza wersja to SAS Visual Analytics 7.3. O nowościach można przeczytać w SAS® Visual Analytics 7.3: User’s Guide.

Wymagania systemowe dla SAS Visual Analytics zostały opisane w dokumencie - SAS® Visual Analytics 7.3. Dla SAS Visual Analytics licencjonowanego razem z SAS Visual Statistics wymagania znajdują się w dokumencie SAS® Visual Analytics 7.3 and SAS® Visual Statistics 7.3.

SAS Visual Analytics jest dystrybuowany w 2 wersjach: rozproszonej (distributed) i nierozproszonej (non-distributed, SMP – Single Machine Platform). Wersja nierozproszona dostępna jest od SAS Visual Analytics 6.1 i działa na pojedynczej maszynie. Wersja rozproszona działa na więcej niż jednej maszynie i składa się z węzła ‘master node’ i węzłów ‘worker node’.

Funkcjonalność obu wersji jest dokładnie taka sama. Wersja rozproszona pozwala na analizę dużo większych zbiorów danych, jak również może być wykorzystywana przez dużą liczbę użytkowników. Głównym komponentem obu wersji jest SAS LASR Analytics Server – platforma analityczna oferująca środowisko do jednoczesnego dostępu do danych dla wielu użytkowników. Dane przechowywane są w pamięci, jak również całe przetwarzanie odbywa się w pamięci.

Język interfejsu może zmienić każdy użytkownik po zalogowaniu do VA Hub, klikając w nazwę użytkownika w górnej prawej części ekranu, wybierając ‘Ustawienia’ i wskazując ‘Ustawienia regionalne użytkownika’. Ustawienia zostaną zastosowane przy ponownym zalogowaniu się do VA.

Ustawienia językowe można tez zmienić dla wybranej aplikacji. W tym celu w danej aplikacji należy wybrać Plik  Preferencje. Zmiana będzie widoczna po ponownym zalogowaniu się do aplikacji.

SAS Visual Analytics oferuje 2 rodzaje interfejsu – klasyczny i nowoczesny. Administrator może globalnie ustawić, który interfejs będzie domyślnie wyświetlany, ale każdy z użytkowników może to zmienić dla siebie. W tym celu po zalogowaniu do VA Hub należy kliknąć w nazwę użytkownika, wybrać ‘Ustawienia’ i ustawić ‘Wygląd domyślny’.

Wersja Visual Analytics 7.3 pozwala na eksport danych do Excela z Przeglądarki raportów tylko wtedy, gdy działa ona w trybie klasycznym. Jeżeli ta funkcjonalność jest niezbędna to należy albo przestawić Przeglądarkę raportów w tryb klasyczny (Punkt 5), albo korzystać z eksportu w Projektancie raportów.

Formaty zdefiniowane przez użytkownika powinny być nałożone na kolumny przed załadowaniem danych do VA. Żaden moduł VA nie pozwala na zmianę formatu na format zdefiniowany przez użytkownika.<

Szczegółowe informacje na temat wykorzystania formatów w VA opisuje nota 47100.

Eksplorator danych, Projektant raportów oraz Przeglądarka raportów wykorzystują formaty nałożone na dane podczas ładowania. Ważne jest, żeby format był dostępny dla serwera aplikacji, który dane będzie ładował (Punkt 33).

Projektant raportów pozwala na zmianę formatu na jeden ze standardowych dla zmiennych numerycznych. Jest również możliwość przywrócenia oryginalnego formatu. Zmienne numeryczne z nałożonym formatem użytkownika są zawsze traktowane jako zmienne klasyfikujące. Dla zmiennych znakowych format nie może być zmieniony.

Eksplorator danych nie pozwala na zmianę formatu. Zmienne numeryczne z nałożonym formatem użytkownika są zawsze traktowane jako zmienne klasyfikujące.

Moduł Przygotowanie danych korzysta z definicji formatów podczas dostępu do danych. Może to być format standardowy lub zdefiniowany przez użytkownika. Format można zmieniać na jeden ze standardowych. Po zmianie nie jest możliwe przywrócenie formatu zdefiniowanego przez użytkownika (w tym celu należy kolumnę usunąć z wyniku i ponownie dodać).

W przypadku systemów Linux, aby format walutowy pokazywał złotówki, może być konieczne dodanie polskich ustawień regionalnych dla SAS Web Application Servera. W tym celu w plikach setenv.sh dla serwerów SASServer1_1 i SASServer12_1 (o ile istnieje) należy dopisać opcje:

-Duser.country=PL -Duser.language=pl

a następnie zrestartować usługi. Opcje te należy dopisać w linii zaczynającej się od "JVM_OPTS".

W przypadku, gdy w raporcie umieszczony jest proces gotowy z promptem pozwalającym na wybór wielu wartości, może się zdarzyć, że proces zakończy się komunikatem: Błąd procesu gotowego. Nie wykonano procesu gotowego.

SAS Visual Analytics do wykonania procesu gotowego używa SAS Stored Process Web Application, przesyłając nazwę raportu i wybrane wartości prompta jako parametry w URL. Jeżeli wybranych wartości jest zbyt dużo, URL jest zbyt długi dla SAS Web Servera.

Rozwiązaniem jest zwiększenie parametru LimitRequestLine w pliku konfiguracyjnym SAS Web Servera – httpd.conf (/Lev1/Web/WebServer/conf).

SAS Visual Analytics należy do produktów, które wymagają aktualizacji licencji zarówno dla SAS Foundation, jak i w metadanych. Dlatego aktualizacja licencji składa się z 2 kroków:

• Aktualizacji licencji SAS Foundation – od wersji 9.4 M3 wykonywana jest przez aplikację SAS Deployment Manager (Apply SAS Foundation license file for renewal); we wcześniejszych wersjach do odnowienia licencji służyło osobne narzędzie (Renew SAS Software Utility na Windows i skrypt sassetup na UNIX/Linux)
• Aktualizacji licencji w metadanych, która jest wykonywana przez SAS Deployment Manager (Update SID File in Metadata). Ten krok wykonywany jest raz dla danego środowiska.

 

Użytkownicy SAS Visual Analytics komunikują się z aplikacją przez przeglądarkę, dlatego otwarty musi być jedynie port, na którym działa SAS Web Server (domyślnie 7980 na Linuxie lub 80 na Windows).

Klient mobilny łączy się z SAS Visual Analytics poprzez serwis SASVisualAnalyticsTransport, który powinien działać na tym samym serwerze aplikacji, na którym jest rozmieszczone SAS Visual Analytics i być dostępny na tym samym porcie.

Nie. Można skonfigurować guest access, która umożliwia anonimowy dostęp to wybranych zasobów i funkcjonalności. Szczegóły konfiguracji znajdują się w SAS® Visual Analytics 7.3 Administration Guide w rozdziale Fine Tuning/Supporting Guest Access.

Co-located Data Provider jest to rozproszone źródło danych, zainstalowane na każdej maszynie, na której działa serwer LASR. Może być zainstalowany i skonfigurowany tylko w wersji rozproszonej, choć nie jest konieczny do działania SAS Visual Analytics. Umożliwia szybkie ładowanie danych do pamięci – ładowanie jest wykonywane lokalnie, gdyż każdy węzeł odczytuje część danych, która jest zapisana fizycznie na tej samej maszynie, bez potrzeby przesyłania przez sieć.

Jako źródło danych może być wykorzystany SAS High-Performance Deployment of Hadoop, dostarczany wraz z wersją rozproszoną SAS Visual Analytics lub inna wspierana dystrybucja Hadoopa.

Jest to biblioteka BASE, wykorzystywana do tworzenia kopii danych ładowanych przez użytkownika do serwera LASR (Import danych), dzięki czemu mogą one być automatycznie załadowane przy starcie serwera LASR (Punkt 3).

W bibliotece tej będą zapisywane tylko dane, które spełniają warunki wykonania automatycznego ładowania przy starcie, czyli pliki importowane z lokalnego komputera oraz dane z Google Analytics, Facebooka lub Twittera.

Dane załadowane do pamięci są z niej usuwane w momencie zatrzymania serwera LASR. Przy starcie serwera LASR muszą zostać ponownie do pamięci załadowane, żeby można z nich było korzystać. Administrator może załadować dane, do których jest dostęp na serwerze. Natomiast dane lokalne, importowane przez użytkowników, mogą być automatycznie ładowane w momencie startu serwera tylko wtedy, gdy zostanie skonfigurowany mechanizm Reload on start dla biblioteki.

W tym celu w definicji biblioteki LASR należy podać następujące opcje:

• Data Provider Library – biblioteka BASE, w której będą umieszczane kopie ładowanych do pamięci danych (Punkt 2)
• We właściwościach biblioteki LASR, na zakładce Extended Attributes zdefiniować atrybuty:
  
  • VA.ReloadOnStart.Enabled      Yes
  • VA.ReloadOnStart.TableDefault    Yes
  • VA.ReloadOnStart.Method    All | Selective

Przy powyższych ustawieniach biblioteki, do pamięci automatycznie będą ładowane tabele spełniające następujące warunki:

• Tabela została zaimportowana do biblioteki, która ma powyższe opcje zdefiniowane.
• Użytkownik, który startuje serwer, ma dostęp w metadanych do tabeli, folderu i biblioteki. W szczególności tabela nie została zarejestrowana w folderze My Folder w metadanych lub użytkownik startujący serwer jest właścicielem tego folderu.
• Użytkownik ma dostęp w systemie operacyjnym do tabeli.
• Tabela była w pamięci przed zatrzymaniem serwera LASR.

Domyślnie tak skonfigurowana jest biblioteka Visual Analytics Public LASR.

Uprawnienia w systemie operacyjnym potrzebne do uruchomienia serwera LASR:

• Użytkownik musi być zautentykowany przez maszynę, na której działa serwer LASR. W przypadku wersji rozproszonej (distributed) użytkownik powinien posiadać dostęp passwordless SSH na wszystkich węzłach.
• Zapis w katalogu z plikami signature files. Katalog jest zdefiniowany w zaawansowanych opcjach serwera LASR, na zakładce Additional Options - Signature files location on server.
• Zapis w katalogu, w którym umieszczane są logi z ostatnio wykonywanej akcji. Katalog jest zdefiniowany dla aplikacji Visual Analytics w Configuration Manager/ SAS Application Infrastructure na zakładce Extended Attributes w atrybucie va.lastActionLogPath; katalog znajduje się na maszynie, na której jest skonfigurowany mid-tier.
• Zapis w katalogu, gdzie zapisywane są logi (o ile są włączone). Katalog zdefiniowany jest w zaawansowanych opcjach serwera LASR, na zakładce Logging Options - Path to log files.
• Zapis w katalogu, w którym umieszczany jest PID procesu i logi z wykonania operacji reload-on-start. Katalog jest zdefiniowany dla aplikacji Visual Analytics w SAS Management Console, w Configuration Manager/ SAS Application Infrastructure na zakładce Extended Attributes w atrubucie va.monitoringPath (domyślnie jest to katalog /Lev1/Applications/SASVisualAnalytics/VisualAnalyticsAdministrator/Monitoring). Atrybut va.MonitoringPath może być ustawiony również dla serwera LASR. W takim przypadku przykrywa on definicję globalną.

Uprawnienia w metadanych:

• ReadMetadata na serwerze LASR

Do zatrzymania serwera dodatkowo w metadanych potrzebne jest uprawnienie Administer.

Nie. Zarówno uruchomienie i zatrzymanie, jak i załadowanie czy usunięcie tabeli z pamięci z poziomu interfejsu SAS Visual Analytics, wymagają startu workspace serwera. SAS Visual Analytics nie pozwala na wystartowanie workspace serwera na koncie grupowym. Dlatego zamiast konta grupowego można skorzystać z autentykacji tokenowej (Nota 52121).

Serwer LASR można uruchomić na różne sposoby:

1. Ręcznie z interfejsu SAS Visual Analytics Administrator
2. Podpinając bibliotekę mechanizmem SASIOLA (uruchomiony w ten sposób serwer LASR będzie działał w wersji jedno-maszynowej)
3. Procedurą LASR (tylko wersja rozproszona)
4. Serwer LASR w niektórych przypadkach może być startowany automatycznie (Punkt 10)

Niezależnie od użytej metody użytkownicy muszą mieć odpowiednie uprawnienia, żeby wystartować serwer LASR (Punkt 4).

Ręcznie z interfejsu SAS Visual Analytics Administrator

Dostęp do interfejsu administratora mają użytkownicy, którzy należą do roli Visual Analytics: Administration. Do wystartowania serwera uruchamiana jest sesja workspace serwera, z której serwer jest startowany. W przypadku serwera non-distributed wykorzystywana jest biblioteka podpięta mechanizmem sasiola oraz procedura VASMP. Sesja workspace serwera pozostaje cały czas uruchomiona. W przypadku serwera rozproszonego jest to kod proc LASR. Po uruchomieniu serwera, sesja workspace serwera jest zamykana.

Podpinając bibliotekę mechanizmem SASIOLA (uruchomiony w ten sposób serwer LASR będzie działał w wersji jedno-maszynowej)

libname lasr sasiola startserver=(path="/tmp")
host="sasserver01.race.sas.com" port=10019 tag='test'
signer="http://sasserver05.race.sas.com:7980/SASLASRAuthorization";

Nazwa serwera (host=) i numer portu muszą zgadzać się z definicją serwera w metadanych. Opcja PATH określa katalog, w którym będą zapisywane pliki signature files (Punkt 12). Powyższa instrukcja wystartuje serwer LASR, który będzie działał dopóki sesja SAS, w której biblioteka była przypisana, działa lub do momentu usunięcia biblioteki. Przy batchowym uruchamianiu serwera LASR instrukcję można połączyć z instrukcją SERVERWAIT procedury VASMP. Instrukcja spowoduje zawieszenie wykonania procedury do czasu otrzymania przez nią żądania przerwania lub zatrzymania serwera LASR:

proc vasmp; serverwait port=10019; quit;

Zatrzymanie serwera następuje przy zamknięciu sesji, która go uruchomiła. Zatrzymanie za pomocą kodu z tej samej sesji:

libname server1 clear;

Zatrzymanie serwera z innej sesji:

proc vasmp; serverterm host="sasserver01.race.sas.com" port=10019; run; quit;

Procedurą LASR (tylko wersja rozproszona)

option set=GRIDHOST="sasserver01.race.sas.com"; option set=GRIDINSTALLLOC="/opt/sas/TKGrid" ; proc lasr create port=10019 path="/tmp" logging(path="/tmp" maxfilesize=5 keeplog); performance nodes=all; run;

Zatrzymywanie serwera: option set=GRIDHOST="sasserver01.race.sas.com"; option set=GRIDINSTALLLOC="/opt/sas/TKGrid" ; proc lasr stop port=10019; run;

W powyższym przypadku serwer zaczeka, aż wszystkie żądania zostaną przetworzone. Użycie wyrażenia stop (immediate) zatrzymuje serwer natychmiast.

Workspace serwer jest wykorzystywany w interfejsie SAS Visual Analytics do rejestracji tabel, ładowania/importowania danych, startowania i zatrzymywania serwera LASR oraz przy przygotowaniu danych.

Użytkownicy, którzy wykonują wszystkie lub część powyższych zadań, muszą mieć uprawnienia do uruchamiania tego serwera.

Przy próbie wystartowania serwera LASR za pomocą biblioteki z mechanizmem SASIOLA, pojawia się błąd:

libname lasr sasiola startserver=(path="/tmp" keeplog=yes)
host="sasserver01.race.sas.com" port=10019 tag='test'
signer="http://sasserver05.race.sas.com:7980/SASLASRAuthorization";

ERROR: You cannot combine the STARTSERVER or SERVEROPTS= syntax with the specification of a host other than the local machine. ERROR: Invalid parameter ERROR: Error in the LIBNAME statement.

Jedną z przyczyn może być skonfigurowanie 2 kontekstów serwera na 2 serwerach i uruchamianie kodu serwerze działającym na innej maszynie, niż skonfigurowane było VA i nie dodanej do ‘Job Execution Service’. Inną możliwość to różne nazwy serwerów w definicji połączenia serwera LASR w metadanych, co opisuje dokładnie nota 56189.

Tak. W tym celu należy:

• Zalogować się do części administracyjnej SAS Visual Analytics (Zarządzanie środowiskiem).
• Wybrać Plik --> Preferencje, następnie Zarządzanie środowiskiem.
• Zaznaczyć Zarejestruj działania jako instrukcje SAS-a i podać istniejącą ścieżkę.
• Od tej pory każde uruchomienie lub zatrzymanie serwera LASR z interfejsu stworzy nowy plik we wskazanym katalogu, zawierający kod startujący lub zatrzymujący dany serwer.

Otrzymany kod może być wykorzystany do wsadowego uruchamiania serwera LASR, np. z wykorzystaniem batch serwera.

Serwer LASR może być startowany automatycznie w momencie pojawienia się żądania ładowania lub importu danych. Mechanizm ten jest włączany poprzez ustawienie we właściwościach biblioteki rozszerzonego atrybutu va.AutoLoad.AutoStart na Yes dla co najmniej jednej biblioteki powiązanej z tym serwerem. Serwer jest automatycznie startowany, gdy:

• Serwer nie działa
• Pojawia się żądanie załadowania lub importu danych do biblioteki LASR, która ma atrybut va.AutoLoad.AutoStart ustawiony na Yes
• Użytkownik ma odpowiednie uprawnienia (Punkt 4)

Żądania otwarcia zbioru, odczytu danych czy uruchomienia zapytania nie powodują uruchomienia serwera.

W standardowej konfiguracji tak skonfigurowana jest biblioteka Visual Analytics Public LASR.

Serwer LASR działa na koncie użytkownika, w imieniu którego uruchomiona zostąła sesja SAS startująca serwer. W przypadku autostartu, serwer działa na koncie użytkownika, który pierwszy będzie chciał załadować dane (i tym samym spowoduje automatyczny start serwera).

SAS LASR Analytic Server wykorzystuje dwa rodzaje plików nazywanych signature files – dla serwera i dla tabeli. Zostały wprowadzone jako jeden z mechanizmów kontroli dostępu do serwera LASR i tabel załadowanych do pamięci. W momencie startu serwera LASR w katalogu wskazanym w definicji serwera w metadanych tworzony jest podkatalog i w nim umieszczany jest plik signature file dla serwera. W tym samym miejscu, w momencie ładowania tabel na dany serwer, są również tworzone pliki signature files dla tabel. Podkatalog jest usuwany przy zatrzymaniu serwera. Pliki związane z tabelami są usuwane przy usuwaniu tabeli z pamięci.

Katalog dla plików signature files podaje się w metadanych w definicji serwera LASR (w zaawansowanych właściwościach, na zakładce Additional Options, w polu Signature files location on server field). Jeżeli serwer startowany jest z kodu, lokalizację plików można podać w opcji PATH procedury LASR. Podana ścieżka musi być dostępna na maszynie zdefiniowanej w opcji GRIDHOST (master node).

Dostęp do tego katalogu powinni mieć tylko użytkownicy, którzy będą tworzyć pliki. Do analizy danych, które już zostały załadowane do pamięci, dostęp do katalogu nie jest konieczny.

Znacznik serwera (tag) jest to ciąg znaków związanych z biblioteką LASR, który w połączeniu z nazwą tabeli załadowanej do pamięci, pozwala jednoznacznie zidentyfikować tabelę w ramach serwera LASR i powiązać ją z odpowiadającym jej obiektem w metadanych.

Znaczniki definiuje się w metadanych w opcji biblioteki Server tag. Znaczniki serwera dla bibliotek muszą być zdefiniowane w następujący sposób:

• Jeżeli dane dla biblioteki są ładowane z co-located HDFS, znacznik musi być zdefiniowany jako ścieżka na HDFSie, rozdzielona kropkami.
• Jeżeli dane dla biblioteki ładowane są za pomocą mechanizmu SAS Embedded Process, wtedy znacznik musi być poprawną nazwą biblioteki (co najwyżej 8 znaków, bez znaków specjalnych, pierwszy znak to litera lub znak podkreślenia)
• Jeżeli dane dla biblioteki są ładowane z legacy co-located data provider, wtedy znacznik musi być taki sam, jak nazwa źródłowej biblioteki.
• W innych przypadkach znacznik może być dowolnym, unikalnym ciągiem znaków.
• Jeżeli znacznik nie został zdefiniowany dla biblioteki, domyślnie jest przyjmowany znacznik WORK.

W ramach danego serwera LASR kombinacja znacznika i tabeli musi być unikalna.

Do załadowania/importu danych użytkownik powinien:

• Być zautentykowany na serwerze, na którym działa LASR
• W przypadku wersji rozproszonej użytkownik musi mieć skonfigurowane passwordless ssh na wszystkich węzłach
• Mieć uprawnienie do zapisu w katalogu, w którym jest tworzony signature file (Punkt 12), do katalogu, w którym jest zapisywany log z ostatnio wykonanej akcji (atrybut va.lastActionLogPath – Punkt 30), katalogu, w którym jest zapisywany pid procesu (atrybut va.monitoringPath – Punkt 4)

Ładowanie/Import tabeli wymaga następujących uprawnień w metadanych:

• ReadMetadata do serwera
• ReadMetadata, Read, WriteMetadata i Administer do biblioteki, do której dane są ładowane
• ReadMetadata, Read, WriteMemberMetadata, Write do folderu, w którym tabela będzie zarejestrowana
• Należeć do roli, która daje uprawnienie na wykonanie importu i ładowania danych.

Ładowanie/import danych za pomocą interfejsu graficznego VA powołuje sesję workspace serwera. Dlatego użytkownik, który wykonuje tę operację, musi mieć uprawnienia do jego uruchomienia.

Metody ładowania danych do serwera LASR:

• Z interfejsu VA:
  • Import danych w Eksploratorze lub w Projektancie raportów
  • Przygotowanie danych
  • Administrator

Metoda ta powołuje sesję workspace serwera, który dane załaduje do pamięci i zarejestruje w metadanych.

• Gotowe zadania w aplikacjach:
  • SAS Enterprise Guide
  • SAS Add-In for MS Office
  • SAS Data Integration Studio

Zadania te są uruchamiane w ramach sesji workspace serwera, który ładuje dane do pamięci.

• Mechanizm automatycznego ładowania danych (Autoload – Punkt 25)

• Automatyczne ładowanie danych przy starcie serwera (Punkt 3)

• Z kodu za pomocą biblioteki podpiętej mechanizmem SASIOLA, procedurą LASR (tylko wersja rozproszona) lub procedury HPDS2.

Niezależnie od wybranej metody użytkownik musi mieć uprawnienia do wykonania tej akcji (Punkt 14).

Poniższe przykłady pokazują, jak załadować dane bezpośrednio do serwera LASR. W przypadku wersji rozproszonej z co-located Hadoopem, ze względów wydajnościowych wskazane jest załadowanie danych najpierw do Hadoopa, następnie równolegle z Hadoopa do serwera LASR (Punkt 18 i Punkt 19).

Biblioteka podpięta mechanizmem SASIOLA:

LIBNAME VALIBLA SASIOLA TAG=HPS PORT=10011 HOST="sasbi"
SIGNER="http://sasbi:7090/SASLASRAuthorization" ;

/* Usunięcie tabeli z serwera LASR, o ile istnieje.
Poniższy kod usunie jedynie dane z pamięci,
Rejestracja w metadanych pozostanie */
%macro deletedsifexists(lib,name);
%if %sysfunc(exist(&lib..&name.)) %then %do;
proc datasets library=&lib. nolist;
delete &name.;
quit;
%end;
%mend deletedsifexists;
%deletedsifexists(valibla,test);

/* Załadowanie do pamięci */
data VALIBLA.test;
set sashelp.class;
run;
/* Zarejestrowanie w metadanych w przypadku nowej tabeli;
Rejestracja tabeli istniejącej w metadanych nie
Zostanie zmieniona */
Proc Metalib;
omr(library="Visual Analytics LASR");
folder="/User Folders/sasdemo/My Folder";
update_rule=(noupdate);
select ("test");
Run; Quit;

Rejestracja w metadanych jest niezbędna do tego, żeby tabela była widoczna w SAS Visual Analytics. Bez rejestracji w metadanych dane będą tylko załadowane do pamięci, ale niewidoczne w interfejsie. Zarejestrowanie tabeli w metadanych w bibliotece LASR wymaga, żeby tabela była załadowana do serwera LASR z takim samym znacznikiem (tag), jaki jest podany w definicji biblioteki w metadanych. W powyższy sposób mogą być załadowane dowolne dane, do których jest dostęp w danej sesji SASa. W przypadku wersji rozproszonej dane będą ładowane poprzez węzeł master, który rozdzieli dane na poszczególne węzły. Uwaga! Procedura METALIB nie zwraca błędu, jeżeli tabela nie zostanie zarejestrowana. Dlatego należy sprawdzić albo w wynikowym raporcie albo w logu, czy rejestracja się powiodła. W przypadku, gdy tabela nie została zarejestrowana w logu pojawi się następujący komunikat:

NOTE: Metadata for 0 tables matched the data sources.
NOTE: 1 tables listed in the SELECT or EXCLUDE statement were not found in either the metadata or the data source.

Procedura LASR (tylko wersja rozproszona)
Procedura LASR może być wykorzystywana do ładowania dowolnych danych, które są dostępne w sesji SAS, w której będzie uruchamiana. W takim przypadku dane będą ładowane poprzez serwer master. Może być również wykorzystana do równoległego ładowania danych z co-located Hadoop (Punkt 19), bezpośrednio do wszystkich węzłów.

libname hps (sashelp);
OPTION SET=GRIDINSTALLLOC="/opt/sas/TKGrid";
OPTION SET=GRIDHOST="sasserver01";
LIBNAME VALIBLA SASIOLA TAG=HPS PORT=10011 HOST="sasbi"
SIGNER="http://sasbi:7090/SASLASRAuthorization" ;
%deletedsifexists(valibla,prdsale);
proc lasr add data=hps.prdsale port=10010;
run;
Proc Metalib;
omr(library="Visual Analytics LASR");
folder="/User Folders/lasradm/My Folder";
select ("prdsale");
update_rule=(noupdate);
Run; Quit;

W przypadku użycia proc LASR trzeba pamiętać o tym, że nie ma ona możliwości zdefiniowania znacznika dla ładowanej tabeli. Dlatego ładując dane przypisuje im znacznik będący nazwą biblioteki, z której dane pochodzą. W celu wykorzystania załadowanych danych w VA trzeba zagwarantować, że nazwa biblioteki źródłowej jest taka sama, jak znacznik biblioteki LASR w metadanych, w której tabela będzie zarejestrowana. Jedyny wyjątek, to dane pochodzące z co-located Hadoop. Wtedy znacznikiem będzie ścieżka na HDFSie.

Procedura HPDS2
W przypadku wersji nierozproszonej kod procedury HPDS2 jest wykonywany w ramach sesji workspace serwera, jedno- lub wielowątkowo. W przypadku wersji rozproszonej, jest wykonywany równolegle na wszystkich węzłach. Jeżeli przetwarzane dane są lokalne dla sesji SASa, z której kod został uruchomiony, wtedy są one dystrybuowane na węzły w ramach działania procedury HPDS2. Jeżeli dane są już dostępne na węzłach (w co-located Hadoop), wtedy są one przetwarzane lokalnie na węźle, na którym się znajdują.

OPTION SET=GRIDINSTALLLOC="/opt/sas/TKGrid";
OPTION SET=GRIDHOST="sasserver01";
LIBNAME valibla SASIOLA TAG=HPS PORT=10010 SIGNER="http://sasserver05.race.sas.com:7980/SASLASRAuthorization" HOST="sasserver01.race.sas.com" ;
%deletedsifexists(valibla,bmw_cars);
proc hpds2 in=dane.cars out=valibla.bmw_cars;
data ds2gtf.out;
method run();
set ds2gtf.in;
if make='BMW';
end;
enddata;
run;
proc metalib;
omr (library="Visual Analytics LASR");
update_rule= (noupdate);
report(type=summary);
folder="/GATE/CaseStudy Playpen/Analytical LASR Data";
select=("bmw_cars");
run;

Przyczyną takiego komunikatu prawdopodobnie jest jedna z poniższych możliwości:

• Do serwera LASR została już załadowana tabela o takiej samej kombinacji znacznika serwera i nazwy tabeli (Punkt 13). W takim przypadku należy albo usunąć starą tabelę, albo zmienić nazwę tabeli, która ma być załadowana.
• Istnieją w metadanych co najmniej 2 biblioteki LASR, które mają zdefiniowany taki sam znacznik; w takim przypadku należy zmodyfikować definicję jednej z nich.
• Istnieją w metadanych co najmniej 2 biblioteki LASR, które nie mają zdefiniowanego znacznika. W takim przypadku dla obu stosowany jest domyślny znacznik WORK, który powoduje, że nie da się odróżnić, z której biblioteki została załadowana tabela. W tym przypadku należy zdefiniować znacznik dla co najmniej jednej z tych bibliotek.

W SAS Enterprise Guide została załadowana tabela do serwera LASR, kod wykonał się bezbłędnie, tabela została wyświetlona w EG, a jednak w interfejsie SAS Visual Analytics nie jest ona widoczna.

Prawdopodobnie zaszła jedna z następujących możliwości:

• Tabela nie została zarejestrowana w metadanych po załadowaniu.
• Tabela została zarejestrowana w metadanych w katalogu, do którego użytkownik zalogowany w SAS Visual Analytics nie ma dostępu.
• Tabela została załadowana z innym znacznikiem, niż zdefiniowany dla biblioteki i dlatego nie została zarejestrowana w metadanych.

Hadoop zainstalowany na tych samych węzłach, na których działa serwer LASR (co-located Hadoop), jest wykorzystywany do szybszego ładowania danych do pamięci oraz do przechowywania kopii danych załadowanych do pamięci.

Dane do co-located Hadoopa można załadować za pomocą proc HPDS2 lub biblioteki podpiętej mechanizmem SASHDAT. W obu przypadkach dane są ładowane poprzez master node.

Procedura HPDS2

OPTION SET=GRIDINSTALLLOC="/opt/sas/TKGrid";
OPTION SET=GRIDHOST="sasserver01";

libname hdpuser sashdat path="/hps";

proc hpds2 in=sashelp.cars out=hdpuser.cars_area(replace=yes) ;
data ds2gtf.out;
dcl double area;
method run();
set ds2gtf.in;
area = wheelbase * length;
end;
enddata;
run;

Biblioteka podpięta mechanizmem SASHDAT

OPTION SET=GRIDINSTALLLOC="/opt/sas/TKGrid";
OPTION SET=GRIDHOST="sasserver01";

libname hdpuser sashdat path="/hps";

data hdpuser.carsFirstLast(replace=yes
logupdate
partition=(make) hash
orderby=(MSRP Model));
set sashelp.cars;
by make;
if first.make then output;
if last.make then output;
run;

Z co-located Hadoop do pamięci dane można załadować albo za pomocą procedury LASR lub procedury HPDS2. W obu przypadkach dane ładowane są równolegle na wszystkich węzłach.

Procedura LASR

OPTION SET=GRIDINSTALLLOC="/opt/sas/TKGrid";
OPTION SET=GRIDHOST="sasserver01";

libname hdpuser sashdat path="/hps";

proc lasr add data=hdpuser.cars222 port=10010;
run;

proc metalib;
omr (library="Visual Analytics LASR");
update_rule= (noupdate);
report(type=summary);
folder="/GATE/CaseStudy Playpen/Analytical LASR Data";
select=("cars222");
run;

Procedura HPDS2

OPTION SET=GRIDINSTALLLOC="/opt/sas/TKGrid";
OPTION SET=GRIDHOST="sasserver01";

libname hdpuser sashdat path="/hps";

libname lasr1 sasiola port=10010 tag="hps";

proc hpds2 in=hdpuser.cars out=lasr1.bmw_cars;
data ds2gtf.out;
method run();
set ds2gtf.in;
if make='BMW';
end;
enddata;
run;

proc metalib;
omr (library="Visual Analytics LASR");
update_rule= (noupdate);
report(type=summary);
folder="/GATE/CaseStudy Playpen/Analytical LASR Data";
select=("bmw_cars");
run;

Ładowanie tabeli z HDFS do serwera LASR za pomocą interfejsu ‘Zarządzanie środowiskiem’ kończy się poprawnie, a jednak tabeli nie widać na liście tabel serwera LASR, nie może być wybrana w Eksploratorze danych ani w Projektancie raportów, nie ma jej również w SAS Management Console. Przy próbie ponownego ładowania pojawia się błąd: ‘Table is already loaded in memory’.

Najbardziej prawdopodobną przyczyną problemu jest niepoprawny znacznik podany przy ładowaniu tabeli. W przypadku ładowania danych z HDFS musi to być ścieżka do zbioru w HDFS, rozdzielana kropkami.

Istnieją 2 sposoby na dodanie danych do tabeli załadowanej do serwera LASR:

• pełna wymiana danych
• dodanie nowych rekordów

Dodanie nowych rekordów

LIBNAME VALIBLA SASIOLA TAG=VAPUBLIC PORT=10031 HOST="sasva"
SIGNER="http://sasva:80/SASLASRAuthorization" ;

%deletedsifexists(valibla,test);

libname dane 'D:\opt\sasinside\SASHome\SASEnterpriseGuide\7.1\Sample\Data';

data VALIBLA.baseball(append);
set dane.baseball;
run;

Uwaga!
Dane są dodawane tylko do pamięci. Żadne dane na dysku nie są modyfikowane. Dlatego po dodaniu danych warto również dodać dane do oryginalnego źródła danych.

Uwaga!
Procedura APPEND nie jest wspierana jako metoda doładowania danych do serwera LASR. Przy próbie jej użycia pojawia się komunikat:

ERROR: Update access is not supported for file
VALIBLA.TEST.DATA.

Tak, podczas dodawania danych tabela cały czas jest dostępna dla użytkowników. Domyślnie nowe dane są widoczne po zakończeniu dodawania. Zachowanie można zmienić dodając opcję zbioru autocommit.

LIBNAME VALIBLA SASIOLA TAG=VAPUBLIC PORT=10031 HOST="sasva"
SIGNER="http://sasva:80/SASLASRAuthorization" ;

%deletedsifexists(valibla,test);

libname dane 'D:\opt\sasinside\SASHome\SASEnterpriseGuide\7.1\Sample\Data';

data VALIBLA.baseball(append autocommit=100R);
set dane.baseball;
run;

W powyższym kodzie nowe dane będą udostępniane co 100 wczytanych rekordów.

Wersja rozproszona:

OPTION SET=GRIDHOST="sasserver01";
OPTION SET=GRIDINSTALLLOC="/opt/sas/TKGrid";

proc lasr details port=10011;
performance host="sasserver01.race.sas.com";
run;

Wersja nierozproszona:

proc vasmp;
tableinfo / port=10010;
run;
quit;

Obie wersje:

LIBNAME VALIBLA SASIOLA TAG="GATE.Marketing" PORT=10011 HOST="sasserver01.race.sas.com"
SIGNER="http://sasserver05.race.sas.com:7980/SASLASRAuthorization" ;
proc datasets lib=valibla;
run;
quit;

Ostatni kod pokaże tylko tabele, które zostały załadowane i mają taki sam znacznik, jak podany w definicji biblioteki.

Do usunięcia tabeli za pomocą kodu można wykorzystać proc IMSTAT oraz bibliotekę podpiętą mechanizmem SASIOLA. Ważne jest, żeby w definicji biblioteki podać znacznik, z którym została załadowana tabela:

OPTION SET=GRIDHOST="sasserver01";
OPTION SET=GRIDINSTALLLOC="/opt/sas/TKGrid";

libname example sasiola host="sasserver01.race.sas.com" port=10010 tag='hps';

proc imstat data=example.prdsale;
droptable example.prdsale;
run;

Autoload to mechanizm automatycznej synchronizacji danych w pamięci z określoną lokalizacją na dysku. Specjalny proces co określony okres czasu wykonuje następujące działania:

• Ładuje do pamięci nowe pliki
• Przeładowuje zbiór w przypadku pojawienia się nowszej wersji niż ta, która została załadowana do pamięci
• Dodaje nowe dane do już załadowanych do pamięci tabel
• Usuwa wskazane tabele

Wskazana lokalizacja ma określoną strukturę katalogów:

• Katalog główny – tu umieszczane są nowe pliki w postaci arkuszy Excel (xls lub xlsx), plików tekstowych z separatorem lub zbiorów SAS. Pliki, które nie zostały wcześniej załadowane, są ładowane do pamięci; jeżeli któryś z plików był zmieniony od ostatniego ładowania, wówczas tabela jest przeładowywana w pamięci.
• Append – zawiera dane, które mają być dodane do istniejących tabel w pamięci
• Unload – zawiera tabele, które mają być usunięte z serwera LASR
• Formats
• Logs

Mechanizm nie jest domyślnie skonfigurowany i uruchomiony, choć jest stworzona domyślna struktura katalogów w /Levx/AppData/SASVisualAnalytics/VisualAnalyticsAdministrator/AutoLoad oraz przygotowane są skrypty w /Levx/Applications/SASVisualAnalytics/VisualAnalyticsAdministrator.

Kroki niezbędne do skonfigurowania mechanizmu są dokładnie opisane w SAS® Visual Analytics 7.3 Administration Guide w rozdziale Loading Data/Autoload.

Dla SAS Visual Analytics można włączyć mechanizm Autoload, czyli automatyczne ładowanie danych ze wskazanych katalogów na dysku (Punkt 25). Proces ten domyślnie będzie uruchamiany co 15 minut. Każde ładowanie jest odnotowywane w zbiorze (domyślnie /Levx/Applications/SASVisualAnalytics/VisualAnalyticsAdministrator/Logs/autoload.sas7bdat), przez co rozmiar zbioru ciągle wzrasta. To z kolei powoduje, że czas dodania kolejnego rekordu do zbioru jest coraz dłuższy, dlatego po pewnym czasie ładowanie może przestać się mieścić w przewidzianym okienku czasowym. W przypadku korzystania z mechanizmu Autoload należy pamiętać o usuwaniu tego zbioru co jakiś czas.

W celu zaimportowania danych z zewnętrznej bazy danych użytkownik musi należeć do roli, która daje dostęp do tej funkcjonalności. Warunkiem powodzenia tej operacji jest licencja na odpowiedni moduł SAS/ACCESS oraz zainstalowanie i skonfigurowanie tego modułu. Jeżeli po wskazaniu bazy danych w interfejsie nie widać tabel, najczęściej jest to spowodowane brakiem licencji, nieskonfigurowaniem lub niepoprawną konfiguracją modułu SAS/ACCESS dla danej bazy.

Serwer LASR przechowuje wszystkie dane w pamięci, więc powinien mieć dostęp do jak największej ilości pamięci. Są jednak przypadki, gdy wielkość pamięci używanej przez serwer LASR trzeba ograniczyć. W zależności od wersji (rozproszona czy nierozproszona) oraz od systemu operacyjnego dostępnych jest kilka parametrów:

Dla wersji rozproszonej serwera LASR (Linux):

• Plik resource.settings w katalogu instalacyjnym TKGrid. Jest to zalecany mechanizm kontroli pamięci dla rozproszonego serwera LASR:
  • TKMPI_MEMSIZE=xxx – maksymalna wielkość rzeczywistej pamięci wykorzystywanej przez węzeł. Nie obejmuje plików SASHDAT ładowanych z HDFS.
  • TKMPI_ULIMIT=”-v xxx” – wielkość wirtualnej pamięci wykorzystywanej przez węzeł. Obejmuje pliki SASHDAT ładowane z HDFS.

Zmiany wprowadzone w tym pliku muszą być rozpropagowane na wszystkie węzły, po czym serwer LASR musi zostać zrestartowany.

• TABLEMEM
  Opcja podawana w procedurze LASR przy starcie serwera LASR lub definiowana w metadanych w zaawansowanych opcjach serwera LASR na zakładce ‘Memory Limits’ – ‘Data loading (*)’ Definiuje wielkość zużycia pamięci, powyżej której nowe tabele nie będą ładowane do pamięci. Oznacza łączną wielkość pamięci na wszystkich węzłach. Po zmianie ustawień w metadanych wymagany jest restart SAS Web Application Serwera.
  
  Może być modyfikowana dla działającego serwera LASR za pomocą procedury IMSTAT lub VASMP.

Dla wersji nierozproszonej:

• MEMSIZE
  Opcja systemu SAS. Podstawowy sposób kontroli pamięci dla nierozproszonej wersji serwera LASR. Określa maksymalną wielkość pamięci wirtualnej dostępnej dla serwera LASR.

Na obu wersjach można również wykorzystać parametr VA.MaxTotalMemoryForTables, ustawiany w rozszerzonych atrybutach w definicji serwera LASR w metadanych. Definiuje maksymalną wielkość pamięci na serwerze LASR, zarezerwowaną dla tabel.

Przy imporcie lokalnych plików limit na importowane pliki jest narzucany przez przeglądarkę (na ogół 4GB). Można jednak importować pliki spakowane (*.zip), co pozwala zwiększyć ten limit.

Dla SAS Visual Analytics można zdefiniować dodatkowe limity, które nie będą pozwalały na import dużych danych:

• va.SelfService.ImportRowsHardCap – maksymalna liczba wierszy przy imporcie tabeli. Jeżeli liczba wierszy jest większa, dane nie są importowane.
• va.SelfService.ImportRowsSoftCap – liczba wierszy w importowanej tabeli, która spowoduje wyświetlenie ostrzeżenia o prawdopodobnie długim czasie ładowania.

Zdefiniowanie powyższych limitów powoduje, że przed importem wysyłane jest do bazy zapytanie o liczbę wierszy, co może pogorszyć wydajność.

• va.SelfServe.MaxUploadSizeInMegabytes – maksymalny rozmiar pliku, jaki użytkownik może zaimportować.

Powyższe opcje ustawia się w SAS Management Console wybierając Application Management --> SAS Application Infrastructure --> Visual Analytics 7.3 i wyświetlając właściwości. Opcje znajdują się na zakładce Advanced.

Jest kilka miejsc, w których mogą być zapisywane logi z działania SAS Visual Analytics oraz serwera LASR.

• Logi aplikacji znajdują się na serwerze mid-tier, domyślnie w katalogu /Levx/Web/Logs/SASServer12_1 (jeżeli aplikacje są rozłożone na kilku serwerach aplikacji) lub /Levx/Web/Logs/SASServer1_1 (jeżeli zdefiniowany jest tylko 1 serwer aplikacji).
• Podgląd logu z ostatnio wykonanej akcji na serwerze LASR jest dostępny w interfejsie. Fizycznie te logi są przechowywane w ścieżce wskazanej w atrybucie aplikacji va.lastActionLogPath. Atrybut można zmienić w SAS Management Console w Application Management --> SAS Application Infrastructure, wybierając właściwości Visual Analytics 7.3 i zakładkę Advanced. Domyślnie jest to ścieżka /Lev1/Applications/SASVisualAnalytics/VisualAnalyticsAdministrator/Monitoring/Logs
  
  Zmiana tej ścieżki wymaga restartu serwera aplikacji.
• Logowanie dla serwera LASR domyślnie jest wyłączone. Można je włączyć w SAS Management Console, w zaawansowanych opcjach serwera LASR, na zakładce ‘Logging Options’. Dla wersji nierozproszonej logi zawsze będą zapisywane w katalogu, w którym znajdują się signature files (Punkt 12). Dla rozproszonej ścieżkę podaje się w zaawansowanych właściwościach serwera. Ścieżka musi istnieć na serwerze, na którym działa master node. Domyślnie jest to Levx/Applications/SASVisualAnalytics/LASR/Logs/
  
  Zmiana opcji wymaga restartu serwera LASR.

• Dokumentacja SAS Visual
• Analytics
• Niektóre pozycje wymagają podania hasła, które mogą dostać klienci, posiadający licencję na SAS Visual Analytics. W tym celu prosimy o kontakt ze wsparciem technicznym.
• Opis produktu SAS Visual Analytics
  
• Dokumenty techniczne SAS Visual Analytics
• Dokumentacja serwera LASR