Når du har Sberov-skala. Bruker Ab Initio med Hive og GreenPlum

For en tid tilbake sto vi overfor spørsmålet om å velge et ETL-verktøy for arbeid med Big Data. Den tidligere brukte Informatica BDM-løsningen passet ikke oss på grunn av begrenset funksjonalitet. Bruken er redusert til et rammeverk for å starte gnist-send-kommandoer. Det var ikke mange analoger på markedet som i prinsippet var i stand til å jobbe med datamengden vi håndterer hver dag. Til slutt valgte vi Ab Initio. Under pilotdemonstrasjoner viste produktet svært høy databehandlingshastighet. Det er nesten ingen informasjon om Ab Initio på russisk, så vi bestemte oss for å snakke om opplevelsen vår på Habré.

Ab Initio har mange klassiske og uvanlige transformasjoner, koden som kan utvides med sitt eget PDL-språk. For en liten bedrift vil et så kraftig verktøy sannsynligvis være overkill, og de fleste av mulighetene kan være dyre og ubrukte. Men hvis skalaen din er nær Sberovs, kan Ab Initio være interessant for deg.

Det hjelper en virksomhet å akkumulere kunnskap globalt og utvikle et økosystem, og en utvikler til å forbedre sine ferdigheter i ETL, forbedre sin kunnskap i skallet, gir muligheten til å mestre PDL-språket, gir et visuelt bilde av lasteprosesser og forenkler utvikling på grunn av overflod av funksjonelle komponenter.

I dette innlegget vil jeg snakke om evnene til Ab Initio og gi komparative egenskaper for arbeidet med Hive og GreenPlum.

• Beskrivelse av MDW-rammeverket og arbeidet med dets tilpasning for GreenPlum
• Ab Initio ytelsessammenligning mellom Hive og GreenPlum
• Working Ab Initio med GreenPlum i nesten sanntidsmodus

Funksjonaliteten til dette produktet er veldig bredt og krever mye tid å studere. Men med de riktige arbeidsferdighetene og de riktige ytelsesinnstillingene, er resultatene av databehandling veldig imponerende. Å bruke Ab Initio for en utvikler kan gi en interessant opplevelse. Dette er en ny versjon av ETL-utvikling, en hybrid mellom et visuelt miljø og nedlastingsutvikling i et skriptlignende språk.

Bedrifter utvikler økosystemene sine, og dette verktøyet kommer mer til nytte enn noen gang. Med Ab Initio kan du samle kunnskap om din nåværende virksomhet og bruke denne kunnskapen til å utvide gamle og åpne nye virksomheter. Alternativer til Ab Initio inkluderer visuelle utviklingsmiljøer Informatica BDM og ikke-visuelle utviklingsmiljøer Apache Spark.

Beskrivelse av Ab Initio

Ab Initio, som andre ETL-verktøy, er en samling produkter.

Ab Initio GDE (Graphical Development Environment) er et miljø for utvikleren der han konfigurerer datatransformasjoner og kobler dem sammen med datastrømmer i form av piler. I dette tilfellet kalles et slikt sett med transformasjoner en graf:

Inngangs- og utgangsforbindelsene til funksjonelle komponenter er porter og inneholder felt beregnet innenfor transformasjoner. Flere grafer forbundet med strømmer i form av piler i rekkefølgen av deres utførelse kalles en plan.

Det er flere hundre funksjonelle komponenter, som er mye. Mange av dem er høyt spesialiserte. Mulighetene til klassiske transformasjoner i Ab Initio er bredere enn i andre ETL-verktøy. For eksempel har Join flere utganger. I tillegg til resultatet av å koble til datasett, kan du få utdataposter for inngangsdatasett hvis nøkler ikke kunne kobles til. Du kan også få avslag, feil og en logg over transformasjonsoperasjonen, som kan leses i samme kolonne som en tekstfil og behandles med andre transformasjoner:

Eller du kan for eksempel materialisere en datamottaker i form av en tabell og lese data fra den i samme kolonne.

Det er originale transformasjoner. For eksempel har Scan-transformasjonen funksjonalitet som ligner på analytiske funksjoner. Det er transformasjoner med selvforklarende navn: Lag Data, Les Excel, Normaliser, Sorter i grupper, Kjør program, Kjør SQL, Join med DB osv. Grafer kan bruke kjøretidsparametere, inkludert muligheten for å sende parametere fra eller til operativsystemet. Filer med et ferdig sett med parametere som sendes til grafen kalles parametersett (psets).

