Любая аперацыя з вялікімі дадзенымі патрабуе вялікіх вылічальных магутнасцей. Звычайнае перасоўванне дадзеных з базы на Hadoop можа доўжыцца тыднямі ці каштаваць, як крыло самалёта. Не хочаце чакаць і марнавацца? Збалансуйце нагрузку на розныя платформы. Адзін са спосабаў - pushdown-аптымізацыя.
Я папрасіў вядучага ў Расіі трэнера па распрацоўцы і адміністраванні прадуктаў Informatica Аляксея Ананьева расказаць аб функцыі pushdown-аптымізацыі ў Informatica Big Data Management (BDM). Калісьці вучыліся працаваць з прадуктамі Informatica? Хутчэй за ўсё менавіта Аляксей расказваў вам асновы PowerCenter і тлумачыў, як будаваць мапінгі.
Аляксей Ананьеў, кіраўнік накіравання па навучанні DIS Group
Што такое pushdown?
Многія з вас ужо знаёмыя з Informatica Big Data Management (BDM). Прадукт умее інтэграваць вялікія дадзеныя з розных крыніц, перамяшчаць іх паміж рознымі сістэмамі, забяспечвае да іх лёгкі доступ, дазваляе прафіляваць іх і шматлікае іншае.
Ва ўмелых руках BDM здольны тварыць цуды: задачы будуць выконвацца хутка і з мінімальнымі вылічальнымі рэсурсамі.
Таксама так хочаце? Навучыцеся выкарыстоўваць функцыю pushdown у BDM для размеркавання вылічальнай нагрузкі паміж рознымі платформамі. Тэхналогія pushdown дазваляе ператварыць мапінг у скрыпт і абраць асяроддзе, у якім гэты скрыпт запусціцца. Магчымасць такога выбару дазваляе камбінаваць моцныя бакі розных платформаў і дасягаць іх максімальнай прадукцыйнасці.
Для налады асяроддзя выканання скрыпту трэба абраць тып pushdown. Скрыпт можа быць цалкам запушчаны на Hadoop ці часткова размеркаваны паміж крыніцай і прымачом. Ёсць 4 магчымыя тыпу pushdown. Мапінг можна не ператвараць у скрыпт (native). Мапінг можна выканаць максімальна на крыніцы (source) ці цалкам на крыніцы (full). Таксама мапінг можна ператварыць у скрыпт Hadoop (none).
Pushdown-аптымізацыя
Пералічаныя 4 тыпы можна па-рознаму камбінаваць - аптымізаваць pushdown пад пэўныя патрэбы сістэмы. Напрыклад, часта мэтазгодней выняць дадзеныя з базы дадзеных, ужываючы яе ўласныя магчымасці. А пераўтварыць дадзеныя - сіламі Hadoop, каб саму базу не перагружаць.
Давайце разгледзім выпадак, калі і крыніца, і прымач знаходзяцца ў БД, а платформу выканання пераўтварэнняў можна абраць: у залежнасці ад налад гэта будзе Informatica, сервер БД ці Hadoop. Такі прыклад дазволіць найболей сапраўды зразумець тэхнічны бок працы гэтага механізму. Натуральна, у рэальным жыцці, такая сітуацыя не ўзнікае, але для дэманстрацыі функцыяналу яна падыходзіць найлепшым чынам.
Возьмем мапінг для чытання дзвюх табліц у адзінай базе дадзеных Oracle. А вынікі чытання няхай запісваюцца ў табліцу ў гэтай жа базе. Схема мапінгу будзе такая:
У выглядзе мапінгу на Informatica BDM 10.2.1 гэта выглядае такім чынам:
Тып pushdown - native
Калі мы абяром тып pushdown native, то мапінг будзе выкананы на серверы Informatica. Дадзеныя будуць прачытаны з сервера Oracle, перанесены на сервер Informatica, трансфармаваны там і перададзены ў Hadoop. Іншымі словамі, мы атрымаем звычайны ETL-працэс.
Тып pushdown - source
Пры выбары тыпу source мы атрымліваем магчымасць размеркаваць наш працэс паміж серверам базы дадзеных (БД) і Hadoop. Пры выкананні працэсу з гэтай наладай у базу паляцяць запыты на выбарку дадзеных з табліц. А астатняе будзе выконвацца ў выглядзе крокаў да Hadoop.
Схема выканання будзе выглядаць так:
Ніжэй - прыклад налады асяроддзя выканання.
У гэтым выпадку мапінг будзе выконвацца ў два крокі. У яго наладах мы ўбачым, што ён ператварыўся ў скрыпт, які будзе адпраўлены на крыніцу. Прычым аб'яднанне табліц і пераўтварэнне даных выканаецца ў выглядзе перавызначанага запыту на крыніцы.
На малюнку ніжэй, мы бачым аптымізаваны мапінг на BDM, а на крыніцы - перавызначаны запыт.
Роля Hadoop у дадзенай канфігурацыі звядзецца да кіравання струменем дадзеных дырыжыравання імі. Вынік запыту будзе накіраваны ў Hadoop. Пасля завяршэння чытання файл з Hadoop будзе запісаны ў прымач.
Тып pushdown - full
Пры выбары тыпу full мапінг цалкам ператварыцца ў запыт на БД. А вынік запыту будзе накіраваны на Hadoop. Схема такога працэсу прадстаўлена ніжэй.
Прыклад наладкі прадстаўлены ніжэй.
У выніку мы атрымаем аптымізаваны мапінг падобны да папярэдняга. Розніца толькі ў тым, што ўся логіка пераносіцца на прымач у выглядзе перавызначэння яго ўстаўкі. Прыклад аптымізаванага мапінгу прадстаўлены ніжэй.
Тут, як і ў папярэднім выпадку, Hadoop выконвае ролю дырыжора. Але тут чытанне крыніцы рабіцца цалкам, а далей на ўзроўні прымача выконваецца логіка апрацоўкі дадзеных.
Тып pushdown - null
Ну і апошні варыянт тып pushdown, у рамках якога наш мапінг ператворыцца ў скрыпт на Hadoop.
Аптымізаваны мапінг зараз будзе выглядаць так:
Тут дадзеныя з файлаў-крыніц спачатку будуць прачытаныя на Hadoop. Затым яго ж сродкамі гэтыя два файлы будуць аб'яднаны. Пасля гэтага дадзеныя будуць пераўтвораны і выгружаны ў БД.
Разумеючы прынцыпы pushdown-аптымізацыі, можна вельмі эфектыўна арганізаваць многія працэсы працы з вялікімі дадзенымі. Так, зусім нядаўна адна буйная кампанія ўсяго за некалькі тыдняў выгрузіла са сховішча ў Hadoop вялікія дадзеныя, якія да гэтага збірала некалькі гадоў.
Крыніца: habr.com