Importul datelor în SAP HANA

Adela Roa Bacalu
Senior ABAP Consultant

Acest articol acoperă aspectele tehnice ale importului de date în SAP HANA, cu care ne-am ocupat în cadrul migrării unei aplicații dezvoltate cu tehnologii Microsoft la o combinație de tehnologii SAP și non-SAP. Pornim de la o aplicație de statistică și raportare care este deja în producție și în care se înregistrează sute de înregistrări zilnic, cu o bază de date în MS SQL Server 2008, iar front end .NET. Ne dorim să dezvoltăm o aplicație nouă cu bază de date ultra-performantă SAP HANA, folosind platforma și conceptele XS Advanced, iar pentru interfețele utilizator tehnologia Angular2. Printre motivele pentru care a fost necesară această migrare, menționăm, în primul rând, performanța, iar în al doilea rând, nevoia de extindere a aplicației cu noi funcționalități care ar fi fost foarte dificilă în contextul aplicației vechi.

Ne propunem, de această dată, să prezentăm modurile prin care putem încărca date în SAP HANA dintr-o sursă externă, baza de date originală fiind MS SQL Server. Vom începe cu opțiunea File Import, care este soluția quick and easy atunci când nu avem foarte multe date de adus în sistem, fiind disponibilă chiar în IDE; mai apoi, vom analiza metoda Bulk Load, utilă în cazul în care lucrăm cu fișiere mai mari, de dimensiuni de până la câțiva GB, urmând ca, în ultima parte a articolului, să ne concentrăm pe un tool destinat importului și replicării datelor în timp real, SAP SLT.

Pentru a afla mai multe detalii despre platforma SAP HANA și de ce o folosim, vă recomandăm articolul SAP HANA ca bază de date.

File Import

Poate cea mai banală dintre metode, aceasta presupune faptul că dispunem de date într-unul din formatele xls, xlsx sau csv. Este o metodă rapidă și ușoară, dar care nu ne lasă foarte mult loc de manevră în ceea ce privește formatul datelor și a personalizării procesului de încărcare. Se pretează tabelelor mici, deoarece manipularea conținutului fișierului sursă poate fi realizată foarte rapid. Vorbim de fișiere din categoria de dimensiune MB. Un mare avantaj al acestei soluții îl reprezintă faptul că nu avem nevoie de un tool extern, suplimentar, pentru a aduce date în sistem.

Tabela destinație pe care vrem să o populăm poate să fie deja prezentă în sistem sau poate fi creată automat la import. În cazul în care ea există, înregistrările noi se adaugă celor vechi, care rămân neschimbate. De asemenea, nu putem modifica în niciun fel tipurile de date existente.

Lucrăm direct din HANA Studio, alegem perspectiva Modeler și navigăm la calea următoare:

1. Quick View->Import->SAP HANA Content->Data From Local File;

2. Alegem sistemul destinație;

3. Specificăm fișierul sursă și diferitele opțiuni la încărcare, cum ar fi delimitatorul dintre câmpuri, opțiunea dacă fișierul conține sau nu ca primă înregistrare denumirea coloanelor și, nu în ultimul rând, tipul de encoding;

4. Definim maparea coloanelor dorite din fișierul sursă pe coloanele destinație, putând fi omise unele coloane din sursă - cu următoarele opțiuni pentru mapare automată:

   • One To One - secvențial, vor fi mapate toate coloanele în ordinea în care ele apar în fișier și în tabelă;

   • Map By Name - în cazul în care coloanele au același nume în tabela sursă și în tabela destinație;

Maparea se poate face și manual, cu drag and drop.

Figura 1: Importul datelor din fișier local

5.Avem posibilitatea să vizualizăm o selecție mică, atât din datele pre-existente în tabelă, cât și din datele care urmează să fie introduse, iar dacă totul arată în regulă, finalizăm operațiunea.

În protocol, observăm detalii despre execuția activității de import:

Elapsed Time: 3,419 Seconds
Loading Data from NPW.CurrencyExchangesrates_with_Isocodes.csv 100% completed
Batch from record 2 to 15555 inserted
Batch from record 15556 to 31109 inserted
Batch from record 31110 to 46663 inserted

Înregistrările au fost copiate în tabela destinație:

select count(*) from "NPW"."CurrencyExchangesrates_with_Isocodes"
46.661

Dimensiunea fișierului csv:

Bulk Load

Prin această metodă, avansăm către următorul nivel de complexitate după importul automat "quick & easy" al datelor. Facem uz de consola Windows și de instrucțiunea IMPORT, reușind să aducem în sistem conținutul unor fișiere mult mai mari (categoria de dimensiune GB) față de metoda File Import. Analog metodei anterioare, nu avem nevoie de niciun alt tool, folosim infrastructura SAP HANA pe care o avem deja la dispoziție.