Som forventet har Ab Initio GDE sitt eget depot kalt EME (Enterprise Meta Environment). Utviklere har mulighet til å jobbe med lokale versjoner av kode og sjekke utviklingen inn i det sentrale depotet.

Det er mulig, under utførelse eller etter utførelse av grafen, å klikke på en hvilken som helst flyt som forbinder transformasjonen og se på dataene som gikk mellom disse transformasjonene:

Det er også mulig å klikke på hvilken som helst strøm og se sporingsdetaljer - hvor mange paralleller transformasjonen fungerte i, hvor mange linjer og byte som ble lastet inn i hvilke av parallellene:

Det er mulig å dele opp utførelsen av grafen i faser og markere at noen transformasjoner må utføres først (i nullfasen), de neste i første fase, de neste i andre fase osv.

For hver transformasjon kan du velge den såkalte layouten (hvor den skal utføres): uten paralleller eller i parallelle tråder, hvis antall kan spesifiseres. Samtidig kan midlertidige filer som Ab Initio lager når transformasjoner kjører, plasseres både i serverfilsystemet og i HDFS.

I hver transformasjon, basert på standardmalen, kan du lage ditt eget skript i PDL, som er litt som et skall.

Med PDL kan du utvide funksjonaliteten til transformasjoner, og spesielt kan du dynamisk (ved kjøretid) generere vilkårlige kodefragmenter avhengig av kjøretidsparametere.

Ab Initio har også velutviklet integrasjon med OS via shell. Spesielt bruker Sberbank linux ksh. Du kan utveksle variabler med skallet og bruke dem som grafparametere. Du kan kalle utføringen av Ab Initio-grafer fra skallet og administrere Ab Initio.

I tillegg til Ab Initio GDE er mange andre produkter inkludert i leveransen. Det er et eget Co>Operation System med krav om å bli kalt et operativsystem. Det er et kontroll>senter hvor du kan planlegge og overvåke nedlastingsflyter. Det finnes produkter for å gjøre utvikling på et mer primitivt nivå enn Ab Initio GDE tillater.

Beskrivelse av MDW-rammeverket og arbeidet med dets tilpasning for GreenPlum

Sammen med produktene sine leverer leverandøren MDW (Metadata Driven Warehouse)-produktet, som er en grafkonfigurator designet for å hjelpe med typiske oppgaver med å fylle datavarehus eller datahvelv.

Den inneholder tilpassede (prosjektspesifikke) metadataparsere og ferdige kodegeneratorer rett ut av esken.

Som input mottar MDW en datamodell, en konfigurasjonsfil for å sette opp en tilkobling til en database (Oracle, Teradata eller Hive) og noen andre innstillinger. Den prosjektspesifikke delen distribuerer for eksempel modellen til en database. Den ut-av-boksen-delen av produktet genererer grafer og konfigurasjonsfiler for dem ved å laste inn data i modelltabeller. I dette tilfellet opprettes grafer (og psets) for flere moduser for initialisering og inkrementell arbeid med å oppdatere enheter.

I tilfeller med Hive og RDBMS genereres forskjellige grafer for initialisering og inkrementelle dataoppdateringer.

Når det gjelder Hive, kobles de innkommende deltadataene via Ab Initio Join med dataene som var i tabellen før oppdateringen. Datalastere i MDW (både i Hive og RDBMS) setter ikke bare inn nye data fra deltaet, men lukker også periodene med relevans for dataene hvis primærnøkler mottok deltaet. I tillegg må du skrive om den uendrede delen av dataene. Men dette må gjøres fordi Hive ikke har slette- eller oppdateringsoperasjoner.

Når det gjelder RDBMS, ser grafer for inkrementell dataoppdatering mer optimale ut, fordi RDBMS har reelle oppdateringsmuligheter.

Det mottatte deltaet lastes inn i en mellomtabell i databasen. Etter dette kobles deltaet til dataene som var i tabellen før oppdateringen. Og dette gjøres ved å bruke SQL ved å bruke en generert SQL-spørring. Deretter, ved å bruke SQL-kommandoene delete+insert, settes nye data fra deltaet inn i måltabellen og periodene med relevans for dataene hvis primærnøkler mottok deltaet, lukkes.
Det er ikke nødvendig å omskrive uendrede data.

Så vi kom til den konklusjonen at når det gjelder Hive, må MDW gå for å skrive om hele tabellen fordi Hive ikke har en oppdateringsfunksjon. Og ingenting er bedre enn å fullstendig omskrive dataene når oppdateringen er oppfunnet. Når det gjelder RDBMS, tvert imot, fant skaperne av produktet det nødvendig å overlate tilkoblingen og oppdateringen av tabeller til bruk av SQL.

