Antaŭ iom da tempo, ni alfrontis la demandon pri elekto de ETL-ilo por labori kun Big Data. La antaŭe uzita Informatica BDM-solvo ne konvenis al ni pro limigita funkcieco. Ĝia uzo estis reduktita al kadro por lanĉi spark-submeti komandojn. Ne estis multaj analogoj sur la merkato, kiuj principe kapablas labori kun la volumo de datumoj, kiujn ni traktas ĉiutage. Fine ni elektis Ab Inition. Dum pilotmanifestacioj, la produkto montris tre altan datumtraktadrapidecon. Pri Ab Initio preskaŭ mankas informoj en la rusa, do ni decidis paroli pri nia sperto pri Habré.
Ab Initio havas multajn klasikajn kaj nekutimajn transformojn, kies kodo povas esti etendita uzante sian propran PDL-lingvon. Por malgranda komerco, tia potenca ilo verŝajne estos troa, kaj la plej multaj el ĝiaj kapabloj povas esti multekostaj kaj neuzataj. Sed se via skalo estas proksima al tiu de Sberov, tiam Ab Initio povas esti interesa por vi.
Ĝi helpas entreprenon amasigi scion tutmonde kaj evoluigi ekosistemon, kaj programisto plibonigi siajn kapablojn en ETL, plibonigi sian scion en la ŝelo, disponigas la ŝancon regi la PDL-lingvon, donas vidan bildon de ŝarĝaj procezoj kaj simpligas evoluon. pro la abundo de funkciaj komponantoj.
En ĉi tiu afiŝo mi parolos pri la kapabloj de Ab Initio kaj provizos komparajn karakterizaĵojn de ĝia laboro kun Hive kaj GreenPlum.
- Priskribo de la kadro MDW kaj laboro pri ĝia personigo por GreenPlum
- Ab Initio-efikeckomparo inter Hive kaj GreenPlum
- Laborante Ab Initio kun GreenPlum en Reĝimo Preskaŭ Reala Tempo
La funkcieco de ĉi tiu produkto estas tre larĝa kaj postulas multan tempon por studi. Tamen, kun la taŭgaj laborkapabloj kaj la ĝustaj agordoj, la rezultoj de datumtraktado estas tre imponaj. Uzado de Ab Initio por programisto povas provizi interesan sperton. Ĉi tio estas nova kompreno pri ETL-evoluo, hibrido inter vida medio kaj elŝuta evoluo en manuskripto-simila lingvo.
Komercoj disvolvas siajn ekosistemojn kaj ĉi tiu ilo utilas pli ol iam ajn. Kun Ab Initio, vi povas amasigi scion pri via nuna komerco kaj uzi ĉi tiun scion por vastigi malnovajn kaj malfermi novajn entreprenojn. Alternativoj al Ab Initio inkluzivas vidajn evoluajn mediojn Informatica BDM kaj nevidajn evoluajn mediojn Apache Spark.
Priskribo de Ab Initio
Ab Initio, kiel aliaj ETL-iloj, estas kolekto de produktoj.
Ab Initio GDE (Grafika Disvolva Medio) estas medio por la programisto, en kiu li agordas datumajn transformojn kaj ligas ilin kun datumfluoj en formo de sagoj. En ĉi tiu kazo, tia aro de transformoj estas nomita grafeo:
La enigo- kaj produktaĵkonektoj de funkciaj komponentoj estas havenoj kaj enhavas kampojn kalkulitajn ene de transformoj. Pluraj grafeoj ligitaj per fluoj en formo de sagoj en la ordo de sia ekzekuto estas nomitaj plano.
Estas kelkcent funkciaj komponantoj, kio estas multe. Multaj el ili estas tre specialigitaj. La kapabloj de klasikaj transformoj en Ab Initio estas pli larĝaj ol en aliaj ETL-iloj. Ekzemple, Aliĝi havas plurajn elirojn. Krom la rezulto de konekto de datumaroj, vi povas akiri eligajn rekordojn de enigo datumseroj, kies ŝlosiloj ne povis esti konektitaj. Vi ankaŭ povas ricevi malakceptojn, erarojn kaj protokolon de la transforma operacio, kiu povas esti legita en la sama kolumno kiel tekstdosiero kaj prilaborita kun aliaj transformoj:
Aŭ, ekzemple, vi povas materiigi datumricevilon en formo de tabelo kaj legi datumojn de ĝi en la sama kolumno.
Estas originalaj transformoj. Ekzemple, la Scan-transformo havas funkciecon similan al analizaj funkcioj. Estas transformoj kun memklarigeblaj nomoj: Krei Datumojn, Legi Excel, Normaligi, Ordigi ene de Grupoj, Kuri Programon, Kuri SQL, Kunigi kun DB, ktp. Grafikaĵoj povas uzi rultempajn parametrojn, inkluzive de la eblo de pasi parametrojn de aŭ al. la operaciumo. Dosieroj kun preta aro de parametroj pasitaj al la grafeo estas nomitaj parametroj (psets).
Kiel atendite, Ab Initio GDE havas sian propran deponejon nomitan EME (Enterprise Meta Environment). Programistoj havas la ŝancon labori kun lokaj versioj de kodo kaj kontroli siajn evoluojn en la centran deponejon.
Eblas, dum ekzekuto aŭ post ekzekuto de la grafeo, klaki sur iu ajn fluo liganta la transformon kaj rigardi la datumojn kiuj pasis inter ĉi tiuj transformoj:
Eblas ankaŭ klaki sur iu ajn fluo kaj vidi spurajn detalojn - kiom da paraleloj funkciis la transformo, kiom da linioj kaj bajtoj estis ŝarĝitaj en kiu el la paraleloj:
Eblas dividi la ekzekuton de la grafeo en fazojn kaj marki, ke iuj transformoj devas esti faritaj unue (en la nula fazo), la sekvaj en la unua fazo, la sekvaj en la dua fazo, ktp.
Por ĉiu transformo, vi povas elekti la tiel nomatan aranĝon (kie ĝi estos efektivigita): sen paraleloj aŭ en paralelaj fadenoj, kies nombro povas esti specifita. Samtempe, provizoraj dosieroj kiujn Ab Initio kreas kiam transformoj funkcias, povas esti metitaj kaj en la servila dosiersistemo kaj en HDFS.
En ĉiu transformo, surbaze de la defaŭlta ŝablono, vi povas krei vian propran skripton en PDL, kiu estas iom kiel ŝelo.
Kun PDL, vi povas etendi la funkciecon de transformoj kaj, precipe, vi povas dinamike (je rultempo) generi arbitrajn kodfragmentojn depende de rultempaj parametroj.
Ab Initio ankaŭ havas bonevoluintan integriĝon kun la OS per ŝelo. Specife, Sberbank uzas linukson ksh. Vi povas interŝanĝi variablojn kun la ŝelo kaj uzi ilin kiel grafeajn parametrojn. Vi povas voki la ekzekuton de Ab Initio-grafoj de la ŝelo kaj administri Ab Inition.
Krom Ab Initio GDE, multaj aliaj produktoj estas inkluzivitaj en la transdono. Estas sia propra Ko>Operacia Sistemo kun pretendo esti nomata operaciumo. Estas Kontrolo> Centro, kie vi povas plani kaj kontroli elŝutajn fluojn. Estas produktoj por fari evoluon je pli primitiva nivelo ol Ab Initio GDE permesas.
Priskribo de la kadro MDW kaj laboro pri ĝia personigo por GreenPlum
Kune kun ĝiaj produktoj, la vendisto liveras la produkton MDW (Metadata Driven Warehouse), kiu estas grafika agordilo dizajnita por helpi kun tipaj taskoj de loĝado de datumstokejoj aŭ datumtrezorejoj.
Ĝi enhavas kutimajn (projekt-specifajn) metadatumajn analizilojn kaj pretajn kodgenerantojn el la skatolo.
Kiel enigo, MDW ricevas datummodelon, agordan dosieron por starigi konekton al datumbazo (Oracle, Teradata aŭ Hive) kaj iujn aliajn agordojn. La projekt-specifa parto, ekzemple, deplojas la modelon al datumbazo. La senfina parto de la produkto generas grafikaĵojn kaj agordajn dosierojn por ili ŝarĝante datumojn en modelajn tabelojn. En ĉi tiu kazo, grafikaĵoj (kaj psetoj) estas kreitaj por pluraj reĝimoj de pravalorigo kaj pliiga laboro pri ĝisdatigo de estaĵoj.
En la kazoj de Hive kaj RDBMS, malsamaj grafeoj estas generitaj por inicialigo kaj pliigaj datenĝisdatigoj.
En la kazo de Hive, la envenantaj deltaj datumoj estas konektitaj per Ab Initio Join kun la datumoj kiuj estis en la tabelo antaŭ la ĝisdatigo. Datumaj ŝargiloj en MDW (kaj en Hive kaj RDBMS) ne nur enmetas novajn datumojn de la delto, sed ankaŭ fermas la periodojn de graveco de la datumoj, kies ĉefaj ŝlosiloj ricevis la delta. Krome, vi devas reverki la neŝanĝitan parton de la datumoj. Sed ĉi tio devas esti farita ĉar Hive ne havas operaciojn por forigi aŭ ĝisdatigi.
En la kazo de RDBMS, grafikaĵoj por pliiga datuma ĝisdatigo aspektas pli optimumaj, ĉar RDBMS havas realajn ĝisdatigajn kapablojn.
La ricevita delto estas ŝarĝita en mezan tabelon en la datumbazo. Post ĉi tio, la delto estas konektita al la datumoj kiuj estis en la tabelo antaŭ la ĝisdatigo. Kaj ĉi tio estas farita uzante SQL uzante generitan SQL-demandon. Poste, uzante la SQL-komandojn forviŝi+enigi, novaj datumoj de la delto estas enmetitaj en la celtabelon kaj la periodoj de graveco de la datumoj kies primaraj ŝlosiloj ricevis la delto estas fermitaj.
Ne necesas reverki neŝanĝitajn datumojn.
Do ni venis al la konkludo, ke en la kazo de Hive, MDW devas iri por reverki la tutan tabelon ĉar Hive ne havas ĝisdatigfunkcion. Kaj nenio pli bona ol tute reverki la datumojn kiam ĝisdatigo estis inventita. En la kazo de RDBMS, male, la kreintoj de la produkto trovis necesa konfidi la konekton kaj ĝisdatigon de tabeloj al la uzo de SQL.
Por projekto ĉe Sberbank, ni kreis novan, reuzeblan efektivigon de datumbaza ŝargilo por GreenPlum. Ĉi tio estis farita surbaze de la versio, kiun MDW generas por Teradata. Estis Teradata, kaj ne Oracle, kiu plej proksime kaj plej bone venis por tio, ĉar... estas ankaŭ MPP-sistemo. La labormetodoj, same kiel la sintakso, de Teradata kaj GreenPlum montriĝis similaj.
Ekzemploj de MDW-kritikaj diferencoj inter malsamaj RDBMSoj estas kiel sekvas. En GreenPlum, male al Teradata, kiam oni kreas tabelojn oni devas skribi klaŭzon
distributed byTeradata skribas:
delete <table> all, kaj en GreenPlum oni skribas
delete from <table>En Oracle, por optimumigo, ili skribas
delete from t where rowid in (<соединение t с дельтой>), kaj Teradata kaj GreenPlum skribas
delete from t where exists (select * from delta where delta.pk=t.pk)Ni ankaŭ rimarkas, ke por ke Ab Initio funkciu kun GreenPlum, estis necese instali la klienton GreenPlum sur ĉiuj nodoj de la Ab Initio-grupo. Ĉi tio estas ĉar ni konektis al GreenPlum samtempe de ĉiuj nodoj en nia areto. Kaj por ke legado de GreenPlum estu paralela kaj ĉiu paralela Ab Initio-fadeno legu sian propran parton de datumoj de GreenPlum, ni devis meti konstruon komprenitan de Ab Initio en la sekcion "kie" de SQL-demandoj.
where ABLOCAL()kaj determini la valoron de ĉi tiu konstruo specifante la parametran legadon de la transforma datumbazo
ablocal_expr=«string_concat("mod(t.", string_filter_out("{$TABLE_KEY}","{}"), ",", (decimal(3))(number_of_partitions()),")=", (decimal(3))(this_partition()))», kiu kompilas al io simila
mod(sk,10)=3, t.e. vi devas instigi GreenPlum per eksplicita filtrilo por ĉiu sekcio. Por aliaj datumbazoj (Teradata, Oracle), Ab Initio povas plenumi ĉi tiun paraleligon aŭtomate.
Ab Initio-efikeckomparo inter Hive kaj GreenPlum
Sberbank faris eksperimenton por kompari la agadon de MDW-generitaj grafikaĵoj rilate al Hive kaj rilate al GreenPlum. Kiel parto de la eksperimento, en la kazo de Hive estis 5 nodoj sur la sama areto kiel Ab Initio, kaj en la kazo de GreenPlum estis 4 nodoj sur aparta areto. Tiuj. Hive havis iun aparataron avantaĝon super GreenPlum.
Ni konsideris du parojn da grafikaĵoj plenumantaj la saman taskon ĝisdatigi datumojn en Hive kaj GreenPlum. En la sama tempo, la grafikaĵoj generitaj de la MDW-agordilo estis lanĉitaj:
- komenca ŝarĝo + pliiga ŝarĝo de hazarde generitaj datumoj en Hive-tabelon
- komenca ŝarĝo + pliiga ŝarĝo de hazarde generitaj datumoj en la saman GreenPlum-tabelon
En ambaŭ kazoj (Hive kaj GreenPlum) ili kuris alŝutojn al 10 paralelaj fadenoj sur la sama Ab Initio-areto. Ab Initio konservis mezajn datenojn por kalkuloj en HDFS (laŭ Ab Initio, MFS-aranĝo uzanta HDFS estis uzita). Unu linio de hazarde generitaj datumoj okupis 200 bajtojn en ambaŭ kazoj.
La rezulto estis tia:
Abelujo:
Komenca ŝarĝo en Hive
Vicoj enmetitaj
6 000 000
60 000 000
600 000 000
Daŭro de komencado
elŝutoj en sekundoj
41
203
1 601
Pliiga ŝarĝo en Hive
Nombro da vicoj disponeblaj en
celtabelo komence de la eksperimento
6 000 000
60 000 000
600 000 000
Nombro de deltaj linioj aplikitaj al
celtabelo dum la eksperimento
6 000 000
6 000 000
6 000 000
Daŭro de pliigo
elŝutoj en sekundoj
88
299
2 541
GreenPlum:
Komenca ŝarĝo en GreenPlum
Vicoj enmetitaj
6 000 000
60 000 000
600 000 000
Daŭro de komencado
elŝutoj en sekundoj
72
360
3 631
Pliiga ŝarĝo en GreenPlum
Nombro da vicoj disponeblaj en
celtabelo komence de la eksperimento
6 000 000
60 000 000
600 000 000
Nombro de deltaj linioj aplikitaj al
celtabelo dum la eksperimento
6 000 000
6 000 000
6 000 000
Daŭro de pliigo
elŝutoj en sekundoj
159
199
321
Ni vidas, ke la rapideco de komenca ŝarĝo en Hive kaj GreenPlum linie dependas de la kvanto da datumoj kaj, pro pli bona aparataro, ĝi estas iomete pli rapida por Hive ol por GreenPlum.
Pliiga ŝarĝo en Hive ankaŭ linie dependas de la volumeno de antaŭe ŝarĝitaj datumoj disponeblaj en la cela tabelo kaj daŭrigas sufiĉe malrapide kiam la volumeno kreskas. Ĉi tio estas kaŭzita de la bezono reverki la celtabelon tute. Ĉi tio signifas, ke apliki malgrandajn ŝanĝojn al grandegaj tabeloj ne estas bona uzkazo por Hive.
Pliiga ŝarĝo en GreenPlum malforte dependas de la volumo de antaŭe ŝarĝitaj datumoj disponeblaj en la cela tabelo kaj daŭrigas sufiĉe rapide. Ĉi tio okazis danke al SQL Joins kaj la arkitekturo GreenPlum, kiu ebligas la forigan operacion.
Do, GreenPlum aldonas la delton per la metodo delete+insert, sed Hive ne havas forigajn aŭ ĝisdatigoperaciojn, do la tuta datumtabelo estis devigita esti reverkita tute dum pliiga ĝisdatigo. La komparo de la ĉeloj emfazitaj en grasa skribo estas plej malkaŝa, ĉar ĝi respondas al la plej ofta opcio por uzi rimedojn-intensajn elŝutojn. Ni vidas, ke GreenPlum venkis Hive en ĉi tiu testo je 8 fojojn.
Laborante Ab Initio kun GreenPlum en Reĝimo Preskaŭ Reala Tempo
En ĉi tiu eksperimento, ni provos la kapablon de Ab Initio ĝisdatigi la GreenPlum-tabelon kun hazarde generitaj partoj de datumoj en preskaŭ reala tempo. Ni konsideru la tabelon GreenPlum dev42_1_db_usl.TESTING_SUBJ_org_finval, kun kiu ni laboros.
Ni uzos tri Ab Initio-grafikojn por labori kun ĝi:
1) Graph Create_test_data.mp - kreas datumdosierojn en HDFS kun 10 vicoj en 6 paralelaj fadenoj. La datumoj estas hazardaj, ĝia strukturo estas organizita por enmeti en nian tabelon
2) Grafiku mdw_load.day_one.current.dev42_1_db_usl_testing_subj_org_finval.pset - MDW generita grafeo per pravalorigo de datumoj enmeto en nian tabelon en 10 paralelaj fadenoj (testaj datumoj generitaj de grafikaĵo (1) estas uzataj)
3) Grafikaĵo mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset - grafeo generita de MDW por pliiga ĝisdatigo de nia tabelo en 10 paralelaj fadenoj uzante parton de ĵus ricevitaj datumoj (delta) generita de grafeo (1)
Ni rulu la suban skripton en NRT-reĝimo:
- generi 6 testliniojn
- elfari komencan ŝarĝon enmetu 6 testajn vicojn en malplenan tablon
- ripetu pliigan elŝuton 5 fojojn
- generi 6 testliniojn
- fari pliigan enmeton de 6 testaj vicoj en la tabelon (en ĉi tiu kazo, la valid_to_ts eksvalidiĝotempo estas agordita al la malnovaj datumoj kaj pli lastatempaj datumoj kun la sama ĉefa ŝlosilo estas enmetitaj)
Ĉi tiu scenaro imitas la manieron de reala funkciado de certa komerca sistemo - sufiĉe granda parto de novaj datumoj aperas en reala tempo kaj tuj estas verŝita en GreenPlum.
Nun ni rigardu la protokolon de la skripto:
Komencu Create_test_data.input.pset je 2020-06-04 11:49:11
Finu Create_test_data.input.pset je 2020-06-04 11:49:37
Komencu mdw_load.day_one.current.dev42_1_db_usl_testing_subj_org_finval.pset je 2020-06-04 11:49:37
Finu mdw_load.day_one.current.dev42_1_db_usl_testing_subj_org_finval.pset je 2020-06-04 11:50:42
Komencu Create_test_data.input.pset je 2020-06-04 11:50:42
Finu Create_test_data.input.pset je 2020-06-04 11:51:06
Komencu mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset je 2020-06-04 11:51:06
Finu mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset je 2020-06-04 11:53:41
Komencu Create_test_data.input.pset je 2020-06-04 11:53:41
Finu Create_test_data.input.pset je 2020-06-04 11:54:04
Komencu mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset je 2020-06-04 11:54:04
Finu mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset je 2020-06-04 11:56:51
Komencu Create_test_data.input.pset je 2020-06-04 11:56:51
Finu Create_test_data.input.pset je 2020-06-04 11:57:14
Komencu mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset je 2020-06-04 11:57:14
Finu mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset je 2020-06-04 11:59:55
Komencu Create_test_data.input.pset je 2020-06-04 11:59:55
Finu Create_test_data.input.pset je 2020-06-04 12:00:23
Komencu mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset je 2020-06-04 12:00:23
Finu mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset je 2020-06-04 12:03:23
Komencu Create_test_data.input.pset je 2020-06-04 12:03:23
Finu Create_test_data.input.pset je 2020-06-04 12:03:49
Komencu mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset je 2020-06-04 12:03:49
Finu mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset je 2020-06-04 12:06:46
Rezultas ĉi tiu bildo:
Diagramo
Komencu tempon
Finu la tempon
longo
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.regula.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.regula.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.regula.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.regula.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.regula.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
Ni vidas, ke 6-pliiglinioj estas procesitaj en 000 minutoj, kio estas sufiĉe rapida.
La datumoj en la cela tabelo montriĝis distribuitaj jene:
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;
Vi povas vidi la korespondado de la enmetitaj datumoj al la tempoj kiam la grafikaĵoj estis lanĉitaj.
Ĉi tio signifas, ke vi povas ruli pliigan ŝarĝon de datumoj en GreenPlum en Ab Initio kun tre alta frekvenco kaj observi altan rapidecon enmeti ĉi tiujn datumojn en GreenPlum. Kompreneble, ne eblos lanĉi unufoje sekundon, ĉar Ab Initio, kiel ajna ETL-ilo, postulas tempon por "ekfunkciigi" kiam ĝi estas lanĉita.
konkludo
Ab Initio estas nuntempe uzata ĉe Sberbank por konstrui Unified Semantic Data Layer (ESS). Ĉi tiu projekto implikas konstrui unuigitan version de la stato de diversaj bankaj komercaj entoj. Informoj venas de diversaj fontoj, kies kopioj estas preparitaj sur Hadoop. Surbaze de komercaj bezonoj, datummodelo estas preparita kaj datumtransformoj estas priskribitaj. Ab Initio ŝarĝas informojn en la ESN kaj la elŝutitaj datumoj ne nur interesas la komercon en si mem, sed ankaŭ funkcias kiel fonto por konstrui datumvendejojn. Samtempe, la funkcieco de la produkto permesas uzi diversajn sistemojn kiel ricevilon (Hive, Greenplum, Teradata, Oracle), kio ebligas facile prepari datumojn por komerco en la diversaj formatoj, kiujn ĝi postulas.
La kapabloj de Ab Initio estas larĝaj; ekzemple, la inkluzivita MDW-kadro ebligas konstrui teknikajn kaj komercajn historiajn datumojn el la skatolo. Por programistoj, Ab Initio ebligas ne reinventi la radon, sed uzi multajn ekzistantajn funkciajn komponantojn, kiuj esence estas bibliotekoj necesaj kiam oni laboras kun datumoj.
La aŭtoro estas sperta en la profesia komunumo de Sberbank SberProfi DWH/BigData. La profesia komunumo SberProfi DWH/BigData respondecas pri evoluigado de kompetentecoj en tiaj areoj kiel la Hadoop-ekosistemo, Teradata, Oracle DB, GreenPlum, same kiel BI-iloj Qlik, SAP BO, Tableau, ktp.
fonto: www.habr.com