Configurare

Începem prin a permite accesul din Hana Studio la fișiere aflate pe server; pentru aceasta navigăm la detaliile sistemului, în secțiunea Configuration.

Din motive de securitate, doar fișierele CSV localizate pe serverul bazei de date, la calea definită în parametrul de configurare csv_import_path_filter pot fi încărcate, folosind instrucțiunea IMPORT FROM SQL. Putem activa temporar această opțiune cu ajutorul parametrului de configurare enable_csv_import_path_filter. În secțiunea import_export a configurației indexserver, există doi parametri cu care putem jongla pentru a actualiza calea de unde se importă date sau pentru a dezactiva opțiunea cu totul.

Figura 2: Parametri de configurare a importului de date în Hana Studio

Dezactivare:

ALTER SYSTEM ALTER CONFIGURATION ('indexserver.ini', 'system') set ('import_export', 'enable_csv_import_path_filter') = 'false' with reconfigure

Activare și specificarea căii:

ALTER SYSTEM ALTER CONFIGURATION ('indexserver.ini', 'system') set ('import_export', 'csv_import_path_filter') = '/ A; / B'with reconfigure

După ce adăugăm o cale '/ A' la filtrul de cale, fiecare sub-cale a lui '/ A' este adaugată automat.

Execuție

După ce am configurat sistemul în așa fel încât să permită importul datelor, avem două opțiuni - să folosim direct fișierul .csv sau un intermediar, .ctl.

• IMPORT FROM CSV FILE '/hana/shared/BLOAD/data.csv' INTO "myTargetTable"

• IMPORT FROM CONTROL FILE '/hana/shared/BLOAD/data.ctl';

Conținutul fișierului cu extensia .ctl arată în felul următor:

IMPORT DATA INTO TABLE "myTargetTable"FROM '/hana/shared/BLOAD/data/data.csv'
RECORD DELIMITED BY 'n' -- separatorul dintre rânduri
FIELD DELIMITED BY ';' -- separatorul dintre coloane
BATCH 1000 -- dimensiunea unui pachet, în cazul în care avem foarte multe linii
ERROR LOG /log/error.log -- fișierul unde vor fi protocolate erorile, în cazul în care ele apar
FAIL ON INVALID DATA -- opțiune cu ajutorul căreia ne asigurăm că încărcarea datelor se oprește în momentul în care apare o eroare

Să vedem cum se comportă această metodă cu un test simplu.

truncate table "mySchema"."myTargetTable";
IMPORT FROM '/hana/shared/BLOAD/data.ctl' WITH THREADS 10 BATCH 1000;

Statement 'IMPORT FROM '/hana/shared/BLOAD/data.ctl' WITH THREADS 10'
successfully executed in **16,488 seconds** (server processing time: 16,486 seconds);

Înregistrările au fost copiate în tabela destinație:

Select count (*) from "mySchema"."myTargetTable";
7.288.660

Dimensiunea fișierului .csv:

Import planificat

În cazul în care avem acces în mod regulat la date noi, acestea pot fi copiate în sistem automat, folosind opțiunea Bulk Load și un job planificat la intervale regulate. Metoda aceasta se pretează scenariilor în care trebuie să replicăm date generate de alte aplicații și care nu se schimbă foarte des, de exemplu, datele generate la închiderea lunii financiare.

În continuare, vă prezentăm opțiunea de a planifica un import cu ajutorul XS Job Scheduler, un utilitar care va executa, în mod regulat și repetitiv acțiunile planificate. Avem nevoie de o procedură care să conțină instrucțiunea import și de un fișier XS Job Scheduler File, categorie pe care o regăsim, de asemenea, în SAP HANA Studio. Structura acestui fișier are formatul următor:

{
    "description": "Import data",
    "action": "mySchema:importJob.xsjs::importData",
    "schedules": [
       { "xscron": "* * * * * * 59"       
       }
    ]
}

• action - funcția care se va executa când rulează jobul

• schedules - secțiune cu detalii suplimentare legat de timeframe-ul în care rulează jobul

• xscron - parametru care definește frecvența cu care va rula jobul, specificat în sintaxa cron

Câteva exemple concrete:

*** * * * * */5 *** - O dată la 5 minute, oricând în minutul specificat *** * * * * */5 30** - O dată la 5 minute, la secunda 30 din minutul specificat

*** * * -1.mon7 0 0** - În ultima luni din lună, la ora 07:00 **2017 * * fri17 0 0** - În fiecare vineri din anul 2017, la ora 17:00 *** * 3:-2 * 12:14 0 0** - O dată pe oră în intervalul 12:00 - 14:00, în fiecare zi cuprinsă între cea de-a treia zi și antepenultima zi din lună

Detalii despre xsjob și alte configurări legate de acesta pot fi vizualizate în XS Admin Tool.