For et prosjekt hos Sberbank laget vi en ny, gjenbrukbar implementering av en databaselaster for GreenPlum. Dette ble gjort basert på versjonen som MDW genererer for Teradata. Det var Teradata, og ikke Oracle, som kom nærmest og best for dette, fordi... er også et MPP-system. Arbeidsmetodene, samt syntaksen, til Teradata og GreenPlum viste seg å være like.

Eksempler på MDW-kritiske forskjeller mellom ulike RDBMS-er er som følger. I GreenPlum, i motsetning til Teradata, må du skrive en klausul når du lager tabeller

distributed by

Teradata skriver:

delete <table> all

, og i GreenPlum skriver de

delete from <table>

I Oracle skriver de for optimaliseringsformål

delete from t where rowid in (<соединение t с дельтой>)

, og Teradata og GreenPlum skriver

delete from t where exists (select * from delta where delta.pk=t.pk)

Vi legger også merke til at for at Ab Initio skulle fungere med GreenPlum, var det nødvendig å installere GreenPlum-klienten på alle noder i Ab Initio-klyngen. Dette er fordi vi koblet til GreenPlum samtidig fra alle noder i klyngen vår. Og for at lesing fra GreenPlum skulle være parallell og hver parallell Ab Initio-tråd kunne lese sin egen del av data fra GreenPlum, måtte vi plassere en konstruksjon forstått av Ab Initio i "hvor"-delen av SQL-spørringer

where ABLOCAL()

og bestemme verdien av denne konstruksjonen ved å spesifisere parameteravlesningen fra transformasjonsdatabasen

ablocal_expr=«string_concat("mod(t.", string_filter_out("{$TABLE_KEY}","{}"), ",", (decimal(3))(number_of_partitions()),")=", (decimal(3))(this_partition()))»

, som kompilerer til noe sånt som

mod(sk,10)=3

, dvs. du må spørre GreenPlum med et eksplisitt filter for hver partisjon. For andre databaser (Teradata, Oracle) kan Ab Initio utføre denne parallelliseringen automatisk.

Ab Initio ytelsessammenligning mellom Hive og GreenPlum

Sberbank gjennomførte et eksperiment for å sammenligne ytelsen til MDW-genererte grafer i forhold til Hive og i forhold til GreenPlum. Som en del av eksperimentet, i tilfelle av Hive var det 5 noder på samme klynge som Ab Initio, og i tilfelle av GreenPlum var det 4 noder på en separat klynge. De. Hive hadde en viss maskinvarefordel fremfor GreenPlum.

Vi vurderte to par med grafer som utfører den samme oppgaven med å oppdatere data i Hive og GreenPlum. Samtidig ble grafene generert av MDW-konfiguratoren lansert:

• innledende belastning + inkrementell belastning av tilfeldig genererte data til en Hive-tabell
• innledende belastning + inkrementell belastning av tilfeldig genererte data i samme GreenPlum-tabell

I begge tilfeller (Hive og GreenPlum) kjørte de opplastinger til 10 parallelle tråder på samme Ab Initio-klynge. Ab Initio lagret mellomliggende data for beregninger i HDFS (i form av Ab Initio ble MFS-layout med HDFS brukt). En linje med tilfeldig genererte data okkuperte 200 byte i begge tilfeller.

Resultatet ble slik:

Vinter:

Første lasting i Hive

Rader satt inn
+6 000 000 XNUMX
+60 000 000 XNUMX
+600 000 000 XNUMX

Initialiseringsvarighet
nedlastinger på sekunder
41
203
1

Inkrementell lasting i Hive

Antall rader tilgjengelig i
måltabell i begynnelsen av eksperimentet
+6 000 000 XNUMX
+60 000 000 XNUMX
+600 000 000 XNUMX

Antall deltalinjer brukt på
måltabell under eksperimentet
+6 000 000 XNUMX
+6 000 000 XNUMX
+6 000 000 XNUMX

Varighet av inkrementell
nedlastinger på sekunder
88
299
2

GreenPlum:

Første lasting i GreenPlum

Rader satt inn
+6 000 000 XNUMX
+60 000 000 XNUMX
+600 000 000 XNUMX

Initialiseringsvarighet
nedlastinger på sekunder
72
360
3

Inkrementell lasting i GreenPlum

Antall rader tilgjengelig i
måltabell i begynnelsen av eksperimentet
+6 000 000 XNUMX
+60 000 000 XNUMX
+600 000 000 XNUMX

