Некаторы час таму перад намі паўстала пытанне выбару ETL-сродкі для працы з BigData. Раней якое выкарыстоўвалася рашэнне Informatica BDM не задавальняла нас з-за абмежаванай функцыянальнасці. Яе выкарыстанне звялося да фрэймворка па запуску каманд spark-submit. На рынку мелася не так шмат аналагаў, у прынцыпе здольных працаваць з тым аб'ёмам дадзеных, з якім мы маем справу кожны дзень. У выніку мы выбралі Ab Initio. У ходзе пілотных дэманстрацый прадукт паказаў вельмі высокую хуткасць апрацоўкі даных. Інфармацыі пра Ab Initio на рускай мове амаль няма, таму мы вырашылі расказаць пра свой досвед на Хабры.
Ab Initio мае мноства класічных і незвычайных трансфармацый, код якіх можа быць пашыраны з дапамогай уласнай мовы PDL. Для дробнага бізнэсу такая магутная прылада, верагодна, будзе залішняй, і большасць яго магчымасцяў могуць апынуцца дарагімі і незапатрабаванымі. Але калі вашы маштабы набліжаюцца да сбераўскіх, то вам Ab Initio можа быць цікавы.
Ён дапамагае бізнэсу глабальна збіраць веды і развіваць экасістэму, а распрацоўніку – прапампоўваць свае навыкі ў ETL, падцягваць веды ў shell, дае магчымасць засваення мовы PDL, дае візуальную карціну працэсаў загрузкі, спрашчае распрацоўку дзякуючы багаццю функцыянальных кампанентаў.
У пасце я распавяду аб магчымасцях Ab Initio і прывяду параўнальныя характарыстыкі па ім працы з Hive і GreenPlum.
- Апісанне фрэймворка MDW і прац па ім даналадцы пад GreenPlum
- Параўнальныя характарыстыкі прадукцыйнасці Ab Initio па працы з Hive і GreenPlum
- Праца Ab Initio з GreenPlum у рэжыме Near Real Time
Функцыянал гэтага прадукта вельмі шырокі і патрабуе нямала часу на сваё вывучэнне. Аднак, пры належных навыках працы і правільных наладах прадукцыйнасці вынікі апрацоўкі дадзеных атрымліваюцца вельмі ўражлівыя. Выкарыстанне Ab Initio для распрацоўніка можа даць яму цікавы досвед. Гэта новы погляд на ETL-распрацоўку, гібрыд паміж візуальным асяроддзем і распрацоўкай загрузак на скрыпта-падобнай мове.
Бізнэс развівае свае экасістэмы і гэты інструмент аказваецца яму як ніколі дарэчы. З дапамогай Ab Initio можна збіраць веды аб бягучым бізнэсе і выкарыстоўваць гэтыя веды для пашырэння старых і адкрыцця новых бізнэсаў. Альтэрнатывамі Ab Initio можна назваць з візуальных асяроддзяў распрацоўкі Informatica BDM і з невізуальных асяроддзяў – Apache Spark.
Апісанне Ab Initio
Ab Initio, як і іншыя ETL-сродкі, уяўляе сабой набор прадуктаў.
Ab Initio GDE (Graphical Development Environment) - гэта асяроддзе для распрацоўніка, у якой ён наладжвае трансфармацыі дадзеных і злучае іх струменямі дадзеных у выглядзе стрэлачак. Пры гэтым такі набор трансфармацый называецца графам:
Уваходныя і выходныя злучэнні функцыянальных кампанентаў з'яўляюцца партамі і ўтрымоўваюць палі, вылічаныя ўсярэдзіне пераўтварэнняў. Некалькі графаў, злучаных патокамі ў выглядзе стрэлачак у парадку іх выканання называюцца планам.
Ёсць некалькі сотняў функцыянальных кампанентаў, што вельмі шмат. Многія з іх вузкаспецыялізаваныя. Магчымасці класічных трансфармацый у Ab Initio шырэй, чым у іншых ETL-сродках. Напрыклад, Join мае некалькі выхадаў. Апроч выніку злучэння датасетаў можна атрымаць на вынахадзе запісу ўваходных датасетаў, па ключах якіх не атрымалася злучыцца. Таксама можна атрымаць rejects, errors і лог працы трансфармацыі, які можна ў гэтым жа графе прачытаць як тэкставы файл і апрацаваць іншымі трансфармацыямі:
Або, напрыклад, можна матэрыялізаваць прымач дадзеных у выглядзе табліцы і ў гэтым жа графе лічыць з яго дадзеныя.
Ёсць арыгінальныя трансфармацыі. Напрыклад, трансфармацыя Scan мае функцыянал, як у аналітычных функцый. Ёсць трансфармацыі з размаўлялымі назвамі: Create Data, Read Excel, Normalize, Sort within Groups, Run Program, Run SQL, Join with DB і інш. Графы могуць выкарыстоўваць параметры часу выканання, у тым ліку магчымая перадача параметраў з аперацыйнай сістэмы ці ў аперацыйную сістэму . Файлы з гатовым наборам перадаваных графу параметраў завуцца parameter sets (psets).
Як і належыць, Ab Initio GDE мае свой рэпазітар, названы EME (Enterprise Meta Environment). Распрацоўнікі маюць магчымасць працаваць з лакальнымі версіямі кода і рабіць check in сваіх распрацовак у цэнтральны рэпазітар.
Маецца магчымасць падчас выканання або пасля выканання графа клікнуць па любым які злучае трансфармацыі струмені і паглядзець на дадзеныя, якія прайшлі паміж гэтымі трансфармацыямі:
Таксама ёсць магчымасць клікнуць па любым патоку і паглядзець tracking details – у колькі паралеляў працавала трансфармацыя, колькі радкоў і байт у які з паралеляў загрузілася:
Ёсць магчымасць разбіць выкананне графа на фазы і адзначыць, што адны трансфармацыі трэба выконваць перш за ўсё (у нулявой фазе), наступныя ў першай фазе, наступныя ў другой фазе і г.д.
У кожнай трансфармацыі можна абраць так званы layout (дзе яна будзе выконвацца): без раўналежнікаў або ў раўналежных струменях, лік якіх можна задаць. Пры гэтым часовыя файлы, якія стварае Ab Initio пры працы трансфармацый, можна размяшчаць як у файлавай сістэме сервера, так і ў HDFS.
У кожнай трансфармацыі на базе шаблону па змаўчанні можна стварыць свой скрыпт на мове PDL, які крыху нагадвае shell.
З дапамогай мовы PDL вы можаце пашыраць функцыянал трансфармацый і, у прыватнасці, вы можаце дынамічна (падчас выканання) генераваць адвольныя фрагменты кода ў залежнасці ад параметраў часу выканання.
Таксама ў Ab Initio добра развіта інтэграцыя з АС праз shell. Менавіта ў Ашчадбанку выкарыстоўваецца linux ksh. Можна абменьвацца з пераменнымі shell і выкарыстоўваць іх у якасці параметраў графаў. Можна з shell выклікаць выкананне графаў Ab Initio і адміністраваць Ab Initio.
Апроч Ab Initio GDE у пастаўку ўваходзіць шмат іншых прадуктаў. Ёсць свая Co>Operation System з прэтэнзіяй звацца аперацыйнай сістэмай. Ёсць Control>Center, у якім можна ставіць на расклад і маніторыць патокі загрузкі. Ёсць прадукты для ажыццяўлення распрацоўкі на больш прымітыўным узроўні, чым дазваляе Ab Initio GDE.
Апісанне фрэймворка MDW і прац па ім даналадцы пад GreenPlum
Разам са сваімі прадуктамі вендар пастаўляе прадукт MDW (Metadata Driven Warehouse), які ўяўляе сабой канфігуратар графаў, прызначаны для дапамогі ў тыповых задачах па напаўненні сховішчаў даных або data vaults.
Ён змяшчае карыстацкія (спецыфічныя для праекту) персеры метададзеных і гатовыя генератары кода "са скрынкі".
На ўваходзе MDW атрымлівае мадэль дадзеных, канфігурацыйны файл па наладзе злучэння з базай дадзеных (Oracle, Teradata або Hive) і некаторыя іншыя наладкі. Спецыфічная для праекту частка, напрыклад, разгортвае мадэль у базе дадзеных. Скрынкавая частка прадукта генеруе графы і наладкавыя файлы да іх па загрузцы дадзеных у табліцы мадэлі. Пры гэтым ствараюцца графы (і psets) для некалькіх рэжымаў ініцыялізавальнай і інкрыментальнай працы па абнаўленні сутнасцяў.
У выпадках Hive і RDBMS генеруюцца якія адрозніваюцца графы па ініцыялізавальным і інкрымінтальнаму абнаўленню дадзеных.
У выпадку Hive якія паступілі дадзеныя дэльты злучаецца пасродкам Ab Initio Join з дадзенымі, якія былі ў табліцы да абнаўлення. Загрузчыкі дадзеных у MDW (як у Hive, так і ў RDBMS) не толькі ўстаўляюць новыя дадзеныя з дэльты, але і закрываюць перыяды актуальнасці дадзеных, па першасных ключах якіх паступіла дэльта. Акрамя таго, даводзіцца перапісаць нанава нязмененую частку дадзеных. Але так даводзіцца рабіць, паколькі ў Hive няма аперацый delete ці update.
У выпадку ж RDBMS графы па інкрэмэнтальным абнаўленні дадзеных выглядаюць больш аптымальна, таму што RDBMS маюць рэальныя магчымасці абнаўлення.
Якая паступіла дэльта загружаецца ў прамежкавую табліцу ў базу дадзеных. Пасля гэтага адбываецца злучэнне дэльты з дадзенымі, якія былі ў табліцы да абнаўлення. І робіцца гэта сіламі SQL пасродкам згенераванага SQL-запыту. Далей з дапамогай SQL-каманд delete+insert у мэтавую табліцу адбываецца ўстаўка новых дадзеных з дэльты і зачыненне перыядаў актуальнасці дадзеных, па першасных ключах якіх паступіла дэльта.
Дадзеныя перапісваць няма патрэбы.
Такім чынам, мы дашлі да высновы, што ў выпадку Hive MDW павінен пайсці на перапісванне ўсёй табліцы, таму што Hive не мае функцыі абнаўлення. І нічога лепшага поўнага перапісвання дадзеных пры абнаўленні не прыдумана. У выпадку ж RDBMS, наадварот, стваральнікі прадукта палічылі патрэбным даверыць злучэнне і абнаўленне табліц выкарыстанню SQL.
Для праекту ў Ашчадбанку мы стварылі новую шматкроць выкарыстоўваную рэалізацыю загрузніка базы дадзеных для GreenPlum. Зроблена гэта было на аснове версіі, якую MDW генеруе для Teradata. Менавіта Teradata, а не Oracle падышла для гэтага лепш і бліжэй за ўсё, т.я. таксама з'яўляецца MPP-сістэмай. Спосабы працы, а таксама сінтаксіс Teradata і GreenPlum аказаліся блізкія.
Прыклады крытычных для MDW адрозненняў паміж рознымі RDBMS такія. У GreenPlum у адрозненні ад Teradata пры стварэнні табліц трэба пісаць клаузу
distributed byУ Teradata пішуць
delete <table> all, а ў GreеnPlum пішуць
delete from <table>У Oracle у мэтах аптымізацыі пішуць
delete from t where rowid in (<соединение t с дельтой>), а ў Teradata і GreenPlum пішуць
delete from t where exists (select * from delta where delta.pk=t.pk)Яшчэ адзначым, што для працы Ab Initio з GreenPlum запатрабавалася ўсталяваць кліент GreenPlum на ўсе ноды кластара Ab Initio. Гэта таму, што мы падключыліся да GreenPlum адначасова з усіх вузлоў нашага кластара. А для таго, каб чытанне з GreenPlum было паралельным і кожны паралельны струмень Ab Initio чытаў сваю порцыю дадзеных з GreenPlum, прыйшлося ў секцыю "where" SQL-запытаў змясціць разуменую Ab Initio канструкцыю
where ABLOCAL()і вызначыць значэнне гэтай канструкцыі, паказаўшы якая чытае з БД трансфармацыі параметр
ablocal_expr=«string_concat("mod(t.", string_filter_out("{$TABLE_KEY}","{}"), ",", (decimal(3))(number_of_partitions()),")=", (decimal(3))(this_partition()))», якая кампілюецца ў нешта тыпу
mod(sk,10)=3, г.зн. даводзіцца падказваць GreenPlum відавочны фільтр для кожнай партіціі. Для іншых баз дадзеных (Teradata, Oracle) Ab Initio можа выканаць гэтае распаралельванне аўтаматычна.
Параўнальныя характарыстыкі прадукцыйнасці Ab Initio па працы з Hive і GreenPlum
У Ашчадбанку быў праведзены эксперымент у параўнанні прадукцыйнасці згенераваных MDW графаў у дачыненні да Hive і ў дачыненні да GreenPlum. У рамках эксперыменту ў выпадку Hive мелася 5 нод на тым жа кластары, што і Ab Initio, а ў выпадку GreenPlum мелася 4 ноды на асобным кластары. Г.зн. Hive меў некаторую перавагу над GreenPlum па жалезе .
Было разгледжана дзве пары графаў, якія выконваюць адну і тую ж задачу абнаўлення дадзеных у Hive і ў GreenPlum. Пры гэтым запускалі графы, згенераваныя канфігуратарам MDW:
- ініцыялізавальная загрузка + інкрыментальная загрузка выпадкова згенераваных дадзеных у табліцу Hive
- ініцыялізавальная загрузка + інкрыментальная загрузка выпадкова згенераваных дадзеных у такую ж табліцу GreenPlum
У абодвух выпадках (Hive і GreenPlum) запускалі загрузкі ў 10 раўналежных струменяў на адным і тым жа кластары Ab Initio. Прамежкавыя дадзеныя для разлікаў Ab Initio захоўваў у HDFS (у тэрмінах Ab Initio быў выкарыстаны MFS layout using HDFS). Адзін радок выпадкова згенераваных дадзеных займала ў абодвух выпадках па 200 байт.
Вынік атрымаўся такі:
Вулей:
Ініцыялізавальная загрузка ў Hive
Устаўлена радкоў
6 000 000
60 000 000
600 000 000
Працягласць ініцыялізуючай
загрузкі ў секундах
41
203
1 601
Інкрыментальная загрузка ў Hive
Колькасць радкоў, якія былі ў
мэтавай табліцы на пачатак эксперыменту
6 000 000
60 000 000
600 000 000
Колькасць радкоў дэльты, ужытых да
мэтавай табліцы ў ходзе эксперыменту
6 000 000
6 000 000
6 000 000
Працягласць інкрыментальнай
загрузкі ў секундах
88
299
2 541
GreenPlum:
Ініцыялізавальная загрузка ў GreenPlum
Устаўлена радкоў
6 000 000
60 000 000
600 000 000
Працягласць ініцыялізуючай
загрузкі ў секундах
72
360
3 631
Інкрыментальная загрузка ў GreenPlum
Колькасць радкоў, якія былі ў
мэтавай табліцы на пачатак эксперыменту
6 000 000
60 000 000
600 000 000
Колькасць радкоў дэльты, ужытых да
мэтавай табліцы ў ходзе эксперыменту
6 000 000
6 000 000
6 000 000
Працягласць інкрыментальнай
загрузкі ў секундах
159
199
321
Бачым, што хуткасць якая ініцыялізуе загрузкі як у Hive, так і ў GreenPlum лінейна залежыць ад аб'ёму дадзеных і па чынніках лепшага жалеза яна некалькі хутчэй для Hive, чым для GreenPlum.
Інкрыментальная загрузка ў Hive таксама лінейна залежыць ад аб'ёму наяўных у мэтавай табліцы раней загружаных дадзеных і праходзіць дастаткова павольна з ростам аб'ёму. Выклікана гэта неабходнасцю перазапісваць мэтавую табліцу поўнасцю. Гэта азначае, што ўжыванне маленькіх змен да велізарных табліц – не вельмі добры варыянт выкарыстання для Hive.
Інкрыментальная ж загрузка ў GreenPlum слаба залежыць ад аб'ёму наяўных у мэтавай табліцы раней загружаных дадзеных і праходзіць дастаткова хутка. Атрымалася гэта дзякуючы SQL Joins і архітэктуры GreenPlum, якая дапускае аперацыю delete.
Такім чынам, GreenPlum улівае дэльту шляхам delete+insert, а ў Hive няма аперацый delete або update, таму ўвесь масіў дадзеных пры інкрыментальным абнаўленні былі змушаныя перапісваць цалкам. Найбольш паказальна параўнанне выдзеленых тоўстым вочак, так як яно адпавядае найбольш частаму варыянту эксплуатацыі рэсурсаёмістых загрузак. Бачым, што GreenPlum выйграў у Hive у гэтым тэсце ў 8 разоў.
Праца Ab Initio з GreenPlum у рэжыме Near Real Time
У гэтым эксперыменце праверым магчымасць Ab Initio вырабляць абнаўленне табліцы GreenPlum выпадкова фармаванымі порцыямі дадзеных у рэжыме, блізкім да рэальнага часу. Разгледзім табліцу GreenPlum dev42_1_db_usl.TESTING_SUBJ_org_finval, з якой будзе весціся праца.
Будзем выкарыстоўваць тры графы Ab Initio па працы з ёй:
1) Граф Create_test_data.mp - стварае ў 10 паралельных патокаў файлы з дадзенымі ў HDFS на 6 000 000 радкоў. Дадзеныя выпадковыя, структура іх арганізавана для ўстаўкі ў нашу табліцу
2) Граф mdw_load.day_one.current.dev42_1_db_usl_testing_subj_org_finval.pset - згенераваны MDW граф па ініцыялізавальнай устаўцы дадзеных у нашу табліцу ў 10 паралельных патокаў (выкарыстоўваюцца тэставыя дадзеныя, згенераваныя графам (1)
3) Граф mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset - згенераваны MDW граф па інстрамэнтальнаму абнаўленню нашай табліцы ў 10 паралельных патокаў з выкарыстаннем порцыі свежых паступілі дадзеных (дэльты), згенераваных граф
Выканаем ніжэйпрыведзены сцэнар у рэжыме NRT:
- згенераваць 6 тэставых радкоў
- вырабіць ініцыялізавальную загрузку ўставіць 6 000 000 тэставых радкоў у пустую табліцу
- паўтарыць 5 разоў інкрыментальную загрузку
- згенераваць 6 тэставых радкоў
- вырабіць інкрыментальную ўстаўку 6 000 000 тэставых радкоў у табліцу (пры гэтым старым дадзеным прастаўляецца час заканчэння актуальнасці valid_to_ts і ўстаўляюцца свежыя дадзеныя з тым жа першасным ключом)
Такі сцэнар эмулюе рэжым рэальнай працы нейкай бізнэс-сістэмы - у рэжыме рэальнага часу з'яўляецца досыць аб'ёмная порцыя новых дадзеных і тут жа ўліваецца ў GreenPlum.
Цяпер паглядзім лог працы сцэнара:
Start Create_test_data.input.pset at 2020-06-04 11:49:11
Finish Create_test_data.input.pset at 2020-06-04 11:49:37
Start mdw_load.day_one.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 11:49:37
Finish mdw_load.day_one.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 11:50:42
Start Create_test_data.input.pset at 2020-06-04 11:50:42
Finish Create_test_data.input.pset at 2020-06-04 11:51:06
Start mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 11:51:06
Finish mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 11:53:41
Start Create_test_data.input.pset at 2020-06-04 11:53:41
Finish Create_test_data.input.pset at 2020-06-04 11:54:04
Start mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 11:54:04
Finish mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 11:56:51
Start Create_test_data.input.pset at 2020-06-04 11:56:51
Finish Create_test_data.input.pset at 2020-06-04 11:57:14
Start mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 11:57:14
Finish mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 11:59:55
Start Create_test_data.input.pset at 2020-06-04 11:59:55
Finish Create_test_data.input.pset at 2020-06-04 12:00:23
Start mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 12:00:23
Finish mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 12:03:23
Start Create_test_data.input.pset at 2020-06-04 12:03:23
Finish Create_test_data.input.pset at 2020-06-04 12:03:49
Start mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 12:03:49
Finish mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 12:06:46
Атрымліваецца такая карціна:
Графік
Час пачатку
Час заканчэння
Даўжыня
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
Бачым, што 6 000 000 радкоў інкрэмента апрацоўваюцца за 3 хвіліны, што досыць хутка.
Дадзеныя ў мэтавай табліцы атрымаліся размеркаванымі наступным чынам:
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;
Можна разглядзець адпаведнасць устаўленых дадзеных момантам запуску графаў.
Значыць можна запускаць у Ab Initio інкрыментальную загрузку дадзеных у GreenPlum з вельмі высокай частатой і назіраць высокую хуткасць устаўкі гэтых дадзеных у GreenPlum. Вядома, раз у секунду запускацца не атрымаецца, бо Ab Initio, як і любы ETL-сродак, пры запуску патрабуе часу "на разварушванне".
Заключэнне
Цяпер Ab Initio выкарыстоўваецца ў Ашчадбанку для пабудовы Адзінага семантычнага пласта дадзеных (ЕСС). Гэты праект мае на ўвазе пабудову адзінай версіі стану розных банкаўскіх бізнес-сутнасцяў. Інфармацыя прыходзіць з розных крыніц, рэплікі якіх рыхтуюцца да Hadoop. Зыходзячы з запатрабаванняў бізнэсу, рыхтуецца мадэль дадзеных і апісваюцца трансфармацыі дадзеных. Ab Initio загружае інфармацыю ў ЕСС і загружаныя дадзеныя не толькі ўяўляюць цікавасць для бізнесу самі па сабе, але і служаць крыніцай для пабудовы вітрын даных. Пры гэтым функцыянал прадукта дазваляе выкарыстоўваць у якасці прымача розныя сістэмы (Hive, Greenplum, Teradata, Oracle), што дае магчымасць без асаблівых намаганняў падрыхтоўваць дадзеныя для бізнесу ў розных патрабаваных яму фарматах.
Магчымасці Ab Initio шырокія, напрыклад, які прыкладаецца фрэймворк MDW дае магчымасць будаваць тэхнічную і бізнэс-гістарычнасць дадзеных "са скрынкі". Для распрацоўнікаў Ab Initio дае магчымасць "не вынаходзіць ровар", а карыстацца мноствам наяўных функцыянальных кампанентаў, якія па сутнасці з'яўляюцца бібліятэкамі, патрэбнымі пры працы з дадзенымі.
Аўтар - эксперт прафесійнай супольнасці Ашчадбанка SberProfi DWH / BigData. Прафесійная супольнасць SberProfi DWH/BigData адказвае за развіццё кампетэнцый у такіх кірунках, як экасістэма Hadoop, Teradata, Oracle DB, GreenPlum, а таксама BI інструментах Qlik, SAP BO, Tableau і інш.
Крыніца: habr.com