Figura 3: SAP HANA XS Administration Tool - componenta XS JOB Dashboard

Cu toate că putem programa execuția importului cu o frecvență maximă de o dată pe secundă, tot nu putem spune că avem acces la date în timp real, având în plus și o constrângere de dimensiune de care trebuie să ținem cont. În acest scop s-au creat alte instrumente dedicate, iar în cele ce urmează vom discuta despre SAP SLT. 

Replicarea datelor în timp real folosind SLT

SAP Landscape Transformation Replication Server (SLT) este o soluție SAP folosită pentru încărcarea inițială și sincronizarea ulterioară, în timp real a datelor atât din surse SAP cât și non-SAP în HANA, această soluție fiind integrată în HANA Studio. Tipurile de baze de date acceptate ca sursă sunt: SAP MaxDB, IBM DB2, MSSQL și Oracle. Se pretează foarte bine scenariului în care trebuie să replicăm date tranzacționale, care se schimbă foarte des sau continuu - comenzi, livrări, vânzări cu amănuntul, sisteme de tranzacții financiare etc.

Funcționează pe bază de trigger, astfel încât, după configurarea inițială, orice modificare a datelor în sistemul sursă, declanșează aceeași modificare în sistemul destinație. Pe partea de HANA, de menționat este faptul că avem nevoie de minim Support Package Stack 9 (HANA SPS09), pentru a putea replica date dintr-un sistem non-SAP. Este, de asemenea, necesară o platformă independentă SAP NetWeaver, pe care să ruleze joburile de replicare. Această soluție este de un real ajutor și în cazul migrărilor în mai mulți pași, care presupun, de obicei, o fază a proiectului în care aplicația veche și cea nouă trebuie să fie funcționale concomitent (side-by-side). SLT poate realiza replicarea datelor în timp real sau planificat.

SLT este compus din:

• Tabelele în care se protocolează înregistrările noi și cele care au suferit modifcări de la ultima replicare executată cu succes;

• Module de citire a datelor;

• Module de control care execută transformări asupra datelor din sursă ca să le pregătească pentru scriere;

• Module de scriere.

În cazul nostru concret, comunicarea cu sistemul sursă Microsoft se face printr-o conexiune directă la baza de date. Pentru situațiile în care baza de date originală este SAP, comunicarea se realizează prin RFC.

Figura 4: Transferul datelor folosind SAP SLT

Configurare

Folosind tranzacția DBACOCKPIT pe sistemul SAP pe care este instalat SLT, începem prin a ne crea conexiunile la sistemul sursă MSSQL și la sistemul destinație SAP HANA, specificând în ambele configurări, pe lângă datele de autentificare, și schema din baza de date cu care se lucrează. În cazul în care încă nu avem schema destinație, SLT o creează automat analog celei sursă. Altfel, se face o verificare a compatibilității tabelelor existente. La cea mai mică diferență, SLT creează o tabela nouă.

Figura 5: Conexiunile la diferitele baze de date, configurate în DBACOCKPIT

În HANA s-au creat automat obiecte noi. De menționat sunt rolurile:

• <SCHEMA>_DATA_PROV - gestionează achiziția de date, fiind necesar celor care configurează și monitorizează procesul.

• <SCHEMA>_POWER_USER - beneficiază de toate privilegiile SQL asupra conținutului de date în schema destinație.

• <SCHEMA>_USER_ADMIN - oferă drept de execuție pentru procedurile RS_GRANT_ACCESS și RS_REVOKE_ACCESS, necesar celor care administrează drepturile anumitor categorii de utilizatori, specificând obiecte concrete la care aceștia au acces sau nu.

• <SCHEMA>_SELECT - acordă dreptul de a vizualiza conținutul de date din întreaga schemă.

Și procedurile:

• RS_GRANT_ACCESS - acordă drepturi de acces la anumite obiecte specificate.

• RS_REVOKE_ACCESS - retractează/anulează aceste drepturi.

LTR (Landscape Transformation Replication Server Work Center)

În continuare, prezintă interes tranzacțiile LTRC (Landscape Transformation Replication Server Cockpit) și LTRS (Landscape Transformation Replication Server Settings), cu ajutorul cărora vom specifica individual, tabelele care trebuie replicate, ce set de date trebuie replicat și sub ce formă. Folosind aceeași conexiune la baza de date, putem avea mai multe procese de replicare - intervine conceptul de Mass Transfer ID, în care grupăm o suită de tabele, de exemplu, după anumite criterii funcționale. Un Mass Transfer ID are nevoie de minim patru procese de tip background (BGD WP), disponibile în sistem pentru a executa joburile standard SLT:

• Master Job - monitorizează configurațiile active, verificând regulat dacă există activități noi care trebuie executate.

• Master Controller Job - declanșat de Master Job, creează triggere și tabele de log în care sunt scrise înregistrările de copiat/actualizat.