Antall deltalinjer brukt på
måltabell under eksperimentet
+6 000 000 XNUMX
+6 000 000 XNUMX
+6 000 000 XNUMX

Varighet av inkrementell
nedlastinger på sekunder
159
199
321

Vi ser at hastigheten på innledende lasting i både Hive og GreenPlum lineært avhenger av datamengden, og på grunn av bedre maskinvare er den litt raskere for Hive enn for GreenPlum.

Inkrementell lasting i Hive avhenger også lineært av volumet av tidligere lastet data som er tilgjengelig i måltabellen og fortsetter ganske sakte ettersom volumet vokser. Dette er forårsaket av behovet for å omskrive måltabellen fullstendig. Dette betyr at å bruke små endringer på store tabeller ikke er et godt bruksområde for Hive.

Inkrementell lasting i GreenPlum avhenger svakt av volumet av tidligere lastet data som er tilgjengelig i måltabellen og fortsetter ganske raskt. Dette skjedde takket være SQL Joins og GreenPlum-arkitekturen, som tillater sletteoperasjonen.

Så GreenPlum legger til deltaet ved å bruke delete+sert-metoden, men Hive har ikke slette- eller oppdateringsoperasjoner, så hele dataarrayen ble tvunget til å skrives om helt under en inkrementell oppdatering. Sammenligningen av cellene uthevet med fet skrift er mest avslørende, siden den tilsvarer det vanligste alternativet for å bruke ressurskrevende nedlastinger. Vi ser at GreenPlum slo Hive i denne testen med 8 ganger.

Working Ab Initio med GreenPlum i nesten sanntidsmodus

I dette eksperimentet vil vi teste Ab Initios evne til å oppdatere GreenPlum-tabellen med tilfeldig genererte databiter i nesten sanntid. La oss vurdere GreenPlum-tabellen dev42_1_db_usl.TESTING_SUBJ_org_finval, som vi skal jobbe med.

Vi vil bruke tre Ab Initio-grafer for å jobbe med det:

1) Graph Create_test_data.mp – lager datafiler i HDFS med 10 6 000 rader i 000 parallelle tråder. Dataene er tilfeldige, strukturen er organisert for innsetting i tabellen vår

2) Graf mdw_load.day_one.current.dev42_1_db_usl_testing_subj_org_finval.pset – MDW-generert graf ved å initialisere datainnsetting i tabellen vår i 10 parallelle tråder (testdata generert av graf (1) brukes)

3) Graf mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset – en graf generert av MDW for inkrementell oppdatering av tabellen vår i 10 parallelle tråder ved bruk av en del av nylig mottatte data (delta) generert av graf (1)

La oss kjøre skriptet nedenfor i NRT-modus:

• generere 6 000 000 testlinjer
• utfør en innledende belastning, sett inn 6 000 000 testrader i en tom tabell
• gjenta trinnvis nedlasting 5 ganger
  • generere 6 000 000 testlinjer
  • utfør en inkrementell innsetting av 6 000 000 testrader i tabellen (i dette tilfellet er valid_to_ts-utløpstiden satt til de gamle dataene og nyere data med samme primærnøkkel settes inn)

Dette scenariet emulerer modusen for reell drift av et bestemt forretningssystem - en ganske stor del av nye data vises i sanntid og helles umiddelbart inn i GreenPlum.

La oss nå se på skriptets logg:

Start Create_test_data.input.pset på 2020-06-04 11:49:11
Fullfør Create_test_data.input.pset kl. 2020-06-04 11:49:37
Start mdw_load.day_one.current.dev42_1_db_usl_testing_subj_org_finval.pset på 2020-06-04 11:49:37
Fullfør mdw_load.day_one.current.dev42_1_db_usl_testing_subj_org_finval.pset kl. 2020-06-04 11:50:42
Start Create_test_data.input.pset på 2020-06-04 11:50:42
Fullfør Create_test_data.input.pset kl. 2020-06-04 11:51:06
Start mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset på 2020-06-04 11:51:06
Fullfør mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset kl. 2020-06-04 11:53:41
Start Create_test_data.input.pset på 2020-06-04 11:53:41
Fullfør Create_test_data.input.pset kl. 2020-06-04 11:54:04
Start mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset på 2020-06-04 11:54:04
Fullfør mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset kl. 2020-06-04 11:56:51
Start Create_test_data.input.pset på 2020-06-04 11:56:51
Fullfør Create_test_data.input.pset kl. 2020-06-04 11:57:14
Start mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset på 2020-06-04 11:57:14
Fullfør mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset kl. 2020-06-04 11:59:55
Start Create_test_data.input.pset på 2020-06-04 11:59:55
Fullfør Create_test_data.input.pset kl. 2020-06-04 12:00:23
Start mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset på 2020-06-04 12:00:23
Fullfør mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset kl. 2020-06-04 12:03:23
Start Create_test_data.input.pset på 2020-06-04 12:03:23
Fullfør Create_test_data.input.pset kl. 2020-06-04 12:03:49
Start mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset på 2020-06-04 12:03:49
Fullfør mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset kl. 2020-06-04 12:06:46

Det viser seg dette bildet:

Graph
Starttid
Avslutt tid
Lengde

Create_test_data.input.pset
04.06.2020 11: 49: 11
04.06.2020 11: 49: 37
00:00:26

mdw_load.day_one.current.
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 11: 49: 37
04.06.2020 11: 50: 42
00:01:05

Create_test_data.input.pset
04.06.2020 11: 50: 42
04.06.2020 11: 51: 06
00:00:24

mdw_load.regular.current.
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 11: 51: 06
04.06.2020 11: 53: 41
00:02:35

Create_test_data.input.pset
04.06.2020 11: 53: 41
04.06.2020 11: 54: 04
00:00:23

mdw_load.regular.current.
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 11: 54: 04
04.06.2020 11: 56: 51
00:02:47

Create_test_data.input.pset
04.06.2020 11: 56: 51
04.06.2020 11: 57: 14
00:00:23

mdw_load.regular.current.
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 11: 57: 14
04.06.2020 11: 59: 55
00:02:41

Create_test_data.input.pset
04.06.2020 11: 59: 55
04.06.2020 12: 00: 23
00:00:28

mdw_load.regular.current.
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 12: 00: 23
04.06.2020 12: 03: 23
00:03:00

Create_test_data.input.pset
04.06.2020 12: 03: 23
04.06.2020 12: 03: 49
00:00:26

mdw_load.regular.current.
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 12: 03: 49
04.06.2020 12: 06: 46
00:02:57

Vi ser at 6 000 000 inkrementlinjer behandles på 3 minutter, noe som er ganske raskt.
Dataene i måltabellen viste seg å være fordelt som følger:

select valid_from_ts, valid_to_ts, count(1), min(sk), max(sk) from dev42_1_db_usl.TESTING_SUBJ_org_finval group by valid_from_ts, valid_to_ts order by 1,2;

Du kan se samsvaret mellom de innsatte dataene og tidspunktene grafene ble lansert.
Dette betyr at du kan kjøre inkrementell lasting av data til GreenPlum i Ab Initio med en veldig høy frekvens og observere en høy hastighet på å sette inn disse dataene i GreenPlum. Selvfølgelig vil det ikke være mulig å starte en gang i sekundet, siden Ab Initio, som ethvert ETL-verktøy, krever tid for å "starte opp" når det lanseres.

Konklusjon

Ab Initio brukes for tiden i Sberbank for å bygge et Unified Semantic Data Layer (ESS). Dette prosjektet innebærer å bygge en enhetlig versjon av tilstanden til ulike bankforretningsenheter. Informasjon kommer fra ulike kilder, replikaene av disse er utarbeidet på Hadoop. Basert på virksomhetens behov utarbeides en datamodell og datatransformasjoner beskrives. Ab Initio laster informasjon inn i ESN og de nedlastede dataene er ikke bare av interesse for virksomheten i seg selv, men fungerer også som en kilde for å bygge datamars. Samtidig lar funksjonaliteten til produktet deg bruke ulike systemer som mottaker (Hive, Greenplum, Teradata, Oracle), noe som gjør det mulig å enkelt klargjøre data for en virksomhet i de ulike formatene den krever.

Ab Initios muligheter er brede; for eksempel gjør det inkluderte MDW-rammeverket det mulig å bygge tekniske og forretningshistoriske data ut av boksen. For utviklere gjør Ab Initio det mulig å ikke finne opp hjulet på nytt, men å bruke mange eksisterende funksjonelle komponenter, som i hovedsak er biblioteker som trengs når man jobber med data.

Forfatteren er ekspert i fagmiljøet til Sberbank SberProfi DWH/BigData. Fagmiljøet SberProfi DWH/BigData er ansvarlig for å utvikle kompetanse innen områder som Hadoop-økosystemet, Teradata, Oracle DB, GreenPlum, samt BI-verktøy Qlik, SAP BO, Tableau, etc.

Kilde: www.habr.com