• Data Load Job - copiază efectiv înregistrările și actualizează statusul; dacă este necesar, se poate specifica un număr maxim de joburi pentru data load, astfel încât să permită funcționarea optimă a mai multor Mass Transfer IDs pe sistem.

• Un alt job rezervat care să acopere mai multe categorii de activități:

  • Migration Object Definition- creează obiecte de bază pentru fiecare tabelă care trebuie replicată în parte.

  • Access Plan Calculation - stabilește planul de acces pentru fiecare tabelă, utilizat pentru încărcarea sau replicarea datelor.

  • Configuration Settings Change - execută modificările cerute de administrator în Configuration & Monitoring Dashboard.

Crearea unui proces nou pentru Mass Transfer se realizează folosind tranzacția LTRC.

Figura 6: Lista de Mass Tranfer ID - Tranzacția LTRC

Setările individuale pentru tabele trebuie specificate din tranzacția LTRS. Avem opțiunea să preluăm toate câmpurile din tabela sursă sau să omitem unele câmpuri. De asemenea, putem construi reguli de mapare a structurilor, simple (de ex., maparea unui RAW16 folosit pentru identificatori unici pe un NVARCHAR36) sau complexe (de ex., aplicarea unor patternuri înainte de scrierea datelor în tabela destinație, cu mențiunea că nu este recomandat să efectuăm calcule aici, ci în HANA, din rațiuni de performanță).

Figura 7: Setările de replicare pentru o tabelă anume în tranzacția LTRS

La nevoie, aceste setări pot fi salvate sub forma unei arhive și importate în alt sistem.

Execuție

Tot cu ajutorul tranzacției LTRC, declanșăm replicarea datelor pentru fiecare tabelă în parte. Avem la dispoziție mai multe moduri de operare:

• Load - încărcarea inițială a datelor;

• Replicate - sincronizarea datelor în timp real; execută automat și operația Load în cazul în care pasul a fost omis;

• Stop - oprește procesul de replicare și șterge artefactele aferente;

• Suspend - oprește procesul de replicare, dar modificările continuă să fie supravegheate;

• Resume - reia procesul de replicare suspendat.

Figura 8: Opțiunile disponibile pentru achiziția de date

Monitorizare

Pentru supravegherea procesului de replicare a datelor, utilizăm tranzacția LTRO, cu ajutorul căreia primim informații despre:

• Numărul proceselor care rulează și numărul proceselor disponibile;

• Statusul conexiunilor dintre sisteme, precum și log-uri (se înregistrează în protocol mesaje de atenționare și de eroare) ;

• Statusul transferurilor (pentru un Mass Transfer ID specificat) și diferite statistici legate de durata și de cantitatea de date replicate.

De multe ori, o imagine este mai valoroasă decât o descriere stufoasă. În imaginea de mai jos observăm în Data Transfer Monitor cum sunt folosite procesele disponibile și ce operațiuni s-au executat pe tabelele selectate.

Figura 9: Statusul procesării tabelelor din selecția curentă

În exemplul prezentat, observăm că inițial 2.368.456 de înregistrări au fost copiate în aprox. 6 minute, timp care cumulează și exportul datelor din sursă. De asemenea, apar defalcați timpii inițiali pentru citire, conversie și scriere a datelor. În funcție de numărul de procese de background disponibile, timpul acesta mai poate fi îmbunătățit. După încărcarea datelor în masă, urmează replicarea acestora în timp ce ele se înregistrează în sursă.

Figura 10: Statistici despre datele transferate

Concluzii

Importul datelor în SAP HANA se poate realiza prin numeroase metode, dintre care acest articol a prezentat doar trei. Rămâne la latitudinea echipei de proiect să stabilească strategia pentru transferul datelor, în funcție de necesitățile de zi cu zi - dacă este vorba despre o operațiune ce se va executa o singură dată sau dacă va fi declanșată la intervale regulate de timp. Lucrurile se complică dacă este nevoie de replicarea datelor în timp real, dar pentru fiecare dintre aceste scenarii, platforma SAP HANA este pregătită și vine în întâmpinarea clienților punându-le la dispoziție diferite mecanisme, atât pentru surse SAP, cât și non-SAP. În proiectul nostru, această combinație File Import + Bulk Load + SLT Replication a reușit să acopere toate cerințele de business, inclusiv pe cele de performanță. De menționat este și faptul că timpul necesar importului de date se cumulează cu timpul necesar exportului de date din baza de date sursă, care, în cazul nostru, a fost de multe ori mult mai mare decât importul propriu-zis. Vorbim de un factor de peste 15 în cazul Bulk Load. Vă invităm să descoperiți și să utilizați aceste metode în proiectele voastre și așteptăm, cu interes, comentarii despre experiențele voastre în acest domeniu.